What AI benchmarks actually measure

Every new model launch comes with a table of numbers: MMLU, GPQA, SWE-bench and a rank on a public preference leaderboard. The numbers look precise, and they usually go up.

Read carefully, they say something narrower. Each score records how a particular system, set up a particular way, performed on a fixed set of questions or tasks, graded by a particular rule. That is useful evidence. It is not a verdict on whether the model will handle your contracts, codebase or customer emails.

Here is what the widely cited benchmarks test, what weakens them, how to read a leaderboard and how to build a small evaluation of your own.

A benchmark is a test set plus a grading rule

Strip away the branding and most benchmarks have the same parts: a set of items, a way of presenting them to the model, and a rule that turns each answer into a score. Change any part and the number can change.

That makes a benchmark more like an exam than a measure of general ability: it tells you how a student did on that paper, under those conditions. The useful habit is to ask, for any number: which items, graded how, under what setup, reported by whom?

If you need a refresher on what the model underneath is doing, our large language model explainer covers training, inference and why fluent output is not the same as a correct one.

What the common benchmarks actually test

Each benchmark below was designed to answer a specific question, and each answer has limits.

MMLU: broad academic knowledge, multiple choice

MMLU (Measuring Massive Multitask Language Understanding) was introduced in 2020 as a test of "multitask accuracy" across 57 subjects, including elementary mathematics, US history, computer science and law.[1] Questions are multiple choice with four options.[2] A high score shows the model can pick the right option across many academic topics. It does not show the model can write a usable memo on any of them.

GPQA: hard science questions that resist searching

GPQA is a set of 448 multiple-choice questions in biology, physics and chemistry, written by domain experts.[3] Its authors report that experts with or pursuing PhDs reached 65% accuracy, while skilled non-experts reached 34% despite spending, on average, more than 30 minutes with unrestricted web access. That is why the authors call the questions "Google-proof". GPQA tests difficult, specialised reasoning in three sciences. A strong result says little about writing, coding or everyday instructions.

Humanity's Last Exam: a harder closed-ended exam

Humanity's Last Exam (HLE) was created because older tests stopped separating the best models. Its paper notes that models already exceed 90% accuracy on popular benchmarks like MMLU.[4] HLE contains 2,500 multiple-choice and short-answer questions across dozens of subjects, each with a known answer that can be graded automatically and that "cannot be quickly answered via internet retrieval." It also reports calibration: whether a model's stated confidence matches how often it is right. It remains a test of closed-ended academic questions, not of open-ended work.

HumanEval: does the generated function pass its tests?

HumanEval, released with OpenAI's 2021 Codex paper, measures "functional correctness for synthesizing programs from docstrings": the model writes a Python function from a description, and unit tests decide whether it works.[5] The paper also shows why setup matters. The Codex model solved 28.8% of problems with a single attempt, but 70.2% when 100 samples were generated per problem. "Pass" can mean very different things depending on how many tries are counted.

SWE-bench: fixing real issues in real repositories

SWE-bench moves from single functions to software maintenance. It contains 2,294 problems drawn from real GitHub issues and the pull requests that fixed them, across 12 popular Python repositories.[6] The system receives the codebase and the issue text and must edit the code so the repository's tests pass. In the original paper, the best model resolved 1.96% of issues.

OpenAI later worked with the SWE-bench authors to screen the test set. Its annotators found that many samples had underspecified issue descriptions or unit tests that could reject valid solutions; 68.3% of the samples they reviewed were filtered out. The remaining 500 became SWE-bench Verified.[7] On 23 February 2026, OpenAI said it had stopped reporting SWE-bench Verified scores, citing flawed tests that reject correct solutions and contamination from training data, and recommended SWE-bench Pro instead.[8] The 2024 post notes that scaffolding, the agent software wrapped around a model, can swing results widely: one model's score on a subset ranged from 2.7% to 28.3% depending on the scaffold. A SWE-bench number describes a model and its harness. Our coding assistants shortlist explains why the harness matters when choosing a tool.

Arena-style preference leaderboards: which answer did people prefer?

Chatbot Arena, now run as Arena (previously known as LMArena), takes a different approach. A user enters a prompt, sees answers from two anonymous models, and votes for the one they prefer. Model names are revealed only after the vote.[9] The original paper describes the pairwise, crowdsourced method and reports that crowd votes agreed well with expert raters.[10] Votes are converted into a ranking with a statistical model, known as Bradley–Terry, that estimates each model's strength from its wins and losses.[11]

