Maîtriser l'évaluation des agents d'IA : une approche systématique

Introduction

Dans le domaine en pleine expansion de l'intelligence artificielle, de nombreuses équipes continuent d'évaluer leurs agents de manière similaire à celle des grands modèles de langage. Cette méthode consiste souvent à exécuter quelques tâches, à inspecter la sortie finale, et à supposer que tout fonctionne correctement. Cependant, cette approche peut négliger des échecs significatifs. Par exemple, un modèle peut choisir un outil inapproprié ou générer des arguments incorrects pour cet outil. De plus, le système d'agent peut mal gérer les échecs de l'outil ou suivre une séquence d'actions inefficace. En se concentrant uniquement sur la réponse finale, on passe à côté des points de défaillance potentiels.

L'évaluation des agents comble cette lacune en examinant l'ensemble du processus d'exécution. Elle s'intéresse à la manière dont un agent raisonne, prend des décisions, utilise des outils et s'adapte au fur et à mesure que la tâche progresse. Cette approche fournit une image plus précise de la fiabilité, de l'efficacité et de la performance globale, aidant ainsi les équipes à identifier les problèmes avant qu'ils n'atteignent la production. Les principes abordés dans cet article forment la base d'une approche systématique pour mesurer et améliorer la performance des agents.

Étape 1 : Comprendre pourquoi l'évaluation des agents est importante

Lorsqu'un agent échoue, la réaction instinctive est souvent de penser qu'il s'agit d'un problème de prompt : le prompt du système doit être plus clair. Bien que cela puisse parfois être vrai, l'échec est souvent un problème de mesure : l'évaluation n'a pas été conçue pour détecter ce qui a échoué.

Les agents d'IA fonctionnent à travers plusieurs couches, et chacune de ces couches peut échouer indépendamment. La couche de raisonnement, alimentée par le modèle de langage, gère la planification, la décomposition des tâches et la sélection des outils. La couche d'action, quant à elle, est alimentée par des appels d'outils et des réponses de systèmes externes et gère l'exécution. Un agent peut raisonner correctement sur ce qu'il doit faire, mais appeler ensuite le bon outil avec des arguments mal formés. Traiter l'évaluation des agents comme un simple contrôle de précision de bout en bout néglige ces deux surfaces de défaillance.

Étape 2 : Définir à quoi ressemble le succès de l'évaluation des agents

L'efficacité d'une évaluation repose sur la clarté de ses critères de succès. Une tâche d'évaluation bien formulée est celle où deux experts du domaine, travaillant indépendamment, parviennent au même verdict de réussite ou d'échec.

Pour commencer, il est essentiel de disposer de spécifications de tâches sans ambiguïté, associées à des solutions de référence. Ces solutions sont des sorties connues comme correctes qui passent tous les évaluateurs, prouvant que la tâche est solvable et vérifiant que la logique de notation est correctement configurée.

Avant toute exécution de notation, il est crucial de définir les éléments suivants pour les évaluations :

• La tâche : quels sont les inputs que l'agent reçoit, ce qu'il est censé faire et à quoi ressemble l'environnement au départ.
• Les critères de succès : cela inclut non seulement la réponse finale, mais aussi les résultats intermédiaires qui comptent, tels que l'appel du bon outil, la mise à jour correcte de l'état, et si la réponse était fondée sur le contexte récupéré.
• Les cas négatifs : des évaluations unilatérales créent une optimisation unilatérale. Des ensembles de données équilibrés, couvrant à la fois quand un comportement doit se produire et quand il ne doit pas, empêchent les agents de surdéclencher ou de sous-déclencher une capacité.

Un ensemble de tâches bien spécifiées tirées des échecs d'utilisation réels est un meilleur point de départ que d'attendre le jeu de données parfait. Les évaluations deviennent plus difficiles à construire plus vous attendez.

Étape 3 : Noter la couche d'action de l'agent avec des vérifications basées sur le code

Les évaluateurs déterministes, c'est-à-dire du code qui vérifie des conditions spécifiques sans jugement du modèle, sont l'option la plus rapide, la moins coûteuse et la plus reproductible dans toute pile d'évaluation d'agent. Pour la couche d'action, ils doivent toujours être le point de départ.

Ces vérifications incluent :

• Vérification des appels d'outils : s'assurer que l'agent a appelé le bon outil dans la bonne séquence.
• Validation des arguments : vérifier si les inputs ont les bons types, les paramètres requis et des valeurs valides.
• Vérification des résultats : s'assurer que l'environnement se termine dans l'état attendu.
• Analyse des transcriptions : examiner le nombre de tours, les tokens consommés et la latence.

Ces vérifications sont souvent rapides, objectives et faciles à déboguer, mais elles peuvent être fragiles. Par exemple, un évaluateur vérifiant pour "confirmation_code" : "CONF-789" manquera une réponse correcte qui formate les mêmes données différemment.

Étape 4 : Noter la qualité du raisonnement et de la sortie de l'agent avec des juges basés sur le modèle

