2026-06-10 · Mis à jour 2026-07-22

[!NOTE] Traduction automatique Cet article a été traduit automatiquement depuis la version originale en anglais.

Évaluation des agents AI en production : des traces aux suites de tests

Un chatbot vous fournit une seule réponse à évaluer. Un agent, quant à lui, vous remet tout un arbre de décisions : des plans, tool calls, des tentatives de réessai, ainsi que le moment précis où il a décidé que la tâche était terminée.

Cette différence exige une méthode d’évaluation distincte. Une réponse finale peut sembler correcte même lorsque l’agent a omis un outil obligatoire, répété une requête 17 fois, interprété à tort un résultat, ou suivi un parcours interdit par la politique de production. L’évaluation basée uniquement sur la réponse masque ces échecs.

En résumé : L’évaluation des agents nécessite trois types de métriques : des métriques de résultat, des métriques de trajectoire et des métriques de composants. La structure doit reposer sur ce cycle : suivi → étiquetage → regroupement en clusters → suppression des doublons → versionnement de dataset → vérification via des pipelines CI → surveillance en temps réel. Il convient d’employer des vérifications déterministes pour le ordre des outils, leurs arguments, les boucles ainsi que les invariants. Les juges LLM ne doivent être utilisés que lorsque la vérification dépend d’une interprétation ; ces juges doivent alors être conçus à l’aide du raisonnement guidé par des schémas (SGR)), et calibrés à l’aide d’étiquettes fournies par des humains avant d’être considérés fiables.

Pourquoi les évaluations d’agents diffèrent

Les évaluations traditionnelles LLM ne prennent généralement en compte qu’une seule paire entrée-sortie : la pertinence, la fidélité, la correction, la sécurité, et éventuellement le style. Les agents introduisent en outre une phase de planification, tool calls, des tentatives répétées ainsi que des vérifications de terminaison, ce qui fait que chaque étape représente un nouveau point potentiel d’échec.

Prenez un agent de remboursement. La transcription peut se terminer correctement alors que le suivi est erroné :

lookup_order -> issue_refund -> final_answer

L’évaluation de la sortie est réussie. L’évaluation de la trajectoire devrait échouer car verify_identity N’a jamais été exécuté auparavant. issue_refundPour les agents utilisant des outils, les évaluations à réponse unique ne constituent que des tests de base : elles permettent de détecter des défaillances totales mais ignorent tout le reste.

Il existe un deuxième problème : les erreurs s’accumulent. Si un flux de travail comporte 20 étapes obligatoires, chacune s’exécutant de manière indépendante et présentant une fiabilité de 95 %, le taux de réussite global se situe autour de 36 % :

Ainsi, l’agent peut sembler fonctionnel lors des vérifications isolées tout en échouant dans la plupart des exécutions complètes. La cause de cet échec se situe généralement quelque part au milieu du processus, et sa détection nécessite une visibilité au niveau des composants, et non une simple réexamination de la réponse.

Deux équipes de recherche ont quantifié cette valeur.

tau-bench Il attribue à l’agent des tâches de service clientèle dans les domaines de la compagnie aérienne et du commerce de détail. L’agent dialogue avec un utilisateur simulé, effectue des appels vers APIs, et doit se conformer aux politiques propres au domaine. Après la conversation, le correcteur vérifie si la base de données a atteint l’état cible indiqué dans les annotations. Un enregistrement de dialogue plausible contenant des lignes incorrectes échoue également.

Dans ce cadre d’évaluation, même GPT-4o n’a réussi que moins de la moitié des tâches. La publication présente également pass^k: exécuter la même tâche k Comptez le nombre de tentatives uniquement si l’agent parvient à réussir toutes les étapes. k s’exécute.

Les scores de vente au détail qui semblaient acceptables lors d’une première tentative sont tombés en dessous de 25 % à k = 8Ce même agent a été confronté à la même tâche à huit reprises et a produit des résultats pour l’essentiel différents. Une évaluation effectuée en une seule exécution ne permet pas de mettre en évidence cette instabilité.

