Rubriques d'évaluation d'agent qui voyagent à travers les piles

Définition d'une rubrique prête à voyager

Je commence par écrire la rubrique avant de regarder la sortie du modèle. La rubrique doit contenir trois axes indépendants : la réussite de la tâche, la correction de l'outil et la fidélité. Chaque axe obtient son propre guide de notation qui ne mentionne pas le nom du modèle, la version du framework ou le libellé exact de l'invite. Je garde les guides dans un fichier texte brut qui vit à côté de la suite de tests afin que quiconque puisse les vérifier.

Propriétés de base

- Critères préenregistrés – les conditions de réussite sont écrites avant la première exécution. - Isolement des axes – les scores d'un axe ne se mélangent jamais avec un autre. - Langage sans version – éviter les phrases comme « à partir de GPT-4 » ou « lors de l'utilisation de LangChain 0.1 ».

Lorsque je suis ces propriétés, la même rubrique me donne des nombres comparables que je fasse fonctionner l'agent avec OpenAI's GPT-4o, Anthropic's Claude 3 ou un modèle local Llama 3.

Pourquoi la réussite de la tâche doit être basée sur le résultat

La réussite de la tâche répond à la simple question : l'agent a-t-il terminé ce qui lui a été demandé? Je juge cela contre une liste de contrôle qui examine l'état final du monde, et non le libellé de la réponse. Par exemple, si la tâche est « mettre à jour l'adresse e-mail de l'utilisateur vers alice@example.com », je vérifie l'enregistrement de la base de données après l'exécution. Je ne me soucie pas de savoir si l'agent a dit « J'ai mis à jour votre e-mail » ou « Votre e-mail est maintenant alice@example.com ».

Liste de contrôle concrète

- Précondition vérifiée (par exemple, l'utilisateur existe). - Postcondition vérifiée (par exemple, le champ e-mail est égal à alice@example.com). - Aucun effet secondaire supplémentaire (par exemple, aucun autre champ n'a été modifié). - Facultatif : latence inférieure à un seuil (par exemple, 2 secondes).

J'enregistre un résultat binaire pass/fail pour chaque trajectoire. Si l'agent échoue à la postcondition, le score de réussite de la tâche est zéro, quel que soit à quel point la prose semble fluide.

La correction de l'outil comme axe séparé

La correction de l'outil examine les appels que l'agent effectue vers des API externes, des fonctions ou des bases de données. Je traite chaque appel comme une mini-expérience : l'agent a-t-il choisi l'outil correct, a-t-il passé les arguments corrects et l'a-t-il appelé le bon nombre de fois? Je suis les conseils des feuilles de triche OWASP sur l'utilisation sécurisée des outils, par exemple la feuille de triche LLM Prompt Injection Prevention et la feuille de triche SQL Injection Prevention pour éviter l'injection accidentelle.

Rubrique de notation

- Outil correct sélectionné – 1 point. - Tous les arguments correspondent au schéma – 1 point par argument. - Aucun appel supplémentaire – 1 point si le nombre d'appels est égal au nombre attendu. - Aucun effet secondaire interdit (par exemple, écriture dans un journal qui devrait rester en lecture seule) – 1 point.

Le score de l'axe est la somme des points divisée par le nombre maximum de points possibles. Je garde cet axe séparé afin qu'une erreur dans l'utilisation de l'outil ne cache pas une réussite dans la réalisation de la tâche.

Fidélité : traçage de chaque affirmation

La fidélité demande si chaque affirmation dans la sortie de l'agent peut être traçée jusqu'aux résultats de l'outil ou au contexte qui a été donné au modèle. Je traite la sortie comme un ensemble d'affirmations et je vérifie chaque affirmation contre les preuves. Si une affirmation ne peut pas être étayée, je la marque comme une hallucination. Cet axe est le plus important lorsque l'agent résume des documents, cite des sources ou répond à des questions qui nécessitent des données externes.

Vérification étape par étape

- Divisez la sortie en phrases atomiques. - Pour chaque phrase, listez les faits qu'elle affirme. - Faites correspondre chaque fait à une ligne dans la sortie de l'outil ou à un extrait du contexte fourni. - Si un fait n'a pas de correspondance, comptez-le comme un échec. - Score de fidélité = (nombre de faits étayés) / (nombre total de faits).

