LLM-as-a-judge : faire évaluer les réponses d'une IA par une autre IA

Quand on teste un assistant IA, la revue humaine de chaque réponse devient vite impossible. Une technique s’est imposée pour passer à l’échelle : le LLM-as-a-judge, ou LLM évaluateur. On confie à un second modèle la notation des réponses du premier, selon des critères précis.

L’idée est simple. Bien l’appliquer l’est beaucoup moins.

Le principe

Pour chaque scénario de test, on fournit au LLM évaluateur :

• la question posée ;
• la réponse produite par l’agent testé ;
• éventuellement une réponse de référence ou des éléments attendus ;
• une grille d’évaluation explicite.

Il renvoie une note et une justification, idéalement dans un format structuré (JSON) que le test peut lire.

Une bonne grille fait un bon juge

L’erreur classique est de demander « Cette réponse est-elle bonne ? Note de 1 à 10 ». Le résultat est flou et instable. Une bonne grille découpe le jugement en critères binaires ou à peu de niveaux :

• La réponse contient-elle l’information X ? (oui / non)
• Contient-elle une affirmation absente du document source ? (oui / non)
• Reste-t-elle dans le périmètre du produit ? (oui / non)
• Le ton est-il adapté à un client ? (oui / partiellement / non)

Des questions fermées donnent des verdicts plus reproductibles, et des échecs plus faciles à comprendre.

Les pièges à connaître

Un LLM évaluateur a ses propres biais, documentés dans la littérature sur l’évaluation des modèles :

• Le biais de longueur : il a tendance à préférer les réponses longues.
• Le biais de position : quand on lui demande de comparer deux réponses, l’ordre de présentation peut influencer le verdict.
• La complaisance : il peut juger favorablement des réponses produites par un modèle de la même famille que lui.
• L’instabilité : la même évaluation lancée deux fois peut donner deux notes.

Comment s’en protéger

1. Étalonner le juge : faites noter par des humains un échantillon de réponses, puis comparez avec les verdicts du LLM. Tant que l’accord n’est pas satisfaisant, retravaillez la grille.
2. Fixer les paramètres : même modèle, même version, température basse, prompt versionné dans le dépôt comme du code.
3. Inverser l’ordre dans les comparaisons par paires, et ne garder que les verdicts cohérents.
4. Garder des assertions déterministes pour tout ce qui peut l’être (format, appels d’outils, mots interdits). Le juge ne sert qu’à ce qui exige vraiment du jugement.
5. Relire les échecs : chaque échec signalé par le juge mérite un coup d’œil humain, au moins au début.

Où le placer dans votre stratégie

Le LLM évaluateur est un outil de mesure à grande échelle, pas un oracle. Je l’utilise pour suivre l’évolution de la qualité d’une version à l’autre sur des centaines de scénarios, et pour repérer les régressions. Les décisions de mise en production, elles, restent appuyées sur des critères vérifiables et sur la revue humaine des cas critiques.

Dans un prochain article, je montrerai comment brancher ce type d’évaluation dans une CI, à côté de vos tests Playwright habituels.