第4章 推理期扩展

推理时怎样释放或放大能力？

第3章可以把模型塑造成更守指令的协作组件，却不能保证它在复杂问题中一次生成就走对路径。大模型的“推理”不是一个单独的神经网络模块，而是模型、提示、搜索、验证器和推理预算共同形成的过程。自回归模型每次只预测下一个 token，但复杂任务需要先拆解问题、保留中间状态、比较候选路径、检查结果，再决定是否继续。于是，推理算法要回答两个问题：如何从概率分布中生成更好的轨迹，如何用额外计算换取更高的任务成功率。

本章的判断是：推理期扩展以时间、token 和验证成本交换复杂任务成功率；它提升的是候选答案质量，而不是替代事实来源、权限控制或 Serving 可靠性。后训练改变默认行为，推理期扩展决定当前任务如何使用计算，两者必须在任务可验证性和预算约束下协同选择。

本章把“推理能力”和“推理服务”分开。采样、解码、CoT、Self-Consistency、Tree of Thoughts、验证器、RLVR、test-time scaling 和 speculative decoding 属于算法层；GPU 显存、KV cache 分页、continuous batching 和分布式 serving 属于后续 Infra 章节。本章会说明两者的接口，但不把系统吞吐优化冒充模型推理能力。

4.1 历史发展：从一次生成到搜索式推理

自回归生成的基本范式

给定输入 (x)，语言模型定义一个条件分布：

$$ P(y\mid x)=\prod_{t=1}^{T}P(y_t\mid x,y_{<t}). $$

最初的生成系统通常只取最大概率 token，或者用 beam search 在有限候选中寻找高概率序列。GPT-3 展示了模型可以通过上下文示例执行多种任务 [1]，但也暴露了一个事实：单次 greedy 生成的局部最优，不一定对应全局正确答案。模型可能在早期选错一个前提，后续所有 token 都流畅地围绕错误继续。

CoT 与验证式推理

Chain-of-Thought 通过示范中间步骤，让模型把复杂答案展开成一串可观察的推理文本 [2]。Zero-shot CoT 进一步发现，简单的“逐步思考”提示也能诱导某些模型生成中间过程 [3]。Self-Consistency 不再只取一条思路，而是独立采样多条推理轨迹，再对最终答案做多数投票 [4]。这解决了单次采样偶然失败的问题，但成本随样本数增加。

随后出现了显式搜索、工具调用和验证器：Tree of Thoughts 把中间思路组织成可回溯的树 [5]，Graph of Thoughts 允许不同思路合并和循环 [6]，ReAct 把推理与行动交替连接到外部环境 [7]。在数学、代码和形式化任务中，结果验证器和过程验证器让“好思路”不再完全依赖主观评价 [9][10]。

Test-time Scaling 成为新杠杆

传统规模化主要增加参数和训练 token，reasoning model 则在推理时增加计算预算。模型可以生成更多 reasoning token、采样多个候选、调用验证器、进行搜索或重试。OpenAI 的 reasoning 系列将“思考时间”作为可调资源公开讨论 [12]；DeepSeek-R1 把强化学习与可验证奖励结合，展示了模型通过更长推理和自我反思提升数学、代码等任务的路线 [13]。

Test-time scaling 的关键不是“思考越长越好”，而是把预算分配给有价值的分支。Snell 等人的研究指出，在一定条件下，合理增加推理时计算可能比增加模型参数更有效 [11]。新限制也随之出现：推理成本、延迟、错误累积、验证器漏洞和停止条件，成为算法与产品必须共同设计的对象。

4.2 生成分布与采样：模型如何选择下一个 token

Logits、softmax 与温度

模型在每一步输出词表大小的 logits (z_i)。温度采样先把 logits 除以 (\tau)，再计算：

$$ p_i=\frac{\exp(z_i/\tau)}{\sum_j\exp(z_j/\tau)}. $$

当 (\tau<1) 时，概率分布更尖锐，输出稳定但可能重复；当 (\tau>1) 时，低概率 token 获得更多机会，输出更有多样性但错误率可能上升。温度不是“创造力旋钮”这么简单，它改变的是整个生成分布，可能影响事实、格式、代码和安全边界。

采样实现还要处理数值稳定性，通常先减去最大 logit 再做 softmax；低温下要避免概率下溢，高温下要避免尾部噪声占据过多质量。中文、代码和结构化输出的 token 分布不同，不能用一套参数覆盖所有任务。

Greedy、Top-k 与 Top-p

Greedy 每步选择最高概率 token，确定性强，适合部分代码补全和固定格式，但容易陷入重复或早期错误。Top-k 只保留概率最高的 k 个 token，在有限候选中采样；k 太小接近贪心，k 太大又会引入低质量尾部。Top-p，也称 nucleus sampling，保留累计概率达到 p 的最小 token 集合，候选数量随分布形状动态变化 [19]。

Top-p 适合语言模型概率分布变化较大的自然语言生成，但不是质量保证。一个错误前提可能拥有很高概率，top-p 只会在错误附近增加多样性。代码、SQL、JSON 和函数调用最好结合语法约束、schema 或验证器；单纯调低 temperature 不能把不可靠输出变成可靠输出。

