How to measure a model honestly. What a benchmark actually measures, how much its number would move on a redraw, whether the model has seen the test, how far to trust a judge, how to score an agent that acts, how to build the evals that decide what you ship, and how millions of human votes become a leaderboard, all derived and coded from scratch.
Chapter 22 · Section 22.1 · 90 min
Why evaluation is hard
This chapter is about measuring a model honestly. The book so far has built models, trained them, aligned them, and made them fast, and every step was judged by a number. Fine-tuned models were scored on held-out tasks with error bars (§14.7), reasoning models by pass@k (§18.2), and safety by refusal and attack rates (§19.4). Those numbers now decide what labs train and ship, and they fail in ways no amount of compute fixes. The chapter treats an evaluation as a measurement with its own errors. It builds the statistics, the leak detectors, the model judges, the agent harnesses, and the human arenas that keep the measurement honest, using the confidence intervals and paired tests of §0.11, recapped where they are needed.
This section is about why a benchmark score can be wrong, and how to tell the kinds of error apart. A benchmark is a fixed set of test questions, called items, with a rule for grading the answers. Its score is usually the share of items a model gets right. Labs pick checkpoints, ship models, and decide which ideas to scale on gaps of a point or two in such scores, so knowing what a score can and cannot tell you is part of the job.
The one idea to carry away is an asymmetry. More test items shrink only the random noise in a score. Every other kind of error is a bias, and a bias survives any number of items.
Two measurements from the last two years show the problem. The first is a leaderboard, a public ranking of models by their scores on one benchmark. GPQA Diamond is a set of 198 graduate-level multiple-choice science questions with four options each. In October 2026 its top five looked like this, in independent runs by Epoch AI (2026).
model
GPQA Diamond accuracy
Gemini 4 Argon (high)
96.4%
GPT-6 Astra (max)
95.8%
Claude Sonnet 5.5 (max)
95.6%
GPT-6.1 Sol (max)
95.4%
Gemini 3.8 Flash (high)
95.4%
The five models are 1.0 point apart, and on 198 questions one point is about two questions. Which one is best at graduate-level science? By the end of this section you will be able to show that the benchmark cannot say.
The second is a randomized trial. In the first half of 2025 the research group METR had 16 experienced open-source developers work on 246 real tasks in large repositories they knew well (Becker et al. 2025). Each task was randomly assigned to allow or forbid AI tools. Before starting, the developers forecast that AI would cut their time per task by 24%. Afterward they believed it had cut it by 20%. Measured, tasks with AI took 19% longer.
Over the same months, scores on SWE-bench Verified rose steeply. That benchmark has 500 real GitHub issues, and a fix counts as correct when hidden unit tests pass. In Epoch AI's runs, which use 484 of the issues, GPT-4o (November 2024) solved 31.0%, Claude 3.7 Sonnet (February 2025) 61.0%, and Claude Opus 4 (May 2025) 70.7%.
Both stories are failures of measurement, of different kinds. In the first, a number is too noisy, and too close to the best score the test allows, to rank the models. In the second, a number rose fast and did not track the thing people cared about. This section answers five questions, in order. What does an evaluation estimate, and how does its error split into parts? What does it mean for a benchmark to measure the right thing? How much does reporting the best of many tries inflate a score, and how far can an adversary push a public leaderboard? Why do benchmarks stop improving below 100%? And how large is the measured gap between benchmark scores and real work?
Five ways a score can be wrong
A thermometer reads a temperature. A thermostat reads it and then acts to change it. Benchmarks are built to be read like thermometers and are used like thermostats. Labs choose training mixtures, checkpoints, and prompts by what raises the number. Researchers decide which ideas deserve attention by it, and buyers choose models by it. Each of those uses pushes on the number, and a number that is pushed on drifts away from the thing it was built to read.
This drift is Goodhart's law, named for the economist Charles Goodhart. In the short form of the anthropologist Marilyn Strathern, when a measure becomes a target, it stops being a good measure (Strathern 1997). §16.5 met it as reward hacking, where a policy trained against a learned reward model found answers that the reward model scored highly and humans disliked. On a public benchmark the optimizer is a whole research community, and the reward model is the test set.
The pressure acts through five ways a reported score can be wrong. To see all five at once, picture a 20-question quiz meant to tell whether a new hire can do a job. The quiz covers a syllabus that is not quite the job. Three of its questions leaked from last year's exam. A teacher who likes long answers grades it. And it is taken on a calculator that sometimes freezes. In the table, n is the number of items in a benchmark and K is the number of answers sampled from the model on each item.
error term
in the quiz
in a language model evaluation
where the chapter treats it
validity
the syllabus is not the job
the benchmark's items, grading, or protocol differ from real use
Only one row, sampling, shrinks when you add questions. A 2,000-question quiz on the wrong syllabus, graded by the same teacher, still measures the wrong thing. It measures it more precisely, and that is all. The next part makes this exact.
An evaluation is an estimator
An estimator is a rule that turns random data into a guess at a fixed unknown number. The fraction of heads in 100 coin flips is an estimator of the coin's chance of heads. An evaluation is the same kind of object. The unknown number is how good the model is at the job you care about. The data are the model's answers to a sample of test items, scored by a grader.
Here is a tiny case with numbers. A model will answer customer-support tickets, and on real tickets it gives a good answer 60% of the time. You cannot measure that directly, so you run a benchmark of 10 FAQ-style questions, and the grader marks 8 of them right. The estimate is 0.8 and the target is 0.6. Part of the 20-point gap is luck, since 10 questions is very few. Part of it is that FAQ questions are easier than real tickets. Only the first part would shrink if you asked 1,000 FAQ questions instead of 10.
To make that split precise we need names for the pieces. The protocol is everything between an item and its score. That means the prompt template and any example answers shown in it, the decoding settings, any tools or agent scaffold, the rule that extracts the answer, and the rule that averages the scores. The grader is whatever scores a response, such as exact match against an answer key, unit tests, a model judge, or a human.
In plain words, the number you want is how good the model is where it will be used, judged by what quality really means. The number you compute is an average of a grader's verdicts on a sample of benchmark items. Every way a benchmark result misleads is a way these two numbers differ.
To split the difference we need one number in between. Let μbench=Ex∼DbenchEy[g⋆(x,y)] be the true quality on fresh benchmark items the model has never seen, with the protocol run exactly as intended and graded by true quality. In the support example it is the model's real success rate on FAQ questions, whatever the grader says. Write E[μ^] for the average of the estimate over everything random in it. That covers the draw of items, the sampled responses, and any randomness in the grader and the environment.
Why it holds. The first identity is exact, because the middle terms cancel when you add the three brackets. For the mean squared error, write b=bval+bmeas, a constant, and e=μ^−E[μ^], which has mean zero. Then E[(b+e)2]=b2+2bE[e]+E[e2]=b2+Var(μ^).
The variance formula comes from §14.7, which derived the variance of an average over items and samples. Each item i has its own true pass ratepi, the chance that one sampled answer to it passes. The between-item varianceσb2 is how much the pi differ from item to item. The within-item varianceσw2 is the average spread of one graded sample around its own item's pass rate. For a pass or fail grade it is the average of pi(1−pi). More samples per item shrink only the second term, while more items shrink both. The square root of Var(μ^) is the standard error, the typical distance between the score and its own average over redraws (§0.11).
In plain words, the squared error of a reported score is a squared bias, which no amount of data removes, plus a variance that falls like 1/n. Setting the two equal gives the crossover size,
n∗=b2σb2+σw2/K.
Past n∗ items the bias is most of the error, and more items buy almost nothing. Jacobs and Wallach (2021) make the same split in the language of measurement theory, where reliability roughly means low variance and validity roughly means low bias.
A small simulation shows all five terms at once. A model handles three kinds of request, lookups, coding, and long analyses, with true pass rates 0.9, 0.7, and 0.4. Users mostly ask for long analyses. The benchmark was built from what was easy to collect, which is mostly lookups. On top of that, 15% of the items leaked into training, the grader passes 20% of wrong answers, and 3% of runs crash and score zero.
Python · cell 1
Two lessons follow. A bigger benchmark makes a wrong number more precise, not more right. And biases can cancel, so a score that passes a sanity check can still be wrong in three ways at once. In an interview, when someone proposes more eval data as the fix for a misleading number, the right first question is which term dominates the error.
The widget uses the model of the worked example, with p=0.7 and one sample per item. Drag the end of each bias bar to set that bias in points, and grow the benchmark with the slider or with Play. The plot below the bars shows the sampling error falling with n against the flat dashed line of the total bias.
Which error dominates a reported number?
Drag a bias bar to set it in points. Then grow the benchmark and see which errors shrink.
Loading interactive figure…
What construct validity asks
Every benchmark has a name, and the name makes a claim. GPQA claims to test graduate-level scientific reasoning, and HumanEval, a set of 164 short Python function problems with unit tests, claims to test coding. Whether the scores back the name is the question of validity. It is the hardest of the five terms to measure, because it compares the benchmark with real use, which you cannot sample directly.
Psychology and education faced this problem a century before machine learning. They measure constructs, properties you cannot observe directly, such as reading ability or anxiety. They do it through an operationalization, a concrete procedure you can run, such as a reading test. A bathroom scale is a good operationalization of weight and a poor one of fitness. The same reading supports one claim and not the other. The theory of when a measurement can be trusted is called measurement theory, and Jacobs and Wallach (2021) brought it to computer scientists.
In plain words, the question is never "is this benchmark valid?" but "does this score justify this particular claim?". The same 198 questions can support "the model answers these multiple-choice science questions well" and fail to support "the model reasons like a PhD scientist".
The field's most famous benchmarks have been read as more than they are. ImageNet and GLUE were treated as measures of general visual and general language understanding, while each is a particular collection of items, labels, and formats (Raji et al. 2021). A later review had 29 expert reviewers examine 445 language model benchmarks from the main machine learning and language conferences (Bean et al. 2025). Of the benchmarks that defined the phenomenon they measure, 47.8% used a contested definition. Across all 445, 12.3% drew their items only from datasets that happened to be easy to get, a practice called convenience sampling, and another 27.0% did so in part. Only 16.0% used uncertainty estimates or statistical tests to compare models.
The review closes with eight recommendations that read like an outline of this chapter, from defining the phenomenon and sampling items to represent it, to preparing for contamination and comparing models with statistics.
An interviewer who asks "is benchmark X a good measure of Y?" wants this kind of answer. Name the claim, then go through the kinds of evidence for and against it.
Checking that a benchmark measures something other than capability
Discriminant validity has a famous failure in safety research. To see it we need one number for a model's general capability. It comes from a striking regularity. Collect the scores of many models on many benchmarks, and one direction accounts for most of the differences between models. For 77 open base models from 21 families, the first principal component of standard benchmark scores explains nearly 80% of the variance, and the top three explain about 97% (Ruan et al. 2024).
A quick recap of the tool. Principal component analysis (PCA) finds the direction in which a cloud of points is most spread out. When the data are standardized, that direction is the top eigenvector of the correlation matrix. Each point's score is its coordinate along that direction, the dot product of its standardized row with the eigenvector. §1.6 used PCA to look inside embeddings, and §0.10 derived it from the spectral theorem.
In plain words, put every benchmark on the same scale, find the one direction along which the models differ most, and call a model's position along it its capability. Standardizing matters because benchmarks are reported in different units and spreads. Without it, the benchmark with the widest spread would decide the direction. The variance share says how much of the differences between models that one direction explains. A large share is convergent evidence that the benchmarks measure something in common, though not that the something is what any of their names claim.
Ren et al. (2024) applied this to safety. They built the capabilities score from standard capability benchmarks, among them MMLU (multiple-choice academic knowledge), MATH and GSM8K (math word problems), and BBH (hard reasoning puzzles). The first component explained 78.3% of the variance for 27 base models and 70.8% for 26 chat models. They then correlated each safety benchmark with it, with every safety score oriented so that higher means safer.
Many safety benchmarks tracked capability closely. For chat models, TruthfulQA MC1, a multiple-choice test of whether a model repeats common misconceptions, had a capabilities correlation of 81.2%. The ETHICS benchmark of moral knowledge had 82.2%. A larger model scores higher on them, so an improvement on such a benchmark cannot be credited to safety work.
Others moved the other way. WMDP is a multiple-choice test of hazardous knowledge in biosecurity, chemistry, and cybersecurity, scored so that higher means less of that knowledge. Its three subsets had correlations of −81% to −88% for the same chat models, plausibly because more capable models know more of everything, including what is dangerous. Ren et al. called the resulting confusion safetywashing, capability gains presented as safety progress. A benchmark meant to measure something distinct from general capability has to show that it is distinct, and the capabilities correlation is the test.
Here is the construction on simulated data. Forty models have a hidden capability. Ten benchmarks track it with different strengths and are reported on different scales, the last on a very wide one. A "safety" benchmark has a loadingβ on capability, the correlation it would have with the true capability, and we vary it.
Python · cell 2
The first component explains 65.2% of the variance and correlates 0.969 with the true capability, so it recovers the hidden variable well from ten noisy benchmarks. Without standardizing, the one benchmark on a wide scale takes 90% of the direction's squared weight instead of 13%. The "capabilities score" then becomes little more than that one benchmark.
A safety benchmark with loading β has a correlation with the score of about 0.97β, its loading times the score's own correlation with capability, plus a little chance correlation. A loading of 0.9 shows up as 0.88, and a loading of 0 shows up as 0.17. That last number is pure chance. With 40 models, a correlation whose true value is zero has a standard deviation of about 1/N−1=0.16. So read a capabilities correlation against an interval, because small differences between benchmarks mean nothing.
Core
The capabilities correlation of a benchmark
Implement capability_correlation(S) for a score matrix S of shape (N, J), with one row per model and one column per benchmark. It returns a tuple (scores, share, r).
scores is the length-N capabilities score of the definition. Use all J benchmarks, standardize each with the divisor N (S.std(0)), and orient v1 so that its entries sum to a positive number.
share is the variance share λ1/∑jλj.
r is a length-J array. Entry j is the Pearson correlation between column j and the capabilities score computed from the other J−1 columns, oriented the same way. That way no benchmark is compared with a score it helped build.
Ren et al. used Spearman's rank correlation, which is the Pearson correlation of the ranks. Pearson keeps the exercise short, and swapping in ranks changes one line.
import numpy as np
def capability_correlation(S):
raise NotImplementedError
Tests, hints, verified solutions, and AI help, with Pro at $7.99 a month.
Goodhart's law on a shared test set
Goodhart's law comes in several forms, and two of them matter here (§16.5, §19.1). The regressional form says that when you pick whatever scores highest on a noisy measure, you also pick whatever had the luckiest noise. The extremal form says that the measure and the truth part ways exactly where you push hardest.
A public benchmark is a measure that a whole community pushes on. A submission is one model, checkpoint, prompt, or seed scored on it. Every paper that reports the best of its runs, and every lab that keeps the highest-scoring submission, is selecting on the benchmark's noise. §0.11 called the many quiet choices behind such selection the garden of forking paths. Here we measure how much it inflates a leaderboard. Start with the smallest case, by hand.
Now the general case. Take m submissions that all have the same true accuracy p on the benchmark's distribution, scored on the same n items. By the normal approximation to the binomial, each observed score is approximately S^j≈p+SE⋅Zj, with SE=p(1−p)/n and Zj standard normal. The leaderboard reports maxjS^j, so the expected reported score is
E[j≤mmaxS^j]=p+SE⋅E[j≤mmaxZj].
The submissions are equally good, so all of the excess is selection. §16.1 computed the expected maximum of m independent standard normals as an integral against the density of the maximum, E[maxjZj]=∫zmφ(z)Φ(z)m−1dz. Here φ and Φ are the standard normal density and cumulative distribution function. What we need now is how it grows with m, and what correlation between submissions does to it.
∂ Proof of the bound, its tightness, and the correlated case
The bound. Fix t>0. The exponential is convex, so Jensen's inequality gives etE[maxjZj]≤E[etmaxjZj]. The exponential is also increasing, so etmaxjZj=maxjetZj≤∑jetZj, since a maximum of positive numbers is at most their sum. The moment generating function of a standard normal is E[etZ]=et2/2. Together,
The right side is smallest where its derivative −lnm/t2+1/2 vanishes, at t=2lnm, where it equals lnm/2+lnm/2=2lnm. Nothing used independence, only that each Zj is standard normal.
Tightness for independent normals. Fix δ∈(0,1) and let tm=(1−δ)2lnm. Write A for the event maxjZj≤tm. By independence and 1−x≤e−x,
P(A)=Φ(tm)m=(1−Φˉ(tm))m≤exp(−mΦˉ(tm)),
with Φˉ=1−Φ. The standard Gaussian tail bound Φˉ(t)≥1+t2tφ(t) gives mΦˉ(tm)≥1+tm2tm⋅2πm1−(1−δ)2, since mφ(tm)=me−(1−δ)2lnm/2π. The factor m1−(1−δ)2 grows like a power of m, while tm/(1+tm2) shrinks only like 1/lnm. So mΦˉ(tm)→∞ and P(A)→0.
Now split the expectation on A. Off A the maximum exceeds tm. On A it is at least Z1≥−∣Z1∣, and by Cauchy-Schwarz E[∣Z1∣1A]≤E[Z12]P(A)=P(A). Hence
E[jmaxZj]≥tm(1−P(A))−P(A).
Dividing by 2lnm and letting m→∞ gives a limit inferior of at least 1−δ. With the upper bound and δ arbitrary, the ratio tends to 1.
The correlated case.maxj(ρU+1−ρVj)=ρU+1−ρmaxjVj, because the shared term is the same for every j. Taking expectations and using E[U]=0 gives E[maxjZj]=1−ρE[maxjVj]. Each Zj is standard normal, and any two have correlation ρ.
In plain words, reporting the best of m runs adds about 2lnm standard errors of pure luck. That amount grows slowly and never stops growing. Correlated submissions add less, because they share their luck. The bound is loose at practical sizes. For m=100 it says 3.03 standard errors where the truth is 2.51. In the decomposition of the previous part, this is a measurement bias created by the reporting rule. Each submission's own score is unbiased for p, yet the reported maximum is not.
What is ρ in practice? It is the correlation between the scoring errors of two submissions, and it comes from items they find hard or easy together. Suppose every submission has the same per-item pass rates pi, with between-item variance σb2, and their outcomes on an item are independent given pi. Over a fresh draw of the n items, two scores then have covariance σb2/n and variance p(1−p)/n each, so ρ=σb2/(p(1−p)). Variants of one model, such as seeds, prompts, and nearby checkpoints, also make the same mistakes on the same items, which pushes ρ toward 1. Mania et al. (2019) measured this similarity among ImageNet models and showed that it provably limits the overfitting that comes from reusing a test set.
The cell simulates 400 leaderboards of 1,000 equally good submissions. It compares the average best score with the exact integral and with the bound.
Python · cell 3
On many leaderboards a 4-point gain is a headline, and here it comes from nothing but a thousand tries. This is why a careful team reports how many runs preceded a number. It is also why an interviewer who hears "we tried a few prompts and took the best" will ask how much of the gain is selection.
Core
The selection bias of a leaderboard
Implement two functions.
best_of_m_inflation(m, n, p, rho=0.0) returns the inflation, the expected amount by which the best of m equally good submissions overstates their common accuracy p. All of them are scored on the same n items, and their scoring errors have correlation rho.
debiased_best(observed_best, m, n, rho=0.0) returns the accuracy p for which p plus its inflation equals observed_best.
The setup provides expected_max_normal(m), which computes E[maxj≤mZj] by the integral of §16.1.
import numpy as np
from scipy import optimize
def best_of_m_inflation(m, n, p, rho=0.0):
raise NotImplementedError
def debiased_best(observed_best, m, n, rho=0.0):
raise NotImplementedError
Tests, hints, verified solutions, and AI help, with Pro at $7.99 a month.
The widget runs the same experiment with p=0.7 and n=1,000. Each dot is one submission's public score, the board reports the best, and the board's winner is also scored on 10,000 private items it was never selected on. Press Play to add submissions one at a time. The plot below the dots follows the board, in points above the truth, along the dashed curve of the expected inflation, while the winner's private score stays near zero.
How much does reporting the best of many submissions inflate a leaderboard?
Every submission has true accuracy 70%. The board reports the best score on 1,000 public items, and its winner is rescored on 10,000 private items.
Loading interactive figure…
How large is this effect at real scale? Smaller than the arithmetic suggests, for reasons the arithmetic also explains. Kaggle is a platform for machine learning competitions. Each competition scores submissions on a public split of the test set while it runs, and on a private split at the end, so the gap between the two directly measures overfitting to the public split. Across 120 Kaggle competitions, Roelofs et al. (2019) found little evidence of substantial overfitting.
Recht et al. (2019) rebuilt the test sets of CIFAR-10 and ImageNet by following the original collection procedures. Accuracy dropped by 3 to 15 points on CIFAR-10 and 11 to 14 points on ImageNet. Yet gains on the old test sets carried over to larger gains on the new ones, so the ranking of models largely held. They attributed the drops to slightly harder images, a shift between Dbench and the new test distribution, rather than to repeated reuse of the old test set.
Two things keep real overfitting small. Submissions are highly correlated, so 1−ρ is small. And most participants are not adversaries. The second assumption is the one to worry about, because the next result shows how far an adversary can go.
How far an adversary can push a leaderboard
Blum and Hardt (2015) asked what an analyst can do with nothing but a leaderboard that reports accurate scores. The answer is unsettling. Knowing nothing about the labels, the analyst can climb the board steadily. The recipe has three steps. Submit random guesses. Keep the ones the board scored at one half or above, since each of those tends to agree with the hidden labels a little more than chance. Then submit their majority vote, which adds up those small agreements. We write k for the number of these probing submissions, following the paper.
∂ Why the attack works, and its size
Here is a heuristic calculation of the gain, with normal approximations, which the simulation below confirms. A random vector agrees with y on each coordinate with probability 21, so its public accuracy is aj≈21+Zj/(2n) with Zj standard normal. The attack keeps the vectors with Zj>0, about s=k/2 of them, and E[Z∣Z>0]=2/π. So a kept vector agrees with y on an average coordinate with probability
21+Δ,Δ=2n2/π=2πn1.
On one coordinate, the s kept vectors are close to independent votes, each right with probability 21+Δ. They are close to independent because each vector's selection depends on that coordinate through only one of n terms. The count of right votes is approximately normal with mean s(21+Δ) and variance s/4, so the majority is right with probability
The last step is the first-order expansion of Φ at 0, valid while the gain is small. That is about 21+0.225k/n. Each kept vector carries a sliver of information about y, of size 1/n, and the majority adds the slivers coherently while their noise averages out.
In plain words, a leaderboard that reports exact scores leaks a sliver of information about its labels with every submission, and k slivers add up to about k/n of fake accuracy. With 1,000 submissions against 2,000 public labels, the attack scores about 65.5% while knowing nothing. On labels the board never used it scores 50%, so the whole gain is overfitting.
Interview
The boosting attack
A classic interview question asks why a public leaderboard cannot be trusted, and the strongest answer is to break one. Implement boosting_attack(oracle, n, k, rng). Here oracle(u) returns the accuracy of a 0/1 vector u of length n on a hidden public subset of the items.
Draw all k random vectors at once with rng.integers(0, 2, (k, n)).
Query the oracle on each and keep those scoring at least 0.5.
Return their coordinatewise majority as an integer 0/1 vector, with ties broken toward 1.
The setup provides make_leaderboard(n, rng), which returns hidden labels, the public mask, and an oracle, for your own experiments.
import numpy as np
def boosting_attack(oracle, n, k, rng):
raise NotImplementedError
Tests, hints, verified solutions, and AI help, with Pro at $7.99 a month.
The Ladder, a leaderboard that leaks less
The attack works because every exact score leaks information, so the fix is to release less. A competition needs to know which submission is best so far, not the score of every submission. The board can therefore stay silent unless a submission makes a clear improvement. Blum and Hardt (2015) call this the Ladder.
Hiding the small gains is the whole design. Of eight submissions the board moved six times, and of the other two the analyst learned only that neither was a clear improvement. A board that moves rarely has a short history, and a short history is what the next guarantee rests on.
∂ Why the Ladder's error grows only like a logarithm of k
The argument is a compression argument. Whatever the analyst does, the entire history of the board is determined by the steps at which it moved and the values it moved to. Accuracies lie in [0,1] and each move raises the board by more than η, so there are at most about 1/η moves. Each goes to one of about 1/η values, at one of k positions. So the whole history can be written down with about B=(1/η+2)log(4k/η) bits, which is the paper's count. Fix the analyst's random seed. An adaptive analyst is then a deterministic function of the history, so across all possible histories it can submit at most 2B distinct classifiers.
Now recall Hoeffding's inequality from §15.1. The mean of n independent variables in [0,1] falls more than γ below its expectation with probability at most e−2γ2n. The same bound holds for rising more than γ above it, so a deviation of more than γ either way has probability at most 2e−2γ2n. A fixed classifier's public accuracy is the mean of n independent 0/1 outcomes, so it is within γ of its true accuracy except with that probability. (We write γ for the deviation because ε is reserved in this section for the label-error rate.) A union bound, which adds up the failure probabilities of all 2B possible classifiers, gives a total failure probability of at most 2⋅2Be−2γ2n. That is small once γ≈B/n.
Balancing γ≈1/(ηn) against the rounding error η gives η≈n−1/3, up to the logarithm, and an error of the same order. The board that shows every score has no such bound. Its history takes about logn bits per submission, so B grows linearly in k.
In plain words, the Ladder caps how much an adaptive analyst can learn from the board, and what cannot be learned cannot be overfit. Its error depends on the number of submissions k only through a logarithm, while the error of a board that shows every score grows like k. The guarantee is of order n−1/3, larger than the logk/n floor that no mechanism can beat, and whether any mechanism can close that gap was left open by the paper. Against the boosting attack, the simulation below shows the Ladder's board at roughly the best-of-k noise of the previous part.
Research
The Ladder
Implement ladder(scores, eta). It takes the public accuracies of the submissions in the order they arrive and returns the array of released values R1,…,Rk of the Ladder, starting from R0=0. For the eight-submission sequence worked above, [0.513, 0.548, 0.561, 0.587, 0.50, 0.595, 0.603, 0.622] with η=0.02, the answer is [0.52, 0.54, 0.56, 0.58, 0.58, 0.58, 0.60, 0.62].
The tests check that sequence, then run the boosting attack against your board. The attacker votes with only the submissions that moved the board. The tests check that the board ends below the best-of-k noise plus two steps.
import numpy as np
def ladder(scores, eta):
return np.array(scores, dtype=float) # placeholder: the plain leaderboard shows every score
Tests, hints, verified solutions, and AI help, with Pro at $7.99 a month.
Now the attack and the Ladder side by side, on 2,000 public and 2,000 private labels, averaged over 20 boards. Against the Ladder the attacker does its best, voting with the submissions that moved the board, since only those carry information.
Python · cell 4
The widget runs the attack on one board with 2,000 public and 2,000 private labels and a Ladder step of η=0.01. After each of k random submissions, the pink line is what the board shows for the attack's vote and the green line is the vote's accuracy on the private labels. Against the Ladder, the pink line is the Ladder's released value.
Can random guesses climb a public leaderboard?
Each submission is a random guess on 2,000 public labels. The attack submits a majority vote of the lucky ones.
Loading interactive figure…
The practical lesson holds for any internal leaderboard. Release as little as the decision needs, because every released number is a little information an optimizer can use.
Why benchmarks saturate below 100%
A benchmark that cannot separate the models you care about has stopped working, even if every number on it is correct. This happens in two ways. Top scores can approach the best score the benchmark allows, which is below 100% whenever some answer keys are wrong. Or top scores can get too close to each other for the benchmark's size to resolve.
The example shows two effects at once. The perfect model loses 6 points, so wrong keys put a cap on the score. The 80% model loses only 4.4, so the true 20-point gap between the two models shows up as 18.4. Wrong keys also compress the scale below the cap. The definition names the cap.
The compression is the subtler effect, because it moves every score, not only the top one. The next result gives the exact formula under a simple model of how keys go wrong, and inverts it to recover a model's true accuracy.
∂ Proof of the label-error formula
Condition on whether the key is right and whether the model is right. These two events are independent by assumption, so the four cases have probabilities (1−ε)a, (1−ε)(1−a), εa, and ε(1−a).
If the key is right, the model matches it exactly when it is right, so the first case contributes (1−ε)a and the second nothing. If the key is wrong and the model is right, the model chose the true answer and the key is another option, so they never match. If both are wrong, the model chose one of the Kopt−1 wrong options and the key is a uniformly random one of the same Kopt−1, independently, so they match with probability 1/(Kopt−1).
Adding the cases gives the formula. It is linear in a with slope 1−ε−ε/(Kopt−1)=1−εKopt/(Kopt−1), which is positive under the stated condition, so it can be inverted. □
In plain words, label errors cap the score and also squeeze the scale below the cap. Every difference between two models shrinks by the factor 1−εKopt/(Kopt−1), so a noisy key makes models look closer together than they are. In the hand example the factor is 1−0.06⋅4/3=0.92, so a true 10-point gap shows up as 9.2.
The assumptions matter, and MMLU shows why. MMLU is a multiple-choice benchmark of academic knowledge, with four options per question and 14,042 test questions in 57 subjects. Gema et al. (2024) re-annotated 5,700 of its questions across all 57 subjects, a set they call MMLU-Redux. They estimated that 6.49% of the full benchmark's questions contain errors, and 57% of the sampled Virology questions did. Only part of that is a wrong key. Their estimates by type are 1.42% wrong ground truth, 1.54% multiple correct answers, 0.62% no correct answer, 2.47% unclear questions, and 0.44% unclear options. On an item with two correct answers, a perfect model may well match the key.
The cell checks the formula by simulation and inverts it for MMLU. Its last line recomputes the ceiling with an assumed chance, for each error type, that a perfect model still matches the key.
Python · cell 5
Label errors are not only a problem of old benchmarks. Humanity's Last Exam (HLE) was built in 2025 to be hard for the best models. It has 2,500 questions written by experts, 76% with a short exact answer and the rest multiple choice (Phan et al. 2025). Two audits found that experts dispute the key on about 15% to 29% of its questions, depending on the subset and on how strict the check is.
For a short-answer item, a wrong answer essentially never matches a wrong key, which is the limit Kopt→∞ of the theorem. The floor ε/(Kopt−1) then vanishes and the expected score is a(1−ε). A key-error rate of 29% caps a subset near 71%, and 15.4% puts the ceiling of the whole benchmark near 85%. A perfect expert would score in those ranges, and a model that matched every key would be matching the errors too. So the best score of 54.8% in October 2026 still leaves real headroom, but a future 80% on HLE may already be close to saturation.
Core
What true accuracy does a score imply on a noisy benchmark?
Implement ceiling(eps) and implied_accuracy(observed, eps, K_opt, n) under the model of the theorem.
ceiling(eps) returns the score of a perfect model.
implied_accuracy inverts the formula and clips its answer to [0,1], since sampling noise can push a score slightly past either end.
implied_accuracy raises ValueError when the observed score exceeds the ceiling by more than three standard errors, that is, when observed>1−ε+3observed(1−observed)/n. A score that high means the error model or the reported ε is wrong.
import numpy as np
def ceiling(eps):
return 1.0 # placeholder: a perfect model would score 100%
def implied_accuracy(observed, eps, K_opt, n):
return observed # placeholder: takes the score at face value
Tests, hints, verified solutions, and AI help, with Pro at $7.99 a month.
When a benchmark is too small to rank the leaders
Saturation also comes from the other direction, a benchmark too small for the gaps it is asked to resolve. §9.6 showed one face of this at the bottom of the scale. A model with a true accuracy of 10−4 scores exactly zero on a 200-question test about 98% of the time, since (1−10−4)200≈0.98. A metric that only counts exact successes then turns smooth progress into an apparent sudden jump. At the top of the scale the same arithmetic stops the board from ranking models at all.
Core
Is this benchmark saturated?
Implement saturation_report(acc, n, eps, human=None, alpha=0.05) for a list of model accuracies on one benchmark of n items. It returns a dict with three keys. Write top for the highest accuracy and SEj=accj(1−accj)/n for model j's standard error.
"ceiling" is the effective ceiling c=min(1−ε,h), or 1−ε when human is None.
"saturated" says whether the top score is within noise of the ceiling by a one-sided test, that is, whether top≥c−z1−αSEtop.
"n_tied" is a rough resolution count. It is the number of models, the leader included, whose gap to the leader is below z1−α/2SEtop2+SEj2, each model using its own standard error.
Real comparisons should be paired and corrected for comparing many models at once, which §22.2 does.
import numpy as np
from scipy import stats
def saturation_report(acc, n, eps, human=None, alpha=0.05):
raise NotImplementedError
Tests, hints, verified solutions, and AI help, with Pro at $7.99 a month.
How do you tell saturation from a real plateau, where models have really stopped improving? Read the remaining errors. If expert review finds that most items the best models still miss have wrong or debatable keys, the benchmark is saturated, and further gains are noise. If the remaining items are valid and hard, the plateau is real and the benchmark still has something to say. MMLU-Redux is exactly this exercise done at scale, and its error types are the reason the MMLU ceiling above is a range rather than a number.
The gap between benchmark scores and real use
Everything so far concerned a benchmark's internal health. The validity bias bval asks a harder question. Does a perfectly measured benchmark score predict the thing you will use the model for? That is a question of criterion validity, and the only way to answer it is to measure the criterion itself.
How can both the benchmark curve and the trial be right? List the differences between the two measurements, and each one is a validity gap.
Different items. SWE-bench tasks are self-contained issues with tests. The trial's tasks were the developers' own backlog, in repositories with very high quality bars, much unwritten context, and code review.
Different graders. A benchmark task passes when hidden tests pass. A real change passes when it meets the project's standards. The developers accepted fewer than 44% of the AI's generations and spent about 9% of their time reviewing and cleaning AI output.
Different populations. The trial's developers were experts on their own code, which is exactly where help is hardest to give. The authors list high familiarity with the repository among the factors likely to contribute to the slowdown.
Different estimands. The estimand is the quantity a study sets out to estimate. A benchmark estimates whether a model can finish a task alone. The trial estimated the time a human takes with the model's help, which includes prompting, waiting, and checking.
The authors are careful about scope. Their result is about early-2025 tools, for one population, in one setting, and it does not show that AI cannot speed up software work in general. Its lesson for evaluation is sharper than its lesson for productivity. People, experts included, badly misjudge usefulness from experience and from benchmark curves, and only a measurement of the criterion settles the question.
GDPval (Patwardhan et al. 2025) is one response, a benchmark built from the work itself. Its 1,320 tasks come from the real deliverables of professionals in 44 occupations across the 9 sectors that contribute most to US GDP. The professionals average 14 years of experience, and a task takes one of them about 7 hours on average. Graders from the same occupations compare a model's deliverable with a human expert's without knowing which is which. The metric is a win rate against the expert, so its ceiling is set by the human baseline, and the baseline can be replaced by a stronger one as models catch up. On the public 220-task gold subset, 47.6% of Claude Opus 4.1's deliverables were judged as good as or better than the expert's at release. GDPval has its own validity limits, which its authors name. Its tasks are precisely specified and done in one shot, while real work involves finding out what is wanted and iterating.
What labs do about it
No single practice fixes all five error terms, so evaluations that hold up combine several. The table lists the main practices by the term each attacks.
practice
error term it attacks
what it costs
what it misses
private held-out test sets, used rarely
Goodhart pressure, leakage
building and guarding the set
validity, since it shares the public set's distribution
measuring use, with A/B tests and randomized trials
validity
time, users, and ethics review
anything before deployment
The last row is the only one that measures μ⋆ directly, and the only one you cannot run before launch. That is why the rest of the chapter exists. Each later section makes one of the cheaper rows rigorous.
Notice also what none of them does. Every row treats the model as a black box judged by its outputs. Asking what a model computes inside, instead of only what it outputs, is the program of interpretability, which complements behavioral evaluation rather than replacing it. And putting all these pieces together into a system that gates releases, monitors deployed models, and escalates safety concerns is the job of designing an evaluation and safety system, a standard design interview at frontier labs.
Measuring your own selection bias in PyTorch
The best-of-m formula needs ρ and assumes equally good submissions. In practice you have something better, the per-item results of every submission, and you can estimate your own leaderboard's selection bias directly.
Split the public items in half at random.
Pick the best submission on one half and score it on the other half. The gap is the selection bias at n/2 items.
The bias scales like the standard error, so divide by 2 to convert it to n items. Average over many random splits.
The block checks this against the true public-minus-private gap and against the formula. It uses m=50 submissions whose items have pass rates pi∼Beta(1.4,0.6). For a Beta distribution with parameters a and b and mean p=a/(a+b), Var(pi)=p(1−p)/(a+b+1). So ρ=σb2/(p(1−p))=1/(1.4+0.6+1)=1/3.
🔥 In PyTorchfor a machine with PyTorch
All three agree at about 2.6 points (2.64, 2.62, and 2.66 in this run). The split-half estimate needs no model of the submissions. It still works when they differ in true quality, where only the rescaling by 2 is approximate. Run it before you report the best of many runs, and subtract what it finds. Better still, report the chosen submission's score on items you never selected on.
Read more
Jacobs and Wallach (2021). Measurement and Fairness. Measurement theory for computer scientists, with construct reliability and the seven aspects of construct validity defined carefully.
🎬 How METR measures Long Tasks and Experienced Open Source Dev Productivity - Joel Becker, METR · AI EngineerThe lead author of the METR randomized trial explains why benchmark scores rose while measured developer productivity fell, the section's use gap in the author's own words.🎬 Evaluating Machine (Human) Accuracy and Robustness on ImageNet - Ludwig Schmidt · IARAI ResearchA co-author of Recht et al. (2019) on rebuilding the ImageNet test set, why accuracy dropped while rankings held, and why test set reuse caused less overfitting than people feared.🎬 How Should We Evaluate Machine Learning for AI?: Percy Liang · AAAIPercy Liang on the limits of the train-test paradigm and the alternatives to it, adversarial and interactive evaluation among them, which is the motivation for living and adversarial benchmarks.