今天给大家分享一篇论文,揭秘o1类超大型语言模型的过度思考:2+3=?答案仅需5个token,o1类模型凭啥要900个?
题目是:Do NOT Think That Much for 2+3=? On the Overthinking of o1-Like LLMs
作者单位:腾讯AI Lab、上海交通大学
论文链接:https://arxiv.org/abs/2412.21187
这篇论文探讨了一类被称为“o1-like”
的大型语言模型(LLMs)在推理过程中存在的问题,即“overthinking”(过度思考)
。这些模型在处理问题时,尤其是简单问题,会分配过多的计算资源,而这种过度的资源分配对于提高答案的准确性几乎没有帮助。具体来说,论文试图解决以下问题:
o1-like
模型在处理简单问题时,会生成过多的解决方案和思考步骤,这导致了计算资源的浪费。论文的目标是通过深入分析过度思考问题,并提出相应的效率指标和优化策略,来提高o1-like模型在AI推理任务中的计算资源利用效率,减少不必要的计算开销。
在人工智能的领域中,大型语言模型(LLMs)如OpenAI的o1模型及其复制品,以其卓越的推理能力引领着技术前沿。这些模型通过模仿人类在回答问题前的深思熟虑,展现了解决复杂问题的强大潜力。它们通过延长思考链(chain-of-thought,CoT),探索多种策略,分解复杂步骤,并进行双重检查,从而增强了处理复杂推理任务的能力。这种方法,被称为“测试时计算扩展”,通过在模型的推理阶段分配更多的计算资源,以期获得更准确的响应。
然而,随着这些模型在推理过程中展现出的卓越性能,一个关键问题逐渐浮现:模型是否在测试时智能且高效地扩展了计算资源?在这篇文章中,论文将深入探讨o1-like模型中的一个普遍问题——过度思考
。
过度思考是指模型在面对简单或答案显而易见的问题时,仍然分配过多的计算资源,这不仅导致了效率低下,还暴露了模型在推理和决策过程中的基本局限性。
具体来说,它们倾向于在非常简单或答案已经显而易见的问题上花费过多的计算资源(以token或思考轮次计)。例如,图1(a)比较了o1-like模型与常规模型在回答“2加3等于多少?”这个问题时的token使用情况。平均而言,o1-like模型消耗的token比常规模型多出1953%。
本篇就是对这一类问题进行了初步探索并提出一些策略缓解思考,通过简化推理过程来减少计算开销,同时保持模型性能。
尽管上述工作考虑了如何提高模型的推理效率,但它们主要关注的是传统模型,而不是具有更长思考链(chain-of-thought)的o1-like模型。 本工作首次提出了o1-like模型中的过度思考问题,并通过自我训练方法来训练模型学习如何高效地思考,而不是简单地限制推理空间或由用户指定Token耗费个数。
论文选择了三个测试集来评估o1-like模型的性能:
测试集的整体难度等级为:ASDIV < GSM8K < MATH500。
研究主要关注两个广泛认可的o1-like模型,它们具有明显的长CoT(思考链):QwenQwQ-32B-Preview和DeepSeek-R1-Preview。QwQ-32B-Preview是一个开源模型,而DeepSeek-R1-Preview只能通过Web界面访问。由于DeepSeek-R1-Preview的每日消息限制为50条,论文仅在MATH500测试集上评估了这个模型。
论文通过以下几个步骤解决o1-like模型中的过度思考问题:
在这一部分,论文对o1-like模型生成的输出进行全面分析。首先展示这些模型在响应中的解决方案分布情况。接着提出识别长CoT(思考链)响应中的两个效率问题:准确性和多样性。为了实证评估这些效率问题,基于探索提出了两个效率指标。结论是:
o1-like模型往往会过度思考,特别是在处理更简单的数学问题时。
在本文中,答案被定义为包含明确答案的完整模型生成的一部分。例如,在图2中,QwQ生成的每个答案都包含答案5。论文使用Llama-3.3-70B模型来从生成的响应中分离出答案。
图3显示了不同测试集和模型(QwQ-32B-Preview和DeepSeek-R1-Preview)生成响应中的答案数量分布。通常,o1-like模型为大多数实例产生2到4轮答案,QwQ-32B-Preview在测试集上的覆盖率为76%到85%,DeepSeek-R1-Preview在MATH500测试集上的覆盖率为74%。
对于不同的测试集,QwQ-32B-Preview倾向于为更简单的测试集生成更多的答案。例如,在最简单的ASDIV测试集上,QwQ模型的平均答案数量为3.6,而在最困难的MATH500测试集上,平均答案数量为2.8。
为了验证这一发现,研究者们在MATH500测试集的不同难度级别上进行了分析,如图4所示。QwQ-32B-Preview和DeepSeek-R1-Preview在较容易的1-2级问题上生成的答案轮次更多(分别为平均3.75轮和3.35轮),与4-5级问题(分别为平均3.0轮和2.7轮)相比,尽管随着难度级别的增加,token的数量一致增加。这些结果支持了o1-like模型倾向于为更简单的数学问题生成更多答案轮次的主张。
总的来说,这部分内容揭示了o1-like模型在解决不同难度级别的数学问题时,倾向于为简单问题生成更多的答案,这可能表明这些模型在处理简单问题时存在过度思考的现象。
在这部分,论文将探讨o1-like模型在生成解决方案时,如何影响其准确性的效率。这里的直觉是,在图2中的例子里观察到,第一轮答案回复就已经给出了正确答案。而后续的答案回复,虽然占据了生成的token的大多数,但实际上并没有提高准确性。
基于这个观察,论文研究了后续答案回复是否对准确性提升有贡献。具体来说,对于所有o1-like模型在响应中产生正确答案的情况,论文计算了第一个正确答案的出现分布,称之为“首次正确分布”。如果更多的正确答案出现在早期回复中,那么后续回复对准确性提升的贡献就很小,表明效率降低。
图5展示了测试集和模型中首次正确分布的情况。在超过92%的情况下,第一轮答案回复就产生了正确答案。值得注意的是,第一轮通常只包含生成的总token的不到60%,这表明延长的CoT可能并不会显著提高准确性。例如,在ASDIV测试集上,QwQ-32B-Preview模型第一轮解决方案的平均长度是287个token,只占整个回复的38.7%。
这些结果表明,后续解决方案对准确性的提升贡献很小。
结果效率指标:
基于上述观察,论文提出了一个结果效率指标来实证评估后续解决方案对准确性提升的有效性。准确性的效率指标如下:
这一部分考察了o1-like模型在思考过程中多样性的效率。背后的直觉是,虽然解决一个简单的数学问题看起来可能很直接,但从不同的角度来解决它可以增强理解和培养数学思维的灵活性,这本身就是有价值的。
考虑图2中QwQ-32B-Preview的输出示例:
这三个答案回复提供了关于问题的不同视角。然而,答案4重复了答案3,答案5重复了答案2,使用了类似的视角。
图6展示了每个答案索引的独特性比率。直观上,答案#1的独特性比率总是100%,因为它没有前序答案,因此对于所有实例来说τ都等于1。通常,随着索引的增加,比率会下降,表明后续答案往往重复了之前的答案。例如,在各个测试集中,答案#4的独特性比率大多低于30%,低于答案#3,后者高于45%。
在除了ASDIV之外的测试集中,答案#2的比率显著下降,表现不如答案#3。通过检查输出,我们发现答案#2经常使用与答案#1相同的视角来双重检查答案。随后,答案#3尝试从一个新的视角解决问题。
表1展示了模型效率的结果。为了比较,我们包括了两个代表性的传统大型语言模型(LLMs):Llama-3.3-70B-Instruct和Qwen2.5-Math-72B-Instruct。这些传统的LLMs只产生单一答案,这意味着。因此,在这些情况下,结果效率指标ξO等同于准确性,过程效率指标ξP等于1.0。相比之下,o1-like模型生成的响应明显更长,这在提高准确性和答案多样性方面效率较低。我们将这种生成token的低效使用称为“过度思考问题”。
图7展示了MATH500测试集不同难度级别上的详细效率结果。DeepSeek-R1-Preview
在2-5级的问题上,无论是结果效率还是过程效率,都一致优于QwQ-32B-Preview
。值得注意的是,两个模型在最简单的1级问题上表现都不佳,结果效率低于50%,这与在简单的ASDIV测试集上观察到的结果相符。这些发现强调了o1-like模型在处理更简单的数学问题时尤其明显的过度思考问题。
本节探讨了通过自训练策略提升o1-like模型效率、减轻过度思考问题的方法。
以下是对文档中提到的四个主要部分的总结:
本研究揭示了o1-like模型(类似于OpenAI的o1模型)的一个关键挑战:
在测试时有效地和智能地扩展计算资源。
通过突出过度思考现象并提出效率指标,论文增强了对o1-like模型资源利用的理解,基于自训练的方法有效地减少了过度思考,降低了不必要的计算,同时保持了模型性能。
这项工作不仅提高了模型效率,还为未来在AI推理任务中优化计算资源分配的研究奠定了基础。未来的研究方向包括探索能够根据问题复杂性动态调整的自适应计算策略,以及完善效率指标以实现更广泛的模型泛化。
论文在结论部分提出了一些可以进一步探索的方向,这些方向有助于优化计算资源在AI推理任务中的分配,并提高o1-like模型的效率和性能。以下是一些具体的探索点:
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。