Certaines dimensions de l'évaluation des agents résistent à la vérification déterministe, telles que la qualité de sortie, le ton, la fidélité au contexte récupéré, et l'empathie appropriée. Pour ces aspects, un modèle de langage utilisé comme juge, ou LLM-en-juge, est l'outil approprié. Il est flexible et capable de gérer des sorties ouvertes, mais introduit du non-déterminisme et une dérive de calibration que les évaluateurs basés sur le code n'ont pas.

Pour maintenir la fiabilité des évaluateurs basés sur le modèle, les pratiques suivantes sont recommandées :

• Rédiger des rubriques structurées : par exemple, "Évaluer si la réponse est utile" produit du bruit. Une rubrique spécifiant que la réponse doit aborder la question de l'utilisateur, fonder les affirmations sur le contexte récupéré et éviter les suggestions hors sujet produit un signal. Notez chaque dimension avec un jugement séparé et isolé.
• Calibrer régulièrement par rapport au jugement humain : la précision du LLM-en-juge doit être vérifiée par rapport à un échantillon noté par des experts du domaine. Lorsque des divergences apparaissent, la rubrique est presque toujours le problème. Donnez à l'évaluateur une option explicite "Impossible à déterminer" pour éviter des jugements forcés sur des cas ambigus.
• Intégrer des crédits partiels pour les tâches à plusieurs composants : un agent de support qui identifie correctement le problème et vérifie le client mais échoue à traiter le remboursement est significativement meilleur que celui qui échoue au premier pas. Un pass/fail binaire cache où l'agent se décompose réellement.

Étape 5 : Adapter la stratégie d'évaluation des agents au type d'agent

Les stratégies de notation s'appliquent largement, mais le type d'agent détermine quels évaluateurs portent le plus de poids et quels modes de défaillance prioriser.

• Les agents de codage : ils écrivent, testent et déboguent du code. Le logiciel est largement déterministe : le code s'exécute-t-il, les tests passent-ils, la correction résout-elle le problème sans casser la fonctionnalité existante ? Des benchmarks comme SWE-bench Verified et Terminal-Bench suivent cette approche pass/fail, complétée par des vérifications de qualité basées sur des rubriques pour la sécurité, la lisibilité et la gestion des cas extrêmes.

• Les agents conversationnels : ils interagissent avec les utilisateurs dans le cadre de workflows de support, de vente et de coaching. La qualité de l'interaction fait partie de ce qui est évalué — non seulement si le ticket a été résolu, mais si le ton était approprié et la résolution clairement expliquée. Cela nécessite un second modèle de langage simulant l'utilisateur ; τ-bench modélise exactement cela, avec des évaluateurs évaluant à la fois l'achèvement de la tâche et la qualité de l'interaction à travers les tours.

• Les agents de recherche : ils rassemblent et synthétisent des informations à partir de sources. Les vérifications de fondement vérifient que les affirmations sont soutenues par des sources récupérées, les vérifications de couverture définissent ce qu'une bonne réponse doit inclure, et les vérifications de qualité des sources confirment que l'agent a consulté du matériel autoritaire.

Étape 6 : Prendre en compte la non-déterminisme dans les résultats d'évaluation des agents

Le comportement des agents varie entre les exécutions ; la même tâche, les mêmes inputs, le même agent peuvent produire différentes sélections d'outils, chemins de raisonnement et résultats. L'évaluation sur un seul essai peut donc être trompeuse, car elle cache la variabilité que des métriques de précision simples échouent à capturer.

Ceci est une conséquence directe de la non-déterminisme dans les systèmes d'agents. Les sorties de modèles stochastiques, la latence des outils, les échecs partiels et la prise de décision adaptative introduisent tous de la variabilité entre les exécutions. Par conséquent, évaluer un agent nécessite de raisonner sur des distributions de résultats plutôt que sur une seule trace d'exécution.

Pour tenir compte de cette variabilité, des métriques comme pass@k et pass^k sont couramment utilisées :

• pass@k : la probabilité qu'au moins un des k essais indépendants réussisse, utile lorsque plusieurs tentatives sont acceptables.
• pass^k : la probabilité que tous les k essais réussissent, important lorsque chaque interaction doit être fiable.

Par exemple, un agent avec un taux de succès de 75 % sur un essai unique réussit à tous les trois essais seulement environ 42 % du temps, montrant à quelle vitesse la fiabilité se dégrade lors des exécutions répétées.

Le choix entre ces métriques est finalement une décision produit plutôt qu'une question purement technique. Si un seul résultat correct est nécessaire, pass@1 ou pass@k est utile. Si chaque interaction doit réussir de manière cohérente, pass^k est la mesure la plus significative.

Étape 7 : Séparer les évaluations de capacité des suites de régression

Les évaluations de capacité sont conçues pour répondre à une question tournée vers l'avenir : que peut faire cet agent qu'il ne pouvait pas faire auparavant ? Pour cette raison, elles devraient commencer avec des taux de réussite relativement bas et se concentrer sur des tâches qui sont encore difficiles pour le système. Lorsqu'une évaluation de capacité atteint des scores très élevés — disons 90 % — elle ne mesure souvent plus la capacité, mais confirme simplement la fiabilité sur des problèmes déjà résolus.