Sommaire
Vous avez câblé un système multi-agents, vous lui avez donné des outils et vous l'avez lancé avec l'Agent SDK — alors comment mesurer si l'agent fait réellement son travail ? Pour une sortie unique, vous pouvez la noter avec des évaluations d'IA. Mais un agent planifie sur de nombreuses étapes, appelle des outils et agit avec un état. Même si la dernière phrase a l'air correcte, il a peut-être franchi un pont dangereux en chemin. C'est là que les agent evals entrent en scène.
Cet article expose, sur la base d'informations officielles, ce que sont les agent evals, en quoi elles diffèrent des évaluations de LLM, quoi mesurer (5 dimensions), comment noter (3 correcteurs), les pièges propres à ce domaine, ainsi que le workflow pratique et les benchmarks. Les points clés d'abord. ① Les agent evals mesurent non seulement « la sortie finale » mais aussi « la trajectory » des actions. ② Anthropic recommande de noter le résultat (l'état final), pas le chemin — car une vérification mécanique des étapes est fragile. ③ Commencez avec un petit jeu d'évaluation de 20 à 50 tâches tirées d'échecs réels, et exécutez une notation automatisée.
Mesurer à la fois « la réponse finale » et « le chemin parcouru »
— évaluer la sortie ne suffit pas ; les agents sont multi-étapes, utilisent des outils et ont un état
Anthropic recommande de noter le résultat plutôt que le chemin — mais la trajectory vous dit pourquoi il a échoué. Utilisez les deux, chacun à sa juste place.
1. Que sont les agent evals ?
Les agent evals sont le processus consistant à mesurer systématiquement si un « agent » — qui utilise des outils et enchaîne plusieurs étapes pour atteindre un objectif — parvient réellement à accomplir ses tâches. Elles sont une évolution des évaluations de LLM, qui jugent la qualité d'un seul prompt ; la cible s'élargit de « une sortie » à « une séquence d'actions ».
Pourquoi c'est important : dans son guide sur les agent evals, Anthropic note que « les évaluations deviennent plus difficiles à construire plus vous attendez. Au début, les exigences produit se traduisent naturellement en cas de test », et recommande que « 20 à 50 tâches simples tirées d'échecs réels constituent un excellent point de départ ». Autrement dit, les agent evals transforment « ça a l'air de marcher » en chiffres reproductibles. Cela s'articule avec l'observabilité de l'IA (observer l'exécution) — les traces que vous observez deviennent la matière première de l'évaluation.
2. Pourquoi elles diffèrent des évaluations de LLM (sortie vs trajectory)
Les évaluations de LLM traditionnelles notent essentiellement « entrée → une sortie ». Mais un agent planifie, appelle des outils, regarde les résultats, décide du coup suivant et met à jour son état. Donc se contenter de regarder la sortie finale ne suffit pas. Google le dit de même : « il ne suffit pas de simplement vérifier les sorties ; nous devons comprendre le "pourquoi" derrière les actions d'un agent », et scinde l'évaluation en deux familles : « réponse finale » et « trajectory ». Microsoft aussi affirme qu'il faut « évaluer non seulement la sortie finale, mais aussi la qualité et l'efficacité de chaque étape », en la divisant en évaluation système (de bout en bout) et processus (étape par étape).
💡 L'idée centrale : une « réponse finale correcte » peut masquer un processus cassé. À l'inverse, la réponse peut être juste mais atteinte par chance, par hasard, ou via un raccourci dangereux. Donc pour les agents, vous regardez à la fois le « résultat » et le « processus ». Pour les bases de l'évaluation d'une sortie unique et de la méthode LLM-as-judge, voir l'article sur les évaluations d'IA.
3. Quoi mesurer : 5 dimensions
Voici cinq angles couramment utilisés pour l'évaluation d'agents.
A-t-il atteint l'objectif ? Jugez d'après l'état final — qu'une réservation existe bien dans la DB — et non d'après l'énoncé « j'ai réservé ».
A-t-il suivi des étapes raisonnables ? A-t-il utilisé les bons outils dans le bon ordre et le bon nombre ? Des détours inutiles ou des manœuvres dangereuses ?
A-t-il choisi le bon outil et passé les bons arguments ? Vérifiez les noms de fonctions, les types d'arguments et les valeurs (et détectez les appels superflus).
Combien d'étapes, de tokens, de dollars et de secondes ? Une réponse correcte n'est pas viable si le coût explose. À relier aux métriques observées.
La sortie est-elle pertinente, exacte et complète ? Notez les contenus ouverts avec la méthode LLM-as-judge ou une grille.
Remarque : la 4. efficacité (tokens, coût, latence) n'est pas formellement codifiée comme une « métrique d'évaluation » par un éditeur en particulier ; en pratique, ce sont souvent des signaux d'observabilité ramenés dans l'évaluation. Cela reste une dimension essentielle pour arrêter un agent qui boucle et s'emballe.
4. Comment noter : 3 correcteurs et « résultat vs chemin »
Il existe globalement trois types de correcteurs. En suivant le cadre d'Anthropic, chacun a ses compromis.
| Correcteur | Forces | Faiblesses |
|---|---|---|
| Code (programmatique) | Rapide, peu coûteux, objectif, reproductible | Fragile face aux variations valides / alternatives |
| LLM-as-judge (modèle) | Souple, scalable, capte la nuance | Non déterministe, plus coûteux, nécessite une calibration avec des humains |
| Humain | Référence absolue pour la qualité | Coûteux, lent (à éviter si possible) |
La démarche standard : notez par code ce que vous pouvez, ne confiez que les parties subjectives et ouvertes à un modèle différent en tant que LLM-as-judge, et réservez les humains aux contrôles ponctuels aux points clés. La conception du LLM-as-judge (grilles détaillées, sorties discrètes, biais du juge) est traitée en profondeur dans l'article sur les évaluations de LLM.
La « correspondance de trajectory » mécanique est fragile
Alors comment noter la trajectory ? Ici, Anthropic adopte une position tranchée : « Il existe un réflexe courant qui consiste à vérifier que les agents ont suivi des étapes très précises, comme une séquence d'appels d'outils dans le bon ordre. Nous avons constaté que cette approche est trop rigide et aboutit à des tests excessivement fragiles, car les agents trouvent régulièrement des approches valides que les concepteurs d'évaluations n'avaient pas anticipées. Pour ne pas punir inutilement la créativité, il vaut souvent mieux noter ce que l'agent a produit, et non le chemin qu'il a emprunté. » Pour une réservation de vol, par exemple, vous mesurez si une réservation existe réellement dans la DB SQL de l'environnement comme état final — et non l'énoncé « j'ai réservé ».
De leur côté, Google et Microsoft proposent des degrés de correspondance de trajectory (exacte / dans l'ordre / dans n'importe quel ordre, etc.) comme métriques formelles. Les deux ne sont pas contradictoires — les évaluations de trajectory sont efficaces pour diagnostiquer « pourquoi il a échoué », et les évaluations de résultat évitent de punir une créativité valide. En pratique, le juste milieu réaliste est d'éviter la correspondance exacte stricte et de l'assouplir en un contrôle des actions clés : « les outils critiques ont-ils été appelés ? »
5. Problèmes propres aux agent evals
Les agent evals comportent des difficultés que l'évaluation d'une sortie unique ne connaît pas.
- Non-déterminisme (la même entrée emprunte des chemins différents) : une réussite ne signifie pas qu'elle se reproduit. Il vous faut des métriques de fiabilité comme le fait de réussir sur l'ensemble des k exécutions (pass^k). L'article sur τ-bench rapporte que « les modèles se dégradent considérablement à mesure que k augmente, révélant leur manque de fiabilité » (les chiffres sont datés à un instant donné).
- Erreurs cumulatives : si une seule étape réussit avec une probabilité p, alors t étapes réussissent à peu près à pt. Plus la chaîne est longue, plus elle s'effondre vite — c'est pourquoi la réussite chute fortement sur les tâches à long horizon.
- Reward hacking / specification gaming : un comportement qui satisfait la lettre du correcteur sans atteindre l'objectif réel. Dans l'exemple de DeepMind, un bras robotisé s'est placé entre la caméra et l'objet, trompant les évaluateurs en leur faisant croire qu'il avait saisi l'objet alors que ce n'était pas le cas. Détecter un « chemin qui a l'air correct mais dangereux » exige d'évaluer la trajectory et les effets de bord.
- Jeux d'évaluation qui se périment / contamination : lorsqu'un benchmark fuite dans les données d'entraînement (contamination), les scores cessent de refléter la capacité réelle. Vous devez continuer à mettre à jour vos évaluations de régression à mesure que l'agent mûrit.
Le problème du « chemin dangereux » est dans la continuité des garde-fous d'IA. Une évaluation qui ne regarde que la réponse finale passe à côté de ces pièges.
6. Le workflow et les benchmarks
Ancré sur les recommandations d'Anthropic, le workflow est simple.
- Construisez petit, à partir d'échecs réels : vous n'avez pas besoin de centaines. Transformez 20 à 50 échecs survenus en production en cas de test.
- Exécutez une notation automatisée : le code d'abord, le LLM-as-judge uniquement pour les parties ouvertes. Privilégiez le volume sur la qualité d'une notation manuelle.
- Séparez deux types : les évaluations de capacité (à quoi est-il bon ?) et les évaluations de régression (sait-il toujours faire ce qu'il savait faire ?).
- Inscrivez-les dans un cycle de vie : ① évaluations automatisées avant lancement (intégrées au CI) → ② monitoring en production → ③ tests A/B → ④ retours utilisateurs et revue des traces, par couches successives.
- Écrivez-les tôt : les évaluations deviennent plus difficiles à construire plus vous attendez.
Les benchmarks d'agents bien connus sont aussi des références utiles pour construire vos propres évaluations (l'essentiel est de lire « ce que chacun mesure » ; les scores bougent selon le modèle et la version, alors ne les prenez pas au pied de la lettre).
| Benchmark | Ce qu'il mesure |
|---|---|
| SWE-bench / Verified | Résoudre de vrais problèmes GitHub avec un patch, noté réussite/échec par la suite de tests (basé sur l'exécution) |
| τ-bench / τ²-bench | Dialogue multi-tours outil×utilisateur dans le retail, l'aérien, etc. + respect des politiques ; noté sur l'état final de la DB |
| WebArena | Accomplissement de tâches d'opération web autonome sur des répliques de sites réalistes |
| GAIA | Tâches d'assistant généraliste faciles pour les humains, difficiles pour l'IA (raisonnement + outils + navigation) |
| OSWorld | Computer use pilotant une interface graphique sur un vrai OS, évalué sur la base de l'exécution |
| BFCL | Justesse de l'appel de fonctions/outils (noms de fonctions, structure des arguments, exécutabilité) |
Côté outillage, LangSmith, Braintrust, DeepEval et Arize Phoenix prennent en charge l'évaluation de la trajectory et des appels d'outils. La plupart s'appuient sur les traces, en notant aux niveaux de l'étape, de l'exécution et du jeu de données. À noter que Claude Managed Agents intègre une notation basée sur les résultats — où un correcteur distinct évalue par rapport à votre grille — en natif.
Résumé
Les agent evals sont le processus consistant à mesurer si un agent multi-étapes qui utilise des outils parvient réellement à accomplir ses tâches. Contrairement aux évaluations de LLM, qui regardent une sortie unique, elles examinent à la fois « la réponse finale (résultat) » et « le chemin parcouru (trajectory) ». Les dimensions sont ① résultat ② trajectory ③ usage des outils ④ efficacité ⑤ qualité finale. Notez avec code → LLM-as-judge → humain, et Anthropic recommande de « noter le résultat (l'état final), pas le chemin » (une vérification mécanique des étapes est fragile).
Les pièges propres à ce domaine sont le non-déterminisme (pass^k), les erreurs cumulatives, le reward hacking et les jeux d'évaluation périmés. En pratique, la démarche standard consiste à commencer petit avec 20 à 50 cas tirés d'échecs réels, exécuter une notation automatisée dans le CI, séparer évaluations de capacité et de régression, et les écrire tôt. À lire aussi : évaluations d'IA, observabilité, comment construire un système multi-agents, Managed Agents.
FAQ
Q. Que sont les agent evals ?
A. Le processus consistant à mesurer systématiquement si un agent multi-étapes qui utilise des outils parvient réellement à accomplir ses tâches. Elles sont une évolution des évaluations de LLM, qui notent un seul prompt ; la cible s'élargit de « une sortie » à « une séquence d'actions ». Leur marque de fabrique est de regarder non seulement la réponse finale mais la trajectory qui y a mené (quels outils ont été appelés, et comment).
Q. En quoi diffèrent-elles des évaluations de LLM ordinaires ?
A. Dans le fait de regarder « une sortie » ou « une chaîne d'actions ». Comme un agent planifie, appelle des outils et met à jour son état, la seule sortie finale ne suffit pas. Une réponse correcte peut masquer un processus cassé, et une réponse juste peut être venue via un raccourci dangereux. Vous évaluez donc à la fois le résultat (état final) et la trajectory (processus).
Q. Que dois-je mesurer ?
A. Les cinq dimensions courantes : ① résultat (réussite de la tâche = l'état final correspond-il à l'objectif ?) ② trajectory (étapes raisonnables ?) ③ justesse de l'usage des outils (bon outil, bons arguments ?) ④ efficacité (étapes, tokens, coût, latence) ⑤ qualité de la réponse finale (pertinente, exacte, complète ?). La dimension 4 fait intervenir des signaux d'observabilité et est importante pour stopper les emballements.
Q. Dois-je vérifier la trajectory (les étapes) en correspondance exacte ?
A. Non — la correspondance exacte stricte tend à être fragile. Anthropic recommande : « vérifier que les appels d'outils ont suivi le bon ordre est trop rigide et fragile ; les agents trouvent des alternatives valides, alors mieux vaut noter le résultat, pas le chemin. » En pratique, évitez la correspondance exacte et assouplissez en un contrôle des actions clés : « les outils critiques ont-ils été appelés ? » Cela dit, la trajectory est utile pour diagnostiquer pourquoi il a échoué, alors utilisez chacune là où elle convient.
Q. Comment démarrer ?
A. Commencez par transformer 20 à 50 échecs de production en cas de test. Comme le dit Anthropic, « vous n'avez pas besoin de centaines ; 20 à 50 tâches simples tirées d'échecs réels constituent un excellent point de départ ». Notez automatiquement — le code pour ce que le code peut mesurer, un LLM-as-judge (modèle distinct) uniquement pour les parties ouvertes — et placez-les dans le CI pour attraper les régressions. Séparez les évaluations de capacité (à quoi il est bon) des évaluations de régression (préserver ce qui marchait), et écrivez vos évaluations tôt.
