Benchmarks d'évaluation d'agents : d'AgentBench à DeepEval, guide pratique des tests de performance

Vous testez un agent de service client sur 100 cas : taux de succès de 78 %. Pas mal, en apparence. Vous relancez exactement les mêmes tests : le taux tombe à 65 %.

L’évaluation d’agents n’a rien à voir avec l’évaluation classique des modèles de questions-réponses. Pour un LLM, vous demandez « Quelle est la capitale de la France ? » — « Paris » est correct, « Marseille » ne l’est pas, c’est binaire. Un agent, lui, réfléchit, planifie, appelle des outils, change d’avis en cours de route. Pour une même tâche, il peut réussir par le chemin A aujourd’hui, échouer par le chemin B demain, et réussir par le chemin C après-demain.

J’ai lu des tonnes de papers, parcouru la doc d’AgentBench, WebArena et autres benchmarks — et je m’y perdais. Ce n’est qu’après quelques échecs en projet que j’ai compris : on ne peut pas se contenter de regarder la ligne d’arrivée, il faut examiner la trajectoire.

1. Pourquoi l’évaluation d’agents est plus difficile que le Q&A classique ?

Le cœur du problème : l’autonomie. À chaque exécution, l’agent peut choisir un chemin différent.

Exemple concret. J’ai testé un agent de réservation de voyage avec la tâche « Réserver le vol le moins cher demain de Pékin à Shanghai ». Première exécution : il consulte Ctrip, compare trois vols, choisit le moins cher et passe commande — parfait. Deuxième exécution, même tâche : il consulte Ctrip, puis Fliggy, entre dans une boucle pendant cinq minutes et échoue par timeout.

Même entrée, trajectoires différentes. C’est là toute la difficulté : vous n’avez pas besoin d’un simple label « bon/mauvais », mais d’un cadre capable d’analyser l’ensemble du processus d’exécution.

Cadre d’évaluation à trois couches

Selon Anthropic, l’évaluation d’un agent doit se décomposer en trois niveaux :

Couche de raisonnement (Reasoning Layer) : la planification est-elle correcte ? L’agent a-t-il bien compris la tâche ? A-t-il établi un plan d’exécution raisonnable ?

Couche d’action (Action Layer) : les outils choisis sont-ils les bons ? Les paramètres sont-ils corrects ? L’ordre des appels d’outils est-il cohérent ?

Exécution globale (Overall Execution) : la tâche est-elle accomplie ? Combien d’étapes ont été nécessaires ? Quelle est l’efficacité ?

Un chiffre de la doc DeepEval m’a marqué : l’échec d’appel d’outil est le problème le plus fréquent chez les agents. Environ 40 % des échecs viennent d’un mauvais choix d’outil ou de paramètres incorrects. Conclusion : la plupart des problèmes se situent à la couche d’action, pas au raisonnement.

Limites des métriques traditionnelles

Pour le Q&A classique, la précision ou le F1 suffisent. Pas pour un agent.

Supposons un taux de succès de 78 %. Que vous apprend ce chiffre ? Presque rien.

Pourquoi ? Parce que 78 % peut signifier :

• planification correcte mais échec d’appel d’outil (problème de couche d’action)
• planification erronée dès le départ (problème de couche de raisonnement)
• planification et outils corrects, mais échec à la dernière étape (problème d’exécution globale)

Chaque cause d’échec appelle une optimisation différente. Planification défaillante → ajuster le prompt ou changer de modèle ; mauvais appel d’outil → revoir la définition des outils ou ajouter des validations ; échec en fin de parcours → souvent un problème de gestion des cas limites.

L’enjeu n’est donc pas « a-t-il réussi ? », mais « où a-t-il échoué ? ».

2. Comparaison de 5 benchmarks d’évaluation majeurs

Les benchmarks d’évaluation d’agents ne manquent pas. Voici cinq références mainstream que j’ai étudiées ou exécutées moi-même.

AgentBench : benchmark de capacités globales

AgentBench, publié par Tsinghua à ICLR’24, est l’un des premiers benchmarks complets dédiés aux LLM-as-Agent. Il couvre 8 environnements : requêtes base de données, navigation Web, appels API, exécution de code, etc.

Mon retour d’expérience : la couverture est réelle, idéale pour comparer des modèles candidats comme backbone d’agent. En revanche, l’installation est laborieuse (Docker requis), et le Dev set seul déclenche plus de 4 000 appels LLM — le coût monte vite.

