Les tests de cohérence des agents d’IBM révèlent pourquoi une seule réussite ne suffit pas
Les tests de cohérence des agents d’IBM ont mis en lumière un contraste marqué entre la réussite sur un benchmark et un comportement fiable. Un agent GPT-4.1 a mené à bien 77,4 % de ses exécutions sur AppWorld, mais n’a réussi l’ensemble de cinq tentatives que pour 53,0 % des tâches.
Cet écart de 24,4 points change la signification d’une démonstration d’agent réussie. Une exécution correcte peut prouver qu’un agent possède la capacité requise. Elle ne peut pas démontrer que les utilisateurs obtiendront le même résultat demain, ni même cinq minutes plus tard.
IBM Research s’attaque à cette distinction avec de nouvelles directives de cohérence dans ALTK-Evolve. Le système repère les décisions instables dans une trajectoire d’agent enregistrée, puis transforme ces faiblesses en instructions réutilisables. Ses premiers résultats suggèrent que les gains de fiabilité ne nécessitent pas toujours un modèle plus grand.
Ces travaux remettent également en question la manière habituelle dont les fournisseurs présentent les performances des agents. Une moyenne de classement peut récompenser un agent qui fonctionne souvent tout en dissimulant la fréquence à laquelle il échoue après avoir déjà réussi.
Les résultats de cohérence d’IBM révèlent la métrique manquante
La conclusion centrale d’IBM est que la précision moyenne et la réussite reproductible décrivent deux produits fondamentalement différents.
Les chercheurs ont testé un agent ReAct alimenté par GPT-4.1 sur 168 tâches issues de la partition test_normal d’AppWorld. ReAct est une architecture d’agent qui alterne étapes de raisonnement et actions, comme l’appel d’une application ou la recherche d’informations stockées.
Chaque tâche a fait l’objet de cinq nouvelles exécutions. Selon l’étude de cohérence d’IBM, l’agent de référence a atteint un score Mean@5 de 77,4 %. Mean@5 calcule la moyenne du taux de réussite sur cinq tentatives.
Ce chiffre semble convenir à une démonstration produit convaincante. Pourtant, l’agent n’a obtenu qu’un score Pass^5 de 53,0 %. Pass^5 ne considère une tâche comme réussie que si les cinq tentatives aboutissent.
La différence entre ces résultats constitue l’écart de cohérence. Ici, il a atteint 24,4 points de pourcentage. Sur le groupe de tâches le plus difficile, IBM indique que l’écart a atteint 30 points.
Cette distinction est importante, car Pass^5 n’est pas la métrique Pass@5, plus courante dans certaines évaluations de programmation. Pass@5 demande si au moins une tentative sur cinq réussit. Pass^5 demande si chaque tentative réussit.
Ces métriques correspondent à des produits différents. Pass@5 convient lorsqu’un système peut générer plusieurs candidats, les tester et conserver le meilleur. Pass^5 correspond aux flux de travail où chaque exécution doit être fiable.
Un développeur demandant à un agent cinq correctifs de code possibles peut tirer parti d’une seule réponse valide. Une équipe comptable demandant à un agent de rapprocher une transaction ne peut pas accepter sans risque quatre exécutions correctes et une erreur dommageable.
Le même problème s’applique à l’analyse des contrats. Un agent qui identifie une obligation lors d’un examen mais l’omet lors d’un autre n’est pas simplement variable. Il produit des décisions commerciales incohérentes à partir de preuves identiques.
Les résultats d’IBM ne montrent pas que GPT-4.1 n’est pas capable d’accomplir ces tâches. Une moyenne de 77,4 % établit qu’il le peut souvent. Ils montrent que cette capacité ne résistait pas de manière fiable à la répétition dans cette configuration d’agent particulière.
C’est le renversement central de l’article. La première réussite est une preuve de possibilité, pas une preuve de fiabilité opérationnelle.
La communauté plus large de l’évaluation est parvenue à une conclusion similaire. Les conseils d’Anthropic sur l’évaluation des agents distinguent Pass@k de Pass^k et recommandent d’adapter la métrique aux exigences du produit.
Anthropic propose une illustration simple. Une tâche présentant un taux de réussite de 75 % par essai n’a qu’environ 42 % de chances de réussir sur trois essais indépendants. La qualité apparente diminue parce que l’exigence passe d’une réussite occasionnelle à une réussite ininterrompue.
Les moyennes conservent leur utilité. Elles permettent de comparer la capacité globale et de voir si une modification améliore les résultats sur un ensemble de tâches. Elles deviennent trompeuses lorsque les acheteurs les interprètent comme une garantie de fiabilité.
Pour les déploiements en entreprise, les deux chiffres ont leur place dans l’évaluation. Mean@k indique aux équipes à quelle fréquence un agent fonctionne. Pass^k indique combien de tâches restent fiables lors d’utilisations répétées.
Pourquoi un agent peut changer de trajectoire à température zéro
Un agent peut devenir incohérent même lorsque le prompt, le modèle, les outils et la température de décodage semblent inchangés.
Un LLM choisit chaque token suivant à partir d’une distribution de probabilités. Certaines décisions ont un favori évident, tandis que d’autres comportent plusieurs options presque à égalité.
IBM les décrit comme des décisions nettes et plates. Une distribution nette concentre l’essentiel de la probabilité sur un seul choix. De faibles changements de calcul ont peu de chances d’en modifier le vainqueur.
Une distribution plate répartit la probabilité entre plusieurs choix plausibles. Un infime décalage numérique peut modifier le token qui arrive en tête et envoyer l’agent sur une trajectoire différente.
Cette différence devient importante dans les systèmes qui utilisent des outils. Un seul token modifié peut changer la sélection d’une API, une requête de recherche, un argument d’outil, une décision de nouvelle tentative ou l’interprétation d’un résultat intermédiaire.
Un chatbot ordinaire peut absorber certaines variations de formulation sans modifier son sens final. Un agent agit à partir de ses choix intermédiaires. Chaque choix modifié change les informations disponibles à l’étape suivante.
Le risque se cumule au fil d’une longue trajectoire. Si un agent prend des dizaines de décisions, plusieurs peuvent se situer près de seuils instables. Une seule doit basculer pour qu’un appel d’outil ultérieur ou la réponse finale échoue.
IBM a exécuté son agent ReAct à une température de 0,0. Les chercheurs soutiennent donc que l’échantillonnage ordinaire n’a pas causé la variabilité observée.
Une température zéro ne rend pas chaque exécution d’un modèle hébergé mathématiquement identique. Le regroupement des requêtes, le comportement du matériel, les opérations en virgule flottante et les détails d’implémentation côté fournisseur peuvent légèrement modifier les probabilités.
Ces variations restent souvent invisibles dans la génération de texte ordinaire. Elles comptent lorsque deux choix sont presque à égalité. Un léger changement peut les réordonner, malgré une demande utilisateur inchangée.
Une graine fixe présente également des limites. Elle contrôle une partie du processus de génération, mais ne fige pas toutes les couches d’un système d’inférence distant. Elle ne rend pas non plus une décision incertaine plus tranchée.
Ce mécanisme explique pourquoi une répétition réussie peut échouer lors d’une démonstration en direct. L’agent n’a pas nécessairement oublié la tâche. Il a emprunté une autre branche du même arbre de décision.
Prenons un agent chargé de compter les activités terminées dans une note. Lors d’une exécution, il peut compter chaque marqueur de case à cocher. Lors d’une autre, il peut également compter une légende expliquant le format de la case à cocher.
Les deux trajectoires peuvent initialement sembler raisonnables. Une seule produit le total attendu. L’erreur vient d’une décision non résolue sur la manière d’interpréter le document, et non d’un manque d’accès à la note.
Les flux de travail plus longs amplifient ce comportement. Un agent de recherche peut choisir une autre source, mal interpréter une date ambiguë ou s’arrêter après le premier document correspondant. Chaque choix façonne tout ce qui suit.
Cela fait de la fiabilité des agents IA en partie un problème d’orchestration. Un meilleur modèle de base peut augmenter les chances de prendre de bonnes décisions, mais il ne garantit pas la disparition de ses choix limites.
Les conditions externes ajoutent une autre couche. ReliabilityBench évalue les exécutions répétées en parallèle de requêtes paraphrasées et de défaillances d’outils. Son cadre de stress en production traite la cohérence, la robustesse et la tolérance aux pannes comme des dimensions distinctes.
L’expérience actuelle d’IBM isole plus étroitement les exécutions répétées. Cette focalisation facilite l’examen de l’écart de cohérence, mais elle ne représente pas toutes les défaillances de production auxquelles un agent sera confronté.
Les déploiements réels doivent composer avec des données modifiées, des identifiants expirés, des limites de débit d’API, des réponses partielles et des schémas évolutifs. Un comportement stable face à une entrée identique constitue donc une exigence de départ, et non l’intégralité de la norme de fiabilité.
ALTK-Evolve transforme l’incertitude en directives ciblées
ALTK-Evolve cherche à corriger les décisions instables sans rejouer chaque tâche dans un environnement actif.
Le nouveau processus commence par une trajectoire enregistrée. Une trajectoire est l’enregistrement ordonné des prompts, décisions, appels d’outils, observations et réponses produits lors d’une exécution d’agent.
L’outil Consistency Analyzer d’IBM réexamine chaque point de décision à l’aide du contexte déjà stocké dans cette trace. Il demande plusieurs complétions alternatives et mesure dans quelle mesure le choix du modèle varie.
La configuration par défaut génère cinq complétions au moyen d’un appel de modèle supplémentaire par étape de décision. Elle ne répète ni les appels d’outils externes ni l’exécution complète de la tâche.
Cette conception est importante en production. Une réexécution complète pourrait envoyer un autre e-mail, modifier deux fois un enregistrement, dupliquer un achat ou rencontrer des données ayant déjà changé.
Le rééchantillonnage hors ligne évite ces effets secondaires. Il supprime également le besoin d’une étiquette de vérité terrain durant l’étape de diagnostic.
L’analyseur fonctionne en boîte noire, ce qui signifie qu’il ne nécessite ni logits du modèle ni accès interne. Les équipes peuvent l’appliquer à un modèle hébergé si elles possèdent la trace d’origine et peuvent soumettre à nouveau ses contextes de décision.
Chaque décision reçoit un score de cohérence. Les étapes dont les complétions divergent deviennent candidates à l’ajout de directives.
ALTK-Evolve transforme ensuite ces candidats en instructions comportementales concises. Son objectif plus large consiste à extraire des leçons utiles de trajectoires antérieures et à les récupérer lors de tâches ultérieures.
Pour l’exemple de comptage dans une note, les directives générées recommandaient une expression régulière ancrée sur les lignes plutôt qu’un simple comptage de sous-chaînes. Elles demandaient également à l’agent d’examiner plusieurs résultats de recherche avant de sélectionner une note.
Ces instructions s’attaquent à des schémas de défaillance généraux. Elles ne se contentent pas d’enregistrer la bonne réponse numérique de la tâche initiale.
Cette différence est essentielle. Mémoriser une réponse améliorerait un élément de benchmark sans renforcer l’agent. Une règle réutilisable peut aider avec de nouvelles notes, d’autres formats de cases à cocher ou des décisions de recherche connexes.
Le dépôt ALTK-Evolve inclut désormais Consistency Analyzer et les composants de génération de directives. Le projet utilise une licence Apache 2.0 et prend en charge l’intégration via le Model Context Protocol.
Sa couche de récupération introduit des directives pertinentes dans le contexte de l’agent au moment de l’inférence. Elle fournit ainsi au modèle des rappels ciblés sans exiger que chaque trace historique reste dans le prompt actif.
L’approche ressemble à une forme ciblée de mémoire opérationnelle. Au lieu de demander à l’agent de relire tout ce qu’il a fait, le système distille les leçons récurrentes et récupère celles associées à la tâche en cours.
Cette distinction importe également pour le travail de connaissance. Une archive plus grande ne produit pas automatiquement de meilleures décisions. Une mémoire utile nécessite une sélection, une gestion des conflits et un contexte adapté à la demande active.
Le même principe sous-tend une base de connaissances IA bien structurée. Le contenu stocké devient précieux lorsqu’un système peut récupérer les bonnes preuves sans submerger le contexte de travail.
La méthode d’ALTK-Evolve est plus restreinte qu’une plateforme générale de connaissances. Elle cible le comportement des agents et utilise des directives dérivées de trajectoires. Néanmoins, les deux cas révèlent la même contrainte : conserver l’information est plus facile que d’appliquer la bonne information au bon moment.
Le mécanisme crée également une boucle de rétroaction. Les équipes peuvent collecter des traces, détecter les étapes instables, générer des recommandations candidates et évaluer si ces recommandations améliorent les exécutions ultérieures.
Cependant, le système n’élimine pas le besoin de tests. Une règle générée peut être erronée, trop générale ou nuisible en dehors de la situation qui l’a produite.
Les équipes ont toujours besoin de gestion des versions et de mécanismes de retour en arrière. Elles doivent également suivre quelle directive a influencé une décision, en particulier lorsqu’un agent effectue un travail réglementé ou aux conséquences financières importantes.
Le gain de fiabilité est important, mais les preuves restent limitées
IBM fait état d’une amélioration substantielle, bien que l’étude demeure une évaluation précoce sur une configuration de référence principale.
Après l’ajout de directives de cohérence, le Pass^5 est passé de 53,0 % à 69,0 % sur les 168 tâches AppWorld. Cela représente une amélioration de 16 points du nombre de tâches réussies lors des cinq exécutions.
Le Mean@5 a également progressé, de 77,4 % à 81,0 %. L’écart de cohérence s’est donc réduit de 24,4 points à 12,0 points.
Ce résultat est important, car la moyenne n’a pas diminué. Une méthode qui améliorerait la répétabilité en enfermant l’agent dans une stratégie systématiquement médiocre ne résoudrait pas le problème sous-jacent.
IBM affirme que les directives ont maintenu ou amélioré le Mean@5 à tous les niveaux de difficulté. Le groupe intermédiaire a gagné 22,9 points en Pass^5, tandis que le groupe difficile en a gagné 14,3.
Les gains relatifs ont été de 44 % pour les tâches intermédiaires et de 45 % pour les tâches difficiles. Les tâches faciles ont gagné 12,2 points, avec moins de marge d’amélioration.
IBM a également testé les directives sur une tâche différente mais liée, au sein du même scénario AppWorld. Le Pass^5 a augmenté de 13 points, contre un gain de 16 points pour la même tâche.
Ce résultat étaye l’affirmation selon laquelle certaines directives se transfèrent au-delà d’une trajectoire enregistrée. Il n’établit pas une généralisation large à des applications, secteurs ou architectures d’agents sans lien entre eux.
Une deuxième expérience a utilisé gpt-oss-120b. Son Pass^5 sur la même tâche est passé de 10,1 % à 16,1 %, tandis que les performances sur des tâches similaires ont gagné 8,7 points.
Ce niveau de référence plus faible montre que les directives ne peuvent pas remplacer entièrement les capacités. Une amélioration de six points est significative, mais un taux de réussite sur toutes les exécutions de 16,1 % reste inadapté à une automatisation aux conséquences importantes.
Le rapport technique complet présente la méthodologie à l’origine de ces affirmations. Malgré cela, les lecteurs devraient considérer ces résultats comme des éléments issus de l’évaluation des auteurs, et non comme une confirmation indépendante sur des systèmes de production.
Le test principal utilise une configuration ReAct, une répartition principale du benchmark et cinq répétitions par tâche. AppWorld propose des scénarios réalistes couvrant plusieurs applications, mais un benchmark reste un environnement contrôlé.
Cinq exécutions révèlent une instabilité qu’une seule exécution masque. Elles n’estiment pas précisément les défaillances rares susceptibles d’apparaître au fil de milliers d’interactions avec des clients.
L’évaluation soulève aussi une question statistique. Le Pass^k diminue naturellement à mesure que k augmente, car chaque essai supplémentaire crée une nouvelle possibilité d’échec.
Une équipe produit doit donc choisir k en fonction de l’exposition réelle. Cinq exécutions réussies peuvent constituer un filtre de développement raisonnable. Elles ne prouvent pas la fiabilité à l’échelle de l’entreprise.
Les directives peuvent également devenir obsolètes. Les API évoluent, les politiques changent et les solutions de contournement antérieures peuvent entrer en conflit avec le nouveau comportement du système.
Une règle dérivée d’une branche instable peut supprimer une alternative valide ailleurs. Plus un système accumule de directives, plus la résolution des conflits et la qualité de récupération deviennent importantes.
Il existe aussi une différence entre un comportement cohérent et un comportement correct. Un agent qui répète la même action erronée présente une stabilité comportementale parfaite et une valeur de tâche nulle.
L’expérience d’IBM se prémunit contre ce problème en rapportant le Mean@5 parallèlement au Pass^5. Les équipes de production devraient préserver ce même couplage et ajouter des mesures de sécurité spécifiques aux résultats.
Pour les flux de travail sensibles, l’objectif doit être une exactitude cohérente. La stabilité seule ne devrait jamais se substituer à l’exactitude factuelle, à la conformité aux politiques, aux vérifications d’autorisation ou à la supervision humaine.
Les modèles plus grands font désormais face à un concurrent au niveau des systèmes
Les nouvelles données remettent en question l’hypothèse selon laquelle les problèmes de fiabilité doivent d’abord être résolus en remplaçant le modèle sous-jacent.
Les mises à niveau de modèles restent attrayantes, car elles peuvent améliorer de nombreuses tâches à la fois. Elles exigent également moins de diagnostic sur mesure que la reconstruction de la mémoire ou du système d’évaluation d’un agent.
Pourtant, un modèle plus grand ne révèle pas où un agent existant devient instable. Il peut améliorer les performances moyennes tout en laissant subsister un écart significatif entre une réussite occasionnelle et une réussite répétée.
L’approche d’IBM représente une voie concurrente. Au lieu de modifier le modèle, elle modifie les informations fournies aux points de décision à haut risque.
La comparaison n’oppose pas strictement le modèle à la mémoire. Les systèmes robustes utiliseront conjointement des modèles performants, des outils bien conçus, un contexte ciblé, des contrôles déterministes et des évaluations répétées.
La pression s’exerce sur les fournisseurs d’agents et les acheteurs en entreprise qui ne communiquent encore qu’un seul taux de réussite. Une fois que le Pass^k entre dans les discussions d’achat, une moyenne élevée ne constitue plus qu’une partie des preuves.
Les acheteurs peuvent demander si la même tâche a été répétée, si l’environnement a été réinitialisé et si chaque exécution a atteint un résultat acceptable. Ils peuvent également exiger des résultats par niveau de difficulté plutôt qu’un seul chiffre agrégé.
Les développeurs font face à un changement similaire. Un rapport de bug indiquant qu’un agent a échoué une fois peut ne plus être reproductible à la demande. Les équipes ont besoin de traces complètes pour localiser la décision antérieure qui a divergé.
L’observabilité devient une composante de la qualité du produit. Sans prompts stockés, arguments d’outils, résultats et choix intermédiaires, une exécution instable peut disparaître sans s’expliquer.
Cela rend l’architecture d’évaluation importante avant le déploiement. Les équipes ont besoin de tâches représentatives, d’états de départ contrôlés, de critères de réussite explicites et d’un nombre suffisant de répétitions pour révéler la variance.
Elles doivent également distinguer les tâches réessayables des actions à exécution unique. La génération d’un brouillon peut tolérer plusieurs tentatives. L’envoi d’un paiement, la suppression d’un fichier ou l’approbation d’un contrat exigent des contrôles plus stricts.
Le Pass@k convient au premier groupe lorsque les résultats peuvent être vérifiés automatiquement. Le Pass^k est plus informatif pour le second, en particulier lorsque les utilisateurs attendent que le premier résultat soit sûr.
Certains flux de travail ne devraient dépendre d’aucune de ces métriques seules. Un agent transactionnel a également besoin de limites d’autorisation, de contrôles d’idempotence, de journaux d’audit et d’une validation déterministe avant d’exécuter une action irréversible.
Les directives peuvent réduire le raisonnement incertain, mais elles ne remplacent pas ces garanties. La fiabilité d’un agent est une propriété du système, pas un score de modèle.
Les résultats renforcent également l’argument en faveur d’un contexte de travail soigneusement sélectionné. Les équipes utilisent déjà le knowledge blending pour relier les éléments stockés au travail en cours. Les directives pour agents appliquent une idée similaire aux enseignements comportementaux.
La retenue est essentielle. Davantage de contexte récupéré peut créer de la distraction, des contradictions et une latence accrue. Une instruction ciblée n’a de valeur que si elle atteint la bonne tâche et ne déplace pas des éléments essentiels.
C’est là que réside le défi à long terme d’ALTK-Evolve. Son diagnostic peut identifier des décisions variables, mais le système environnant doit gérer une collection croissante d’enseignements.
Un déploiement réussi nécessitera des politiques d’expiration, la détection des conflits, la traçabilité et des évaluations des modifications de directives. Sans cela, la solution d’hier peut devenir la source cachée de défaillances de demain.
Ce qui montrera si l’approche d’IBM tient dans la durée
Trois signaux détermineront si les directives de cohérence deviennent une couche standard pour les agents ou restent une technique de benchmark prometteuse.
Le premier signal sera une reproduction indépendante sur d’autres benchmarks et architectures d’agents. Les chercheurs devraient tester la méthode sur des agents de navigation web, des agents de programmation, des systèmes de service client et des flux de travail confrontés à de véritables défaillances d’API.
Une répétition de l’amélioration de 16 points du Pass^5 renforcerait l’affirmation centrale d’IBM. Des gains plus faibles ou incohérents suggéreraient qu’AppWorld contient des schémas d’échec particulièrement adaptés à la correction par directives.
Les comparaisons devraient inclure plusieurs modèles de base. Elles devraient également rapporter l’utilisation de tokens, la latence, le coût de l’analyseur, la surcharge de récupération et le nombre de directives injectées par tâche.
Le deuxième signal sera la performance sur des périodes plus longues. Un système d’apprentissage utile doit intégrer de nouvelles directives sans accumuler de règles contradictoires ou obsolètes.
Les équipes devraient mesurer si le bénéfice perdure après des centaines ou des milliers de trajectoires. Elles devraient également tester si la récupération des directives reste précise à mesure que le magasin s’agrandit.
Il faudra surveiller les évaluations qui figent un ensemble de directives et le testent face à des versions ultérieures d’applications. De bonnes performances montreraient que les règles saisissent des comportements durables. Une dégradation rapide révélerait une charge de maintenance.
Le troisième signal sera l’adoption de rapports fondés sur des exécutions répétées. Les tableaux de bord des fournisseurs devraient publier conjointement Mean@k et Pass^k, en indiquant clairement k.
Cette évolution permettrait aux acheteurs de distinguer les modèles qui réussissent fréquemment des systèmes qui réussissent de manière fiable. Elle découragerait aussi les démonstrations fondées sur une seule exécution favorable.
Le secteur devrait aller plus loin en combinant la répétition avec des paraphrases et des défaillances d’outils contrôlées. Des prompts identiques ne représentent qu’un type de pression en production.
Le travail d’IBM établit de manière convaincante qu’une exécution réussie est une norme trop faible. Il offre également une méthode pratique pour localiser l’incertitude sans répéter chaque action réelle.
La question restante est de savoir si ces gains persistent en dehors de la configuration de recherche. Les développeurs peuvent y répondre en réexécutant leurs propres flux de travail importants, en préservant des traces complètes et en mesurant le succès sur toutes les exécutions.
Si votre agent gère un travail aux conséquences importantes, ne demandez pas seulement s’il a accompli la tâche. Demandez à quelle fréquence il accomplit correctement la même tâche, quelles décisions varient et ce qui se produit lorsque les directives d’hier rencontrent les conditions de demain.
