Module 9 — Évaluation : jeux de référence et jugements humains

Un modèle qui affiche 82 pour cent sur MMLU est-il bon pour notre assistant de support ? La question paraît naïve, elle est en réalité fondamentale : on ne connaît pas de métrique unique qui prédise la qualité perçue en production. Ce module montre pourquoi les jeux de référence publics sont insuffisants, pourquoi les arènes humaines et les modèles-juges ne les remplacent pas, et comment construire un jeu d'évaluation métier qui, lui, tranche entre deux options.

Les jeux de référence, à quoi ils servent vraiment

Les jeux publics — MMLU, HellaSwag, GSM8K, HumanEval — ont un rôle : comparer rapidement deux modèles sur des tâches standardisées. Ils permettent le suivi d'une famille à travers ses versions, et le classement d'une communauté sur une échelle commune.

MMLU (Massive Multitask Language Understanding) contient 57 sujets académiques allant de l'histoire américaine à la médecine, en questions à choix multiples. C'est le tableau de bord de facto de la communauté des LLM.

Jeu de référence	Ce qu'il mesure	Ce qu'il ne mesure pas
MMLU	connaissance factuelle en 4 choix	raisonnement libre, factualité en génération
HellaSwag	complétion de sens commun	logique formelle
GSM8K	arithmétique scolaire	mathématique de recherche
HumanEval	codage Python court	codage sur base réelle
MT-Bench	dialogue via juge modèle	robustesse et sécurité

Ces jeux évaluent des compétences génériques, dans des formats précis. Rien de ce qui figure dans le tableau ne mesure la capacité à répondre à un client mécontent en français, en 200 jetons, sans dépasser le mandat commercial. Ce dernier point est exactement ce qui compte pour notre projet.

La contamination, le biais qui vide les scores

La menace la plus sérieuse sur les jeux publics est la contamination : le corpus de préentraînement, tiré du web, contient tout ou partie des questions et réponses des jeux de test. Le modèle ne « raisonne » plus sur la question ; il la reconnaît. Sa performance apparente sur MMLU peut alors dépasser ce qu'il ferait sur un jeu inédit du même niveau.

Détecter la contamination est difficile mais pas impossible :

• Comparer les questions à des empreintes floues (MinHash) sur le corpus.
• Mesurer la performance sur des variantes reformulées : si un modèle chute de 15 points sur des reformulations, c'est le signe d'une reconnaissance mémorisée.
• Comparer performance sur des questions publiées avant et après la date de coupure du modèle.

Une étude systématique (Roberts et al., 2023) a montré que la plupart des jeux publics majeurs sont partiellement présents dans les corpus des grands modèles. La conséquence : on ne peut pas prendre un score MMLU au pied de la lettre pour un modèle sorti après une date de publication.

Les arènes et le score Elo

Les arènes, comme LMSYS Chatbot Arena, procèdent différemment. Un utilisateur pose une question, reçoit deux réponses anonymes produites par deux modèles tirés au hasard, et choisit laquelle est meilleure. Les résultats de dizaines de milliers de duels alimentent un score Elo, similaire à celui des échecs.

$$E_A = \frac{1}{1 + 10^{(R_B - R_A)/400}}.$$

Le principe : le nouveau score d'un modèle dépend de qui il a battu et à quel point ces adversaires sont forts. L'échelle Elo est relative, sans signification absolue ; un modèle à 1 250 est simplement plus faible qu'un modèle à 1 350 par une marge estimée.

Les arènes ont deux vertus. Elles évaluent le comportement réel dans des conversations diverses, et elles n'ont pas de jeu de questions figé à contaminer. Elles ont aussi deux limites.

• Les utilisateurs des arènes ne représentent pas les publics métiers. Ce sont plutôt des développeurs curieux, en anglais, qui testent des cas amusants.
• Les préférences humaines fluctuent selon la longueur, le ton, la mise en forme. Un modèle un peu bavard, courtois et joliment formaté gagne des points sans être plus juste.

Le score d'arène est donc utile comme signal global, insuffisant comme critère d'achat.

Le modèle juge, un miroir imparfait

Une pratique courante depuis 2023 consiste à faire évaluer les sorties par un LLM plus grand, souvent GPT-4 ou son équivalent. C'est l'idée derrière MT-Bench, AlpacaEval et beaucoup de bancs d'évaluation internes.

def juger(question, reponse_a, reponse_b, juge):
    invite = (
        "Compare ces deux reponses a la meme question. "
        "Indique laquelle est meilleure sur trois criteres : exactitude, "
        "clarte, utilite. Reponds strictement au format JSON.\n\n"
        f"Question : {question}\n\n"
        f"Reponse A : {reponse_a}\n\n"
        f"Reponse B : {reponse_b}\n\n"
        "JSON attendu : {\"gagnant\": \"A\"|\"B\"|\"egalite\", \"raisons\": \"...\"}"
    )
    return juge.generer(invite, temperature=0.0)

