AI Benchmarks, Explained: What MMLU and Friends Actually Measure
How to read a benchmark table without being fooled by it.
AI benchmarks for language models measure performance on curated test suites, but each score reflects a narrow, constructed view of capability. MMLU tests academic knowledge with multiple choice questions. Arena ranks models by which answers people prefer. HELM reports several qualities side by side. SWE-bench checks whether a model can fix real bugs in real code. Reading any benchmark number well means understanding how prompts, scoring rules, and contamination shape it.
A five point gain on MMLU can vanish if you change the prompt template by a few words. Yet leaderboards still treat that difference as a meaningful improvement. This article shows how the underlying machinery works, so you can read benchmark tables without being fooled by them.
Why benchmark scores are like exam grades, not IQ tests
Think of a benchmark as a specific exam that a student takes. A high grade means the student did well on that particular set of questions, using that particular grading scheme. It does not mean the student is generally smart, creative, or capable in all domains. One exam might reward memorization. Another might reward clever problem solving under time pressure. Two students with the same grade on different exams may have entirely different strengths.
Benchmark scores work the same way. MMLU is a multiple choice exam spanning 57 subjects. A model scoring 87% did not "know" 87% of all human knowledge. It performed well on those 57 subjects, using that question format, under a specific prompt template, with no real world interaction. Swap the exam for Arena, and the same model gets a rating that depends entirely on which other models were in the pool and which users wrote the prompts. Neither number is a complete picture.
The rest of this article unpacks how the most cited benchmarks actually work, where they mislead, and how to read scores the way people who build evaluations do.
How does MMLU actually decide which answer is "correct"?
MMLU comes from the 2020 paper Measuring Massive Multitask Language Understanding: about 15,900 questions across 57 subjects, each with four options. The original way to score it looks at probabilities rather than at a written answer. The evaluator builds a prompt that ends with the question, the four options and the cue "Answer:". Then it asks the model how likely each letter, A, B, C or D, is as the very next token, and the most likely letter counts as the model's answer. (Under the hood, the model gives every possible next token a raw score, called a logit, and turns those scores into probabilities.) Nothing is sampled, so the result is the same on every run.
Here is a made-up example. The question asks which planet is the largest: A) Mars, B) Jupiter, C) Earth, D) Venus. After "Answer:", the model's probabilities for the next token might be A 0.12, B 0.61, C 0.20 and D 0.07. B has the highest probability, so B counts as the model's answer, and it is right. The model never wrote a sentence; the evaluator only compared four numbers.
For the curiousthe scoring rule in symbols.
In words: for a question , take the probability the model gives to each option letter , and pick the option with the largest one.
The prompt often begins with a few solved example questions, called few-shot examples; the original MMLU setup used five. And this is only one way to score. Many labs instead let the model write out its reasoning and then read off the letter it chose, which can give a different score. Even small differences in how the probability method is implemented matter. When Hugging Face compared three implementations of MMLU in 2023 (the original, the one in Stanford's HELM, and the one then in EleutherAI's lm-evaluation-harness), LLaMA 65B scored 0.637, 0.636 and 0.488, and the differences were big enough to change the ranking order of models (What's going on with the Open LLM Leaderboard?). That is why the first thing any reproduction effort should check is exactly how a number was produced: the prompt, the examples, and the scoring method.
Why do small prompt changes nudge MMLU scores by 4-5%?
A model's probabilities for A, B, C and D depend on the surrounding words, not only on what it knows. The model is not just retrieving knowledge. It is also judging how likely each continuation seems given the style of the prompt, so a different wording can flip a few answers.
The MMLU-Pro paper measured this. Across 24 prompt styles, scores on the original MMLU moved by about 4 to 5 percent, and by almost 11 in the worst case. MMLU-Pro, which gives every question ten options and removes noisy items from MMLU, brought that down to about 2 percent. If you see two models with a 3-point gap on MMLU-Pro, you can be more confident it reflects a real difference. The same gap on original MMLU could easily be a prompt artifact.
MMLU-Pro is also much harder. With ten options, random guessing yields 10% accuracy instead of 25%, and the paper reports accuracy falling by 16% to 33% compared with MMLU. It also found that letting models reason step by step helped on MMLU-Pro, unlike on the original MMLU, a sign that its questions need more reasoning and less recall.
When comparing models, always check which benchmark variant is being reported and whether prompt-sensitivity numbers are disclosed. A difference that looks significant may be invisible once you switch to MMLU-Pro or even a slightly different template.
What does an Arena score actually represent?
Arena ranks models from pairwise human votes. It began as Chatbot Arena (Chatbot Arena: An Open Platform for Evaluating LLMs by Human Preference), was renamed LMArena, and since January 2026 is simply Arena, at arena.ai (LMArena is now Arena). A user sees two anonymous answers to their own prompt and picks the one they prefer. Early ratings were updated after every vote with the Elo system used in chess. Since January 2024 the leaderboard has fitted all the votes together with a Bradley-Terry model, a close statistical cousin of Elo that does not depend on the order in which votes arrive (Chatbot Arena: New models & Elo system update). Many announcements still call the result an Elo score.
A rating of 1300 does not mean "the model is 1300 good at coding." It means that, within the pool of models being compared and under the prompts Arena users happen to submit, this model wins more pairwise comparisons than models with lower ratings. Because all the ratings are fitted together, a score means something only relative to the other models on the same leaderboard snapshot: compare the gaps between models, not absolute numbers across months.
Style, tone, length, and refusal behavior strongly influence votes. A model can rank high because it writes friendly, well-formatted responses, not because it answers facts correctly. In 2024 the Arena team added style control, which estimates how much length and formatting sway votes and adjusts for them (Does style matter? Disentangling style and substance in Chatbot Arena), and in May 2025 it became the default for the text and vision leaderboards (leaderboard dataset notes). Even so, nobody checks the answers against a ground truth. That makes Arena a useful measure of user experience but a poor measure of factual accuracy or task-specific capability.
How does contamination inflate benchmark scores?
Contamination happens when test questions appear in the model's training data. If a model has memorized MMLU answers, it can repeat the correct option without reasoning. This produces scores that look like real understanding but crumble when questions are rephrased or when a contamination-free variant is used.
MMLU-CF, from Microsoft researchers, tackles this with new questions drawn from a broader range of sources, three decontamination rules (rephrase each question, shuffle its options, and replace one option with "None of the other choices"), and a closed test set. Its 10,000 test questions are never published, while a public validation set of similar difficulty lets anyone check their setup. To get a test score, you run the validation set yourself and then ask the authors, through a GitHub issue, to run your model on the hidden test set (MMLU-CF repository). The gap is clear: GPT-4o scored 73.4% on the MMLU-CF test set with five examples, against 88.0% on MMLU, and the paper notes that some models answered with choices identical to the original MMLU ones, a sign of memorization (MMLU-CF: A Contamination-free Multi-task Language Understanding Benchmark).
If you need a trustworthy knowledge score, look for benchmarks that explicitly describe decontamination steps and keep test data private. Alternatively, run your own evaluation on a privately held set of questions that you know never appeared in public training data. Trusting a published MMLU score without contamination analysis is gambling that the model never saw the test set.
Why does HELM report seven metrics instead of one number?
HELM, the Holistic Evaluation of Language Models from Stanford's Center for Research on Foundation Models, runs models through dozens of scenarios and reports seven metrics: accuracy; calibration (whether a model that says it is 80% sure is right about 80% of the time); how well results hold up when the input is slightly changed, for example with typos; fairness; bias; toxicity; and efficiency (Holistic Evaluation of Language Models). A single accuracy number can hide that a model answers correctly most of the time but produces toxic output on some prompts, or that its stated confidence is useless.
HELM's per-scenario tables and leaderboards show these trade-offs explicitly. A model might have higher accuracy than another but worse fairness. A human reading the full report can decide which trade-offs matter for their use case. If you only look at the top row of a leaderboard, you miss risks that will matter in production. One thing to know as of October 2026: the project's GitHub page says HELM entered maintenance mode on June 1, 2026.
For a team deploying a model in a customer facing product, this multi-metric approach is far more actionable than a single MMLU number. The cost is complexity. You need to set aside time to read the scenario-by-scenario breakdowns and decide which dimensions are constraints and which are nice-to-have.
What does SWE-bench actually test that snippet benchmarks miss?
Classic code benchmarks test one small function at a time. HumanEval, the best known, has 164 hand-written problems: the model gets a function signature and a docstring (a short description of what the function should do) and writes the body, which is then run against a handful of unit tests (Evaluating Large Language Models Trained on Code). Its metric, pass@k, is the chance that at least one of k generated attempts passes all the tests. These benchmarks check small, self-contained functions.
SWE-bench: Can Language Models Resolve Real-World GitHub Issues? goes much further. It has 2,294 tasks taken from real GitHub issues in 12 popular Python projects. The model gets the whole codebase and the issue text and must produce a patch. The patch is judged by tests taken from the real fix, which the model never sees, plus the project's existing tests, which must keep passing. Scores are reported as the percentage of issues resolved, with one attempt per task. Many headline numbers use SWE-bench Verified, a 500-task subset whose tasks human engineers checked for quality (SWE-bench Verified dataset card). This is end-to-end software engineering: the model must find its way around a real project, follow its conventions, and make changes that pass tests across multiple files.
- Function signature and docstring
- Small unit tests on one function
- Tests self-contained coding
- Full repository and issue description
- Patch must pass the real fix's hidden tests and the existing ones
- Tests engineering in a real codebase
SWE-bench is harder and more expensive to run than snippet benchmarks, because every task needs the project's own environment to run its tests. When you see a SWE-bench score, always check which version of the benchmark was used (the full set, the Verified subset, or a newer variant) and whether the evaluation harness was reproduced faithfully.
What do frontier model announcements cite in 2026?
MMLU no longer separates the best models. The authors of Humanity's Last Exam point out that leading models now score above 90% on it (Humanity's Last Exam), so a one-point gap between two frontier models says almost nothing. Launch posts have moved to harder tests:
- GPQA Diamond is a 198-question subset of GPQA: A Graduate-Level Google-Proof Q&A Benchmark, whose main set has 448 graduate-level multiple choice questions in biology, physics, and chemistry; Diamond keeps the questions that expert validators answered correctly and most non-experts got wrong. In the paper, experts with or pursuing PhDs in the field scored 65%, while skilled non-experts scored only 34% despite spending over 30 minutes per question with full web access. That is what "Google-proof" means.
- Humanity's Last Exam has 2,500 questions at the frontier of human knowledge, written by subject experts and organized by the Center for AI Safety and Scale AI, each with one clear answer that cannot be found by a quick search.
- SWE-bench Verified and agent benchmarks, such as Terminal-Bench (tasks in a real command line) and OSWorld (operating a computer), test whether a model can get work done rather than pick a letter.
Google's Gemini 3 announcement (November 2025) leaned on Humanity's Last Exam, GPQA Diamond, ARC-AGI-2, SWE-bench Verified and Terminal-Bench 2.0. Anthropic's Claude Opus 5.5 announcement (September 2026) leads with agentic tests such as Terminal-Bench 4.0 and OSWorld, plus Humanity's Last Exam. Neither mentions MMLU. Expect these names to keep changing: once the top models max out a benchmark, launch posts move on to a harder one.
Quick Reference
| Benchmark | Measures | Metric | Watch out for |
|---|---|---|---|
| MMLU | Academic multitask knowledge | Accuracy (most likely option letter, or the letter a model writes) | Prompt sensitivity, contamination, saturation above 90% |
| MMLU-Pro | Harder, reasoning-heavy multitask with 10 options | Accuracy | Open test set, so still exposed to contamination |
| MMLU-CF | Multitask knowledge with strict decontamination | Accuracy on a closed test set | The authors must run the test, which limits independent reproduction |
| Arena | Human pairwise preference | Arena score (Bradley-Terry fit, often called Elo) | Relative to the model pool; style sways votes, even with style control |
| HELM | Many scenarios, seven qualities | Per-scenario tables and leaderboards | Reading one sub-metric alone; in maintenance mode since June 2026 |
| HumanEval | One small function at a time | pass@k (unit tests) | Tests only small, self-contained functions |
| SWE-bench (Verified) | Fixing real GitHub issues | % of issues resolved, one attempt | Environment setup cost; check which version was used |
| GPQA Diamond | Graduate-level science that resists web search | Accuracy | Only 198 questions, so small gaps are noise |
| Humanity's Last Exam | Expert questions across dozens of subjects | Accuracy | Scores with and without tools are not comparable |
Frequently Asked Questions
Q: Why does my local MMLU evaluation differ from the published numbers? Even small differences in prompt template, few-shot examples, or scoring method shift scores by several percent, and different implementations can even reorder models. To get comparable numbers, use exactly the same evaluation harness, version, and template as the published result. Otherwise, treat your numbers as a separate measurement.
Q: How can I tell if a model's benchmark score is inflated by contamination? Check whether the model reproduces the original answer options verbatim when prompted with only the question stem. Then test it on a contamination-free variant like MMLU-CF or on paraphrased versions of the questions. A sharp drop on those variants is a strong signal of memorization, not generalization.
Q: Is an Arena score the best measure of human preference? It is a reasonable crowd-sourced signal of what a broad set of users prefer, adjusted for style by default since May 2025. It is not absolute and does not guarantee task utility. For applications where factual correctness or safety is critical, complement it with task-specific accuracy benchmarks.
Q: Why do some benchmarks report accuracy, some pass@k, and some % resolved? Accuracy is natural for multiple choice, where one answer is right. pass@k comes from code benchmarks like HumanEval, where a model can generate several attempts and the question is whether any of them passes the tests. SWE-bench reports the share of issues resolved, usually with one attempt per task, which is closer to how a developer's work is judged.
Q: When should I choose HELM over a single benchmark like MMLU? Use HELM's multi-metric view when you need to weigh correctness, calibration, fairness, and toxicity together, and you can invest time interpreting full scenario reports. For quick sanity checks, or when only knowledge accuracy matters, a single benchmark suffices but may hide risks that surface later.
Test yourself
You are choosing between two models. Model X beats Model Y by 3 points on MMLU, but loses to it by 2 points on MMLU-Pro and by 2 points on SWE-bench Verified. Which result do you trust more, and what would you do before deciding?
Answer: Trust the MMLU-Pro and SWE-bench Verified results more. MMLU is saturated near the top, its scores swing by about 4 to 5 percent with prompt wording alone, and its public questions may have leaked into training data, so a 3-point MMLU lead is within the noise. MMLU-Pro is harder and far less sensitive to prompts (about 2 percent), and SWE-bench Verified measures something different: fixing real code, judged by tests. Two harder, independent measures pointing the same way beat one noisy one. Still, 2 points is a small gap, so before deciding, check how each number was produced (prompt, reasoning or not, number of attempts, harness version), look for error bars, and best of all run both models on a sample of your own real tasks. Lean towards Model Y for now.
If you want this kind of breakdown every week, how real systems actually work under the hood, subscribe to Internals Decoded at internalsdecoded.com.
Sources
- Measuring Massive Multitask Language Understanding (Hendrycks et al. 2020)
- MMLU-Pro: A More Robust and Challenging Multi-Task Language Understanding Benchmark (Wang et al. 2024)
- MMLU-CF: A Contamination-free Multi-task Language Understanding Benchmark (Microsoft, 2024)
- MMLU-CF repository (Microsoft)
- What's going on with the Open LLM Leaderboard? (Hugging Face, June 2023)
- EleutherAI lm-evaluation-harness
- Chatbot Arena: An Open Platform for Evaluating LLMs by Human Preference (Chiang et al. 2024)
- Chatbot Arena: New models & Elo system update (LMSYS, December 2023)
- Does style matter? Disentangling style and substance in Chatbot Arena (LMSYS, August 2024)
- Arena leaderboard dataset notes (Hugging Face)
- LMArena is now Arena (Arena, January 2026)
- Holistic Evaluation of Language Models (Liang et al. 2022)
- HELM on GitHub (Stanford CRFM)
- Evaluating Large Language Models Trained on Code (Chen et al. 2021), the HumanEval paper
- SWE-bench: Can Language Models Resolve Real-World GitHub Issues? (Jimenez et al. 2023)
- SWE-bench Verified dataset card
- GPQA: A Graduate-Level Google-Proof Q&A Benchmark (Rein et al. 2023)
- Humanity's Last Exam (Center for AI Safety and Scale AI, 2025)
- A new era of intelligence with Gemini 3 (Google, November 2025)
- Introducing Claude Opus 5.5 (Anthropic, September 2026)