MAST Ces études analysent les causes des échecs des agents. Les auteurs ont annoté plus de 1 600 traces d’exécution provenant de 7 frameworks populaires multi-agent frameworks et ont classé ces échecs en 14 modèles récurrents. Cette taxonomie comprend des définitions de rôles trop vagues (conception système), un agent qui ignore ce que rapporte un autre agent (désalignement inter-agent), ainsi que la déclaration de succès sans vérification du résultat (absence de validation). Ces problèmes sont liés aux prompts, à la logique d’orchestration, et à l’absence de contrôles au sein des harness. Un modèle de base plus performant ne peut pas effectuer une étape de validation qui n’a jamais été implémentée ; par conséquent, l’objectif d’évaluation doit intégrer le harness entourant le modèle.

L’écart d’adoption

Selon l’enquête de LangChain, de nombreux répondants disposent déjà des éléments nécessaires pour améliorer les évaluations : 89 % ont indiqué disposer d’une certaine capacité d’observabilité, tandis que 52,4 % ont effectué des évaluations hors ligne et 37,3 % des évaluations en ligne.

Le même État de l’ingénierie des agents Les enquêtes indiquent que 57,3 % des répondants disposent déjà d’agents en environnement de production. Lorsqu’on leur a demandé quels facteurs entravaient la mise en production, 32 % ont cité la qualité et 20 % la latence. Il s’agit d’une enquête menée par le fournisseur auprès de ses propres clients, et non d’un recensement des équipes gérant des agents, mais elle met en évidence un écart important entre la collecte d’informations sur les traçages et une évaluation systématique.

Cela place les équipes dans une situation délicate : elles peuvent examiner un exécution défaillante a posteriori, mais risquent néanmoins de déployer à nouveau ce même défaut.

Chaque panne en production diagnostiquée doit laisser derrière elle une trace, une étiquette, une ligne dataset, ainsi qu’un scoreur. Une panne récurrente doit faire partie du jeu de tests de régression.

Sélectionner les métriques par mode de défaillance

La métrique appropriée dépend du mode de défaillance, et non de framework. La segmentation utile comporte trois niveaux d’application :

1. Les évaluations des résultats indiquent si la tâche a abouti avec succès.
2. Les évaluations de trajectoire déterminent si le parcours suivi était valide, efficace et conforme à la politique définie.
3. Les évaluations des composants identifient quel outil, récupérateur, sous-agent ou étape de décision a causé une défaillance.

Chaque domaine d’application peut être exécuté en mode hors ligne sur des cas fixes et reproductibles avant la mise en production, ou en mode en ligne sur des traces de production échantillonnées après l’envoi de la réponse. La section « Guardrails » ci‑dessous décrit en détail cette distinction. Les évaluations hors ligne peuvent nécessiter des données d’or. Les évaluations en ligne devraient privilégier des invariants, des distributions ainsi que des vérifications asynchrones qui ne perturbent pas le flux des requêtes.

Commencez par des métriques déterministes. Elles sont peu coûteuses, rapides et ne subissent pas de dérive.

Correctitude des appels d’outils

La correction des outils consiste à comparer les outils appelés avec ceux attendus. Choisissez la rigueur en conséquence :

• Correspondance exacte : la séquence doit être identique. Utilisez cette option lorsque l’ordre des éléments est une contrainte impérative, par exemple lookup_order -> verify_identity -> issue_refund.
• Correspondance par ordre in-order : les outils requis doivent apparaître dans le bon ordre relatif, mais des appels supplémentaires inoffensifs sont autorisés.
• Correspondance par ordre quelconque : les outils requis doivent être présents, mais leur ordre peut varier.

Un petit scoreur local suffit pour commencer :

from collections import Counter


def tool_correctness(called: list[str], expected: list[str], mode: str = "in_order") -> float:
    if not expected:
        return 1.0
    if mode == "exact":
        return float(called == expected)
    if mode == "any_order":
        matched = sum((Counter(called) & Counter(expected)).values())
        return matched / len(expected)

    rows = [[0] * (len(expected) + 1) for _ in range(len(called) + 1)]
    for i, tool in enumerate(called):
        for j, wanted in enumerate(expected):
            if tool == wanted:
                rows[i + 1][j + 1] = rows[i][j] + 1
            else:
                rows[i + 1][j + 1] = max(rows[i][j + 1], rows[i + 1][j])
    return rows[-1][-1] / len(expected)


