推理大模型的后训练增强技术--LLM 推理型的现状（文末送书） - 文章 - 开发者社区

作者：Sebastian Raschka

原文：https://magazine.sebastianraschka.com/p/state-of-llm-reasoning-and-inference-scaling

提升大型语言模型（LLM）的推理能力无疑是 2025 年最火热的话题之一，而且理由很充分。更强的推理能力意味着 LLM 可以处理更复杂的问题，让它在各种任务上表现得更出色，更贴近用户的实际需求。

最近几周，研究人员提出了不少提升推理能力的新策略，比如增加推理时的计算量、强化学习、监督微调以及知识蒸馏等。而且，很多方法都会结合这些技术，以达到更好的优化效果。

本文将聚焦于 LLM 推理优化的最新研究进展，特别是自 DeepSeek R1 发布以来，关于推理时计算量扩展的相关方法和应用。

picture.image

在 LLM 中实现和改进推理：四个主要类别

大多数读者对 LLM 推理模型可能已经比较熟悉，这里简单介绍一下它的定义。基于 LLM 的推理模型，主要是通过生成中间步骤或结构化的“思考”过程，来解决多步骤问题。不同于只给出最终答案的传统问答式 LLM，推理模型会在推理过程中展现其思考路径，或者在内部完成推理。这种方式让它在处理谜题、编程挑战、数学问题等复杂任务时，表现得更加出色。

picture.image

一般来说，改进推理有两种主要策略：（1）增加_训练_计算量，或（2）增加_推理_计算量，也称为_推理时扩展_或_测试时扩展_。

推理计算量是指在训练后，为响应用户查询而生成模型输出所需的处理能力。

picture.image

请注意，上面显示的图表看起来好像我们通过训练时计算量或测试时计算量来改进推理。然而，LLM 通常旨在通过结合大量的训练时计算量（广泛的训练或微调，通常使用强化学习或专门数据）和增加的测试时计算量（允许模型在推理期间“思考更长时间”或执行额外计算）来改进推理。

picture.image

要了解推理模型是如何被开发和优化的，分别拆解不同的技术仍然是一个高效的思路。在此前的文章 理解推理 LLM 中，对推理 LLM 进行了更细致的分类，并将其归纳为四个主要类别，如下图所示。

picture.image

上图中的方法 2-4 通常会让 LLM 生成更长的回答，因为这些方法在输出中加入了中间步骤和解释。而由于推理成本通常与响应长度成正比（比如，响应长度翻倍，计算量也会相应增加一倍），这些训练策略本质上与推理扩展密切相关。不过，在这一部分关于 推理时计算量扩展 的讨论中，重点将放在那些可以直接控制生成 token 数量的技术，比如额外的采样策略、自我纠正机制等。

本文主要关注 2025 年 1 月 22 日 DeepSeek R1 发布之后，围绕 推理时计算量扩展 的最新研究和模型进展。（原本计划涵盖所有类别的方法，但篇幅过长，因此决定将训练时计算量相关的方法留到后续的专门文章中。）

picture.image

在我们研究推理时计算量扩展方法以及推理模型的不同进展领域（重点是推理时计算量扩展类别）之前，让我至少简要概述一下所有不同的类别。

1. 推理时计算量扩展

这一类方法主要聚焦于在 推理阶段 提升模型的推理能力，而无需重新训练或修改底层模型的权重。核心思路是在计算资源的投入和模型性能提升之间找到平衡，通过 思维链推理 （Chain-of-Thought Reasoning）以及各种 采样策略 等技术，让即使是固定的模型也能更强大。

尽管 推理时计算量扩展 被单独归类，以便更专注于这类技术的应用，但实际上，它可以适用于任何 LLM。例如，OpenAI 在训练 o1 模型时采用了强化学习，同时也运用了推理时计算量扩展的方法。而值得注意的是，DeepSeek R1 论文中明确提到，该模型并未使用推理时扩展技术，但他们也承认，这类技术可以轻松集成到 R1 的部署或应用中。这一点在之前的文章 理解推理 LLM 也有详细讨论。