Repetition penalty 与 Unlikelihood

重复可能来自高概率 token 的自强化：模型生成一个短语后，历史上下文使同一短语继续变得可能。repetition penalty 在解码时降低已经出现 token 的分数，简单有效，但可能误伤合法重复，例如代码中的变量名或诗歌中的韵脚。Unlikelihood training 从训练目标出发，显式惩罚不希望出现的候选，尝试让模型减少重复模式 [27]。

推理时还可以限制重复 n-gram、设置最小长度、引入 stop sequence 或使用语法约束。每种方法都可能产生副作用：过强惩罚会让模型刻意换词、破坏术语一致性或生成不自然文本。应该用真实任务的重复率、正确率和格式通过率共同评估。

任务化采样配置

采样参数应纳入版本管理和评估记录。模型版本相同，只改变 temperature、top-p 或 stop 条件，也可能造成明显的行为变化。

4.3 解码算法：从局部选择到候选搜索

Beam Search 与长度偏差

Beam search 每一步保留概率最高的 B 条前缀，扩展后再裁剪。它比 greedy 能探索更多路径，但自回归概率倾向偏爱短序列：每增加一个 token 就乘以一个小于 1 的概率。实际系统常使用长度归一化或长度惩罚，但惩罚过强会生成冗长答案。

Beam search 在机器翻译等条件生成任务中有历史价值，但在开放式聊天中不一定优于采样。模型的概率高低未必等于人类偏好，beam 可能产生安全、流畅但空泛的候选。解码算法必须与训练目标匹配，不能假设最大 likelihood 就是最佳任务答案。

Constrained Decoding

结构化生成可以通过有限状态机、上下文无关文法、JSON schema 或词表屏蔽限制候选 token。每一步只允许仍然可能形成合法输出的 token，能显著提高 JSON 和函数参数的解析成功率。它解决的是语法正确性，不解决字段值正确性；一个结构合法的 SQL 仍然可能查错表，一个字段类型正确的 API 调用仍然可能越权。

约束解码要处理 tokenizer 边界、Unicode、转义、空白、停止条件和流式输出。schema 版本变化后，旧约束不能继续复用。生产系统应在模型输出之后再次解析和校验，不能把解码器视为唯一防线。

Speculative Decoding

投机解码用一个较小的 draft model 先生成连续候选，再由 target model 一次验证多个 token。若 target 接受候选，就减少逐 token 的大模型调用；若在某个位置拒绝，就从 target 的校正分布继续生成。Leviathan 等人的方法给出了在保持目标分布的条件下加速自回归解码的框架 [21]；speculative sampling 进一步讨论了随机采样下的接受与修正 [22]。

关键条件是 draft 与 target 足够相似，且验证多个 token 的并行计算成本低于逐 token 生成。接受率低时，draft 只增加开销；draft 太大时，节省的成本又会消失。速度收益还受 batch、上下文长度、GPU kernel 和传输影响，因此要用真实请求分布测量，而不是只看理论接受率。

Speculative decoding 改善的是生成速度，不自动改善答案质量。严格的接受—修正算法可以保持 target 分布，但如果 target 本身错误，最终仍然错误。工程上需要同时监控接受率、tokens/s、TTFT、TPOT、显存和输出一致性。

Blockwise 与并行预测

Blockwise parallel decoding 让模型尝试一次预测一个 token block，再用后续计算验证，目标是减少串行深度 [23]。这类方法与 speculative decoding 有相似目标，但候选产生方式、模型结构和验证过程不同。它们的共同限制是：自回归依赖仍然存在，真正可并行的部分取决于候选正确率和验证成本。

4.4 Chain-of-Thought 与分解式推理

CoT 解决什么问题

直接让模型从问题跳到答案，容易在多步任务中丢失中间变量。CoT 通过显式生成中间步骤，把一个长映射拆成多个局部映射：理解题意、列出条件、执行运算、检查结论。Wei 等人的实验显示，足够大的模型在提供推理示范后，复杂算术、常识和符号任务的性能明显提高 [2]。

从算法角度看，CoT 增加了计算轨迹和可利用的中间状态；从工程角度看，它增加了 token 成本和泄露风险。输出的“思考过程”也不一定是模型真实的因果过程，可能是事后合理化。Huang 等人讨论了 CoT 的可解释性与推理过程问题，提醒不能把可读的步骤直接当作忠实解释 [16]。

Zero-shot CoT 与提示设计

“逐步思考”一类的提示可以在没有任务专用示范时诱导分步推理 [3]。但效果依赖模型规模、任务类型、语言和提示位置。对代码、数学和规划任务，提示可以明确要求先列约束、再生成候选、最后检查；对敏感任务，不应要求模型公开所有内部思考，而应要求输出可审计的结论、依据和验证状态。

