Search, Verifiers, and Budget-Forcing — Reasoning Models & Test-Time Compute

A large language model (LLM) can often produce a plausible answer in one pass, but many important problems are not solved by plausibility alone. They are solved by trying alternatives, rejecting weak ones, and spending more effort on the parts that are uncertain or costly to get wrong. Search, verifiers, and budget-forcing are the three simple ideas behind that shift: explore the space of possible answers, judge those answers with some independent signal, and deliberately allocate time or computation instead of accepting the first fluent response.

Start with the problem: finding, not just saying

Imagine a maze. If you stand at the entrance and say the first route that comes to mind, you may be lucky, but luck is not a method. A better method is to try routes, remember where they lead, turn back from dead ends, and prefer paths that get closer to the exit. That is search.

In artificial intelligence, search means exploring a set of possible states and moves. A state is where the system currently is: a partial plan, a draft answer, a board position, a line of code, or a proposed diagnosis. A move changes the state: add a sentence, call a tool, run a test, choose an action, or revise a step. A goal is the condition the system is trying to reach.

A one-shot answer is still a kind of search, but it is an extremely short one. The system moves directly from prompt to answer without examining many alternatives. Search makes that process explicit. It asks: what else could we try, how do we know whether it helped, and when should we stop?

Why the first answer is often not the best answer

The first answer has two advantages: it is fast, and it is cheap. It also has two weaknesses: it may be based on a brittle interpretation of the task, and it may not expose its own mistakes. Fluency can hide uncertainty. A paragraph can sound settled even when its facts, assumptions, or reasoning are poor.

Search improves this by creating variation. The system can generate several candidate answers, plans, tool calls, or proofs. Some candidates will fail quickly. Some will be redundant. A few may reveal a better route that a single pass would never have taken.

This does not mean that more candidates always produce better results. Search without judgment is wandering. The value comes from pairing generation with selection: create options, compare them, keep the useful ones, and discard the rest.

📌

Search is not magic. Search only helps when the system has enough variety to find better options and enough signal to recognize them.

Search pairs generation with selection: create options, compare them, keep the useful ones, discard the rest, repeat.

Verifiers: the part that says what good means

A verifier is anything that evaluates a candidate answer or action. It may be a simple rule, a unit test, a calculator, a database lookup, a second model, a human reviewer, or a combination of these. The verifier is important because it gives search direction. Without it, the system has no reliable way to prefer one candidate over another.

The strongest verifiers are grounded in the task itself. If the task is to write code, tests and static analysis can check whether the code runs and follows constraints. If the task is arithmetic, a calculator can check the result. If the task is legal, medical, or strategic, the verifier may need documented sources, expert review, or a carefully designed rubric.

Some verifiers are deterministic: the same input always gives the same result. A compiler either accepts code or reports an error. Other verifiers are probabilistic: they estimate quality but may disagree from run to run. A learned reward model, which is a model trained to score outputs, can be useful, but it is not the same as truth. It reflects the data, labels, and incentives used to train it.

Rule-based verifier: checks explicit constraints, such as length, format, or forbidden content.
Execution verifier: runs code, queries a system, or performs a calculation to see what actually happens.
Reference verifier: compares the output with trusted sources, known answers, or retrieved evidence.
Model-based verifier: asks another model to score, critique, or rank candidates.
Human verifier: uses expert judgment where context, accountability, or values matter.

The strongest verifier is grounded in the task itself: tests for code, a calculator for math, sources for law, a rubric for strategy.

Budget-forcing: making effort a design choice

A budget is the amount of time, computation, money, or human attention the system is allowed to spend. Budget-forcing means deliberately requiring the system to use, reserve, or allocate that budget instead of stopping at the first acceptable-looking answer. It turns effort into a controlled variable.

There are several ways to force a budget. You can ask for multiple independent drafts and pick the best one. You can require a model to produce an intermediate plan before finalizing. You can run a tree search, where promising branches get expanded and weak branches are pruned. You can spend extra verification only on uncertain cases. In each case, the system is not merely allowed to think longer; it is structured to spend effort in a particular way.

The word forcing matters. Many systems naturally prefer short routes because they reduce latency and cost. If the product, prompt, or orchestration layer accepts the first fluent answer, the system may never discover that a better answer was available. Budget-forcing changes the default from answer now to answer after the agreed amount of checking.

Budget-forcing structures effort: multiple drafts, an intermediate plan, a pruned tree search, or checks aimed at uncertain cases.

The trade-off: quality, latency, and cost

Search and verification consume resources. More candidates mean more model calls, more tool calls, more memory, and more waiting. A system that is slightly more accurate but five times slower may be worse for a live customer support chat. The same delay may be acceptable for drafting a contract clause, planning a software migration, or reviewing a safety-critical procedure.

