Évaluer un agent LLM — méthodes et pièges

En bref

Un agent LLM ne renvoie pas une réponse : il exécute une séquence d’étapes, appelle des outils, prend des décisions intermédiaires. Évaluer ce comportement dépasse largement le test unitaire classique. Les approches disponibles — métriques de trajectoire, LLM-as-a-Judge, monitoring continu, spécifications formelles — répondent à des questions différentes et comportent chacune des angles morts.

En clair : tester une fonction Python, c’est lui passer une entrée et vérifier la sortie. Tester un cuisinier, c’est différent : on vérifie le plat final, mais aussi la propreté du plan de travail, l’ordre des préparations, le temps total, la cohérence entre intention et exécution. L’évaluation d’agents fait pareil. Elle observe la trajectoire (quels outils, dans quel ordre), la qualité du livrable, et la dérive dans le temps. Aucune méthode unique ne couvre les trois axes.

Pourquoi l’évaluation agentic est un problème distinct

Un test logiciel classique vérifie une sortie déterministe à partir d’une entrée fixe. Un agent opère dans un environnement dynamique et probabiliste : la même requête peut produire des chemins d’exécution différents selon l’état des outils, la mémoire disponible ou la formulation du contexte. La performance peut se dégrader progressivement sans qu’aucune erreur explicite ne soit levée.

Trois propriétés rendent l’évaluation agentic structurellement différente :

• Non-déterminisme : l’agent choisit ses outils et l’ordre de ses actions à chaque exécution.
• Opacité intermédiaire : l’erreur peut survenir à n’importe quelle étape, pas seulement en sortie finale.
• Dérive temporelle : la distribution des données d’entrée change, les APIs externes évoluent, les performances se dégradent sans signal d’alerte clair.

“Evaluating intelligent agents goes beyond traditional tests to continuously measure their effectiveness, efficiency, and adherence to requirements in real-world environments.” — Gulli et al. (2025), Ch.19

Métriques de trajectoire : comparer le chemin réel au chemin idéal

La trajectoire d’un agent est la séquence des étapes qu’il exécute pour atteindre un objectif. L’évaluation par trajectoire compare ce chemin réel à un chemin de référence (expected tool trajectory) défini lors de la création des cas de test.

Trois niveaux de rigueur sont utilisables selon le contexte :

Un format de cas de test typique inclut : la requête utilisateur, la trajectoire attendue, les réponses intermédiaires de référence, et la réponse finale attendue.

Limite principale : définir la trajectoire idéale suppose de connaître à l’avance le comportement correct. Pour des tâches ouvertes ou créatives, cette référence est difficile à établir et peut sur-contraindre des comportements alternatifs valides.

En clair : la métrique de trajectoire est l’équivalent d’une fiche de check-up médical. “Le médecin a-t-il mesuré la tension ? La température ? L’a-t-il fait dans l’ordre habituel ?” Si oui, l’examen est conforme. Cette grille marche bien quand le bon protocole est connu. Elle bloque quand il y a plusieurs façons valables de résoudre le problème.

LLM-as-a-Judge : évaluation qualitative par un modèle évaluateur

Certaines dimensions — pertinence, clarté, utilité, absence de biais — ne se réduisent pas à une comparaison avec une référence fixe. LLM-as-a-Judge utilise un modèle de langage comme évaluateur : il reçoit la sortie de l’agent et une rubrique structurée, puis produit des scores et une justification.

Une rubrique typique définit plusieurs critères (ex. : exhaustivité, exactitude factuelle, ton, absence d’hallucination), chacun noté sur une échelle (1-5), avec demande de justification et sortie JSON structurée pour faciliter l’agrégation.

Forces :

• Capable d’évaluer des sorties textuelles complexes sans référence manuelle.
• Scalable : s’applique à des milliers de sorties sans annotation humaine systématique.
• Flexible : la rubrique s’adapte au domaine (juridique, médical, technique).

Limites :

• Le modèle évaluateur hérite des biais du modèle évalué si les deux partagent la même base d’entraînement.
• La rubrique doit être calibrée empiriquement : une rubrique vague produit des scores peu exploitables.
• Le coût d’inférence s’ajoute à celui de l’agent évalué.
• Résultats non reproductibles si la température de l’évaluateur n’est pas fixée.