called = ["lookup_order", "check_refund_policy", "issue_refund"]
expected = ["lookup_order", "verify_identity", "issue_refund"]

print(round(tool_correctness(called, expected, "exact"), 3))     # 0.0
print(round(tool_correctness(called, expected, "in_order"), 3))  # 0.667

Le in_order Le score correspond au taux de rappel de la séquence commune la plus longue : il indique quelle fraction de la séquence requise a survécu, dans le bon ordre. Faites attention à ce que cet indicateur ignore. Les appels inutiles n’ont aucun effet négatif sur ce score, ce qui permet à un agent d’obtenir une valeur de 1,0 tout en effectuant deux fois plus d’appels que nécessaire. Lorsque les appels supplémentaires entraînent des coûts financiers ou modifient l’état du système, suivez également la précision (nombre d’appels correspondants par rapport au nombre total d’appels) et analysez ces deux indicateurs ensemble. Le rappel permet de détecter les étapes manquantes, tandis que la précision permet de repérer les déviations.

La métrique de correction des outils de DeepEval expose les mêmes paramètres via should_consider_ordering et should_exact_match.

Correctitude des arguments

Appeler l’outil adéquat avec des arguments incorrects est souvent pire que d’appeler le mauvais outil, car les traces d’exécution semblent alors normales.

Dans les cas simples, on valide JSON schema ainsi que les valeurs exactes. Dans les cas sémantiques, on stocke les arguments attendus et on évalue les écarts :

{
    "trace_id": "tr_2417",
    "input": "Reschedule order A-100 for next Friday.",
    "expected_tools": ["lookup_order", "reschedule_delivery"],
    "expected_arguments": {
        "reschedule_delivery": {
            "order_id": "A-100",
            "date": "2026-06-19"
        }
    }
}

Une métrique basée sur le nom d’une outil ne peut pas détecter 2026-06-17 là où la politique l’exige 2026-06-19. Le dataset doit également stocker les arguments.

Le score associé à ce dataset est parameter-match : la fraction des attentes remplies. (tool, key, value) Il multiplie par trois le nombre d’actions correctement exécutées par l’agent.

def argument_correctness(called_args: dict, expected_args: dict) -> float:
    total = matched = 0
    for tool, params in expected_args.items():
        for key, want in params.items():
            total += 1
            if called_args.get(tool, {}).get(key) == want:
                matched += 1
    return matched / total if total else 1.0

L’égalité stricte est appropriée pour les identifiants, les enums et les dates. Elle est inadaptée pour le texte libre et les nombres flottants, où == Il marque une réponse correcte comme étant fausse. Évaluez ces champs selon leurs propres critères : une correspondance de chaîne normalisée, une analyse de date, et une tolérance numérique. La métrique reste inchangée ; seul le comparateur par champ varie.

Efficacité, boucles et impasses

Un agent qui termine la tâche après cinq tool calls redondants signale néanmoins un problème de planification et coûte davantage en termes de ressources pour s’exécuter.

Signaux bon marché par lesquels vous devriez commencer :

• Taux d’appels redondants : apparition de tool calls identique avec les mêmes arguments, répétée plus de deux fois.
• Anomalies de forme des traces : pics soudains de la profondeur, du nombre d’appels d’outils, du nombre de tokens, de la latence ou du coût.
• Convergence du chemin : proximité du parcours suivi par l’agent par rapport au chemin valide le plus court connu pour la tâche.
• Correctitude de la terminaison : détermination du fait que l’agent s’est arrêté prématurément, a continué à fonctionner après avoir réussi, ou a déclaré la réussite sans le changement d’état requis.
• Respect du plan : si l’agent établit un plan avant d’agir, il convient de vérifier si la trace suit ce plan. Un bon plan ignoré et un mauvais plan suivi à la lettre échouent tous deux, pour des raisons opposées ; la différence entre le plan et la trace permet de savoir lequel des deux.

Exécutez-les avant un jugement chaque fois que c’est possible. Un détecteur de boucles se trouve quelques lignes au-dessus du trace. Il n’a pas besoin de modèle.

Achèvement de la tâche et évaluation des résultats

En termes d’architecture bout en bout, la question centrale est : « L’utilisateur a-t-il obtenu ce qu’il demandait ? »

Deux schémas s’avèrent les plus efficaces :

