生产级LLM如何在推理时进行更优推理（源自Google、OpenAI与Anthropic的研究）

8种让LLM在推理时更擅长推理的技术，涵盖权衡取舍与实践要点。这些技术目前均已在前沿实验室投入生产，其研究背景来自Google、OpenAI和Anthropic。

当基于LLM的任务准确率不足时，干预成本最低的环节往往是推理阶段。

由于无需重新训练，模型权重得以保持不变——整个技术方案通过提示词和LLM调用周围的编排逻辑来实现。

Google曾有一篇论文专门验证这种做法的效益，研究发现，在FLOPs匹配的对比条件下，测试时计算量（test-time compute）能超越14倍参数规模的模型：

本文将详解八项此类技术、其权衡关系，并揭示一个核心属性——它将决定这些技术是否适用于你的用例。

GIF

分配计算的两种方式

推理计算可沿两个方向扩展：

你可以对同一提示词多次采样并择优，或是在模型回答前将单一轨迹进一步延伸。

• 并行采样彼此独立，因此可批量并发执行。更多采样会消耗更多token与GPU时间，但对延迟影响甚微。

• 顺序生成的每个token都依赖前序token，本质上是串行过程。更多推理步骤会直接增加延迟，增加硬件也无法改善这一点。

树形方法则融合了这两种技术：

分支对应并行步骤，延伸存活路径对应顺序步骤，它们同时继承了两种成本特征与两类失败模式。

两类失败模式的表现方向也不同：

• 并行方案的瓶颈出现在采样间错误相关性较高时。

• 顺序方案的瓶颈则在于额外token可能使模型偏离已形成的正确答案。

1) 思维链（Chain of Thought）

通过提示词引导模型逐步思考，让中间结果进入上下文窗口，使后续token能基于这些信息生成，而非仅靠单次前向传递承载全部信息。

# 仅作示意。
# 辅助函数为占位符，并非真实API。

prompt = question + "请逐步思考，然后给出最终答案。"

answer = model(prompt)

实际上，这项技术的收益远不如其流行程度暗示的那样显著。

一项涵盖100余篇论文、20个数据集和14个模型的研究发现，其优势主要集中在数学与符号类任务。

在MMLU基准测试中，除非问题或回答包含等号，直接回答的效果与思维链相当。

事实上，如果你的LLM应用已运行在最新的推理模型上，这项技术基本是多余的。

模型本身已会自主书写思考步骤，再次提示只会增加token数量而不增加结构价值。

2) 多数投票（Majority Voting）

以非零温度对同一提示词运行多次采样，提取每次推理轨迹的最终答案，返回出现频率最高的结果。

# 仅作示意。
# 辅助函数为占位符，并非真实API。

answers = []

for i in range(N):
    trace = model(prompt, temperature=0.8)
    answers.append(extract_final_answer(trace))

return most_common(answers)

样本间的一致性可作为正确性信号的代理指标，因此完全不需要奖励模型。

当自我一致性（Self-consistency）提出时，在GSM8K数据集上为PaLM-540B带来了17.9分的提升。

当然，随着基础模型改进，这一优势幅度已逐步缩小。例如在Gemini 2.5上，20次采样仅使MATH-500提升1.6分，HotpotQA提升0.4分，而token成本几乎随采样次数线性增长。

此技术还存在结构性局限：

投票能降低方差但无法消除偏差。当模型对所有样本错误地理解同一问题时，所有推理轨迹都会一致同意，并将错误答案附带更高的置信度估计返回。

此外，该方法要求答案可进行相等性比较，因此不适用于开放式生成任务。主要适用于数学、分类和提取任务。摘要和具有多种有效形式的代码类任务自然不适合多数投票。

3) N选最佳（Best-of-N）

生成N个完整答案，使用奖励模型为每个答案评分，保留最高分者。这涵盖了投票无法处理的场景，因为评分器可适用于任何输出格式。

# 仅作示意。
# 辅助函数为占位符，并非真实API。

candidates = []

for i in range(N):
    candidates.append(model(prompt, temperature=0.8))

return max(candidates, key=reward_model.score)

N并非可无限调高的超参数。

有论文研究发现，随着N增加，真实奖励先上升至峰值，随后因对代理奖励模型的优化压力增大而下降。

超过该峰值后，搜索过程开始寻找奖励模型喜欢的答案，而非真正正确的答案。

另一个问题是奖励模型的辨别能力必须优于策略模型的生成能力。

获得这种特性代价高昂，因此许多N选最佳方案在较小N值处即达到平台期并保持稳定。

4) 扩展思考（Extended Thinking）

模型在生成答案前会投入token预算进行内部推理。

# 仅作示意。
# 辅助函数为占位符，并非真实API。

answer = model(prompt, thinking={"budget_tokens": 8000})

目前所有主要服务商都提供了此功能，例如：

• Claude的budget_tokens参数
• Gemini的thinkingBudget参数
• OpenAI模型的reasoning_effort参数

这是列表中唯一从提示工程移入训练过程的技术。

R1-Zero仅通过强化学习，无需任何推理时外部框架，就在AIME 2024上从15.6%提升至71.0%。

更长的推理轨迹并非普遍有益。Anthropic的逆缩放研究构建了准确率随推理长度增长而下降的任务：计数问题中无关数字会误导模型；相关性任务中模型可能偏离稳健先验而趋向较弱特征；约束满足谜题中模型会重复推导已确定的结论。

对于生产环境而言，最大努力程度是错误的默认设置。有效设置需针对具体任务，其寻找过程应基于评估而非假设。

5) 自我优化（Self-Refinement）

