AWS lance UAEF : un seul jeu de 36 métriques pour les agents, quel que soit le framework

Vous avez construit un agent avec LangGraph, il fonctionne, les métriques sont en place. Puis l'équipe décide de passer à Strands ou de déplacer une partie de la logique vers AgentCore, et il s'avère que le scoring, le stockage des résultats et les rapports sont taillés pour le format de traces de l'ancien framework. Il faut reconstruire l'évaluation, et la question simple « l'agent s'est-il amélioré après le changement de prompt ? » reste sans réponse.

AWS propose de rompre ce couplage. UAEF (Universal Agent Evaluation Framework) est un projet open source sous licence Apache 2.0 (dépôt awslabs/uaef). Il sépare « la manière dont le framework a enregistré l'exécution de l'agent » de « la manière dont nous évaluons la qualité ». D'après AWS, 12 organisations des secteurs des télécoms, de la santé et de la finance l'ont déjà utilisé.

Comment ça marche

En entrée, deux éléments : un agent et un jeu de données. Le jeu de données contient les requêtes et, éventuellement, les réponses de référence. Pour vérifier les appels d'outils, il faut ajouter à la référence les appels attendus : quels outils, dans quel ordre et avec quels arguments.

Ensuite, le pipeline fonctionne ainsi :

1. L'adaptateur lit la trace d'exécution native (messages, appels d'outils, transferts entre agents) et la convertit au format unifié AgentTrace. On peut fournir une trace toute prête, issue des logs ou de Langfuse. Ou bien UAEF appelle lui-même l'agent via ARN ou endpoint HTTP pour chaque entrée du jeu de données.
2. La trace est analysée pour détecter les données personnelles (e-mails, téléphones, numéros de carte) avant d'être enregistrée.
3. Le moteur calcule les métriques. Il y en a 36, réparties en 7 dimensions : appel d'outils, qualité de la réponse, IA responsable, performance, dialogue multi-étapes, coordination de plusieurs agents et raisonnement.
4. Le résultat est enregistré comme une expérience : métadonnées dans DynamoDB, résultats complets avec les justifications du juge dans S3.

L'idée centrale tient à l'ordre des opérations : d'abord la normalisation, ensuite l'évaluation. C'est pourquoi un agent sur un framework peut être comparé équitablement à un agent sur un autre, sur la même échelle. Chaque métrique renvoie un nombre de 0 à 1, où 1 est la meilleure valeur.

Métriques déterministes et LLM juge

Il existe deux types de métriques. Les métriques déterministes sont calculées directement à partir de la trace et de la référence, et sont reproductibles à l'identique. Les autres reposent sur LLM-as-a-judge : un modèle sur Amazon Bedrock évalue ce qui est difficile à formaliser, par exemple la pertinence ou la sécurité. Il est possible d'ajouter ses propres métriques et de brancher RAGAS et DeepEval.

Les auteurs décrivent séparément la protection du juge. La réponse de l'agent entre dans le prompt du juge, c'est donc une entrée non fiable. Sinon, un agent capable d'influencer le juge pourrait influencer ses propres évaluations. Les critères sont envoyés séparément du contenu, le contenu est échappé, et le juge doit citer un fragment textuel du texte évalué. Si la citation ne figure pas dans le texte, l'évaluation est rejetée. AWS prévient toutefois honnêtement : les évaluations du juge sont un signal pour le développement, pas un mécanisme de sécurité. Pour la protection en runtime, il faut Bedrock Guardrails.

Comparaison de versions et régressions

C'est la partie la plus pratique. Pour chaque métrique commune à deux exécutions, UAEF calcule la variation absolue et en pourcentage et la classe en régression, amélioration ou sans changement. Le seuil par défaut est de 5 %. La gravité de la régression se répartit en trois niveaux : légère (5–10 %), modérée (10–20 %) et sévère (plus de 20 %). Les régressions sont regroupées par dimension.

Imaginons que vous ayez modifié le prompt système. La comparaison peut montrer que la qualité de la réponse n'a pas changé, alors que la précision du choix des outils a chuté de 12 %, soit une régression modérée. Sans ventilation par dimension, vous ne verriez que le score moyen, qui a à peine bougé.

On peut associer une configuration à l'exécution : framework, modèle, outils, prompt, paramètres et même le commit Git. Une exécution peut être désignée comme référence. Chaque score est alors rattaché au changement qui l'a produit.

Les rapports fonctionnent à trois niveaux : synthèse des résultats dans l'interface web, rapport statistique et insights LLM. Le rapport statistique est calculé uniquement à partir des scores, sans LLM, avec intervalles de confiance et valeurs aberrantes ; il est donc toujours identique pour les mêmes données. Les insights, c'est-à-dire les hypothèses sur les causes et les priorités de correction, sont générés par un modèle sur Bedrock via la bibliothèque Python.

Que faire de tout cela

Premièrement : n'activez pas les 36 métriques d'un coup. Dans son playbook, AWS conseille de partir du scénario d'usage. Un assistant RAG a besoin de pertinence, de précision et de faithfulness de RAGAS ; un agent avec outils a besoin du choix et de l'ordre des appels et de la qualité des paramètres. Les métriques superflues coûtent du temps et des appels à Bedrock.

Deuxièmement : UAEF peut être intégré au CI/CD via la bibliothèque Python, et pour les collègues moins techniques, il existe un service déployable avec une interface low-code. Le moteur est le même dans les deux cas.

Les limites sont également évidentes. L'outil est fortement lié à AWS : le juge tourne sur Bedrock, et le stockage repose sur DynamoDB et S3. Un seuil de 5 % sur un petit jeu de données peut facilement être pris pour du bruit ; regardez donc les intervalles de confiance dans le rapport. Et ne confondez pas évaluation de la qualité et protection : pour la sécurité, il faut des garde-fous distincts.

Pour les équipes qui exécutent des agents sur plusieurs frameworks ou prévoient de migrer, c'est une base prête à l'emploi pour les tests de régression d'agents, qu'il aurait autrement fallu écrire soi-même.