• Évaluation de l’achèvement des tâches sans référence : on extrait l’objectif à partir de l’entrée et on détermine si le journal d’activité ainsi que la réponse finale y ont abouti. Cette méthode fonctionne en temps réel, car le trafic de production contient rarement des résultats de référence prédéfinis.
• Notation de l’état de l’environnement : on compare les lignes de base de données, fichiers, tickets, réservations ou enregistrements finaux à un état d’objectif annoté. Cette approche est plus fiable que la correspondance de transcriptions, car les agents peuvent découvrir des chemins valides que vous n’avez pas explicitement décrits.

La deuxième option est préférable lorsque vous pouvez la mettre en œuvre. L’état final correspond au contrat. La transcription n’est qu’une preuve.

Deux réserves sont à prendre en compte pour rester objectif, issues toutes deux du benchmark qui a popularisé l’évaluation par état. tau-bench peut attribuer une note satisfaisante à un agent qui ne fait rien sur certaines tâches inactives, car l’état de départ répondait déjà au critère d’objectif. De plus, Anthropic a rapporté un exécution d’Opus 4.5 qui a « échoué » à une tâche de réservation sur tau2-bench en exploitant une faille dans la politique, ce qui s’est en réalité avéré être le meilleur résultat pour l’utilisateur. L’évaluation par état est supérieure à la correspondance de transcriptions, mais l’état cible reste une annotation, et les annotations présentent des erreurs. Il convient d’auditer les cas qui réussissent trop facilement, et non seulement ceux qui échouent.

L’engrenage trace-to-eval

Éviter les pannes de production minière avant d’élaborer des cas d’évaluation supplémentaires.

La boucle :

1. Capturer la trace complète.
2. Identifier ce qui a échoué.
3. Regrouper les échecs similaires.
4. Conserver un exemple représentatif par cluster.
5. Gérer la version de dataset.
6. Le lancer dans le pipeline CI.
7. Continuer à évaluer en temps réel des traces de production échantillonnées.

Le répertoire associé trace2evals il met en œuvre le cycle complet destiné à un agent de support défaillant. Il capture les segments GenAI OpenTelemetry, détecte les pannes selon des règles déterministes, élimine les doublons au sein d’une versionée dataset « gold », puis réexécute chaque version gold dans l’environnement CI. La configuration par défaut scriptée ne nécessite pas de clé API, donc make demo Reproduit le processus hors ligne.

Détection des défaillances de mine par analyse d’erreurs

Hamel Husain et Shreya Shankar présentent un flux de travail d’analyse des erreurs dédié précisément à cette étape ; celui de Hamel guide de terrain Il l’analyse pas à pas. Les deux premières étapes tirent leur nom de la recherche qualitative, mais la méthode est simple : lire les traces, prendre des notes et identifier les motifs.

1. Codage ouvert : lire de 30 à 50 traces réelles et rédiger des notes libres sur les causes des dysfonctionnements.
2. Codage axial : regrouper ces notes en 5 ou 6 catégories de défaillance nommées.
3. Étiqueter tout en fonction de la taxonomie définie.
4. Créer des métriques pour les groupes les plus importants.

Ne commencez pas avec des étiquettes telles que reasoning_issue ou tool_problem. Elles sont trop vagues pour être testées. Utilisez des étiquettes telles que missing_identity_verification, date_argument_mismatch, retried_same_tool_after_429, ou stopped_before_database_update. Une étiquette qui indique précisément ce que le test de régression doit vérifier.

Dédupliquer avant de promouvoir

La boucle de détection de traces présente un piège : l’ajout permanent de toutes les traces défectueuses. Cela génère un dataset de grande taille, coûteux et peu généralisable. Ce dernier conserve des doublons presque identiques provenant de mars, tout en omettant la nouvelle manifestation du même bug en juin.

Grouper d’abord les éléments. Sélectionner un seul identifiant représentatif par cluster. Stocker les identifiants de suivi associés dans les métadonnées afin qu’un auditeur puisse examiner les preuves issues du environnement de production ultérieurement.

Si un cluster de défaillances réapparaît après une correction, cela signifie que le cas de régression n’a pas été généralisé. Il convient de recréer le cluster et d’élargir l’ensemble de données de référence, plutôt que d’ajouter des exemples représentant 15 points supplémentaires.

