Comment évaluer un agent d’IA ? Tâches, trajectoires, fiabilité et coût

Évaluer un agent d’IA consiste à vérifier s’il accomplit de manière fiable des tâches représentatives, suit des parcours acceptables, respecte ses limites et apporte une valeur suffisante au regard de son coût. Une réponse finale ne suffit pas : un agent peut parvenir à un résultat plausible en prenant des mesures dangereuses, en avançant des affirmations non étayées, en multipliant excessivement les nouvelles tentatives ou simplement par chance.

L’évaluation des agents est difficile, car le système agit au fil du temps. Le modèle choisit des outils, observe des environnements qui évoluent et peut emprunter un parcours différent à chaque exécution. Les évaluations efficaces mesurent donc les résultats et les trajectoires sur plusieurs essais.

Le vocabulaire de l’évaluation des agents

Le guide d’Anthropic pour mieux comprendre l’évaluation des agents propose un ensemble de termes utiles :

• Tâche : un cas de test comportant un objectif, un environnement, des entrées et des critères de réussite.
• Essai : une tentative de l’agent pour accomplir une tâche.
• Transcription ou trajectoire : la séquence de messages, de décisions, d’appels d’outils, d’observations et d’actions au cours de l’essai.
• Évaluateur : une règle, un programme, un modèle ou une personne qui note une partie des performances.
• Dispositif d’évaluation : le système qui prépare les environnements, exécute les essais, recueille les traces, fait appel aux évaluateurs et rend compte des résultats.

Distinguer ces notions permet d’éviter une erreur fréquente : considérer une seule démonstration réussie comme la preuve que l’agent sera fiable.

Commencer par définir clairement la tâche

Une tâche d’évaluation utile décrit l’état initial, les outils disponibles, les contraintes, le résultat attendu et les comportements importants qui sont interdits. Le test doit ressembler à une situation de travail réelle sans imposer un parcours unique préétabli.

Pour un agent d’assistance, « résoudre le ticket » est trop vague. Une tâche mieux définie précise le dossier du client, la politique applicable, les solutions autorisées, les communications requises et les modifications qui doivent apparaître dans le système de référence. Il est alors possible de l’évaluer de manière objective.

Les quatre niveaux de l’évaluation des agents

Ces niveaux doivent rester distincts dans les rapports. Les regrouper en une seule moyenne peut masquer des comportements inacceptables, par exemple un score élevé de réussite des tâches qui dissimule des tentatives fréquentes d’utilisation non autorisée d’outils. Les équipes peuvent d’abord définir des seuils de sécurité impératifs, puis comparer la qualité des résultats et l’efficacité des essais qui satisfont à ces seuils.

1. Qualité des résultats

L’agent a-t-il atteint l’objectif ? Les évaluateurs des résultats peuvent vérifier les changements exacts apportés à l’état du système, les champs requis, les résultats des tests, l’exactitude factuelle, l’étayage des citations ou la qualité au regard d’une grille d’évaluation.

Dans la mesure du possible, évaluez l’état final de l’environnement plutôt que les affirmations de l’agent. Un agent de programmation n’a pas réussi simplement parce qu’il affirme avoir corrigé le bogue : les tests pertinents et le comportement du système doivent le confirmer.

2. Qualité de la trajectoire

L’agent a-t-il suivi un parcours approprié ? L’évaluation de la trajectoire peut repérer les accès inutiles aux données, l’utilisation d’outils interdits, les échecs répétés, l’absence de vérification, les observations inventées ou les violations des règles d’approbation.

Tout écart par rapport à un parcours de référence n’est pas nécessairement une erreur. Les agents peuvent trouver des solutions valides que les évaluateurs n’avaient pas prévues. Les évaluateurs doivent faire respecter les exigences réelles tout en autorisant d’autres approches efficaces.

3. Sécurité et respect des politiques

L’agent est-il resté dans les limites de son autorité ? Les tests doivent inclure des injections de prompt, des instructions contradictoires, des données sensibles, des intentions ambiguës de la part de l’utilisateur et des demandes nécessitant un refus ou une remontée à un niveau supérieur.

