02 - Le LLM comme juge#

Faire noter une IA par une autre IA, c'est puissant et fragile. Voici quand l'utiliser et quand s'en passer.

Temps de lecture : 13 min | Niveau : Intermediaire

Ce que tu sauras faire apres#

• Decider en 30 secondes si ta tache se note par code ou par un modele juge.
• Ecrire une grille de notation qui ne laisse pas le juge improviser.
• Copier un prompt de juge complet et l'adapter a ta tache.
• Reconnaitre les biais connus du juge et les neutraliser.
• Remplacer un juge LLM par une verification deterministe quand c'est possible.

🎯 Le principe#

Certaines sorties ne se comparent pas avec un ==. Exemples typiques chez toi :

• Un resume de ticket d'incident.
• Une explication en francais d'une requete SQL complexe.
• Un commentaire de code genere.
• Une reponse d'assistant a une question metier posee sur ton catalogue de donnees.

Pour ces cas, tu demandes a un second modele de noter la sortie du premier, selon une grille que tu ecris toi-meme.

La doc Anthropic recommande explicitement : utilise un modele different de celui qui a genere la sortie (« generally best practice to use a different model to evaluate than the model used to generate the evaluated output »).

🚦 D'abord : est-ce que tu as vraiment besoin d'un juge ?#

Pose-toi cette question dans cet ordre. Arrete-toi a la premiere reponse "oui".

Regle d'or : le juge LLM est le dernier recours, pas le premier reflexe. Il coute des tokens, il est lent, et il introduit sa propre incertitude. Une regex coute 0 et donne toujours le meme resultat.

Exemple concret de verification deterministe#

Ton prompt genere une requete SQL a partir d'une question metier. Ne demande pas a un juge « est-ce que cette requete est bonne ? ». Fais ca :

import sqlglot

def verifier_sql(requete: str, tables_autorisees: set[str]) -> dict:
    controles = {}

    # 1. Est-ce que ca parse ?
    try:
        arbre = sqlglot.parse_one(requete, read="postgres")
        controles["parse_ok"] = True
    except Exception:
        return {"parse_ok": False}

    # 2. Est-ce qu'elle ne touche que des tables autorisees ?
    tables = {t.name for t in arbre.find_all(sqlglot.exp.Table)}
    controles["tables_ok"] = tables.issubset(tables_autorisees)

    # 3. Est-ce qu'elle est en lecture seule ?
    interdits = ("insert", "update", "delete", "drop", "truncate", "alter")
    controles["lecture_seule"] = not any(m in requete.lower() for m in interdits)

    return controles

Ensuite, tu executes la requete sur un jeu de donnees fige et tu compares le resultat a un resultat de reference. C'est deterministe, gratuit, reproductible. Aucun juge LLM ne fait mieux que ca.

Garde le juge pour l'explication en francais qui accompagne la requete.

📏 Ecrire une grille de notation#

Une grille, c'est une echelle + une definition de chaque niveau. Sans definitions, le juge invente sa propre echelle et tes notes ne veulent rien dire.

La doc Anthropic decrit trois formes :

1. Echelle de Likert 1 a 5 pour les attitudes subjectives (ton, empathie, professionnalisme).
2. Classification binaire pour les controles pass / fail (ex : est-ce que la reponse contient une donnee personnelle ?).
3. Echelle ordinale 1 a 5 pour un degre d'utilisation d'un element (ex : a quel point la reponse exploite le contexte fourni).

Attention a un detail important. L'exemple d'echelle de Likert donne par la doc Anthropic ne definit que les deux extremites : 1: Not at all <critere> et 5: Perfectly <critere>. Les trois niveaux du milieu ne sont pas definis.

C'est justement la que le juge derive. Si tu veux une echelle 1-5 exploitable, ecris toi-meme les cinq niveaux. Voici une formulation de depart, a adapter a ton critere :

Ce tableau est une proposition, pas une citation. Ce qui vient de la doc, c'est le principe : une echelle avec des niveaux nommes, et non une note libre.