Monitoring continu et dérive

Un agent en production ne se comporte pas comme un agent en développement. La dérive (drift) désigne la dégradation progressive de la performance due à des changements dans la distribution des entrées, les mises à jour des APIs, ou l’évolution du contexte utilisateur.

Le monitoring continu enregistre de façon structurée, à chaque interaction : latence, nombre de tokens consommés, outils appelés, résultat final, erreurs levées. Ces données alimentent des systèmes persistants (logs JSON, bases de séries temporelles, plateformes d’observabilité) qui permettent de détecter les anomalies par comparaison avec une baseline.

Métriques courantes à surveiller :

• Latence par étape : détecter les goulots d’étranglement et les appels d’outils anormalement lents.
• Taux d’erreur par type : distinguer erreurs d’outil, erreurs de raisonnement, timeouts.
• Distribution des trajectoires : une trajectoire qui s’allonge sans justification peut signaler une dégradation.
• Consommation tokens : un agent qui consomme de plus en plus de contexte peut signaler un problème de formulation.

Limite principale : le monitoring détecte les symptômes, pas les causes. Distinguer une dérive du modèle d’un changement légitime du comportement attendu nécessite une interprétation humaine.

Le modèle Contractor : vers des spécifications formelles

Les approches précédentes évaluent après l’exécution. Le modèle Contractor propose une approche différente : intégrer les critères d’évaluation dans la définition même de la tâche, sous forme de contrat formel.

Le contrat spécifie : livrables explicites, périmètre d’action, ressources autorisées, critères de validation. Il repose sur quatre piliers :

1. Spécification formelle : le contrat est la source de vérité unique. Pas d’ambiguïté sur ce qui constitue un succès.
2. Négociation avant exécution : l’agent dialogue avec l’utilisateur pour clarifier le contrat avant de commencer.
3. Exécution itérative avec auto-validation : l’agent génère, révise, améliore en boucle jusqu’à satisfaire les critères du contrat.
4. Décomposition hiérarchique : les tâches complexes sont fractionnées en sous-contrats assignables, chacun vérifiable indépendamment.

“The contractor framework reimagines AI interaction by embedding principles of formal specification, negotiation, and verifiable execution directly into the agent’s core logic.” — Gulli et al. (2025), Ch.19

Forces : réduit l’ambiguïté, permet l’auditabilité, facilite la décomposition d’orchestrations complexes.

Limites : la spécification formelle suppose que l’utilisateur sache définir précisément ce qu’il veut — ce qui n’est pas toujours le cas. La phase de négociation ajoute de la latence. Le modèle est moins adapté aux tâches exploratoires où les critères de succès émergent au cours de l’exécution.

Évaluation des systèmes multi-agents

Quand plusieurs agents collaborent, l’évaluation s’étend à la coordination. Quatre questions structurent cette évaluation :

1. Coopération : l’information passe-t-elle correctement d’un agent à l’autre ?
2. Respect du plan : le système suit-il la décomposition prévue sans bloquer ?
3. Routage : le bon agent est-il sélectionné pour la bonne tâche ?
4. Scalabilité : ajouter un agent améliore-t-il ou dégrade-t-il les performances globales ?

“You can examine how well each individual agent performs its specific job, but you must also evaluate how the entire system is performing as a whole.” — Gulli et al. (2025), Ch.19

Un système multi-agents peut réussir chaque évaluation individuelle tout en échouant collectivement. L’évaluation bout-en-bout reste indispensable.

Matrice de décision : quelle méthode d’évaluation choisir

Ce qu’il faut retenir

• Les métriques de trajectoire (exact, in-order, any-order match) offrent une évaluation objective mais supposent une référence préalablement définie.
• LLM-as-a-Judge couvre les dimensions qualitatives mais hérite des biais du modèle évaluateur et exige une rubrique calibrée.
• Le monitoring continu détecte la dérive en production ; il ne remplace pas une évaluation structurée en développement.
• Le modèle Contractor intègre les critères de succès dans la spécification de la tâche — efficace pour les contextes critiques, moins adapté aux tâches ouvertes.
• En multi-agents, l’évaluation individuelle ne suffit pas : la coordination et la scalabilité du système doivent être testées séparément.