Comment nous testons nos agents en développement

Pourquoi tester les agents est si difficile

L’agent IA fonctionne comme prévu, ce n’est pas facile. Même de petites modifications apportées à des composants tels que vos versions d’invite, l’orchestration des agents et les modèles peuvent avoir des impacts importants et inattendus.

Certains des principaux défis comprennent :

Résultats non déterministes

Le problème sous-jacent est que les agents ne sont pas déterministes. La même entrée entre, deux sorties différentes peuvent sortir.

Comment tester un résultat attendu lorsque vous ne savez pas quel sera le résultat attendu ? En termes simples, tester des résultats strictement définis ne fonctionne pas.

Résultats non structurés

Le deuxième défi, moins discuté, du test des systèmes agents est que les résultats sont souvent non structurés. Les fondements des systèmes agents sont grande langue des modèles après tout.

Il est beaucoup plus simple de définir un test pour des données structurées. Par exemple, le champ id ne doit jamais être NULL ou toujours être un nombre entier. Comment définissez-vous la qualité d’un grand champ de texte ?

Coût et échelle

LLM-en tant que juge est la méthodologie la plus courante pour évaluer la qualité ou la fiabilité des agents d’IA. Cependant, il s’agit d’une charge de travail coûteuse et chaque interaction utilisateur (trace) peut comprendre des centaines d’interactions (spans).

Nous avons donc repensé notre stratégie de test d’agents. Dans cet article, nous partagerons nos apprentissages, notamment un nouveau concept clé qui s’est avéré essentiel pour garantir la fiabilité à grande échelle.

Tester notre agent

Nous avons deux agents en production qui sont exploités par plus de 30 000 utilisateurs. L’agent de dépannage examine des centaines de signaux pour déterminer la cause première d’un incident de fiabilité des données, tandis que l’agent de surveillance formule des recommandations intelligentes en matière de surveillance de la qualité des données.

Pour l’agent de dépannage, nous testons trois dimensions principales : la distance sémantique, l’ancrage et l’utilisation des outils. Voici comment nous testons pour chacun.

Distance sémantique

Nous utilisons des tests déterministes lorsque cela est approprié, car ils sont clairs, explicables et rentables. Par exemple, il est relativement simple de déployer un test pour s’assurer que l’une des sorties du sous-agent est au format JSON, qu’elle ne dépasse pas une certaine longueur, ou encore pour s’assurer que les garde-corps sont appelés comme prévu.

Cependant, il arrive parfois que les tests déterministes ne suffisent pas. Par exemple, nous avons exploré l’intégration des résultats attendus et nouveaux en tant que vecteurs et l’utilisation de tests de similarité cosinus. Nous avons pensé que ce serait un moyen moins coûteux et plus rapide d’évaluer la distance sémantique (le sens est similaire) entre les résultats observés et attendus.

Cependant, nous avons constaté qu’il y avait trop de cas dans lesquels la formulation était similaire, mais le sens était différent.

Au lieu de cela, nous proposons maintenant à notre LLM de juger le résultat attendu de la configuration actuelle et de lui demander de noter sur une échelle de 0 à 1. la similitude de la nouvelle sortie.

Enracinement

Pour l’ancrage, nous vérifions que le contexte clé est présent lorsqu’il devrait l’être, mais également que l’agent refusera de répondre lorsque le contexte clé est manquant ou que la question est hors de portée.

Ceci est important car les LLM sont désireux de plaire et auront des hallucinations lorsqu’ils ne sont pas ancrés dans un bon contexte.

Utilisation de l’outil

Pour l’utilisation de l’outil, nous avons un LLM-as-juge qui évalue si l’agent a fonctionné comme prévu pour le scénario prédéfini, c’est-à-dire :

• Aucun outil n’était attendu et aucun outil n’a été appelé
• Un outil était attendu et un outil autorisé a été utilisé
• Aucun outil requis n’a été omis
• Aucun outil non autorisé n’a été utilisé

La véritable magie ne réside pas dans le déploiement de ces tests, mais dans la manière dont ces tests sont appliqués. Voici notre configuration actuelle éclairée par quelques essais et erreurs douloureux.

Bonnes pratiques en matière de tests d’agents

Il est important de garder à l’esprit que non seulement vos agents sont non déterministes, mais que vos évaluations LLM le sont également ! Ces bonnes pratiques sont principalement conçues pour lutter contre ces lacunes inhérentes.

Échecs doux

Les seuils stricts peuvent être bruyants avec les tests non déterministes pour des raisons évidentes. Nous avons donc inventé le concept d’« échec doux ».

L’évaluation revient avec un score compris entre 0-1. Tout ce qui est inférieur à 0,5 est un échec brutal, tandis que tout ce qui dépasse 0,8 est une réussite. Des échecs légers se produisent pour des scores compris entre 0,5 et 0,8.

Les modifications peuvent être fusionnées pour un échec logiciel. Cependant, si un certain seuil de défaillances logicielles est dépassé, cela constitue une défaillance matérielle et le processus est arrêté.

Pour notre agent, il est actuellement configuré de telle sorte que si 33 % des tests aboutissent à un échec logiciel ou s’il y a plus de 2 échecs logiciels au total, alors il est considéré comme un échec matériel. Cela empêche la fusion de la modification.

Réévaluer les échecs logiciels

Les échecs mineurs peuvent être un canari dans une mine de charbon, ou dans certains cas, ils peuvent être absurdes. Environ 10 % des échecs légers sont le résultat d’hallucinations. En cas d’échec logiciel, les évaluations seront automatiquement réexécutées. Si les tests réussis, nous supposons que le résultat original était incorrect.

Explications

Lorsqu’un test échoue, vous devez comprendre pourquoi il a échoué. Nous demandons désormais à chaque juge LLM non seulement de fournir une note, mais de l’expliquer. C’est imparfait, mais cela contribue à renforcer la confiance dans l’évaluation et accélère souvent le débogage.

Suppression des tests floconneux

Vous devez tester vos tests. Surtout avec les évaluations LLM en tant que juge, la façon dont l’invite est construite peut avoir un impact important sur les résultats. Nous effectuons des tests plusieurs fois et si le delta des résultats est trop important, nous réviserons l’invite ou supprimerons le test instable.

Suivi en production

Les tests d’agents sont nouveaux et difficiles, mais c’est une promenade de santé par rapport à la surveillance du comportement des agents et des résultats en production. Les entrées sont plus compliquées, il n’y a pas de résultat attendu par rapport à la référence et tout est à une échelle beaucoup plus grande.

Sans compter que les enjeux sont bien plus élevés ! Les problèmes de fiabilité du système deviennent rapidement des problèmes commerciaux.

C’est notre objectif actuel. Nous exploitons observabilité des agents outils pour relever ces défis et rapportera de nouveaux enseignements dans un prochain article.

L’agent de dépannage est l’une des fonctionnalités les plus efficaces que nous ayons jamais proposées. Développer des agents fiables a été un parcours déterminant pour une carrière et nous sommes ravis de le partager avec vous.

---

Michael Segner est stratège produit chez Monte Carlo et auteur du rapport O’Reilly, « Améliorer la fiabilité des données + de l’IA grâce à l’observabilité ». Ceci a été co-écrit avec Elor Arieli et Alik Peltinovich.