Free preview

When the Proxy Keeps Rising and the Truth Turns Over

In one line: as you optimise harder against a proxy, true quality rises, peaks and then falls — while the proxy score keeps climbing, so the failure is invisible from inside the loop.

Everyone can recite that optimising a proxy eventually breaks it. What separates a Staff answer is knowing the shape of the curve, and that the shape is why nobody notices.

The measured shape

The cleanest study of this uses a synthetic setup: a fixed gold reward model stands in for human judgement, a proxy is trained on its labels, and a policy is optimised against the proxy. Optimisation pressure is measured as distance travelled from the starting policy, expressed as a KL divergence.

Both curves are fit as smooth functions of the square root of the KL distance — a quadratic form under best-of-n sampling, a logarithmic one under reinforcement learning — and their coefficients scale predictably with reward model size and data. The result that matters for a system designer is the divergence: the gold score turns over while the proxy fit barely does.

So the loop's own dashboard shows a line going up throughout. There is no dip to alert on, no error rate, no exception. The system is working exactly as specified and the thing you wanted has been getting worse for some time.

Why it happens, mechanically

The proxy agrees with the truth on the distribution it was fitted to. The optimiser's job is to move away from that distribution — that is what optimisation is. As it moves, it reaches inputs where the proxy was never calibrated, and out there the proxy's errors are not random: the optimiser has been selecting for the direction in which the proxy over-estimates, because that direction is what "improvement" looked like.

Two consequences follow, and both are usable in an interview.

Optimisation pressure is the variable, not the model or the metric. The same proxy is fine at low pressure and dangerous at high pressure, which means "how hard are we optimising" is a design parameter you should be able to state a value for.

A better proxy moves the peak, it does not remove it. Larger reward models delay the turnover; they do not prevent it. So "we will use a stronger judge" is a mitigation, not a solution.

What it looks like in a real loop

The generic forms are worth recognising because they arrive looking like wins:

The last one is the pattern to hold onto: when the metric is the absence of an event, the cheapest way to improve it is to suppress the event rather than its cause.

Defences that hold

  • Cap the optimisation pressure. Bound how far an artifact may move from the current one per round, and bound the number of rounds between human review. This is the only defence that addresses the mechanism rather than a symptom.
  • Keep a gold set that is never optimised against and is scored by a different process — ideally human-labelled. Its job is to detect the turnover, which requires that it is never used to select.
  • Use several evaluators that fail differently — a programmatic check, a judge, a human sample — and treat divergence between them as a stop signal. When the judge is rising and the human sample is flat, the loop has left the region where they agree.
  • Watch the artifact's diff, not only the score. Reward hacking is usually obvious in the artifact and invisible in the metric.

Saying it well

State the curve. Say the proxy keeps rising after the gold turns over, so the failure is silent by construction. Then give the defence in terms of pressure rather than metric quality — a better judge buys distance, a pressure cap and an unoptimised gold set buy detection.

Key takeaway

Optimising against a proxy produces a gold-score curve that rises, peaks and falls, while the proxy score keeps climbing — so from inside the loop the failure has no signal at all. Treat optimisation pressure as a bounded design parameter, keep a never-optimised gold set scored by a different process, run evaluators that fail differently and stop on their divergence, and read the artifact diff rather than only the metric.

Next: why the candidate that won is usually worse than its score.

Enjoying the preview?

Create a free account to unlock the rest of this course, the in-browser judge, and live AI mock interviews.

Sign up free to continue