This measures what users prefer on the prompts they type, which is not the same as correctness. Arena's own analysis found that controlling for response length and markdown formatting changed the rankings, with length the dominant style factor.[11] As the team put it, "it's not just what you say, but how you say it."

Why scores drift away from reality

Three problems recur in the research. None makes benchmarks useless; each means a score needs context.

Contamination: the test leaked into the training data

Most benchmarks are published online, and models are trained on large amounts of online text. If test items, or close copies, end up in training data, a model can score well by recognition rather than reasoning.

The GSM1k study tested this for grade-school maths. Its authors wrote 1,000 new problems matching the style and difficulty of the widely used GSM8k benchmark, then compared results. Some models dropped by up to 8%, with several model families showing signs of systematic overfitting; many frontier models showed minimal signs of it.[12] OpenAI makes a similar point about SWE-bench: because its tasks come from public GitHub repositories, large models trained on internet text are "likely to be contaminated."[7]

Saturation: everyone is near the ceiling

When the leading models all score in the high 80s or 90s, differences of a point or two say more about noise and formatting than capability. The MMLU-Pro authors describe performance on MMLU as having "begun to plateau," and report that scores on the original test shifted by 4–5% across prompt styles.[2] A gap smaller than the prompt sensitivity is not a meaningful gap.

Benchmarks also contain mistakes. One re-annotation study estimated that 6.49% of MMLU questions contain errors, and found errors in 57% of the questions it analysed in the virology subset.[13] Near the ceiling, a model can lose points for disagreeing with a wrong answer key.

Leaderboard dynamics: who tested what, and how often

Public leaderboards have their own distortions. The Leaderboard Illusion, a 2025 analysis of Chatbot Arena, reported that some providers privately tested multiple model variants before release and could choose which scores to publish, including 27 private variants tested by Meta ahead of a Llama 4 release.[14] It also estimated that a few large providers received far more voting data than open-weight models. Arena's policies may have changed since.

"Language models have outpaced our ability to evaluate them effectively."

— Jimenez and colleagues, SWE-bench: Can Language Models Resolve Real-World GitHub Issues? (2023).[6]

The gap between a benchmark and your task

Even a clean, honestly reported score answers a question you may not be asking. Four gaps matter.

Different inputs. Benchmarks use clean, self-contained items. Your work arrives as messy emails and documents with missing context.

Different grading. Multiple-choice tests reward picking the right option. Your task may reward following a house format, refusing to guess, or citing the right clause.

Different setup. Published scores often depend on specific prompts, tools, scaffolds and numbers of attempts. The HumanEval and SWE-bench examples above show how much those choices move results. The product you use may be configured differently, and may run a reasoning mode the benchmark did or did not use.

Different failure costs. A benchmark counts every wrong answer the same. In your workflow, a confidently wrong figure in a client report costs far more than a clumsy sentence. Our hallucinations explainer covers why plausible errors are the expensive kind.

"Evaluations based on static datasets are inherently limited, and SWE-bench is no exception."

— OpenAI, Introducing SWE-bench Verified (2024, updated 2025).[7]

AI Chronicle

How to read a leaderboard

Leaderboards compress all of this into one ranked column. Five questions recover what was lost.

1. What does this benchmark test? Match it to your task. A science-exam score says little about drafting support replies.
2. How is it graded? Exact answers, unit tests, human votes or another model acting as judge each reward different behaviour.
3. What was the setup? Look for the prompt format, number of attempts, tools or scaffold, and whether a reasoning mode was used. If the source does not say, treat the number as less comparable.
4. Who ran it, and on which version? A developer's own launch figures, an independent leaderboard and a third-party reproduction are different kinds of evidence. Record the exact model identifier and date.
5. Is the difference meaningful? Small gaps near the top of a saturated test, or within a leaderboard's stated confidence interval, may not reflect a real difference.

It also helps to look across several benchmarks. Stanford's HELM project measured seven metrics, including accuracy, calibration, robustness and efficiency, across shared scenarios. Before HELM, the models it studied had on average been evaluated on just 17.9% of its core scenarios, which made like-for-like comparison difficult.[15] When you see a new launch table, our guide to judging a new AI model release turns these questions into a checklist.

