目录

大型语言模型(LLM)的工作原理根植于模式匹配和对下一个词元的统计预测(“随机鹦鹉”)。从这种方法中产生的一个有些出人意料的能力是它们也能在一定程度上”推理”解决问题。有些模型的推理能力比其他模型更强，OpenAI的”o1”和”o3”模型是两个突出的推理模型，而DeepSeek的”R1”最近引起了很大轰动。但是当我们在编码任务中使用AI时，这种能力发挥什么作用呢？

剧透提醒：我还没有答案！但我有问题和想法。

我将从两个方面开始讨论，这两个方面在我的理解中是推理能力的限制，而且这些限制在编码环境中是相关的。然后我将分享我的想法，即推理在哪些编码任务中可能有用，在哪些任务中可能没用。

上下文至关重要，尤其是对推理而言

苹果公司去年发表的一篇关于大型语言模型推理局限性的论文引起了广泛关注。作者引入了一个新的基准测试，用来测试LLM在”数学推理”方面的能力。他们的基准测试基于一个已有的包含小学数学问题的测试集。他们选取了100个问题，将其转化为带有变量占位符的模板，然后为每个模板创建了50个变体，形成了一个包含5,000个问题的数据集。在第二步中，他们还创建了一个新的数据集，在问题中添加了无关信息。

他们发现：

  1. 姓名和数字的变化会影响模型解决问题的性能。即使推理步骤完全相同(Sophie看她的侄子变成Anita看她的孙女，或者是12个毛绒玩具而不是8个)，模型解决问题的性能也不一致，甚至比原始基准测试略有下降。

  2. 当问题的难度和规模增加时，性能进一步下降。

  3. 最后，他们发现在问题中添加无关信息对性能有很大的负面影响。

首先，这是一个很好的例子，说明为什么我们应该对LLM基准测试持保留态度。

在编码环境中，我发现最后一个发现特别有趣。编码助手正在变得越来越善于为LLM编排相关的代码上下文，这样模型就能拥有恰到好处的信息来为我们提供有用的代码建议。这篇论文表明，对于良好的推理来说，特别重要的是我们的工具能够丢弃可能会分散模型注意力并对推理质量产生负面影响的无关代码片段。

基本上：数据质量很重要，对推理而言比其他任务类型更为重要。当我们确定了一个需要多步骤推理的问题时，我们应该特别注意我们提供给模型的上下文。

推理步骤中没有函数调用

像o1和R1这样的推理模型分两步工作，首先他们”推理”或”思考”用户的提示，然后在第二步中返回最终结果。在推理步骤中，模型通过思维链来得出结论。能否完全看到这个推理步骤的内容取决于模型前端的用户界面。例如，OpenAI只向用户展示每个步骤的摘要。DeepSeek的平台显示完整的推理链(当然，当你自己运行R1时，你也可以访问完整的链)。在推理步骤结束时，聊天机器人UI会显示”思考了36秒”或”推理了6秒”等消息。无论花费多长时间，无论用户是否能看到，后台都在生成词元，因为LLM通过词元生成进行思考。

据我所知，在这种推理模式下，模型无法调用可用的任何函数。我不确定这是因为API限制还是模型限制，但我的猜测是，推理步骤的全部目的是生成一个不中断的词元链，而用函数调用中断这一过程会部分违背其目的。

何时推理与编码任务相关？

许多推理基准测试使用小学数学问题，所以当我试图找到软件中需要思维链的类似问题时，这些是我的参考框架。对我来说，这似乎是关于需要多个步骤才能得出解决方案的问题，其中每个步骤都依赖于前一个步骤的输出。

基于这个定义，对于以下任务，推理似乎并不重要，因为这些事情可以由LLM处理，而无需逐步推理：

  • 内联代码建议
  • 为新函数生成代码
  • 回答关于如何做某事的问题(例如，”如何删除所有本地Docker镜像？”)
  • 生成文档或摘要
  • 将自然语言转换为正式查询(例如SQL)

这是针对编码进行微调的模型擅长的领域，不管它们的推理能力如何。

推理模型主要在以下两个环境中被提及：

调试

调试似乎是思维链的一个极好的用例。我的主要疑惑是，函数调用的缺失会在多大程度上阻碍我们使用推理进行调试。

让我们考虑一个调试任务：我有一个错误，想要AI思考可能的原因。在那一点上，我自己实际上不知道问题源自何处，我不能将整个代码库放入上下文窗口，所以我实际上希望AI工具沿途查找信息。

例如，假设日志中有一个错误，”ERROR: duplicate key value violates unique constraint “users_email_key”“，我要求AI帮我调试。第一个假设可能是电子邮件验证不起作用，所以我希望它查找我的验证代码，然后继续推理。这是调试的典型特征，我们提出假设，然后查找确认或否定我们假设的信息，然后要么采取下一步，要么完全放弃假设。根据我对LLM推理步骤的理解，目前不可能通过函数调用沿途查找更多信息。

制定实现计划

我看到很多报告说人们使用推理模型进行编码的规划步骤，然后使用特别擅长编码的模型(如Claude Sonnet)来实现该计划。最近流行的开源编码助手Cline发布了一个功能，开发者可以在”Plan”和”Act”模式之间切换，这不仅阻止LLM直接跳到实现阶段，而且还使得在第一步使用不同的模型变得更容易，可能是具有推理能力的模型。

我尝试过几次使用推理模型进行规划，但老实说，到目前为止，我还没有感觉到与好的编码模型有什么特别的不同。这让我想知道，规划编码任务真的是一个思维链问题吗？”我们需要一个API端点和这个Web组件的变化”是模型应该通过推理得出的东西，还是可以通过更基本的模式匹配能力来处理？

我使用得还不够多，无法得出结论。但我上面提到的论文中的第二个发现也可能相关：当作者增加数学问题的规模和难度时，”[…]随着涉及的词元或步骤数量的增加，得出准确答案的概率呈指数下降”，”[…]随着难度增加，性能下降，方差增加”。在论文中，”难度”被定义为向原始问题添加更多因素和条件。

这些发现是否为具有高推理能力的模型可以规划和解决的问题的规模和难度设定了一个玻璃天花板？我们可能会发现o1和R1在编码中的作用比目前宣传的要小。考虑Qodo的这种方法作为例子，他们发现逐步的代理流程可以胜过单独的推理模型。如果问题的规模和复杂性确实应该继续成为模型的限制因素，那么要使AI更好地解决问题，我们必须在某种代理中分解事情，该代理给多个模型提供较小的问题。在这种情况下，我想知道推理是否只对那些较小问题的一小部分是绝对必要的。

总结

我个人还不确定推理模型对软件开发任务来说是否真如宣传的那样是个大的游戏改变者。除了速度慢和成本高昂外，模型还有上述潜在限制，在我用它们进行编码或调试问题的各种尝试中，我还没有发现o1在有良好AI上下文编排的IDE中给我的结果明显好于Claude-Sonnet-3.5的情况。