顾名思义，模型先生成答案，接着自我批判，然后重写答案，循环重复直至满足停止条件。

# 仅作示意。
# 辅助函数为占位符，并非真实API。

answer = model(prompt)

for i in range(max_rounds):
    critique = model("找出此答案中的错误：" + answer)
    if "no errors" in critique:
        break
    answer = model("根据此批判重写：" + answer + critique)

return answer

有论文研究了当无外部信息输入时该循环的表现，结果出人意料。

在GSM8K上，GPT-3.5修正了7.6%的错误答案，却改变了8.8%的正确答案，导致整体循环产生净负收益，还额外消耗了token。

此前关于自我纠正的积极结果使用了“先知标签”来决定何时停止优化，因此循环仅针对已知错误的答案运行。

这隐含了对标准答案的过滤，但在真实流量的推理阶段并不可用。

当批判来自模型外部时，优化确实有效。编译器、测试套件或类型检查器携带了模型自身分布中不具备的信息。

6) 思维树（Tree of Thought）

模型提出多个候选下一步骤（而非单一方案），进行评分，保留最优的几个分支，并回溯淘汰看似无望的分支：

# 仅作示意。
# 辅助函数为占位符，并非真实API。

paths = [""]

for depth in range(max_depth):
    candidates = []
    for path in paths:
        candidates += propose_next_steps(path, n=5)
    paths = top_k(candidates, key=score_step, k=5)
    if any(is_complete(p) for p in paths):
        break

return best(paths)

在24点游戏中，此技术将GPT-4的准确率从思维链的4%提升至宽度5时的74%。

该任务会因过早锁定错误分支且无法回溯而受惩罚，这正是回溯策略能发挥优势的场景。

思维树的开销大致相当于50-100次独立思维链尝试的消耗。

因此在尝试前，值得先验证20-40次生成加投票是否能达到相同准确度，因为后者token消耗要少得多。

7) 束搜索（Beam Search）

束搜索保留K个部分解决方案，并在每一步生成时即进行评分，而非等待完整答案生成。

# 仅作示意。
# 辅助函数为占位符，并非真实API。

beams = [""]

for depth in range(max_depth):
    candidates = []
    for beam in beams:
        candidates += model.continue_one_step(beam, n=4)
    beams = top_k(candidates, key=prm.score, k=K)

return max(beams, key=prm.score)

逐步评分器是过程奖励模型（下图所示第二种技术）：

GIF

随着预算增长，其与N选最佳的排名关系会发生逆转。

研究发现，在小计算预算下束搜索表现优于N选最佳，但随着预算增长则被反超，因为搜索开始满足过程奖励模型而非真正解决问题。

过度优化会产生重复且信息量低的步骤，部分解决方案甚至坍缩为一两个步骤。

最终，问题难度决定了哪种方法更优：

• 简单问题：束搜索会过度优化而N选最佳不会
• 中等难度问题：束搜索稳定获胜
• 最难任务：没有方法明显更优

这在生产环境中难以实际应用，因为问题难度在答案生成前是未知的。

8) 蒙特卡洛树搜索（Monte Carlo Tree Search）

选择一个有希望的部分路径，将其延伸至完整答案，将分数沿路径反向传播，并在多次迭代中重复此过程。

# 仅作示意。
# 辅助函数为占位符，并非真实API。

root = Node(prompt)

for i in range(n_iterations):
    node = select_most_promising(root)
    child = node.expand()
    answer = rollout_to_completion(child)
    backpropagate(child, value_model.score(answer))

return best_child(root)

蒙特卡洛树搜索（MCTS）源于AlphaGo和AlphaZero，这些场景中每回合的移动选择空间较小且可枚举。

DeepSeek也曾尝试，但token生成打开了更大的搜索空间，因此DeepSeek限制了每个节点的延伸深度。这导致搜索陷入局部最优。

他们同时弃用了过程奖励模型，原因包括：一般推理中步骤正确性难以定义，自动标注无法扩展，且策略模型会学习利用评分器。

而R1则通过基于规则的奖励进行强化学习，将搜索过程融入了模型权重。

实践要点

所有技术本质上完成两件事：生成候选方案，并从中选择。

生成部分已被充分理解且基本解决。但这些方法主要差异在于如何选择最终答案。

当存在精确检查器（如单元测试、编译器、模式验证器）时，这些方法能随预算增长持续有效。

它们提供了无法被操纵的信号，扩展针对该信号的搜索能持续产生价值。

但当选择器是学习而来的奖励模型时，两个维度会以相同方式退化，且退化幅度随预算增长而扩大。

因此实践中，应首先构建验证信号，其次扩展搜索。

对于无法构建良好检查器的任务，推理时计算通常不如预期有效，应探索进一步训练。

为此，RULER技术应运而生。

它使用LLM作为奖励函数，将强化学习扩展至无可验证答案的智能体任务，并免除了为每个任务手写奖励函数的需求。

我在以下文章中追溯了从RLHF到GRPO（带可验证奖励）再到RULER的完整演进路径：

Avi Chawla@_avichawla·4月28日 文章《顶级AI实验室如何在2026年构建RL智能体（运用Karpathy的系统提示学习思想）》 揭秘Anthropic、OpenAI和DeepSeek如何汇聚于将系统提示用作奖励函数的单一思想。全面解析从RLHF到RULER的RL演进历程，附代码示例….1491451697K

👉 轮到你了：这些技术中哪些你已投入生产？又是什么原因让你放弃了其他未采用的技术？

至此完结！

如果你喜欢本教程： 找到我 → @_avichawla

每天分享数据科学、机器学习、大语言模型和检索增强生成的教程与见解。