好的分解不是把答案机械拆成更多句子。它应减少依赖、暴露可验证中间量、允许失败后回溯。例如 SQL Agent 可以先识别实体和权限，再生成查询，执行只读检查后返回结果；代码 Agent 可以先列修改文件和测试，再生成 patch，运行测试后决定是否提交。

Self-Refine 与迭代修正

Self-Refine 让模型先生成答案，再根据反馈批评和改写，多轮迭代改善输出 [26]。它适合错误可以被规则、测试或明确 rubric 发现的任务。没有独立反馈时，模型可能只是重复自己的偏差；迭代次数太多还会造成答案漂移和成本爆炸。

反馈应尽量具体：指出代码哪项测试失败、数学哪一步不成立、JSON 哪个字段非法、事实缺少哪条证据。泛泛地要求“请改得更好”只能改变风格，不能保证正确性。迭代停止条件应由错误是否消失、验证器是否通过和预算是否耗尽共同决定。

4.5 Self-Consistency、搜索与思路图

多轨迹采样

Self-Consistency 对同一问题采样多条 CoT，再聚合最终答案 [4]。如果不同轨迹独立地走向同一个结果，结果可信度通常提高；如果轨迹高度相关，多数投票只是重复同一个错误。采样温度、轨迹数量、答案规范化和投票规则都会影响效果。

聚合不能总是使用字符串多数票。数学答案需要解析等价表达式，代码需要执行测试，开放问答需要 judge 或证据检索。可以把每条轨迹映射为 ((answer, evidence, cost))，先过滤验证失败的轨迹，再按答案聚合。这样“多数”建立在可接受候选集合上，而不是所有文本一视同仁。

Tree of Thoughts

Tree of Thoughts 把推理看成搜索：在每个状态生成若干思路，使用评估器筛选 promising 分支，继续扩展或回溯 [5]。它适合需要规划、组合搜索或中间状态可评价的任务，例如数值游戏、路线安排和多步证明。搜索策略可以是 breadth-first、depth-first、best-first 或 beam-like pruning。

树搜索的难点是状态表示和启发式评估。状态太粗，无法区分不同前提；状态太长，评估成本高；启发式不准，搜索会把预算花在错误分支；分支太多，组合爆炸。实际系统通常需要限制深度、宽度、每步 token、总 verifier 次数和超时，并保存可回放轨迹。

Graph of Thoughts 与共享中间结果

某些推理任务不是树，而是多个思路可以合并、比较和循环。Graph of Thoughts 允许把生成的思路作为图节点，执行聚合、变换和反馈 [6]。例如多个候选计划可以先各自提出，再让模型抽取共同约束，形成一个更稳的综合计划。

图结构的收益是复用中间结论，代价是状态一致性和循环检测。若一个错误结论被多个分支共享，错误影响面会扩大；若节点没有版本和来源，无法知道综合答案依赖哪条路径。工程上应给每个节点记录输入、生成模型、验证结果和依赖关系，把推理图当作可审计的 DAG 或状态机。

4.6 验证器、奖励与推理可靠性

结果验证器

结果验证器只判断最终结果是否满足条件。代码题可以运行隐藏测试，数学题可以检查数值或符号答案，SQL 可以在只读数据库比较结果，规划任务可以检查环境状态。Cobbe 等人的研究展示了训练 verifier 来区分数学答案的路线 [9]。

结果验证的优点是信号清晰、成本可控；缺点是不能解释中间过程，也可能存在测试盲区。一个能通过不完整单元测试的代码不一定正确，一个答案数值正确的推导不一定逻辑有效。验证器的覆盖率、误报率和版本必须纳入模型评估。

过程验证器

过程奖励模型在每个推理步骤上给分，帮助模型学习哪些中间状态更可靠。Let’s Verify Step by Step 说明逐步验证可以改善数学推理监督 [10]。过程监督能缓解最终结果的信用分配问题，但标注和建模成本更高，还可能奖励形式正确但语义无效的“看起来像推理”。

结果奖励与过程奖励可以结合：过程分用于引导搜索，最终验证用于发布门禁；如果两者冲突，以可验证结果和任务约束为准。任何 reward 都是代理，必须通过独立测试防止模型学习评估器漏洞。

幻觉检测与一致性

SelfCheckGPT 利用多个采样结果之间的一致性，检测事实陈述可能存在的幻觉 [17]。如果相同问题的独立样本对一个事实说法差异很大，说明模型内部不确定；但一致性不代表真实，一个模型可以稳定重复错误。幻觉研究还区分事实错误、无依据生成、上下文冲突和指令偏离 [18]。

更可靠的做法是让模型引用检索证据、调用事实工具或通过程序检查，并把“不确定”作为合法输出。采样一致性可以作为风险信号，不能单独作为事实验证器。高风险领域要把证据来源、时间、权限和版本纳入判定。

搜索复杂度与剪枝策略

如果每个状态扩展 (b) 个候选，搜索深度为 (d)，最坏情况下节点数为 (O(b^d))。这也是为什么“让模型多想一些”很快会变成成本问题。剪枝的目标是在不丢失高质量路径的前提下减少节点，包括保留 top-k 状态、设置上限、去除重复状态、优先扩展高价值节点，以及在验证失败时尽早停止。

