最近一篇论文标题很有意思叫《LLMs Cant Jump》。一句话解释大语言模型在需要“回溯上下文、跳过中间步骤、重新计数”这类跳跃式推理任务上表现远没有想象中可靠。这篇文章不是教你怎么部署一个开源模型而是帮你搞清楚一个更根本的问题LLM 的推理能力到底是从训练数据里“背”出来的还是真的学会了推导如果你在做 Agent、RAG、自动化测试或者 LLM 应用评估这个问题的答案直接影响你的技术选型和 Prompt 设计。论文核心观点可以概括为三点LLM 在“从通顺文本中提取/恢复信息”的传统 NLP 任务上表现很好但在“需要进入执行模式的跳跃式推理”任务上表现很差。即使训练数据里包含大量类似例子模型性能提升也相当有限。模型与人类处理这类推理的方式有本质差异现有评估框架容易高估模型能力尤其是包含思维链CoT提示时。下面的内容我会从论文的推理逻辑、实验设计、结果分析和工程影响几个维度展开最后给出对 LLM 应用开发和模型选择的建议。文章不涉及具体部署命令侧重算法与推理能力分析。1. 核心观点速览能力项说明研究对象大语言模型的跳跃式推理Jump Reasoning能力核心结论LLM 在需要多步运算和跳跃式复查的任务上表现显著落后于传统 NLP 任务问题根源训练目标和推理目标之间存在 gap模型倾向于“接着上文生成”而非“执行计算”受影响任务数学计算、字母计数、单词计数、逐字回忆、状态追踪等受影响场景代码生成、Agent 任务规划、结构化输出、日志分析、自动化测试评估方式需要设计“思考后回答”和“直接回答”的对比实验以及带 CoT 的提示实验工程启示关键链路不要依赖单一 LLM 的原生推理能力需要用外部工具、验证步骤和显式约束兜底这个表可以快速传达论文最重要的结论。下面展开分析。2. 什么是“跳跃式推理”2.1 定义“跳跃式推理”指的是模型在执行任务时必须跳过文本表面的流畅性进入一种类似计算机执行的模式。具体来说模型需要从上下文中恢复一个状态例如“当前计数为多少”。执行一个操作例如“加 1”。将结果重新写回上下文并继续执行后续步骤。这种推理方式在人类看来很简单但它并不符合语言模型“逐词预测下一个 token”的天然工作方式。语言模型在预训练阶段学习到的统计规律本质上倾向于生成通顺、合理的文本而不是执行精确的计算。2.2 与传统 NLP 任务的区别传统的 NLP 任务例如情感分类、主题分类、填词都可以通过模式匹配或上下文检索完成。模型只需要“读”文本然后在记忆中找到最相似的范式输出即可。这类任务并不需要精确维护中间状态。跳跃式推理任务则完全不同。以论文中可能涉及的单词计数任务为例输入文本是一段通顺的话“The cat sat on the mat and looked at the dog.”任务是“这句话里有多少个字母 a”要回答这个问题模型必须忽略句子语义将注意力放在字符级别。逐个字符检查统计目标字母出现次数。保持计数状态不能遗漏、不能重复。这个任务对于人类来说很简单但对于以“下一个词预测”为目标训练的 LLM却非常困难。因为模型在训练时很少会碰到“数清楚一段自然语言中某个字符出现次数”这种需求它的注意力机制天生更关注语义层面的相关性而不是字符层的精确计数。2.3 跳跃式推理的三个关键操作论文讨论的跳跃式推理我认为可以拆解为三个关键操作暂停生成模型需要抑制“继续输出通顺文本”的默认行为。回溯读取模型需要回到输入文本中重新读取已经“看”过的内容。状态更新模型需要将计数结果或累计结果写回内部状态并在后续步骤中保持更新。这三个操作对于 Transformer 架构来说并不是设计时的强项。Transformer 的自注意力机制虽然可以关注任意位置但对于需要精确统计和状态累积的任务它的位置编码和注意力分布并不能保证准确的计数行为。3. 实验设计思路论文的实验思路非常有启发。它不是简单地问“模型能不能答对”而是设计了一组对比任务用来定位模型真正欠缺的能力。3.1 任务设计对比整套实验应该包含两类任务任务 A可通顺生成的文本任务给定一段文本要求模型从文本中提取信息并以自然语言回答。例如从简历中提取候选人的姓名、年龄、工作经验。任务 B需要跳跃式推理的任务给定一段通顺文本但问题要求模型对文本的某个中间状态进行精确计算。例如统计这段文本中某个单词出现的次数计算文本中所有数字的和从一段对话中恢复某个时刻的状态。核心思想是文本是人类可读的、流畅的但任务本身却要求模型忽略文本的表层流畅性进入“计算模式”。3.2 训练数据可控性论文另一个重要设计是可控的训练数据。理想情况下研究者会构造一个训练集其中包含大量的任务 B 示例让模型在训练时“见过”类似问题。然后观察模型在训练集上的表现如何模型在 OOD分布外测试集上的表现如何模型是否真的学到了推理能力还是仅仅记住了训练样本的答案这种设计可以有效地区分“记忆”和“推理”。如果模型只在训练集上表现好但在分布外数据上表现差说明模型并没有真正学会跳跃式推理而是在背答案。4. 核心发现LLM 如何“思考”论文最核心的发现我认为可以概括为以下几个方面4.1 在通顺文本任务上模型表现良好当任务只是“从文本中提取信息并以自然语言回答”时LLM 的表现确实不错。这与我们日常使用 ChatGPT、Claude 等模型的经验一致让模型总结一篇文档、提取关键实体、回答常识问题效果都很好。原因是这些任务本质上不要求模型精确维护中间状态模型只需“读过”文本然后生成一个与文本语义一致的答案。Transformer 的自注意力机制搭配大规模语料预训练足以处理这类语义检索任务。4.2 在跳跃式推理任务上模型表现显著下降当任务需要精确计数、状态恢复和符号操作时模型表现急剧下降。以字母计数任务为例人类可以轻松数清楚一段话中某个字母的出现次数最多花点时间。LLM 在同样任务上的准确率会明显低于人类水平而且随着文本长度增加下降幅度更明显。同样地单词计数、算术运算、逐字回忆等任务也存在这个问题。值得注意的是即使是当前主流的强模型在这个维度上的能力仍然受限。4.3 思维链无法完全弥补先天缺陷论文另一个重要发现是思维链Chain-of-ThoughtCoT提示虽然能提升模型在某些推理任务上的表现但对于跳跃式推理的改善有限。原因在于CoT 本质上是让模型“说人话式地分步推理”但模型生成的中间步骤并不保证正确。模型可以生成看起来合理的推理过程但其中的状态更新可能是错的。举例来说模型可能会这样回答字母计数问题让我逐个检查这句话中的字母 a 1. The - 没有 a 2. cat - 有 1 个 a 3. sat - 有 1 个 a ... 所以共有 3 个 a。这个推理过程看起来非常合理但模型在“逐个检查”这一步可能并没有真的逐个检查。它只是生成了一段看似在检查的文本。因此最后的答案并不比直接回答更可靠。在某些情况下CoT 甚至可能让模型更自信地输出错误答案。4.4 模型与人类的推理机制存在本质差异人类在解决跳跃式推理问题时会明确切换认知状态从“阅读理解模式”切换到“执行计算模式”。在这个过程中我们会暂停语义理解将输入符号化然后按规则逐步操作。LLM 没有真正的“执行模式”。它的每一步输出都是在预测下一个 token这个预测基于的是海量文本中学到的统计规律。它并不会真正“暂停”并“执行计算”只是生成看起来像计算过程的文本。这个差异解释了为什么模型在跳跃式推理上表现不佳也解释了为什么简单的“更大模型”和“更多数据”并不能根治这个问题。5. 实验结果的具体表现虽然论文的具体数值需要以正式发表的版本为准但根据通常的实验设计可以预期以下表现模式5.1 任务类型与准确率矩阵任务类型人类表现LLM 表现直接回答LLM 表现CoT文本摘要高高高实体提取高高高单词计数高低中低字母计数高低中低算术运算多步高稍慢中低中状态追踪高低低这个矩阵说明LLM 的能力分布并不是“全能的”而是和任务类型高度相关。越是需要精确状态维护的任务模型表现越差。5.2 训练数据影响如果训练数据中已经包含了大量类似任务和答案模型在训练集上可能表现不错。这很可能是因为“记住了答案”。但如果测试数据的格式稍有变化例如文本长度更长、要求统计的字符换了一个、问题措辞变了模型表现会显著下降。这说明模型并没有学会通用的计数能力而是记住了训练数据中的模式。5.3 Scaling 的边际效应这里不宜给出具体硬件或显存数字但按照现有公开经验简单增加参数量、增加训练数据量对这类跳跃式推理的改善是有限的。真正有效的提升来自增加中间监督例如让模型在训练时学会输出逐步计算的内部状态。引入外部计算工具计算器、代码解释器等。将语言模型的“通顺生成”能力与符号执行器的“精确计算”能力结合起来。6. 为什么“会说话”不等于“会推理”6.1 预训练目标的本质LLM 的预训练目标是最小化下一个 token 的预测误差。这意味着模型被迫学会的是“在给定上文的情况下哪个 token 最可能出现在这里”。在绝大多数文本中最可能的 token 是语义通顺、语法正确的延续而不是精确计算的中间结果。因此模型天然倾向于生成通顺文本而不是执行精确运算。当两者冲突时模型更倾向于选择“通顺但错误”的答案。6.2 注意力机制的限制Transformer 的注意力机制擅长捕捉输入中不同位置之间的相关性但这种相关性是软性的、分布式的。在进行字母计数时模型需要在某一个位置“精确”地知道“到目前为止统计到第几个了”。注意力机制并不能自然地提供这种精确计数能力。6.3 RLHF 的影响RLHF 等对齐技术让模型的回答更符合人类偏好但它并不能从根本上改变模型“无法精确计算”的底层架构限制。RLHF 可以提高模型在对话场景下的可用性但不能让模型获得一个新的认知能力。7. 对 LLM 应用开发的工程启示这部分是对想在生产环境中使用 LLM 的工程师最有价值的内容。7.1 不要依赖单一 LLM 做精确计算如果你的应用涉及精确计数、多步算术、状态追踪建议不要直接把任务丢给 LLM。更可靠的方案包括用代码执行器Python 解释器计算结果让 LLM 负责生成代码再由解释器执行。用正则表达式进行文本抽取和计数。用数据库查询进行聚合统计。为模型提供计算器工具function calling让它调用外部工具而不是自己心算。比如下面的思路import re text The cat sat on the mat and looked at the dog. letter a # 先用 LLM 判断任务类型再用确定性代码执行 count len(re.findall(letter, text)) print(count)7.2 使用验证器和反思循环当任务确实需要 LLM 生成答案时建议引入验证器。例如让模型生成答案后再让另一个模型或同一个模型的另一轮调用检查答案。使用外部数据源交叉验证。对数值型输出设置合理范围检查。这种“生成-验证”架构可以显著提高可靠性但代价是增加推理时延和成本。7.3 Agent 场景中要显式规划步骤如果你构建 Agent不要期望模型内部会进行真正的状态追踪。更稳妥的做法是将任务拆解为多个子任务。每个子任务的输入和输出都显式记录在上下文中。每一步的中间结果都用代码或工具验证。只有最后一步交给 LLM 进行语义整合和输出。相当于把“跳跃式推理”的压力从模型内部转移到了外部流程。8. 哪些任务可以放心交给 LLM虽然跳跃式推理是 LLM 的弱项但以下场景仍然适合使用 LLM文本理解与摘要信息密度高、不需要精确计数的任务。语义检索和匹配判断两个句子是否语义相近。知识问答基于训练数据和外部知识库的常识性回答。代码生成生成代码片段后续由编译器和解释器验证正确性。多轮对话管理理解上下文并生成自然回复。这些任务的共同点是正确答案不依赖于精确的中间状态维护而是依赖于语义理解和模式复用。9. 模型选的越大越好吗很多人习惯认为“模型越大越聪明”。但按照这篇论文的观点简单地扩大模型规模并不能解决跳跃式推理的缺陷。模型变大可能在语义理解上更强但在符号操作上的进步有限。更有效的策略包括策略原理适用场景模型 代码解释器由代码执行精确计算数学、统计、数据处理模型 检索器由外部库提供知识点知识密集型问答模型 验证器由监督环节兜底高风险生产环境多模型投票降低单次随机误差重要决策场景微调 中间监督训练模型逐步输出中间状态特定领域的可控推理这些组合策略本质上都是把“跳跃推理”拆成“模型擅长的语义理解”和“工具擅长的精确计算”再组合起来。10. 正确理解 LLM 的能力边界《LLMs Cant Jump》这篇论文真正的价值是让我们重新审视一个被过度神化的概念“大语言模型具有推理能力”。更准确的说法是大语言模型擅长语义理解、模式识别和文本生成但在需要精确状态维护和符号计算的任务上它的可靠性还远不能满足生产环境的要求。如果你正在做 LLM 应用开发我的建议是先对你的任务做一次“能力类型分类”判断它属于语义任务还是符号任务。如果是符号任务优先考虑外部工具不要把计算压力放在模型上。如果必须使用模型设计“生成-验证”流程为每一步中间结果建立明确的检查机制。不要轻视训练数据分布对模型表现的影响。模型在 benchmark 上的高准确率不一定是推理能力的证明也可能只是记忆的成功。最后也是最重要的不要让 LLM 在你的关键业务链路上“自由发挥”。把它当作一个强大的语义引擎而不是一个可靠的推理引擎。论文全文以 PDF 形式发布建议对推理机制和评估方法感兴趣的读者读一下原始实验设置。下一次遇到“让 AI 自动计算”的客户需求时你会感谢自己提前理解了这篇论文的结论。