Évaluation des agents AI : Phoenix, LangSmith et DeepEval
Traduction automatique
Cet article a été traduit automatiquement depuis la version originale en anglais.
Aucun outil d’évaluation d’agent ne peut remplacer la conception des tests. Commencez par les échecs que le produit doit détecter : réponses incorrectes, mauvais choix d’outils, arguments invalides ou effets de bord dangereux. Vérifiez également les étapes inutiles ainsi que les régressions de latence et de coût. Choisissez ensuite l’outil adapté à l’endroit où ces tests doivent s’exécuter.
Utilisez Phoenix lorsque le traçage ouvert et l’auto-hébergement sont importants. Utilisez LangSmith lorsque les datasets, les traces, l’annotation et les expériences doivent partager un même processus géré. Utilisez DeepEval lorsque l’évaluation doit s’intégrer à un pipeline CI Python comme des tests. Ajoutez Promptfoo pour une CLI locale, des tests matriciels et des cas de red team.
Choisissez selon l’endroit où les tests s’exécutent, les étapes à examiner et la nécessité de conserver les données d’évaluation dans votre environnement.
Tableau de décision
| Besoin | Point de départ | Pourquoi |
|---|---|---|
| Traces OpenTelemetry et auto-hébergement | Phoenix | Le traçage, les évaluations, les datasets et les expériences open source utilisent les conventions OpenTelemetry et OpenInference. |
| Traces, datasets et revue dans un service géré | LangSmith | Il évalue les trajectoires et les réponses finales, et peut fonctionner avec des agents externes à LangChain. |
| Tests Python et contrôles CI | DeepEval | L’évaluation des agents de bout en bout et au niveau des composants s’intègre bien à un processus orienté tests. |
| Tests matriciels locaux et red teaming | Promptfoo | La CLI et la bibliothèque open source exécutent des évaluations reproductibles et des cas de sécurité dans la CI. |
| Vérifications de politique ou d’outils propres au produit | Évaluateurs personnalisés | Les juges génériques ne connaissent ni vos permissions, ni vos actions irréversibles, ni vos budgets, ni vos invariants métier. |
Évaluer les étapes et le résultat
Une trajectoire est la séquence de décisions du modèle et de tool calls au cours d’une exécution. Une réponse finale correcte peut masquer des erreurs dans ces étapes. Un agent peut appeler le mauvais outil, réessayer inutilement, exposer des arguments sensibles ou parvenir à une réponse plausible sans preuve. À l’inverse, une autre séquence d’outils valide ne devrait pas échouer simplement parce qu’elle diffère d’une trace de référence.
Conservez des vérifications distinctes pour :
- l’exactitude de la réponse finale et l’étayage par des preuves
- la sélection des outils et la validité des arguments
- les actions obligatoires, interdites ou répétées
- les décisions de politique et les limites d’approbation
- l’efficacité de la trajectoire, la latence et le coût
- la récupération après des erreurs d’outils ou des résultats partiels
Utilisez autant que possible des assertions déterministes. Réservez les juges fondés sur des modèles aux questions sémantiques, calibrez-les sur des exemples examinés et stockez le modèle du juge ainsi que le prompt avec chaque résultat.
Par exemple, testez un agent de suivi des commandes avec un utilisateur qui n’a pas accès à la commande demandée. Vérifiez qu’il ne renvoie pas les détails de la commande et n’appelle pas d’outil d’écriture. Même un refus final poli échouerait au test si une étape antérieure avait divulgué l’enregistrement privé.
Une première stack pratique
- Dans le code applicatif qui exécute le modèle et les outils, enregistrez un ID de requête, l’outil sélectionné, les arguments dont les données sensibles ont été supprimées, le résultat et la durée.
- Transformez les incidents de production en un petit dataset de régression.
- Ajoutez des vérifications déterministes pour les schémas, les actions interdites, les budgets et les preuves requises.
- Ajoutez un juge sémantique calibré pour les résultats que les règles ne peuvent pas évaluer.
- Exécutez les cas rapides à chaque modification, puis une suite plus large avant la mise en production.
- Échantillonnez les traces de production pour détecter de nouveaux modes d’échec et intégrez-les aux tests.
Pour aller plus loin
- Évaluation des agents : des traces aux suites de tests explique la conception des évaluations qui sous-tend ces outils.
- Sécurité des agents AI couvre les vérifications de politique qu’un évaluateur devrait observer, mais qu’il ne peut pas appliquer seul.
- Runtime des agents AI de longue durée couvre les traces et les checkpoints qui rendent les échecs reproductibles.