Mesurer un agent¶
Dans l'industrie, on ne trace pas de carte de contrôle avant d'avoir validé l'instrument de mesure. Cette étape s'appelle l'analyse du système de mesure (Measurement System Analysis, MSA) : un pied à coulisse qui donne des résultats différents sur la même pièce rend toute carte inutile. Pour un agent, l'instrument de mesure est la batterie d'évaluations et son correcteur. Ce chapitre l'examine avant de parler de surveillance.
L'instrument lui-même peut être faux¶
Le cas SWE-bench Verified¶
SWE-bench Verified est, jusqu'en 2026, le banc d'essai de référence des agents de code : 500 tickets GitHub réels, chacun accompagné de tests qui valident le correctif. En février 2026, OpenAI annonce cesser de l'utiliser (source) : sur les problèmes audités, au moins 59,4 % ont des tests qui rejettent des solutions correctes, et plusieurs modèles reproduisent des correctifs de mémoire (contamination). Epoch AI estimait de son côté le taux d'erreur du jeu de données à 5-10 % (méthodologie).
Erreur fréquente : prendre un banc d'essai pour une vérité
Un test qui rejette une solution correcte est un instrument biaisé. Dans le vocabulaire de la MSA, c'est un défaut de justesse (le test mesure autre chose que la correction) doublé d'un défaut de fidélité quand le résultat dépend du run. Avant de surveiller le taux de réussite d'un agent sur une batterie maison, il faut auditer un échantillon de ses échecs à la main.
Le cas du juge LLM¶
Quand le correcteur est lui-même un modèle de langage (LLM-as-judge), il apporte ses propres biais documentés :
- position, verbosité et auto-promotion (Zheng et al., NeurIPS 2023, arXiv 2306.05685) ; le même article trouve néanmoins plus de 80 % d'accord entre GPT-4 et les humains, le même niveau qu'entre humains ;
- en jouant seulement sur l'ordre de présentation, Vicuna-13B « bat » ChatGPT sur 66 requêtes sur 80 quand ChatGPT est le juge (Wang et al., arXiv 2305.17926) ;
- les modèles reconnaissent et favorisent leurs propres productions (Panickssery, Bowman, Feng, arXiv 2404.13076). Conséquence pratique : ne pas faire juger le code d'un modèle par le même modèle.
Hamel Husain, l'un des praticiens les plus suivis sur les évaluations, recommande de calibrer un juge contre des étiquettes humaines et de rapporter séparément son taux de vrais positifs et de vrais négatifs, car l'accord brut est trompeur quand les classes sont déséquilibrées (source).
Enfin, le juge dérive lui aussi. Un article de juin 2026 formule le problème en une phrase : « toute alarme de dérive est ambiguë entre un produit qui s'est dégradé et un juge qui a changé » (Li, arXiv 2606.15474). La solution proposée est un ensemble d'ancrage fixe, étiqueté par des humains, que le juge re-note périodiquement — exactement l'équivalent d'un étalon de calibration qu'on repasse sur la machine de mesure chaque matin.
Bien définir ce qu'on mesure : pass@k contre pass^k¶
Pour une tâche, on lance l'agent k fois. Deux mesures sont possibles :
- pass@k (Chen et al., 2021, arXiv 2107.03374) : probabilité qu'au moins un des k essais réussisse. Mesure de capacité.
- pass^k (Yao et al., τ-bench, 2024, arXiv 2406.12045) : probabilité que les k essais réussissent tous. Mesure de fiabilité.
Si chaque essai réussit indépendamment avec une probabilité \(p\) :
où \(p\) est le taux de réussite d'un essai et \(k\) le nombre d'essais. Le script (§5) donne quelques valeurs :
| \(p\) | pass@5 | pass^5 | pass@10 | pass^10 |
|---|---|---|---|---|
| 0,60 | 0,990 | 0,078 | 1,000 | 0,006 |
| 0,80 | 1,000 | 0,328 | 1,000 | 0,107 |
| 0,95 | 1,000 | 0,774 | 1,000 | 0,599 |
Anthropic le résume dans son guide des évaluations d'agents : à k = 10, les deux mesures « racontent des histoires opposées » (source).
Lequel surveiller dans un orchestrateur
Un orchestrateur 100 % automatisé lance une fois chaque tâche et fusionne le résultat (ou relance sur échec, ce qui coûte). Ce qui compte pour la production est donc \(p\) lui-même — le taux de réussite au premier essai — et sa stabilité dans le temps. pass@k est une mesure de potentiel pour la recherche ; ce n'est pas une mesure de qualité de production.
Le bruit d'échantillonnage : combien d'essais faut-il ?¶
Les barres d'erreur¶
Evan Miller (Anthropic) a publié en novembre 2024 un guide statistique des évaluations (arXiv 2411.00640, billet). Ses cinq recommandations :
- Toujours rapporter une erreur standard.
- Utiliser des erreurs standard par grappes quand les questions sont groupées (plusieurs questions sur un même document) : elles peuvent être plus de trois fois plus grandes que les erreurs naïves.
- Réduire la variance propre à chaque question en rééchantillonnant.
- Comparer deux modèles par différences appariées sur les mêmes questions.
- Faire une analyse de puissance avant de lancer l'évaluation.
Ce que vaut un écart de 2 points¶
Sur SWE-bench Verified, Bjarnason, Silva et Monperrus ont relancé 60 000 trajectoires (arXiv 2602.07150, 2026) : le score d'une exécution unique varie de 2,2 à 6,0 points selon l'exécution retenue, avec un écart-type supérieur à 1,5 point même à température 0. Un gain annoncé de 2 ou 3 points peut donc n'être que du bruit.
Le calcul pour votre propre batterie¶
Le script (§4) calcule le nombre d'essais nécessaires pour distinguer deux taux de réussite avec un risque d'erreur de 5 % et une puissance de 80 % (test bilatéral de deux proportions) :
| Comparaison | Essais par version |
|---|---|
| 80 % contre 70 % | 294 |
| 80 % contre 75 % | 1 094 |
Et il simule une carte p (proportion de réussites par lot) sur un agent dont le taux de réussite normal est 80 %, avec des limites à 3σ, quand le taux réel tombe à 70 % :
| Essais par lot | Limite basse | Probabilité de détecter au lot suivant | Lots avant détection (moyenne) |
|---|---|---|---|
| 10 | 0,42 | 4,7 % | 21 |
| 30 | 0,58 | 8,4 % | 12 |
| 50 | 0,63 | 14,1 % | 7 |
| 100 | 0,68 | 28,9 % | 3 |
Limite importante
Une chute de 80 % à 70 % de réussite — un agent qui rate une tâche sur trois au lieu d'une sur cinq — n'est détectée par une carte p qu'après 210 à 360 essais dans tous les cas. Une batterie de 20 tâches lancée à chaque modification de prompt ne voit rien d'une dégradation de cette taille. C'est la raison quantitative pour laquelle le postmortem d'Anthropic insiste sur l'évaluation continue en production : seule la production fournit assez d'essais.
À retenir
Avant de surveiller un agent : (1) auditer l'instrument (tests qui rejettent des solutions correctes, juge non calibré), (2) choisir la bonne mesure (taux de réussite au premier essai, pas pass@k), (3) accepter que la détection de dégradations modérées demande des centaines d'essais — et donc que la surveillance se fasse sur le flux de production, pas sur une batterie de pré-déploiement.