大模型虽然推理能力增强，却常常「想太多」，回答简单问题也冗长复杂。Rice大学的华人研究者提出高效推理概念，探究了如何帮助LLM告别「过度思考」，提升推理效率。
LLM的推理能力显著增强，然而，这个「超级大脑」也有自己的烦恼。
有时候回答会绕好大一个圈子，推理过程冗长又复杂，虽能得出正确答案，但耗费了不少时间和计算资源。
比如问它「2加3等于多少」，它可能会从数字的概念、加法原理开始，洋洋洒洒说上一大通，这在实际应用中可太影响效率啦。
来自Rice大学的华人研究者提出了「高效推理」的概念，在保证回答准确的同时，更快、更简洁地给出答案。
论文链接：https://arxiv.org/abs/2503.16419
项目链接：https://github.com/Eclipsess/Awesome-Efficient-Reasoning-LLMs
接下来，深入探讨LLM的高效推理，帮它们告别「过度思考」。
LLM通过思维链（CoT）提示等技术，在复杂推理任务中表现亮眼。
CoT就像是给模型装上了「思考引擎」，让它能一步一步地推导，把推理过程清晰地展现出来。
不过，这份出色的表现，需要消耗大量计算资源。
LLM经常出现「过度思考」的情况，生成长而冗余的推理内容，增加了延迟和资源消耗。
本文聚焦于如何在提升或保持模型性能的同时，优化推理过程，这对计算资源有限的实际场景十分重要。
研究者梳理了应对「过度思考」，实现高效推理的技术手段：
此外，研究者还介绍了用高效数据训练推理模型，探索小模型的推理能力，并讨论了评估方法和基准测试。
LLM产生冗长、不必要的推理过程时，就出现了「过度思考」现象。
在回答「0.9和0.11哪个大」这个简单的问题时，DeepSeek-R1和QwQ-32B这两个模型给出的答案都十分冗长。
它可能会从十进制的原理开始，分析小数点后的每一位数字，还会尝试用各种方法验证，比如转化为分数或在数轴上表示，最后才给出答案。
虽然答案是对的，但推理过程又长又啰嗦，耗费了大量时间和计算资源。
DeepSeek-R1：好的，我得判断0.9和0.11谁更大。它们都是小数，但小数点后的位数不一样。我先想想每个小数的含义，0.9就是十分之九，因为小数点后第一位是十分位。等等，我换个方法确认下，把它们转成百分数试试……为了确保没错，我在数轴上表示一下吧。还有其他验证方法吗？用减法好像也行……或者……我确定答案是0.9。（616字，19秒）
QwQ-32B：要找出0.9和0.11哪个大。它们是小数，逐位比较看看？我回忆下小数比较的规则……0.9 小数点后有1位，0.11有2位，写法上是不是要调整下……不对，我再检查下，是不是哪里搞错了。换个思路……另一种方法是……最终答案是0.9更大。（602字，42秒）
从这个例子，能看出「过度思考」的几个特点：回答简单问题，两个模型都写了600多字。推理过程中有很多重复、多余的验证方法。
推理内容越长，处理所需的时间就越多。模型会反复怀疑自己的推理过程。
在资源有限的环境，或像自动驾驶、智能交互助手这类需要实时响应的应用场景中，「过度思考」带来的效率低下问题就会格外突出。
高效推理方法有以下三类，基于模型的有效推理、针对结果的优化和借助输入提示的有效推理。
一种有效的做法是在RL中加入长度奖励，引导它生成简洁的推理。
以前，模型训练的时候主要关注答案是否正确、格式是否规范。现在研究人员给它加了一个新的「考核指标」——推理长度。
就像老师不仅要求学生答对题，还要求答题过程简洁明了。
奖励函数通常是这样的：
其中α用来调节长度惩罚在奖励函数中的权重，R_length是根据推理响应长度设置的惩罚项，计算方式如下：
模型为了获得更多奖励，就会在保证答案准确的同时，尽量少用token。
利用可变长度的CoT数据进行监督微调，也是提升推理效率的有效方法。
这就好比给模型提供了不同难度和长度的「练习题」，让它学会灵活应对各种情况。
训练数据中既有完整详细的推理链，也有简短、高效的推理路径。
通过这些示例，模型就能学会在不降低准确性的前提下，采用更简洁高效的推理模式。
在微调模型的时候，既可以采用像LoRA这样的标准微调方法，对模型参数进行小范围的调整；也可以采用渐进式微调，让模型慢慢适应新的思考节奏，逐步提高推理效率。
从推理输出的角度，研究人员尝试通过创新的方式来压缩推理步骤，让模型的「思考过程」更加精简。
这些方法不改变模型的参数，直接对推理输出的结果进行优化。
潜在推理技术能把推理步骤压缩为更精简的表达形式，图中展示了多种以更高效的格式编码的潜在推理方法：
这些方法通常会用到嵌入函数，把冗长的推理内容映射到一个更紧凑的空间里，用公式表示就是：
E_compact是压缩后的推理表示，f是学习到的变换函数。
除了利用潜在表示，在推理过程中动态调整推理策略也是提高效率的关键。
动态推理会根据每个问题的具体情况，按需生成推理步骤，图中介绍了两种典型的技术。
在奖励引导方面，推测拒绝优化了最佳N解码算法。在生成多个响应的过程中，根据奖励模型的评估，及时丢弃低质量的输出，减少不必要的计算开销。
面对复杂问题时，它会先大量生成可能的推理路径，然后快速排除那些没有希望的路径，只保留高质量的路径继续推理，大大提高了推理效率。
这两种技术的核心思路都是，根据问题的复杂程度灵活调整推理深度，用公式表示为：
借助输入提示，巧妙引导思考从输入提示的角度入手，也能让模型推理变得更高效。
长度约束提示简单又实用，直接在提示里要求模型控制推理长度，比如「用不超过10个token回答下面的问题」。
CoD方法则让模型在逐步推理时，只保留每个思考步骤的最少草稿，最多用五个单词。
比如在解答数学题时，模型不再详细写出每一步的推导过程，而是用简洁的几个词概括关键思路，这样在保证准确性的同时，大大减少了token的使用。
不同的任务难度不同，对推理的要求也不一样。
因此，根据输入提示的属性进行推理路由也是一种提高效率的策略。
RouteLLM训练了一个查询路由器，它根据问题的复杂性将查询分配给合适的模型。
简单的问题就交给速度快但推理能力较弱的模型处理，复杂的问题则交给能力更强的模型，这样可以充分发挥不同模型的优势，提高整体推理效率。
Self-Ref方法让LLM能根据自身的不确定性分数来决定是否需要路由到更强大的模型。
如果模型对自己的答案不太确定，就会自动寻求更强大模型的帮助，减少不必要的推理步骤。
除了上述方向，研究人员还在数据、模型和评估等方面进行了深入探索，以进一步提升LLM的推理效率。
很多研究发现，训练数据的质量和结构，对模型的高效推理能力影响很大。
通过精心挑选和组织训练数据，即使数据量少，也能让模型有出色的表现。
LIMO打破了传统的观念，不再追求数据的数量，而是专注于质量。
它会从难度、通用性和知识多样性等方面挑选高质量的问题，然后再配上结构合理、验证严格的解决方案。
用这精心挑选的817个样本，LIMO训练出来的模型就能超越那些用了10多万个样本训练的模型，是不是很厉害？
S2R给LLM注入了自我验证和自我纠正的能力，就像给模型请了一个私人教练。
它先在一个精心挑选的数据集上对模型进行微调，让模型初步具备这些能力，然后再通过RL进一步提升。
只用了3100个初始化样本，S2R微调后的模型在推理任务中的表现，比很多用大量长CoT蒸馏数据训练的模型还要好。
LLM虽然能力很强，但它对计算资源的要求也很高，在一些资源有限的场景里就有点施展不开。
这时候，小语言模型（SLM）就有了用武之地。
不过，要让SLM在有限的资源下也能有强大的推理能力，还得给它来点「特殊训练」。
知识蒸馏是提升SLM推理能力的重要方法，简单来说，就是把LLM的智慧传递给SLM。
混合蒸馏就像是把不同的「知识精华」混合在一起，有的把长、短CoT推理示例混合，有的把CoT和PoT（Program of Thought）结合，让SLM能吸收更全面的知识。
反事实蒸馏则像是给SLM创造了一些假设情境，通过对原始问题进行特殊处理，生成多视角的CoT，让SLM从不同角度学习知识。
还有反馈驱动的蒸馏技术，它会不断优化蒸馏数据集，像给SLM提供越来越精准的学习资料。
另外，一些方法还把探测和检索机制融入蒸馏过程，或者在蒸馏时让模型根据任务动态调整推理策略，这些都帮助SLM更好地学习LLM的推理能力。
评估高效推理，需要综合考虑准确性和推理效率：
实际评估时，通常会先把效率指标标准化处理，再和准确性指标结合起来，形成一个综合指标：
既奖励正确性，又鼓励推理的简洁性。
Sys2Bench涵盖了算术、逻辑、常识、算法和规划等多个领域的任务，用11个不同的数据集对LLM进行全方位的测试。
通过这个测试，发现仅靠增加推理时的计算资源，并不能让模型在所有任务中都表现出色，提升LLM的推理能力需要多种方法结合。
还有一些研究专门考察不同的推理策略对模型性能的影响，以及测试时扩展（TTS）策略和模型性能之间的关系。
对LLM的过度思考问题，也有专门的评估方法。
研究人员开发了一个评估框架，可以深入分析模型的推理过程，找出像分析瘫痪、异常行为和过早放弃等模式。
他们提出了「过度思考分数」，就像是一个健康指标，分数越高，说明模型过度思考的问题越严重，任务性能就越差。
通过选择过度思考分数低的解决方案，可以让模型性能提高30%，同时降低43%的计算开销。
参考资料：
https://www.alphaxiv.org/overview/2503.16419
新智元报道 编辑：英智
本文由人人都是产品经理作者【新智元】，微信公众号：【新智元】，原创/授权 发布于人人都是产品经理，未经许可，禁止转载。
题图来自Unsplash，基于 CC0 协议。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。