Regle pratique : une note par dimension, jamais une note globale#

Une note globale "7/10" ne te dit pas quoi corriger. Decoupe :

Dimension 1 : Exactitude factuelle (le contenu est-il conforme aux donnees fournies ?)
Dimension 2 : Completude (a-t-il couvert tous les points demandes ?)
Dimension 3 : Format (respecte-t-il la structure imposee ?)
Dimension 4 : Concision (pas de remplissage ?)

Le format seul se verifie par code. Garde le juge pour 1, 2 et 4.

📋 Template pret a copier : prompt de juge#

Copie ce bloc, remplis les crochets. Il impose une sortie parsable et interdit les commentaires libres.

Tu es un evaluateur. Tu notes une reponse produite par un assistant. Tu ne
produis pas de reponse toi-meme, tu notes uniquement.

<tache_demandee>
[RECOPIE ICI LA CONSIGNE EXACTE QUI A ETE DONNEE A L ASSISTANT]
</tache_demandee>

<donnees_source>
[COLLE ICI LES DONNEES SUR LESQUELLES LA REPONSE DEVAIT S APPUYER]
</donnees_source>

<reponse_a_noter>
[COLLE ICI LA SORTIE DU MODELE]
</reponse_a_noter>

Note la reponse sur ces dimensions, chacune de 1 a 5 :
- exactitude : les faits enonces sont-ils tous verifiables dans <donnees_source> ?
  1 = plusieurs faits faux ou inventes, 5 = tous les faits sont verifiables.
- completude : tous les points de <tache_demandee> sont-ils traites ?
  1 = la plupart des points manquent, 5 = tous les points sont traites.
- concision : y a-t-il du remplissage, des repetitions, des formules creuses ?
  1 = plus de la moitie du texte est du remplissage, 5 = aucun remplissage.

Regles :
- Tu te bases UNIQUEMENT sur <donnees_source>. Ta connaissance generale n'est pas
  une preuve.
- La longueur d'une reponse n'est pas un critere de qualite.
- Si <donnees_source> ne permet pas de trancher sur un fait, considere-le comme
  non verifiable et baisse la note d'exactitude.

Renvoie UNIQUEMENT ce JSON, sans texte autour :
{"exactitude": <1-5>, "completude": <1-5>, "concision": <1-5>,
 "faits_non_verifiables": ["<citation exacte du fait douteux>", ...],
 "justification": "<2 phrases maximum>"}

Variante binaire (plus fiable, a privilegier)#

Quand tu peux poser une question fermee, fais-le. Les notes binaires sont beaucoup plus stables que les echelles 1-5.

<donnees_source>
[COLLE LES DONNEES]
</donnees_source>

<reponse_a_verifier>
[COLLE LA SORTIE DU MODELE]
</reponse_a_verifier>

Question : chaque affirmation chiffree de <reponse_a_verifier> est-elle
directement verifiable dans <donnees_source> ?

Reponds uniquement par "oui" ou "non".

Une sortie oui / non se parse en une ligne et se moyenne sur 20 cas pour donner un taux. C'est le modele de la classification binaire documente par Anthropic, aussi utilise pour detecter des donnees personnelles dans une sortie.

Astuce API : les plateformes proposent des sorties structurees qui contraignent la reponse a un schema JSON. Chez Anthropic, c'est le champ output_config, avec un sous-objet format de type json_schema. Exemple tire de la doc officielle :

Copier

{
  "output_config": {
    "format": {
      "type": "json_schema",
      "schema": {
        "type": "object",
        "properties": { "verdict_ok": { "type": "boolean" } },
        "required": ["verdict_ok"],
        "additionalProperties": false
      }
    }
  }
}

Ca t'evite de parser du texte libre et de gerer les cas ou le juge bavarde.

⚠️ Les biais du juge#

Ce sont des defauts connus et documentes dans la pratique. Prends-les au serieux, ils faussent tes chiffres.

Le controle indispensable : calibrer le juge#

