推理预算实验：Best-of-N 的收益与拐点

本实验使用两个核心输入：单次成功率 $p$ 和候选数 $N$。至少一次正确的理论上限是：

$$P_{\text{any}} = 1-(1-p)^N$$

默认 $p=0.25$、$N=8$ 时，$P_{\text{any}} \approx 0.90$。这看起来非常诱人，但还不是最终可靠率。

验证器修正

把验证器准确率 $v$ 作为选择阶段的乘数，是一种粗略估计：

$$P_{\text{selected}} \approx P_{\text{any}} \times v$$

当 $v=0.9$ 时，估计可靠率约为 81%。真实系统还应考虑候选之间的相关性、验证器对错误答案的偏好，以及无法自动验证的任务。

成本

若每次采样花费 $c$，总预算为 $Nc$。每个成功答案的期望成本约为：

$$\frac{Nc}{\max(P_{\text{selected}}, \epsilon)}$$

这比“单次成本”更接近业务指标，也更容易暴露“多试几次”的隐藏代价。

打开 推理预算分配器 调整参数。若把验证器精度降到 50%，观察理论上限与最终可靠率的差距如何扩大。

最后，永远把延迟纳入模型：截止期前无法完成的候选没有业务价值。

实验里的四个参数

attempts 是候选数量，successRate 是单次回答正确的概率，verifierAccuracy 是从候选中选对答案的概率，costPerAttempt 是一次采样与验证的统一成本单位。实验先计算至少一次正确的上限：

$$P_{\text{best-of-N}} = 1 - (1-p)^N$$

再把验证器精度作为近似筛选率，得到可靠率上界 $P_{\text{verified}} \approx P_{\text{best-of-N}} \times v$。这个乘法假设验证器独立于候选生成；真实任务中验证器可能被同一个错误模式欺骗，因此实际值会更低。

一个可手算的例子

若单次成功率 25%，采样 8 次，理论上至少一次正确的概率是：

$$1 - 0.75^8 \approx 0.8999$$

也就是说，最好情况下约有 90% 的概率找到一个正确答案。若验证器只有 90% 的选对能力，最终可靠率的上界约为 81%。如果每次尝试成本是 1.5，总预算为 12。这个例子的重点不是 12 这个数字，而是“上限”“验证后结果”和“业务成本”是三个不同量。

何时增加尝试不会划算

当样本高度相关时，多个候选可能重复同一种错误；当验证器只比随机选择略好时，增加候选只会给选择器更多噪声；当失败代价很高时，概率上界也不能替代人工确认。还要检查总延迟：8 个候选如果串行执行，墙钟时间可能是单次尝试的八倍；并行执行则要付出显存和调度成本。

把实验用于方案评审

先设定业务约束：至少 80% 可靠、P95 不超过 5 秒、每次请求最多 15 个成本单位。然后把参数扫一遍，找出满足约束的最低候选数，而不是先选一个很大的采样数再解释成本。若没有任何配置满足，结论应是“需要更好的模型、验证器或人工流程”，而不是继续增加重试。

样本相关性与失败模式

实验假设候选之间独立，这是最乐观的情况。真实模型在相同提示下经常重复同一条推理路径，尤其是提示有强烈格式约束、知识缺失或采样温度较低时。此时增加 attempts 只会让成本上升，而 best-of-N 的实际收益接近零。改进方法是提高采样多样性、改变提示视角、引入工具或外部检索，而不是机械增加次数。

验证器也可能出现两类错误：把错误答案判为正确（假阳性）和把正确答案判为错误（假阴性）。假阳性对用户体验最危险，因为它让系统更自信；假阴性会浪费候选并降低有效样本数。实验的“验证后可靠率”可以看作上限提示，实际部署应单独测量验证器在目标任务上的混淆矩阵。

如何把实验用于面试

解释这个模型时，先明确假设，再算一个可手算的例子，最后指出假设何时失效。不要只说“best-of-N 很强”，也不要把概率模型说成真实模型性能。更好的回答是：我会先测单次成功率、错误相关性和验证器精度，再根据截止期与单位经济性选择候选数；如果验证器不可靠，就降低自动化程度或改用可执行测试。

把实验的输出写进报告时，至少附上任务描述、样本规模、验证器来源、候选相关性估计和成本单位。缺少这些条件，任何“可靠率提升”都无法被别人复核。预算模型的用途是让团队讨论约束，而不是替代真实评测。

若把单次成本换成真实价格，要注意输入 token、输出 token、验证调用和重试可能分别计价。实验用一个统一成本单位是为了比较策略，不是给出账单。实际决策应把最坏请求和 P95 请求都算进去，否则一个价格很低但长尾极重的配置会误导预算。

推理预算还应有名额和并发限制。多个用户同时触发高预算任务时，服务可能因为排队而超过截止期；设置每租户的候选额度、队列优先级和降级阈值，比单纯限制单次尝试数更能保护整体体验。

这些限制应在上线前用压测验证，而不是只写在配置注释里。

预算模型、观测数据和降级策略三者齐全时，增加推理计算才会成为可控的工程选择。

否则，更多“思考”只是把成本和不确定性推给用户。

好的推理预算应当让每一次额外尝试都能解释它降低了哪一种失败概率。

无法解释的尝试不值得计入预算。

预算表应该让这个判断一目了然。