Faire évaluer un LLM par un autre LLM, la nouvelle frontière du testing

Évaluer la qualité d’une réponse de LLM, surtout pour des tâches ouvertes comme la synthèse ou la réponse à une question, a toujours été un processus coûteux et manuel. Les métriques classiques comme BLEU ou ROUGE sont peu corrélées avec la perception humaine. L’émergence de frameworks open-source comme llm-verify popularise une nouvelle approche : utiliser un LLM puissant (souvent propriétaire, comme GPT-4) comme un “juge” pour évaluer les réponses d’un autre modèle. Cette technique, “LLM-as-a-judge”, permet de scaler l’évaluation de la qualité sémantique, mais elle n’est pas une solution miracle et comporte ses propres biais et coûts.

comment ça marche ?

Le principe est de fournir au LLM-juge un prompt très structuré qui contient la question initiale, la réponse à évaluer, et parfois la “vérité terrain” (la réponse attendue). On lui demande de noter la réponse sur plusieurs critères et de fournir une justification.

un exemple de prompt d’évaluation

Un bon prompt d’évaluation est la clé. Il doit être extrêmement précis pour limiter la subjectivité du juge.

Tu es un évaluateur expert et impartial. Évalue la réponse fournie sur une échelle de 1 à 5 selon les critères suivants :

1.  **Exactitude factuelle**: La réponse est-elle cohérente avec la source de vérité ? (1=totalement fausse, 5=totalement exacte)
2.  **Complétude**: La réponse couvre-t-elle tous les aspects importants de la question ? (1=très incomplète, 5=très complète)
3.  **Style et Ton**: Le ton est-il approprié pour un client ? (1=inapproprié, 5=parfait)

[Source de vérité]
...
[Question]
...
[Réponse à évaluer]
...

[Sortie]
Fournis ta réponse au format JSON avec les clés `score_exactitude`, `score_completude`, `score_style`, et `justification`.

avantages et limites

les avantages

Scalabilité: Permet d’évaluer des milliers de réponses de manière automatique, là où une évaluation humaine serait trop lente et coûteuse.
Évaluation de la nuance: Le LLM-juge peut évaluer des aspects qualitatifs (style, ton, pertinence) qu’aucune métrique traditionnelle ne peut capturer.
Itération rapide: On peut obtenir un feedback qualitatif sur un nouveau prompt ou un nouveau modèle en quelques minutes.

les limites et risques

Biais du juge: Le LLM-juge a ses propres biais. Il a tendance à préférer les réponses plus longues et celles qui ressemblent à son propre style.
Coût: Utiliser un modèle puissant comme GPT-4 pour chaque évaluation peut vite devenir cher, surtout sur de grands jeux de test.
Manque de sensibilité: Pour des tâches très spécifiques ou de niche, le juge peut ne pas avoir l’expertise nécessaire pour évaluer correctement la réponse.
Reproductibilité: Les scores peuvent varier légèrement d’une exécution à l’autre si la temperature du juge n’est pas à zéro.

intégration dans la CI/CD

L’évaluation par LLM devient vraiment puissante lorsqu’elle est intégrée dans un pipeline de CI/CD. À chaque pull request qui modifie un prompt, la CI lance l’évaluation sur un “golden dataset” (un jeu de test de référence) et bloque la PR si le score moyen se dégrade.

# Exemple d'étape dans un pipeline GitHub Actions
- name: "Evaluate LLM response quality"
  id: llm_eval
  run: |
    # Ce script exécute l'évaluation et retourne un score
    SCORE=$(python -m llm_verify --answers-file new_answers.json --golden-dataset golden.json)
    echo "::set-output name=quality_score::$SCORE"

- name: "Check quality gate"
  if: steps.llm_eval.outputs.quality_score < env.MIN_QUALITY_THRESHOLD
  run: |
    echo "La qualité des réponses a régressé. Le build est rejeté."
    exit 1

notre retour d’expérience

Après avoir intégré llm-verify dans nos pipelines, nous avons constaté que :

C’est un excellent détecteur de régressions. Il est très efficace pour repérer quand un changement de prompt dégrade la qualité des réponses sur des cas connus.
Il ne remplace pas l’évaluation humaine. Pour le lancement d’une nouvelle fonctionnalité majeure, une revue manuelle par des experts reste indispensable.
Le coût est un facteur à surveiller. Nous avons optimisé en n’utilisant le LLM-juge que sur un sous-ensemble des tests pour les PRs, et sur le set complet uniquement pour les déploiements en staging.

faq

Quel modèle choisir comme “juge” ? Le plus puissant et le moins biaisé possible. Actuellement, les modèles de la classe de GPT-4 sont considérés comme les plus fiables pour cette tâche.
Comment construire un bon “golden dataset” ? Il doit être représentatif de vos cas d’usage réels. Incluez des exemples simples, des cas limites, et des questions auxquelles le système est censé refuser de répondre. Commencez avec 50 exemples et enrichissez-le au fil du temps avec les échecs que vous observez en production.
Peut-on utiliser un modèle open source comme juge ? Oui, mais il faut être prudent. Les modèles open source actuels peuvent avoir des biais plus prononcés et être moins bons pour suivre des instructions complexes. Il est recommandé de comparer leurs évaluations à celles d’un modèle de pointe et à des évaluations humaines pour calibrer leur fiabilité.

Menu