🔥 Ne perdez plus des mois sur des produits sans demande ! Validez vos promesses SaaS avec Adsterra à petit budget →

Tester l'MVP →Pub

Cas d’usage : choisir un modèle backbone parmi plusieurs candidats pour un agent généraliste.

WebArena : spécialisé navigation Web

WebArena se concentre sur l’environnement Web. Il reconstruit des sites réels (e-commerce, forum, cartographie…) et demande à l’agent d’y accomplir des tâches de navigation.

Par exemple : « Trouver un post sur Reddit et y commenter ». Il teste la capacité de l’agent à opérer dans un Web authentique.

Cas d’usage : agent navigateur ou automatisation Web.

τ-Bench : test du dialogue multi-tours

τ-Bench (prononcé tau-bench), développé avec la participation d’Anthropic, cible les scénarios multi-tours. Il simule des contextes de service réels — retail, réservation aérienne — avec un rôle utilisateur simulé qui dialogue avec l’agent.

Particularité : il évalue la performance en conversation, pas seulement la complétion d’une tâche en un tour.

Cas d’usage : agent de service client, agent de réservation, tout agent conversationnel.

SWE-Bench : benchmark de capacités code

SWE-Bench mesure spécifiquement les compétences de programmation. Il extrait de vrais issues et PR GitHub et demande à l’agent de corriger le code.

Benchmark exigeant : l’agent doit comprendre la structure du projet, localiser le bug et produire un correctif qui passe les tests.

Cas d’usage : assistant de programmation ou agent de correction de code.

Claw-Eval / ACE-Bench : nouveaux benchmarks 2026

Claw-Eval (renommé ACE-Bench) est apparu en 2026 avec une difficulté configurable. Vous ajustez le niveau des tâches selon les capacités de votre agent.

Bonne idée : l’évaluation n’est pas ponctuelle, elle est continue. Quand l’agent progresse, la difficulté suit.

Cas d’usage : évaluation sur mesure en entreprise, ou système d’évaluation itératif durable.

Aide à la sélection de benchmark

Il n’y a pas de réponse universelle — tout dépend de votre scénario :

Mon conseil : commencer par AgentBench pour établir une baseline globale, puis approfondir avec un benchmark spécialisé selon votre cas d’usage.

3. Système de métriques d’évaluation d’agents

Passons aux indicateurs concrets. Voici six catégories de métriques qui couvrent l’essentiel.

1. Taux de succès (Success Rate)

La métrique la plus directe : la tâche est-elle accomplie ?

Mais attention au piège : que signifie « accompli » ? L’agent le déclare-t-il lui-même, ou faut-il un critère objectif ?

Ma pratique actuelle : définir des conditions d’acceptation explicites. Pour « réserver un vol », par exemple :

• numéro de commande existant
• informations de vol correctes
• prix dans la fourchette attendue

Plus les critères sont précis, plus le taux de succès est significatif.

2. Précision des appels d’outils

Deux dimensions : choisir le bon outil, transmettre les bons paramètres.

« Bon outil » signifie que l’agent sélectionne l’outil approprié au moment voulu. « Bons paramètres » signifie format et contenu corrects.

En projet, cette métrique révèle souvent les faiblesses cachées. J’ai eu un agent à 82 % de succès global, mais seulement 68 % de précision sur les outils — il confondait régulièrement « consulter » et « réserver ».

3. Taux de progression (Progress Rate)

Pour les tâches multi-étapes, le taux de progression indique jusqu’où l’agent est allé.

Une tâche en 5 étapes, l’agent échoue à la 4e : taux de succès 0 %, taux de progression 80 %. Ensemble, ces chiffres montrent que l’agent est proche du but — peut-être qu’une optimisation de la dernière étape suffit.

4. Métriques de qualité du raisonnement

Ces métriques évaluent la capacité de planification :

PlanQuality (qualité de planification) : le plan est-il raisonnable ? La logique entre les étapes est-elle cohérente ?

PlanAdherence (adhérence au plan) : l’exécution réelle s’écarte-t-elle du plan initial ?

Vultr - Serveur cloud NVMe haute performance, 32 emplacements mondiaux, déploiement Docker en un clic

Voir les tarifs →Pub