2. 纯强化学习

此方法仅专注于强化学习 (RL) 来开发或改进推理能力。它通常涉及使用来自数学或编码领域的、可验证的奖励信号来训练模型。虽然强化学习允许模型发展更具战略性的思维和自我改进能力，但它也面临着诸如奖励黑客攻击、不稳定性和高计算成本等挑战。

3. 强化学习和监督微调

这种混合方法将强化学习 (RL) 与监督微调 (SFT) 相结合，以实现比纯强化学习更稳定和更通用的改进。通常，首先使用 SFT 在高质量的指令数据上训练模型，然后使用 RL 进一步改进以优化特定行为。

4. 监督微调和模型蒸馏

此方法通过在高质量的标记数据集 (SFT) 上进行指令微调来提高模型的推理能力。如果此高质量数据集由更大的 LLM 生成，则此方法也称为 LLM 环境中的“知识蒸馏”或简称为“蒸馏”。但是，请注意，这与深度学习中的传统知识蒸馏略有不同，后者通常涉及不仅使用较大教师模型的输出（标签），还使用 logits 来训练较小的模型。

推理时计算量扩展方法

上一节已经对 推理时计算量扩展 做了简要总结，在深入探讨该领域的最新研究之前，先更详细地介绍一下这一概念。

推理时扩展 的核心思路是在推理过程中增加计算资源（即“计算量”），从而提升 LLM 的推理能力。为什么这能有效？可以用一个简单的类比来解释： 人类在思考时间更充裕时，往往能给出更精准的答案 ，同样地，LLM 也可以通过一些技术，在生成过程中进行更多“思考”，从而优化推理效果。

其中一种方法是 提示工程 ，比如 思维链（Chain-of-Thought, CoT） 提示。在提示中加入类似“逐步思考”的短语，可以引导模型生成中间推理步骤，从而提高复杂问题的准确性。不过，这种方法对于简单的日常查询来说并不必要，而且由于 CoT 提示会让模型生成更多 token，实际上也会提高推理成本。

picture.image

另一种方法涉及投票和搜索策略，例如多数投票或束搜索，这些方法通过选择最佳输出来改进响应。

picture.image

1. “s1：简单测试时扩展”

接下来的内容将聚焦于 推理时扩展 领域的最新研究进展，探索如何提升 LLM 的推理能力。首先，先来看一篇具有代表性的论文，它可以作为推理时扩展的一个典型案例。

在这一类别中，一项值得关注的研究是 s1: Simple Test-Time Scaling ，于 2025 年 1 月 31 日 发表。这篇论文提出了一种名为 “等待（wait）”token 的新方法，可以将其视为“逐步思考”提示的一种更现代化变体。需要注意的是，该研究涉及监督微调（SFT）以生成初始模型，因此并不完全属于纯粹的推理时扩展方法。然而，它的核心目标仍然是 在推理阶段主动控制模型的推理过程 ，因此仍然归入 “推理时计算量扩展” 这一类别。

简而言之，他们的方法是双重的：

创建一个包含 1k 个训练示例的精选 SFT 数据集，其中包括推理轨迹。
通过以下方式控制响应长度：
a) 附加“等待 (Wait)”token，使 LLM 生成更长的响应，自我验证并纠正自身，或
b) 通过添加思考结束 token 分隔符（“最终答案 (Final Answer:)”）来停止生成。他们称这种长度控制为“预算强制 (budget forcing)”。

picture.image

预算强制 (Budget forcing) 可以被视为一种顺序推理扩展技术，因为它仍然一次生成一个 token（但只是生成更多）。相比之下，我们有并行技术，例如多数投票，它聚合多个独立的补全结果。

picture.image

他们发现他们的预算强制 (budget-forcing) 方法比我讨论过的其他推理扩展技术（如多数投票）更有效。如果要批评或改进，我希望看到更复杂的并行推理扩展方法的结果，例如束搜索、前瞻搜索或谷歌去年在 _ Scaling LLM Test-Time Compute Optimally Can Be More Effective Than Scaling Model Parameters _论文中描述的最佳计算量优化搜索。甚至可以与经典的顺序方法（如思维链提示（“逐步思考 (Think step by step)”））进行简单比较。

