MMLU : pourquoi le nom d'un benchmark ne suffit pas à le définir
En bref
- Deux modèles d'une même famille déclarent des scores MMLU différents (0.781 et 0.79) sous le même nom de benchmark, mais avec des frames différentes (split de données, implémentation, grader, runner).
- Le benchmark_id « mmlu » ne fixe que le nom, pas la procédure complète d'évaluation : split (dev vs test vs test-lite), implémentation (HELM vs Eleuther vs code original), prompt format, grader et accès réseau du runner restent libres.
- L'article propose que la comparabilité soit attachée à la référence traçable (hash du frame), pas au nombre seul : deux frames différentes ne sont pas comparables, même avec des chiffres identiques.
- L'APL AI-Eval profile utilise des content-addressed objects (hashes) pour que chaque revendication porte sa procédure complète et soit vérifiable.
Ce que dit la source
L'auteur affirme qu'une différence de 0.009 entre deux scores MMLU du même modèle pose un problème de comparabilité non résolvable par un simple benchmark_id. Deux évaluations déclarent le même provider, model family, metric et benchmark name, mais leurs frames (procédures d'évaluation) diffèrent : runners, graders et dataset splits ne sont pas identiques. Pour l'auteur, le vrai problème est qu'un nom de benchmark fixe l'intention mais pas la réalité : « mmlu » désigne une famille de datasets, pas une procédure complète. Cela rend impossible de répondre à une requête « score-delta » sans d'abord aligner les conditions d'évaluation. L'article propose un modèle alternatif : chaque claim (revendication de score) doit porter avec elle le hash de son frame complet, de sorte que deux frames différentes ne puissent pas être comparées sans travail explicite.
- Cinq variables restent ouvertes une fois « mmlu » fixé : la split (dev 285 questions, test 14,042 ou test-lite non publié), l'implémentation (HELM, Eleuther, code original produisent 0.637/0.488/0.636 pour llama-65b), le prompt format, le grader et l'accès réseau du runner.
- La Hugging Face dataset (cais/mmlu) diffère de l'archive papier Hendrycks : test set 14,042 vs 14,079, validation 1,531 vs 1,540. L'archive originale n'est plus accessible (HTTP 403 en septembre 2026).
- Un seul benchmark_id ne suffît pas : le Open LLM Leaderboard (juin 2023) documente trois harnesses (HELM, Eleuther, code original) qui évaluent le même dataset en 5-shot et obtiennent des résultats non comparables malgré le label MMLU partagé.
- Le frame_ref.hash permet la traçabilité : dans l'APL AI-Eval profile, chaque claim porte le hash sha256 de son frame complet (procédure, split, grader). Deux frames différentes produisent deux hashes différents ; la comparabilité est une propriété du frame, pas du nombre.
- apl-valid valide la structure mais ne dit rien sur la correction du score : un frame bien formé peut déclarer une mauvaise procédure.
Dans les commentaires
Débat très maigre (2 commentaires seulement, tous deux critiques de la forme, zéro débat substantiel). Le fil éclaire peu sur les mérites de la proposition.
- Deux commentateurs soulignent que la présentation de l'article (structure « What X does not fix », même la TL;DR) est opaque et quasi inintelligible, sans engagement sur le fond technique.
- Le débat sur le fil est trop limité pour restituer des objections ou alternatives substantielles à la thèse de l'auteur ; il ne porte que sur l'accessibilité rédactionnelle.
Notre lecture
L'article identifie un problème réel et peu discuté : la comparabilité de scores de benchmark dépend de la procédure d'évaluation, pas du nom du benchmark seul. L'exemple MMLU est convaincant (implementation variance documentée = 0.637 vs 0.488 pour le même modèle). La proposition du APL AI-Eval profile (content-addressed frames avec hashes) est intéressante mais très technique et peu testée à l'échelle. Pour une DSI ou une équipe d'ML, le takeaway pratique est clair : un score MMLU seul n'est jamais suffisant ; toujours demander la procédure complète (split, implémentation, prompt, grader). Difficile d'en tirer une recommandation d'outil ou de changement immédiat, mais utile à comprendre pour toute revendication de benchmark public. Le problème existe, la solution proposée est trop jeune pour être actionnelle.