Judges : évaluation automatique par LLM — Production — Batch, Optimisation et Observabilité

Leçon corrigée le 2 novembre 2026 d’après le SDK mistralai 3.7.0 et la page Evaluators de Mistral : judges.create exige aussi description et tools (les anciens exemples auraient échoué), une sortie de régression demande min_description et max_description, et un juge s’essaie directement sur une conversation avec judge_conversation. Les variables de gabarit et les « Campaigns » des anciennes versions ne figurent plus dans la documentation. Sources : Evaluators · client-python.

Automatiser l’évaluation de la qualité

Relire manuellement des milliers de conversations est impossible à l’échelle de la production. Les juges répondent à ce problème : ce sont des évaluateurs fondés sur un LLM, que vous configurez une fois — instructions, modèle, format de sortie — puis que vous appliquez à des conversations ou à des enregistrements de datasets. Chaque jugement rend une analyse et une réponse : un label ou un score.

Deux types de juges

Classification

Un juge de classification attribue des labels discrets à chaque réponse. Exemples :

Binaire : helpful / not_helpful
Multi-classes : excellent / acceptable / poor
Catégorisation : code_question / general_knowledge / troubleshooting
Sécurité : safe / needs_review / unsafe

Régression

Un juge de régression attribue un score numérique dans un intervalle, dont vous décrivez les deux bornes :

Note d’utilité de 1 à 5
Score de pertinence de 0 à 100
Niveau de confiance de 0.0 à 1.0

Écrire de bonnes instructions

Les instructions du juge déterminent toute la qualité de l’évaluation, et la première cause d’échec est le flou. « Évaluez la qualité de la réponse » ne veut rien dire pour un modèle — chaque exécution interprétera « qualité » différemment. La version qui fonctionne nomme les critères observables : « Évaluez si la réponse répond directement à la question posée, avec des informations factuellement correctes. » Le même principe vaut pour le contexte : votre juge ne sait pas qu’il évalue un chatbot de support technique où « bon » signifie « résout le problème du client sans le renvoyer vers la documentation ». Si vous ne le lui dites pas explicitement, il appliquera une définition générique de la qualité qui n’est pas la vôtre.

Les cas limites méritent une attention particulière, car c’est là que les évaluations divergent. Préciser « un score de 3 signifie que la réponse est partiellement correcte mais manque d’un élément clé » stabilise le milieu de votre échelle — sans cet ancrage, la même conversation recevra 2, 3 ou 4 selon les exécutions. Le test ultime est simple : si deux évaluateurs humains lisant vos instructions pouvaient ne pas être d’accord sur un cas donné, votre critère est trop vague, et le juge héritera de cette ambiguïté à grande échelle.

Créer un juge de classification via le SDK

from mistralai.client import Mistral

client = Mistral(api_key="votre-cle-api")

# Juge de classification à trois niveaux
classifieur = client.beta.observability.judges.create(
    name="Qualité des réponses support",
    description="Classe chaque réponse du chatbot de support en trois niveaux de qualité.",
    model_name="mistral-medium-latest",
    instructions="""
Évaluez la dernière réponse de l'assistant dans la conversation fournie.

Contexte : il s'agit d'un chatbot de support technique.

Critères :
- La réponse est-elle factuelle et correcte ?
- Répond-elle directement à la question posée ?
- Le ton est-il professionnel et empathique ?

Classez la réponse selon les catégories proposées.
""",
    output={
        "type": "CLASSIFICATION",
        "options": [
            {"value": "excellent", "description": "Réponse correcte, complète et professionnelle"},
            {"value": "acceptable", "description": "Réponse correcte mais incomplète ou ton perfectible"},
            {"value": "poor", "description": "Réponse incorrecte, hors sujet ou non professionnelle"},
        ],
    },
    tools=[],  # aucun outil pour ce juge
)

print(f"Juge créé : {classifieur.id}")

Créer un juge de régression via le SDK

# Juge de régression : score d'utilité de 1 à 5
noteur = client.beta.observability.judges.create(
    name="Score d'utilité",
    description="Note l'utilité de la dernière réponse de l'assistant, de 1 à 5.",
    model_name="mistral-small-latest",
    instructions="""
Évaluez l'utilité de la dernière réponse de l'assistant sur une échelle de 1 à 5.

1 = Inutile (hors sujet, incorrect, ou ne répond pas à la question)
2 = Peu utile (partiellement correct mais manque l'essentiel)
3 = Moyennement utile (correct mais incomplet ou trop vague)
4 = Utile (correct et suffisamment détaillé)
5 = Très utile (correct, détaillé, avec des exemples ou étapes claires)
""",
    output={
        "type": "REGRESSION",
        "min": 1,
        "max": 5,
        "min_description": "Réponse inutile : hors sujet, incorrecte ou sans réponse",
        "max_description": "Réponse très utile : correcte, détaillée, étapes claires",
    },
    tools=[],
)

print(f"Juge créé : {noteur.id}")

Valider avant de passer à l’échelle

Un juge non validé produit des annotations fausses à grande échelle. Avant de vous y fier, essayez-le sur des conversations dont vous connaissez la bonne réponse : judge_conversation l’applique à une liste de messages et renvoie son analyse et son verdict.

resultat = client.beta.observability.judges.judge_conversation(
    judge_id=classifieur.id,
    messages=[
        {"role": "user", "content": "Mon imprimante affiche l'erreur E04, que faire ?"},
        {"role": "assistant", "content": "Consultez la documentation."},
    ],
)

print(resultat.analysis)  # le raisonnement du juge
print(resultat.answer)    # le label ou le score

Procédez ensuite avec méthode :

Testez sur 10 à 20 cas dont vous avez fixé vous-même le bon verdict
Vérifiez l’accord : le juge donne-t-il les mêmes résultats que vous ?
Testez la stabilité : en relançant sur les mêmes cas, les résultats sont-ils identiques ?
Identifiez les motifs d’échec : sur quels types de conversations le juge se trompe-t-il ?

Si l’accord est trop faible, retravaillez les instructions avant toute utilisation à grande échelle. Un juge validé s’applique ensuite aux enregistrements d’un dataset (client.beta.observability.datasets.records.judge), et la même logique de juge LLM se retrouve dans les évaluateurs des évaluations hors ligne (leçon 14).

Points clés à retenir

Un juge LLM classe (labels) ou note (scores) des conversations, avec une analyse à l’appui
judges.create demande name, description, model_name, instructions, output et tools
Une sortie de régression décrit ses deux bornes (min_description, max_description)
Les instructions doivent être spécifiques, contextualisées et ancrées sur des exemples de score
Validez un juge avec judge_conversation sur des cas connus avant de vous y fier