剪枝器可以使用模型分数、规则分数、检索证据、程序测试和历史成功率。单一模型分数容易把流畅错误排在前面；单一规则又可能误杀创造性路径。组合评分要注意尺度校准，避免某个分数因为数值范围更大而完全支配决策。对高风险任务，宁可保留少量候选等待人工，也不能用不可解释的启发式直接丢弃所有替代路径。

状态去重也是重要优化。不同文字可能表达同一个数学答案、代码状态或计划状态；如果只按字符串去重，搜索会重复探索。可以对结构化状态做规范化，对代码运行结果做状态摘要，对答案做数学等价化。但语义去重本身可能误合并不同前提，必须保留原始轨迹和依赖信息，以便验证失败时回溯。

生成质量与搜索多样性

搜索不是候选越相似越好。若所有分支都来自同一个高概率前缀，投票和搜索只是在放大同一偏差；若候选完全随机，验证成本会很高。可以在早期使用较高温度或 diverse sampling 获取不同计划，再在后期降低温度并使用 verifier 收敛。多样性应在“不同有效策略”之间，而不是错误格式和无意义改写之间。

对代码任务，可以让候选使用不同算法或边界处理，再通过测试筛选；对数学任务，可以要求不同证明路径或不同变量消元顺序；对规划任务，可以改变资源约束和执行顺序。多样性设计必须与任务结构结合，不能简单把 temperature 调高后宣称探索更充分。

训练时推理与推理时搜索的关系

CoT 数据、过程奖励和搜索轨迹会改变模型的先验，但不意味着上线时必须暴露同样长的思考。训练可以让模型学会提出更有价值的候选，推理时再根据难度选择短答、单轨迹、少量采样或完整搜索。相反，如果训练没有学会可验证的中间结构，仅靠 runtime 反复采样可能得到更多相似错误。

因此评估应比较四种配置：基础模型单次生成、后训练模型单次生成、后训练模型加采样、后训练模型加验证或搜索。这样才能知道收益来自训练、额外计算还是验收机制。DeepSeek-R1 等工作说明强化学习可以把一部分搜索能力压进模型，但生产系统仍需要按预算和风险动态决定是否启动外部搜索 [13]。

4.7 Test-time Scaling：推理预算如何分配

预算的组成

推理预算不只是生成 token 数，还包括候选数量、搜索深度、验证次数、工具调用次数、上下文长度和 wall-clock 时间。可以把一次任务的预算写为：

$$ B=C_{tokens}+\lambda_1C_{samples}+\lambda_2C_{verify}+\lambda_3C_{tools}+\lambda_4C_{latency}. $$

不同任务的最优分配不同。简单问答增加候选没有收益；数学题可能需要多条轨迹和 verifier；代码题可能更适合少量候选加真实测试；Agent 任务需要把预算留给工具观察和重试。Snell 等人提出的 compute-optimal test-time scaling 视角，正是要寻找模型规模、样本数和验证计算之间的平衡 [11]。

何时增加模型，何时增加推理

如果错误来自知识缺失，增加推理预算通常没有帮助；如果错误来自搜索路径、算术步骤或偶然采样，增加预算可能有效；如果验证器不可靠，增加候选只会增加验证成本；如果任务本身没有可判定目标，长 CoT 可能只是生成更多解释。

可用一个小实验估计收益曲线：固定模型和提示，逐渐增加 reasoning token、候选数和 verifier 次数，记录成功率、单位成功成本、p95 延迟和失败类型。当收益曲线很快饱和时，继续扩大预算不划算；当成功率持续增长但延迟超限时，可以做路由，让简单请求走短路径、困难请求走长路径。

预算实验还要做按难度分层。平均值可能掩盖一个重要事实：简单问题不需要额外计算，困难问题却只有在某个预算阈值之后才突然成功。可以按问题长度、步骤数、工具数量、历史失败率和验证难度建立桶，分别拟合成功率曲线。这样路由器才能为不同请求选择预算，而不是把所有请求都提升到最高档。

预算也不是越多越公平。长时间搜索会占用共享 GPU 和工具配额，导致其他请求排队；无限重试可能放大一个错误状态；过多候选会增加用户等待和隐私暴露。因此多租户系统需要设置每租户 token、验证、工具和时间配额，并在资源紧张时优先保证低风险、短任务和已经接近完成的请求。

这说明 test-time scaling 既是算法问题，也是资源调度问题。算法必须显式暴露预算和停止接口，系统才能根据优先级、风险和容量做出可解释的分配。

Reasoning RL 与蒸馏

Reasoning RL 使用可验证任务奖励，让策略探索更有效的推理轨迹。DeepSeekMath 将 GRPO 与数学验证结合 [14]，DeepSeek-R1 展示了从冷启动示范到强化学习和蒸馏的组合路线 [13]。PPO 等策略优化方法提供了更通用的 RL 基础 [15]。