Versionner le dataset

La version datasets s’effectue de la même manière que la gestion des versions prompts et du code. Chaque fois qu’un élément significatif change (le modèle, prompt, tool schema, le juge prompt, ou le comportement de l’application), il est nécessaire d’exécuter la même version dataset avant et après cette modification.

La porte CI doit fixer :

• Version dataset
• Version de l’application
• Version prompt
• Modèle d’évaluation
• Évaluer prompt
• Version du code d’évaluateur

Si l’un de ces déplacements est effectué, la comparaison avant/après devient floue. A goldens-v3.json Un fichier dans Git fonctionne bien à petite échelle. Les captures d’écran natives des outils Langfuse, Phoenix, Braintrust ou LangSmith s’avèrent utiles dès que dataset devient un environnement collaboratif.

Porte de contrôle CI

Une métrique défaillante doit impérativement entraîner l’échec de la compilation ; sinon, l’ensemble d’évaluation n’est rien de plus qu’un tableau de bord que personne ne consulte.

Le test doit relancer l’agent actuel avec l’entrée de référence. Il ne doit pas se contenter de rejouer la trace ancienne qui a échoué :

@pytest.mark.parametrize("golden", GOLDENS, ids=[item["id"] for item in GOLDENS])
def test_agent_regression(golden: dict) -> None:
    answer, fresh_trace = run_agent_and_capture_trace(golden["input"])

    refired = set(flag_failures(fresh_trace)) & set(golden["failure_modes"])
    assert not refired, f"failure mode regressed: {sorted(refired)}"

    assert tool_correctness(
        called=[call["name"] for call in fresh_trace["tool_calls"]],
        expected=golden["expected_tools"],
        mode=golden.get("tool_match", "in_order"),
    ) >= golden.get("tool_threshold", 1.0)

Il est facile de se tromper quant à cette distinction. La fonction du dataset est de détecter lorsque la prochaine version de l’agent répète une ancienne erreur, et non de conserver l’erreur elle-même dans un archivage.

Calibrez le juge avant de lui faire confiance

LLM-en tant que juge est utile. Il est également facile de se tromper soi-même à son sujet.

G-Eval Il demande à un juge d’établir des étapes de rubrique explicites avant l’évaluation. Ensuite, il additionne les scores de chaque niveau de notation, en les pondérant selon leur probabilité de token ($\text{score} = \sum_i p(s_i)\,s_i$). Ce protocole a permis de suivre plus fidèlement les évaluations humaines que les anciennes métriques automatiques qu’il a remplacées.

L’étape pondérée par probabilité nécessite des valeurs logprobs fournies par l’arbitre, que certains modèles hébergés ne rendent pas accessibles. Néanmoins, le résultat global continue de permettre d’utiliser une grille d’évaluation explicite plutôt que simplement un score brut.

MT-Bench Les résultats ont montré que GPT-4 était en accord avec les préférences humaines à peu près autant souvent que les humains le sont entre eux, ce qui a contribué à faire de LLM un outil de jugement des tendances dominantes. Des travaux ultérieurs ont mis en évidence des biais liés à la position, à la longueur du texte et aux préférences personnelles. Les scores attribués par le juge peuvent également varier lorsque le prompt ou la version du modèle change.

JudgeBench Création de paires de réponses dans lesquelles l’une des réponses est objectivement fausse selon des connaissances vérifiables, des raisonnements logiques, des calculs mathématiques ou du code. GPT-4o a obtenu 50,9 % sur cet ensemble de tests, tandis que le meilleur juge humain a atteint environ 64 %. Les réponses affirmées avec certitude mais erronées représentent un cas difficile pour les systèmes d’évaluation basés sur des modèles.

Traitez le juge comme un instrument de mesure : calibrez-le en fonction des étiquettes fournies par des humains avant qu’il ne procède à toute évaluation, et vérifiez-le à nouveau chaque fois que le modèle du juge ou prompt subit une mise à jour.

Lorsqu’un juge est requis, il convient de structurer le verdict de manière claire. Raisonnement guidé par schéma (SGR) définit le chemin de raisonnement du juge sous forme de schéma Pydantic. Structured Outputs ou constrained decoding, ce qui exige alors des champs tels que evidence, passed_criteria, failed_criteria, failure_mode, et score.