J'enregistre les comptes bruts afin que je puisse voir si une baisse de fidélité provient de quelques grandes hallucinations ou de nombreuses petites erreurs.

Ce que cela n'est PAS

Je veux être clair sur les limites d'une rubrique prête à voyager. Elle ne garantit pas que l'agent est sécurisé, peu coûteux ou rapide. Elle ne promet pas une précision de 100 % sur chaque entrée possible. Elle ne remplace pas un examen de sécurité dédié, une analyse de coûts ou un benchmark de latence. La rubrique ne mesure que les trois axes que j'ai définis ci-dessus. Si vous avez besoin de savoir si l'agent divulgue des clés privées, vous devez exécuter un contrôle de gestion des secrets séparé, par exemple en utilisant la feuille de triche Secrets Management.

En résumé, la rubrique est un outil pour comparer la qualité de l'agent entre les piles, et non une solution miracle pour toutes les préoccupations de production.

Construction de trajectoires comparables

Une trajectoire est le journal complet de ce qui s'est passé pendant une exécution : l'invite initiale, chaque appel d'outil avec ses arguments et résultats, et la sortie finale du modèle. Je stocke chaque trajectoire comme un objet JSON avec un schéma fixe afin que je puisse diffuser les exécutions automatiquement. Ci-dessous se trouve un exemple du schéma que j'utilise.

Champ | Type | Description invite | chaîne | L'invite exacte envoyée au modèle. appels | tableau | Liste ordonnée des exécutions d'outils. appels[].outil | chaîne | Nom de l'outil ou de l'API. appels[].args | objet | Arguments passés à l'outil. appels[].résultat | n'importe quel | Sortie brute de l'outil. sortie | chaîne | Texte final retourné par le modèle. métadonnées | objet | Balises facultatives telles que le nom du modèle, la version du framework, la date.

Puisque le schéma ne change jamais, je peux calculer les scores des trois axes pour chaque trajectoire en utilisant les mêmes scripts. Je garde un ensemble maître de trajectoires qui couvre les tâches principales que je livre et les modes d'échec courants que j'ai vus. Lorsque je modifie le modèle, je réexécute les mêmes trajectoires et je compare les nouveaux scores à la référence.

Exécution d'évaluations sur chaque modification

J'intègre l'étape d'évaluation dans mon pipeline d'intégration continue. Le pipeline effectue les opérations suivantes sur chaque commit qui peut affecter le comportement :

- Vérifiez le code le plus récent. - Installez les dépendances de l'agent. - Exécutez l'agent contre l'ensemble de trajectoires fixe. - Analysez les journaux et calculez les scores de réussite de la tâche, de correction de l'outil et de fidélité. - Publiez les résultats sur un tableau de bord et signalez toute axe qui chute de plus de cinq pour cent par rapport à la construction verte précédente.

Cette pratique attrape les régressions tôt. Par exemple, lorsque j'ai changé la bibliothèque de récupération sous-jacente, l'axe de correction de l'outil est tombé de 0,96 à 0,82 car la nouvelle bibliothèque a retourné des résultats dans un ordre différent, ce qui a provoqué l'agent pour faire des appels supplémentaires. La chute est apparue dans le rapport CI avant qu'un utilisateur ne remarque un problème.

Je garde également un ensemble de vingt trajectoires évaluées par un humain. Chaque mois, je note ces trajectoires avec une personne et je compare la moyenne aux scores automatiques. Si le juge automatique dérive, je recalibre la rubrique ou je réentraîne le modèle de juge.

Liste de contrôle de l'opérateur pour les rubriques d'évaluation d'agent qui voyagent à travers les piles

Je garde une liste de contrôle écrite à côté de chaque version qui touche ce sujet. La liste est ennuyeuse à dessein : nommez le propriétaire, nommez l'artefact de preuve et nommez le rollback. Si une étape ne peut pas produire un fichier, un ticket ou une ligne de journal, ce n'est pas une étape — c'est un vœu.

Avant de modifier la production

