AWS détaille cinq modèles pour évaluer les agents d'IA profonds

AWS et LangSmith ont publié un guide détaillé pour évaluer les agents d'IA profonds : des systèmes autonomes qui résolvent seuls des tâches en plusieurs étapes, en raisonnant et en prenant des décisions en cours de route.

Cinq critères d'évaluation

La principale conclusion d'AWS : évaluer un agent selon un seul paramètre est une erreur. Il faut une approche globale. L'entreprise propose cinq axes de vérification, chacun couvrant un aspect différent du travail de l'agent :

• Justesse du résultat : l'agent a-t-il donné la bonne réponse finale à la question de l'utilisateur
• Trajectoire de résolution : quel chemin l'agent a choisi, si les étapes sont logiques et s'il y a des erreurs évidentes dans le raisonnement
• Gestion des outils : quelles API, quels services et quelles bases de données l'agent a appelés, et s'il les a utilisés efficacement
• Sécurité et conformité : l'agent a-t-il respecté les politiques d'accès et est-il resté dans les limites des actions autorisées
• Transparence des décisions : le développeur peut-il comprendre la logique de chaque décision de l'agent

Sur les premiers prototypes, l'accent est mis sur la justesse et la logique. Dans un système en production, surtout s'il est critique, la priorité se déplace vers la sécurité, la supervision et la capacité d'expliquer chaque décision de l'agent.

Tests hors ligne et supervision en direct

AWS a décrit une approche à deux niveaux : contrôle avant le lancement et contrôle après.

Le premier niveau est le test hors ligne pendant le développement. On écrit des tests en pytest, on fournit à l'agent des entrées prédéfinies et on vérifie s'il donne la bonne réponse. C'est du test unitaire classique, mais pour des systèmes d'IA : un jeu de questions, des résultats attendus et une vérification de correspondance.

LangSmith y ajoute le suivi des traces d'appels. Pendant que l'agent travaille, l'outil enregistre chaque étape : les sous-questions que l'agent s'est posées, les services qu'il a appelés et la manière dont il est passé d'une étape à l'autre. Si le résultat est faux, on voit précisément où l'erreur s'est produite et on peut la corriger.

Le second niveau s'active après le déploiement en production. Quand l'agent travaille avec de vrais utilisateurs, LangSmith continue d'observer. Le système suit des métriques en temps réel : temps de réponse à chaque requête, taux d'erreurs, taux de réussite de l'exécution et durée de chaque étape intermédiaire. Si les métriques commencent à se dégrader, l'alerte se déclenche automatiquement.

Un agent text-to-SQL comme exemple complet

AWS a construit un agent de démonstration qui traduit le langage courant en requêtes SQL sur des bases de données. L'utilisateur écrit : « Montre le top 10 des clients par volume de ventes ce trimestre ». L'agent analyse la demande, génère la commande SQL, l'exécute sur la base de données et renvoie un tableau de résultats.

Cet exemple couvre entièrement les cinq critères d'évaluation : justesse du résultat final, logique des étapes, choix des bons outils (quelles tables interroger), sécurité (ne pas sortir du périmètre des données disponibles) et possibilité de comprendre pourquoi l'agent a produit précisément cette commande SQL.

L'agent est déployé sur Amazon Bedrock, un service cloud géré pour travailler avec de grands modèles de langage. Bedrock prend en charge la mise à l'échelle de l'infrastructure, la tolérance aux pannes et la conformité aux normes de sécurité. Le développeur se concentre sur la logique de l'agent, tandis que Bedrock assure fiabilité et performances.

Ce que cela change

Jusqu'ici, évaluer des systèmes d'IA complexes relevait de l'art : on lance un agent, on regarde le résultat et on devine pourquoi telle chose s'est produite. AWS et LangSmith apportent une démarche d'ingénierie. Quand on voit la trace complète des décisions de l'agent et qu'on peut la vérifier pas à pas, il devient possible non seulement d'attraper une erreur, mais aussi de la prévenir dès le développement.

Pour les systèmes de grande taille et critiques, où un agent gère des paiements, l'accès à des données confidentielles ou prend des décisions métier importantes, cela passe de la catégorie « ce serait bien » à celle de « indispensable ».