Best-of-N 是一种架构，而不仅仅是打榜技巧

每个前沿实验室的发布公告现在都附带同样的脚注：“包含并行测试时计算 (parallel test-time compute)”。Sonnet 的 SWE-bench 分数因此提升了约 5 分。GPT-5 级别的模型利用它将错误率降低了两位数。Gemini 的 Deep Think 依靠它几乎将其 ARC-AGI-2 分数翻了一番。大多数工程团队将该脚注视为基准测试的“调味剂”——一种虚标排行榜数字的手段，且认为没有实际系统会为此买单——然后继续围绕他们能负担得起的最强模型，进行单次尝试 (one attempt) 的产品架构设计。

这种直觉大概落后了两年。实验室在专业版 (pro tiers) 中加入并行采样并非为了营销装饰；他们加入它是由于在单个答案背后运行 N 次尝试通常是获得高质量的最廉价方式，有时甚至是唯一方式。当一个廉价模型的三次尝试加上一个像样的选择器 (selector) 能够击败每个 token 成本高出十倍的模型的一次尝试时，Best-of-N 就不再是一个基准测试把戏，而变成了一个架构决策——它拥有自己的成本模型、延迟特征以及标志性的失败模式。以此方式对待它的团队，正悄无声息地以比那些仍在旗舰模型上进行单次推理 (one-shot inference) 的团队更低的成本，交付更好的答案。

覆盖率曲线是核心论据

这里的经验基础很简单，一旦你看到它，就很难忽视。在非零温度 (nonzero temperature) 下对同一个问题反复采样模型，其覆盖率 (coverage) —— 即 至少一次 尝试正确的比例 —— 在四个数量级范围内随采样数量对数线性增长。《Large Language Monkeys》论文在 SWE-bench Lite 上具体化了这一点：一个中端开源模型通过一次尝试解决了 15.9% 的问题，而通过 250 次尝试解决了 56%，击败了当时 43% 的单次尝试最先进水平。

带着系统思维再读一遍。同一个模型 的一次尝试与多次尝试之间的差距，甚至比该模型与世界上最强模型之间的差距还要大。你的模型已经知道如何解决比单次采样揭示的更多的问题。能力就在那里；单次推理只是未能将其收割 (harvest) 出来。

生产环境的转化是每个团队都可以在自己的工作负载上运行的成本比较：

• 垂直扩展 (Vertical scaling)：支付更高费用购买更大的模型，获得更好的单次采样答案分布。
• 水平扩展 (Horizontal scaling)：支付更多费用从小模型中获取更多采样，从而在更广泛的搜索中获得更多机会。

在重推理的基准测试中，使用 Best-of-N 的小模型通常在总 token 成本相同或更低的情况下，匹配或击败高一级的模型 —— 通过采样扩展的 1.5B 模型表现优于单次尝试的 3B 模型，3B 优于 7B。这种交叉点并非普适的：如果你的任务单次成功率接近于零（再多采样也救不了你）或接近于一（采样毫无增益），那么垂直扩展胜出。Best-of-N 在中间地带发挥作用，即模型有时能成功，而你需要它可靠地成功。

延迟方面的情况也比直觉预想的要好。尝试是并发运行的，因此挂钟延迟 (wall-clock latency) 是 N 次尝试中的最大值加上评判环节，而不是 N 次尝试的总和。利用供应商的批量定价 (batch pricing) 和共享提示词前缀缓存 (shared prompt-prefix caching) —— 这 N 次尝试共享相同的输入 token，大多数 API 现在只对缓存的前缀计费一次 —— 第二次到第五次尝试的边际成本主要是输出 token。对于一个单次尝试需要 90 秒的代理 (agentic) 任务，5 次并行尝试大约只需要 95 秒。

评判器是你的质量上限

这就是基准测试框架与生产环境框架完全分道扬镳的地方。基准测试报告的是覆盖率 —— pass@k，“是否有任何一次尝试成功” —— 因为基准测试工具知道正确答案。生产环境则不然。你必须 挑选 出一个尝试展示给用户，而这个挑选者（而不是生成器）成为了限制你质量的组件。

这是 Best-of-N 中真正困难的部分，且按领域清晰划分：

• 可验证领域 (Verifiable domains) 是天赐之物。必须通过测试的代码、必须执行的 SQL、具有可检查答案的数学、带有模式 (schema) 的结构化输出 —— 在这里，验证器是确定性的，覆盖率曲线可以被完全收割。如果你能运行候选方案，Best-of-N 几乎就是免费的质量提升。
• 半可验证领域 (Semi-verifiable domains) 拥有廉价的部分过滤器：它是否可编译、是否可解析、是否符合 lint 规则、是否引用了存在的文档。这些过滤器不负责选出最佳候选者，但能廉价地剔除最差的候选者，从而将评判器的任务从“大海捞针”转变为“对合理的方案进行排序”。
• 不可验证领域 (Unverifiable domains) —— 摘要、计划、电子邮件、分析 —— 让你陷入模型评判模型的情形，而这正是团队受挫的地方。

关于 LLM 作为评判器 (LLM-as-judge) 可靠性的研究应该给所有人的热情泼点冷水。评判器表现出位置偏见 (position bias，无论内容如何都更倾向于出现在第一或第二位的候选者)、冗长偏见 (verbosity bias，更长的答案获胜) 和自我偏好 (self-preference，评判器偏爱其自身模型系列的输出)。更糟糕的是，评判器可能是高度 可重复 的（不同运行之间的相关性超过 0.95），但仍然是严重 无效 的，始终由于相同的偏见原因挑选出错误的答案。在仪表盘上，可重复性感觉就像可靠性。但它不是。

《Large Language Monkeys》的结果还有后半部分，其引用率远低于前半部分：在没有自动验证器的领域中，多数投票 (majority voting) 和奖励模型 (reward models) 在几百个采样后会进入平台期。覆盖率持续攀升，但收割到的准确率却停滞不前。这两条曲线之间的差距正是评判器的失败率，这也是为什么“直接调大 N”不是一种策略的原因。超过适度的 N 之后，你买到的不再是准确率，而是你的评判器无法区分的候选方案。

因此，Best-of-N 系统的工程努力应该放在杠杆作用最大的地方：选择器。按单位努力的价值排序，实际操作建议如下：

• 在改进模型之前先进行机械性去偏。 在每次对比时随机化候选者顺序，或者评估两种顺序并剔除不一致的判定。通过规范化格式消除长度线索。使用与生成器不同模型系列的评判器。
• 比起绝对评分，更倾向于两两对决 (pairwise tournaments)。 询问评判器“这两个中哪一个更好”比“给这个打 1–10 分”更可靠，且在 N 个候选者中进行淘汰赛只需 N−1 次对比。
• 拆解判定。 多智能体验证工作表明，一组细分领域的“方面验证器 (aspect verifiers)” —— 事实是否与上下文一致、是否遵循要求的格式、是否解决了请求的所有部分 —— 每个验证器返回一个二进制批准，优于一个给出整体判定的通用评判器。窄问题更容易回答，也更容易校准。
• 在信任任何东西之前，先针对黄金集 (gold set) 进行校准。 一个在三个例子上看起来合理的评判器提示词，在生产环境中会以你直到用户发现前都看不到的方式失败。在一百个标注案例上衡量评判器与人工的一致性；将该一致性比率视为系统的质量上限，因为它确实就是。

加载中…