All Things AI
Start Here

Why Benchmarks Lie

Intermediate

Why Benchmarks Lie

AI benchmark leaderboards are cited in every model launch blog post and used to justify product decisions worth millions. Yet practitioners increasingly treat them with scepticism. Understanding the specific ways benchmarks fail - and what to do instead - is essential for making sound model selection decisions.

Training Data Contamination

The most serious failure mode: benchmark questions appear in the model's training data. When a model is evaluated on questions it has "seen" during training, scores measure memorisation, not capability. This is especially problematic for:

  • Benchmarks released years ago (MMLU 2020, HumanEval 2021) - thoroughly contaminated
  • Web-scraped training data that includes academic papers discussing benchmark results
  • Models trained on GitHub - which contains HumanEval solutions in repositories

Concrete example

Multiple papers have demonstrated that models score 15โ€“25% higher on benchmarks whose questions appear in their training data versus genuinely held-out equivalents. GPT-4 scores on HumanEval are likely inflated; no reliable way to verify from outside OpenAI.

Benchmark Saturation

A saturated benchmark has scores clustered near the ceiling. When every frontier model scores 85โ€“92% on MMLU, a 3% difference is not meaningful - it is within the noise of prompt sensitivity. A saturated benchmark provides no signal for choosing between models.

The trajectory of benchmark saturation has accelerated: MMLU took 4 years to saturate (2020โ€“2024); SWE-bench Lite saturated in under 18 months. New, harder benchmarks must be continuously created to stay ahead of model capability.

Goodhart's Law in AI Evaluation

"When a measure becomes a target, it ceases to be a good measure." Models are now explicitly optimised to score well on popular benchmarks during post-training. RLHF and SFT training often use benchmark performance as a signal - meaning models get better at the benchmark specifically, not at the underlying capability the benchmark was designed to measure.

The leaderboard arms race

Benchmarks like Chatbot Arena attempted to solve this by using human votes on anonymous models - harder to game. But even Arena scores can be influenced by deploying a model configured to produce chatbot-pleasing outputs in ways that may not translate to production performance.

Distribution Mismatch

Benchmarks measure performance on their specific task distribution, which may differ substantially from your use case. A model that tops the MATH leaderboard may underperform on your financial modelling tasks because the question format, domain vocabulary, and answer structure differ from competition mathematics.

What benchmarks measure poorly

  • โ€ข Long-running agent tasks with real-world tool calls
  • โ€ข Domain-specific knowledge not in training data
  • โ€ข User preference for tone, style, and length
  • โ€ข Consistency across many calls (variance, not just mean)
  • โ€ข Real-world latency and cost under production load

What benchmarks measure well

  • โ€ข General knowledge coverage at a point in time
  • โ€ข Basic coding ability on standard problems
  • โ€ข Mathematical reasoning in exam format
  • โ€ข Safety behaviours under adversarial prompting

What to Do Instead

The only benchmark that reliably predicts performance on your specific application is one you build yourself.

1. Build a domain eval set

Collect 100โ€“500 representative inputs from your actual use case. Include known correct outputs. This is the ground truth for model selection.

2. Test production-representative prompts

Use the exact prompts your system uses - not simplified versions. Small prompt differences can swing scores 10%+.

3. Use LLM-as-Judge for scoring

For open-ended outputs without exact-match answers, use a strong model as judge with a rubric. Imperfect but scalable; use human annotation for your most critical eval set items.

4. Measure variance, not just mean

A model that scores 80% mean with 5% variance is more reliable than one that scores 83% mean with 20% variance. For production systems, consistency matters.

Red Flags in Benchmark Claims

  • Score reported on only one benchmark - cherry-picked
  • No comparison to previous version of the same model
  • 8-shot evaluation compared to 0-shot competitors
  • Human expert baseline not provided for context
  • Model evaluated only on benchmarks it was fine-tuned on
  • "State of the art" on a saturated benchmark where all models score 90%+