Comment évaluer des agents IA : jeux de tests, évaluateurs et vérifications de régression
Un guide pratique en six étapes pour évaluer des agents IA : définir les critères de réussite, créer des jeux de tests à partir de défaillances réelles, choisir les évaluateurs, exécuter des vérifications de régression et surveiller l’agent en production.

Derrière chaque excellent produit d’IA se cache un solide processus d’évaluation des agents d’IA, qu’on appelle les évals, qui détecte les erreurs tôt et garantit le bon fonctionnement de l’agent. Les évals sont essentielles pour les agents d’IA qui exécutent des actions à haut risque, comme des remboursements au nom de quelqu’un.
Mettre en place ce processus exige certaines connaissances techniques et des compétences en analyse de données. Mais ce n’est pas aussi intimidant ni inaccessible qu’on pourrait le croire. Pour vous aider à démarrer, nous avons décrit six étapes pratiques pour évaluer des agents d’IA, ainsi que les idées reçues courantes qui compromettent le processus.
Que signifie évaluer un agent d’IA?
Évaluer un agent d’IA consiste à mesurer sa capacité à accomplir correctement des tâches et à vérifier si ses décisions respectent les exigences de l’organisation. Concrètement, les évaluations d’agents d’IA, ou évals, sont des indicateurs précis qui aident les organisations à déterminer si l’agent fonctionne de façon suffisamment fiable pour le rôle prévu.
Prenons l’exemple d’un agent d’IA chargé des achats dans une usine de fabrication, qui vérifie l’inventaire des pièces de rechange et prépare les demandes de réapprovisionnement. Si une pièce approuvée n’est pas disponible ou si les renseignements sur le fournisseur sont périmés, l’agent signalera-t-il le problème ou recommandera-t-il un substitut non approuvé?
Et si vous modifiez son invite système pour corriger ce problème, comment savoir que vous n’en avez pas introduit un autre?
Sans évaluation, les gestionnaires de produits en sont essentiellement réduits à deviner. Les évals fournissent donc un signal de rétroaction qui permet de mesurer la performance, de repérer les problèmes récurrents et de tester les changements avec plus d’assurance.
Cela dit, une évaluation d’agent peut examiner plusieurs aspects d’une exécution :
- La qualité du résultat final
- Les renseignements utilisés par l’agent
- Les outils qu’il a appelés
- Le respect des règles qui encadrent son comportement
Indicateurs courants d’évaluation des agents d’IA
Les évals s’appuient sur des données qualitatives et quantitatives. L’évaluation qualitative vous aide à comprendre ce qui se passe et pourquoi, notamment grâce à l’examen manuel des décisions de l’agent. L’évaluation quantitative transforme ces observations en signaux mesurables, par exemple en comptant la fréquence de modes de défaillance précis ou en calculant le taux de réussite des tâches.
Voici la liste des indicateurs fondamentaux d’évaluation des agents d’IA :
- La réussite de la tâche indique si l’agent a atteint le résultat visé; elle se mesure généralement en pourcentage d’exécutions qui produisent des résultats valides.
- La justesse des actions indique si l’agent a utilisé les outils de façon appropriée, choisi des arguments valides et respecté les autorisations.
- La qualité des réponses permet d’évaluer si le résultat final est exact, complet et utile. Elle peut englober l’exactitude factuelle, le respect des instructions et la capacité de l’agent à appuyer ses décisions sur les renseignements disponibles.
- La fiabilité mesure la constance des résultats au fil d’essais répétés, avec des entrées variées et dans les cas limites.
- Le coût et la latence mesurent les ressources nécessaires pour obtenir un résultat réussi, y compris le temps d’exécution, la consommation de jetons et les appels d’outils.
Selon ce que vous mesurez, les évals peuvent porter sur la performance de bout en bout d’un agent, sur sa trajectoire d’exécution ou sur des composantes individuelles comme les appels d’outils et les étapes de récupération.
Étape 1 : Définir ce à quoi ressemble une exécution réussie de l’agent
D’abord, décrivez explicitement ce que l’agent est censé accomplir — les exigences du produit. Cela semble évident, mais c’est parfois étonnamment difficile. Le phénomène porte même un nom : l’écart de spécification.
Voici comment l’aborder, selon Andrey Khomutov, notre scientifique principal des données :
« Commencez par deux questions : “Qu’est-ce qui compterait comme un travail accompli?” et “Qu’est-ce qui rendrait inacceptable une exécution en apparence réussie?”
Pour les agents, d’un point de vue technique, cela signifie vérifier à la fois le résultat et la façon dont ils y sont parvenus. »
Un agent peut produire la bonne réponse en accédant à un corrigé qui a fuité, ou effectuer des actions non autorisées pendant qu’il accomplit sa tâche. Khomutov souligne que la fuite des réponses et les actions risquées pendant les évaluations sont des raisons concrètes de ne pas juger uniquement la réponse finale.
« Je m’attends à ce que l’inspection des trajectoires devienne une composante standard des suites d’évals d’agents, plutôt qu’une chose qu’on fait seulement quand un résultat semble suspect », ajoute-t-il.
Faites ensuite appel à un expert du domaine pour valider vos critères de réussite. Les personnes qui ont une connaissance pratique du domaine peuvent dire si les conditions que nous avons fixées pour un agent d’IA correspondent bien à un résultat réussi.
Étape 2. Constituer un jeu de tests à partir de tâches et d’échecs réels
Examinez le comportement réel de l’agent pour comprendre à quoi ressemblent une bonne et une mauvaise performance. Résistez à la tentation de commencer par générer des dizaines de tests fondés uniquement sur ce qui, selon vous, pourrait mal tourner.
Hamel Husain, ingénieur en ML chez Parlance Lab, et Shreya Shankar, chercheuse en systèmes de ML et en évals d’IA appliquée, recommandent de commencer par l’analyse des erreurs, une technique empruntée à l’apprentissage automatique et à la science des données. Le processus débute par une analyse qualitative des traces d’exécution de l’agent — des enregistrements qui montrent l’entrée de l’utilisateur, les appels d’outils, les renseignements récupérés et la sortie de l’agent.
- Examinez les traces une à une et annotez les erreurs (codage ouvert). Demandez à un expert du domaine d’inspecter les exécutions de l’agent et de rédiger de courtes observations sur ce qui a mal tourné. Concentrez-vous sur la première erreur significative.
- Regroupez les observations en modes de défaillance (codage axial). Une fois que vous avez suffisamment de notes, utilisez un LLM pour proposer des catégories d’erreurs similaires. Il pourrait s’agir de recommandations de pièces incompatibles, de récupérations inexactes des données d’inventaire ou de transferts ratés vers un humain.
- Comptez les occurrences. Associez chaque observation à une catégorie, puis utilisez une feuille de calcul ou un tableau croisé dynamique pour calculer la fréquence de chaque mode de défaillance.
- Établissez les priorités, en tenant compte à la fois de la fréquence et de la gravité.
- Transformez les défaillances importantes en cas de test. Enregistrez l’entrée pertinente, les conditions de départ, le résultat attendu et les critères de correction afin de pouvoir tester l’agent de nouveau dans le même scénario.
Combien de traces faut-il examiner? Environ 100, mais il n’y a pas de chiffre magique. Arrêtez-vous plus tôt dès que vous atteignez la saturation théorique : le point où l’examen de traces supplémentaires ne révèle plus de nouveaux schémas de défaillance significatifs.
Vous n’avez pas encore lancé l’application? Des exemples synthétiques peuvent aider à constituer un premier jeu de tests, mais les données d’utilisateurs réels devraient l’alimenter dès qu’elles sont disponibles.
L’utilisation des bancs d’essai dans l’évaluation des agents d’IA
En plus de créer vos propres cas de test, vous pouvez utiliser des collections existantes de tâches d’évaluation standardisées, appelées bancs d’essai (benchmarks), pour évaluer les capacités d’un agent.
Mais les bancs d’essai ne sont pas infaillibles. Les audits de SWE-bench, les examens des bancs d’essai d’Epoch AI et les bonnes réponses initialement rejetées dans TheoPhysEval montrent comment des tâches ou des réponses attendues erronées peuvent fausser les résultats d’évaluation.
Comme le conseille Khomutov, choisissez des bancs d’essai à jour et pertinents pour votre domaine, et examinez les réussites ou les échecs surprenants avant de considérer les scores comme une preuve fiable de la performance de l’agent.
Étape 3. Exécuter l’agent dans un environnement de test reproductible
Un environnement de test reproductible est une configuration contrôlée dans laquelle vous pouvez exécuter un agent d’IA sur les mêmes cas de test, dans les mêmes conditions de départ, et comparer les résultats. Il peut s’agir d’un dossier de cas de test, d’un script Python qui exécute l’agent ou d’un ensemble de vérifications qui évaluent les résultats.
Vous pouvez commencer par stocker des entrées représentatives dans des fichiers JSON et utiliser un script Python pour exécuter le flux de travail de votre agent et vérifier ses sorties à l’aide d’assertions. Pour l’agent d’inventaire de notre usine de fabrication, un environnement de test reproductible pourrait ressembler à ceci :
Pour mettre en place un environnement de test reproductible, suivez ces étapes :
- Enregistrez des entrées représentatives. Stockez des événements réels ou des cas de test dans la même structure que celle que votre application reçoit en production. Dans notre scénario, vous enregistreriez sous forme de fichier JSON une demande d’entretien contenant l’identifiant de la machine, la pièce de rechange requise et la date d’entretien, ainsi qu’un instantané des données d’inventaire et des pièces approuvées.
- Exécutez le flux de travail. Faites passer chaque entrée par l’agent, y compris ses étapes de récupération, ses appels d’outils et la génération de sa réponse.
- Enregistrez le résultat et la trace. Consignez la sortie finale et les actions intermédiaires pertinentes (comme les consultations de l’inventaire) afin de voir non seulement si l’agent a échoué, mais aussi à quel endroit.
- Répétez les cas en fonction de la gravité et de la fréquence des défaillances, ainsi que de la difficulté à corriger le problème. Les applications de LLM sont non déterministes (elles peuvent produire des résultats différents à partir d’entrées identiques); une exécution réussie ne garantit donc pas que la suivante le sera aussi. Indiquez la proportion d’essais réussis et examinez les échecs.
Pour ce dernier point, Khomutov conseille de mesurer le pass@1 (la fréquence à laquelle l’agent réussit en une seule tentative) et le pass@k (la probabilité de réussir au moins une fois sur un nombre donné de tentatives). Si vous indiquez le pass@k, précisez le nombre de tentatives, car produire une bonne réponse parmi plusieurs ne signifie pas que l’agent sait laquelle choisir.
À mesure que votre application prend de l’ampleur, utilisez un cadre de test comme pytest pour organiser et exécuter les tests, et envisagez de stocker les grands jeux de données de test et les résultats dans une base de données.
Étape 4. Choisir le bon correcteur pour chaque vérification
Un correcteur (aussi souvent appelé évaluateur) est un mécanisme — un fragment de code, un LLM guidé par une grille de correction ou un réviseur humain — qui vérifie une sortie ou une action de l’agent par rapport à un critère défini. Un correcteur renvoie un verdict réussite/échec et une explication qui indique les éléments probants pertinents.
Info : Une grille de correction est un ensemble de critères et d’instructions qui définissent ce qui constitue un résultat correct ou acceptable.
Le type de correcteur approprié dépend de ce que vous cherchez à vérifier. Voici comment se comparent les trois approches :
Correcteur | Idéal pour | Exemple | Principale limite |
Basé sur le code | Conditions exactes et vérifiables | La pièce de rechange recommandée figurait-elle sur la liste de compatibilité approuvée? | Ne peut pas évaluer de façon fiable toutes les décisions subjectives |
LLM comme juge | Évaluations qui dépendent du contexte | L’agent a-t-il expliqué pourquoi il ne pouvait pas recommander de pièce de remplacement? | Ses jugements peuvent être erronés ou incohérents |
Humain | Expertise propre au domaine et cas incertains | Le gestionnaire de l’entretien juge-t-il la recommandation de l’agent appropriée? | Coûteux à appliquer à grande échelle |
Il arrive que différents aspects d’une même exécution nécessitent des méthodes d’évaluation différentes; vous devrez donc peut-être combiner plusieurs correcteurs.
Comment combiner les correcteurs?
Posez-vous la question : « Le résultat peut-il être vérifié par rapport à une règle connue ou à une valeur attendue, ou exige-t-il un jugement de type humain? »
- Si vous pouvez vérifier le résultat de façon exacte, commencez par un correcteur basé sur le code. Les correcteurs basés sur le code peuvent aussi vérifier des sorties structurées, des valeurs de champs valides, des arguments d’outils ou l’état final d’une base de données.
- Si la vérification exige d’interpréter le contexte, utilisez l’approche LLM comme juge.
- Faites appel à des réviseurs humains pour les décisions propres à un domaine ou contestées.
Important! Un correcteur LLM peut mal interpréter les éléments probants ou appliquer une grille de façon incorrecte. Il lui faut alors une étape d’évaluation supplémentaire : le calibrage par rapport à des jugements humains.
Calibrez le correcteur LLM par rapport à des jugements humains.
Pour l’essentiel, le calibrage exige qu’un expert du domaine évalue des exécutions réelles de l’agent. L’expert compare ensuite ses jugements avec ceux du LLM et peaufine la grille de correction en fonction des désaccords.
Voici un processus de calibrage du correcteur en cinq étapes :
- Recueillez des exemples d’entrées et de sorties de l’agent, ainsi que les traces pertinentes.
- Demandez à un expert du domaine d’évaluer de façon indépendante si chaque exemple satisfait au critère d’évaluation.
- Exécutez le correcteur LLM sur ces exemples.
- Comparez les jugements humains à ceux du modèle.
- Examinez les désaccords et peaufinez la grille du correcteur avant de le tester sur de nouveaux exemples.
Khomutov insiste également sur l’importance de tester séparément la constance du correcteur LLM :
« Donnez-lui plusieurs fois exactement la même exécution enregistrée et les mêmes fichiers, sans réexécuter l’agent. Cela vous permet de distinguer la variation dans le travail de l’agent de la variation dans la correction. »
Si une même sortie obtient des verdicts différents, ne présumez pas que chaque variation de score vient de l’agent. Examinez plutôt une matrice de confusion qui montre quand le correcteur a correctement repéré des erreurs, quand il les a manquées et quand il a signalé à tort des sorties acceptables.
La révision humaine demeure essentielle pour établir des jugements de référence, trancher les cas contestés et découvrir de nouveaux modes de défaillance que les correcteurs existants n’ont pas été conçus pour détecter.
Étape 5. Comparer les versions et effectuer des vérifications de régression
Supposons que l’analyse des erreurs révèle que votre agent d’inventaire recommande souvent des pièces de remplacement non approuvées. Vous modifiez son invite système pour exiger une vérification explicite de la compatibilité. Le cas qui échouait au départ réussit maintenant. Mais comment savoir si ce changement n’a pas eu d’incidence sur d’autres tâches?
C’est là qu’interviennent les tests de régression.
Les tests de régression consistent à réexécuter des cas de test qui réussissaient auparavant après avoir modifié l’invite, le modèle ou le flux de travail d’un agent, afin de s’assurer que le changement n’a pas introduit de nouvelles défaillances.
- Reproduisez la défaillance initiale à l’aide d’une entrée enregistrée du jeu de tests.
- Apportez une modification ciblée à l’invite, au modèle ou au flux de travail.
- Réexécutez le test qui échouait pour vérifier si le problème est résolu.
- Exécutez les autres tests pour vérifier que la modification n’a pas compromis des comportements qui fonctionnaient auparavant.
- Examinez les résultats et analysez toute nouvelle défaillance.
Comparez l’agent de référence et l’agent mis à jour à l’aide des mêmes cas de test et des mêmes critères de notation pour obtenir des résultats fiables.
Étape 6 : surveiller la performance de l’agent IA en production
L’évaluation d’un agent ne s’arrête pas une fois l’application déployée. Comme l’expliquent Husain et Shankar, les évaluateurs que vous utilisez pendant le développement peuvent aussi être exécutés sur de vraies données de production afin de mesurer la performance de votre agent au fil du temps.
C’est ce qu’on appelle l’évaluation en ligne, qui constitue l’un des volets d’un processus plus large de surveillance de la production permettant de révéler des défaillances récurrentes ou jusque-là inconnues.
Ce processus est itératif et comprend quatre activités complémentaires :
- Exécutez des juges LLM calibrés sur les traces de production. Échantillonnez de vraies interactions de l’agent et appliquez-leur les évaluateurs que vous avez déjà validés par rapport à des jugements humains.
- Suivez l’évolution des taux d’échec. Utilisez les catégories de défaillances établies lors de l’analyse des erreurs pour quantifier les problèmes récurrents.
- Continuez d’examiner les traces manuellement. Les évaluateurs automatisés ne détectent que les problèmes qu’ils sont conçus pour repérer. Examinez manuellement des échantillons d’interactions réelles de l’agent pour découvrir de nouvelles erreurs ou des demandes inhabituelles des utilisateurs.
- Utilisez des tests A/B pour mesurer les résultats d’affaires (seulement lorsque c’est pertinent). Comparez différentes invites, différents modèles ou différents flux de travail à l’aide d’indicateurs comme le taux d’achèvement des tâches, la satisfaction des utilisateurs et le délai de résolution. Ce processus aide à déterminer si une modification améliore réellement l’expérience produit, au-delà de la simple réussite de tests individuels.
Une remarque importante : les évaluations n’ont pas besoin d’être peaufinées à la perfection. Elles doivent simplement être assez bonnes pour améliorer votre produit.
Idées reçues courantes sur l’évaluation des agents IA
- Les évaluations ne sont que des tests unitaires. C’est faux. Les tests unitaires sont de petites vérifications automatisées qui ne constituent qu’une partie de l’évaluation. Les évaluations comprennent aussi l’analyse qualitative des erreurs, les jugements humains, la surveillance de la production et des expériences visant à mesurer la qualité de l’application.
- Une plateforme d’évaluation peut tout faire à votre place. Les outils prêts à l’emploi peuvent automatiser certaines vérifications, mais ils ne peuvent pas déterminer quels modes de défaillance (types d’erreurs ou comportements indésirables de l’agent) comptent pour votre produit.
- Vous pouvez laisser un LLM tout évaluer. C’est une grave erreur. L’analyse des erreurs menée par des humains et le calibrage des évaluateurs restent essentiels, car les LLM n’ont pas le contexte d’affaires nécessaire pour découvrir tous les problèmes.
- Les tests A/B ou la simple utilisation de l’agent remplacent les évaluations. Faux. Les tests A/B peuvent montrer quelle version obtient de meilleurs résultats selon les indicateurs choisis, mais ils ne peuvent pas, à eux seuls, expliquer les problèmes sous-jacents.
FAQ sur l’évaluation des agents IA
1. Quelle est la différence entre l’évaluation des agents IA et l’évaluation des LLM?
L’évaluation des LLM mesure la capacité d’un modèle de langage à accomplir une tâche donnée, comme répondre à une question, résumer un document ou extraire de l’information. L’évaluation des agents IA porte sur un système qui exécute de façon autonome plusieurs étapes pour accomplir une tâche.
Contrairement à une évaluation de LLM classique, l’évaluation d’un agent examine à la fois le résultat final et la séquence d’actions effectuées pour y parvenir, y compris les appels d’outils, les décisions et le respect des règles prédéfinies.
2. Principaux indicateurs pour l’évaluation des agents IA
Les indicateurs d’évaluation des agents IA se répartissent en deux grandes catégories :
- Indicateurs de performance technique : taux de réussite des tâches, exactitude des actions, qualité des réponses, fiabilité (pass@1 et pass@k), latence, utilisation des jetons et coût par tâche réussie.
- Indicateurs d’affaires et d’expérience utilisateur : satisfaction de la clientèle (CSAT), taux de résolution des problèmes, taux d’escalade, taux de conversion, durée d’exécution des tâches et autres résultats propres au rôle de l’agent.
Par exemple, un agent de soutien à la clientèle pourrait être évalué sur la résolution réussie des problèmes et la satisfaction de la clientèle, tandis qu’un agent d’achat IA pourrait être mesuré selon l’exactitude des demandes de réapprovisionnement, les taux d’approbation et la durée du cycle d’approvisionnement.
Les bons indicateurs doivent refléter à la fois la fiabilité de l’agent et la mesure dans laquelle son travail améliore les résultats d’affaires.
3. Quels sont les meilleurs outils pour évaluer les agents IA?
Parmi les options courantes, on trouve :
- Cadriciels de test : les assertions Python et pytest sont utiles pour exécuter des cas de test reproductibles et vérifier des conditions précises, par exemple si un agent a sélectionné le bon outil ou renvoyé un identifiant de pièce valide.
- Cadriciels d’évaluation d’agents IA : DeepEval et la boîte à outils agent-eval de Google permettent des évaluations plus complexes, notamment au moyen de traces d’exécution, d’évaluateurs basés sur des LLM et de tests de régression automatisés.
- Plateformes d’évaluation et d’observabilité : LangSmith, Arize Phoenix et MLflow aident les équipes à examiner le comportement des agents, à gérer les jeux de données d’évaluation, à comparer les versions des agents et à surveiller leur performance en production.
4. Comment automatiser l’évaluation des agents IA?
Vous pouvez automatiser l’évaluation des agents IA en créant des tests reproductibles, en appliquant des évaluateurs automatisés et en intégrant ces vérifications à vos flux de travail de développement et de production :
- Créez un jeu de données d’évaluation : recueillez des tâches utilisateur représentatives, les résultats attendus, les défaillances connues et les traces d’exécution de l’agent. Incluez des cas limites comme des appels d’outils échoués, des informations manquantes et des actions non autorisées.
- Automatisez l’exécution des tests et la notation : utilisez des cadriciels comme pytest ou DeepEval pour exécuter les cas de test et appliquer des vérifications basées sur le code ou des évaluateurs LLM. Validez les évaluateurs LLM par rapport à des jugements humains avant de vous fier à leurs notes.
- Intégrez les évaluations à votre processus CI/CD : relancez automatiquement les tests de régression lorsque les développeurs modifient les invites, les modèles, les outils ou le flux de travail d’un agent. Comparez les résultats à une référence et établissez des seuils de qualité qui bloquent les mises en production lorsque des vérifications critiques échouent.
- Appliquez des évaluateurs calibrés à des échantillons de traces de production, suivez les taux d’échec et d’autres indicateurs de performance, et analysez les nouvelles erreurs au moyen d’un examen manuel.