Placer les champs d’éléments de preuve avant la note. Le juge applique ensuite les mêmes étapes de grille prédefinies, dans le même ordre de champs, à chaque exécution et pour tous les modèles compatibles. Un examinateur peut consulter des champs nommés au lieu de parser un paragraphe. L’outil CI peut effectuer une comparaison diff d’un objet JSON stable, tandis que l’ensemble de calibration révèle quelle étape de la grille n’était pas en accord avec l’étiquette manuelle.

Il peut également modifier la courbe de coût. Considérez un modèle moins cher comme un candidat potentiel, et non comme un remplaçant automatique. Faites-le fonctionner sur le même ensemble de données de calibration étiquetées par des humains. Comparez son taux d’accord, son taux de faux positifs et son taux de faux négatifs avec ceux du juge principal. N’employez-le que pour les cas courants s’il respecte les seuils définis par votre ensemble d’application. Conservez le juge principal pour les cas de désaccord, les cas à haut risque ou les séances de calibration.

Liste de contrôle par défaut pour l’hygiène des juges :

1. Privilégiez autant que possible un système binaire « réussite/échec ». Les échelles à cinq niveaux incitent à une précision artificielle.
2. Étiquetez manuellement de 30 à 50 trajectoires avant d’établir le critère d’évaluation final.
3. Mesurez la concordance entre les juges et les humains à l’aide du kappa de Cohen (concordance corrigée du hasard, de sorte qu’un juge qui vote systématiquement « réussite » obtient une valeur proche de zéro) ou simplement des taux TPR/TNR.
4. Décomposez les critères globaux. La question « L’agent a-t-il vérifié l’identité avant le remboursement tool call ? » est plus pertinente que « La trajectoire était-elle bonne ? ».
5. Affichez le verdict via un schéma SGR contenant les preuves, les critères non respectés, le mode d’échec ainsi que la note obtenue.
6. Utilisez, si possible, un juge appartenant à une famille de modèles différente de celle du générateur.
7. Aléatoisez l’ordre des comparaisons par paires et calculez la moyenne dans les deux sens.
8. Pénalisez l’utilisation de longueurs non justifiées dans les critères d’évaluation. Une réponse plus longue ne signifie pas nécessairement qu’elle est meilleure.
9. Fixez le modèle du juge, prompt, dataset, le schéma ainsi que la version de l’application.
10. Récalibrez après toute modification apportée au modèle, prompt, aux outils, aux politiques ou aux schémas.

Pour obtenir des scores à haute valeur stratégique, privilégiez un petit jury plutôt qu’un seul juge centralisé. PoLL Nous avons testé un groupe de juges plus restreints, sélectionnés parmi des familles de modèles indépendantes, et avons fusionné leurs décisions. Au cours de six datasets, ce groupe a montré une capacité à reproduire les jugements humains supérieure à celle d’un seul juge GPT-4. De plus, il a permis d’éviter le biais de préférence pour soi propre propre aux juges individuels, tout en coûtant plus de sept fois moins cher. Préservez la révision par des humains pour les décisions ayant des conséquences financières, relatives à l’accès, à la sécurité ou au respect des réglementations.

Si un juge obtient un score de kappa de 0,55 par rapport aux humains sur votre tâche, n’utilisez pas ce résultat pour bloquer les déploiements. Employez-le plutôt pour trier les files d’attente des revues. Lorsque le score se situe autour de 0,75 et que le coût lié aux échecs est modéré, il devient beaucoup plus facile de justifier l’utilisation d’une étape de contrôle en intégration continue.

Les contraintes de sécurité bloquent les évaluations en ligne de commande, tandis que les mécanismes d’observation interviennent ultérieurement

Les gens confondent ces éléments car ils génèrent tous deux des scores. La différence réside dans leur emplacement : en ligne dans le chemin de la requête, avant la diffusion, ou après la réponse.

Les guardrails s’exécutent en ligne de commande. Ils sont rapides, déterministes et visibles pour l’utilisateur. Un guardrail peut bloquer un tool call, masquer les données PII, rejeter des prompt injection, ou obliger à une tentative de réexécution avant que la réponse ne quitte le système. Un faux positif constitue en fait une faille en environnement de production.

