Lancer l'agent n'est que la première étape.Auteur de l'article : elune
Article traduit, source : ME News
Lancer l'agent n'est que la première étape.
Ce qui est vraiment difficile, c’est de déterminer : si elle est stable, si elle est correcte, ou si elle a dégradé discrètement à cause d’un seul prompt ou d’une mise à jour du modèle.
Les 10 méthodes d'évaluation suivantes méritent d'être connues de chaque ingénieur en IA.
1. Golden Set
Prepare a set of fixed and frozen test cases.
Après chaque modification des invites, du modèle, des outils ou du flux de travail, relancez cet ensemble d'exemples pour déterminer si le système s'est amélioré ou s'il a échoué discrètement dans certains scénarios.
C'est la ligne de base la plus fondamentale du système d'évaluation des agents.
Outil recommandé : OpenAI Evals
Peut être utilisé pour construire un ensemble de tests de référence exécutables de manière répétée et comparer les performances de différents modèles ou versions de système.
2. Juge LLM | LLM comme juge
Utiliser un autre modèle de langage à grande échelle pour évaluer les réponses ouvertes selon des critères de notation préétablis.
Cette méthode est particulièrement efficace lorsque la tâche n'a pas de réponse unique et ne peut pas être jugée correcte ou incorrecte par correspondance de chaînes ou sortie fixe.
Par exemple, le modèle de jugement peut évaluer si la réponse est précise, complète, pertinente et respecte les exigences de l'utilisateur.
Outil recommandé : OpenEvals
Fournit des évaluateurs prêts à l'emploi pour les applications LLM, permettant de mettre en place rapidement des processus d'évaluation automatisés.
3. Évaluation multidimensionnelle | Rubric Scoring
Ne donnez pas uniquement à l'agent une « note de qualité » générale.
Doit être évalué séparément :
- Correctness
- Intégrité
- Style d'expression
- Security
- Temps de réponse
- Coût d'appel
Un score global peut masquer les problèmes réels.
Par exemple, une baisse du score total n'indique pas nécessairement une erreur de réponse, mais peut être due à une augmentation soudaine du coût d'appel des outils ; une augmentation du score total peut également reposer sur une diminution de la sécurité.
Outil recommandé : DeepEval
Support the creation of custom indicators and independent scoring across different quality dimensions.
4. Évaluation de la trajectoire | Trajectory Eval
N'évaluez pas seulement la réponse finale fournie par l'Agent, mais aussi l'ensemble du processus qu'il a suivi pour accomplir la tâche.
Incluant :
- Avez-vous sélectionné le bon outil ?
- Les outils sont-ils appelés dans un ordre raisonnable ?
- Is repeating an invalid action?
- Des étapes nécessaires ont-elles été omises ?
- Les décisions ont-elles été ajustées correctement en fonction des résultats des outils ?
L'agent pourrait finir par obtenir la bonne réponse, mais le processus intermédiaire est inefficace, fragile, voire risqué.
Outil recommandé : AgentEvals
You can review the agent's actions, decisions, and tool calls throughout the full execution trace.
5. Tests unitaires des outils | Tool Unit Tests
Écrivez des tests indépendants pour chaque outil utilisé par l'agent.
Use fixed input to verify fixed output, without involving the model.
Cela permet de décomposer le problème :
Est-ce un problème d’inférence de l’agent, ou un problème avec les outils, interfaces ou le serveur MCP sous-jacents ?
Il n'a de sens d'évaluer si l'Agent a correctement appelé l'outil qu'après avoir assuré la fiabilité de l'outil lui-même.
Outil recommandé : MCP Inspector
Can be used to check and test the MCP Server, tool parameters, and return results.
6. Jeu de tests de régression | Regression Suite
Sauvegarder les cas d'exécution réels passés et les réexécuter à chaque mise à jour des invites, du modèle ou de l'ensemble d'outils.
Ensuite, comparez les résultats des versions ancienne et nouvelle pour vérifier :
- La tâche initialement correcte a-t-elle échoué ?
- Le format de sortie a-t-il changé ?
- Les appels d'outils augmentent-ils ?
- Les délais et les coûts ont-ils augmenté ?
- Certaines cases limites se dégradent-elles ?
La meilleure performance moyenne de la nouvelle version ne signifie pas qu'elle n'a pas rompu les anciennes fonctionnalités.
Outil recommandé : Promptfoo
Support the execution of reproducible evaluation suites, capture regression issues, and integrate checking processes into CI.
7. Tests A/B en production | A/B Testing in Production
Répartir aléatoirement le trafic utilisateur réel entre deux versions différentes pour comparer leur performance dans un environnement réel.
Vous pouvez tester :
- Deux ensembles de prompts
- Deux modèles
- Deux flux de travail Agent
- Différentes combinaisons d'outils
- Différentes stratégies de réponse
La version avec un score hors ligne plus élevé ne garantit pas nécessairement un taux de réussite utilisateur plus élevé.
Ce qui compte vraiment, c’est le résultat réel, par exemple le taux d’achèvement des tâches, le taux d’adoption par les utilisateurs, le taux de conversion, le taux de prise en main humaine et le taux de résolution des problèmes.
Outil recommandé : GrowthBook
Provide feature toggles, controlled experiments, and product analytics capabilities.
8. Revue humaine | Human Review
Des échantillons réguliers d'enregistrements de fonctionnement réels sont évalués par des examinateurs humains.
La revue humaine permet non seulement de détecter les problèmes omis par l'évaluation automatisée, mais aussi de calibrer les juges LLM.
À vérifier attentivement :
- Les scores du modèle correspondent-ils aux jugements humains ?
- Les critères d'évaluation sont-ils suffisamment clairs ?
- Le modèle de jugement privilégie-t-il les réponses longues ?
- Évaluation automatique des erreurs graves éventuellement omises
L'évaluation automatisée ne peut pas remplacer complètement le jugement humain.
Outil recommandé : Argilla
Aider l'équipe à collecter des retours humains, vérifier les sorties du modèle et transformer les résultats en jeux de données de haute qualité.
9. Shadow Run
Faire fonctionner la version candidate sur le trafic réel, sans afficher sa sortie aux utilisateurs.
L'ancienne version est toujours utilisée en production, tandis que la nouvelle version s'exécute uniquement en arrière-plan pour comparer leurs performances.
Cette méthode est adaptée aux mises à jour à haut risque, par exemple :
- Changer le modèle principal
- Rewrite the system prompt
- Intégration de nouveaux outils externes
- Modifier la logique de décision de l'Agent
- Élargir les autorisations des outils
Shadow running helps teams identify issues in real traffic before official release, while avoiding direct impact on users.
Outil recommandé : Langfuse
Suivez les exécutions de production, comparez les versions candidates et surveillez les résultats d'évaluation.
10. Tests de red teaming | Red Teaming
Attaquez activement votre propre système avant l'attaquant.
La portée du test inclut :
- Attack de jailbreak
- Prompt injection
- Fuite de données sensibles
- Contournement de permissions
- Abus d'outils
- Fichiers ou contenus de pages web malveillants
- Opération externe non prévue
Les tests de red teaming sont particulièrement importants pour les agents pouvant appeler une base de données, envoyer des e-mails, modifier des fichiers, exécuter du code ou accéder aux systèmes internes.
Outil recommandé : Garak
Détecte les vulnérabilités de sécurité et les comportements non sécurisés dans le système LLM.
L'évaluation hors ligne vous indique que le système fonctionne correctement dans l'environnement de test.
L'évaluation en ligne vous indique que le système continue de fonctionner normalement après son déploiement.
Vous n'avez peut-être pas besoin de mettre en place les 10 mécanismes d'évaluation en une seule fois.
Une approche plus pratique consiste à :
Revoyez la dernière défaillance de l'Agent, puis priorisez le déploiement des deux méthodes d'évaluation qui auraient pu détecter le problème à l'avance.
Établir d'abord un jeu de tests doré, puis compléter avec des tests de régression ou des vérifications manuelles permet souvent d'éviter un grand nombre d'erreurs élémentaires.
À sauvegarder.