Guide
Évaluer un agent IA : tâches, correcteurs, traces
Évaluer un agent IA : tâches tirées d'échecs réels, essais répétés, correcteurs par code, modèle ou humain, pass@k et pass^k, d'après Anthropic.
Mis à jour le
Pour évaluer un agent IA, on lui donne une série de tâches aux critères de réussite clairs, on lance plusieurs essais par tâche parce que ses réponses varient, on note le résultat final avec des correcteurs adaptés, et on lit les traces pour comprendre les échecs. C'est la méthode publiée par Anthropic dans « Demystifying evals for AI agents » (09/01/2026), résumée ici.
Le vocabulaire
| Terme | Sens |
|---|---|
| Tâche (task) | Un test, avec des entrées et des critères de réussite |
| Essai (trial) | Une tentative sur une tâche ; on en lance plusieurs |
| Correcteur (grader) | La logique qui note un aspect du travail ; une tâche peut en avoir plusieurs |
| Trace (transcript) | L'enregistrement complet d'un essai : messages, appels d'outils, résultats |
| Résultat (outcome) | L'état final de l'environnement, par exemple : la réservation existe-t-elle dans la base ? |
| Banc d'évaluation (evaluation harness) | L'infrastructure qui lance les essais et collecte les notes |
Anthropic insiste sur un point : évaluer un « agent », c'est évaluer ensemble le modèle et le programme qui le fait agir (le harness). Changer d'outils ou d'instructions change le résultat autant que changer de modèle.
Trois sortes de correcteurs
| Correcteur | Forces | Faiblesses |
|---|---|---|
| Par code (tests, comparaisons, vérification de l'état final) | Rapide, peu coûteux, objectif, reproductible | Fragile face à des variantes valables, peu nuancé |
| Par un modèle (un modèle de langage qui note selon une grille) | Souple, capte la nuance, passe à l'échelle | Non déterministe, plus coûteux, doit être calibré par des humains |
| Humain | Référence de qualité, sert à calibrer les autres | Lent, coûteux, difficile à multiplier |
Pour un modèle correcteur, Anthropic conseille une grille par critère et une sortie « inconnu » possible, plutôt que de forcer une note quand l'information manque.
Deux familles d'évaluations
- Évaluations de capacité : « que sait bien faire cet agent ? » Elles commencent avec un taux de réussite faible, pour donner une cible.
- Évaluations de non-régression : « l'agent réussit-il encore tout ce qu'il réussissait ? » Elles doivent rester proches de 100 %.
Une évaluation de capacité qui atteint un taux élevé devient une évaluation de non-régression.
Répéter les essais : pass@k et pass^k
Un agent ne donne pas toujours la même réponse. D'où deux mesures :
- pass@k : probabilité d'obtenir au moins une réussite en k essais. Utile quand une seule bonne solution suffit.
- pass^k : probabilité que les k essais réussissent tous. Utile quand il faut être fiable à chaque fois, par exemple pour un agent face aux clients.
L'exemple d'Anthropic : un agent qui réussit 75 % du temps a une probabilité d'environ 42 % de réussir trois essais de suite (0,75 × 0,75 × 0,75). Un taux de réussite qui semble correct peut donc cacher une fiabilité insuffisante.
Constituer le jeu de tâches
- Commencer petit : 20 à 50 tâches simples tirées d'échecs réels, selon Anthropic. Dans son article sur le système de recherche multi-agents (13/06/2025), l'équipe raconte avoir démarré avec une vingtaine de requêtes représentatives.
- Puiser dans le réel : vérifications manuelles déjà faites, tickets de bogues, demandes du support. Chaque échec signalé par un utilisateur devient une tâche.
- Écrire des tâches sans ambiguïté : deux experts doivent arriver au même verdict. Fournir une solution de référence qui passe tous les correcteurs.
- Tester aussi ce qui ne doit pas arriver : des tâches où l'agent doit refuser, s'abstenir ou demander une précision.
- Isoler les essais : chaque essai part d'un environnement propre, sans état laissé par le précédent.
Noter le résultat, pas le chemin
Anthropic recommande de noter « ce que l'agent a produit, pas le chemin qu'il a pris » : plusieurs parcours peuvent être valables, et imposer une séquence précise d'appels d'outils pénalise des solutions correctes. Prévoyez des points partiels : un agent qui identifie le problème mais échoue au remboursement fait mieux que celui qui se trompe dès le départ.
Selon le type d'agent
| Type d'agent | Comment vérifier |
|---|---|
| Programmation | Tests automatisés, complétés par une grille de qualité du code |
| Conversation (support, accueil) | État final (le ticket est-il résolu ?), grille sur la qualité de l'échange, et un second modèle qui joue l'utilisateur |
| Recherche | Ancrage dans les sources, couverture, qualité des sources ; calibrage régulier par des experts |
| Utilisation d'ordinateur | État final dans l'application ou la base |
Lire les traces
Le conseil le plus simple de l'article est aussi le plus important : vous ne saurez pas si vos correcteurs fonctionnent sans lire les traces et les notes de nombreux essais. C'est en lisant qu'on découvre un outil mal décrit, une consigne mal comprise ou un correcteur trop sévère. Anthropic applique la même démarche aux outils eux-mêmes dans « Writing effective tools for agents » (11/09/2025) : des tâches réalistes, des vérificateurs, puis l'analyse des traces pour améliorer les descriptions.
Pour relier qualité et dépense, rapportez le coût total à la réussite : voyez coût d'un agent. Et si votre agent est exposé à des contenus extérieurs, ajoutez des tâches d'injection de prompt à votre jeu de test.
Questions fréquentes
Combien de tâches faut-il pour commencer à évaluer un agent ?
Anthropic indique que 20 à 50 tâches simples tirées d'échecs réels sont un très bon départ, sans attendre d'en avoir des centaines.
Quelle différence entre pass@k et pass^k ?
pass@k est la probabilité de réussir au moins une fois en k essais ; pass^k est la probabilité de réussir les k essais. Le second compte quand l'agent doit être fiable à chaque fois, par exemple face à un client.
Sources
Pages consultées pour écrire cet article :