Les évaluations hors ligne sont exécutées avant la mise en production. Elles sont reproductibles. Elles servent de filtre pour prompts, les modèles, les outils, les récupérateurs d’informations et les politiques, en fonction d’un dataset fixe.

Les évaluations en ligne s’exécutent après la réponse, généralement sur un trafic échantillonné. Elles peuvent faire appel à des juges LLM plus lents, puisqu’ils ne se trouvent pas dans le chemin de latence. Leur rôle est de détecter les dérives, d’identifier de nouveaux groupes de pannes, et de fournir les données nécessaires au prochain dataset hors ligne.

Si la position est incorrecte, cela entraîne des problèmes dans tous les cas :

• Un juge situé dans le chemin de la requête ajoute de la latence ainsi qu’une nouvelle source de fragilité du système.
• Une mesure de sécurité reléguée au calcul asynchrone permet aux violations des politiques d’atteindre les utilisateurs.

Pour les systèmes à fort volume de données, évaluez un petit échantillon à l’aide d’un juge plus performant, et un échantillon plus large avec des classificateurs moins coûteux. Déclenchez des alertes en fonction des clusters et des intervalles de confiance, plutôt qu’en se basant sur une seule estimation bruitée.

Choix d’outils

Aucun outil unique ne gère l’ensemble du cycle de vie. Les architectures les plus robustes reposent sur deux composants : un stockage de traces et un exécuteur de CI/eval.

Les notes relatives aux compromis décrivent l’origine des coûts, et non leur nature exacte. Les pages de tarification évoluent constamment, et les fournisseurs prennent en compte des éléments différents : des traces, des observations, des intervalles temporels, des scores, des utilisateurs, le taux de rétention ou encore les données traitées. Vérifiez à nouveau les tarifs en temps réel avant de valider une décision.

Raccourcis de décision :

• Besoin d’un suivi d’activité auto-hébergé avec portabilité OTel : commencez par Phoenix ou Langfuse.
• Nécessité d’une étape de validation CI basée sur le code en premier : commencez par DeepEval.
• Déjà engagé avec LangGraph : LangSmith s’avère pratique.
• Souhait de revues de régression de PR gérées : Braintrust est difficile à surpasser.
• Les cas de sécurité et de tests par équipe rouge prédominent : Promptfoo est l’outil idéal pour cela.
• Recherche en matière de sécurité ou travail contrôlé sur benchmark : Inspect AI convient mieux dans ce contexte.

Le choix de l’outil est secondaire. Si les pannes en production ne deviennent pas des cas de test, vous payez principalement pour le stockage des traces.

Une liste de contrôle pratique pour le déploiement

Créez les preuves pipeline avant d’élargir l’ensemble des métriques. Commencez par déterminer d’où proviendront les exemples.

1. Collectez d’abord les exécutions historiques. Si l’agent existe déjà, récupérez les traces, les tickets de support, les rapports de bogues, les sessions de notation négative, les transcriptions des tests qualité manuels ainsi que les notes issues de l’utilisation interne avant de modifier l’implémentation. Si l’agent n’existe pas encore, enregistrez chaque prototype et chaque exécution de test manuel dès le premier jour.

2. Instrumenter la forme de suivi. Capturer les messages, tool calls, les arguments, les sorties des outils, les erreurs, les comptages de tokens, la latence, le coût, les retours d’information des utilisateurs, la version de l’application, la version de prompt, la version du modèle, la version de tool schema, ainsi que l’état final de l’environnement. Utiliser OpenTelemetry Conventions de l’IA générative ou des segments de type OpenInference si vous souhaitez assurer la portabilité. Utilisez Langfuse, LangSmith, Phoenix ou Braintrust si vous voulez disposer immédiatement d’une interface utilisateur pour le suivi ainsi que d’un flux de travail dataset.

3. Transformer les échecs réels en cas de départ. Lisez les traces avant de les résumer à l’aide d’un modèle. Pour chaque échec utile, stockez l’entrée, l’ID de la trace source, l’état attendu, les invariants d’outil attendus, le mode d’échec, le niveau de gravité ainsi que la note du réviseur. Langfuse permet de relier les éléments dataset aux traces en environnement de production ; LangSmith peut générer des datasets à partir des exécutions traçées. Conservez le lien source afin que le cas reste auditable.

