PROOF-Gen : comment les parcours infructueux d'un agent IA deviennent de meilleures données d'entraînement

PROOF-Gen récupère les parcours réussis à partir des échecs des agents IA et les convertit en données propres pour une distillation de modèles plus sûre et contrôlée.

Quelle est la valeur d’un agent IA qui exécute correctement presque toutes les étapes d’une tâche, mais échoue à l’étape qui détermine le résultat final ? Dans la plupart des pipelines de génération et de filtrage, l’ensemble du parcours est rejeté. La tâche PROOF-Gen : des données optimisées à une meilleure distillation L'étude d'Anh Ta, Junjie Zhu et Shahin Shayandeh soutient que c'est précisément ainsi que l'on perd les scénarios complexes qu'un modèle plus petit doit apprendre à résoudre.

PROOF-Gen, de la Optimisation réflexive par scénario pour remédier aux échecs de génération, intègre une étape de récupération avant le fine-tuning supervisé. Un « reflector » lit la trace d’exécution ayant échoué et le retour d’information des évaluateurs, génère un guidage correctif provisoire et guide le même exécuteur vers une nouvelle exécution depuis le début. Si tous les contrôles sont réussis, le guidage est supprimé avant l’entraînement de l’« étudiant ».

La lacune du modèle « generate-and-filter »

La première phase habituelle de la distillation de modèles pour les agents d'appel d'outils consiste en un ajustement fin supervisé sur des trajectoires générées par un modèle « enseignant » puissant. Le pipeline exécute chaque tâche, vérifie le résultat final et ne conserve que les traces qui ont réussi. Cette logique protège l'ensemble d'entraînement contre les exemples manifestement erronés, mais un filtre binaire traite de la même manière une exécution qui a échoué immédiatement et une exécution qui a mené à bien quatre des cinq étapes requises.

Dans l'analyse des tâches effectuées sur le t2-bench, 473 essais sur 834 ont échoué. Parmi ces échecs, 67 % avaient correctement exécuté plus de la moitié des appels d'outils requis. Les chercheurs décrivent des « near-misses » dans lesquels l’agent avait exécuté les routines mais avait omis une action cruciale, telle qu’un basculement en itinérance, l’envoi d’un SMS d’autorisation ou un réapprovisionnement en données. Une seule omission suffisait à entraîner une erreur d’environnement ou d’état de la base de données.

Cela revêt une importance opérationnelle immédiate. Qu'il s'agisse du service client, des opérations de commerce électronique ou des flux de travail internes, un ensemble d'entraînement qui ne retient que les réussites faciles devient le reflet de ce que le « teacher » résout déjà. Les points de décision difficiles sont absents, alors que c’est là que se concentre le véritable risque. La distinction entre la bonne réponse et le bon artefact apparaît également dans le K-Bench pour l'évaluation des agents IA.

Comment fonctionne PROOF-Gen ?

Pour chaque tâche ayant échoué, le « reflector » reçoit l'intégralité de la trace d'exécution ainsi que les retours du vérificateur : quelle assertion a échoué, quel état est resté erroné et où une nouvelle décision est nécessaire. Il rédige ensuite une fiche aide-mémoire provisoire contenant des conseils pratiques, tels que l'ordre correct d'utilisation des outils ou la condition qui a été ignorée.

L'exécuteur recommence la tâche depuis le début en suivant ces instructions. En cas de nouvel échec, le réflecteur révise la fiche de référence et effectue une nouvelle tentative, jusqu'à un maximum de dix itérations au cours de l'expérience. L'optimisation s'effectue scénario par scénario. Contrairement à une optimisation générale des prompts qui recherche des instructions pour de nombreuses entrées, ici, le prompt peut être sur-adapté à une tâche spécifique, car il est temporaire et sera rejeté.

Le produit, ce n'est pas la fiche de référence, mais la trajectoire menant au succès. Avant d'entrer dans l'ensemble d'entraînement, le guidage provisoire est supprimé. L'apprenant voit les décisions, les appels de fonctions et le résultat final, et non pas l'échafaudage qui a aidé l'enseignant à les produire. Ainsi, le pipeline vise à transmettre un comportement de résolution sans reproduire les indications spécifiques à la tâche.

