Checking a solution is frequently easier than finding one. Verifying that a proof holds is easier than constructing it; confirming that code passes a test is easier than writing the code. That asymmetry is old, and it is what verifier models exploit.
Generate several candidate answers. Score each with a model trained to assess correctness. Return the best. You have spent more compute at inference and, on the right tasks, bought a meaningful accuracy improvement.
What changed in 2026
- Step-level verification displaced outcome-level. Scoring each reasoning step, rather than only the final answer, proved substantially more effective.
- Verifiers enabled search. Reliable partial-state scoring is what makes tree search directed rather than random.
- Inference-time compute became a deliberate axis. Spending more at inference rather than training larger models settled as a legitimate strategy.
- Independence became the stated requirement. The finding that a verifier sharing the generator's weights and prompt inherits its errors moved into standard practice.
Outcome versus process
|
Outcome verifier |
Process verifier |
| Scores |
The final answer |
Each reasoning step |
| Training data |
Answer correctness labels |
Step-level correctness labels |
| Signal density |
One label per attempt |
Many labels per attempt |
| Catches |
That something is wrong |
Where it went wrong |
| Enables search |
Weakly |
Well |
| Labelling cost |
Low |
High |
An outcome verifier tells you a chain of reasoning arrived somewhere wrong. That is useful for selecting among complete candidates and useless for guiding exploration, because you learn nothing until the end.
A process verifier scores each step. That gives dense signal — you can prune a branch as soon as it goes wrong rather than after generating the rest of it — which is what makes search efficient. It also catches the case where correct reasoning reaches a wrong answer through an arithmetic slip, and the more troubling reverse: flawed reasoning that happens to arrive at the right answer, which an outcome verifier rewards.
The cost is labelling. Marking which step in a chain first went wrong is far more work than marking whether the answer was right.
Independence matters
A verifier that shares the generator's weights and prompt shares its blind spots. If the model reasons incorrectly about a class of problem, it will verify that incorrect reasoning as sound, because the same process produced both judgements.
Meaningful independence comes from any of: a separately trained model, a different prompt framing that changes what the model attends to, a different model family entirely, or — best of all — a non-model check.
That last one deserves emphasis. Where a deterministic check exists, use it. A schema validator, a test suite, a compiler, or a lookup against a database is cheaper, exact, and not subject to the verifier's own error rate. Reach for a model verifier only when the property you need to check cannot be expressed as a rule — see LLM output validation.
The accuracy ceiling
A verifier is a model with an error rate, and that error rate bounds what the whole arrangement can achieve.
A verifier agreeing with human judgement 80% of the time cannot reliably select the best of five candidates, because it misjudges one in five. Best-of-N selection improves with more candidates only while the verifier can actually tell them apart — past that, you are sampling more and choosing among them badly.
Two consequences. Measure verifier accuracy against human labels before trusting a pipeline built on it. And watch for the same drift that affects any evaluator: as the generator improves, its outputs move outside the distribution the verifier was trained on, and reliability degrades exactly when quality is highest — the pattern described in eval drift.
Common mistakes
- Same model and prompt for generation and verification. Shared blind spots.
- Using a model where a rule would do. Slower, more expensive, and less exact.
- Not measuring verifier accuracy. It is the ceiling on everything downstream.
- Outcome-only verification for search. No signal until the end, so no pruning.
- Ignoring verifier drift. Degrades as the generator improves.
- Sampling more candidates than the verifier can discriminate between. Cost without benefit.
FAQ
How many candidates should I generate?
As many as your verifier can meaningfully rank, which is fewer than people assume. Measure selection accuracy against candidate count; it plateaus and then declines as noise dominates.
Is this the same as LLM-as-judge?
Closely related. A judge typically scores quality against a rubric; a verifier scores correctness, often trained specifically for it. The reliability concerns are the same — see LLM-as-judge.
Can I train one without step-level labels?
Outcome labels alone give you an outcome verifier, which is easier to build and weaker. Some approaches infer step labels from outcomes across many samples, at the cost of noise.
Does this replace reflection?
It is generally a stronger version of the same idea — a dedicated scorer rather than prompted self-critique. See agent reflection.
Where to go next
For the search this enables, read tree search agents. For the deterministic checks that should come first, LLM output validation, and for the evaluator reliability problem, LLM-as-judge.