同一个模型回答一道难题，可以只生成一次，也可以生成多份候选，再比较、验证和重写。后者在模型训练结束以后多花了计算，这类做法常被称为测试时计算，也有人叫它推理时计算或 test-time compute。
我看了两篇研究测试时计算的论文。一篇分析怎样按题目难度分配预算，另一篇研究只靠黑盒模型生成与比较多个候选。它们共同说明，多算几次有机会提高正确率，可收益取决于题目、生成方法和选择答案的办法。
计算可以花在两个地方
第一种办法让模型沿一条回答继续推理、检查和修正。第二种办法并行生成多份答案，再由验证器或另一次模型调用挑选。候选越多，至少产生一份正确答案的机会可能增加，最后的选择器也必须认得正确答案。选择器判断不稳，多生成只会多出一堆待选文本。
研究者还会用过程奖励模型检查中间步骤。它能给推理过程提供更细的信号，却需要额外训练或标注。没有专用验证器时，可以让黑盒模型比较候选。2024 年的一篇论文设计了淘汰赛式比较，候选两两判断后留下一个答案，也分析了按平均胜率选择的联赛式办法。
这些设计带来的成本很直接。生成八份候选通常比生成一份消耗更多 token 和算力，串行检查还会延长等待时间。在线客服问营业时间，很少值得走多轮搜索。复杂代码、数学题或高价值分析可以多花预算，因为一次错误的后果和人工复查成本更高。
简单题和难题不能吃同一份预算
Snell 等人的研究发现，测试时计算方法的效果会随题目难度变化。研究中的自适应分配比固定的 best-of-N 基线提高了四倍以上的计算效率。在一部分小模型已经有一定成功率的问题上，小模型配合测试时计算还能超过参数量大十四倍的模型。
这组结果有明确边界。它来自特定模型、数学数据和计算匹配实验，不能直接推成所有文字任务的采购结论。模型对问题完全不会时，反复生成可能只是在重复同类错误。问题太简单时，额外搜索也没有多少可提高的空间。
企业做测试时计算，先给真实题目分组。确定答案能由程序验证的任务，可以生成几份候选后运行测试或规则检查。开放写作更适合少量候选加人工选择。每一组都记录正确率、首个 token 等待、总耗时和 token 成本，再决定何时追加预算。
路由规则也应允许及时停下。第一份答案已经通过确定性检查，就不用凑满八份。多份候选高度相同，继续生成的收益通常很小。系统可以把省下的计算留给失败样本，也可以直接请求人工处理。
测试时计算给模型多一次尝试，却没有把验证问题消掉。最实用的落点是把预算写进评测。哪类题多算以后真有改善，改善一分要多等多久、多花多少，再由这些记录决定上线范围。