无论如何，这是一篇非常有趣的论文和方法！

附注：为什么是“等待 (Wait)”token？ 我的猜测是，研究人员受到了 DeepSeek-R1 论文中“顿悟时刻 (Aha moment)”图的启发，研究人员在图中看到 LLM 提出了类似“_等等，等等。等等。这是一个顿悟时刻，我可以标记一下 (Wait, wait. Wait. That's an aha moment I can flag here.)_”的内容，这表明纯强化学习可以诱导 LLM 产生推理行为。

有趣的是，他们还尝试了其他 token，例如“_嗯 (Hmm)_”，但发现“_等待 (Wait)_”的表现略好。

picture.image

其他关于推理时计算量扩展的值得注意的研究论文

本月推理模型研究领域相当活跃，为了控制文章篇幅，接下来的论文摘要会尽量简明扼要。下面是几篇与 推理时计算量扩展 相关的有趣研究，按照 发布日期升序 排列。

需要注意的是，并非所有论文都完全属于推理时计算量扩展范畴，其中有些还涉及特定的训练过程。但它们的共同点在于，都在不同程度上探索了 如何控制推理阶段的计算量 ，并将其作为提升 LLM 推理能力的一种机制。

2. 测试时偏好优化 (Test-Time Preference Optimization)

📄 1 月 22 日，_测试时偏好优化：通过迭代文本反馈进行即时对齐 (Test-Time Preference Optimization: On-the-Fly Alignment via Iterative Textual Feedback)_， https://arxiv.org/abs/2501.12895

测试时偏好优化 (TPO) 是一个迭代过程，可在推理期间使 LLM 输出与人类偏好对齐（这不会改变其底层模型权重）。在每次迭代中，模型都会：

为给定的提示生成多个响应。
使用奖励模型对响应进行评分，以选择得分最高和最低的响应作为“选择 (chosen)”和“拒绝 (rejected)”响应
提示模型比较和批判“选择 (chosen)”和“拒绝 (rejected)”的响应
通过将批判转换为文本建议来更新原始模型响应，从而改进输出

通过迭代执行步骤 1-4，模型可以改进其原始响应。

picture.image

来自“测试时偏好优化：通过迭代文本反馈进行即时对齐 (Test-Time Preference Optimization: On-the-Fly Alignment via Iterative Textual Feedback)”，https://arxiv.org/abs/2501.12895 的注释图

3. 思绪纷飞 (Thoughts Are All Over the Place)

📄1 月 30 日，_思绪纷飞：关于 o1 类 LLM 的思考不足 (Thoughts Are All Over the Place: On the Underthinking of o1-Like LLMs)_， https://arxiv.org/abs/2501.18585

研究人员探索了一种称为“思考不足 (underthinking)”的现象，即推理模型经常在推理路径之间切换，而不是完全专注于探索有希望的路径，从而降低了问题解决的准确性。

为了解决这个“思考不足 (underthinking)”问题，他们引入了一种称为“思绪切换惩罚 (Thought Switching Penalty, TIP)”的方法，该方法修改了思绪切换 token 的 logits，以阻止过早的推理路径转换。

他们的方法不需要模型微调，并且在多个具有挑战性的测试集中经验性地提高了准确性。

picture.image

来自“思绪纷飞：关于 o1 类 LLM 的思考不足 (Thoughts Are All Over the Place: On the Underthinking of o1-Like LLMs)”，https://arxiv.org/abs/2501.18585 的注释图

4. 用推理时计算量换取对抗鲁棒性 (Trading Inference-Time Compute for Adversarial Robustness)

📄 1月 31 日，_用推理时计算量换取对抗鲁棒性 (Trading Inference-Time Compute for Adversarial Robustness)_， https://arxiv.org/abs/2501.18841

在许多情况下，增加推理时计算量可以提高推理 LLM 的对抗鲁棒性，从而降低攻击成功率。与对抗训练不同，此方法不需要任何特殊训练，也不需要事先了解特定的攻击类型。

但是，也有一些重要的例外。例如，在涉及策略歧义或漏洞利用的设置中，改进是有限的。此外，推理改进的鲁棒性可能会因新的攻击策略（例如“少思考 (Think Less)”和“书呆子狙击 (Nerd Sniping)”）而降低。

因此，虽然这些发现表明扩展推理时计算量可以提高 LLM 的安全性，但这本身并不是对抗鲁棒性的完整解决方案。

picture.image

来自“用推理时计算量换取对抗鲁棒性 (Trading Inference-Time Compute for Adversarial Robustness)”，https://arxiv.org/abs/2501.18841 的注释图

5. 关联思绪链 (Chain-of-Associated-Thoughts)

📄 2 月 4日，CoAT：用于增强大型语言模型推理的关联思绪链框架 (CoAT: Chain-of-Associated-Thoughts Framework for Enhancing Large Language Models Reasoning)， https://arxiv.org/abs/2502.02390

研究人员将经典的蒙特卡洛树搜索 (Monte Carlo Tree Search) 推理时扩展与“关联记忆 (associative memory)”相结合，后者在推理路径探索期间充当 LLM 的知识库。使用这种所谓的关联记忆 (associative memory)，LLM 可以更轻松地考虑早期的推理路径，并在响应生成期间动态地利用信息。

picture.image

来自“CoAT：用于增强大型语言模型推理的关联思绪链框架 (CoAT: Chain-of-Associated-Thoughts Framework for Enhancing Large Language Models Reasoning)”，https://arxiv.org/abs/2502.02390 的注释图

6. 退后一步，向前飞跃 (Step Back to Leap Forward)

📄 2 月 6 日，退后一步，向前飞跃：用于提升语言模型推理的自我回溯 (Step Back to Leap Forward: Self-Backtracking for Boosting Reasoning of Language Models)，https://arxiv.org/abs/2502.0440 本文提出了一种自我回溯机制，该机制允许 LLM 通过学习在训练和推理期间何时以及何处回溯来改进其推理。虽然训练涉及教导模型使用 <backtrack> token 识别和纠正次优推理路径，但关键贡献是一种推理时基于树的搜索，该搜索使用这种学习到的回溯能力来探索替代解决方案。

独特之处在于，这种探索不需要依赖外部奖励模型（这与使用基于过程奖励模型的基于搜索的方法不同，我在本文“1. 推理时计算量扩展方法”部分开头提到了这种方法）。

picture.image

来自“退后一步，向前飞跃：用于提升语言模型推理的自我回溯 (Step Back to Leap Forward: Self-Backtracking for Boosting Reasoning of Language Models)”，https://arxiv.org/abs/2502.04404 的注释图

我在此处添加这篇论文是因为它非常关注所提出的回溯推理时扩展方法，该方法通过动态调整搜索深度和广度来改进推理，而不是从根本上改变训练范式（尽管需要使用 <backtrack> token 进行训练）。

7. 通过潜在推理扩展测试时计算量 (Scaling up Test-Time Compute with Latent Reasoning)

📄 2 月 7 日，通过潜在推理扩展测试时计算量：一种循环深度方法 (Scaling up Test-TimeCompute with Latent Reasoning: A Recurrent Depth Approach)， https://arxiv.org/abs/2502.05171

研究人员没有通过生成更多 token 来改进推理，而是提出了一种通过在潜在空间中迭代循环深度块来扩展推理时计算量的模型。此块的功能类似于 RNN 中的隐藏状态，它允许模型在不需要更长的 token 输出的情况下改进其推理。

然而，一个关键缺点是缺乏显式的推理步骤，在我看来，显式的推理步骤对于人类可解释性非常有用，并且是思维链方法的主要优势。

picture.image

来自“通过潜在推理扩展测试时计算量：一种循环深度方法 (Scaling up Test-Time Compute with Latent Reasoning: A Recurrent DepthApproach)”，https://arxiv.org/abs/2502.05171 的注释图

8. 10 亿参数的 LLM 能否超越 4050 亿参数的 LLM？ (Can a 1B LLM Surpass a405B LLM?)

📄 2 月 10 日，10 亿参数的 LLM 能否超越 4050 亿参数的 LLM？重新思考计算量最优的测试时扩展 (Can 1B LLM Surpass 405B LLM? Rethinking Compute-Optimal Test-Time Scaling)， https://arxiv.org/abs/2502.06703

许多推理时扩展技术都依赖于采样，这需要过程奖励模型 (Process Reward Model, PRM) 来选择最佳解决方案。本文系统地分析了推理时计算量扩展如何与 PRM 和问题难度相互作用。

研究人员开发了一种计算量最优的扩展策略，该策略适应 PRM、策略模型和任务复杂性的选择。他们的结果表明，通过正确的推理时扩展方法，10 亿参数的模型可以胜过缺乏推理时扩展的 4050 亿参数的 Llama 3 模型。

同样，他们展示了具有推理时扩展的 70 亿参数模型如何在保持更高推理效率的同时超越 DeepSeek-R1。

这些发现突出了推理时扩展如何显着改进 LLM，其中小型 LLM 通过适当的推理计算量预算，可以胜过更大的模型。

picture.image

来自“10 亿参数的 LLM 能否超越 4050 亿参数的 LLM？重新思考计算量最优的测试时扩展 (Can 1B LLM Surpass 405B LLM? Rethinking Compute-Optimal Test-Time Scaling)”，https://arxiv.org/abs/2502.06703 的注释图

9. 在测试时从反馈中学习推理 (Learning to Reason from Feedback at Test-Time)

📄 2 月 16 日，在测试时从反馈中学习推理 (Learning to Reason from Feedback at Test-Time)， https://www.arxiv.org/abs/2502.12521

很难将其归类为推理时方法还是训练时方法，因为它在推理时优化 LLM，从而改变其权重参数。

因此，本文探索了一种使 LLM 在推理时从错误中学习的方法，而无需将失败的尝试存储在提示中（这会很昂贵）。这种方法没有采用通常通过将先前的尝试添加到上下文中（顺序修订）或盲目生成新答案（并行采样）来改进答案的方法，而是在推理时更新模型的权重。

为此，作者引入了 OpTune，这是一个小的、可训练的优化器，它根据模型在上一次尝试中犯的错误来更新模型的权重。这意味着模型会记住它做错了什么，而无需将不正确的答案保留在提示/上下文中。

picture.image

来自“在测试时从反馈中学习推理(Learning to Reason from Feedback at Test-Time)”， https://www.arxiv.org/abs/2502.12521 的注释图

10. 用于LLM 推理和规划的推理时计算 (Inference-Time Computations for LLM Reasoning and Planning)

📄 2 月 18 日，用于 LLM 推理和规划的推理时计算：基准和见解 (Inference-Time Computations for LLM Reasoning and Planning:A Benchmark and Insights)， https://www.arxiv.org/abs/2502.12521

本文针对推理和规划任务，对各种推理时计算量扩展技术进行了基准测试，重点是分析其计算成本和性能之间的权衡。

作者评估了多种技术——例如思维链 (Chain-of-Thought)、思维树 (Tree-of-Thought) 和推理即规划 (Reasoning as Planning)——跨越算术、逻辑、常识、算法推理和规划等 11 项任务。

主要发现是，虽然扩展推理时计算可以提高推理能力，但没有一种技术在所有任务中始终优于其他技术。

picture.image

来自 _用于 LLM 推理和规划的推理时计算：基准和见解 (Inference-Time Computations for LLM Reasoning and Planning: A Benchmark and Insights)_，https://www.arxiv.org/abs/2502.12521 的注释图

11. 内在思考 Transformer (Inner Thinking Transformer)

📄 2 月 19 日，内在思考 Transformer：利用动态深度扩展来促进自适应内部思考 (Inner Thinking Transformer: Leveraging Dynamic Depth Scaling to Foster Adaptive Internal Thinking)， https://arxiv.org/abs/2502.13842

内在思考 Transformer (ITT) 在推理期间动态分配更多计算量。与基于 Transformer 的标准 LLM 对所有 token 使用固定深度（= 使用相同数量的层）不同，ITT 采用自适应 Token 路由 (Adaptive Token Routing) 为困难的 token 分配更多计算量。这些困难的 token 多次通过同一层以进行额外的处理，从而增加了这些困难 token 的推理计算量预算。

picture.image

来自“内在思考 Transformer：利用动态深度扩展来促进自适应内部思考 (Inner Thinking Transformer: Leveraging Dynamic Depth Scaling to Foster Adaptive Internal Thinking)”，https://arxiv.org/abs/2502.13842 的注释图

12. 用于代码生成的测试时扩展 (Test Time Scaling for Code Generation)

📄 2 月 20 日，S：用于代码生成的测试时扩展 (S: Test Time Scalingfor Code Generation)， https://arxiv.org/abs/2502.14382**

推理时扩展可以通过并行扩展（生成多个答案）、顺序扩展（迭代改进答案）或两者来实现，正如 2024 年夏季谷歌的论文（ Scaling LLM Test-Time Compute Optimally can be More Effective than Scaling Model Parameters ）中所述。

S* 是一种专门为代码生成设计的测试时计算量扩展方法，可改进并行扩展（生成多个解决方案）和顺序扩展（迭代调试）。

picture.image

来自“S：用于代码生成的测试时扩展(S*: Test Time Scaling for Code Generation)”，https://arxiv.org/abs/2502.14382 的注释图*

该方法分两个阶段运行：

阶段 1：生成

模型生成多个代码解决方案，并使用问题提示中提供的执行结果和测试用例迭代地改进它们。

可以将此视为编码竞赛，模型提交解决方案、运行测试并修复错误：

模型生成多个候选解决方案。
每个解决方案都在公共测试用例（预定义的输入-输出对）上执行。
如果解决方案失败（输出不正确或崩溃），模型会分析执行结果（错误、输出）并修改代码以改进它。
此改进过程会迭代地继续，直到模型找到通过测试用例的解决方案。

例如， 假设模型被要求实现一个函数 is\_even(n) ，该函数对于偶数返回 True，否则返回 False。

模型的第一次尝试可能是：


            
            
                

              
 
 def
 
  
 
 is\_even
 
 
 (n)
 
 :
 
              
   

 
                  
              
 return
 
               n % 
              
 2
 
                
              
 # ❌ 错误：应该是 `== 0`

模型使用公共测试用例测试此实现：


            
            
                

              is\_even(4) True        False        ❌ 失败 is\_even(3) False        True        ❌ 失败

在查看结果后，模型意识到 4 % 2 返回 0，而不是 True，因此它修改了函数：

现在，该函数 通过了所有公共测试 ，完成了调试阶段。

阶段 2：选择

一旦多个解决方案通过了公共测试，模型必须选择最佳解决方案（如果可能）。在这里，S* 引入了自适应输入合成 (adaptive input synthesis) 以避免随机选择：

模型比较两个都通过公共测试的解决方案。
它问自己：“我可以生成一个输入来揭示这些解决方案之间的差异吗？”
它创建一个新的测试输入并在其上运行两个解决方案。
如果一个解决方案产生正确的输出而另一个解决方案失败，则模型选择更好的解决方案。
如果两个解决方案的行为相同，则模型随机选择一个。

例如， 考虑 is\_perfect\_square(n) 的两个不同实现：


            
            
                

              
 import
 
               math
              
   

 
              
   

 
              
 
 def
 
  
 
 is\_perfect\_square\_A
 
 
 (n)
 
 :
 
              
   

 
                  
              
 return
 
               math.isqrt(n) ** 
              
 2
 
               == n


            
            
                

              
 
 def
 
  
 
 is\_perfect\_square\_B
 
 
 (n)
 
 :
 
              
 return
 
               math.sqrt(n).is\_integer()

两者都通过了简单示例的提供的测试用例：


            
            
                

              n = 
              
 25
 
              
   

 
              print(is\_perfect\_square\_A(n))  
              
 # ✅ True (正确)
 
              
   

 
              print(is\_perfect\_square\_B(n))  
              
 # ✅ True (正确)

但是，当 LLM 生成边缘情况时，我们可以看到其中一个失败，因此在这种情况下，模型将选择解决方案 A：


            
            
                

              n = 
              
 10
 
              **
              
 16
 
               + 
              
 1
 
              
   

 
              print(is\_perfect\_square\_A(n))  
              
 # ✅ False (正确)
 
              
   

 
              print(is\_perfect\_square\_B(n))  
              
 # ❌ True (不正确)

13. 思维链的草稿 (Chain of Draft)

📄 2 月 25 日，思维链草稿：通过少写来更快思考 (Chain of Draft: Thinking Faster by Writing Less)， https://arxiv.org/abs/2502.18600

研究人员观察到，虽然推理 LLM 通常会生成冗长的逐步解释，但人类通常依赖于仅捕获必要信息的简洁草稿。

受此启发，他们提出了草稿链 (Chain of Draft, CoD)，这是一种提示策略，可通过生成最少但信息丰富的中间步骤来减少冗长。因此，从某种意义上说，这是一种用于推理时扩展的方法，它通过生成更少的 token 来提高推理时扩展的效率。

picture.image

来自“草稿链：通过少写来更快思考 (Chain of Draft: Thinking Faster by Writing Less)”， https://arxiv.org/abs/2502.18600 的注释图

查看结果，似乎 CoD 几乎与标准提示一样简洁，但与思维链 (Chain of Thought, CoT) 提示一样准确。正如我之前提到的，在我看来，推理模型的优势之一是用户可以阅读推理轨迹以学习并更好地评估/信任响应。CoD 在某种程度上削弱了 CoT 的优势。但是，在不需要冗长的中间步骤的情况下，它可能会非常方便，因为它可以在保持 CoT 准确性的同时加快生成速度。

14. 更好的反馈和编辑模型 (Better Feedback and Edit Models)

📄 3 月 6 日，专用反馈和编辑模型支持开放域通用任务的推理时扩展 (Dedicated Feedback and Edit Models Empower Inference-Time Scaling for Open-Ended General-Domain Tasks)， https://arxiv.org/abs/2503.04378

许多用于扩展推理时推理的技术依赖于具有可验证答案的任务（如可以检查的数学和代码），这使得它们难以应用于开放式任务，如写作和通用问题解决。

为了解决关于可验证答案的这一限制，研究人员开发了一个系统，其中一个模型生成初始响应，另一个模型提供反馈（“反馈模型 (feedback model)”），第三个模型根据该反馈改进响应（“编辑模型 (edit model)”）。

他们使用大量人工注释的响应和反馈数据集来训练这些专门的“反馈 (feedback)”和“编辑 (edit)”模型。然后，这些模型通过在推理时生成更好的反馈和进行更有效的编辑来帮助改进响应。

picture.image

结论

推理时计算量扩展 已成为今年最热门的研究方向之一，它的核心目标是在 不修改模型权重 的前提下，提升大型语言模型的推理能力。

目前，这一领域的研究方法涵盖范围广泛，既有 基于 token 的简单干预 （比如“等待（Wait）”token），也有 更复杂的搜索和优化策略 ，例如 测试时偏好优化（Test-Time Preference Optimization） 和 关联思绪链（Chain-of-Associated-Thoughts） 等。

从整体趋势来看，一个反复出现的主题是： 在推理阶段增加计算量，即使是相对较小的模型，也能在推理基准测试中实现显著的性能提升 。这意味着，合理的推理策略可以在一定程度上 缩小小型、成本更低的模型与大型模型之间的性能差距 ，让更具性价比的模型在推理能力上接近更强大的同类产品。

成本警告

需要注意的是，推理时扩展会带来额外的计算成本。因此，在实际应用中，如何取舍是一道平衡题——是选择一个较小的模型，并通过推理时扩展增强推理能力，还是直接使用一个更大的模型，减少甚至完全不使用推理扩展，这取决于具体的使用场景和计算成本考量。

举个例子，o1 模型虽然大量依赖推理时扩展，但整体成本仍然可能比更大的 GPT-4.5 低，后者可能根本不需要推理扩展。因此，在选择模型时，不仅要考虑推理能力，还要结合计算资源、使用频率和成本效益来权衡。

picture.image

哪种技术？

然而， 推理时计算量扩展并不是万能解法 。尽管 蒙特卡洛树搜索（Monte Carlo Tree Search） 、 自我回溯（Self-Backtracking） 和 动态深度扩展（Dynamic-Depth Scaling） 等技术确实能显著提升推理能力，但它们的效果往往 依赖于具体任务的类型和难度 。正如一些早期研究所示，没有任何一种推理时扩展方法能够在所有任务中都表现最佳。

此外，这类方法通常是 用更长的响应时间换取更强的推理能力 ，但较慢的响应速度可能会影响用户体验，尤其是在一些对时效性要求较高的场景下。例如，对于简单任务，许多用户可能更倾向于使用 GPT-4o 而不是 o1 ，因为前者响应更快，而后者尽管推理能力更强，但可能带来额外的等待时间。

因此，在实际应用中， 如何在推理质量和响应速度之间找到最佳平衡，仍然是推理时计算量扩展需要持续优化的关键问题 。

下一步是什么

展望未来，今年的研究趋势很可能会围绕 “通过推理时计算量扩展提升推理能力” 展开，并主要沿着两个方向发展：

专注于优化模型性能 ，争夺基准排行榜的领先地位。这一方向的研究通常会探索更高效的计算策略，以最大化 LLM 在推理任务中的表现。
关注推理成本与性能之间的平衡 ，优化不同任务的资源分配。这一类研究更倾向于在实际应用场景中寻找最佳性价比，确保在提升推理能力的同时，不至于带来过高的计算开销。

无论是哪种方式，推理时计算量扩展的最大优势在于，它可以适用于任何现有 LLM，赋予它们更强的推理能力，使其更适应特定任务。这一特性使其成为提升 LLM 实用性的一项重要策略，也将推动未来 AI 发展的新阶段。

按需思考(Thinking on Demand)

一个值得关注的行业趋势可以称为 “按需思考（Thinking on Demand）” 。自 DeepSeek R1 发布以来，各大公司似乎都在争相为产品加入推理能力，推动 LLM 在推理方向上的发展。

一个有趣的变化是，大多数 LLM 提供商现在都允许用户手动 启用或禁用“思考”功能 。虽然具体机制并未公开，但很可能是基于相同的 LLM，通过 调整推理时计算量 来控制推理能力的强弱。

比如， Claude 3.7 Sonnet 和 Grok 3 都为用户提供了显式的“思考”开关，而 OpenAI 则采用了 模型切换 的方式，要求用户在使用推理能力更强的模型时，手动切换到 GPT-4o/4.5 或 o1/o3-mini。此外，OpenAI 的 CEO 还透露， GPT-4.5 可能是他们最后一款没有明确推理或“思考”模式的模型 。在开源领域，即便是 IBM 也为其 Granite 模型 添加了显式的“思考”切换功能。

整体来看， 无论是通过推理时计算量扩展，还是在训练阶段引入推理能力，这一趋势无疑是 2025 年 LLM 发展的重要方向 。随着时间推移，推理能力可能不再被视为一个额外的或可选的特性，而是像 指令微调（Instruction Tuning） 或 强化学习（RLHF） 一样，成为 LLM 的标配。

正如前面所提，由于篇幅限制，本文主要聚焦于 推理时计算量扩展 这一方向，而这一领域的研究也在持续推动 LLM 向更高效、更智能的方向演进。

为了回馈粉丝，我们选取了5本

《大模型技术30讲》用来抽奖送给大家，中奖条件为ChallengeHub粉丝即可

没中奖的同学，也可以自行购买