Évaluer un agent IA en production : le juge sémantique

Mettre un agent IA en production sans système d'évaluation automatique, c'est piloter à l'aveugle. Les métriques classiques (latence, taux d'erreur HTTP) ne disent rien sur la qualité des réponses. Mais appeler un LLM frontier (GPT-5.5, Claude Opus) pour juger chaque interaction en production devient vite prohibitif.

Réponse directe : un juge sémantique est un modèle fine-tuné spécifiquement pour évaluer la qualité des traces d'un agent. LangChain et Fireworks ont démontré qu'un Qwen-3.5-35B fine-tuné sur quelques centaines d'exemples égale ou dépasse les modèles frontier sur ce type de tâche, à un coût 10 à 100 fois inférieur. Voici la méthode.

Pourquoi les métriques classiques ne suffisent pas

Un agent IA produit des réponses en langage naturel, exécute des outils, maintient un contexte multi-tours. Les métriques d'infrastructure (uptime, latence p95, tokens utilisés) ne capturent pas si l'agent a répondu correctement à la vraie question de l'utilisateur.

Les problèmes les plus fréquents en production sur des agents :

• Erreurs perçues par l'utilisateur : l'agent répond à côté, confond deux entités, oublie une contrainte mentionnée plus tôt dans la conversation.
• Corrections en boucle : l'utilisateur reformule la même demande plusieurs fois, signalant implicitement que la réponse précédente était insuffisante.
• Refus non justifiés : l'agent refuse d'exécuter une action légitime sans raison claire.

Ces signaux sont présents dans les traces de conversation, mais les extraire manuellement à l'échelle n'est pas viable. C'est le problème que résout un juge sémantique automatique.

Qu'est-ce qu'un "perceived error" ?

LangSmith, la plateforme de traçage d'agents de LangChain, traite des milliards de tokens par jour en logs de production. Pour miner des signaux de qualité sur chaque trace, l'équipe a défini un concept central : l'erreur perçue ("perceived error").

Une erreur perçue se produit quand l'utilisateur pense que l'assistant a fait une erreur ou a produit quelque chose qui nécessite une correction. Ce n'est pas un jugement sur la correction objective de la réponse, ni sur la satisfaction générale de l'utilisateur. Exemple : un agent peut donner une réponse factuelle correcte que l'utilisateur trouve frustrante sans que l'agent ait commis d'erreur.

Le format de sortie du juge est simple et extractible :

{"perceived_error": true, "reason": "L'utilisateur corrige la date de réunion utilisée par l'assistant."}

Ce format binaire + justification est suffisant pour trier les traces, créer des datasets d'amélioration, et détecter les régressions.

Comment LangChain et Fireworks ont construit un juge à 100x moins cher

Le dataset

L'équipe a utilisé deux datasets de traces internes :

• chat-langchain : agent Q&A sur la documentation LangChain, conversations techniques multi-tours.
• Fleet : outil no-code d'agents pour des tâches variées (rédaction, recherche, etc.).

Total : 885 + 911 traces, avec des annotations générées via un panel de modèles frontier avec réconciliation humaine en cas de désaccord. Résultat : environ 24% de traces avec une erreur perçue sur chat-langchain, 18% sur Fleet.

Le modèle et le fine-tuning

Après des tests sur plusieurs modèles, le choix s'est porté sur Qwen-3.5-35B comme base. Les modèles plus petits avaient des taux d'erreur trop élevés sur les traces multi-tours complexes. L'entraînement a utilisé un LoRA SFT sur l'infrastructure Fireworks, uniquement sur les données chat-langchain.

Le résultat clé : le modèle fine-tuné sur chat-langchain surpasse tous les modèles frontier sur Fleet sans avoir été entraîné sur une seule trace Fleet. Le juge généralise bien entre domaines.

Le coût

Un modèle fine-tuné correspond à un modèle open source servi en inférence dédiée : 10 à 100 fois moins cher qu'un appel à Claude Opus ou GPT-5.5, selon le volume de traces. À l'échelle de milliards de tokens par jour, l'écart de coût est décisif.

Comment implémenter votre propre juge de trace

Étape 1 : annoter un dataset minimal

Commencez avec 200 à 500 traces de votre agent en production. Utilisez un panel de modèles frontier pour générer les labels initiaux, avec un humain pour les cas divergents.

import anthropic
import json
 
client = anthropic.Anthropic()
 
def annotate_trace(trace: str) -> dict:
    response = client.messages.create(
        model="claude-opus-4-8",
        max_tokens=200,
        messages=[{
            "role": "user",
            "content": f"""Analyse cette trace de conversation agent-utilisateur.
Détermine s'il y a une erreur perçue par l'utilisateur.
 
Trace :
{trace}
 
Réponds en JSON : {{"perceived_error": bool, "reason": "..."}}"""
        }]
    )
    return json.loads(response.content[0].text)

Étape 2 : fine-tuner un modèle open source

Avec un dataset de 500+ exemples annotés, un LoRA SFT sur Qwen-3.5-35B ou un modèle équivalent suffit à atteindre des performances frontier. Les plateformes comme Fireworks, Together AI ou un GPU OVHcloud permettent de lancer l'entraînement sans infrastructure dédiée.

Points critiques de la préparation des données :

• Inclure uniquement les messages Human/AI, pas les appels d'outils (ils augmentent le bruit sans améliorer les signaux de perception).
• Conserver les conversations complètes sans troncature : le jugement de perception nécessite l'historique complet.

Étape 3 : intégrer le juge dans le pipeline de production

Le juge s'intègre après chaque trace complète, en asynchrone pour ne pas impacter la latence de l'agent :

import asyncio
from typing import Any
 
async def evaluate_trace_async(trace: list[dict[str, Any]]) -> dict:
    # Appel au juge fine-tuné via endpoint dédié
    # Retourne {"perceived_error": bool, "reason": str}
    ...
 
async def agent_pipeline(user_message: str, history: list) -> str:
    response = await run_agent(user_message, history)
    
    # Évaluation asynchrone, non bloquante
    asyncio.create_task(
        evaluate_trace_async(history + [{"role": "assistant", "content": response}])
    )
    
    return response

Implications pour les PME

Un système d'évaluation de cette nature change la façon de gérer un agent en production.

Détection des régressions. Chaque mise à jour du prompt système ou du modèle peut être comparée à la baseline via le taux d'erreurs perçues. Une régression devient visible avant que les utilisateurs ne s'en plaignent.

Dataset d'amélioration continue. Les traces avec erreurs perçues forment automatiquement un dataset pour l'amélioration itérative : prompt engineering, fine-tuning, ou modification de la logique de l'agent.

Conformité et audit. Les organisations soumises au RGPD peuvent utiliser ces logs pour démontrer que le système surveille la qualité et traite les erreurs de façon systématique.

Le juge sémantique est l'outil manquant entre "l'agent fonctionne en développement" et "l'agent est fiable en production".

TL;DR

Un juge sémantique fine-tuné détecte les erreurs perçues dans les traces d'agents IA, à 10-100x le coût d'un LLM frontier. La méthode LangChain + Fireworks : annoter 500 traces, fine-tuner Qwen-3.5-35B avec LoRA, intégrer en asynchrone post-trace. Le modèle fine-tuné sur un domaine généralise bien à d'autres domaines. C'est la brique manquante pour passer d'un agent qui "marche" à un agent dont on peut mesurer et améliorer la qualité systématiquement.

Vous déployez un agent IA et cherchez à mettre en place un système d'évaluation ? Décrivez votre cas d'usage.