Les équipes qui développent des agents d’IA ont besoin de plus que d’un contrôle de la réponse finale pour déterminer si le système fonctionne comme prévu. Dans les applications combinant récupération, génération et appels d’outils, un résultat erroné peut être dû au choix d’une mauvaise base de données ou à la récupération de documents inappropriés, même si le problème semble se situer uniquement dans le texte final. Lors d’une présentation donnée via InfoQ, Susan Chang, data scientist principale chez Elastic, a expliqué comment l’entreprise avait développé un cadre commun pour évaluer ses agents utilisés dans la cybersécurité et les chatbots d’entreprise.
Des évaluations isolées aux outils communs
Les équipes d’Elastic ont commencé par créer des jeux de données, des évaluateurs et des processus de traçage distincts pour chaque agent. Dans le cas d’un agent de détection des attaques, les tests comprenaient des scénarios d’attaque et des scénarios légitimes conçus par des analystes et des chercheurs en sécurité, avec des métriques telles que la précision et le rappel, l’exactitude factuelle, la similarité et la classification des tactiques MITRE. Les chatbots fondés sur les données de l’entreprise testaient quant à eux des questions et la récupération de documents, en mettant l’accent sur la pertinence et l’exhaustivité de la réponse, l’exactitude des identifiants de produit et la formulation de requêtes ES|QL.
La diversité de ces cas a entraîné une importante répétition du travail. Elastic a donc créé un cadre commun capable d’importer différents types de jeux de données dans un schéma unifié, d’exécuter des évaluations fondées sur les traces d’exécution et de fournir des évaluateurs communs pour les applications RAG, en plus de composants personnalisés pour chaque produit. Le processus peut être exécuté localement, charger les données, exécuter l’agent, recueillir les résultats, puis afficher les scores aux développeurs.
Le traçage est indispensable pour comprendre la cause des échecs
L’expérience montre que le traçage de l’agent ne devrait pas se limiter à sa sortie finale. Il faut enregistrer les outils appelés, les recherches vectorielles et lexicales, les données récupérées, la consommation de jetons, le temps de réponse et la séquence des décisions. Ce niveau de détail permet d’évaluer l’appel d’un outil donné ou de découvrir que l’agent a utilisé une mauvaise source avant que le problème n’apparaisse dans la réponse finale.
Les cas d’échec signalés par les utilisateurs, comme une évaluation négative, peuvent également être transformés en nouveaux exemples dans le jeu de données de test. Les retours de production deviennent ainsi une partie des tests de régression des versions ultérieures, au lieu de rester des notes manuelles séparées du cycle de développement.
Pourquoi LLM-as-a-judge ne suffit-il pas ?
Elastic a utilisé des modèles de langage pour évaluer les sorties d’autres modèles dans des tâches ouvertes ou ambiguës, comme le style, la cohérence et l’adéquation de la réponse au contexte. Cette approche permet d’étendre l’évaluation lorsqu’il est difficile d’écrire une règle précise pour juger un texte long. Cependant, elle peut produire des résultats variables d’une exécution à l’autre et échouer à détecter des erreurs spécifiques, comme un identifiant de produit inexistant ou une formulation de requête invalide.
Elastic a donc combiné LLM-as-a-judge avec des évaluations déterministes fondées sur des règles et la programmation. Ces évaluations examinent la structure JSON ou YAML, la validité de la syntaxe, la présence des entités requises et la possibilité d’exécuter le code ou la requête, ainsi que des métriques telles que la précision, le rappel et l’exactitude factuelle. Cette combinaison réduit le coût et accélère l’évaluation dans les cas où une réponse claire est disponible, tout en réservant le jugement sémantique aux tâches difficiles à réduire à des règles.
Que ne peut-on pas généraliser ?
Elastic n’a pas considéré la création de données de test spécialisées comme une tâche entièrement automatisable. En cybersécurité, l’équipe a besoin d’analystes et de chercheurs pour déterminer ce qui constitue une véritable attaque et quel comportement est acceptable pour l’utilisateur final. De même, la définition d’une régression varie selon les agents : un agent de sécurité peut devenir plus enclin à déclarer la présence d’attaques même lorsque des données légitimes sont saisies après une certaine mise à jour.
L’étalonnage des évaluateurs reste également de la responsabilité de chaque équipe. Si l’évaluateur linguistique attribue des scores différents au même cas ou ne concorde pas avec le jugement humain de référence, le cadre commun produira des chiffres trompeurs, quelle que soit la qualité de l’architecture logicielle. Chang a également signalé le risque de biais de l’évaluateur lorsque les mêmes familles de modèles sont utilisées pour la génération et le jugement, car celui-ci peut surestimer les performances de ces modèles.
Qu’est-ce qui change concrètement pour les équipes ?
L’expérience d’Elastic recommande de commencer avec un petit ensemble d’exemples de test, pouvant aller de 20 à 50 cas, plutôt que d’attendre un jeu de données parfait. Au début, un travail dispersé peut être acceptable pour accélérer l’apprentissage, notamment lorsque les cas d’usage et les métriques sont encore en cours de découverte. Mais lorsque plusieurs agents passent en production, le traçage et l’évaluation de base deviennent indispensables pour répondre aux questions de performance et diagnostiquer les problèmes rencontrés par les utilisateurs.
Elastic a également transféré certains outils d’évaluation de Python vers TypeScript afin de s’aligner sur le code de production écrit en TypeScript et d’utiliser Playwright ainsi qu’un outil interne dédié appelé Scout. Cette étape ne signifie pas que toutes les évaluations de data science doivent être transférées ; elle reflète un besoin précis de réduire l’écart entre ce que l’équipe teste et ce que le système exécute réellement. La conclusion pratique est que le cadre commun peut unifier le schéma, l’exécution et les métriques générales, mais qu’il ne peut pas remplacer l’expertise du domaine ni le jugement sur ce qui doit être considéré comme une réussite ou un échec.