This is why budget-forcing should be tied to the value and risk of the task. Low-risk tasks can use small budgets and lightweight verifiers. High-risk tasks deserve stronger checks, clearer audit trails, and sometimes human review. A service-level objective (SLO) is a measurable reliability or latency target, such as responding within two seconds for 95 percent of requests. Search policies should respect these targets rather than treating quality as the only goal.

A useful design question is not how much search can we afford everywhere. It is where does extra effort change the decision. If a verifier is weak, spending more search budget may only produce more polished errors. If the verifier is strong, extra candidates can materially improve outcomes because the system can tell better from worse.

⚠️

Budget follows risk. Spend the largest budgets on tasks where mistakes are expensive and verification is strong enough to guide the extra effort.

Failure modes: when search makes things worse

Search can amplify errors when the verifier rewards the wrong thing. If a scoring rule prefers confident language, the system may learn to produce confident nonsense. If a rubric rewards citation count rather than source quality, it may gather impressive but irrelevant references. This is a version of Goodhart's law: when a measure becomes the target, it can stop being a good measure.

Search can also overfit to the verifier. Code may pass the visible tests while failing real user cases. A generated answer may satisfy a checklist while missing the user's actual need. A model-based judge may share the same blind spots as the model being judged, especially if both were trained on similar data.

Another failure mode is wasted deliberation. For some tasks, the first answer is already good enough, and more search only adds cost. For other tasks, the missing ingredient is not more thinking but better information. If the system lacks the needed facts, it should retrieve data, ask a clarifying question, or escalate, not simply generate more guesses.

⚠️

Fluent is not verified. A polished answer is only evidence that the system can write smoothly, not that the answer is correct.

Decisions for leaders and practitioners

The practical decision is where to place effort in the workflow. A leader may decide that routine summaries get one model pass and a format check, while financial forecasts get multiple scenarios, data validation, and human sign-off. A practitioner may decide that code generation must pass unit tests, security scans, and style checks before it can be proposed for review.

Start by classifying tasks by consequence. What happens if the output is wrong, late, incomplete, or misleading? Then identify the best available verifier. If the only verifier is another model making a vague judgment, be cautious about high-stakes automation. If the verifier is an executable test, a trusted database, or an expert review process, search becomes more dependable.

Finally, set stop rules before deployment. Stop after a fixed number of candidates, after confidence crosses a threshold, after a cost limit is reached, or after a human reviewer intervenes. Stop rules prevent runaway spending and make system behavior easier to explain.

Classify the task by risk and value.
Choose the strongest practical verifier.
Set a search budget for normal, hard, and exceptional cases.
Define stop rules for cost, time, confidence, and escalation.
Measure outcomes on real tasks, not only on examples selected during development.

A simple design pattern to remember

A dependable search system has four parts. It proposes candidates. It checks them with the best available verifier. It allocates budget based on risk and uncertainty. It stops according to a rule that was chosen before the answer was known.

This pattern scales from small to large systems. For a short email, candidates may be alternate phrasings and the verifier may be tone and length checks. For code, candidates may be different implementations and the verifier may be tests. For operations planning, candidates may be response plans and the verifier may be policy, inventory, timing, and human approval.

The central lesson is modest but powerful: intelligence is not only in generation. It is also in selection. A system that knows how to look, check, and stop can be more useful than one that merely answers quickly.

Key takeaways

Search treats problem solving as exploring possible answers or actions, not merely producing the first response.
A verifier gives search direction by judging which candidates are better, safer, or more correct.
Budget-forcing deliberately spends time or computation on generation and checking instead of accepting the first fluent answer.
Extra search helps most when the verifier is strong and the task has meaningful risk or value.
Weak verifiers can reward the wrong behavior, producing polished errors or overfitted answers.
Good systems define budgets, stop rules, and escalation paths before they are needed.

A dependable search system proposes candidates, checks them, allocates budget by risk, and stops on a preset rule.

Glossary

Large language model (LLM): A machine learning system trained on large amounts of text to predict and generate language.
Search: The process of exploring possible states, actions, or answers to find one that meets a goal.
Verifier: A rule, tool, model, or person that evaluates whether a candidate output is correct, useful, or acceptable.
Budget-forcing: A design technique that requires a system to spend a planned amount of effort on search or verification before stopping.
Candidate: One possible answer, plan, action, or intermediate result considered during search.
Reward model: A model trained to assign scores to outputs, often used as a learned but imperfect verifier.
Service-level objective (SLO): A measurable target for a system, such as a maximum response time or required availability level.
Goodhart's law: The observation that when a measurement becomes a target, people or systems may optimize the measure in ways that reduce its original meaning.