Évaluer un agent d’IA, c’est vérifier qu’il atteint un objectif utilisateur tout au long de son parcours d’exécution, et pas seulement qu’il formule une réponse finale convaincante. Pour rendre l’exercice reproductible, reliez un parcours utilisateur critique à des scénarios, à l’examen des traces, à des contrôles automatisés et aux retours de production. Google décrit cette démarche dans son guide d’évaluation des agents.
Un processus en cinq étapes
Chaque étape prépare la suivante : on définit d’abord la réussite, puis on teste des situations réalistes, on rend les exécutions comparables, on automatise les contrôles et l’on réutilise les observations de production.
Les étapes
1. Définir la réussite à partir d’un parcours utilisateur
Commencez par décrire une personne, son objectif, les contraintes de la tâche et les conditions permettant de vérifier le résultat. Ce parcours utilisateur critique transforme une demande générale — par exemple, traiter une demande de remboursement — en points d’évaluation concrets : l’agent a-t-il trouvé la bonne commande ? A-t-il respecté la règle applicable ? A-t-il produit la réponse attendue ?
Google recommande de convertir chaque clause du parcours en contrôle. Cette méthode évite de réduire l’évaluation à une note globale qui ne dit pas à quel moment l’agent a déraillé.
2. Tester des scénarios et examiner les traces
Préparez un scénario courant et des cas limites : informations incomplètes, faute de frappe, demande formulée sur plusieurs échanges ou donnée inconnue. Google propose de commencer avec des utilisateurs simulés, puis d’intégrer progressivement des traces issues de la production.
Une trace permet d’examiner le déroulement plutôt que le seul résultat : les prompts, les étapes intermédiaires, les arguments transmis aux outils et la réponse finale. Au départ, lisez ces traces manuellement et transformez les échecs récurrents en contrôles répétables. Une réponse fluide peut masquer une erreur dans un appel d’outil ou une étape intermédiaire.
3. Rendre les exécutions comparables
Un agent peut suivre des trajectoires différentes d’un essai à l’autre, tandis qu’un service externe ou une base de données peut aussi changer. Braintrust recommande donc plusieurs essais pour une même tâche et des dépendances contrôlées, par exemple des services simulés (stubs) ou des instantanés de données. Son guide décrit aussi les environnements isolés et l’injection de pannes — comme des délais d’attente, des réponses mal formées ou des champs manquants — pour tester la réaction de l’agent. Ces méthodes sont détaillées dans le guide de Braintrust.
Comparez les essais dans des conditions aussi stables que possible : vous pourrez mieux distinguer une variation du comportement de l’agent d’un changement dans son environnement. Braintrust ne fixe pas de nombre universel d’essais.
4. Combiner les contrôles et calibrer les juges LLM
Aucun contrôle ne couvre à lui seul tous les types d’échec. Google distingue quatre familles : les tests unitaires, les métriques déterministes, les grilles d’évaluation appliquées par un juge LLM et les tests d’intégration. Les premières vérifications peuvent cibler un composant ; les dernières examinent le comportement à travers plusieurs étapes. Google recommande aussi de comparer les évaluations automatiques à des traces examinées par des humains, et de privilégier des critères binaires lorsque c’est possible.
Un juge LLM peut évaluer une réponse selon une grille ou comparer deux réponses. Zahra Ashktorab, d’IBM Technology, décrit trois biais possibles : le biais de position, qui favorise une réponse selon son ordre d’affichage ; le biais de verbosité, qui favorise les réponses plus longues ; et le biais d’auto-préférence, qui favorise une réponse produite par le modèle évaluateur lui-même. Pour sonder spécifiquement le biais de position, inversez l’ordre des réponses candidates et vérifiez si le jugement change. Ce test ne porte que sur l’effet de l’ordre.
5. Protéger la base de référence et apprendre de la production
Conservez le même jeu de tests de référence pendant une comparaison et ne modifiez qu’une variable à la fois. Sinon, un score peut changer parce que les tests ont changé, et non parce que l’agent s’est amélioré. Google illustre le piège avec 12 réussites sur 20 tests, soit 60 % ; après la suppression de cinq tests échoués, les mêmes 12 réussites représentent 80 % des 15 tests restants. Aucun nouveau test n’a été réussi.
Suivez aussi le comportement opérationnel : latence, consommation de jetons, coût d’API et nombre d’appels aux outils, en plus de la qualité des réponses. Pour les changements intégrés en CI/CD, Google décrit une barrière combinant un seuil global de réussite et l’absence de régression sur les métriques principales déjà réussies. Le seuil de 95 % donné dans son guide est un exemple, pas une norme générale.
Enfin, l’évaluation peut s’appuyer sur les interactions en production. Microsoft décrit une boucle où les observations en ligne servent à actualiser les jeux de tests hors ligne ; Google recommande également d’ajouter aux tests de référence les cas limites découverts en production. Microsoft présente cette approche dans sa leçon sur l’évaluation des agents en production.