4. En l’absence d’historique, il convient de générer des cas de démarrage en conditions froides. Il faut demander à un LLM de rédiger des tâches à partir des exigences produits, des politiques, des tool schemas, des machines d’état ainsi que de macros de support. Ces tâches doivent couvrir les scénarios réussis ainsi que les échecs liés à des permissions incorrectes, à l’absence de vérifications d’identité, à des tool results obsolètes, à des dates ambiguës, aux tentatives de réessai après atteinte des limites de fréquence, ou encore à des résultats contradictoires provenant des outils.

5. Ne faites pas confiance aux cas synthétiques tant qu’ils n’ont pas été examinés par un humain. Les exemples synthétiques sont utiles pour assurer la couverture, mais pas pour refléter la vérité. Marquez-les avec source: synthetic Et il est nécessaire d’obtenir l’approbation d’un examinateur concernant le résultat attendu. Lorsque c’est possible, exécuter un chemin de référence fiable, et utiliser différentes familles de modèles pour générer le cas d’école ainsi que pour évaluer le résultat.

6. Construisez un petit dataset équilibré. Intégrez des cas de succès, d’échec, de refus, des cas limites, des scénarios à longues interactions, des cas sensibles aux politiques, ainsi que des chemins alternatifs valables. Évitez de créer la « transcription idéale originale » ; cette version idéale doit plutôt encodifier le résultat attendu, les invariants autorisés et les modes de défaillance.

7. Ajoutez d’abord des vérifications déterministes. L’ordre requis pour les outils – à savoir la politique d’ordre, les arguments obligatoires, la validation du schéma, les comparaisons d’état final, les limites de boucle, les plafonds de tokens et de latence, ainsi que les invariants spécifiques à la tâche – doit être respecté avant toute exécution par un juge.

8. Ajoutez un juge de forme SGR. Utilisez-le uniquement pour la partie nécessitant une interprétation. Calibrez-le en fonction des étiquettes fournies par des humains. Si ce dernier ne parvient pas à distinguer les exemples bons des mauvais dans l’ensemble de calibration, ajustez d’abord le critère d’évaluation avant de l’intégrer dans le pipeline CI.

9. Connecter le cycle de test. Exécuter le petit ensemble de tests hors ligne dans l’environnement CI, lancer l’ensemble plus complet avant la publication, évaluer le trafic de production échantillonné en ligne, et réintégrer les clusters de pannes récurrentes en ligne dans l’environnement hors ligne dataset.

Votre première suite d’évaluation contiendra des erreurs de manière banale. Déploiez-la quand même. Une suite que vous exécutez quotidiennement est plus facile à corriger qu’un document de conception parfait qui ne bloque jamais une demande de fusion défectueuse.

Références

• repo de démonstration associé à trace2evals
• LangChain – État de l’ingénierie d’agents
• Anthropic – Démystifier les évaluations pour les agents AI
• Hamel Husain – Un guide pratique pour améliorer rapidement les produits AI
• OpenTelemetry conventions sémantiques pour les systèmes AI génératifs
• Correctitude de l’outil DeepEval
• Complétion de tâche DeepEval
• Raisonnement guidé par schéma sur vLLM : Structured Outputs à l’aide de xgrammar et Pydantic
• Langfuse datasets et gestion des versions
• LangSmith – Créer et gérer datasets de manière programmatisée
• Braintrust – Évaluer de manière systématique
• Phoenix LLM effectue une évaluation
• Intégration d’Action GitHub pour Promptfoo
• tau-bench : Un Benchmark pour l’interaction Outil-Agent-Utilisateur dans des domaines du monde réel
• Pourquoi les systèmes Multi-Agent LLM échouent-ils ?
• G-Eval : Évaluation de la génération de langage naturel utilisant GPT-4 afin d’améliorer l’alignement avec les préférences humaines
• Évaluer LLM en tant que juge à l’aide de MT-Bench et Chatbot Arena
• Remplacer les juges par des jurys : évaluation des générations LLM à l’aide d’un panel de modèles diversifiés
• JudgeBench : Un Benchmark permettant d’évaluer des juges basés sur LLM
• Biais de préférence pour soi-même dans LLM en tant que juge