ServiceNow transforme les échecs des agents en données d'entraînement

Chaque équipe qui a déployé un agent IA dans un système d'entreprise réel connaît la même douleur. Le modèle est globalement compétent, puis il rencontre vos outils spécifiques, vos politiques spécifiques, votre fouillis particulier de machine à états, et il trébuche.

La branche de recherche de ServiceNow, CoreAI, a publié un système qui tente de transformer ces trébuchements en atout. Il s'appelle AutoSynthData, et son postulat est que les échecs d'un modèle constituent la matière première la plus précieuse dont vous disposez pour l'entraîner.

Le mécanisme central

Le pipeline commence par exécuter un modèle cible et un modèle enseignant plus puissant sur les mêmes tâches de diagnostic dans un environnement réel. Là où le modèle cible échoue et où l'enseignant réussit, il existe un écart de compétence. AutoSynthData distille cet écart dans ce que l'équipe appelle des fiches de spécification de compétence : des descriptions assainies des outils, des workflows, des états finaux et des variations autorisées impliqués, dépouillées des prompts d'évaluation d'origine et des détails d'entités.

Ces fiches amorcent la génération de nouvelles tâches. Fait crucial, le générateur ne voit jamais les trajectoires d'évaluation d'origine, de sorte que les données produites testent la compétence sous-jacente plutôt que des séquences mémorisées. Le framework met cela à l'échelle en deux phases. Une phase cible crée des tâches de base en parallèle. Une phase de multiplication reprend les tâches vérifiées et génère des variantes avec de nouvelles formulations, de nouvelles configurations d'entités et de nouveaux états initiaux. Une règle empêche les données de dériver : un échantillon multiplié ne peut jamais servir à amorcer une autre multiplication.

Trois conditions pour qu'une tâche vaille la peine d'être générée

ServiceNow précise clairement qu'une requête d'apparence plausible ne suffit pas. Une tâche générée doit satisfaire trois exigences à la fois.

Elle doit être faisable, ce qui signifie qu'il existe au moins un chemin exécutable dans l'environnement qui accomplit la requête tout en respectant les règles. Elle doit être réaliste, c'est-à-dire refléter un travail qu'un utilisateur réel demanderait vraiment, plutôt qu'une action techniquement valide que personne n'entreprendrait. Et elle doit être difficile, c'est-à-dire cibler une faiblesse réelle. Une tâche triviale n'enseigne rien, et une tâche impossible enseigne la mauvaise leçon.

Chaque tâche est livrée avec un vérificateur, et le vérificateur doit lui-même répondre à des critères exigeants. Il doit être cohérent avec le prompt et l'état du système, suffisamment rigoureux pour rejeter les violations de contraintes, et suffisamment complet pour accepter toute solution fonctionnelle plutôt que d'imposer un seul chemin de référence.

Les portes de qualité sont le véritable produit

La partie qui mérite l'attention n'est pas la génération de tâches. C'est la vérification.

Chaque candidat passe deux portes. Une porte positive exécute la solution de référence dans l'environnement pour confirmer que la réponse attendue satisfait bien le vérificateur, ce qui permet de détecter les inadéquations entre le prompt, l'état initial et les critères de réussite. Une porte négative mute ensuite délibérément l'état final pour confirmer que les résultats erronés sont effectivement rejetés. C'est cette seconde porte qui permet de repérer les vérificateurs sous-spécifiés, ceux qui récompenseraient volontiers une trajectoire d'agent mal formée.

Lorsqu'un candidat échoue, un critique diagnostique la défaillance, repère les références cassées ou les états contradictoires, et oriente une réparation limitée plutôt que de rejeter le travail d'emblée. Au niveau supérieur, une revue par lots surveille l'agrégat : quels groupes de tâches sont surreprésentés, quelles dimensions manquent, quels schémas de génération n'arrêtent pas de caler. Le contrôleur oriente alors le lot suivant vers les lacunes qui subsistent.

Pourquoi les données synthétiques sont vraiment nécessaires

