Pass^k : mesurer la cohérence des agents IA en production

Un agent qui réussit une tâche une fois n'est pas un agent fiable. IBM Research a publié le 15 septembre 2026, sur le blog de Hugging Face, une étude qui met un chiffre sur ce que toute équipe qui exploite des agents IA constate : un agent ReAct basé sur GPT-4.1 réussit 77,4 % des exécutions sur le benchmark AppWorld, mais ne réussit les cinq répétitions d'une même tâche que dans 53,0 % des cas. Vingt-quatre points d'écart entre la performance moyenne et la performance garantie. Avec elle, IBM livre un outil open source, ALTK-Evolve, qui réduit cet écart de moitié sans changer de modèle.

Pour une équipe MLOps, le sujet n'est pas académique : c'est la différence entre un agent que l'on peut mettre devant des utilisateurs et un agent qui marche « en démo ». Cet article explique la métrique Pass^k, la méthode de diagnostic d'IBM et ce que cela change dans la façon d'évaluer un agent IA avant la mise en production.

Le contexte

Un agent IA enchaîne des décisions : quel outil appeler, avec quels arguments, quand s'arrêter. Chaque décision est un tirage dans une distribution de probabilité sur les tokens. Même à température 0, cette distribution n'est pas toujours tranchée : quand deux choix sont à égalité ou presque, une perturbation minime côté plateforme (lot d'inférence, arithmétique flottante, version du serveur) suffit à faire basculer la décision. Sur une tâche de vingt étapes, il suffit d'une bascule pour changer le résultat.

Les tableaux de classement masquent ce phénomène parce qu'ils publient une moyenne. La moyenne dit combien de fois l'agent réussit ; elle ne dit pas s'il réussit la même tâche à chaque fois. Or c'est la seconde question que se pose un responsable d'exploitation.

Trois métriques, une seule qui compte en production

IBM formalise la distinction avec trois mesures, calculées sur k exécutions indépendantes de chaque tâche :

• Mean@k : le taux de réussite moyen sur les k exécutions. C'est la métrique des classements.
• Pass@k : la tâche compte comme réussie si au moins une exécution sur k réussit. C'est une mesure optimiste, celle d'un scénario où l'on peut réessayer.
• Pass^k : la tâche compte comme réussie seulement si toutes les k exécutions réussissent. C'est la mesure pessimiste, celle d'un utilisateur qui n'a pas de seconde chance.

L'ordre est toujours le même : Pass^k ≤ Mean@k ≤ Pass@k. L'auteur appelle écart de cohérence la différence entre Mean@k et Pass^k. Sur AppWorld (168 tâches du jeu test_normal, cinq exécutions par tâche), l'agent GPT-4.1 affiche Mean@5 = 77,4 % et Pass^5 = 53,0 % : un écart de 24,4 points.

Pourquoi ce n'est pas Pass@k

Pass@k est utile pour mesurer la capacité d'un modèle quand on peut échantillonner plusieurs réponses et garder la meilleure, par exemple en génération de code avec des tests. Un agent en production n'a pas ce luxe : il exécute une fois, avec des effets de bord (un e-mail envoyé, une commande passée). Pass^k est la métrique qui correspond à cette réalité.

La méthode d'IBM : diagnostiquer sans vérité terrain

ALTK-Evolve est un système open source qui transforme les trajectoires passées d'un agent en consignes réutilisables, distillées automatiquement et réinjectées au moment de l'inférence. La nouveauté du 15 septembre est un type de consigne dédié à la cohérence, produit en deux temps.

1. L'analyseur de cohérence

À partir d'une seule trajectoire enregistrée, l'analyseur rejoue chaque étape de décision par un rééchantillonnage contrôlé : un appel de modèle supplémentaire par étape, qui tire k complétions (cinq par défaut) et regarde si elles convergent. Une étape dont les complétions divergent est une décision instable. Le point important pour une équipe d'exploitation : cette détection ne demande ni vérité terrain, ni rejeu de la tâche complète, ni évaluateur. Elle s'applique à des traces de production.

2. La génération de consignes

Les décisions instables détectées deviennent des consignes en langage naturel, au format du pipeline de récupération existant d'ALTK-Evolve, et sont injectées dans le contexte de l'agent lors des exécutions suivantes. L'agent apprend en quelque sorte à trancher là où il hésitait.

Les résultats chiffrés

Sur AppWorld, avec l'agent ReAct GPT-4.1 et cinq exécutions par tâche :

• Pass^5 passe de 53,0 % à 69,0 % ;
• Mean@5 passe de 77,4 % à 81,0 % : la moyenne ne se dégrade pas, elle progresse ;
• l'écart de cohérence se réduit de 24,4 à 12,0 points ;
• les tâches de difficulté moyenne gagnent 22,9 points de Pass^5 (+44 % en relatif), les tâches difficiles 14,3 points (+45 %) ;
• les consignes se transfèrent à des tâches similaires non vues : +13,0 points.

Sur un modèle plus faible, gpt-oss-120b, le gain existe mais reste modeste : Pass^5 passe de 10,1 % à 16,1 % sur les mêmes tâches (+6,0 points), +8,7 points sur des tâches similaires. IBM en tire une conclusion nette : la cohérence est orthogonale à la capacité. Un modèle plus gros ne règle pas le problème, et un modèle petit ne peut pas être « rendu cohérent » au-delà de ce qu'il sait faire.

Ce que ça change pour les équipes IA

Changer la métrique de recette. Un agent ne devrait pas passer en production sur un Mean@1 mesuré une fois. La recette doit exécuter chaque scénario k fois (cinq est un bon départ) et publier Pass^k à côté de Mean@k. Dans les mises en production d'agents que nous menons, c'est exactement le rôle du jeu d'évaluation : des scénarios rejoués, un seuil de Pass^k par criticité, et un rapport qui montre l'écart de cohérence avant et après chaque changement de prompt ou de modèle.

Attendre un écart qui grandit avec la difficulté. Les chiffres d'IBM montrent que l'écart se creuse sur les tâches moyennes et difficiles. Un agent qui semble fiable sur des cas simples peut être imprévisible sur les cas qui justifient son existence. Les scénarios de recette doivent donc couvrir les enchaînements longs, pas seulement les questions simples.

Diagnostiquer sur les traces de production. L'analyseur de cohérence fonctionne sur une trajectoire enregistrée, sans évaluateur. Branché sur l'observabilité existante (traces d'appels, arguments d'outils), il permet de repérer les décisions instables à partir du trafic réel, puis de les traiter par des consignes plutôt que par un changement de modèle. C'est une boucle d'amélioration à coût d'inférence marginal : un appel supplémentaire par étape analysée, hors ligne.

Ne pas commencer par un modèle plus gros. La recommandation d'IBM est explicite. Avant d'augmenter la facture d'inférence, il faut mesurer l'écart de cohérence, identifier les décisions instables et les encadrer. C'est moins cher, et souvent plus efficace, qu'un changement de modèle qui déplace le problème sans le résoudre.

Garder la moyenne sous surveillance. Toute intervention sur la cohérence doit respecter une contrainte : la précision moyenne ne doit pas baisser, à aucun niveau de difficulté. IBM la présente comme une contrainte dure de sa méthode. Une consigne qui force un choix peut aussi forcer une erreur ; le jeu d'évaluation doit le détecter.

Limites à garder en tête : l'étude porte sur un seul benchmark (AppWorld) et deux modèles ; les gains sur le modèle faible sont limités ; et la question du comportement à des valeurs de k plus élevées n'est pas traitée. Pass^5 n'est pas Pass^50.

En bref

• Sur AppWorld, un agent GPT-4.1 réussit 77,4 % des exécutions mais seulement 53,0 % des tâches à chaque fois : 24,4 points d'écart de cohérence.
• Pass^k (réussite sur toutes les exécutions) est la métrique qui correspond à un agent en production ; Pass@k est une mesure optimiste de réessai.
• ALTK-Evolve détecte les décisions instables par rééchantillonnage d'une trajectoire enregistrée, sans vérité terrain, et les transforme en consignes injectées à l'inférence.
• Résultat : Pass^5 de 53,0 % à 69,0 %, Mean@5 de 77,4 % à 81,0 %, écart réduit à 12,0 points ; gains modestes sur un modèle plus faible.
• Recommandations : publier Pass^k, attendre un écart plus grand sur les tâches difficiles, diagnostiquer avant de changer de modèle.

Vous industrialisez vos agents IA ? SeedVision propose des audits IA en 3-5 jours et des forfaits de mise en production de 15 à 30 jours. Voir les packages ou réserver un appel de 30 min.

Sources : Your Agent Aced the Task. Will It Do It Again? (IBM Research sur le blog Hugging Face, 15 septembre 2026), le dépôt ALTK-Evolve et le rapport technique sur arXiv.

Photo de couverture : Photo by Vishnu Mohanan on Unsplash.