Singularity AI
Saturation, contamination and construct validity — why a leaderboard number tells you less about capability than it appears to.
A benchmark is a proxy. That is not a criticism; it is the entire idea. The trouble begins when the proxy is optimised directly, at which point it stops tracking the thing it was built to approximate. This is Goodhart's law, and machine learning has spent a decade demonstrating it at scale.
Saturation is not achievement
When a benchmark climbs from 60% to 95% in eighteen months, there are at least four explanations: the models genuinely improved, the benchmark leaked into training data, the evaluation protocol drifted, or the remaining 5% is mislabelled and unreachable. These are not exotic possibilities. They are the default hypotheses, and a result is only interesting once they have been ruled out.
Most published comparisons rule out none of them.
Contamination is structural, not accidental
Web-scale training corpora are assembled by crawling. Benchmarks are published on the web. The overlap is not a mistake anyone made; it is the predictable consequence of both practices existing simultaneously. Decontamination pipelines help, but they can only remove what they can detect, and paraphrase survives exact-match filtering comfortably.
The honest position is that for any benchmark published before a model's training cutoff, contamination should be assumed unless specifically excluded.
Construct validity, the part everyone skips
Even a clean, unsaturated benchmark only matters if it measures what its name claims. A "reasoning" benchmark composed of multiple-choice questions measures something — but whether that something is reasoning, or pattern-matching over question formats, is an empirical question that the benchmark itself cannot answer.
The field has good tools for this. Ablations that scramble irrelevant surface features, held-out variants generated after the training cutoff, and adversarial paraphrase all give real signal. They are also more work than reporting a number, which is why they appear less often than they should.
What to do instead
- Prefer evaluations constructed after the model's training cutoff.
- Treat a single aggregate score as a headline, not a finding.
- Look for per-category breakdowns; aggregate scores hide the interesting failures.
- Ask whether the baseline received comparable engineering effort. Usually it did not.
None of this means benchmarks are useless. It means a benchmark result is the beginning of an argument about capability, not the end of one — and it is routinely reported as though the reverse were true.