Les évaluations de sécurité doivent prévoir des conséquences réalistes dans un environnement isolé. Une phrase conforme aux politiques ne suffit pas si l’agent a déjà envoyé le message, modifié le dossier ou exposé les données.

4. Efficacité opérationnelle

Combien de temps et d’argent a nécessité la réussite ? Suivez le nombre de jetons utilisés par le modèle, les appels d’outils, la latence réelle, les nouvelles tentatives, les interventions humaines et le coût des services externes. Un agent qui réussit après 100 actions inutiles peut être moins utile qu’un processus plus simple.

Utiliser plusieurs types d’évaluateurs

Les évaluateurs déterministes vérifient des propriétés précises : si un test a réussi, si un fichier a été correctement modifié, si un champ de base de données contient la valeur requise ou si un point de terminaison interdit a été appelé. Ils sont rapides et cohérents, mais ne couvrent que ce que les développeurs ont encodé.

Les évaluateurs fondés sur des modèles évaluent des qualités telles que la clarté, l’exhaustivité, la pertinence et le respect de critères nuancés. Ils peuvent être déployés à plus grande échelle que l’évaluation humaine, mais doivent eux-mêmes être validés, car ils peuvent être biaisés ou manquer de cohérence.

Les évaluateurs humains sont importants pour exercer un jugement expert, traiter les cas ambigus et valider les évaluateurs automatisés. Comme leur travail est plus lent et plus coûteux, les équipes font souvent appel à eux pour examiner des échantillons, trancher les désaccords et évaluer des domaines à fort impact.

Les meilleures suites d’évaluation combinent ces approches. La plateforme Evals d’OpenAI considère elle aussi l’évaluation comme un processus structuré visant à définir des tests et des évaluateurs, puis à mener des expériences répétées, plutôt que comme un examen informel.

La fiabilité exige des essais répétés

Exécutez chaque tâche suffisamment de fois pour observer les variations dues à l’échantillonnage, aux changements d’outils et à l’état de l’environnement. Indiquez à la fois les performances moyennes et la fréquence des échecs graves. Dans les processus composés de plusieurs étapes dépendantes, la précision de chaque étape peut sembler élevée alors que la fiabilité de bout en bout reste faible, car un seul échec suffit à faire dérailler l’ensemble de la tâche.

Le comportement d’un agent est probabiliste. Une même tâche peut produire des plans, des appels d’outils et des résultats différents. Exécutez plusieurs fois chaque tâche importante et indiquez les taux de réussite ou les distributions des scores, plutôt que de présenter uniquement le meilleur exemple.

Deux mesures de fiabilité répondent à des questions différentes :

• Pass@k : probabilité qu’au moins une des k tentatives réussisse. Cette mesure est utile lorsque plusieurs tentatives sont acceptables.
• Pass^k : probabilité que les k tentatives réussissent toutes. Cette mesure reflète la régularité lorsque chaque exécution doit fonctionner.

Un système peut afficher un Pass@k attrayant tout en restant inadapté à un fonctionnement automatique, car ses exécutions individuelles ne sont pas fiables.

Constituer un jeu de tâches représentatif

Commencez par les échecs réels et les demandes courantes en production. Incluez des tâches simples, des cas limites difficiles, des entrées ambiguës, des erreurs d’outils, des données obsolètes, des informations manquantes et des contenus conçus pour induire le système en erreur.

Ventilez les résultats par type de tâche et par niveau de risque. Une moyenne globale peut masquer une faiblesse grave dans les opérations financières, les tâches à long horizon ou une application particulière. Conservez un jeu de données mis à l’écart afin que les ajustements répétés des prompts ne transforment pas la suite d’évaluation en jeu d’entraînement.

Évaluer l’environnement, pas seulement le modèle

Les performances d’un agent dépendent des définitions des outils, des autorisations, de la mémoire, de la gestion du contexte, de l’interface utilisateur, du comportement du réseau et de l’orchestration. Une mise à niveau du modèle peut réduire une erreur tout en en faisant apparaître une autre.

Versionnez l’ensemble de la pile utilisée pour chaque exécution. Consignez le modèle, les prompts, les outils, l’instantané des données, l’environnement, les budgets et les versions des évaluateurs. Sans cela, il est impossible d’attribuer une variation du score à une cause pertinente.

