AWS montre comment évaluer les agents IA selon 3 modes : du débogage à la production

Un client a demandé le remboursement d'une commande et des explications pour résilier son abonnement. L'agent a effectué le remboursement, pris poliment congé… et oublié l'abonnement. La vitesse de réponse est bonne, le ton aussi. Pour le client, pourtant, la tâche n'est pas terminée. Dans un nouveau document, AWS explique comment repérer ce type d'échec avec Amazon Bedrock AgentCore Evaluations : vérifier les actions individuelles de l'agent et le résultat de toute la conversation, puis utiliser ces vérifications avant la mise en production et sur le trafic réel.

Il s'agit d'une analyse pratique des capacités du service. Sa valeur réside dans la manière de relier l'évaluation de l'agent au travail concret pour lequel l'entreprise paie. Le document lui-même ne permet pas d'affirmer que les vérifications décrites améliorent la qualité d'un certain pourcentage ni qu'elles préviennent à coup sûr les erreurs.

Définissez d'abord ce qui compte comme un travail accompli

AWS suggère de partir du résultat métier. Pour un support, il peut s'agir de résoudre la demande dès le premier contact. Pour un agent de recherche, d'une réponse complète avec sources, fondée sur les documents trouvés. Il faut ensuite décomposer ce résultat en actions observables : l'agent a exécuté toutes les demandes, conservé les détails importants de la conversation, choisi l'outil approprié et lui a transmis les bons paramètres.

Revenons au remboursement. Trois vérifications indépendantes sont utiles ici. GoalSuccessRate évalue l'atteinte de l'objectif sur toute la session. ConversationCompleteness, de DeepEval, aide à repérer la question oubliée sur l'abonnement. PIILeakage vérifie que l'agent n'a pas divulgué de données personnelles. Un remboursement réussi ne dit rien, en soi, des deux autres résultats.

Le niveau de la vérification compte aussi. La justesse des arguments d'un appel d'outil peut s'évaluer sur l'action concrète. Pour savoir si l'agent a répondu à toutes les questions, il faut examiner toute la conversation. Si l'on ne regarde que la dernière réplique, une partie des erreurs échappe à l'analyse.

Un seul jeu de vérifications pour trois modes

AgentCore propose des évaluateurs intégrés d'AWS, des vérifications gérées issues de DeepEval et AutoEval, ainsi que des variantes personnalisées. Les évaluateurs intégrés couvrent la qualité des réponses, l'exécution des tâches, l'utilisation des outils et d'autres comportements. En mode géré pour les vérifications tierces, le service héberge le code, choisit le modèle évaluateur et exécute les requêtes sur sa propre infrastructure. Les variantes personnalisées permettent de changer le modèle, les instructions et les critères d'évaluation.

On peut les lancer de trois façons. Lors du débogage, le développeur transmet une session enregistrée à l'API et obtient une évaluation accompagnée d'une explication. Avant la mise en production, l'équipe fait passer un ensemble fixe de dialogues pour mesurer l'effet d'un changement de prompt ou de modèle. En production, le service vérifie une part définie du trafic réel. Les trois modes utilisent les mêmes identifiants d'évaluateurs.

Il est aussi possible d'évaluer plusieurs critères en un seul appel au modèle. Par exemple, vérifier séparément la résolution de la demande, le respect des règles de remboursement et le ton professionnel. Les résultats sont renvoyés par critère, sans note de synthèse globale. Cela permet de fixer des conditions de publication indépendantes : l'amélioration du ton ne doit pas compenser une violation de la politique.

Il convient de regrouper les vérifications lorsqu'elles requièrent les mêmes données et le même modèle. Si un critère exige une réponse de référence et qu'un autre peut s'évaluer sur un dialogue réel, mieux vaut les laisser séparés.

Où s'arrête l'utilité de l'évaluation automatique

Certaines vérifications nécessitent une réponse correcte connue à l'avance ou une séquence attendue d'appels d'outils. Selon AWS, elles sont disponibles en mode par lots : sur le trafic réel, il n'y a généralement pas de référence. C'est pourquoi l'ensemble de test avant la mise en production et la surveillance en production répondent à des besoins différents, même s'ils partagent un catalogue commun.

Une autre limite tient au modèle évaluateur lui-même. Sa note doit être confrontée à ce que l'équipe considère comme un succès. Pour un remboursement, il est utile de comparer l'évaluation du dialogue au résultat effectif de l'opération dans le système de commandes. Une bonne explication du modèle ne prouve pas encore que l'argent a réellement été rendu.

Pour démarrer concrètement, une équipe peut choisir deux ou trois défaillances importantes et rassembler des dialogues où elles apparaissent. Elle vérifie ensuite si les évaluateurs les détectent, et seulement après, active la surveillance du trafic. Dans ce document, AWS ne fournit aucun calcul de coût ni d'économies. Le budget des vérifications et la confiance accordée à leurs résultats devront être évalués sur vos propres sessions.