Passer au contenu principal
Le nombre de paramètres seul ne vous indique pas si un modèle est bon. Un modèle de 7B entraîné sur les bonnes données peut surpasser un modèle de 13B bâclé en programmation, et un modèle de 8B bien ajusté peut battre un modèle de 70B dans le suivi des instructions. Sans moyen de mesurer la capacité, vous devinez. Les benchmarks d’évaluation — les « éval » — sont des tests standardisés qui vous donnent des chiffres comparables entre les modèles. Ils sont imparfaits, parfois trompeurs, et occasionnellement truqués, mais ils constituent le meilleur outil disponible pour comparer les modèles avant d’engager du matériel pour l’un d’eux. Cette page explique ce que mesurent les principaux benchmarks, comment lire leurs scores, et lesquels comptent réellement pour votre cas d’utilisation.

​
Pourquoi les éval existent

Vous ne pouvez pas juger un modèle uniquement par son nombre de paramètres, la taille de ses données d’entraînement ou son architecture. Ces chiffres décrivent la capacité — ce que le modèle pourrait théoriquement faire — et non la compétence, ce qu’il fait réellement lorsque vous lui donnez un prompt. Les benchmarks existent pour combler cet écart. Un bon benchmark :
  • Standardise la comparaison — chaque modèle répond aux mêmes questions dans les mêmes conditions.
  • Révèle les forces et les faiblesses — un modèle qui obtient de bons scores en mathématiques peut être médiocre en code.
  • Suit les progrès — vous pouvez voir si une nouvelle génération de modèles s’est réellement améliorée ou s’est simplement agrandie.
Mais chaque benchmark a des angles morts. Un score MMLU élevé ne garantit pas que le modèle rédige de bons e-mails. Un score HumanEval faible ne signifie pas que le modèle ne peut pas vous aider à déboguer. Les benchmarks sont un point de départ, pas un verdict.

​
Le paysage des benchmarks

Voici les principaux benchmarks que vous rencontrerez sur les fiches modèles et les classements :
MMLU (Massive Multitask Language Understanding) est le benchmark le plus largement cité. Il couvre 57 matières allant des STEM aux sciences humaines et sociales, du niveau lycée au niveau professionnel. Chaque question est un QCM avec 4 options. Un score de 70 signifie que le modèle répond correctement à 70% de ces questions. MMLU est utile comme indicateur de capacité globale mais ne teste pas la génération ouverte, la créativité ou le suivi des instructions. La plupart des fiches modèles rapportent le score 5-shot.
Ces 2 benchmarks mesurent la génération de code. HumanEval comporte 164 problèmes Python rédigés à la main où le modèle génère une fonction à partir d’un docstring, puis des tests sont exécutés pour vérifier la correction. MBPP est plus grand (~1000 problèmes) mais couvre des tâches algorithmiques plus simples. Les deux rapportent le pass@1 — le pourcentage de problèmes résolus correctement du premier coup. Ils sont bons pour comparer la capacité de codage mais couvrent une tranche étroite de la programmation réelle.
MT-Bench évalue la qualité conversationnelle à travers 80 prompts multi-tours notés par GPT-4 ou des juges humains sur une échelle de 1 à 10. Chatbot Arena (LMSYS) est différent : il oppose 2 modèles anonymes et laisse les utilisateurs voter, produisant un classement ELO comme les ratings d’échecs. Les scores Arena reflètent la préférence utilisateur réelle mais se mettent à jour lentement et favorisent les modèles qui produisent des réponses polies et confiantes plutôt que les modèles qui sont corrects mais concis.
SWE-Bench teste si un modèle peut résoudre de vrais problèmes GitHub de bout en bout : lire le problème, trouver le bug dans une grande base de code, et générer une pull request correcte. Les meilleurs modèles résolvent 30–50% des problèmes sur le sous-ensemble vérifié. C’est le benchmark le plus proche du travail d’ingénierie logicielle réel, mais il est extrêmement difficile et les résultats varient fortement selon le langage et le framework.
LiveBench actualise son ensemble de tests mensuellement avec de nouvelles données, ce qui le rend résistant à la contamination des benchmarks — les modèles ne peuvent pas avoir mémorisé des réponses qu’ils n’ont pas vues pendant l’entraînement. Il couvre les mathématiques, le codage, le raisonnement, la langue, l’analyse de données et le suivi des instructions. Il est plus récent que MMLU ou HumanEval mais de plus en plus cité comme un signal plus fiable.

​
Comment lire un tableau de benchmarks

Les scores semblent autoritaires, mais ils ont besoin de contexte pour être utiles.

​
Ce que signifient les chiffres