Erreurs courantes dans l’évaluation

Les fuites de données constituent un autre risque. Si les tâches d’évaluation, les réponses attendues ou les schémas utilisés par les évaluateurs figurent dans les données d’entraînement du modèle ou dans le contexte de la requête, le score peut mesurer la reconnaissance plutôt que la capacité de généralisation. Conservez des tâches de test privées, actualisez les cas à mesure que les systèmes évoluent et consignez, pour chaque exécution, le modèle exact, la requête, les versions des outils et l’environnement utilisés.

• Évaluation guidée par les démonstrations : choisir les tâches après avoir observé les points forts de l’agent.
• Évaluation fondée uniquement sur la réponse finale : ignorer les trajectoires dangereuses ou coûteuses.
• Conclusions tirées d’une seule exécution : considérer une réussite due à la chance comme une capacité stable.
• Tests sujets aux fuites : inclure la réponse ou la trajectoire de référence dans le contexte de l’agent.
• Évaluateurs modèles non validés : supposer qu’un juge automatisé a raison sans vérifier sa concordance avec des experts.
• Environnements statiques : tester une seule interface, un seul état de compte ou une seule configuration des données.
• Absence de tests négatifs : mesurer l’accomplissement des tâches sans vérifier si l’agent refuse ou transmet le cas à un niveau supérieur de manière appropriée.
• Négliger les aspects économiques : optimiser la réussite au point de rendre les coûts et la latence inacceptables.

Des évaluations hors ligne au suivi en production

Les évaluations hors ligne sont contrôlées et reproductibles. Elles sont idéales pour comparer les requêtes, les modèles, les outils et les politiques avant leur déploiement. Le suivi en production révèle toute la diversité des comportements réels des utilisateurs et des changements d’environnement.

Un programme mature relie les deux. Les incidents et les traces de production peu fiables deviennent de nouvelles tâches hors ligne. Les modifications envisagées doivent réussir la suite de tests de régression. Après le déploiement, les équipes surveillent la réussite des tâches, les taux d’intervention, les événements liés aux politiques, les erreurs des outils, les coûts, la latence et les commentaires des utilisateurs.

Une grille d’évaluation pratique pour les agents

Une grille d’évaluation doit distinguer les critères éliminatoires des indicateurs d’optimisation. Le respect des politiques, les autorisations et les preuves requises peuvent faire l’objet de critères binaires, avec réussite ou échec ; la précision, la latence, le coût et l’effort de révision peuvent ensuite être comparés entre les exécutions acceptables. Cela évite que les équipes ne sacrifient la sécurité à un léger gain d’efficacité, qu’un score moyen pourrait masquer.

Une grille d’évaluation utile peut inclure :

• le taux de réussite des tâches et le score de qualité ;
• la cohérence des résultats d’un essai à l’autre ;
• le taux de violations critiques des politiques ;
• la précision du choix des outils et de leurs paramètres ;
• le taux de récupération après une défaillance d’un outil ou de l’environnement ;
• le taux de transfert à un humain et de prise de contrôle par un humain ;
• la latence médiane et en queue de distribution ;
• le coût du modèle, des outils et du travail humain par tâche réussie ;
• l’efficacité de la trajectoire par rapport à une référence raisonnable.

Indiquez le coût par tâche réussie, et pas seulement le coût par exécution. Un agent peu coûteux qui échoue à plusieurs reprises peut revenir plus cher qu’un modèle plus performant qui réussit du premier coup.

À retenir sur l’évaluation d’un agent IA

L’évaluation des agents consiste à tester un système complet, orienté vers un objectif, dans des conditions réalistes. Elle mesure si le travail est correct, si la démarche est acceptable, si le comportement est reproductible et si les coûts sont raisonnables.

Commencez par un petit ensemble de tâches importantes, plusieurs essais, des évaluateurs à plusieurs niveaux et des trajectoires complètes. Transformez ensuite chaque défaillance significative en production en test de régression. Les capacités des agents évoluent rapidement ; un système d’évaluation durable permet aux équipes de distinguer les progrès réels d’une démonstration convaincante.