ReplayRCA : corriger à la dernière étape fait perdre 17,1 points de correction causale à un modèle puissant

Lorsqu'un agent fondé sur un modèle de langage échoue sur une tâche à plusieurs étapes, on confie de plus en plus souvent l'analyse des causes à un autre modèle. Les auteurs du benchmark ReplayRCA proposent de valider un tel diagnostic non pas en le comparant à une annotation humaine, mais par ses conséquences. L'environnement est ramené à son état précédant l'étape choisie, l'action de l'agent est remplacée par celle que propose le diagnostiqueur, puis le même agent poursuit de façon autonome.

La métrique principale est la correction causale : la part de poursuites réussies après la correction, moins la part de poursuites réussies dans un rejeu de contrôle où l'action initiale de l'agent est reproduite (placebo apparié). C'est aussi en points de cette métrique que se mesure le résultat principal : si l'on force un modèle puissant à n'intervenir qu'à la dernière étape, il perd 17,1 points de correction causale.

Comment séparer le diagnostic de la chance

Le placebo sert à ne pas créditer le diagnostiqueur de ce que l'agent aurait obtenu de toute façon à une deuxième tentative. L'évaluation soustrait la chance de se rétablir seul, l'effet du redémarrage et le bruit d'échantillonnage. Ni modèle-juge ni annotateurs n'interviennent dans le calcul : la vérité, c'est le rejeu lui-même.

Cette approche a sa raison d'être. Les benchmarks existants d'attribution des pannes comparent la réponse à une étiquette, or l'étiquette est discutable : l'« étape décisive » est l'appréciation d'un annotateur, et un autre point de correction tout aussi efficace est compté comme une erreur. De plus, d'après un travail de Naagarajan et Streif (2026), la réponse « toujours la dernière étape » est juste dans 67–96% des cas sur les jeux de données existants, et ne retombe près du niveau aléatoire que sur les pannes dont l'étape décisive est confirmée par le rejeu.

Les tâches proviennent d'OpsWorld, un environnement de back-office déterministe et généré de façon procédurale, avec 15 outils, trois familles de tâches et six niveaux de difficulté. Le dernier niveau est multimodal : QR-codes, photos de formulaires et texte manuscrit. Les instances sont créées à partir d'un seed ; de nouvelles tâches peuvent donc être générées à volonté, ce qui limite la mémorisation des tâches publiées, et chaque restauration d'état est vérifiée.

Ce qu'ont montré les 13 modèles

Sur 62 pannes systémiques calibrées, Grok 4.7 obtient le meilleur résultat. Toutefois, aucune des 78 différences par paires ne résiste à la correction pour comparaisons multiples : l'ordre observé ne peut donc pas être considéré comme une hiérarchie fiable. Les modèles phares des deux plus grands éditeurs, GPT-6 Astra et Claude Fable 5.1, se classent aux 8e et 12e places. Les auteurs précisent que les modèles Claude ont été lancés en dessous du niveau maximal de raisonnement, et qu'une ablation montre un coût de 15,2 points pour Claude Haiku 5.5. Cinq tâches n'ont été corrigées par aucun modèle.

L'astuce structurelle « toujours la dernière étape », qui domine les benchmarks fondés sur l'annotation, ne se transpose pas ici : l'intervention forcée à la dernière étape coûte à un modèle puissant les 17,1 points évoqués plus haut.

Expliquer une panne et la prévenir : deux compétences distinctes

La deuxième piste est la supervision en direct. Le superviseur suit l'exécution au fil de son déroulement et peut intervenir une seule fois avant une action irréversible, sans savoir si l'exécution va échouer. L'échantillon inclut aussi des exécutions réussies, afin de mesurer les fausses alertes. C'est la formulation de la supervision et du contrôle scalables de l'IA, mais appliquée à des erreurs honnêtes plutôt qu'à des agents hostiles, et évaluée par ses conséquences.

Sur 87 exécutions, les deux meilleurs superviseurs sont statistiquement indiscernables, et l'un d'eux est un petit modèle ouvert, DeepSeek V4.1 Flash. GPT-6.1 Sol figure parmi les meilleurs diagnostiqueurs a posteriori, mais s'avère le plus faible comme superviseur en direct. Il présente le plus grand écart entre « expliquer » et « prévenir » sur les mêmes exécutions. Conclusion des auteurs : la qualité de l'analyse après une panne peut être un mauvais prédicteur de la qualité du contrôle en temps réel.

Limites et nouveauté

Le rejeu contrefactuel n'est pas nouveau en soi : CausalFlow, REFLECT, SymTrace et d'autres travaux l'utilisent, mais comme moyen de vérifier leurs propres décisions. Dans ReplayRCA, le rejeu est la règle d'évaluation de n'importe quel modèle diagnostiqueur ; chaque score est calculé par rapport au placebo à la même étape, et les mêmes pannes servent à la fois à l'analyse a posteriori et à la supervision en direct.

Les instances publiées et la structure du générateur restent « apprenables ». Les auteurs évoquent la possibilité de régénérer le pool à mesure que les agents progressent, mais n'ont pas encore pu la vérifier. Ils présentent eux-mêmes ReplayRCA comme un protocole réutilisable et non comme un classement : l'environnement et le code d'évaluation sont publiés sur GitHub. Enseignement pratique pour les équipes qui bâtissent une supervision d'agents : choisir un superviseur d'après la qualité de ses analyses a posteriori est risqué ; mieux vaut le tester sur des exécutions en direct, mêlant lancements réussis et échoués.