在实际跑大模型应用时，很多人会碰到一个很奇怪的现象：同一个问题，模型这次答得不错，下次换个说法，或者只是随机种子变了一下，输出就明显变差。你以为是模型逻辑不行，于是去换更大的基座模型，结果成本翻了几倍，效果提升却有限。还有人试图用微调把模型“教明白”，但训练数据整理、算力开销、版本迭代的维护压力，又让不少团队直接劝退。
那有没有一种办法，不碰权重、不重新训练，只靠推理阶段多做几步，就能让模型表现得明显更稳？
斯坦福 CS329A 第二讲《自我改进 AI 智能体》里，有一个模块专门讲“测试时计算（Test-Time Computation）”。这个概念这几年被反复提起，但在实际应用里，很多人理解得其实不一致。有人把它等同于“让模型多回答几次再投票”，有人觉得这就是“长思维链”，还有人以为它是某种新的采样算法。这些说法都不算完整。
这一讲的真正核心判断是：测试时计算的本质，不是在推理阶段盲目增加计算量，而是把“计算资源”系统地转化为“答案可信度”，通过并行采样和验证机制，让模型在没有训练信号的情况下完成自我改进。
这篇文章会围绕这个判断展开，把测试时计算到底是什么、它和训练阶段优化的边界在哪、并行采样和验证分别解决什么问题，以及落到实际项目里你该怎么设计流程、怎么排查问题，一次讲清楚。
1. 先搞清楚测试时计算到底补的是哪块短板
1.1 训练阶段已经决定了模型能力的上限，测试时计算改变的是“提取能力”的效率
先做一个不太严谨但很有助于理解的类比。
模型训练就像培养一个知识储备很丰富、但临场发挥不稳定的员工。权重是这位员工长期学习积累下来的知识库。微调和继续预训练，等于把员工送出去再进修、再培训，目的是提升他的知识上限。
但真实工作场景里，员工的表现不完全等于他的知识上限。同样一个问题，他状态好时能给出条理清晰的回答；状态不好、问题表述模糊、或者压力很大时，给出的答案就粗糙得多。
测试时计算做的不是再培训，而是在他临场作答时，多给他几轮思考、几次检查、多种思路的尝试空间。同样是这个员工，当他被要求“先别急着回答，多列几种方案，再自己检查一下哪个最合理”时，输出质量自然会提升。
这个类比能解释一个非常关键的认知：测试时计算不会让模型知道它本来不知道的知识，但它能让模型把已经存在于权重里的能力更充分、更稳定地调动出来。
所以，当你发现模型输出质量差，第一反应不应该是“我要不要重新训练它”，而应该是“这个能力模型其实已经具备，我能不能通过推理阶段的手段把它提取得更充分”。
这个判断很重要，因为训练和推理的成本结构完全不同。训练模型需要准备数据、租用训练集群、处理分布式通信、做评估和回归测试，一个版本迭代的周期常常按周甚至按月计算。测试时计算则是在每次推理时动态分配更多计算量，成本是线性的、可控的、可以按任务需求调节的。
1.2 为什么“无训练”也能产生自我改进
“无需训练让 AI 更强”这个描述，听起来有些反直觉。因为过去几年大家习惯的逻辑是：能力不够，就用更多数据训练；效果不好，就微调；场景不对，就做 RLHF。
但实际上，自我改进不完全只发生在权重更新过程中。它还可以发生在推理阶段。
当一个模型对同一个问题生成多个候选答案，再通过某种验证机制从这些候选中选出最优解时，这个“选优”的过程本身，就是一个自我改进的行为。模型初次的单次输出，可能只有 60 分的可信度；通过并行采样生成 8 个候选，再用验证器挑出 92 分的结果，这中间的提升不是来自新知识，而是来自“更多尝试 + 更好选择”。
这一点，在代码生成和数学推理任务里尤其突出。编程代码的正确性是可以用编译、测试用例、静态检查来验证的；数学题的答案是可以重新代入检查的。这类任务天然具备“外部验证”条件，所以测试时计算的效果会特别明显。
理解了这条链路，你就能明白：测试时计算不是某种神秘技巧，它就是把“生成-验证-选择”这套人类解决问题的基本方法论，植入到模型推理流程里。
2. 并行采样：不是简单跑好几次，而是让“搜索”发生在答案空间里
2.1 并行采样的本质是有限预算下的答案分布探索
很多人把并行采样理解成“让模型多回答几次，选一个看起来最好的”。这个理解方向是对的，但少了两个重要细节。
第一个细节是，并行采样的价值不在于“多”，而在于“多样性”。
假设你用一个温度为 0 的配置让模型跑 10 次，这 10 次大概率会产出几乎完全相同的答案，因为温度为 0 时采样是确定性的，模型每次都选概率最高的那个 token。这种情况下，并行采样没有任何意义，它只是重复了 10 次相同结果。
真正有效的并行采样，需要你调整 temperature、top_p 等采样参数，让模型在每次生成时走不同的概率路径。这样，10 次采样才能覆盖答案空间中不同的区域。有的候选答案可能来自更保守的推理路径，有的候选答案可能来自更跳跃的思路。
第二个细节是，并行采样本质上是一种搜索。
你可以把答案空间想象成一片地形，正确答案是隐藏在某个位置的高分区域。单次生成，相当于随机选一个起点，沿着一条路径向下走。如果运气不好，走到一个局部高点就停下来了，这个局部高点可能只是个看起来合理的错误答案。
并行采样，相当于同时派出多个探索者，从不同起点、不同路径去搜索。然后，你再通过验证机制判断谁是真正的最高点。这就是为什么它会被纳入“自我改进 AI 智能体”的范畴——因为智能体不止要能生成，还要能在多个可能性中做出判断和选择。
2.2 Learn to Search：不断试错、验证、回溯的过程本身就是智能
CS329A 这门课在讲测试时计算时，反复出现的一个词是“search”。这里的 search 不是搜索引擎那个 search，而是指模型在推理过程中，能够根据中间结果不断调整后续步骤。
一个不具备搜索能力的模型，会沿着一条固定的推理路径一路走到黑。哪怕中间某一步已经出现明显错误（比如数学推导中的符号写错、代码中变量命名不一致），它也不会停下来修正，而是继续基于错误前提往下算。
具备搜索能力的模型，或者说配合了测试时计算的系统，可以在生成多个候选路径之后，对中间步骤进行验证。发现某条路径的第 3 步有问题，就放弃这条路，回到第 2 步重新选方向。这就像人做题时发现算不下去，会回头检查是不是前面某一步推导错了，而不是硬撑着把错误答案写完。
所以，测试时计算真正改变的东西，不是一个模型的单次生成质量，而是整个推理过程的容错能力。它允许模型犯错，但通过验证和回溯，把错误的代价控制在推理阶段，而不是让错误直接变成最终答案。
2.3 实际采样配置：从单条输出到候选池的工程落地
在实际工程项目里，并行采样并不是简单地改一个参数就完事。它涉及几个关键决策：
- 候选数量 N：你到底让模型生成多少个候选答案？
- 采样温度 T：温度太低，候选之间差异太小；温度太高，候选可能变得杂乱无章。
- 输出长度限制：每一条候选路径允许生成多少 token。
- 批量执行方式：是顺序循环跑 N 次，还是用支持并发请求的推理框架一次发出去。
从工程实践看，我更建议先保守起步。如果你当前单次推理质量已经基本可用，那可以先用 N = 4，采样温度在 0.7 到 0.9 之间做一轮候选池。观察候选答案之间的差异程度，以及验证器的选优是否稳定。
如果 N = 4 的提升已经很明显，不必急着加码。因为采样数量增加带来的收益是边际递减的。N = 4 到 N = 8 通常能带来较明显增益，但 N = 16 到 N = 32 的额外提升，可能还不如你把验证器做得更准一点来得有效。
注意：并行采样不是免费午餐。每增加一个候选，推理成本就乘以 N。在做收益评估时，要把“采样N次 + 验证选最优”的总成本，和“单次生成但使用更强模型”的成本放在一起比较。
3. 验证器才是测试时计算的胜负手
3.1 没有验证的并行采样，只是把错误答案合集变大了
并行采样解决了“模型想不到更好答案”的问题，但它也制造了一个新问题：多个候选答案里，到底哪个才是对的？
如果只是把候选答案堆在一起让用户自己挑，那这个方案基本没有实用价值，因为用户并不具备判断所有候选答案的能力，否则他们自己就能解题了，不需要模型。
所以，测试时计算一定要有一个验证环节。这个验证环节可以很轻量，也可以很复杂，完全取决于任务类型。
在代码生成任务里，最简单的验证方式是单元测试。你让模型生成多个版本的函数实现，然后跑预先写好的测试用例，通过的保留，不通过的淘汰。
在数学题任务里，验证方式可以是把答案代入原题做逆运算，或者用另一个模型对推理步骤进行逐行检查。
在开放式的文本生成任务里，验证会更难做。因为没有一个绝对标准判断“这段话是更好的”，你只能借助另一条模型策略、人工评分、或者一组规则来评估候选质量。
3.2 Self-Consistency：不训练额外模型的轻量验证思路
如果不想额外训练一个奖励模型，一个非常实用的验证思路是 Self-Consistency，也就是多数投票。
它的逻辑很朴素：如果模型多次独立采样，大多数路径最后都收敛到同一个答案，那这个答案大概率是正确的。
比如让模型回答一道数学题，采样 8 次，其中 6 次都得到“42”这个答案，只有偶尔 1 到 2 次给出别的数，那你选“42”就有很强的置信度。
这个方法的优点是零额外训练成本，实现简单；缺点是它只适合答案形式比较规整、能够精确匹配的任务，比如数学运算、多项选择、直接问答。对于开放式写作、方案设计这类没有标准答案的任务，Self-Consistency 的适用范围就明显变窄。
在动手做验证方案之前，先想清楚一个前提：你的任务里，能不能定义“相对正确答案”？如果能，验证器可以走规则或测试之路；如果不能，你就要额外考虑人工筛选、偏好模型或设计多维评分策略。
3.3 训练一个验证器，为什么往往比继续调生成模型更划算
还有一种更系统化的做法：单独训练一个验证器（Verifier），它不负责生成答案，只负责给候选答案打分。
这和你训练生成模型的区别在于：生成模型要学习整个答案的分布，模型容量被大量浪费在“如何生成流畅但未必正确的内容”上。验证器只需要判断“这个答案好不好”，输出一个标量分数，或者一个“可行/不可行”的判断，学习目标更集中，也更容易拟合。
投影到一个实际场景：你做一个代码生成工具，如果用生成模型从文本描述直接写代码，模型要学习语法、库调用、逻辑组合等大量知识；但如果你训练一个验证器来判断“这段代码能否通过测试”，它只需要学习正确代码的特征和错误代码的差异，任务边界清晰得多。
所以，在很多任务里，你与其花很大代价去提升生成模型的单次正确率，不如让生成模型保持当前的探索能力（甚至故意增加它的采样多样性），再花心思训练一个高质量的验证器。这种“强生成 + 强验证”的组合，常常比“单次生成但努力调优”的路线提升更明显。
4. 在真实项目里，测试时计算该怎么落地
4.1 先判断你的任务是否具备“可验证性”
测试时计算不是万能的，它的效果上限和任务的“可验证性”高度相关。
我建议你先给任务做一个分类判断：
| 任务类型 | 验证难度 | 测试时计算策略 |
|---|---|---|
| 代码生成 | 低，可用编译和测试用例验证 | 并行采样多个实现，跑测试选最优 |
| 数学/逻辑推理 | 低到中，可逆运算或规则检查 | Self-Consistency，或训练验证器 |
| 知识问答 | 中，需要对照可信来源 | 生成多个答案，按引用来源和一致性筛选 |
| 开放式写作 | 高，无唯一标准 | 慎用，建议用偏好模型或人工评分 |
| 方案设计 | 高，需要结合约束条件判断 | 先拆解约束，再局部验证分支步骤 |
如果你的任务属于下面几行，那并行采样和验证的价值会打折。你更需要个性化偏好建模、检索增强、或者人工介入的编辑环节。
4.2 最小可用的测试时计算流程
用一个实际项目举例子。假设你正在做一个“自然语言生成 SQL 查询”的工具，目标是让大模型把用户问题转成可执行的 SQL。
你可以设计这样一个最小流程：
- 输入用户问题后，让模型并行采样 5 个候选 SQL，temperature 设为 0.8。
- 写一个基础语法校验脚本，把 5 个候选 SQL 依次解析，淘汰语法错误的。
- 用一个本地测试数据库，把剩余候选 SQL 在预置的表结构上执行一遍。
- 给每个能成功执行的 SQL 做结果对比：有的 SQL 查出来的行数和预期不一致，有的字段选错，有的 JOIN 条件漏了，按结果命中度排序。
- 如果前几名 SQL 的结果一致，就选择结果置信度最高的；如果候选之间差异很大，则触发一轮追问式交互，让用户确认意图。
这个流程里，并行采样负责扩大搜索范围，语法校验和测试执行负责验证，排序规则负责选择。每一步都有明确输入输出，可以独立排查。
4.3 常见失败模式与排查链路
实际用起来，你大概率会遇到几种失败模式。不要急着怀疑并行采样没用，先按链路排查：
**第一层：检查候选多样性。**如果你发现采样 5 次的结果几乎一模一样，问题大概率不在验证器，而在采样配置。把 temperature 调高到 0.8 到 1.0，确认 top_p 不是被设成了 1 且没有任何随机性。有些推理框架默认开了缓存，或者你忘了把 do_sample 打开，会导致多次请求返回相同结果。
**第二层：检查验证标准是否合理。**验证器的评分标准如果定义得太模糊，选出来的“最优答案”可能只是“看起来最顺眼”的答案，而不是真正正确的答案。代码任务就看编译和测试结果，不要加入太多风格偏好；数学任务就看答案是否能对上标准结果的等价形式。
**第三层：检查成本收益比。**如果 N = 8 的候选池已经把推理延迟从 1 秒拉到 6 秒，而准确率只从 78% 涨到 81%，你要判断这 3 个点的增益是否值得。很多时候，把延迟做小、做可控，比一味提高单次准确率对产品体验更重要。
**第四层：检查任务边界。**有些问题本身就没有唯一正确答案，比如“请为这个新产品写一句广告语”。这类任务即使并行采样 100 次，也不可能通过验证选出“最优”，因为最优是主观的、面向受众的。这种情况就不要生搬测试时计算，可以改用人工多选一、A/B 测试这类外部反馈机制。
排查顺序永远是：先看输入和采样配置是否生效，再看验证标准是否可靠，最后才怀疑方案本身不适用。
5. 测试时计算能走多远：从单次推理到智能体工作流
5.1 单次任务里的测试时计算，只是起点
我们在前面讨论的，大多是“单轮生成多个候选 + 验证选择”的模式。这个模式已经能解决很多问题，但它仍然有一个明显的限制：每个候选路径都是独立生成的，路径之间没有交互。
更接近“自我改进智能体”的用法，是把测试时计算嵌入到一个更大的循环里：模型生成候选方案 → 执行或模拟 → 观察结果 → 更新下一步策略 → 继续生成。
这也正是“智能体”和“普通模型调用”的区别。普通模型调用是一次性的：输入进去，输出出来，结束。智能体则是在多步决策中，根据每一步的执行反馈动态调整计划。测试时计算在这里扮演的角色，就是每一轮决策里的“多想几步”和“多试几个方向”。
5.2 从“并行”到“串行”：推理深度的另一种测试时计算
并行采样是用宽度换质量，那么串行思考就是深度换质量。
像让模型先把问题拆解成子问题，按顺序解决，每解决完一个子问题暂停一下，检查结果是否正确，再进入下一个子问题。这个过程也可以看作测试时计算的一部分，因为它消耗的是推理阶段的计算资源，而不是训练阶段。
所以，当你听到“测试时计算”时，不应该只想到诸如并行采样或多数投票这类策略。它实际上包含两种基本范式：
- 增加搜索宽度：多个候选并行生成，再选择。
- 增加搜索深度：沿着一条推理路径做多步验证、回溯、推导。
在实际系统里，这两种范式经常结合使用。一个智能体处理复杂任务时，既有每一步的多种方案选择（并行），也有逐步推进、反复验证的流程控制（串行）。
5.3 这会给模型应用开发带来什么变化
过去我们做一个 AI 产品，核心手艺集中在“如何选模型、如何写提示词、如何准备上下文”。现在，一个明显的趋势是：大量注意力开始转向“如何设计推理流程”。
你要考虑的从“哪个模型回答得最好”变成“怎么让模型在多个尝试里挑出最好的答案”“怎么设计验证规则”“怎么在成本和效果之间做动态折衷”。
这是一种思维方式的迁移：
- 原来：模型是单向输出的黑盒，我们只能调输入。
- 现在：模型是可以反复询问、多轮试错、被验证的组件，我们开始设计它的工作过程。
对个人开发者来说，这意味着你不必拥有最强大的模型，也能借助测试时计算冲高不少实际效果。对团队来说，这意味着一套高质量验证集的长期价值，可能会高于你在某个基座模型上的调优投入。
长期看，谁掌握了更高效的“生成-验证”循环，谁就能在同样模型成本下获得更好的输出质量。这不是模型能力的竞争，而是推理时系统设计的竞争。
6. 什么时候该用它，什么时候不该用
6.1 适合测试时计算的三个特征
一个任务是否适合用测试时计算，可以从三个特征来判断：
特征一：存在明确的对错标准。
比如代码能否通过测试、数学题的结果是否正确、SQL 是否从库里查出符合条件的数据。对错越明确，验证器越容易构建，测试时计算的效果越可预期。
特征二：单一生成结果不够稳定。
如果模型在同一个问题上，温度和采样参数稍微变化，就会产生不同质量的结果，说明它的单次采样稳定性偏低。这时候通过多次采样和选优，就特别有修复价值。
特征三：验证成本低于生成成本。
算一笔账：生成 8 个候选答案，每个消耗 1000 个 token，这就是 8000 个 token 的生成成本。如果验证只需要三四个轻量测试函数或一次规则匹配，成本远低于继续生成，那这个方案就非常划算。如果验证本身需要动用另一套昂贵的大模型，那就要调研清楚整体收益。
6.2 不适合的三种情况
反过来，以下三种情况不要硬套：
情况一：低延迟交互场景。
比如实时对话、语音助手、在线搜索等场景，用户等待时间以百毫秒计。并行采样 N 次会直接乘 N 倍延迟，如果又没法并发，体验会崩。这类场景更适合降低采样数量、缩短思维链长度，或者把候选生成放到后台异步处理。
情况二：开放式创造任务。
广告创意、文案写作、故事创作，这些任务好坏标准因人和场景而异。验证器很难建模“用户是否喜欢”这个模糊目标。强行采样多数投票，会让结果趋向平庸，失去创造力。
情况三：你没有验证依据，也不想引入人工。
如果没有测试用例、没有标准答案、没有奖励模型、没有后续人工评分，那你做并行采样后，只能靠模型自己说“我觉得这个答案好”，这种自我评估在事实性任务上并不可靠。这种情况下，先老老实实加强生成模型的基础能力，或者引入外部检索，可能更有效。
6.3 从最小实验开始，不要一次做到工程极限
最后给一条最实际的建议：不要一上来就搭建复杂的“多模型验证 + 强化学习 + 动态预算调节”系统。那是大团队的工程目标，不是你应该从第一天就开始做的事。
你可以先把一个最小的测试时计算流程跑通：
- 找出一道让模型频繁出错的题，最好它具备明确可验证性。
- 手动写一个验证规则，比如“答案是否等于 xxx”“代码能否通过这 3 条测试”。
- 让模型并行采样 5 个答案，跑验证规则，看看选出的答案是否真的比单次输出更好。
- 记录下：正确率提升了多少？成本和延迟增加了多少？哪些错误是验证器没有拦住的？
跑完这四步，你就会对“测试时计算”这个概念产生真实的体感，而不是停留在“它有潜力”这个模糊判断上。
把这套流程反复应用到更多问题上，慢慢你会发现一个更本质的变化：你不再把大模型当成一个“你问它答”的接口，而是把它当成了一个可以反复协商、多路探索、可被校验的智能组件。这个认知转变，才是测试时计算真正带给你和团队算力之外的长期回报。
