Test d’un mécanisme de contrôle qui permet de réessayer l’action finale erronée d’un agent.

La fonctionnalité Claude Outcomes d’Anthropic propose un mécanisme que de nombreuses équipes mettent en place elles-mêmes : un agent rédige une réponse, un deuxième composant l’évalue selon des critères prédéfinis, et en cas d’erreur, l’agent a droit à une nouvelle tentative. L’idée de base est suffisamment simple pour être testée sans le produit géré, c’est pourquoi une version simplifiée a été recréée dans un environnement contrôlé, avec la sortie de l’agent, un juge basé sur des critères et une seule tentative possible.

La question

Le test pose une seule question : lorsque un agent doit prendre une décision structurée, un mécanisme de tentative répétée contrôlé par des critères réduit-il le nombre d’actions finales erronées ?

Les actions finales sont cruciales ici, car de nombreux échecs des agents réels n’ont rien à voir avec la qualité du texte. Une réponse peut sembler bonne, le JSON peut être interprété, mais l’action choisie peut néanmoins être erronée. Cela se traduit par une erreur opérationnelle dans le flux de travail de support. Par exemple, si un agent renvoie DENY alors que NO_ACTION aurait été la bonne solution, les justifications prudemment formulées ne suffisent pas à corriger la situation.

La configuration

Trente cas de support synthétiques et un modèle, gpt-5.4-mini, ont été utilisés pour cette expérience. Un tel échantillon ne peut pas servir de référence fiable. La valeur réside dans la manière dont les échecs se sont manifestés : quels ont été corrigés par le système, lesquels ont été manqués et où apparaissent les coûts liés à ces schémas.

Chaque cas comprend un bref scénario client, une politique ainsi qu’une liste fermée des actions finales autorisées :

APPROVE
DENY
ASK_CLARIFYING_QUESTION
ESCALATE
NO_ACTION

Deux boucles ont été mises en concurrence. Dans la version de base, le cas est transmis directement à l’agent et toute action qui revient est enregistrée. Dans la version avec contrôle, un juge évalue la première réponse ; en cas d’échec, l’agent est renvoyé pour une nouvelle tentative, cette fois en tenant compte des critères qu’il a manqués.

Le diagramme ci-dessous constitue une référence concise pour les flux de travail d’agents contrôlés par des critères de résultat. Il montre comment des filtres basés sur des critères évaluent une action proposée par rapport à un contrat de politique avant que toute décision finale ne soit acceptée.

Le contrat a été conçu de manière stricte, avec un ensemble d’actions fermé, des contraintes de politique explicites et une seule tentative de réessai en cas d’échec du contrôle basé sur des critères.

Baseline:
case -> agent -> final action

Gated:
case -> agent -> rubric judge
if failed -> retry once
retry answer -> final action

Les cas étaient synthétiques, mais conçus en tenant compte des contraintes typiques de la production :

Un fournisseur réel de LLM a été utilisé et non un simulateur déterministe, car l’aspect intéressant réside dans le comportement réel d’un modèle une fois que sa première réponse a été évaluée et modifiée.

Un juge qui ne possède pas la clé des réponses

Un juge qui connaîtrait déjà la réponse annulerait tout l’intérêt de l’exercice. Chaque cas comprend une expected_action, mais cette valeur n’est utilisée que pour calculer des métriques hors ligne après l’exécution, et le juge ne l’obtient jamais. Ce que voit le juge, c’est l’action choisie par l’agent, et il vérifie cette action par rapport aux contraintes de la politique définie.

Imaginez une demande de remboursement pour laquelle un recours en chargeback est en cours dans le flux de travail des paiements. NO_ACTION pourrait être la solution appropriée, car c’est le service des paiements qui est chargé de sa résolution et le support ne devrait pas se prononcer à ce sujet. Un juge peu rigoureux se contenterait de vérifier si le modèle a choisi NO_ACTION. Cela revient à une vérification contre une clé de réponse. Cette approche convient aux évaluations hors ligne, mais n’est pas une étape de contrôle selon des critères prédéfinis.

Une véritable étape de contrôle pose une question différente : étant donné DENY, l’agent a-t-il erronément attribué au support le rôle de décideur alors qu’un autre flux de travail est chargé de l’affaire ?

Lors de l’exécution, une clé de réponse cachée n’est généralement pas ce qui est souhaité. Ce qui est recherché, c’est une vérification pour savoir si l’action proposée viole un contrat clairement défini. Ici, le contrat était simple : choisir une action finale et ne pas en sélectionner une qui entre en conflit avec les contraintes définies par la politique de l’affaire.

Que s’est-il passé

Lors d’une seule analyse des 30 cas, l’agent de référence a commis 6 erreurs dans les actions finales. Une fois l’intervention du juge et une tentative supplémentaire ajoutées, seules 2 erreurs sont restées.

L’amélioration est réelle, mais les chiffres seuls sont trompeurs. La boucle n’a pas conféré à l’agent de nouvelles compétences générales ; elle a fonctionné uniquement dans les cas où le juge pouvait identifier un conflit spécifique entre l’action choisie et les règles définies, comme le montrent les exemples d’échec.

Ce que la correction a résolu

La boucle a corrigé 4 des 6 erreurs de l’agent de référence. La plupart des corrections ont concerné des cas où cet agent était trop rapide pour refuser. La politique en vigueur ne prévoyait pas d’approbation immédiate, mais elle n’exigeait pas non plus de refus. La meilleure solution était de demander des précisions ou d’attendre un autre processus.