Ces métriques nécessitent un LLM évaluateur. PlanQualityMetric de DeepEval fonctionne ainsi : un autre LLM juge la qualité de planification de l’agent.

5. Métriques d’efficacité

StepEfficiency (efficacité des étapes) : combien d’étapes pour accomplir la tâche ? Quel est le minimum théorique ?

Si 3 étapes suffisent et l’agent en prend 10, StepEfficiency = 30 %.

La consommation de tokens compte aussi — directement liée au coût. Même tâche accomplie : 1 000 tokens vs 5 000 tokens, soit 5 fois la différence de coût.

6. Métriques de stabilité

L’agent est-il stable ? Même tâche exécutée 10 fois : quelle est l’écart-type du taux de succès ?

Je l’avais sous-estimée, jusqu’à ce qu’un agent performant en test devienne très instable en production. Cause : le timeout en production était plus court qu’en test, tronquant une partie des tâches.

Correspondance métriques / cadre à trois couches

Un indicateur faible pointe directement la couche concernée — et la direction d’optimisation.

4. Outils d’évaluation open source : DeepEval vs LangSmith vs Arize Phoenix

Métriques définies, quel outil pour les mesurer ? Comparaison de trois frameworks open source majeurs.

DeepEval : référence pour l’évaluation par composants

DeepEval est un framework Python open source de Confident AI, dédié à l’évaluation de LLM et d’agents.

Sa force : l’évaluation par composants. Vous insérez l’évaluation à n’importe quel nœud de l’agent, pas seulement au résultat final.

Six métriques intégrées :

• TaskCompletionMetric (complétion de tâche)
• StepEfficiencyMetric (efficacité des étapes)
• ToolCorrectnessMetric (exactitude des outils)
• ArgumentCorrectnessMetric (exactitude des paramètres)
• PlanQualityMetric (qualité de planification)
• PlanAdherenceMetric (adhérence au plan)

Sur un projet d’agent de réservation voyage, DeepEval a très bien fonctionné. Le décorateur @observe trace automatiquement raisonnement et appels d’outils, puis évalue couche par couche.

DeepEval propose aussi la plateforme Confident AI pour visualiser les résultats et gérer les jeux de données. La partie open source suffit largement pour démarrer.

LangSmith : officiel LangChain

Si vous développez avec LangChain, LangSmith est le choix le plus naturel. Intégration native, traçage automatique de toute la chaîne d’exécution.

Point fort : traçage de bout en bout. Chaque appel LLM, chaque exécution d’outil — la trajectoire complète est visible.

Produit commercial avec tarification. Adapté aux tests à petite échelle ; les coûts montent en évaluation massive.

Arize Phoenix : observabilité avant tout

Arize Phoenix repose sur OpenTelemetry et se concentre sur l’observabilité.

Approche : traiter l’exécution de l’agent comme un système distribué. Appels LLM et outils = Spans, trajectoire complète = Trace.

Particulièrement adapté à la surveillance en production : détection d’anomalies, analyse de performance.

Aide à la sélection d’outil

Utilisez-vous LangChain ?
  → Oui : privilégiez LangSmith (intégration native)
  → Non : surveillance en production nécessaire ?
       → Oui : Arize Phoenix + DeepEval
       → Non : évaluation en développement → DeepEval

Ma combinaison habituelle : DeepEval en développement, Arize Phoenix en production. Les deux se complètent.

5. Code en pratique : évaluer un agent de réservation voyage avec DeepEval

Assez de théorie — voici un exemple complet de code DeepEval, testé sur un projet réel d’agent de réservation voyage.

Implémentation de l’agent

Définissons d’abord un agent simple, avec le décorateur @observe pour tracer chaque composant :

from deepeval.tracing import observe
from deepeval.metrics import (
    PlanQualityMetric,
    PlanAdherenceMetric,
    ToolCorrectnessMetric,
    ArgumentCorrectnessMetric,
    TaskCompletionMetric,
    StepEfficiencyMetric
)

# 定义工具
@observe(type="tool")
def search_flights(origin: str, destination: str, date: str):
    """搜索航班"""
    # 实际项目中这里会调用真实的 API
    # 示例返回模拟数据
    return [
        {"flight": "CA1234", "price": 500, "time": "08:00"},
        {"flight": "MU5678", "price": 450, "time": "10:30"},
        {"flight": "CZ9012", "price": 520, "time": "14:00"}
    ]