Le modèle juge accélère l'évaluation d'un facteur cent par rapport à un jugement humain. Il a aussi des biais bien documentés.

• Biais de position : le modèle préfère la réponse A ou la réponse B selon l'ordre de présentation. On corrige en évaluant chaque paire dans les deux sens.
• Biais de longueur : les réponses plus longues sont mieux notées, indépendamment du fond.
• Biais de style : les réponses qui « ressemblent » aux réponses que le juge produit lui-même sont favorisées.
• Biais de famille : un juge GPT-4 favorise très légèrement les modèles GPT-4.

Un modèle juge est utile pour un signal rapide sur des changements internes. Il ne remplace pas un jugement humain pour la décision finale.

Construire un jeu d'évaluation métier

C'est la partie la plus rentable, et pourtant la plus négligée. Cinquante à trois cents cas soigneusement construits, dans la langue, le format et le sujet du produit, valent plus que n'importe quel jeu public.

La méthode :

1. Collecter cent à cinq cents échanges réels du support, anonymisés.
2. Faire annoter par des opérateurs expérimentés : quelle serait la réponse idéale, quelle est la classe de la question (info produit, réclamation, litige, hors périmètre).
3. Ajouter des cas adversariaux : questions déguisées, demandes hors mandat, tentatives de manipulation.
4. Ajouter des cas d'abstention : questions dont la réponse n'est pas dans la documentation, où l'assistant doit refuser proprement.
5. Pour chaque cas, définir la métrique. Certaines réponses ont une bonne solution unique (exactitude), d'autres ont plusieurs bonnes formulations (score de couverture par un juge, avec l'humain en superviseur).

# Squelette d'un jeu d'evaluation metier
cas = [
    {
        "id": "case-001",
        "classe": "info_produit",
        "question": "Le modèle X est-il compatible avec le socle Y ?",
        "reponse_ideale": "Oui, la compatibilité est indiquée en fiche technique, section 4.",
        "metrique": "couverture",
    },
    {
        "id": "case-002",
        "classe": "abstention",
        "question": "Quelle est la garantie sur le modèle Z-2027 (produit non commercialisé) ?",
        "reponse_ideale": "Je ne trouve pas cette information ; je vous transfère à un opérateur.",
        "metrique": "abstention_stricte",
    },
    # ... 50 a 300 cas
]

Le tableau qui en sort — modèle × cas × métrique — est la seule chose qui permet, en fin de projet, de comparer honnêtement le modèle A servi par API et le modèle B servi en interne. Sans cet outil, la décision se prend sur des impressions, ce qui suffit rarement à convaincre une direction.

Combiner les niveaux d'évaluation

Un bon programme d'évaluation superpose plusieurs échelles.

Niveau	Cadence	Coût	Rôle
Score sur jeu public	1 par version majeure	gratuit	tri des candidats
Score modèle juge sur jeu métier	à chaque changement de code	quelques centimes	garde-fou continu
Jugement humain sur échantillon	mensuel	temps opérateur	vérité de référence
Retour utilisateur en ligne	continu	outillage	dérive et régressions

Les niveaux ne se remplacent pas, ils se contrôlent l'un l'autre. Un modèle juge qui diverge d'un jugement humain signale un biais du juge. Un retour utilisateur qui diverge du jeu métier signale une évolution des demandes. C'est ce système à quatre niveaux qui rend un assistant améliorable dans le temps.

Un score isolé ment presque toujours

« Notre nouveau modèle bat le précédent de deux points sur MMLU » : c'est une phrase qu'aucun décideur ne devrait accepter comme argument. Ce que la marge de deux points cache, c'est la variance de mesure (souvent supérieure à un point), la contamination, le décodage utilisé, et surtout la distance entre MMLU et l'usage réel. Un chiffre sans écart-type et sans description du protocole doit être considéré comme une opinion.

Le petit jeu qui change tout

Vingt cas construits pour votre métier valent plus qu'un million de questions publiques. Consacrez une demi-journée d'opérateur à en écrire vingt, exécutez-les à chaque modification, et l'équipe cessera de piloter à l'aveugle. Ce jeu grandit organiquement : chaque bogue rencontré en production devient un cas de plus.

En résumé

• Les jeux publics (MMLU, HellaSwag, GSM8K) trient rapidement les candidats mais ne prédisent pas la performance métier, et souffrent de contamination difficile à écarter.
• Les arènes et le score Elo évaluent le comportement réel sur diverses conversations, mais reflètent les préférences d'un public spécifique et sont sensibles à la longueur, au ton et à la mise en forme.
• Un modèle juge accélère l'évaluation d'un facteur cent, avec des biais documentés (position, longueur, style, famille) que l'on compense mais ne supprime pas.
• Un jeu d'évaluation métier — 50 à 300 cas soigneusement annotés, incluant abstention et adversaires — est la seule mesure qui tranche vraiment entre deux options en production.

Module suivant : les chiffres qui décident du choix d'architecture, entre API et auto-hébergement, pour clore le fil rouge.