Quels résultats ont donné le T2-bench et le BFCL ?

Le pool de formation en télécommunications de t2-bench comptait 2 171 tâches. Le modèle GPT-4o teacher a initialement réussi 158 tâches et échoué sur 2 013. Les chercheurs ont envoyé 300 échecs dans la boucle de récupération et en ont récupéré 279, soit 93 %. Les 264 ont été attribuées à l'aide de la fiche de référence et les 15 à une relecture stochastique réussie du simulateur d'utilisateur. L'ensemble de formation final en télécommunications contenait 437 trajectoires, dont 64 % provenaient de la récupération.

Dans le cadre du BFCL v4 multi-turn, le « teacher » a réussi 296 des 560 tâches d'entraînement. La méthode a également été appliquée aux 264 échecs et a permis d'en récupérer 89, soit un taux de 33,7 %. Ce faible taux de récupération ne remet pas en cause le principe ; il montre simplement que la répartition des difficultés et les capacités du vérificateur influencent le résultat. Le taux de récupération doit toujours être considéré en parallèle avec le pool d'échecs initial.

Grâce à l'entraînement combiné, le modèle Qwen3-4B-Instruct-2507 a vu ses performances sur le t2-bench passer de Pass@1 0,132 à 0,529. L'article mentionne également une amélioration de 7,2 points de pourcentage pour le modèle Gemma 4 E4B-it sur le benchmark BFCL v4 multi-turn. Il s'agit là des résultats obtenus sur deux configurations de benchmark, et non d'une affirmation générale selon laquelle tout petit modèle obtiendrait la même amélioration.

Pourquoi le « partial credit » ne suffit pas

Une alternative naturelle consiste à prendre en compte les actions individuelles correctes et à attribuer un crédit partiel. L'étude indique que l'entraînement « filtered-only » a augmenté la précision des actions d'environ 25 points de pourcentage, mais n'a amélioré la réalisation de la tâche de bout en bout dans aucun des quatre couples modèle-benchmark.

Pour Qwen sur le benchmark « telecom », la précision d'action est passée de 41,4 % à 66,3 % avec le modèle QLoRA « filtered-only », tandis que la précision d'environnement est restée pratiquement inchangée, passant de 23,5 % à 22,6 %. Avec le jeu de données combiné, qui comprenait des trajectoires récupérées, les valeurs correspondantes ont atteint respectivement 83,3 % et 54,5 %. La précision sur la base de données est passée de 9,3 % à 15,6 %.

La traduction opérationnelle est simple : un agent peut sembler actif et appeler correctement de nombreuses API sans pour autant mener la tâche à bien. Si un changement d’adresse, un retour ou une annulation aboutit à un état final erroné, le nombre d’appels corrects aux outils ne sauve pas le workflow. C’est pourquoi la test comportemental des agents IA Il faut des assertions de bout en bout, et pas seulement des métriques partielles.

La qualité du réflecteur détermine la récupération

La récupération n'est pas le fruit d'une répétition aveugle. Sur 82 scénarios ayant échoué dans les secteurs du transport aérien, du commerce de détail et des télécommunications, l'autocritique du GPT-4o a permis de récupérer 20 des 82, soit 24,4 %. Avec GPT-5.1 comme « reflector », 80 des 82 scénarios ont été récupérés, soit 97,6 %, tandis que l'« executor » et les autres conditions sont restés inchangés.

La convergence a été rapide. Sur les 264 récupérations basées sur des fiches de référence (cheatsheets) effectuées lors du test « telecom run », 58,7 % ont abouti dès la première itération et 84,1 % avant la troisième. Les scénarios qui restaient non résolus après les premières itérations étaient rarement résolus par la suite. Un diagnostic correct de la cause vaut mieux que de nombreuses variantes incontrôlées d’une même invite.

Cette étude compare également l'exécution directe à partir d'un modèle plus puissant à la configuration « réflecteur puissant et exécuteur moins coûteux ». Sur les 300 tâches complexes du domaine des télécommunications, le GPT-5.1 doté d'une capacité de raisonnement élevée en a résolues 250, tandis que la combinaison d’un exécuteur GPT-4o et d’un réflecteur GPT-5.1 en a résolu 279 en utilisant le modèle le plus coûteux uniquement pour la réflexion, avec en moyenne 2,2 appels par scénario. Le bénéfice économique dépend des prix, de la longueur des trajectoires et du taux de récupération ; il doit être mesuré, et non supposé.

