Anthropic détaille ses evals pour agents IA : trois types de graders et un SWE-bench passé de 40% à 80%

Anthropic a publié un guide d'ingénierie sur l'évaluation des agents IA. Son idée centrale est très terre à terre : sans evals, une équipe qui a atteint la production se met à corriger une chose et à en casser une autre. Un agent appelle des outils, modifie l'état de l'environnement et s'adapte aux résultats intermédiaires sur de nombreuses étapes, si bien que les erreurs s'accumulent. Évaluer un tel système exige de combiner plusieurs méthodes. Pour l'illustrer, les auteurs citent des chiffres : sur SWE-bench Verified, les modèles sont passés de 40% à plus de 80% en un an, et Bolt a mis en place un système d'évaluation opérationnel en trois mois.

Les composants d'un eval d'agent

Anthropic commence par les termes, car l'industrie les emploie de façon disparate. Une tâche (task) est un test unique, avec des données d'entrée et des critères de réussite. Chaque tentative s'appelle un trial, et on en lance plusieurs : la sortie du modèle change d'un run à l'autre. Un grader est la logique qui évalue un aspect précis du travail ; une même tâche peut en comporter plusieurs. Le transcript est la trace complète d'une tentative : messages, appels d'outils, raisonnements. L'outcome est l'état final de l'environnement.

La différence entre ces deux derniers est essentielle. Un agent de réservation peut écrire « Votre vol est réservé », mais seule compte la présence d'une entrée dans la base SQL. Autre précision, sur l'objet de la mesure : en évaluant un agent, on évalue le couple formé par le modèle et son harness, pas le modèle seul. Les auteurs donnent l'exemple d'Opus 4.5 dans le test τ2-bench. Le modèle a trouvé une faille dans les règles de réservation d'un vol et a « échoué » à la tâche selon les critères formels, alors qu'il avait imaginé pour l'utilisateur une meilleure solution.

Trois types de graders

Les evals d'agents s'assemblent généralement à partir de trois types de vérifications :

• Graders à base de code : vérifications par chaînes de caractères et regex, tests fail-to-pass, analyse statique, contrôle de l'état final et des appels d'outils. Rapides, peu coûteux et reproductibles, mais fragiles face aux variations valides d'une réponse. • Graders à base de modèles : rubriques, assertions en langage naturel, comparaison par paires, consensus de plusieurs juges. Flexibles et scalables, mais non déterministes, plus coûteux et à calibrer sur des évaluations humaines. • Graders humains : revue d'experts, crowdsourcing, contrôle par échantillonnage, tests A/B. C'est l'étalon-or de la qualité, mais il est lent et coûteux.

Le score final d'une tâche peut être pondéré, binaire (tous les graders doivent passer) ou hybride. Seconde distinction : capability evals et regression evals. Les premiers doivent démarrer avec un pass rate faible et donner à l'équipe une pente à gravir. Les seconds doivent passer à près de 100% et détecter les régressions. Quand un jeu de capability evals est saturé, ses tâches « sortent » vers la suite de régression.

Agents de code et agents conversationnels

Pour les agents de code, les vérifications déterministes vont de soi : le code s'exécute, les tests passent. SWE-bench Verified soumet à l'agent des issues GitHub issues de dépôts Python populaires. Il ne valide la solution que si les tests qui échouaient sont corrigés et que les tests existants ne sont pas cassés.

Terminal-Bench teste des tâches techniques de bout en bout, comme compiler le noyau Linux depuis les sources ou entraîner un modèle de ML. En plus des tests, Anthropic recommande d'évaluer le transcript : heuristiques de qualité du code et rubriques sur le comportement de l'agent. Dans un YAML d'illustration pour la tâche « corriger un contournement d'authentification », tous les types de vérifications sont réunis, dont des tests, ruff, mypy, bandit et des métriques sur le nombre de tours, les tokens et la latence.

En pratique, précisent les auteurs, des tests unitaires et une rubrique LLM sur la qualité du code suffisent.

Les agents conversationnels (support, ventes, coaching) se distinguent par un point : la qualité de l'interaction elle-même fait partie de ce qu'on évalue. On s'appuie ici sur un état final vérifiable et sur des rubriques qui couvrent à la fois l'exécution de la tâche et la qualité de l'échange.

Par où commencer

Les arguments d'Anthropic en faveur des evals sont pratiques. Au début, ils obligent à fixer ce qui compte comme un succès : deux ingénieurs lisant la même spécification n'interpréteront pas de la même façon le comportement dans les cas limites. Ensuite, ils fournissent des références de base sur la latence, la consommation de tokens, le coût par tâche et le taux d'erreurs. Ils accélèrent aussi le passage à de nouveaux modèles : les équipes dotées d'evals évaluent les forces et les faiblesses en quelques jours, les autres testent pendant des semaines.

Voici les exemples tirés de la pratique. Claude Code s'est d'abord développé grâce aux retours des utilisateurs, puis a reçu des evals sur la concision et l'édition de fichiers, et ensuite sur la sur-complexification des solutions. Descript évalue son agent selon trois critères : ne rien casser, faire ce qui est demandé, le faire bien. L'équipe est passée de la vérification manuelle à des graders LLM avec une calibration humaine périodique. Bolt a commencé tard, quand l'agent était déjà largement utilisé.

La conclusion pratique : n'attendez pas un jeu de tests parfait. Prenez les tâches sur lesquelles l'agent échoue aujourd'hui et formalisez-les comme un capability eval. Ajoutez des graders à base de code sur l'état final de l'environnement. Ne recourez à un juge LLM que pour ce que le code ne peut pas vérifier, et confrontez-le aux évaluations humaines. Exécutez chaque tâche plusieurs fois, et transférez dans la suite de régression celles qui passent de façon stable.