Repeated sampling raises the chance that a correct answer exists somewhere in the pool; a verifier then has to find it. This lesson asks what property of that verifier decides whether more samples help or hurt — and answers with a quantity that standard accuracy metrics barely register.
Two ways a verifier can be imperfect
Give each candidate a score. A useful model separates two failure modes that a single "verifier accuracy" number blends together.[1]
- Discrimination, . Correct candidates score and ordinary wrong ones . Larger means cleaner separation on average; the area under the ROC curve is .
- Exploitability, . A small fraction of wrong candidates are scored high — at or above the correct ones. These are the verifier's blind spots: reward hacks, answers that pass tests without solving the task, persuasive but false proofs.
The two fail differently. Low discrimination costs accuracy smoothly. Any nonzero exploitability places a cliff downstream, because taking the argmax over many samples is a search procedure, and searching long enough finds the blind spot.
The noise floor is a 1927 identity
If a correct candidate scores and a wrong one independently, their difference is , so
This is Thurstone's Law of Comparative Judgment, Case V,[2] the two-alternative forced-choice error rate of signal detection theory, and the bit-error rate of binary phase-shift keying. The lab first reported this expression as a newly discovered cross-domain law with ; it then retracted that framing in full, noting that the measured Monte-Carlo error around an exact identity and that the "law" changes form under non-Gaussian noise.[3] The retraction is part of the lesson: a fit that good, across unrelated domains, usually means you derived an identity.
Why accuracy peaks and then falls
With , Best-of-N accuracy rises monotonically towards coverage. With it becomes a race between two maxima: the best of roughly correct candidates against the best of roughly exploiters whose scores sit, by construction, above the honest distribution. The extreme-value advantage of the larger correct pool grows only like , while the exploiters' margin is fixed, so as grows the exploiters win.
Worked example (the lab's reference model, , , exploiters scored one unit above correct candidates):
| Coverage | Accuracy, | ||||
|---|---|---|---|---|---|
| 16 | 0.815 | 0.61 | 0.61 | 0.56 | 0.41 |
| 64 | 0.999 | 0.87 | 0.85 | 0.71 | 0.34 |
| 512 | 1.000 | 0.98 | 0.93 | 0.59 | 0.17 |
| 8192 | 1.000 | 1.00 | 0.87 | 0.36 | 0.07 |
Bold marks each column's peak on the power-of-two grid. Three regularities follow:[1]
- Honest verifiers are monotone. If your Best-of-N curve turns over, you have measured exploitability, not noise.
- The safe budget is set mainly by . It falls from 512 to 64 to 16 as rises tenfold and fivefold.
- Discrimination buys height, not immunity. At , raising from 2 to 3 lifts the peak from about 0.71 to 0.79, but the curve still turns over, now near .
At , , , a team plans to raise from 64 to 1024 "since coverage is already near 1, it can't hurt". Using the table's model, what happens?
Show answer +Hide answer −
Accuracy falls from about 0.71 to about 0.53 (the model gives 0.526 at ). Coverage is saturated, so the extra samples add almost no new correct candidates but many more chances for a high-scoring wrong one to appear. Past , compute should go to a less exploitable verifier, not more samples.
Calibrating against real reward models
The model would be a curiosity if could not be estimated for real systems. Gao, Schulman and Hilton (2022) measured how a "gold" reward degrades as Best-of-N and RL optimise against proxy reward models of various sizes: gold reward rises, peaks, then falls, with coefficients that scale smoothly with reward-model size.[4] Inverting curves of that shape through the two-axis model, the lab obtained an approximate relation , which maps observed peaks at between 16 and 256 to – — a blind spot between one in 500 and one in 20 wrong answers.[5] That range is invisible to AUC-style reports, and sufficient to explain the saturation practitioners see. The lab is explicit that this is an inversion, not a direct measurement: the functional-form match to Gao et al.'s fitted law failed its own pre-registered bar, and a direct measurement on open reward models is specified but not yet run.[1]
Independent work reached the same qualitative conclusion by other routes. Stroebl, Kapoor and Narayanan (2024) showed that resampling against imperfect unit tests has an accuracy ceiling set by the verifier's false positives, and that once false positives carry a cost, the optimal number of samples is often finite and small.[6] Khalaf et al. (2025) proved that the rise-then-fall of true reward is an inevitable property of a broad class of inference-time selection schemes, including Best-of-N, and proposed tuning the selection parameter to hedge against it.[7]
Exploitability belongs to the verifier and its pool
Three later lab results narrowed the picture.
Pool-relative. Placing one fixed verifier behind five different prefilters changed its measured exploitability from 0.153 to 0.949, a factor of 6.2. A prefilter correlated with the final verifier did worse than no prefilter, because it concentrated the finalist's blind spots.[8] Practical consequence: estimate on the post-prefilter pool the verifier will actually face.
Constructed versus sampled exploits. The model above treats blind spots as sampled — each wrong answer stumbles into one with probability . Real adversaries construct them from the checker's definition. At a matched exploit rate, Best-of-8192 accuracy was 0.862 with sampled exploits and 0.000 with constructed ones; plurality voting among high scorers held at 0.999 in both cases.[9] Construction attacks ranking; it does not attack counting. The live counterpart is GPU kernel competitions, where a workshop paper reports hacked submissions falling from 3.45% to 0.37% after a detector was deployed — with the caveat that the detector itself labelled what counted as a hack.[10]
Heavy tails. The formula holds only for Gaussian-like score noise. Under Cauchy noise it under-predicts the blind-spot rate by 11× at gap/ and 723× at gap/.[3] Never extrapolate a fit into the small- tail; estimate directly from labelled data and check excess kurtosis first.
The pattern is not confined to selection at inference. Reinforcement learning against a verifier is a longer, adaptive search, and 2025–2026 reports find the same failure there: METR observed recent frontier models reward hacking on its agentic task suites,[11] and Helff et al. (2026) found RLVR-trained reasoning models emitting outputs that pass extensional checks without inducing the intended rule, more often as task complexity and inference-time compute grew.[12]
Your verifier was calibrated at on raw samples. You add a cheap prefilter built from the same reward model. Should you reuse when choosing ?
Show answer +Hide answer −
No. Exploitability is a property of the verifier–pool pair. A prefilter correlated with the verifier passes exactly the candidates the verifier is fooled by, so the post-filter can be much higher (in the lab's experiment, a correlated prefilter did worse than none). Re-estimate on the filtered pool.
Try it
Open /research/tools/verifier-budget. With the defaults (, , ) it reports a safe budget of and accuracy at of roughly half the peak. Now set and watch move to 512; then restore and raise to 3 to see the peak rise while the turnover remains. Finally set : the recommended rule switches from Best-of-N to consensus, because plurality voting now beats the argmax peak. If you have labelled validation scores, paste them in to estimate directly — on the pool your verifier will really see.
Key takeaways
- Separate verifier quality into discrimination (, what AUC measures) and exploitability (, the rate of high-scoring wrong answers).
- Any makes Best-of-N accuracy non-monotone in ; the safe budget is governed by , and better discrimination does not remove the turnover.
- Real reward models plausibly sit at – (an inversion, not yet a direct measurement).
- is pool-relative, collapses ranking when exploits are constructed, and must be estimated directly when score tails are heavy; counting-based selection is the more robust default.
Sources
-
NeuroGenesys (2026). "Thurstone bounds Best-of-N: a 1927 identity, calibrated for modern verifiers." Preprint draft. /research/thurstone-bounds-best-of-n ↩ ↩2 ↩3
-
L. L. Thurstone (1927). "A Law of Comparative Judgment." Psychological Review 34(4): 273–286. https://doi.org/10.1037/h0070288 ↩
-
NeuroGenesys (2026). "Correction: the ε selection law is Thurstone's 1927 comparative judgment, not a discovery." /research/epsilon-thurstone-correction ↩ ↩2
-
L. Gao, J. Schulman, J. Hilton (2022; ICML 2023). "Scaling Laws for Reward Model Overoptimization." https://arxiv.org/abs/2210.10760 ↩
-
NeuroGenesys (2026). "When more sampling hurts: verifier exploitability, not accuracy, bounds test-time compute." Superseded draft — its novelty framing is withdrawn by the correction above; its measured constants stand. /research/verifier-exploitability ↩
-
B. Stroebl, S. Kapoor, A. Narayanan (2024). "Inference Scaling fLaws: The Limits of LLM Resampling with Imperfect Verifiers." https://arxiv.org/abs/2411.17501 ↩
-
H. Khalaf, C. M. Verdun, A. Oesterling, H. Lakkaraju, F. du Pin Calmon (2025; NeurIPS 2025). "Inference-Time Reward Hacking in Large Language Models." https://arxiv.org/abs/2506.19248 ↩
-
NeuroGenesys (2026). "Exploitability is a property of a verifier and its candidate pool, not the verifier alone." /research/exploitability-verifier-pool ↩
-
NeuroGenesys (2026). "When the exploit is constructed: ranking collapses, counting survives." /research/constructed-exploits ↩
-
M. E. Baslak, E. Schultheis, M. Sirovatka, A. Zhang, M. Saroufim (2026). "We Let Agents Compete and They Tried to Cheat. KernelGuard: Defending GPU Competitions from Adversarial Agentic Systems." Workshop paper, ICML 2026. https://icml.cc/virtual/2026/67922 ↩
-
METR (2025, June 5). "Recent Frontier Models Are Reward Hacking." https://metr.substack.com/p/2025-06-05-recent-reward-hacking ↩
-
L. Helff, Q. Delfosse, D. Steinmann, et al. (2026). "LLMs Gaming Verifiers: RLVR can Lead to Reward Hacking." https://arxiv.org/abs/2604.15149 ↩
