Évaluation et surveillance

Cadre d'évaluation de la sûreté prêt pour la production, qui mesure les réponses des systèmes d'IA à travers 12 catégories de dangers, avec des protocoles de test standardisés pour les décisions de déploiement.

L'étude AgentBench originale a évalué la liste de modèles publiée dans 8 environnements variés ainsi que dans des contextes multi-tours et ouverts.

Évalue les agents LLM sur des tâches réelles à fort enjeu qui seraient généralement accomplies par plusieurs fonctions métier au sein d'une entreprise de génie logiciel.

Benchmark complet pour évaluer les agents d'IA sur des tâches de recherche ouvertes en apprentissage automatique, issues des principales conférences de ML.

Méthodologie prête pour la production qui adapte les principes des applications 12-factor à des systèmes d'agents évolutifs et maintenables, avec une surveillance et une évaluation complètes.

L'Holistic Evaluation of Language Models de Stanford CRFM, étendue aux capacités des agents. L'exemple détaillé est un instantané de benchmark daté, et non une recommandation de modèle actuelle.

Cadre d'évaluation et d'amélioration avec humain dans la boucle pour les agents fondés sur des LLM, permettant aux ingénieurs de guider et d'évaluer les performances de l'agent à chaque étape du développement.

Benchmark complet de cybersécurité de Meta pour évaluer les risques de sécurité des agents LLM dans des contextes autonomes et multi-agents.

Benchmark de mesure des performances d'agents fondés sur des modèles de pointe pour des tâches d'ingénierie de la recherche en ML, en comparaison avec les capacités d'experts humains.

Suite de benchmarks d'ingénierie logicielle comprenant SWE-bench, SWE-bench Verified et SWE-bench Live. Les modèles cités à titre de comparaison dans l'exemple sont des références historiques.

Executable desktop environments where an agent is scored on the state it leaves behind after doing real work across applications, files and the operating system.

Hard command-line tasks in isolated environments, each with a human-written solution and tests that decide whether the agent actually finished.

Software engineering tasks long enough to take a professional hours or days, drawn from repositories chosen so that memorising the answer is not an option.

Le benchmark GAIA original évaluait le raisonnement, la multimodalité, la navigation web et l'utilisation d'outils. Le modèle cité en comparaison constitue la référence historique de l'article.

Benchmark global évaluant les agents sur cinq domaines, avec 20 tâches et 3K+ prompts. L'exemple conserve la liste de modèles de l'époque de sa publication.

Évaluation complète d'agents web incluant WebArena, VisualWebArena et WorkArena, pour tester des interactions web réalistes dans des environnements isolés (sandbox).

Cadre réglementaire de l'Union européenne pour l'évaluation des agents IA, avec classification fondée sur le risque, exigences pour les modèles GPAI et conformité obligatoire pour tout déploiement dans l'UE.

Cadre d'évaluation complet de l'AI Safety Institute pour les systèmes IA de pointe, coordonné avec les travaux du NIST sur la sûreté de l'IA, pour une évaluation de la sécurité aux normes gouvernementales.

Benchmark multilingue évaluant la performance et la sécurité des agents dans 12 langues. L'exemple est un instantané daté du benchmark, et non une recommandation de modèle actuelle.

Cadre d'Anthropic pour évaluer la sûreté de l'IA à partir de principes constitutionnels, incluant des tests de résistance au jailbreak et une évaluation de l'innocuité.

Traçage en production au niveau de chaque étape qui enregistre chaque appel de modèle, appel d'outil, étape de workflow et sous-agent sous forme de span dans un arbre d'exécution unique, annoté de métriques de tokens, de latence et de coût. Standardisé via les conventions sémantiques OpenTelemetry GenAI (attributs gen_ai.*) et exposé dans des plateformes comme LangSmith, Braintrust et Datadog, c'est le signal en temps réel pour déboguer les défaillances non déterministes en production, à distinguer des benchmarks hors ligne qui notent le comportement avant le déploiement.

Benchmark qui place l'agent entre un utilisateur humain simulé et un ensemble d'API métier (commerce de détail, compagnie aérienne), tout en lui imposant de respecter un document de règles écrit. Plutôt que de vérifier une seule réponse, il compare l'état final de la base de données à un état cible à l'issue de la conversation complète. Sa métrique emblématique est pass^k, la probabilité de réussir les k essais indépendants d'une même tâche, ce qui met en évidence des défauts de constance que masquent les scores pass@1 moyennés.

Discipline du cycle de développement consistant à concevoir d'abord les agents et les prompts en fonction des évals. Des jeux de données de référence soigneusement constitués (environ 50 à 500 cas, pondérés vers les modes de défaillance connus) sont versionnés aux côtés des prompts, exécutés comme suite de non-régression à chaque pull request, et la fusion ou la promotion est conditionnée à des seuils de métriques. Le pipeline fige les versions du modèle et du juge, si bien qu'une mise à jour silencieuse du modèle côté fournisseur est détectée comme une régression au lieu d'être absorbée en douce ; il enchaîne ses vérifications sous forme de lint, puis d'éval hors ligne, puis d'un garde-fou sur les coûts avant qu'un changement ne puisse être fusionné. À distinguer de agent-observability-tracing, qui relève de la télémétrie à l'exécution et non d'un contrôle avant fusion, et des benchmarks publics figés, qui ne sont pas des suites de non-régression détenues par l'équipe dans la CI.

Le versant déploiement de la mise en production sécurisée d'une version d'agent ou de prompt. Le candidat s'exécute d'abord en mode fantôme : il tourne sur le trafic de production réel, mais sa sortie est masquée aux utilisateurs et comparée hors ligne à la version en service, puis il passe à une phase canary sur 1 à 5 pour cent du trafic réel, noté par des évals en ligne face à un groupe témoin, puis à une montée en charge progressive, avec rollback automatique dès qu'une métrique surveillée se dégrade. Coupler les évals en ligne (qui notent le trafic réel à la volée) aux évals hors ligne permet de détecter les défaillances de longue traîne qu'un jeu de référence statique ne peut pas prévoir. À distinguer de eval-driven-agent-development, qui contrôle les changements hors ligne avant la fusion, tandis que ce modèle gouverne la montée en charge en ligne après la fusion.

Un simulateur d'utilisateur piloté par un LLM, paramétré selon des personas variés (utilisateurs désorientés, hostiles, impatients ou changeant d'objectif en cours de route), sert de banc d'essai qui pilote de façon autonome un agent conversationnel à travers de nombreux dialogues multi-tours. Exécuter ces conversations simulées à grande échelle fait apparaître les pertes de contexte, les violations de règles et les hallucinations avant que de vrais utilisateurs ne les rencontrent, en explorant des branches de l'arbre de dialogue que des cas de référence statiques à un seul tour ne peuvent pas atteindre. Cela exige une diversité délibérée des personas et un alignement sur les objectifs, afin d'éviter l'angle mort d'un simulateur unique et coopératif qui se comporte plus docilement que de vrais utilisateurs. À distinguer de tau-bench, un benchmark figé qui embarque un seul simulateur d'utilisateur, et de eval-driven-agent-development, dont les jeux de référence sont des cas statiques à un seul tour, alors que cette approche génère un trafic dynamique multi-tours.