强化学习并不自动产生可靠推理。奖励漏洞会让模型学会投机，奖励稀疏会让训练不稳定，长轨迹会提高 credit assignment 难度。蒸馏可以把大模型的推理轨迹压缩到小模型，但如果轨迹包含错误或过度冗长，小模型也会继承这些问题。必须保留独立 verifier、基础能力回归和成本评估。

分解、层次规划与组合泛化

复杂任务通常不是“多生成几个 token”就能解决，而是需要把目标拆成相互依赖的子目标。组合性研究指出，模型可能分别会做两个简单操作，却无法稳定地把它们组合到一个新任务中 [8]。因此推理算法要显式表示任务结构：先识别对象和约束，再决定步骤顺序，最后把子结果合成为答案。

层次生成把规划和表面实现分开。高层规划先产生章节、步骤、动作或子问题，低层生成再把每个计划展开为自然语言、代码或工具参数。Hierarchical Neural Story Generation 说明，长文本生成可以先规划更高层的内容，再逐步生成细节 [20]。在代码 Agent 中，高层计划可以是“定位调用链—修改接口—补测试—运行回归”，低层模型负责每一步的具体 patch。

分解的关键是边界。子任务太大，仍然需要长链推理；子任务太小，调度和上下文开销会吞掉收益。每个子任务最好有输入契约、输出契约和完成条件。完成条件可以是一个字段完整、测试通过、数据库状态改变或 verifier 接受。没有完成条件的分解只是把一段自由文本拆成几段，不能真正降低错误传播。

搜索状态、动作与回溯

把推理过程形式化为状态 (s_t)、动作 (a_t) 和转移 (s_{t+1}=f(s_t,a_t))，可以更清楚地设计搜索器。状态包含已知事实、已完成步骤、候选答案和剩余预算；动作可以是生成下一步、调用工具、请求澄清、回退或终止；代价包含 token、时间、工具费用和风险。搜索器的目标不是最大化文本概率，而是在约束下找到成功状态。

回溯是搜索区别于普通 CoT 的重要能力。普通生成一旦写出错误前提，后续 token 通常继续围绕错误展开；搜索可以保留多个候选，在验证失败时退回最近的分叉点。回溯需要保存状态快照和依赖关系，不能简单把错误文本追加到上下文后要求模型“重新想一遍”。对于有副作用的工具，回溯还必须配合事务、幂等和补偿，否则算法层回退并不会撤销真实世界的动作。

规划与执行的隔离

规划模型容易产生不可执行计划，执行模型容易在局部步骤上偏离全局目标。实践中可把计划表示成结构化任务图，每个节点包含动作、参数、前置条件、预期结果和失败策略。执行前先检查权限和资源，执行后把真实观察写回状态，再决定继续、重试还是修改计划。

ReAct 的推理—行动交替给出了一个自然接口 [7]，但生产系统还要加入状态机：模型只能提出候选动作，runtime 负责验证 schema、权限和当前状态。这样既能利用模型的灵活规划，也能避免模型通过自然语言绕过动作边界。对于不可逆动作，必须设置确认点；对于可重试动作，必须定义最大次数和退避策略。

4.8 算法—系统接口：把推理预算交给运行系统

推理预算的接口化

推理期扩展一旦进入产品，就不能只说“多想一会儿”。算法需要向运行系统交付一组明确预算：最大输入长度、最大输出长度、候选数量、搜索深度、验证器调用次数、工具调用次数、超时、停止条件和失败降级。没有这些边界，Serving 层无法估算显存、队列、尾延迟和成本，也无法在预算耗尽时给出可解释结果。

这里要避免一个常见混淆：Prefill、Decode、KV Cache、GQA、FlashAttention、Continuous Batching 是推理服务实现细节，第9章会系统展开；本章只关心算法给系统提出了什么资源需求，以及这些需求如何影响当前任务的成功率。换句话说，本章讨论“值得花多少推理预算”，第9章讨论“怎样稳定交付这笔预算”。

长上下文与有效推理

上下文窗口变长不等于推理能力变强。模型可能丢失中间信息、重复引用错误内容，或把更多无关文本当作证据。长上下文推理应测试信息位置、干扰比例、跨文档关系、答案证据和上下文长度增长曲线。若任务只是从文档中检索一个事实，检索和压缩可能比让模型对全部 128K token 做长 CoT 更便宜可靠。

预算调度与难度路由

如果所有请求都使用最大 reasoning budget，简单任务会浪费成本，困难任务仍可能因为预算不足而失败。可以先用轻量模型或短预算进行难度估计，再把请求路由到不同推理策略：直接回答、检索回答、多候选验证、搜索式规划或人工接管。路由器本身也会出错，因此要允许动态升级：当初步答案缺少证据、验证失败或模型置信信号异常时，再增加预算。

预算分配可以看成一个在线决策问题。每增加一次采样或验证，都应估算成功率增益与边际成本。若第一个候选已经通过强验证器，继续生成没有价值；若多个候选互相矛盾，应优先寻找证据或请求澄清，而不是无上限采样。对 Agent 任务，工具调用次数比思考 token 更可能触发真实成本和风险，预算策略必须对不同动作设置不同权重。