How to run a small, task-specific evaluation

The most reliable way to choose a model for your work is to test it on your work. Anthropic's evaluation guidance gives a useful starting frame: define success criteria that are specific and measurable, design tests that "mirror your real-world task distribution," include edge cases, and automate grading where possible.[16]

1. Write down what "good" means. One sentence per criterion, phrased so two people would agree on a verdict. "Classifies the request into the correct category" is checkable; "gives helpful answers" is not.

2. Collect real cases. Pull 20 to 50 examples from your own work, with sensitive details removed. Include the awkward ones: missing information, ambiguous wording, requests that should be refused or escalated.

3. Fix the expected outcome before you run anything. For each case, record the correct label, the required facts or the boundary the answer must respect. Deciding afterwards invites grading the answer you like.

4. Choose the simplest grader that works. Anthropic's guide ranks code-based checks such as exact or string matching as the fastest and most reliable, human grading as the most flexible but slow, and model-based grading as scalable once you have tested that it is reliable.[16] Its example code also notes it is generally better to use a different model as the grader than the one being tested.

5. Hold the setup constant. Use the same prompt, settings and tools for every system you compare. Record the model identifier, product plan and date.

6. Run more than once, and read the failures. Generation can vary between runs, so repeat cases where consistency matters. Then read every wrong answer: one invented figure may matter more than five awkward phrasings.

Keep the case set private and reuse it when a new model arrives. A test only you have seen is the best protection against contamination.

A worked example (hypothetical): sorting refund emails

This scenario is invented to illustrate the method. No model was tested and no results are reported.

Suppose a small online retailer wants a model to sort customer emails into four queues: refund request, delivery problem, product question and other. Two candidate models both post strong benchmark numbers. Neither number says anything about this inbox.

The team writes one success criterion: the email lands in the correct queue, and any email mentioning a chargeback or legal action is flagged for a person, whatever its category. They collect 40 past emails with personal details removed, including six awkward cases: an email that asks two questions, one written in a mix of English and Urdu, a sarcastic complaint, and three that mention a chargeback.

Before running anything, a team member labels each email with its correct queue and flag. A short script checks each label exactly, plus a separate check that all three chargeback emails were flagged. Each model gets the same prompt and three runs per email.

Reading the results means looking past headline accuracy. A model that sorts slightly more emails correctly but misses a chargeback flag fails the criterion that matters most. A one- or two-email difference out of 40 cannot settle the choice alone, so the team would add cases or weigh cost and speed. A benchmark table cannot make that decision for them.

Questions readers commonly ask

Are AI benchmarks useless?

No. They are good at comparing systems on a fixed task under stated conditions and tracking progress over time. They mislead when one number is read as a general verdict.

What is benchmark contamination?

It is when benchmark questions, or close variants, appear in a model's training data, so the model can score well by recognition. Studies such as GSM1k estimate its effect by comparing scores on a public test with scores on freshly written, matched questions.[12]

Is a preference leaderboard like Arena more trustworthy than a test score?

It measures something different: which answers users preferred on their own prompts. Votes can be swayed by length and formatting, and leaderboard policies affect results.[11][14] Use it alongside task tests, not instead of them.

Why do benchmark scores differ between sources for the same model?

Prompts, attempts, tools, scaffolds and model versions all move results; HumanEval and SWE-bench show large swings from setup alone.[5][7] Compare figures only when the setup is disclosed and matched.

How many test cases do I need for my own evaluation?

Enough to cover your common cases and costly failures; 20 to 50 is a practical start for one task. Add more when two systems are close, because small samples cannot separate small differences.

The next step

You now have four questions for any score: which items, graded how, under what setup, reported by whom? Put them to work on the next launch table you see with our guide to judging a new AI model release.

Sources and evidence note

This explainer relies on the original benchmark papers, official benchmark and leaderboard pages, peer-reviewed or preprint critiques, and one vendor's evaluation documentation. Scores quoted from papers describe the models and setups available when each paper was written; they are not current rankings. The refund-email scenario, its criteria and its case counts are illustrative. No hands-on model test was run for this article. All sources accessed 15 October 2026.

Related reading

• Open vs. closed AI models: what the difference means
• Claude vs. ChatGPT vs. Gemini: choosing an assistant