La plupart des benchmarks rapportent un score de 0 à 100, qui est le pourcentage de questions auxquelles le modèle a répondu correctement. Un score MMLU de 70 signifie que le modèle répond correctement à 70% des questions à choix multiples de niveau universitaire. Les ratings ELO (utilisés par Chatbot Arena) sont différents — ce sont des classements relatifs où un écart de 100 points signifie que le modèle le mieux classé gagne environ 64% des affrontements en tête-à-tête.

​
Marge d’erreur

Une différence de 1 à 2 points sur un seul benchmark est du bruit. La méthodologie de notation, le formatage du prompt, et même la variation de la graine aléatoire peuvent faire varier les scores de cette quantité. Si le Modèle A obtient 72 et le Modèle B 74 sur MMLU, considérez-les comme équivalents et regardez un benchmark qui teste la capacité spécifique qui vous intéresse.

​
Contamination

La contamination des benchmarks se produit lorsque les questions de test fuient dans les données d’entraînement d’un modèle. Le modèle obtient un score artificiellement élevé parce qu’il a déjà vu les réponses. C’est un problème croissant à mesure que les benchmarks sont largement publiés. LiveBench et certains benchmarks plus récents luttent contre cela en actualisant régulièrement leurs ensembles de tests.
Lorsque le score d’un benchmark d’un modèle semble suspectement élevé par rapport à ses performances réelles, la contamination est une explication probable. Vérifiez si le benchmark a été publié avant la date de coupure d’entraînement du modèle.

​
Cherry-picking

Ne jugez jamais un modèle par un seul benchmark. Les éditeurs mettent parfois en avant le 1 score où leur modèle semble le meilleur tout en enterrant les résultats plus faibles. Cherchez une série de benchmarks couvrant différentes capacités — connaissances, code, mathématiques, suivi des instructions — avant de tirer des conclusions.

​
Quels benchmarks comptent pour votre cas d’utilisation

Tous les benchmarks ne comptent pas pour toutes les tâches. Concentrez-vous sur ceux qui testent ce dont vous avez réellement besoin :

Assistant de codage

Regardez : HumanEval, MBPP, SWE-Bench. Ceux-ci mesurent directement la génération de code et l’ingénierie logicielle. Ignorez MMLU pour cette décision — un modèle peut obtenir un score élevé en trivia et écrire quand même du mauvais code.

Chatbot et conversation générale

Regardez : MT-Bench, ELO Chatbot Arena, IFEval. La qualité conversationnelle est subjective, donc les benchmarks notés par des humains comptent le plus. IFEval ajoute une mesure de la fiabilité avec laquelle le modèle suit les instructions de formatage et de contraintes.

Raisonnement et analyse

Regardez : GSM8K, MATH, GPQA, ARC-Challenge, BigBench Hard. Ceux-ci testent la logique en plusieurs étapes à différents niveaux de difficulté. GPQA est le plus difficile — utile pour séparer les modèles de pointe des simplement bons.

Assistant général

Regardez : MMLU + MT-Bench + IFEval comme un composite. Aucun chiffre unique ne capture la qualité d’un « assistant général ». Vérifiez les 3 pour avoir une image de la largeur des connaissances, de la compétence conversationnelle et de la conformité aux instructions.
Lorsque vous comparez 2 modèles similaires, passez les moyennes et regardez le benchmark spécifique qui correspond à votre tâche. Un modèle de codage de 7B et un modèle de chat de 7B peuvent avoir des scores MMLU similaires mais des résultats HumanEval très différents.

​
Scores de benchmark à différentes quantifications

Les scores de benchmark sont généralement rapportés à pleine précision (FP16 ou BF16). Lorsque vous exécutez un modèle quantifié localement, attendez une certaine dégradation des scores.

​
À quel point la quantification coûte-t-elle cher ?

L’impact dépend du benchmark, de la taille du modèle et du niveau de quantification :

​
Quand la quantification fait plus mal

  • Les petits modèles perdent plus que les grands modèles. Un modèle de 7B quantifié en Q4_K_M baisse plus qu’un modèle de 70B au même niveau de quantification, car le modèle plus petit a moins de redondance pour absorber les erreurs d’arrondi.
  • Les tâches précises souffrent plus. Les mathématiques et la génération de code sont plus sensibles à la précision des poids que le chat général. Si vous exécutez un assistant de codage, envisagez Q5_K_M ou plus.
  • Les i-quants peuvent aider à faibles largeurs de bits. La quantification Imatrix (IQ4_XS, IQ3_XXS) préserve les poids critiques plus soigneusement et peut récupérer 1–2 points par rapport aux K-quants standards à la même taille.
Un modèle de 70B en Q4_K_M surpasse presque toujours un modèle de 7B à pleine précision sur la plupart des benchmarks. La taille du modèle compte plus que le niveau de quantification lorsque l’écart de taille est important.

​
Exécuter vos propres éval