置信度与停止条件

模型 token 概率不能直接当作答案置信度。一个流畅但错误的答案可能每一步都具有高概率。更有用的停止信号包括：多个候选在可验证答案上收敛，程序测试通过，检索证据覆盖关键断言，计划前置条件满足，或者新增推理步骤不再改变结论。停止条件必须明确，否则模型会在已经正确时继续自我批评，或在无法解决时无限循环。

可以把停止判断分成硬条件和软条件。硬条件是超时、最大 token、最大工具次数、风险等级和 verifier 通过；软条件是候选一致性、证据充分度、模型自评和收益曲线。硬条件保证系统不会失控，软条件帮助系统在预算内选择更好的时机结束。所有停止原因都应写入 trace，便于分析“失败是没有想够，还是不应该继续想”。

推理轨迹的隐私与可观测性

显式 CoT、工具参数和搜索分支可能包含用户隐私、系统提示、内部文档和安全策略。保存完整轨迹有助于调试，但也扩大了敏感数据暴露面。生产系统可以区分内部 trace、用户可见摘要和审计事件：内部 trace 最小权限访问，用户只看到经过筛选的结论和证据，审计事件记录动作、权限和结果而不是全部思考文本。

可观测性不应只记录 token 数。至少要记录 prefill/decode 时间、采样策略、候选数量、搜索深度、验证器结果、工具调用、重试次数、停止原因和最终业务结果。这样才能把算法指标与服务指标关联起来：某个策略可能提高准确率，但同时增加人工接管；某个 verifier 可能减少错误，但让 p95 延迟翻倍。算法选型应基于完整 trace，而不是单一 benchmark。

轨迹压缩与结果表达

推理轨迹可能比最终答案长很多，直接把全部轨迹放入下一轮上下文会增加 token 和隐私风险。可以在阶段之间保存结构化状态、关键事实、失败原因和验证结果，而不是保存所有自然语言草稿。压缩过程必须保留来源：某个结论来自哪条检索、哪次工具调用、哪个验证器版本。否则压缩后的摘要会变成新的不可验证事实。

对用户展示时，也要区分“解释”与“内部搜索”。一个模型可以输出简洁的步骤、证据和不确定性，而不必暴露所有采样分支、系统提示或安全规则。对于代码和数学，展示可复核的关键中间结果通常比展示大量自然语言更有价值；对于高风险动作，展示计划、参数、影响范围和确认点，供用户或审批系统检查。

失败恢复和预算耗尽

推理循环必须设计失败路径。候选全部未通过验证时，可以请求更多信息、切换工具、降级到人工、返回部分结果或明确失败；不能默认继续生成。工具超时要区分网络重试和业务重试，避免重复执行非幂等动作。搜索预算耗尽时，系统应返回“已尝试什么、缺什么证据、下一步需要什么”，而不是把最后一条未验证草稿伪装成答案。

失败恢复策略也应进入训练和评估。SFT 可以示范澄清和安全退出，偏好数据可以奖励诚实失败，RLVR 可以把“正确停止”作为奖励的一部分。这样模型学到的不是无论如何都要输出答案，而是在证据不足时选择更安全、更可控的动作。

中文和代码场景的特殊处理

中文、英文、代码和数字混合输入会产生不同的 token 化和概率形状，采样参数不能直接照搬英文自然语言。中文长文可能需要保留段落、标题和引用边界；代码推理需要维护缩进、括号、类型和测试状态；SQL 需要区分表名、字段名和用户输入；数学表达式需要保留符号结构。中文教材对概率建模、优化和泛化的基础解释有助于理解这些差异 [28][29][30]。

评估时应按语言和格式切片，而不是把所有任务合成一个平均准确率。一个模型可能英文数学推理较强、中文题目较弱；可能自然语言解释很好、代码执行较差；可能单轮输出正确、多轮工具状态错误。推理算法的收益只有在目标语言和目标格式上重复验证，才具有工程意义。

4.9 工程决策与验收方法

按任务选择采样、搜索与验证

这张表将算法选择与系统责任分开：采样和搜索帮助生成候选，验证器决定候选是否满足可检查约束，权限和副作用仍由 Runtime 与策略层负责。第9章只处理这些推理预算怎样在真实流量和 SLO 下被调度与交付。

算法选择矩阵

方法选择必须从失败机制出发。推理算法不会修复所有能力问题，搜索也不会创造缺失知识，验证器也不能保证测试覆盖之外的正确性。

实验与评估记录

每个推理实验至少固定模型 checkpoint、tokenizer、system prompt、采样参数、候选数量、验证器版本、最大 token、超时和硬件环境。报告平均准确率之外，还要报告成本、p50/p95 延迟、成功率随预算的曲线、失败类型和停止原因。

对于随机采样，使用足够重复次数和置信区间；对于多数投票，记录投票前后的候选分布；对于搜索，保存扩展树和剪枝原因；对于 verifier，保存通过与拒绝的样本；对于 speculative decoding，记录 draft 接受率和质量一致性。只有保留这些中间证据，才能知道收益来自算法还是偶然随机种子。