Cette architecture s'apparente au modèle « acteur, juge et éditeur » : un rôle exécute, un autre contrôle et un autre encore propose des corrections. Cette approche est analysée dans le Acteur, juge, éditeur pour une conception IA contrôlée.

Les « capacités » et la « voix de la marque » peuvent être distinguées l'une de l'autre

Une découverte intéressante pour les équipes produit est que le « reflector » peut améliorer le fonctionnement de l'agent sans lui imposer son propre mode de communication. Dans les tâches de télécommunications appariées de cette étude, le GPT-4o, aidé d’une fiche de référence, a conservé son style concis et par étapes, tandis que l’exécution directe par le modèle le plus puissant a généré des protocoles plus détaillés.

La fiche-guide modifie l'ordre et le choix des actions, mais pas nécessairement le ton de l'exécuteur. Pour une marque, c'est essentiel. L'amélioration de la prise en charge par un agent du service client ne doit pas nécessairement se traduire par des réponses qui se transforment en longs manuels techniques. Le choix de l'exécuteur reste un levier pour le ton, la latence et la conception de l'interaction, tandis que le réflecteur sert de mécanisme de résolution des cas difficiles.

Cette distinction n'élimine pas la nécessité de tests d'expérience utilisateur (UX). Un agent peut mener à bien la tâche, mais demander des confirmations ambiguës, utiliser une terminologie interne ou créer des frictions inutiles. C'est pourquoi l'évaluation doit porter sur les résultats, la sécurité et l'expérience conversationnelle, tout comme lors de la sélection Agent IA pour le service client.

La vérification des raccourcis et des fuites

Le risque majeur est qu'une fiche de référence fournisse à l'enseignant des informations qu'il aurait normalement dû découvrir à l'aide d'outils. Dans ce cas, la trajectoire reconstituée semblerait réussie, mais elle apprendrait à l'élève à utiliser des valeurs « magiques », des informations anticipées ou des raccourcis non autorisés.

Les auteurs ont vérifié les trajectoires récupérées à l'aide de deux évaluateurs indépendants afin de détecter d'éventuelles valeurs codées en dur, des raccourcis et l'utilisation d'informations futures, et ont examiné manuellement les écarts. Cet audit ne constitue pas une garantie absolue pour chaque nouvel ensemble de données. Il indique toutefois l'architecture appropriée : chaque argument d'outil doit pouvoir être attribué à la requête, à un résultat d'outil précédent ou à une valeur par défaut légitime du schéma.

Cette exigence s'applique également après la formation. Les journaux, les résultats des évaluateurs et les décisions relatives aux politiques doivent être accompagnés d'une traçabilité afin que l'équipe sache pourquoi une trace a été jugée acceptable. Ce besoin est lié à la preuve de chaque décision prise par un moteur d'IA et par la gestion des données intégrées dans l'ensemble d'apprentissage.

Qu'est-ce que cela signifie pour les agents IA en production ?

Dans le système de production décrit dans cet article, PROOF-Gen a été appliqué à des milliers de scénarios, avec des trajectoires plus longues et plusieurs évaluateurs. Les auteurs font état d’une augmentation de 6,3 points de pourcentage du taux de réalisation des objectifs en termes de qualité des trajectoires. Dans un modèle déployé sur l'appareil, ils font état d'une augmentation de +1,5 point du taux de réalisation des objectifs, d'améliorations allant de +1,7 à +5,0 points pour les indicateurs de qualité de réponse et d'une amélioration moyenne de +1,48 point pour les langues autres que l'anglais.

Ces chiffres concernent spécifiquement ce site de recherche et de production. Ils ne constituent pas une prévision pour une autre entreprise. L'idée générale est que les journaux d'échecs peuvent constituer une source d'exemples de formation potentiels, à condition qu'il existe des traces complètes, des vérificateurs fiables, une provenance claire et une suppression rigoureuse du « scaffold ».

