LLM 搜尋中，增加候選廣度比加深單一答案更划算
Breadth is the cheap axis
一項量子電路設計研究中，LLM 驅動搜尋在 8 項任務中的 7 項超越此前最佳成果；作者據此主張，候選生成和篩選成本低時，應多生成候選並投入資源篩選，而非只加深單一答案的推理。
Seven of eight circuit-design tasks, an LLM-driven search beat the previous state of the art. The paper is about quantum circuits, but the thing I keep coming back to is where it spends its compute.
It doesn't ask a model to think harder. It asks a model to propose a lot, then spends the real budget on picking. The model is the cheap part of that loop. The search is the expensive part, and the win lives there.
Look at how most agent stacks spend tokens and you'll see the opposite. One chain of thought, stretched. More "reason carefully." A bigger context window. All depth, no breadth. Depth is what you buy when you have no way to generate alternatives — when your only move is to make the single answer better.
The number I actually track
Hit rate at N. Of N candidates, how often does at least one clear the bar?
If that curve is flat as N grows, your sampler is broken. You're paying eight times for eight copies of the same answer. If it climbs, breadth is doing real work, and you should push N until the curve bends. That bend is your budget line, and it's different for every task. I've never guessed it right, only measured it.
Diversity is the whole game here. Eight samples at temperature 0.2 with the same prompt is one sample with extra steps. I've had more luck varying the framing than the temperature — the same question asked as a constraint problem, as a search problem, as "what would break this." Different decompositions produce genuinely different candidates. Slight perturbations of the same prompt produce siblings.
Why nobody does it
Latency, mostly. Fanning out feels slower even when it isn't — eight parallel calls finish in roughly the time of one, if your provider lets you. Then there's cost accounting: per-token billing makes 8x look like 8x, and nobody wants to explain that line item. And the app mental model is one request, one response. Fanning out breaks it, and now your logs are a tree instead of a line.
All of that is real friction. None of it is a reason the technique doesn't work.
Where it breaks
Tool calls.
If a candidate is a full agent trajectory, N candidates means N sets of side effects. N writes, N emails, N charges on someone's card. Sampling is nearly free for text and expensive for actions, and the moment your candidate touches the world, breadth stops being the cheap axis.
Which points at a shape I've been converging on anyway: keep the acting stage single-threaded, and put the breadth upstream, in the part that only produces text. Propose wide, act once. The expensive, irreversible step gets one shot. The cheap, reversible step gets as many as you can afford.
What I'd take from the paper
Not "models are better at physics now." The interesting claim is narrower and more useful: when candidates are cheap to produce and cheap to filter, the winning move is to stop trying to get one answer right and start trying to get a hundred answers fast.
That's less clever than it sounds. It's also the direction I've been moving my own loops, and it works more often than the clever version did.
來源：DEV Community · dev.to