Avant de faire confiance a ton juge, teste-le comme tu testerais n'importe quel composant.

1. Prends 10 sorties.
2. Note-les toi-meme a la main.
3. Fais-les noter par le juge.
4. Compare.

Si le juge est d'accord avec toi sur 9 cas sur 10, tu peux l'utiliser. S'il est d'accord sur 6, ton prompt de juge est mauvais : precise la grille et recommence.

Note bien : un juge non calibre n'est pas une mesure, c'est une opinion generee.

🔁 AVANT / APRES#

Avant (juge inutilisable)#

Voici une reponse d'un assistant :
[REPONSE]

Est-ce que c'est une bonne reponse ? Donne une note sur 10.

Pourquoi c'est mauvais :

• Pas de donnees source : le juge note avec sa connaissance generale, donc il peut halluciner lui aussi.
• Pas de definition de "bonne".
• Une note globale sur 10 : 15 niveaux non definis, le juge repondra toujours 7 ou 8.
• Sortie en texte libre : impossible a agreger sur 20 cas.

Apres (juge exploitable)#

<donnees_source>
[EXTRAIT DU CATALOGUE DE DONNEES]
</donnees_source>

<reponse_a_noter>
[REPONSE]
</reponse_a_noter>

Note de 1 a 5 l'exactitude : chaque nom de table et de colonne cite dans
<reponse_a_noter> existe-t-il dans <donnees_source> ?
1 = plusieurs noms inexistants, 5 = tous les noms existent.

Liste les noms cites qui n'existent pas dans <donnees_source>.

Renvoie uniquement : {"exactitude": <1-5>, "noms_inexistants": ["..."]}

Pourquoi c'est mieux : le juge a une source de verite, une seule dimension, une echelle definie, une sortie parsable. Et bonus : la liste noms_inexistants se re-verifie par code contre le vrai catalogue. Tu as transforme une note subjective en controle deterministe.

C'est le mouvement a rechercher en permanence : utiliser le juge pour extraire des affirmations verifiables, puis les verifier par code.

💸 Le cout du juge#

Un juge, c'est un appel API de plus par cas de test. Sur 200 cas et 5 iterations de prompt, ca fait 1 000 appels supplementaires.

Trois facons de reduire :

• Utilise un modele plus petit et moins cher pour juger quand la grille est simple (binaire). La doc Anthropic propose ce schema pour les filtres d'entree, avec un modele leger type Haiku.
• Regroupe plusieurs dimensions dans un seul appel de juge plutot qu'un appel par dimension.
• Pour les taches non urgentes, passe par l'API Batch : la doc de tarification Anthropic indique une remise de 50 % sur les tokens d'entree et de sortie pour le traitement par lot.

A retenir#

• Ordre de preference : comparaison exacte > parsing/schema > regex > requete SQL de controle > metrique textuelle > juge LLM.
• Un juge sans donnees source note avec sa propre connaissance : il peut halluciner lui aussi.
• Une dimension par note, une echelle definie niveau par niveau, une sortie JSON.
• Le binaire (oui/non) est nettement plus stable que l'echelle 1-5.
• Calibre ton juge sur 10 cas notes a la main avant de lui faire confiance.
• Utilise un modele different de celui qui a genere la sortie.

Sources#

Toutes ces pages ont ete ouvertes et verifiees le 26 septembre 2026.

• Anthropic - Define success criteria and build evaluations : echelle de Likert, classification binaire, echelle ordinale, et la recommandation d'utiliser un modele different pour juger.
• Anthropic - Mitigate jailbreaks and prompt injections : la forme exacte de output_config.format avec un json_schema.
• Anthropic - Pricing : remise de 50 % de l'API Batch, multiplicateurs du cache.
• Microsoft Foundry - Built-in evaluators reference : l'evaluateur Rubric note selon des criteres ponderes, avec un LLM comme juge.
• OpenAI - Graders : le "score model grader" est l'equivalent OpenAI du juge LLM.