Aller au contenu principal

Évaluer votre agent d'IA

Avancé
What you'll learn
  • Comprendre pourquoi les évaluations d'agents diffèrent des évaluations de prompts — la trajectoire compte, pas seulement la réponse finale
  • Construire un golden set de 20 à 100 cas réels avec des critères de réussite clairs
  • Noter quatre couches : justesse des appels d'outils, qualité de trajectoire, succès de la tâche, dérive en production
  • Utiliser LLM-as-judge en toute sécurité : rubrique d'abord, calibrage contre les humains, vérification ponctuelle des verdicts
  • Livrer une évaluation qui tourne en CI et fait échouer un mauvais changement avant qu'il n'atteigne les utilisateurs

Une évaluation d'agent répond à une question plus difficile que « le prompt a-t-il renvoyé les bons mots ? ». Elle demande : un modèle exécuté en boucle a-t-il choisi les bons outils, dans le bon ordre, avec les bons arguments, est-il arrivé au bon résultat — et est-il resté dans les limites de budget et de sécurité ?

Sautez cette étape et vous livrerez un agent « utile » qui régresse silencieusement chaque fois que vous ajustez le system prompt.

Pourquoi les agents ont besoin de leurs propres évaluations​

Une évaluation de prompt unique note une entrée → une sortie. Un agent produit une trajectoire : une chaîne de raisonnement, d'appels d'outils, d'observations intermédiaires et de révisions sur plusieurs tours. Deux modes de défaillance rendent cela difficile :

  • Bonne réponse, mauvais chemin. L'agent tombe sur la bonne sortie après des boucles inutiles, des actions dangereuses ou des devinettes chanceuses. Les évaluations basées uniquement sur la réponse finale marquent cela comme réussi ; la production ne le fera pas.
  • Mauvaise réponse, chemin plausible. Chaque étape semble raisonnable isolément, mais l'agent a mal utilisé un outil, ignoré une contrainte ou halluciné un fait intermédiaire. Il faut regarder la trace, pas seulement la réponse.

Les quatre couches d'évaluation​

Empilez-les de la moins coûteuse à la plus coûteuse afin qu'un mauvais changement échoue rapidement sans attendre des correcteurs onéreux.

Guided walkthrough1 of 4
  1. Pour chaque étape attendue, vérifiez que le nom de l'outil correspond, que les paramètres requis sont présents et que les types sont validés. Code pur, millisecondes, aucun modèle nécessaire. Attrape le « a appelé search alors qu'il aurait dû appeler write_file » avant tout le reste.

Les métriques qui prédisent la valeur​

Toutes les métriques ne méritent pas leur place sur le dashboard. Ces cinq-là dictent les décisions de mise en production en 2026 :