- Gélez la branche ou la révision de configuration que vous allez mesurer. - Enregistrez le mode d'échec actuel avec une entrée concrète et une sortie concrète. - Confirmez quelle identité le travail s'exécute sous, et si cette identité peut accéder à des données qu'elle ne devrait pas. - Ouvrez les références principales que vous allez citer : https://cheatsheetseries.owasp.org/cheatsheets/LLM_Prompt_Injection_Prevention_Cheat_Sheet.html, https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html.

Pendant que vous exécutez le contrôle

- Préférez un chemin reproductible à dix captures d'écran anecdotiques. - Écrivez le résultat sécurisé attendu avant de déclencher l'outil ou la requête. - Capturez la commande exacte, l'invite, le schéma ou l'expression régulière sous test — et non une paraphrase. - Si le système peut agir (envoyer, écrire, supprimer, transférer), exigez une limite de confirmation dans le même passage.

Après avoir terminé

- Enregistrez le risque résiduel avec un propriétaire et une date, même lorsque l'analyse est propre. - N'convertissez pas un contrôle vert en langage de vente qui prétend une complétude. - Réexécutez la même liste de contrôle lorsque le modèle, le schéma de l'outil ou les règles de validation changent.

Signal | Ce que vous devez enregistrer | Arrêt de l'expédition? Écriture ou envoi inattendu | Nom de l'outil, arguments, identité | Oui jusqu'à ce que cela soit géré Manque de confirmation sur une action destructive | Chemin d'appel et contournement | Oui Texte non fiable traité comme instruction | Surface source et action résultante | Oui pour la portée de l'agent Analyseur propre, jugement ouvert | Éléments différés + propriétaire | Seulement si le chemin principal est sécurisé

agenteval aide pour le premier passage mesurable. Les choix d'architecture, la validation légale et les affirmations orientées client nécessitent toujours un propriétaire humain. Traitez chaque ligne de la liste de contrôle comme un support de décision, et non comme un certificat.

Comment j'explique les limites aux acheteurs

Lorsqu'un prospect demande si le produit « couvre tout », je réponds avec la limite : les contrôles automatisés détectent les modèles connus ; les chaînes nouvelles et le jugement de politique nécessitent toujours un examen. Cette honnêteté garde la charge de support basse et garde le blog aligné sur ce que le produit fait réellement.

Si vous avez besoin d'un deuxième avis, associez cet article avec les références ci-dessous et avec votre propre reproduction de mise en scène. N'omettez pas l'étape de reproduction simplement parce qu'un modèle a écrit un résumé confiant.

Références

- https://cheatsheetseries.owasp.org/cheatsheets/LLM_Prompt_Injection_Prevention_Cheat_Sheet.html - https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html - https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html - https://docs.agents-squads.com/guides/config-files

Questions fréquentes

Combien de cas de test avons-nous besoin?

Assez pour couvrir les tâches que vous livrez réellement et les façons dont elles échouent. Un petit nombre de trajectoires bien choisies bat un grand ensemble de cas faciles.

Pouvons-nous juger les sorties avec un autre modèle?

Vous pouvez, mais enregistrez que le juge est un modèle et gardez un échantillon fixe noté par des humains, afin que vous puissiez voir si le juge lui-même a dérivé.

Qu'est-ce que la fidélité, concrètement?

Si chaque affirmation dans la sortie est étayée par les résultats de l'outil ou le contexte que l'agent a reçu, plutôt que produite à partir des propres a priori du modèle.

Devrions-nous noter uniquement la réponse finale?

Non. Notez la trajectoire également — les appels d'outils sont là où la plupart des échecs de l'agent se produisent.

Combien de fois les évaluations doivent-elles s'exécuter?

À chaque modification qui peut affecter le comportement : invite, modèle, liste d'outils ou configuration de récupération.

Un bon score signifie-t-il que l'agent est sécurisé?

Non. Cela signifie qu'il a performé bien sur les tâches que vous avez testées. La sécurité, le coût et la gestion des échecs sont des évaluations distinctes.

Références

- NIST — AI Risk Management Framework - Stanford CRFM — HELM (Holistic Evaluation of Language Models)

Essayez le produit : AgentGrade

2026-09-20 · sources primaires uniquement · aucun métrique de trafic fabriqué · support de décision uniquement

Articles liés

- Évaluation hors ligne vs surveillance en ligne pour les agents IA - Explorez la matrice complète des sujets de micro-SaaS IA →