评估集还应包含“看似简单但容易犯错”的反例，例如错误前提、单位混用、边界条件、同义答案、工具返回空结果和权限变化。推理算法如果只在标准题上测试，可能学会固定模板，却无法处理真实系统中的不完整信息和异常状态。每次更新都应比较反例通过率，并保留回归失败样本，避免后续优化再次引入旧问题。

当算法涉及用户可见的思考摘要时，还要评估摘要是否忠实、是否泄露敏感信息、是否误导用户把模型推理当成证明。正确答案、有效证据和可复核步骤应分别计分；语言流畅只能作为辅助指标。

对后端团队而言，最实用的指标不是“平均思考长度”，而是每个成功任务消耗多少 token、多少次验证和多少次工具调用。只有把质量、成本和风险放在同一张表里，才能决定推理预算是否值得。

还要区分模型内部生成与外部可见结果：内部候选可以失败、重试和被丢弃，外部结果必须经过协议校验、证据检查和权限判断。这个边界能把探索自由度与生产可靠性分开。

如果没有这个边界，搜索分支、工具返回值和未验证草稿可能混入用户上下文，既增加成本，也可能造成信息泄露。运行时应明确哪些状态可以回放、哪些状态可以展示、哪些状态只能由审计人员访问，并为每类状态设置保留时间和权限。

这套状态治理是推理算法能够长期演进的基础：算法失败可以重现，系统风险可以审计，成本优化有据可依。只有状态、预算、验证和结果都被记录，推理优化才不是凭感觉调参。实验室中的平均分只能说明方法值得继续研究；要说明服务可靠，还必须在真实任务、真实预算和真实失败路径上反复验证。

给后端工程师的落地清单

实现一个推理型模型服务时，可以按以下顺序评审：先定义任务的成功条件和失败代价；再决定是单次生成、重采样、搜索还是工具循环；为可验证任务实现程序化 verifier；给每种请求设置 token、候选、工具和时间预算；将结构化输出交给 schema 校验；将副作用操作交给权限和人工审批；最后测量单位成功成本和尾延迟。

推理算法的最终验收不是“模型能输出一段很像思考的文字”，而是：在给定预算内，任务成功率是否提高；验证失败是否被拦截；额外计算是否值得；错误是否可定位；系统是否能停止、重试和回滚。这个标准也为后续 Infra 章节提供接口：算法给出预算、状态和验证需求，Infra 负责以稳定成本执行它们。

本章小结

生成算法从 greedy 和 sampling 发展到 CoT、Self-Consistency、显式搜索、验证器和 test-time scaling，核心变化是从“选择一个最可能的下一个 token”转向“在预算内寻找并验证一条可接受的任务轨迹”。投机解码、长上下文压缩和预算路由可以改善执行效率或成本，但它们与推理质量相关而不等价。

面对一个具体任务，先判断错误来自知识、搜索、验证、格式还是系统权限，再选择对应方法。能程序化验证的任务优先使用执行器和 verifier；需要多路径探索的任务使用采样和搜索；需要实时事实的任务使用工具和检索；需要低延迟的任务使用路由、草稿模型和预算控制。这样，推理能力才会从论文中的 benchmark 变成可观察、可控制、可回滚的工程组件。

参考资料

[1] Brown, T. B., et al. Language Models are Few-Shot Learners. NeurIPS, 2020. https://arxiv.org/abs/2005.14165 访问日期：2026-09-22

[2] Wei, J., et al. Chain-of-Thought Prompting Elicits Reasoning in Large Language Models. NeurIPS, 2022. https://arxiv.org/abs/2201.11903 访问日期：2026-09-22

[3] Kojima, T., et al. Large Language Models are Zero-Shot Reasoners. NeurIPS, 2022. https://arxiv.org/abs/2205.11916 访问日期：2026-09-22

[4] Wang, X., et al. Self-Consistency Improves Chain of Thought Reasoning in Language Models. ICLR, 2023. https://arxiv.org/abs/2203.11171 访问日期：2026-09-22

[5] Yao, S., et al. Tree of Thoughts: Deliberate Problem Solving with Large Language Models. NeurIPS, 2023. https://arxiv.org/abs/2305.10601 访问日期：2026-09-22

[6] Besta, M., et al. Graph of Thoughts: Solving Elaborate Problems with Large Language Models. AAAI, 2024. https://arxiv.org/abs/2308.09687 访问日期：2026-09-22

[7] Yao, S., et al. ReAct: Synergizing Reasoning and Acting in Language Models. ICLR, 2023. https://arxiv.org/abs/2210.03629 访问日期：2026-09-22

[8] Press, O., et al. Measuring and Narrowing the Compositionality Gap in Language Models. arXiv, 2022. https://arxiv.org/abs/2210.03350 访问日期：2026-09-22

[9] Cobbe, K., et al. Training Verifiers to Solve Math Word Problems. arXiv, 2021. https://arxiv.org/abs/2110.14168 访问日期：2026-09-22

