Évaluer un agent IA en production : pourquoi les traces comptent
Un taux de réussite moyen cache les erreurs de parcours d'un agent IA. Cette méthode relie traces, preuves de résultat, coût et fiabilité pour comparer des versions sans se laisser tromper par un score unique.
Un agent IA ne se contente pas de produire du texte. Il planifie, appelle des outils, lit des données et modifie parfois un système métier. Pour l'évaluer, le résultat final ne suffit donc pas. Deux agents peuvent afficher la même réponse, alors que l'un a utilisé la bonne source et l'autre a contourné la tâche ou profité d'un défaut du test.
Cet article propose une méthode de recherche appliquée : conserver la trace complète d'un épisode, exiger une preuve du résultat, classer les échecs et publier une courbe de qualité contre coût et latence. L'objectif est une mesure reproductible avant et après un changement de modèle, de prompt ou d'outil.
Réponse en bref
Évaluez un agent sur des scénarios représentatifs, avec un état initial connu et un oracle indépendant. Enregistrez les étapes, appels d'outils, observations, validations et arrêts. Donnez trois sorties au lieu d'un seul score : succès prouvé, échec prouvé et résultat inconnu. Rapportez ensuite la qualité par scénario, le coût, la latence, les violations de politique et la stabilité entre répétitions.
Schéma Nexxom. Une trace devient une mesure seulement lorsqu'elle est reliée à une preuve de résultat et à une règle de décision publiée.
Pourquoi le score moyen est insuffisant
Un benchmark interactif transforme souvent une trajectoire complexe en succès ou échec. Cette réduction est pratique, mais elle peut masquer une vérification trop faible. Le papier Can Agent Benchmarks Support Their Scores? montre qu'un contrôle qui vérifie seulement un clic ou un bouton peut annoncer un succès sans prouver que le bon état métier a été atteint. Les auteurs proposent de distinguer Evidence Pass, Evidence Fail et Unknown.
Le problème se rencontre aussi dans les évaluations de sécurité. AgentDojo utilise 97 tâches réalistes et 629 cas de test pour observer des agents qui appellent des outils sur des données non fiables. Un score global ne dit pas si l'agent a échoué à la tâche, résisté à l'injection ou simplement arrêté avant l'action dangereuse.
Enfin, un agent peut optimiser la métrique au lieu de l'objectif. Le Centre for AI Standards and Innovation de NIST documente des cas de contamination par des solutions accessibles sur Internet et de manipulation du grader. Une trace permet de repérer ces comportements, alors qu'un nombre final les confond avec une amélioration réelle.
Ce qu'il faut capturer dans une trace
Une trace utile est un journal structuré, pas une copie brute de la conversation. Chaque événement doit conserver un identifiant d'épisode, un horodatage, un type et une relation avec l'étape précédente. Les données sensibles doivent être masquées avant stockage.
| Élément | Question de mesure | Exemple de champ |
|---|---|---|
| Contexte | Quelle version et quelles permissions étaient actives ? | model, prompt_version, policy_version, principal |
| Action | Quel outil l'agent a-t-il appelé et avec quels paramètres ? | tool_name, arguments_hash, authorization_decision |
| Observation | Quelle donnée a été renvoyée ? | source_id, retrieval_score, content_hash |
| Vérification | Quelle règle a validé ou rejeté l'étape ? | check_id, verdict, evidence_refs |
| Fin | Quel état réel a été atteint ? | state_before, state_after, stop_reason |
Ne journalisez pas automatiquement la chaîne de pensée privée d'un modèle. Pour la reproductibilité, les événements d'outil, les entrées et sorties utiles, les preuves et les décisions de contrôle suffisent généralement. Le guide NIST AI 800-2 insiste sur la description du protocole, des tentatives, des retours et des conditions de l'évaluation.
Le protocole en six étapes
1. Définir l'épisode et l'état attendu
Commencez par une action métier observable, par exemple créer un ticket avec la bonne priorité ou répondre à une demande en citant la politique interne. Décrivez l'état initial, les permissions et la définition de réussite avant d'exécuter l'agent. Un scénario doit avoir une fin vérifiable, pas seulement une phrase jugée convaincante.
2. Construire une matrice de cas
Échantillonnez les cas faciles, ambigus, longs et adversariaux. Gardez un jeu de test gelé et un jeu de développement séparé. WebArena et BrowserGym montrent l'intérêt d'environnements où l'agent doit naviguer dans un état applicatif plutôt que répondre à une question isolée. Pour une entreprise, remplacez progressivement les tâches publiques par des scénarios internes anonymisés.
3. Figer les variables de comparaison
Pour comparer deux versions, conservez le même modèle de tâche, le même contexte, les mêmes outils, la même limite de temps et la même politique. Si un changement touche plusieurs variables, créez une condition expérimentale distincte. Répétez chaque cas avec des graines ou des conditions contrôlées, puis publiez le nombre d'essais et les exclusions.
4. Vérifier la preuve du résultat
Associez à chaque tâche un oracle : état de base de données, test automatisé, document de référence ou double annotation humaine. Un juge linguistique peut aider à trier, mais il ne doit pas être la seule preuve pour une action critique. Le projet NIST Building Evaluation Probes into Agentic AI propose des sondes qui relient une affirmation à des documents fiables et conservent une piste d'audit.
5. Classer les échecs par étape
Une taxonomie simple sépare planification, sélection d'outil, autorisation, observation, exécution, vérification et communication. Un agent qui a choisi le bon outil mais reçu une donnée périmée n'a pas le même défaut qu'un agent qui a ignoré une interdiction. Cette granularité rend la correction actionnable et évite de changer de modèle quand le problème vient du connecteur.
6. Publier des bornes et non une illusion de précision
Calculez le taux de succès prouvé sur les cas Evidence Pass. Rapportez séparément Evidence Fail et Unknown, puis fournissez un intervalle ou des bornes si l'échantillon est petit. Ajoutez le coût par épisode, la latence p50 et p95, le nombre d'appels d'outils, les violations de politique et le taux d'abstention.
| Mesure | Formule opérationnelle | Décision éclairée |
|---|---|---|
| Succès prouvé | Evidence Pass / épisodes évalués | Peut-on confier cette tâche ? |
| Incertitude | Unknown / épisodes évalués | Faut-il améliorer l'oracle ? |
| Efficacité | coût total / succès prouvé | Le gain vaut-il sa dépense ? |
| Robustesse | succès sans violation / épisodes | Le système reste-t-il sûr ? |
| Stabilité | dispersion des résultats par répétition | Le résultat est-il reproductible ? |
Lire une trace sans surinterpréter
Une trace se lit de la sortie vers la cause. Vérifiez d'abord l'état final, puis remontez à la preuve, à l'appel d'outil et à l'autorisation. Cherchez les divergences entre ce que l'agent dit avoir fait et ce que les journaux confirment. Cette revue peut être automatisée pour le tri, mais les règles et un échantillon humain doivent rester documentés.
NIST décrit dans Analyzing Transcripts from AI Agent Evaluations un processus itératif : préparer les journaux, écrire une grille, valider un scanner sur des exemples connus, puis analyser à grande échelle. La recommandation pratique est de conserver les traces d'un échantillon représentatif, même lorsque les coûts imposent de ne pas tout publier.
Le risque de triche doit être explicitement testé. La page NIST sur les pratiques de détection recommande la revue de transcripts, des règles d'environnement explicites et une description reproductible des affordances. Interdisez, par exemple, l'accès aux solutions et enregistrez les requêtes réseau durant l'épisode si la tâche le requiert.
Exemple de tableau de décision
| Observation sur les traces | Interprétation prudente | Action suivante |
|---|---|---|
| Score élevé, preuve inconnue | Le grader ne mesure pas encore l'état final | Renforcer l'oracle et recalculer |
| Bon résultat, coût et p95 en hausse | Le modèle réussit mais devient difficile à opérer | Ajouter un budget et une règle d'arrêt |
| Échecs concentrés sur un outil | Le défaut est probablement dans le connecteur ou ses permissions | Tester l'outil seul puis l'agent |
| Réussite variable entre répétitions | La stratégie est instable ou le scénario sous-spécifié | Réduire l'aléa, enrichir le contexte, répéter |
| Violation rare mais grave | La moyenne masque un risque de queue | Bloquer la mise en production et ajouter un test adversarial |
Limites et garde-fous
Les traces ne prouvent pas tout. Un événement peut être manquant, falsifié ou trop coûteux à conserver. Les journaux peuvent aussi exposer des données personnelles, des secrets ou des informations de sécurité. Définissez une politique de rétention, hachez les identifiants, séparez les preuves sensibles et contrôlez qui peut relire les épisodes.
Un oracle parfait est rare. Un test automatisé peut vérifier un état mais rater une conséquence métier. Une annotation humaine peut comprendre le contexte mais introduire un désaccord. Documentez les versions de l'oracle, mesurez son accord et marquez les cas ambigus comme Unknown plutôt que de les forcer en succès.
La comparaison ne doit pas devenir un classement permanent. Un agent évolue avec ses outils, ses données et ses règles. Conservez une suite de régression versionnée et relancez-la à chaque changement significatif. Le survey sur l'évaluation des agents LLM rappelle que capacités, comportement, fiabilité et sécurité sont des objectifs différents qui exigent des protocoles distincts.
Méthode Nexxom pour une décision de mise en production
Pour un premier pilote, choisissez dix à trente épisodes représentatifs, définissez un oracle pour chacun, puis capturez une trace minimale. Rejetez toute condition où la preuve est absente. Comparez deux versions sur le même jeu gelé et publiez le tableau Evidence Pass, Evidence Fail, Unknown, coût et p95. Ensuite, ajoutez un scénario adversarial et une revue humaine aveugle des traces.
Cette séquence donne une décision plus utile qu'un score moyen : elle indique si le système est prêt pour une tâche donnée, pourquoi il échoue et quel investissement réduira le risque. C'est cette articulation entre recherche, instrumentation et ingénierie qui permet à Nexxom de transformer une démonstration d'agent en système exploitable.
Sources et lectures primaires
- Can Agent Benchmarks Support Their Scores?, 2026.
- AgentDojo, 2024.
- WebArena, 2023.
- BrowserGym, 2024.
- NIST AI 800-2, projet 2026.
- NIST Building Evaluation Probes, 2026.
- NIST transcript analysis, 2026.
- NIST cheating evaluations, 2025.
- NIST practices for transcript review, 2025.
- HELM evaluation framework, Stanford CRFM.
- Inspect AI, UK AI Security Institute.
- LLM agent evaluation survey, 2025.
