Benchmarks et Évaluations — Lire Entre les Lignes

Pourquoi les Benchmarks Comptent (et Ne Suffisent Pas)

Chaque sortie de modèle s’accompagne d’un tableau de scores sur des benchmarks standardisés, et ces chiffres circulent ensuite tels quels dans les articles de presse et les présentations internes. Ils sont utiles : ils donnent une première idée des capacités et permettent de situer un modèle dans le paysage. Mais ils deviennent trompeurs dès qu’on les lit sans savoir ce qu’ils mesurent réellement. Cette leçon vous apprend à les interpréter avec le recul d’un praticien plutôt qu’avec l’enthousiasme d’un communiqué.

Ce Que Mesurent les Benchmarks Standards

MMLU (Massive Multitask Language Understanding) évalue la connaissance générale d’un modèle sur 57 domaines — histoire, physique, droit, médecine, informatique — sous forme de QCM à quatre choix. Il mesure donc l’étendue des connaissances factuelles, et rien d’autre : ni la capacité à raisonner, ni celle à suivre des instructions complexes, ni la qualité rédactionnelle. Les meilleurs modèles dépassent aujourd’hui 85 à 90 %, ce qui signifie aussi que le benchmark discrimine de moins en moins bien le haut du classement. Un modèle excellent en MMLU peut parfaitement échouer à rédiger une note de synthèse lisible.

HumanEval teste la génération de code Python fonctionnel à partir d’une description en langage naturel, et MBPP (Mostly Basic Python Problems) fait de même avec des problèmes plus simples. Ces benchmarks mesurent la capacité à écrire une fonction isolée correcte. Ils ne disent rien de la capacité à travailler dans une base de code existante, à déboguer un comportement inattendu ou à architecturer un projet — c’est-à-dire l’essentiel du métier. Des variantes existent, HumanEval+ avec des tests plus stricts, MultiPL-E pour couvrir plusieurs langages.

LMArena, anciennement Chatbot Arena, procède autrement : de vrais utilisateurs posent leurs questions à deux modèles anonymes et votent pour la meilleure réponse, le classement se construisant sur un système Elo emprunté aux échecs. Ce dispositif mesure la qualité perçue dans des conversations libres, ce qui en fait le benchmark le plus proche de l’usage réel. Sa faiblesse est symétrique : il ne dit rien des performances sur une tâche technique précise, et il favorise mécaniquement les réponses agréables à lire.

D’autres évaluations complètent le tableau selon la capacité visée. GSM8K et MATH portent sur la résolution de problèmes mathématiques, ARC sur le raisonnement scientifique de niveau secondaire, HellaSwag sur la complétion de scénarios de bon sens, TruthfulQA sur la résistance aux hallucinations et à la désinformation, et CTO Bench sur des tâches de codage end-to-end nettement plus réalistes que HumanEval.

Quatre Règles pour Lire un Tableau de Scores

La première règle est de comparer les comparables. Opposer un modèle de 3 milliards de paramètres à un modèle de 70 milliards sur les mêmes colonnes n’a aucun sens si l’on ignore l’écart de taille et de coût. La question pertinente n’est jamais « qui a le meilleur score » mais « pour un budget donné, quel modèle rend les meilleurs résultats ».

La deuxième règle invite à se méfier des améliorations marginales. Un écart d’un ou deux points sur MMLU entre deux modèles est généralement insignifiant : les benchmarks ont une variance naturelle, et cette différence ne se traduira par rien de perceptible pour vos utilisateurs. Elle fait pourtant d’excellents titres de communiqué.

La troisième règle consiste à chercher la cohérence. Un modèle qui brille sur un seul benchmark et reste dans la moyenne partout ailleurs doit éveiller la méfiance ; les modèles solides affichent des performances régulières sur l’ensemble des évaluations.

La quatrième règle est de vérifier la date. Les scores publiés au lancement d’un modèle peuvent ne plus être représentatifs quelques mois plus tard, parce que de nouveaux concurrents sont arrivés et que les méthodologies d’évaluation ont évolué. Un tableau non daté, dans une présentation commerciale, mérite qu’on demande d’où il vient.

Trois Limites Structurelles

La contamination est la plus insidieuse. Les modèles sont entraînés sur d’immenses corpus de texte qui peuvent contenir les questions et les réponses des benchmarks eux-mêmes. Un score élevé peut alors refléter une mémorisation plutôt qu’une capacité de raisonnement, sans qu’aucune malveillance soit en jeu.

La représentativité pose un problème différent : les benchmarks standardisés ne reflètent pas votre cas d’usage. Un modèle qui excelle sur MMLU peut se révéler médiocre pour rédiger des courriels commerciaux en français, tout simplement parce que personne n’a jamais évalué cette tâche. Les benchmarks mesurent des capacités génériques, jamais des performances dans votre contexte.

L’optimisation, enfin, est une conséquence prévisible de la publicité faite aux classements. Les laboratoires connaissent les benchmarks et peuvent orienter l’entraînement pour y performer, parfois au détriment d’autres tâches. C’est le phénomène du « teaching to the test », bien documenté ailleurs qu’en intelligence artificielle.

Croiser les Sources, puis Tester Vous-Même

Plutôt que de vous fier aux seuls chiffres publiés par un fournisseur — Mistral comme n’importe quel autre —, croisez-les avec des classements indépendants. Artificial Analysis compare qualité, prix, vitesse et latence sur une base homogène. LMArena reflète la préférence humaine en conditions réelles. Le Scale AI Leaderboard se concentre sur le codage, le suivi d’instructions et les mathématiques. Les rankings OpenRouter s’appuient sur l’usage effectif, donc sur ce que les développeurs choisissent réellement de payer. CTO Bench, enfin, propose des tâches de codage réalistes et end-to-end.

Reste que la seule évaluation qui engage vraiment votre décision est celle que vous menez avec vos données, vos cas d’usage et vos critères de qualité. La méthode tient en six gestes :

1. Constituez un jeu de test de 20 à 50 exemples représentatifs de votre usage réel
2. Définissez explicitement vos critères de qualité (précision, ton, exhaustivité, format)
3. Testez 2 ou 3 modèles candidats sur ce même jeu
4. Évaluez en aveugle si possible, sans savoir quel modèle a produit quelle réponse
5. Mesurez également la latence et le coût par requête
6. Décidez au regard du rapport qualité/coût/contraintes

L’évaluation en aveugle mérite une insistance particulière : rien ne biaise davantage un jugement que de savoir qu’une réponse vient du modèle qu’on espérait voir gagner.

Points Clés à Retenir

• Les benchmarks donnent une première indication, mais ne suffisent pas pour choisir un modèle
• MMLU mesure les connaissances, HumanEval le code, LMArena la préférence humaine
• Méfiez-vous des différences marginales et de la contamination des benchmarks
• Consultez les classements indépendants (Artificial Analysis, LMArena, Scale AI)
• La meilleure évaluation est toujours celle que vous faites avec vos propres données