Contexte et objectifs
Publiée le 2 octobre 2026, la note d’AutoSynthData décrit la réponse de ServiceNow CoreAI aux lacunes observées lors des évaluations d’agents conversationnels en environnement d’entreprise. Les modèles, même très capables, échouent sur des flux de travail spécifiques, des contraintes d’outil ou des politiques internes. L’objectif déclaré est de transformer ces échecs en jeux de données synthétiques qui reflètent les exigences réelles du système d’information, afin d’alimenter un cycle d’apprentissage continu.
Architecture du pipeline AutoSynthData
Le pipeline s’articule autour de trois composantes : la spécification du système, le prompt utilisateur et le vérificateur. La spécification encode les politiques, les outils accessibles et l’état initial (par exemple une base de connaissances pré‑chargée). Le prompt décrit la tâche demandée par l’utilisateur. Le vérificateur, quant à lui, doit être cohérent, sonore et complet, c’est‑à‑dire accepter toutes les solutions valides tout en rejetant les trajectoires non conformes. Cette tripartition garantit que chaque tâche synthétique reste ancrée dans l’environnement cible.
Mécanismes de génération et de vérification
AutoSynthData commence par exécuter des tâches de diagnostic sur le modèle cible et un modèle enseignant plus performant. Les écarts de performance sont résumés dans des « capability specification cards », qui décrivent le workflow, les outils impliqués et les critères d’état final. Le générateur ne reçoit pas les prompts ou trajectoires d’origine ; il ne travaille qu’à partir de ces cartes, créant ainsi de nouvelles variantes de prompts, d’états initiaux et de chemins de solution. Chaque variante est soumise à une validation en environnement réel : si le vérificateur accepte la solution, l’échantillon est conservé pour l’étape post‑entraînement.
Évaluation et limites
L’expérimentation « EnterpriseOps Gym » (Malay et al., 2026) montre que le processus itératif réduit progressivement le nombre de tâches non résolues par le modèle cible. Cependant, la qualité du vérificateur reste un facteur de risque : un vérificateur trop permissif introduit du bruit, tandis qu’un vérificateur excessivement restrictif élimine des solutions valides. De plus, la génération dépend fortement de la capacité du modèle enseignant à fournir des solutions correctes, ce qui peut limiter l’applicabilité à des domaines où aucun enseignant supérieur n’est disponible. Enfin, le texte ne fournit pas de métriques chiffrées sur le gain de performance, ce qui empêche une quantification précise de l’impact.