@observe(type="tool")
def book_flight(flight_number: str, passenger_info: dict):
    """预订航班"""
    # 实际项目中这里会调用真实的预订 API
    return {"order_id": "ORD123456", "status": "confirmed"}

# Agent 主体
@observe(type="agent")
def travel_agent(user_input: str):
    """
    旅行预订 Agent
    输入：用户的预订请求
    输出：预订结果或失败信息
    """
    # 推理层：解析任务并制定计划
    @observe(type="reasoning")
    def parse_and_plan(input_text):
        # 这里应该调用 LLM 来解析和规划
        # 示例使用简单的规则解析
        plan = {
            "task": "book_flight",
            "origin": "北京",
            "destination": "上海",
            "date": "明天",
            "steps": ["search", "compare", "book"]
        }
        return plan

    plan = parse_and_plan(user_input)

    # 行动层：执行工具调用
    # 步骤1：搜索航班
    flights = search_flights(
        plan["origin"],
        plan["destination"],
        plan["date"]
    )

    # 步骤2：选择最便宜的航班
    cheapest = min(flights, key=lambda x: x["price"])

    # 步骤3：预订
    result = book_flight(
        cheapest["flight"],
        {"name": "测试用户"}
    )

    return result

Configuration des métriques d’évaluation

from deepeval import evaluate
from deepeval.test_case import LLMTestCase

# 定义测试数据
test_cases = [
    LLMTestCase(
        input="预订明天从北京到上海最便宜的航班",
        expected_output={"order_id": "ORD123456", "status": "confirmed"}
    ),
    LLMTestCase(
        input="帮我查一下下周三从广州到深圳的航班",
        expected_output={"flights": [...]}
    )
]

# 配置评估指标
metrics = [
    TaskCompletionMetric(
        threshold=0.7,
        evaluation_model="gpt-4o"
    ),
    StepEfficiencyMetric(
        threshold=0.5,  # 期望至少 50% 效率
        minimum_steps=3  # 最少需要 3 步
    ),
    ToolCorrectnessMetric(
        threshold=0.8
    ),
    ArgumentCorrectnessMetric(
        threshold=0.8
    ),
    PlanQualityMetric(
        threshold=0.7,
        evaluation_model="gpt-4o"
    )
]

Exécution de l’évaluation

# 方法1：单次评估
for test_case in test_cases:
    result = travel_agent(test_case.input)
    test_case.actual_output = result

evaluate(test_cases, metrics)

# 方法2：数据集批量评估
from deepeval.dataset import EvaluationDataset, Golden

dataset = EvaluationDataset(goldens=[
    Golden(input="预订明天从北京到上海最便宜的航班"),
    Golden(input="查找下周从成都到昆明的航班信息")
])

for golden in dataset.evals_iterator(metrics=metrics):
    output = travel_agent(golden.input)
    # 评估会自动记录和计算

Interprétation des résultats

DeepEval affiche le score et le statut de passage pour chaque métrique. Supposons :

Que retenir ?

• Taux de complétion élevé (85 %) : la plupart des tâches aboutissent
• Efficacité des étapes faible (45 %) : l’agent emprunte probablement des chemins superflus
• Choix d’outils excellent (90 %), mais paramètres insuffisants (72 %)

Direction d’optimisation claire : corriger la logique de construction des paramètres et réduire les étapes inutiles.

6. Pratiques d’évaluation en environnement de production

L’évaluation en développement terminée, l’agent est en ligne — le travail est loin d’être fini.

Railway - Plateforme de déploiement moderne, sans opérations complexes, en ligne en quelques minutes

Commencer →Pub

En production, le comportement diffère : entrées utilisateur plus aléatoires, plus de cas limites, charge concurrentielle. Il faut une boucle complète du développement à la production.

Phase de développement : établir une baseline

Objectif : définir la ligne de référence des capacités de l’agent.

Commencer par un benchmark global comme AgentBench, puis un jeu de données personnalisé pour les scénarios concrets. Couvrir tâches typiques, cas limites et échecs connus.

Checklist de la phase développement :

• couverture du jeu de test ≥ 80 % des scénarios utilisateur
• valeur de référence explicite pour chaque métrique
• enregistrement des échecs et analyse de leur distribution

Phase de déploiement : déploiement progressif et tests A/B

Ne pas basculer en production d’un coup. Commencer par un déploiement progressif.