Les benchmarks publiés sont un point de départ. Si vous devez savoir comment un modèle se comporte sur vos tâches avec votre configuration, exécutez votre propre évaluation.

​
Quand exécuter vos propres éval

  • Vous avez un cas d’utilisation spécifique à un domaine (juridique, médical, financier) que les benchmarks standards ne couvrent pas.
  • Vous comparez 2 modèles qui obtiennent des scores similaires sur les benchmarks publics.
  • Vous testez une quantification ou un fine-tune spécifique et voulez mesurer l’impact réel.
  • Vous devez valider qu’un modèle gère vos cas limites avant de le déployer.

​
Outils pour exécuter des éval

lm-evaluation-harness (par EleutherAI) est l’outil open-source standard. Il prend en charge plus de 60 benchmarks académiques hors de la boîte et s’exécute contre n’importe quel modèle servi via llama.cpp, vLLM, ou une API compatible OpenAI :
OpenAI Evals et HELM (Stanford) sont des alternatives avec des bibliothèques de tâches et des formats de rapport différents.

​
Une éval personnalisée simple

Vous n’avez pas besoin d’un framework pour tester la qualité spécifique à un domaine :
  1. Rédigez 50 questions issues de votre cas d’utilisation réel.
  2. Envoyez chaque question au modèle et enregistrez la réponse.
  3. Notez chaque réponse sur une échelle de 1 à 5 (ou pass/fail pour les questions factuelles).
  4. Répétez pour chaque modèle que vous comparez.
50 questions suffisent pour repérer les grandes différences. Utilisez les mêmes questions pour chaque modèle, et notez à l’aveugle (cachez quel modèle a produit quelle réponse) pour éviter les biais.

​
Quand faire confiance aux scores publiés

Faites confiance aux scores de benchmark publiés lorsque :
  • L’éditeur du modèle a un historique de rapports honnêtes (Meta, Google, Mistral, Qwen, Anthropic).
  • Plusieurs sources indépendantes confirment des chiffres similaires.
  • Le benchmark a été publié après la date de coupure d’entraînement du modèle (réduisant le risque de contamination).
Exécutez votre propre éval lorsque :
  • Vous utilisez une quantification tierce et voulez vérifier qu’elle n’a pas dégradé significativement la qualité.
  • Votre tâche est assez étroite pour que les benchmarks généraux ne s’appliquent pas.
  • Vous prenez une décision de production et avez besoin de confiance au-delà d’un chiffre de classement.

​
Drapeaux rouges dans les rapports de benchmarks

Toutes les affirmations de benchmark ne sont pas dignes de confiance. Surveillez ces schémas :
  • Aucune quantification divulguée. « Notre modèle obtient 78 sur MMLU » — à quelle précision ? S’ils ne disent pas, ils pourraient rapporter des scores à pleine précision pour un modèle que la plupart des utilisateurs exécuteront quantifié.
  • Ne rapportant que le meilleur benchmark. Une page de modèle qui met en avant 1 score et omet les autres fait du cherry-picking. Cherchez un tableau de benchmark complet.
  • Comparant des tailles de modèles différentes. « Notre modèle de 7B bat un modèle de 70B sur X » — oui, sur un benchmark étroit qui favorise les données d’entraînement du 7B. Ce n’est pas une comparaison équitable.
  • Benchmarks contaminés sans divulgation. Si les données d’entraînement d’un modèle ont probablement inclus l’ensemble de test du benchmark et que l’éditeur ne l’aborde pas, traitez le score avec scepticisme.
  • « Bat GPT-4 sur… » Presque toujours sur un benchmark étroit et favorable. GPT-4 est un grand modèle propriétaire — le battre sur 1 tâche spécifique ne signifie pas que le modèle est généralement meilleur.
  • Aucune méthodologie décrite. Si le score n’inclut pas de détails comme le nombre de shots, le format du prompt et la méthode de notation, vous ne pouvez pas le comparer à d’autres chiffres publiés.

​
Où trouver les données de benchmark

Croisez au moins 2 sources avant de faire confiance à un chiffre de benchmark. Si l’Open LLM Leaderboard et le propre papier du modèle rapportent des scores différents, enquêtez pourquoi — c’est généralement une différence dans les paramètres d’évaluation (nombre de shots, format du prompt, ou quantification).

​
Aller plus loin

Lire un nom de modèle

Décodez les noms de modèles, les étiquettes de quantification et les suffixes d’architecture avant de regarder les benchmarks.

Lire une fiche modèle

Trouvez les paramètres, l’architecture, la longueur de contexte et la licence que les benchmarks ne couvrent pas.

Quantification

Comprenez comment la quantification affecte les scores de benchmark que vous venez d’apprendre à lire.

Quel modèle local pour quelle tâche ?

Utilisez les insights des benchmarks pour choisir un modèle adapté à votre cas d’utilisation spécifique.