LLM跳跃式推理缺陷：从“背答案”到真推理有多远？

最近一篇论文标题很有意思，叫《LLMs Can't Jump》。一句话解释：大语言模型在需要“回溯上下文、跳过中间步骤、重新计数”这类跳跃式推理任务上，表现远没有想象中可靠。这篇文章不是教你怎么部署一个开源模型，而是帮你搞清楚一个更根本的问题：LLM 的推理能力到底是从训练数据里“背”出来的，还是真的学会了推导？如果你在做 Agent、RAG、自动化测试或者 LLM 应用评估，这个问题的答案直接影响你的技术选型和 Prompt 设计。

论文核心观点可以概括为三点：

• LLM 在“从通顺文本中提取/恢复信息”的传统 NLP 任务上表现很好，但在“需要进入执行模式的跳跃式推理”任务上表现很差。
• 即使训练数据里包含大量类似例子，模型性能提升也相当有限。
• 模型与人类处理这类推理的方式有本质差异，现有评估框架容易高估模型能力，尤其是包含思维链（CoT）提示时。

下面的内容我会从论文的推理逻辑、实验设计、结果分析和工程影响几个维度展开，最后给出对 LLM 应用开发和模型选择的建议。文章不涉及具体部署命令，侧重算法与推理能力分析。

1. 核心观点速览

这个表可以快速传达论文最重要的结论。下面展开分析。

2. 什么是“跳跃式推理”

2.1 定义

“跳跃式推理”指的是模型在执行任务时，必须跳过文本表面的流畅性，进入一种类似计算机执行的模式。具体来说，模型需要：

1. 从上下文中恢复一个状态（例如“当前计数为多少”）。
2. 执行一个操作（例如“加 1”）。
3. 将结果重新写回上下文，并继续执行后续步骤。

这种推理方式在人类看来很简单，但它并不符合语言模型“逐词预测下一个 token”的天然工作方式。语言模型在预训练阶段学习到的统计规律，本质上倾向于生成通顺、合理的文本，而不是执行精确的计算。

2.2 与传统 NLP 任务的区别

传统的 NLP 任务，例如情感分类、主题分类、填词，都可以通过模式匹配或上下文检索完成。模型只需要“读”文本，然后在记忆中找到最相似的范式，输出即可。这类任务并不需要精确维护中间状态。

跳跃式推理任务则完全不同。以论文中可能涉及的单词计数任务为例：

输入文本是一段通顺的话：

“The cat sat on the mat and looked at the dog.”

任务是：“这句话里有多少个字母 'a'？”

要回答这个问题，模型必须：

• 忽略句子语义，将注意力放在字符级别。
• 逐个字符检查，统计目标字母出现次数。
• 保持计数状态，不能遗漏、不能重复。

这个任务对于人类来说很简单，但对于以“下一个词预测”为目标训练的 LLM，却非常困难。因为模型在训练时，很少会碰到“数清楚一段自然语言中某个字符出现次数”这种需求，它的注意力机制天生更关注语义层面的相关性，而不是字符层的精确计数。

2.3 跳跃式推理的三个关键操作

论文讨论的跳跃式推理，我认为可以拆解为三个关键操作：

1. 暂停生成：模型需要抑制“继续输出通顺文本”的默认行为。
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-Thought，CoT）提示虽然能提升模型在某些推理任务上的表现，但对于跳跃式推理的改善有限。

原因在于：CoT 本质上是让模型“说人话式地分步推理”，但模型生成的中间步骤并不保证正确。模型可以生成看起来合理的推理过程，但其中的状态更新可能是错的。

举例来说，模型可能会这样回答字母计数问题：

让我逐个检查这句话中的字母 'a'： 1. The -> 没有 'a' 2. cat -> 有 1 个 'a' 3. sat -> 有 1 个 'a' ... 所以共有 3 个 'a'。

这个推理过程看起来非常合理，但模型在“逐个检查”这一步，可能并没有真的逐个检查。它只是生成了一段看似在检查的文本。因此，最后的答案并不比直接回答更可靠。在某些情况下，CoT 甚至可能让模型更自信地输出错误答案。

4.4 模型与人类的推理机制存在本质差异

人类在解决跳跃式推理问题时，会明确切换认知状态：从“阅读理解模式”切换到“执行计算模式”。在这个过程中，我们会暂停语义理解，将输入符号化，然后按规则逐步操作。

LLM 没有真正的“执行模式”。它的每一步输出都是在预测下一个 token，这个预测基于的是海量文本中学到的统计规律。它并不会真正“暂停”并“执行计算”，只是生成看起来像计算过程的文本。

这个差异解释了为什么模型在跳跃式推理上表现不佳，也解释了为什么简单的“更大模型”和“更多数据”并不能根治这个问题。

5. 实验结果的具体表现

虽然论文的具体数值需要以正式发表的版本为准，但根据通常的实验设计，可以预期以下表现模式：

5.1 任务类型与准确率矩阵

这个矩阵说明：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，不要期望模型内部会进行真正的状态追踪。更稳妥的做法是：

1. 将任务拆解为多个子任务。
2. 每个子任务的输入和输出都显式记录在上下文中。
3. 每一步的中间结果都用代码或工具验证。
4. 只有最后一步交给 LLM 进行语义整合和输出。

相当于把“跳跃式推理”的压力从模型内部转移到了外部流程。

8. 哪些任务可以放心交给 LLM

虽然跳跃式推理是 LLM 的弱项，但以下场景仍然适合使用 LLM：

• 文本理解与摘要：信息密度高、不需要精确计数的任务。
• 语义检索和匹配：判断两个句子是否语义相近。
• 知识问答：基于训练数据和外部知识库的常识性回答。
• 代码生成：生成代码片段，后续由编译器和解释器验证正确性。
• 多轮对话管理：理解上下文并生成自然回复。

这些任务的共同点是：正确答案不依赖于精确的中间状态维护，而是依赖于语义理解和模式复用。

9. 模型选的越大越好吗

很多人习惯认为“模型越大越聪明”。但按照这篇论文的观点，简单地扩大模型规模，并不能解决跳跃式推理的缺陷。模型变大，可能在语义理解上更强，但在符号操作上的进步有限。

更有效的策略包括：

这些组合策略，本质上都是把“跳跃推理”拆成“模型擅长的语义理解”和“工具擅长的精确计算”，再组合起来。

10. 正确理解 LLM 的能力边界

《LLMs Can't Jump》这篇论文真正的价值，是让我们重新审视一个被过度神化的概念：“大语言模型具有推理能力”。更准确的说法是：大语言模型擅长语义理解、模式识别和文本生成，但在需要精确状态维护和符号计算的任务上，它的可靠性还远不能满足生产环境的要求。

如果你正在做 LLM 应用开发，我的建议是：

1. 先对你的任务做一次“能力类型分类”，判断它属于语义任务还是符号任务。
2. 如果是符号任务，优先考虑外部工具，不要把计算压力放在模型上。
3. 如果必须使用模型，设计“生成-验证”流程，为每一步中间结果建立明确的检查机制。
4. 不要轻视训练数据分布对模型表现的影响。模型在 benchmark 上的高准确率，不一定是推理能力的证明，也可能只是记忆的成功。
5. 最后，也是最重要的：不要让 LLM 在你的关键业务链路上“自由发挥”。把它当作一个强大的语义引擎，而不是一个可靠的推理引擎。

论文全文以 PDF 形式发布，建议对推理机制和评估方法感兴趣的读者读一下原始实验设置。下一次遇到“让 AI 自动计算”的客户需求时，你会感谢自己提前理解了这篇论文的结论。