Troisième article de la série « Production Engineering, Evals & Security avec Claude ».
Lorsqu’une sortie peut être vérifiée par une règle simple, il faut utiliser cette règle.
Si Claude doit renvoyer un label unique, un exact match suffit. Si la réponse doit être un JSON valide avec des champs obligatoires, un code grader est préférable.
Mais certaines qualités ne peuvent pas être réduites à une simple condition logique :
- la fidélité d’un résumé ;
- la complétude d’une réponse ;
- le respect d’instructions complexes ;
- la pertinence d’une justification ;
- le ton attendu ;
- la qualité globale d’une réponse ouverte.
Dans ces situations, le module Production Engineering, Evals & Security introduit le pattern LLM-as-a-judge : utiliser un second modèle pour évaluer la sortie du premier à partir d’une rubric explicite.
Le principe du LLM-as-a-judge
L’architecture générale est simple :
Input
↓
Feature under test
↓
Output
↓
Judge model
+
Evaluation rubric
↓
Score + reasoningLe premier modèle réalise la tâche.
Le second agit comme évaluateur.
Par exemple :
Task:
Résumer cette conversation client.
Output:
"Le client attend toujours son remboursement..."
Judge:
La réponse est-elle fidèle ?
Complète ?
Conforme aux instructions ?Le judge retourne ensuite un score.
Pourquoi ne pas utiliser un judge pour tout ?
Parce que c’est :
- plus coûteux ;
- plus lent ;
- plus variable ;
- plus difficile à interpréter ;
- inutile lorsqu’une règle déterministe suffit.
Le document insiste sur ce point : le choix du grader doit suivre la structure de l’output.
Le raccourci est :
une seule forme correcte
→ exact match
règle structurelle
→ code grader
qualité ouverte
→ LLM-as-judgeUtiliser un judge pour savoir si un JSON est valide serait donc une mauvaise architecture.
Un simple :
json.loads(output)répond déjà à la question de manière déterministe.
Un judge doit recevoir une rubric claire
Le judge ne doit pas être appelé avec une instruction vague comme :
"Note cette réponse de 1 à 10."Ce score serait difficile à défendre.
Le module recommande de lui fournir une vraie grille d’évaluation.
Par exemple :
def grade_by_model(task, solution):
eval_prompt = f"""
You are an expert reviewer.
Evaluate the solution for the task.
Task:
{task}
Solution:
{solution}
Return JSON with:
"strengths": array of 1-3 points
"weaknesses": array of 1-3 points
"reasoning": a one to two sentence explanation
"score": a number from 1 to 10
"""
result = chat([
{
"role": "user",
"content": eval_prompt
}
])
return json.loads(result)Le point important n’est pas seulement le champ :
"score": 8mais aussi :
"strengths": [],
"weaknesses": [],
"reasoning": "..."Le document explique que demander au judge de produire ses forces, faiblesses et son raisonnement aide à rattacher le score à des critères concrets plutôt qu’à produire systématiquement une note moyenne confortable.
Définir les score bands
Une échelle :
1 à 10est insuffisante si personne ne sait ce que signifie :
3
6
9Il faut donc définir des plages.
Par exemple :
1–3
→ échec important
4–7
→ partiellement correct
8–10
→ satisfait largement les critèresPuis il faut adapter ces définitions à la tâche réelle.
Pour un résumé :
1–3
→ informations essentielles absentes ou incorrectes
4–7
→ idée générale correcte mais omissions ou imprécisions
8–10
→ fidèle, complet et conforme aux contraintes demandéesLa rubric doit faire en sorte que deux évaluateurs raisonnables comprennent les scores de manière comparable.
Le piège : confondre précision numérique et fiabilité
Un judge peut retourner :
8.7 / 10Cela semble très précis.
Mais la précision du nombre ne garantit absolument pas la qualité de la métrique.
C’est une illusion fréquente.
Un judge reste lui-même un modèle génératif.
Il peut :
- interpréter différemment la rubric ;
- varier entre deux exécutions ;
- privilégier certains critères ;
- mal distinguer deux niveaux proches.
Le document insiste donc sur une étape essentielle :
Un LLM-as-a-judge doit être calibré sur des cas évalués par des humains avant que ses scores soient considérés comme fiables.
La calibration : comparer le judge à des labels humains
La méthode commence avec un ensemble de cas déjà notés par des humains.
Par exemple :
Case A → humain = 9
Case B → humain = 2
Case C → humain = 7
Case D → humain = 5
Case E → humain = 3On passe ensuite exactement les mêmes cas au judge :
Humans
│
↓
reference labels
Cases ──────────────────┐
│
↓
LLM judge
│
↓
judge scores
│
↓
compare agreement
On mesure ensuite si le judge reproduit suffisamment bien le jugement humain.
Pourquoi mesurer l’accord ?
Supposons :
| Cas | Humain | Judge |
|---|---|---|
| A | 9 | 8 |
| B | 2 | 3 |
| C | 8 | 8 |
| D | 5 | 6 |
Le judge semble raisonnablement aligné.
Mais imaginons :
| Cas | Humain | Judge |
|---|---|---|
| A | 9 | 5 |
| B | 2 | 7 |
| C | 8 | 4 |
| D | 3 | 8 |
Le judge retourne toujours des nombres propres et structurés.
Pourtant sa métrique n’a presque aucune valeur.
Le module résume le problème ainsi : si un judge est en désaccord avec les labels humains environ la moitié du temps, son score peut sembler rigoureux mais ne constitue pas une preuve défendable.
Que faire lorsque la calibration est mauvaise ?
Il ne faut pas immédiatement changer de modèle.
Le premier levier est souvent la rubric.
Le document recommande notamment de :
- préciser la signification de chaque score ;
- clarifier les critères ;
- ajouter un exemple de bonne réponse ;
- ajouter un exemple de mauvaise réponse ;
- relancer la calibration ;
- mesurer à nouveau l’accord.
La boucle devient :
Human-labeled cases
↓
Judge
↓
Agreement faible
↓
Améliorer rubric
↓
Ajouter exemples
↓
Judge
↓
Re-measure agreementLe judge doit donc lui-même être considéré comme un composant à évaluer.
Exemple de rubric améliorée
Au lieu de :
Note cette réponse de 1 à 10.on peut fournir :
Evaluate the summary according to:
1. Faithfulness
- It must not introduce facts absent from the source.
2. Completeness
- It must include all important action items.
3. Instruction following
- It must contain exactly two sentences.
Score:
1–3: major failure on one or more criteria.
4–7: broadly correct but with meaningful omissions or deviations.
8–10: faithful, complete, and compliant with the requested format.Le score devient alors beaucoup plus interprétable.
Le reasoning du judge sert aussi au diagnostic
Supposons que deux prompts aient exactement le même score moyen :
Prompt A → 7.9
Prompt B → 7.9Sans explication, difficile de comprendre la différence.
Mais le judge peut fournir :
{
"strengths": [
"Correctly identifies the refund delay"
],
"weaknesses": [
"Does not mention that the case was escalated"
],
"reasoning": "The summary is faithful but incomplete.",
"score": 7
}Le score répond à :
Quelle est la qualité ?
Le reasoning aide à répondre à :
Pourquoi ce cas a-t-il échoué ?
Cette information peut orienter une modification du prompt.
Mais le reasoning n’est pas une vérité absolue
Le raisonnement du judge améliore la lisibilité de la décision.
Il ne transforme pas pour autant le judge en oracle.
Pour cette raison, la calibration humaine reste nécessaire.
Il faut conserver cette hiérarchie :
human-labeled cases
→ référence de calibration
judge reasoning
→ explication utile
judge score
→ métrique automatisée après calibrationLLM-as-a-judge et coût
Le judge ajoute un appel modèle.
Si une eval contient :
100 casle workflow peut nécessiter :
100 appels pour produire les réponses
+
100 appels pour les jugerAvec :
1000 cascela devient :
1000 + 1000 appelsLe document souligne donc que le judge est particulièrement coûteux par rapport à un exact match ou un code grader, qui peuvent s’exécuter localement.
Une architecture hybride est souvent préférable
Un système réel peut combiner plusieurs graders.
Exemple :
Claude output
│
┌────────────┼─────────────┐
↓ ↓ ↓
JSON valid fields quality
│ present │
↓ ↓ ↓
code grader code grader LLM judge
Le judge n’évalue alors que ce qu’un programme classique ne sait pas vérifier.
C’est une bonne application du principe :
Utiliser le mécanisme le plus simple capable de produire le signal nécessaire.
Exemple : évaluer un résumé
Supposons que la tâche soit :
Produire un résumé en deux phrases incluant le problème et le statut actuel.
On peut répartir l’évaluation.
Code grader
Vérifier approximativement que la sortie contient deux phrases.
LLM-as-judge
Évaluer :
- si le problème est correctement identifié ;
- si le statut est fidèle ;
- si aucune information importante n’est inventée.
On obtient donc :
Format
→ code
Meaning
→ judgeCette séparation réduit le coût et simplifie la rubric du judge.
Un judge est particulièrement utile pour la faithfulness
La faithfulness pose un problème difficile à coder.
Supposons le document source :
Le remboursement est retardé.
Le dossier a été escaladé au service financier.Claude répond :
Le remboursement sera effectué demain.
Le service financier a confirmé le paiement.La réponse peut être :
- fluide ;
- grammaticalement parfaite ;
- structurée correctement.
Mais elle invente des faits.
Un parser ne peut pas détecter facilement cela.
Un judge peut recevoir :
source
+
expected behavior
+
generated outputet évaluer la fidélité.
Éviter une rubric trop générale
Une erreur fréquente consiste à demander au judge d’évaluer trop de choses en même temps.
Par exemple :
Evaluate accuracy, style, tone, safety, completeness,
creativity, usefulness, clarity, conciseness...Le score final devient difficile à interpréter.
Un résultat de :
7ne permet plus de savoir quelle dimension a posé problème.
Une bonne eval cherche une métrique directement liée au comportement attendu.
Par exemple :
faithfulness
completeness
instruction followingsont probablement suffisants pour un résumé.
Calibration et edge cases
La calibration ne doit pas contenir uniquement de bonnes et de mauvaises réponses évidentes.
Il faut aussi inclure des situations difficiles.
Par exemple :
excellent wording + factual omission
complete answer + one hallucinated detail
correct content + wrong required format
technically correct + ignores one instruction
mostly correct + subtle contradictionCe sont précisément ces cas qui révèlent si la rubric permet réellement au judge de distinguer les niveaux de qualité.
Ne pas confondre dataset d’eval et dataset de calibration
Il est utile de distinguer :
Calibration set
→ vérifier que le judge se comporte comme les humains
Eval set
→ mesurer la featureLe premier valide l’instrument.
Le second utilise cet instrument pour mesurer le système.
Conceptuellement :
Human labels
↓
CALIBRATE JUDGE
↓
Validated judge
↓
RUN FEATURE EVAL
↓
Production scoreC’est exactement la logique du thermomètre :
avant de prendre une mesure importante, il faut pouvoir faire confiance à l’instrument.
Coverage ou perfection ?
Le module indique qu’un dataset plus large avec une évaluation automatisée légèrement imparfaite peut être plus utile qu’un minuscule dataset parfaitement évalué.
Pourquoi ?
Parce que l’un des rôles principaux d’une eval est de détecter les régressions et les edge cases.
Trois cas extrêmement raffinés n’exercent que trois situations.
Vingt, cinquante ou cent cas représentatifs couvrent davantage la diversité réelle.
Cela ne signifie pas :
« La qualité du grader n’a aucune importance. »
Cela signifie :
Il faut arbitrer entre qualité du grading et couverture réelle des comportements.
Faire générer des cas par Claude
Le document suggère également de partir d’un petit ensemble humainement validé puis d’utiliser Claude pour générer des variantes et des edge cases supplémentaires.
Par exemple :
Voici cinq exemples de demandes client.
Génère des cas plus difficiles :
- informations contradictoires ;
- plusieurs dates ;
- absence d'information ;
- formulations ambiguës ;
- texte très long.Ensuite :
generated cases
↓
human spot-check
↓
eval datasetLe contrôle humain reste important pour éviter de polluer le dataset avec de mauvais cas ou des attentes incorrectes.
Le judge dans une pipeline CI/CD
Une architecture pratique pourrait distinguer deux niveaux.
Sur chaque modification
Exécuter :
unit tests
+
exact match evals
+
code gradersIls sont :
- rapides ;
- peu coûteux ;
- déterministes.
Sur une cadence plus lente
Exécuter :
full quality eval
+
LLM-as-judgePar exemple avant :
- une release ;
- un changement de modèle ;
- une modification importante du system prompt ;
- une nouvelle version du retrieval ;
- une nouvelle architecture agentique.
Le document source évoque précisément cette logique : les checks locaux peuvent tourner fréquemment, tandis que le judge est mieux adapté à une évaluation qualité périodique plus coûteuse.
Exemple de pipeline
Developer change
│
↓
Unit tests
│
↓
Code graders
│
↓
Quick eval
│
↓
Pass ?
┌────┴────┐
│ │
No Yes
│ │
stop ↓
Full eval
+
LLM judge
│
↓
Quality gate
│
↓
ReleaseOn crée ainsi une véritable quality gate.
Les métriques doivent servir une décision
Un score ne sert à rien s’il n’est associé à aucune règle de décision.
Par exemple :
baseline = 8.3Nouvelle version :
8.5Cela peut autoriser la promotion.
Mais si :
average = 8.5et que trois cas critiques passent de :
10 → 2le système ne devrait peut-être pas être déployé.
Il faut donc regarder :
aggregate score
+
critical cases
+
per-case breakdownet pas seulement une moyenne globale.
Exemple de règle de promotion
On pourrait définir :
Global score >= 8.5
AND
No critical case < 8
AND
Faithfulness >= baseline
AND
No regression > defined thresholdC’est seulement un exemple d’architecture ; le document source ne prescrit pas ces seuils numériques.
L’idée importante, elle, est bien présente dans le module : utiliser les evals comme signal mesurable pour décider si une modification améliore réellement le système.
Quand ne pas utiliser LLM-as-a-judge
Le document est très clair sur ce point.
Si l’output est :
"billing"et que la bonne réponse est :
"billing"utilisez :
exact matchSi la sortie doit simplement être du JSON valide :
code graderUn judge n’ajouterait que :
cost
+
latency
+
variancesans fournir un meilleur signal.
Tableau de décision rapide
| Situation | Solution |
|---|---|
| Une seule réponse correcte | Exact match |
| JSON valide | Code grader |
| Champs obligatoires | Code grader |
| Code parseable | Code grader |
| Valeur numérique dans une plage | Code grader |
| Résumé fidèle | LLM-as-judge |
| Qualité d’une justification | LLM-as-judge |
| Respect complexe des instructions | LLM-as-judge |
| Judge non comparé à des humains | Ne pas encore lui faire confiance |
Ce qu’il faut retenir pour la certification
Le pattern essentiel est :
Open-ended output
↓
LLM-as-judge
↓
Rubric
↓
Human-labeled calibration set
↓
Measure agreement
↓
Use judge at scale1. Le judge est un second appel modèle
Il est utilisé lorsqu’une règle de code ne peut pas mesurer correctement la qualité.
2. Une rubric explicite est indispensable
Le score doit correspondre à des critères observables.
3. Demander reasoning + strengths + weaknesses
Cela rend le score plus explicable et facilite le diagnostic.
4. Un judge doit être calibré
Comparer ses résultats à des human-labeled cases.
5. Mesurer l’accord
Une apparence de précision numérique ne signifie rien si le judge ne correspond pas suffisamment au jugement humain.
6. Le judge coûte plus cher
Chaque cas peut nécessiter un appel modèle supplémentaire.
7. Préférer les graders déterministes lorsqu’ils suffisent
exact/code
>
judgelorsqu’ils peuvent mesurer le comportement attendu.
Pièges d’examen
Scénario : vous voulez vérifier qu’un output contient quatre propriétés JSON obligatoires.
Réponse appropriée :
Code grader, pas LLM-as-judge.
Scénario : vous souhaitez évaluer si un résumé reste fidèle à un document tout en couvrant les informations importantes.
Réponse appropriée :
LLM-as-judge avec rubric.
Scénario : votre judge retourne systématiquement des scores très détaillés, mais vous ne l’avez jamais comparé à des évaluateurs humains.
Conclusion :
Le judge n’est pas encore calibré et ses scores ne sont pas suffisamment défendables.
Scénario : votre judge disagree fortement avec les humains.
Première action :
Améliorer la rubric, préciser les scores, ajouter des exemples, puis mesurer à nouveau l’accord.
Scénario : vous avez 2 000 cas de validation JSON à lancer à chaque commit.
Solution :
Code grader, parce qu’un judge ajouterait inutilement des milliers d’appels API.
À retenir en une phrase
Un
LLM-as-a-judgeest utile lorsque la qualité est ouverte et difficile à coder, mais son score n’est crédible qu’après avoir défini une rubric claire et calibré le judge sur des cas évalués humainement.
