Judges : Évaluation Automatique par LLM

Automatiser l’évaluation de la qualité

Relire manuellement des milliers de conversations pour évaluer la qualité de votre LLM est impossible à l’échelle de la production. Les Judges résolvent ce problème : ce sont des évaluateurs basés sur LLM que vous configurez une fois, puis que vous appliquez à grande échelle via des Campaigns.

Un Judge prend en entrée un événement de chat completion (la conversation, la réponse, le contexte) et produit en sortie un label de classification ou un score numérique.

Deux types de Judges

Classification

Un Judge 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 Judge de régression attribue un score numérique dans un intervalle défini :

• 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 Judge 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 Judge 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, le même événement recevra 2, 3 ou 4 selon l’humeur du modèle. 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 Judge héritera de cette ambiguïté à grande échelle.

Variables Jinja2

Dans vos instructions, vous pouvez référencer le contenu de l’événement avec des variables Jinja2 :

Créer un Judge de Classification via le SDK

from mistralai import Mistral

client = Mistral(api_key="votre-clé-api")

# Judge de classification à 3 niveaux
classifier = client.beta.observability.judges.create(
    name="Qualité des réponses support",
    model_name="mistral-medium-latest",
    instructions="""
Évaluez la qualité de la réponse de l'assistant au message
de l'utilisateur.

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 ?

Message utilisateur : {{ user_message }}
Réponse assistant : {{ assistant_message }}

Classifiez la réponse selon les catégories suivantes.
""",
    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"
            }
        ]
    }
)

print(f"Judge créé : {classifier.id}")

Créer un Judge de Régression via le SDK

# Judge de régression : score d'utilité 1-5
scorer = client.beta.observability.judges.create(
    name="Score d'utilité",
    model_name="mistral-small-latest",
    instructions="""
Évaluez l'utilité de la 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)

Message utilisateur : {{ user_message }}
Réponse assistant : {{ assistant_message }}
Historique : {{ conversation_history }}

Attribuez votre score.
""",
    output={
        "type": "REGRESSION",
        "min": 1,
        "max": 5
    }
)

print(f"Judge scorer créé : {scorer.id}")

Valider avant de scaler

Un Judge non validé peut produire des annotations incorrectes à grande échelle. Avant de lancer une Campaign :

1. Testez sur 10-20 enregistrements manuellement
2. Vérifiez l’accord — Le Judge donne-t-il les mêmes résultats que vous ?
3. Testez la stabilité — En relançant sur les mêmes données, les résultats sont-ils identiques ?
4. Identifiez les patterns d’échec — Sur quels types de conversations le Judge se trompe-t-il ?

Si le taux d’accord est inférieur à 80 %, retravaillez vos instructions.

Points clés à retenir

• Les Judges automatisent l’évaluation de qualité : classification (labels) ou régression (scores)
• Les instructions doivent être spécifiques, contextualisées et testables
• Les variables Jinja2 donnent accès au contenu de l’événement dans les instructions
• Validez toujours un Judge sur 10-20 exemples avant de le déployer en Campaign
• Les Judges ne s’exécutent pas seuls : il faut les attacher à une Campaign