MétriqueCe qu'elle mesurePourquoi elle compte
Taux de succès des tâches% des cas du golden set que l'agent termine correctementLe chiffre phare. Tout le reste est diagnostique.
Coût par tâche réussie$ / cas réussi (tokens in + out, coûts d'outils)Réussir à 10× le coût est une régression.
Latence (p50 / p95)Temps réel par tâche, queue incluseLe p95 est ce que ressentent les vrais utilisateurs — les moyennes mentent.
Précision des appels d'outils% des appels d'outils attendus avec nom + args correctsPrédit la qualité de trajectoire ; peu coûteux à calculer.
Taux d'intervention% des tâches nécessitant une prise en main humaine en prodLe chiffre d'autonomie. En hausse = confiance en baisse.

Suivez-les ensemble — l'une qui bouge sans les autres est généralement un signal précurseur, pas du bruit.

Construire le golden set​

Guided walkthrough1 of 5
  1. Extrayez 20 à 100 tâches de l'usage réel (logs, tickets de support, requêtes utilisateurs). Couvrez le chemin facile fréquent, le milieu délicat et les cas limites qui vous ont déjà mordu.

LLM-as-judge — pas cher, rapide, mais calibrez-le​

Noter à la main des sorties floues ne passe pas à l'échelle. Un modèle capable lisant selon une rubrique explicite, si — le propre guide de méthodologie d'évaluation d'Anthropic recommande ce pattern pour le ton, la fidélité, l'utilité et la sécurité.

Les juges ont des biais bien documentés : ils préfèrent les réponses plus longues, la première option montrée, et les sorties qui reprennent leurs propres formulations. Trois habitudes les gardent honnêtes :

  • Rubrique, pas ressentis. « Notez l'utilité de 1 à 5 » est inutile. Ancrez chaque point de l'échelle à un comportement observable.
  • Calibrez sur un échantillon annoté par humains. Faites noter 30 à 50 cas par des humains ; mesurez l'accord juge-vs-humain (visez un κ de Cohen ≥ 0,6). S'il diverge, resserrez la rubrique.
  • Utilisez un modèle différent comme juge. Noter avec le même modèle qui a produit la sortie induit du biais dans les deux sens.
  • Vérifiez les verdicts par échantillonnage hebdomadaire. Lisez 10 scores aléatoires du juge et leur raisonnement. C'est le moyen le moins cher de détecter la dérive.

Modèle de rubrique LLM-as-judge

You are grading an AI assistant's response against a rubric. Be strict. Cite exact evidence from the response.

<task>{task}</task>
<response>{response}</response>

Rubric (rate 1–5 per dimension):
- Task completion: 1 = ignored task; 3 = partial; 5 = fully done, no gaps.
- Faithfulness: 1 = contains false claims; 3 = mostly grounded, one soft claim; 5 = every claim traceable to input/tools.
- Efficiency: 1 = wandered/looped; 3 = extra steps; 5 = minimum viable path.

Output JSON only:
{"task_completion": N, "faithfulness": N, "efficiency": N, "evidence": "<quote>", "verdict": "pass"|"fail"}

Prompt de revue de trajectoire (Couche 2)

You are auditing an AI agent's tool-call trajectory. The goal was: {goal}
Expected minimum steps: {n_min}

<trajectory>
{list of tool_name(args) -> result, in order}
</trajectory>

Answer in JSON:
{"steps_taken": N, "wasted_steps": N, "wrong_tool_calls": [<indices>], "unsafe_actions": [<indices>], "verdict": "pass"|"fail", "reason": "<one sentence>"}

Générateur de cas adversariaux (faire croître le set)

Generate 5 new eval cases that are likely to break an agent whose current failures cluster around: {failure_pattern}.

For each case give: input, expected output OR pass criterion, ideal tool sequence, and why this case is hard.

Return YAML.

Gate CI : faire échouer le mauvais changement avant qu'il ne parte​

L'évaluation ne rapporte que lorsqu'elle bloque automatiquement les régressions. Branchez-la dans la CI comme un check sur chaque changement de prompt / modèle / outil :

# tests/eval_gate.py — runs on every PR
import json, sys
from anthropic import Anthropic
from my_agent import run_agent

client = Anthropic()
golden = json.load(open("evals/golden.v3.json"))

results = []
for case in golden:
    trace = run_agent(case["input"])
    layer1 = tool_calls_match(trace, case["expected_tools"])   # deterministic
    layer3 = judge(client, case, trace.final_output)           # LLM rubric
    results.append({"id": case["id"], "layer1": layer1, "layer3": layer3["verdict"]})

pass_rate = sum(r["layer3"] == "pass" for r in results) / len(results)
tool_acc  = sum(r["layer1"] for r in results) / len(results)

# Gates — tighten over time
assert pass_rate >= 0.85, f"Task success dropped to {pass_rate:.0%}"
assert tool_acc  >= 0.90, f"Tool-call accuracy dropped to {tool_acc:.0%}"
print(f"PASS: task={pass_rate:.0%} tools={tool_acc:.0%}")

Stockez les scores par run pour pouvoir tracer la tendance. Une chute de 3+ points entre deux merges est une vraie régression, pas du bruit.

Anti-patterns qui font sous-livrer les évaluations
  • Ne juger que la réponse finale — rate tous les bugs de trajectoire. Notez aussi les Couches 1 et 2.
  • Golden set statique — s'il ne grandit pas avec chaque échec de prod, il cesse de prédire la prod. Budgétez du temps chaque mois.
  • Même modèle comme agent et juge — biais dans les deux sens. Faites tourner vers un modèle différent pour la notation.
  • Pas de coût ni de latence dans le gate — un tweak de prompt qui ajoute 8 appels d'outils peut « passer » l'évaluation tout en multipliant la facture par 10.
  • Notation aux ressentis uniquement — « ça semble mieux » n'est pas une métrique. Si vous ne pouvez pas différencier deux nombres, vous ne pouvez pas livrer avec confiance.
Key takeaways
  • Les agents produisent des trajectoires, pas des réponses — évaluez le chemin, pas seulement le résultat
  • Empilez les couches du moins cher au plus cher : justesse des appels d'outils → qualité de trajectoire → succès de la tâche → dérive en production
  • Les cinq métriques qui décident du ship : taux de succès des tâches, coût par succès, latence p50/p95, précision des appels d'outils, taux d'intervention
  • LLM-as-judge passe à l'échelle, mais seulement avec une rubrique explicite, un modèle différent et un calibrage contre des annotations humaines
  • Un golden set qui ne grandit pas à partir des échecs de prod cesse de prédire la prod — faites-le croître chaque mois
  • Branchez l'évaluation dans la CI comme un gate strict — le check qui attrape une régression avant les utilisateurs

Testez-vous​

Testez-vous

0/4
  1. Pourquoi les agents ont-ils besoin d'évaluations de trajectoire, pas seulement d'évaluations de la réponse finale ?
  2. Vous empilez vos évaluations en couches. Quel ordre est du moins cher au plus cher et correct ?
  3. Quelle paire d'habitudes maintient réellement LLM-as-judge digne de confiance dans le temps ?
  4. Votre gate CI passe le taux de succès des tâches mais la latence et le coût par tâche ont doublé. Quel est le bon choix ?
Appuyez sur Entrée ou Espace pour retourner la carte. Utilisez les flèches gauche et droite pour naviguer entre les cartes.Terme affiché.
1 / 7

Suite​