Principe : comparer les performances du groupe de traitement (nouvelle version) et du groupe témoin (ancienne version).

# 灰度评估示例
def ab_test_evaluation():
    # 对照组：旧版本 Agent
    control_results = evaluate_agent(old_agent, test_cases)

    # 灰度组：新版本 Agent
    treatment_results = evaluate_agent(new_agent, test_cases)

    # 对比关键指标
    comparison = {
        "success_rate": {
            "control": control_results.success_rate,
            "treatment": treatment_results.success_rate,
            "delta": treatment_results.success_rate - control_results.success_rate
        },
        "step_efficiency": {
            "control": control_results.step_efficiency,
            "treatment": treatment_results.step_efficiency,
            "delta": treatment_results.step_efficiency - control_results.step_efficiency
        }
    }

    return comparison

Progression recommandée : 1 % → observer 24 h → 5 % → 10 % → 20 % → 50 % → 100 %. À chaque palier, surveiller l’évolution des métriques clés.

Phase de production : surveillance continue

En production, l’évaluation devient de la surveillance.

Priorité : détection d’anomalies — chute soudaine du taux de succès, latence anormale, échec massif d’un outil. Les alertes doivent arriver avant que les utilisateurs ne signalent le problème.

Stratégie d’échantillonnage : impossible d’évaluer chaque requête en production.

• Tâches ordinaires : échantillon 1 % à 5 %
• Tâches critiques (paiement, réservation) : évaluation à 100 %
• Requêtes anormales (échec, timeout) : 100 % en file d’évaluation

Contrôle des coûts : l’évaluation coûte aussi, surtout avec un LLM pour la qualité du raisonnement.

• Petit modèle évaluateur (gpt-4o-mini)
• Évaluation asynchrone, sans bloquer le flux principal
• Circuit breaker : plafond de 100 à 1 000 échantillons

Nécessité de la revue manuelle

L’évaluation automatique a ses limites — certains cas limites demandent un regard humain.

Ma pratique : les cas marqués « incertains » par l’évaluation automatique entrent en file de revue manuelle. Chaque semaine, 10 à 20 cas échantillonnés pour vérifier la précision de l’évaluation auto.

La revue manuelle révèle aussi ce que l’automatisation rate : ton inadapté, réponses confuses pour l’utilisateur — difficile à détecter automatiquement, mais très impactant sur l’expérience.

Boucle d’évaluation complète

Phase de développement
├── Benchmark AgentBench
├── Évaluation sur jeu de données personnalisé
└── Analyse des cas d'échec
    ↓
Phase de déploiement
├── Déploiement progressif (1 % → 5 % → 10 % → …)
├── Évaluation A/B comparative
└── Mécanisme de rollback
    ↓
Phase de production
├── Surveillance par échantillonnage (1 % à 5 %)
├── Alertes de détection d'anomalies
├── File de revue manuelle
    ↓
Itération d'optimisation
├── Attribution des échecs
├── Ajustement prompts / outils
└── Réévaluation
    ↓ (boucle)

Processus itératif, pas un one-shot. Les capacités de l’agent peuvent régresser, les scénarios utilisateur évoluent, de nouveaux problèmes apparaissent — l’évaluation doit suivre.

Conclusion

En résumé : ne regardez pas seulement la ligne d’arrivée, examinez la trajectoire.

Mes erreurs passées : croire que 78 % de succès suffisait, puis découvrir en production une variance de 30 % sur la même tâche. Penser que les appels d’outils étaient solides, alors que 40 % des échecs venaient de paramètres incorrects. Croire que l’évaluation en développement suffisait, alors que la production est un monde différent.

Le cadre à trois couches a clarifié ma démarche : raisonnement pour la planification, action pour les outils, exécution globale pour le résultat. Les cinq benchmarks ont posé une baseline : AgentBench pour le global, τ-Bench pour le multi-tours, SWE-Bench pour le code. DeepEval a rendu l’évaluation exécutable en code : décorateur @observe, six métriques, analyse couche par couche.

Prochaines étapes :

1. Tester votre agent avec AgentBench pour établir une baseline
2. Utiliser DeepEval pour une évaluation par composants et identifier les faiblesses
3. Mettre en place une surveillance en production : détection d’anomalies + revue manuelle

L’évaluation n’est pas une destination, c’est un point de départ. À mesure que l’agent évolue, l’évaluation doit évoluer avec lui.