Il vaut la peine de prendre du recul pour se demander pourquoi cela compte. Les données d'entraînement idéales pour un agent d'entreprise sont un enregistrement de personnes réelles accomplissant un travail réel dans le système réel, correctement étiqueté. Ces données sont rares, sensibles et coûteuses à collecter, et une grande partie ne peut pas quitter les locaux pour des raisons de confidentialité ou de conformité.

La génération synthétique est la porte de sortie, mais elle comporte un mode de défaillance connu. Si vous générez des tâches à partir d'un modèle, vous héritez des angles morts de ce modèle, et les données produites peuvent sembler abondantes tout en enseignant très peu. Toute la contribution d'AutoSynthData réside dans la mécanique entourant la génération qui maintient l'honnêteté des données : des portes qui rejettent les mauvaises tâches, des contrôles de diversité qui empêchent la répétition, et un curriculum qui continue de viser ce que l'agent n'a pas encore maîtrisé. Une génération sans vérification est du bruit. C'est une tentative d'en faire un signal.

Ce que les chiffres disent, et ne disent pas

Dans des tests sur EnterpriseOps Gym, un environnement open source pour les tâches d'agents d'entreprise, un modèle basé sur Gemma affiné sur 2 000 échantillons AutoSynthData a amélioré sa métrique Pass@1 de 35 % par rapport à la référence dans un domaine hybride. Dans le domaine ITSM, l'affinage supervisé synthétique a fait passer le Pass@1 moyen de 18,77 % à 27,18 %.

Ce sont de vrais gains sur un benchmark spécifique, ce qui n'est pas la même chose qu'un résultat général. La dépendance centrale du pipeline est honnête et mérite d'être énoncée clairement : il a besoin d'un modèle enseignant nettement plus puissant pour démontrer le comportement correct, et d'un environnement de simulation précis pour effectuer les tests. Dans une entreprise dépourvue de sandbox haute fidélité et de vérificateurs déterministes fiables, construire la couche d'exécution est en soi un projet d'ingénierie sérieux. AutoSynthData ne supprime pas ce travail. Il change la finalité de ce travail.

Le hic du modèle enseignant

Il y a dans cette conception une dépendance qui mérite sa propre phrase. Tout le pipeline repose sur l'écart entre un modèle faible et un modèle fort. Dans les expériences, l'enseignant était un modèle bien plus grand que la cible. Cela fonctionne quand vous avez un système de pointe à emprunter. Cela fonctionne moins bien lorsque vous êtes vous-même à la pointe, ou lorsque la tâche est si spécialisée qu'aucun modèle plus fort n'existe pour la démontrer. Dans ce cas, le pipeline n'a rien dont il puisse apprendre, et l'écart de compétence sur lequel il repose n'est qu'un mur. La recherche sur la génération de données d'entraînement finit toujours par se heurter à cela : la méthode passe à l'échelle tant que quelqu'un, quelque part, a déjà résolu le problème.

Pourquoi cela définit la forme de l'IA d'entreprise

Ce qui est intéressant dans cette publication, c'est ce qu'elle admet sur la situation réelle de l'IA d'entreprise. Le goulot d'étranglement n'est plus l'obtention d'un modèle compétent. Le goulot d'étranglement, c'est de faire fonctionner correctement un modèle compétent au sein d'une organisation particulière, avec ses outils et ses règles particuliers, là où les défaillances sont subtiles et l'espace d'états vaste.

Pendant des années, la réponse a été l'annotation manuelle, qui est lente, coûteuse et difficile à mettre à l'échelle. AutoSynthData soutient que les défaillances elles-mêmes contiennent le signal, si vous pouvez les extraire, les vérifier et les diversifier sans divulguer l'ensemble d'évaluation. Le pipeline est disponible pour la recherche sur Hugging Face, et l'équipe annonce que l'apprentissage par renforcement utilisant la même méthodologie est la prochaine étape.

Si cela fonctionne de manière générale, l'implication est que la compétence rare dans l'IA d'entreprise se déplace. Il ne s'agit plus d'acquérir des données, mais de construire des environnements suffisamment bons pour y générer des données dignes de confiance. C'est un problème plus difficile, et plus durable, car l'environnement d'une entreprise est ce qu'aucun concurrent ne peut copier.