Tester et évaluer un agent

Un agent n'est pas testé comme un script classique

Le comportement d'un agent dépend du modèle sous-jacent, potentiellement non déterministe (la même entrée peut produire des sorties légèrement différentes d'une exécution à l'autre). Tester un agent nécessite des méthodes adaptées à cette variabilité.

Constituer un jeu de tâches de référence

Une pratique courante consiste à constituer un ensemble de tâches représentatives avec un résultat attendu connu (un "eval set"), permettant de mesurer objectivement si des changements (nouveau prompt, nouveau modèle, nouvel outil) améliorent ou dégradent la performance de l'agent.

Exemple de tâche de test :
Entrée : "Le client demande le statut du ticket TICKET-4521"
Résultat attendu : l'agent appelle l'outil rechercher_ticket
avec le paramètre "TICKET-4521", puis formule une réponse
mentionnant le statut réel retourné

Mesurer plus que le résultat final

Évaluer un agent seulement sur sa réponse finale masque des problèmes potentiels : a-t-il utilisé le bon outil ? A-t-il fait des appels inutiles ? A-t-il pris trop d'itérations ? Ces métriques intermédiaires révèlent des inefficacités même quand le résultat final semble correct.

flowchart TD
    A[Tâche de test] --> B[Exécution de l'agent]
    B --> C{Résultat final\ncorrect ?}
    B --> D{Outils appelés\nde façon appropriée ?}
    B --> E{Nombre d'itérations\nraisonnable ?}
    C --> F[Score global de\nl'agent sur cette tâche]
    D --> F
    E --> F

Cas concret

Une équipe teste un agent de support sur 50 tâches représentatives avant de le déployer en production. L'agent obtient un résultat final correct sur 47 des 50 cas, un score en apparence satisfaisant. Une analyse plus fine révèle que sur 15 de ces 47 cas réussis, l'agent a fait des appels d'outils redondants ou inutiles avant d'arriver au bon résultat, un signal d'inefficacité qui aurait été invisible en ne regardant que le taux de réussite final.

Erreurs fréquentes

• Ne tester un agent que sur quelques cas informels avant un déploiement en production, sans constituer un jeu de tests représentatif et reproductible.
• Mesurer uniquement le résultat final, ignorant l'efficacité du chemin emprunté (nombre d'appels d'outils, itérations), une information pourtant utile pour l'optimisation future.
• Croire qu'un agent testé une fois reste valide indéfiniment, sans retester après un changement de modèle, de prompt système, ou d'outils disponibles.

À retenir

• Un agent, potentiellement non déterministe, nécessite un jeu de tâches de référence reproductible pour mesurer objectivement sa performance.
• Évaluer uniquement le résultat final masque des inefficacités (appels d'outils inutiles, itérations excessives) révélées par des métriques plus détaillées.
• Un agent doit être retesté après tout changement significatif (modèle, prompt, outils), sa performance passée ne garantissant pas sa performance future après modification.

Mini-exercice

Un agent obtient un bon taux de réussite final sur un jeu de tests, mais une analyse plus fine révèle de nombreux appels d'outils redondants sur les cas réussis. Ce taux de réussite final suffit-il à juger l'agent prêt pour la production ?

Réponse : pas nécessairement, car les appels redondants signalent une inefficacité (coût, latence, risque accru d'erreur) invisible si l'on ne regarde que le résultat final. Une analyse plus fine du chemin emprunté par l'agent, pas seulement de sa destination, est nécessaire pour une évaluation complète avant déploiement.