Une demande a été reçue pour modifier l’adresse e-mail d’un compte. Elle provenait d’un nouvel appareil, la vérification en deux étapes n’avait pas été effectuée, et le demandeur connaissait bien le code postal de facturation. La politique exigeait que la vérification en deux étapes soit terminée ou qu’une autre méthode de vérification approuvée soit utilisée avant que le service client ne puisse intervenir. La réponse de base était DENY, bien que l’on s’attendît à ASK_CLARIFYING_QUESTION. Il était prématuré de rejeter la demande alors qu’une méthode de vérification approuvée restait possible ; poser une question était donc la démarche appropriée. Le juge a rejeté ce refus en le jugeant trop hâtif, et lors de la nouvelle tentative, le modèle a choisi ASK_CLARIFYING_QUESTION.

Un autre cas réparé concernait un appareil de remplacement. Un client a demandé au service client de lui en envoyer un nouveau, mais une demande RMA avait déjà été créée ce matin et attendait un scan dans l’entrepôt. La décision de base a indiqué DENY et l’action attendue était NO_ACTION. Ce refus décrivait mal la situation, car le client remplissait bien les conditions. Le processus de remplacement était déjà en cours, et le service client n’aurait pas dû ouvrir une demande RMA supplémentaire. La tentative de correction a finalement abouti à NO_ACTION.

Ces deux exemples montrent la valeur pratique de ce modèle. Ce mécanisme n’a pas rendu le système globalement plus intelligent ; il a simplement forcé la correction d’une incohérence spécifique entre l’action choisie et les règles définies.

Ce qu’il ne pouvait pas corriger

Les deux échecs restants en disent plus que le score global. Il s’agissait dans les deux cas de processus existants où l’action attendue était NO_ACTION, et la réponse finale est restée DENY même après la tentative de réessai.

Dans le premier cas, une demande de remboursement était associée à un recours en chargeback en cours dans le flux de paiement. La politique interdisait au service client de procéder au remboursement tant qu’un recours en chargeback était actif, car c’était le service des paiements qui était chargé de sa résolution. Dans le second cas, un acheteur souhaitait une autorisation d’expédition manuelle alors qu’une vérification de fraude était en cours, et la politique interdisait également au service client d’autoriser l’expédition dans cet état. Dans les deux cas, le système a détecté le problème et a retourné des critères d’échec, et le réessai a malgré tout conservé l’action incorrecte.

Cela modifie la manière dont le schéma doit être évalué pour une utilisation en production. Un mécanisme de contrôle peut détecter qu’une action viole une règle, mais la simple détection ne suffit pas à corriger le problème. Supposons que le modèle ne puisse pas distinguer « refuser la demande » de « s’abstenir car un autre flux de travail en décide ». Dans ce cas, même une réponse marquée comme problématique peut rester inchangée. Le fait d’afficher un aspect sûr ne rend pas une action correcte, et DENY semble prudent, mais reste erroné lorsque l’agent n’a pas d’autorité sur le cas.

Où lui faire confiance

Le succès dans ce cas reposait sur un résultat vérifiable. L’agent choisissait parmi un ensemble fermé, les limites de la politique étaient clairement définies et le juge pouvait comparer l’action choisie à une règle concrète. Les tentatives répétées conditionnées par le résultat gagnent en crédibilité dans de telles situations :

Une plus grande prudence s’impose lorsque le résultat est subjectif :

Il ne faut pas le considérer comme une couche de fiabilité générale. Réservez-le aux cas où une action erronée coûte suffisamment cher pour justifier un appel supplémentaire au modèle, et où le résultat souhaité peut être intégré dans un contrat.

Changements pertinents en environnement de production

Un ajustement est plus important que les autres : interprétez les erreurs répétées non corrigées comme un retour d’information sur la conception. Lorsque l’agent continue de confondre DENY et NO_ACTION, affinez les définitions des actions, ajoutez des exemples ou révisez le contrat de flux de travail. Une nouvelle tentative ne résout que rarement un manque de compréhension.

Il convient également de séparer le contrôle en temps réel de l’évaluation hors ligne. En temps réel, le juge applique les contraintes, tandis que l’évaluation hors ligne compare les actions finales aux attentes étiquetées. Les fusionner fausse l’image du système. Il est également utile de consigner chaque tentative, en indiquant l’action initiale, les critères non respectés, l’action révisée et le verdict final, car la combinaison de corrections et de non-corrections en dit souvent plus que la précision globale.

Le point clé

Les mécanismes de contrôle basés sur les résultats sont efficaces lorsque l’état « terminé » peut être défini comme un contrat. Ici, le contrat était simple : choisir une action finale qui ne viole pas les contraintes de la politique. Dans ces conditions, le boucle de contrôle a réduit de 6 à 2 le nombre d’actions finales incorrectes parmi 30.

Ces échecs résiduels sont ceux qui nécessitent l’attention en environnement de production. Le juge a détecté le problème, mais la tentative de réessai a malgré tout produit l’action incorrecte. Ainsi, la question en suspens n’est pas seulement de savoir si un système peut évaluer les résultats, mais aussi si tout le cycle est capable de transformer cette évaluation en la décision adéquate. C’est là la preuve à demander avant que tout cycle conditionné par un résultat ne touche un flux de travail en temps réel.

Lectures complémentaires

La documentation API d’Anthropic sur la définition des résultats ainsi que son guide sur les agents qui vérifient leur propre travail couvrent la fonctionnalité gérée que cet experiment reflète.