[10] Lightman, H., et al. Let’s Verify Step by Step. arXiv, 2023. https://arxiv.org/abs/2305.20050 访问日期：2026-09-22

[11] Snell, C., et al. Scaling LLM Test-Time Compute Optimally can be More Effective than Scaling Model Parameters. arXiv, 2024. https://arxiv.org/abs/2408.03314 访问日期：2026-09-22

[12] OpenAI. Learning to Reason with LLMs. 2024. https://openai.com/index/learning-to-reason-with-llms/ 访问日期：2026-09-22

[13] Guo, D., et al. DeepSeek-R1: Incentivizing Reasoning Capability in LLMs via Reinforcement Learning. arXiv, 2025. https://arxiv.org/abs/2501.12948 访问日期：2026-09-22

[14] Shao, Z., et al. DeepSeekMath: Pushing the Limits of Mathematical Reasoning in Open Language Models. arXiv, 2024. https://arxiv.org/abs/2402.03300 访问日期：2026-09-22

[15] Schulman, J., et al. Proximal Policy Optimization Algorithms. arXiv, 2017. https://arxiv.org/abs/1707.06347 访问日期：2026-09-22

[16] Huang, J., et al. Let’s Think Step by Step: An Interpretable Reasoning Process in Large Language Models. arXiv, 2022. https://arxiv.org/abs/2205.10625 访问日期：2026-09-22

[17] Manakul, P., Liusie, A., & Gales, M. SelfCheckGPT: Zero-Resource Black-Box Hallucination Detection for Generative Large Language Models. EMNLP, 2023. https://arxiv.org/abs/2303.08896 访问日期：2026-09-22

[18] Ji, Z., et al. Survey of Hallucination in Natural Language Generation. ACM Computing Surveys, 2023. https://arxiv.org/abs/2202.03629 访问日期：2026-09-22

[19] Holtzman, A., et al. The Curious Case of Neural Text Degeneration. ICLR, 2020. https://arxiv.org/abs/1904.09751 访问日期：2026-09-22

[20] Fan, A., et al. Hierarchical Neural Story Generation. ACL, 2018. https://arxiv.org/abs/1805.04833 访问日期：2026-09-22

[21] Leviathan, Y., Kalman, M., & Matias, Y. Fast Inference from Transformers via Speculative Decoding. ICML, 2023. https://arxiv.org/abs/2211.17192 访问日期：2026-09-22

[22] Chen, C., et al. Accelerating Large Language Model Decoding with Speculative Sampling. arXiv, 2023. https://arxiv.org/abs/2302.01318 访问日期：2026-09-22

[23] Stern, M., et al. Blockwise Parallel Decoding for Deep Autoregressive Models. NeurIPS, 2018. https://arxiv.org/abs/1811.03115 访问日期：2026-09-22

[26] Madaan, A., et al. Self-Refine: Iterative Refinement with Self-Feedback. NeurIPS, 2023. https://arxiv.org/abs/2303.17651 访问日期：2026-09-22

[27] Welleck, S., et al. Neural Text Generation with Unlikelihood Training. ICLR, 2020. https://arxiv.org/abs/1908.04319 访问日期：2026-09-22

[28] Zhang, A., Lipton, Z. C., Li, M., & Smola, A. V. Dive into Deep Learning, 2nd ed., 2023. https://zh.d2l.ai/ 访问日期：2026-09-22

[29] 邱锡鹏：《神经网络与深度学习》，机械工业出版社，2020。https://nndl.github.io/ 访问日期：2026-09-22

[30] 周志华：《机器学习》，清华大学出版社，2016。https://cs.nju.edu.cn/zhouzh/zhouzh.files/publication/MLbook2016.htm 访问日期：2026-09-22

版本与范围

本章区分模型生成策略、推理时搜索和 serving 优化。温度、Top-p、约束解码和验证器是应用层可控变量；连续 batching、KV Cache 和吞吐容量属于第 9 章的推理 Infra 主题。投机解码的实际收益依赖模型组合、长度分布和批处理方式；截至 2026-09-21，必须用目标流量压测，而不能引用其他服务的加速比例。

工程决策案例

场景： 系统从一段合同文本提取固定 JSON 字段。对字段名、枚举和 JSON 语法使用 schema/约束解码，并把缺失字段显式返回为 null；不要把低温采样当作结构化输出的保证。对需要生成“风险说明”的自由文本字段，使用较低温度并允许有限候选，再由规则验证引用位置和禁止词。

该设计把“必须正确的接口形状”与“允许有表达差异的自然语言”分开：前者失败即重试或人工转交，后者才适合比较多个候选。评测记录 JSON 解析率、字段级准确率、无依据断言率、p95 延迟和每份合同成本；若约束解码造成延迟不可接受，先缩小输出 schema 或预填确定字段，而不是取消校验。

参考资料与延伸阅读

• Vaswani et al., 2017, Attention Is All You Need。
• Leviathan, Kalman and Matias, 2023, Fast Inference from Transformers via Speculative Decoding。
• vLLM Documentation, accessed 2026-09-21.