Dans le domaine du commerce électronique, les cas potentiels sont le changement d'adresse avant l'expédition, le retour partiel, l'annulation avec des politiques d'exceptions, la vérification de la disponibilité ou une combinaison de CRM et de logistique. Le bon critère d'évaluation n'est pas le nombre d'appels API corrects, mais le fait que le système ait atteint l'état opérationnel souhaité sans enfreindre les règles.

La hiérarchisation des défaillances doit également passer par un filtre économique. Tous les cas limites rares ne méritent pas le même budget de reprise. L'équipe doit mettre en relation la fréquence, le coût de l'erreur, le risque réglementaire et la probabilité de récupération, comme dans une analyse approfondie. Retour sur investissement de l'IA grâce aux jetons dans la valeur du travail.

Sept étapes pour un pipeline de reprise contrôlable

L'application ne part pas du réglage fin, mais de l'observabilité et des vérificateurs. Le protocole suivant transpose ce concept aux agents opérationnels sans considérer que chaque défaillance se prête à l'apprentissage.

Le protocole nécessite des restrictions d'accès et des environnements de test sécurisés. Une boucle de récupération qui répète des actions réelles sans isolation peut entraîner la création de commandes en double, des remboursements erronés ou des modifications irréversibles. L'architecture à accès minimal pour de tels systèmes est analysée dans l'article consacré à droits dynamiques des agents IA.

Limites, coûts et gouvernance

L'étude a utilisé un « teacher », le GPT-4o, et des « reflectors » provenant du même fournisseur. Il n'a pas été démontré que la même relation entre la qualité des « reflectors » et la récupération s'applique à toutes les familles de modèles ou à tous les systèmes à poids ouverts. Les « cheatsheets » peuvent être volumineuses ; l'exécuteur a donc besoin d'un contexte suffisant et d'une exécution fiable des instructions.

Les benchmarks présentent également une échelle et une stochasticité spécifiques. Dans le BFCL, les différentes catégories comprennent un nombre limité de tâches de test, tandis que le t2-bench utilise un simulateur d'utilisateur stochastique. C'est pourquoi cet article distingue le résultat global de 93 % de celui de 88 %, qui est directement attribué à la fiche de référence. Chaque groupe a besoin de répétitions et d'intervalles de confiance, et pas seulement d'un pourcentage de récupération.

PROOF-Gen ne fait pas disparaître les coûts. Il ajoute la réflexion, les réexécutions, le calcul du vérificateur, l'audit humain et la gouvernance des ensembles de données. Sa valeur dépend du fait que la récupération de cas complexes soit moins coûteuse et plus utile que davantage de traces simples ou qu’une exécution directe avec un modèle plus puissant à chaque tour.

Enfin, un mauvais vérificateur peut optimiser la mauvaise chose. Si l’objectif ne récompense que la modification de la base et ignore le consensus, la politique ou la qualité de la réponse, la boucle de récupération peut produire des parcours cohérents mais inacceptables. La gouvernance doit relier le contexte, la mesure et la gestion des risques, et non se résumer en fin de compte à une liste de contrôle de conformité. Le même principe se retrouve dans les politiques concrètes en matière de sécurité de l'IA.

L'échec en tant que signal d'entraînement

PROOF-Gen déplace le goulot d'étranglement de la distillation vers les données. Même le meilleur optimiseur ne peut pas apprendre le chemin à suivre au niveau du point de décision critique si l'ensemble d'apprentissage l'a déjà écarté. Il faut d'abord disposer de démonstrations complètes et vérifiées pour les cas que le « teacher » n'a pas résolus dès le premier essai.

Pour les entreprises, le message est concret : un workflow qui échoue contient souvent une grande partie du processus correct et constitue un indicateur précieux de la lacune qui subsiste. Grâce à des vérificateurs fiables, une réflexion puissante, une provenance claire, la suppression du « scaffold » et une évaluation « holdout », cette lacune peut devenir un nouveau signal d'apprentissage.

L'échec ne doit pas être intégré tel quel dans la formation et ne doit pas être idéalisé. Il doit être transformé en une démonstration réussie, reproductible et vérifiable. C’est là toute la différence entre un journal qui se contente d’expliquer ce qui n’a pas fonctionné et un ensemble de données qui rend le prochain agent réellement plus fiable.