AutoSynthData transforme les échecs d’un agent d’entreprise en données d’entraînement
ServiceNow CoreAI publie AutoSynthData, un pipeline qui convertit les lacunes d’un agent d’entreprise en tâches d’entraînement synthétiques, chacune décrite par une spécification système, un prompt et un vérificateur. Sur le benchmark EnterpriseOps Gym, le fine-tune améliore le Pass@1 de 35 % en relatif, sans jamais toucher aux données d’évaluation d’origine.
2 octobre 2026. ServiceNow CoreAI publie AutoSynthData, un pipeline qui transforme les lacunes d’un agent d’entreprise en données d’entraînement synthétiques, sur le blog Hugging Face. 2 octobre 2026. L’idée centrale tient en une équation : une tâche agentique est un triplet « spécification système + prompt utilisateur + vérificateur », et c’est la vérification — pas la génération — qui fait la qualité des données. 2 octobre 2026. Sur le benchmark EnterpriseOps Gym, le fine-tune obtenu améliore le Pass@1 de 7,2 points en moyenne (+35 % en relatif) dans le domaine Hybrid, et de 18,77 % à 27,18 % dans le domaine ITSM. Pourquoi c’est important : les entreprises butent sur un plafond que ni plus de paramètres ni plus de données génériques ne franchissent — la clé est de fabriquer des données qui ciblent précisément ce que leur modèle échoue à faire.
La tâche agentique, objet formel
Le point de départ est une formalisation. AutoSynthData décrit une tâche agentique comme un triplet : la spécification système (les instructions, les politiques et l’état initial, par exemple une base de données amorcée), le prompt utilisateur (ce que l’utilisateur demande), et le vérificateur (qui décide si la trajectoire produite a réussi).
Chaque composant a ses propriétés. Un prompt utile doit être réalisable (au moins une trajectoire valide existe dans l’environnement), réaliste (il ressemble à ce qu’un utilisateur demanderait vraiment) et difficile (il expose une faiblesse du modèle, car une tâche déjà résolue n’apporte pas de signal). Le vérificateur, lui, doit être cohérent avec le prompt, rigoureux (il rejette les trajectoires qui échouent) et complet (il accepte les solutions valides sans en imposer une seule). Un vérificateur laxiste récompense des comportements faux ; un vérificateur trop strict pénalise des solutions correctes.
Des échecs au curriculum
Le pipeline part des échecs du modèle. AutoSynthData évalue le modèle cible et un enseignant plus fort dans l’environnement, puis identifie où le cible échoue et comment l’enseignant réussit. Ces observations sont distillées en cartes de spécification de capacité, expurgées de tout ce qui pourrait fuiter : le générateur ne reçoit ni les prompts, ni les entités, ni les trajectoires, ni les vérificateurs d’origine.
Il reçoit les cartes, et s’en sert pour créer des tâches nouvelles — d’autres prompts, d’autres états, d’autres chemins de solution. Autrement dit, le système ne réentraîne pas sur les tests d’évaluation : il apprend quoi enseigner, puis fabrique des exercices inédits qui exercent la même capacité. Quand le modèle s’améliore, le curriculum se déplace vers ce qui lui résiste encore.
Générer, puis multiplier
La construction du jeu de données se fait en deux phases. La phase Target crée le noyau d’échantillons à partir des cartes de capacité : des travailleurs génèrent des tâches en parallèle, et chaque candidate passe par la validation, l’exécution, l’évaluation du solveur et la réparation avant d’être acceptée. La phase Multiply étend le jeu en créant des variantes inédites des échantillons acceptés, chacune avec sa propre requête, son état, ses entités et son vérificateur — et chacune devant repasser les mêmes contrôles. Une variante ne peut pas amorcer une autre variante : l’expansion reste ancrée au noyau vérifié, ce qui limite la dérive entre générations.
Côté implémentation, AutoSynthData sépare le contrôleur partagé — génération, contrôle qualité, couverture, construction du jeu — de l’adaptateur propre à l’environnement, chargé de l’exécution, de la relecture des trajectoires de référence et de la vérification déterministe.
Vérifier avant d’accepter
Générer une requête plausible ne suffit pas. Une tâche peut être impossible dans l’environnement, sa solution de référence peut échouer à l’exécution, ou son vérificateur peut récompenser un mauvais état final. AutoSynthData contrôle donc la qualité à deux niveaux.
Au niveau de l’échantillon, chaque candidate passe une vérification positive (la solution prévue résout-elle bien la tâche ?) et une vérification négative (les résultats incorrects échouent-ils bien ?). Cette seconde porte est cruciale : elle détecte les vérificateurs trop faibles qui accordent le succès sans exiger le comportement attendu. Les candidates qui échouent passent par un critique qui diagnostique la cause — état incohérent, workflow impossible, vérificateur défaillant — et guide une réparation à nombre d’essais borné, plutôt que de repartir de zéro.
La calibration de la difficulté repose sur une règle de trois essais : une tâche n’est acceptée que si le modèle cible la résout au plus une fois sur trois, tandis que le solveur plus fort la résout au moins deux fois sur trois. Ce filtre maintient les échantillons dans la zone utile — assez durs pour exposer une faiblesse, assez résolubles pour que l’enseignant fournisse une démonstration fiable.
Au niveau du lot, une méta-revue examine l’ensemble accepté : quelles familles de tâches sont surreprésentées, quelles dimensions de capacité manquent, quelles cibles échouent systématiquement à la génération. Le contrôleur réduit alors la génération dans les régions saturées et la redirige vers les lacunes.
Les chiffres : Hybrid et ITSM
Les expériences, menées sur EnterpriseOps Gym, donnent une mesure concrète. Dans le domaine Hybrid, avec Gemma-4-26B-A4B-it comme cible et Qwen3.8-27B comme enseignant, le pipeline a généré 2 000 échantillons en environ 18 heures. Le meilleur checkpoint (époque 5) améliore le Pass@1 moyen de 7,2 points, soit +35 % en relatif, fait passer le succès du vérificateur de 63,01 % à 68,55 %, et comble 59 % de l’écart initial entre Gemma et le modèle de référence.
Dans le domaine ITSM, avec DeepSeek-V4.1-Flash comme enseignant, le pipeline a produit 1 994 échantillons en 66 heures — une génération plus lente, antérieure aux optimisations de débit — et fait passer le Pass@1 de 18,77 % à 27,18 %. La méthode tient dans un second domaine, ce qui écarte l’hypothèse d’un sur-apprentissage propre à Hybrid.
Les limites et la suite
AutoSynthData reste une démonstration ciblée, et ses auteurs en posent eux-mêmes les bornes. Les expériences portent sur le SFT (supervised fine-tuning) ; la même mécanique pourrait alimenter l’apprentissage par renforcement — générer des tâches qui défient la politique courante, entraîner, puis déplacer la cible de génération avec la politique mise à jour — mais ce n’est encore qu’une piste annoncée.
La difficulté de fond n’est pas la génération de texte, mais la vérification. Écrire un vérificateur rigoureux et complet pour des tâches d’entreprise — où « réussir » dépend d’un état de base de données, d’une politique métier ou d’une chaîne d’outils — reste un problème ouvert. AutoSynthData le contourne par la vérification négative et la réparation assistée, mais la qualité finale du fine-tune restera plafonnée par la qualité des vérificateurs que l’entreprise est capable d’écrire.
Cette publication s’inscrit dans un mouvement plus large : après l’ère des données synthétiques « à grande échelle », de type self-instruct, le champ se déplace vers des données exécutables et vérifiables, ancrées dans un environnement réel. AutoSynthData en est une déclinaison d’entreprise : la donnée n’est pas générée pour ressembler à du texte, mais pour être exécutée et jugée.
Verdict
Si vos agents d’entreprise plafonnent malgré des modèles plus gros, le levier n’est pas un énième fine-tune sur données génériques : c’est un pipeline piloté par les échecs, qui fabrique des tâches synthétiques ciblées, chacune validée par un vérificateur rigoureux et complet. Le vrai goulot n’est pas la génération, mais le vérificateur : c’est lui qui détermine si vos données d’entraînement apprennent le bon comportement ou récompensent des raccourcis. Si vous démarrez de zéro, commencez par formaliser vos tâches en triplet « spécification + prompt + vérificateur » et investissez dans les portes positive et négative avant de multiplier le volume : les 35 % d’AutoSynthData viennent de la qualité des vérifications, pas de la quantité de texte.