如果你曾让大语言模型 (LLM) 比如 ChatGPT 或 Llama 解决一个复杂的数学应用题，你可能已经注意到了一个令人沮丧的模式。有时，它完全理解逻辑，但在简单的算术上却一败涂地 (比如产生幻觉认为 \(25 \times 14 = 300\)) 。而另一些时候，它编写了一个 Python 脚本来解决问题，但这个脚本解的却是完全错误的方程。

这种不一致性凸显了 AI 推理中的一个主要分歧。一方面，我们有 思维链 (Chain-of-Thought, CoT) , 即模型用自然语言解释其推理过程。这对逻辑很有帮助，但容易出现计算错误。另一方面，我们有 思维程序 (Program-of-Thought, PoT) , 即模型编写代码来计算答案。这解决了计算问题，却引入了一个新问题: 模型往往无法将应用题转化为正确的代码逻辑。

在一篇题为 “How Do Humans Write Code? Large Models Do It the Same Way Too” 的精彩新论文中，研究人员提出了一种名为 人类思维语言 (Human-Think Language, HTL) 的新颖框架。他们的前提简单而深刻: 人类不只是直接开始敲代码；我们会先用母语思考问题，然后将思维过程翻译成代码。通过强迫模型做同样的事情——并使用一些巧妙的注意力机制来强制执行——他们在数学推理基准测试中取得了最先进的结果。

在这篇文章中，我们将拆解这篇论文，以理解为什么当前的模型在数学上会失败，HTL 如何模仿人类的认知，以及使其发挥作用的具体机制 (聚焦注意力和强化学习) 。

核心问题: 代码翻译错误

要理解为什么我们需要 HTL，我们首先必须看看为什么当前的“思维程序” (PoT) 方法会失败。

PoT 本应是数学问题的灵丹妙药。我们要做的不是让 LLM 在脑海中计算 \(543 \times 92\) (这是它不擅长的) ，而是让它写出 print(543 * 92)。Python 解释器运行代码，然后我们得到完美的答案。

然而，研究人员发现了一个关键弱点: 代码翻译错误 (Code Translation Error, CTE) 。 当问题以对话方式表述时 (例如，“一个苹果三美元，三个苹果多少钱？”) ，PoT 模型经常误解语义细微差别，并编写出使用错误公式或变量的代码。

图 1: 图表上半部分代表了各模型在 5 个数据集上的平均 CTE。下方是使用 MAmmoTH-Mistral-7B 模型在 Asdiv 数据集上的真实示例，显示了很高的错误率。

如 图 1 所示，错误率高得惊人。即使是像 GPT-4 这样的强大模型和像 MAmmoTH-Mistral 这样的微调模型也深受 CTE 之苦。柱状图显示，仅仅增加模型的大小 (从 7B 到 34B 参数) 并不能解决这个问题。图片的下半部分展示了一个真实的例子: 模型读取了一个关于小组人数的问题，但编写的代码只是简单地将数字相加，而没有遵循问题的逻辑 (写了 TotalPeople = 54 + 17 而不是求解实际的未知数) 。

为什么会发生这种情况？

作者认为，发生这种情况是因为自然语言的预训练数据 (万亿级 token) 在数量上远超代码数据 (十亿级 token) 。自然语言仅仅是更擅长语义分析和规划。当我们强迫模型直接从应用题跳转到 Python 代码时，我们跳过了模型最强的能力: 语言推理。

让我们看一些翻译崩溃的具体例子。

图 5: CoT 正确但 PoT 错误的示例。该图突出了代码生成中的逻辑错误，例如错误的减法顺序或变量初始化。

在上面的 图 5 中，我们看到了一些逻辑 (CoT) 正确但代码 (PoT) 失败的典型案例:

  1. 问题 1 (公交车) : CoT 正确地推断出如果有 10 个孩子下车，你应该减去他们。然而，PoT 代码写出的公式导致了一个负数 (-15) ，这对于儿童数量来说在物理上是不可能的。
  2. 问题 3 (书本与可动人偶) : CoT 正确地识别了比较关系。PoT 代码执行了一个减法，结果是 -4，未能理解“多了多少”的概念。

结论是: CoT 拥有正确的推理“骨架”，即使数学算错了。PoT 拥有正确的计算器，但往往用错了骨架。

解决方案: 人类思维语言 (HTL)

研究人员提出了 人类思维语言 (HTL) 来实现两全其美。核心思想是改变生成流程，以匹配人类的认知过程。

当人类程序员解决数学问题时，他们不会立即幻想 Python 语法。他们会想: “好吧，我需要算出苹果总数。首先我用树的数量乘以每棵树的苹果数，然后加上现有的苹果。” 只有在建立这个逻辑之后，他们才会写出 total = (trees * apples_per_tree) + existing。

HTL 强制执行这个两步过程:

  1. 生成思维链 (CoT) : 模型首先输出完整的自然语言解释。
  2. 生成思维程序 (PoT) : 然后模型生成代码，但是——这是关键的创新点——它被设定为基于 CoT 推理来编写代码，而不仅仅是基于原始问题。

图 3: HTL 的一个成功示例。虽然 CoT 的答案包含计算错误 (红色) ，但推理骨架是正确的。PoT 代码遵循此骨架得出了正确结果。

图 3 完美地展示了这一点。在 CoT 部分，模型试图做数学计算但失败了 (它认为 \(60/2 = 30\)，这是对的，但在其他地方犯了错或产生了幻觉) 。然而，逻辑步骤是完美的。下方的 Python 代码忽略了错误的数学计算，而是将这些步骤翻译成使用 sympy 库的 solve 函数。结果是从正确的逻辑推导出的正确答案，并由完美的计算器执行。

技术创新: 如何强迫模型“倾听”自己的思想

你可能会问，“难道我们不能直接提示模型‘一步步思考’然后再写代码吗？”你可以，但现有的“混合”方法往往会失败，因为模型会被原始问题分心或迷失其推理方向。

为了解决这个问题，作者引入了一种名为 聚焦注意力 (Focus Attention) 的机制。

1. 聚焦注意力机制 (Focus Attention Mechanism)

标准的 Transformer 使用“稠密注意力 (Dense Attention) ”，意味着每个 token 都会关注之前的每一个 token。在 HTL 中，研究人员希望代码 (PoT) 主要关注推理 (CoT) 并尽可能忽略原始问题 (Q) ，以防止前文讨论的“翻译错误”。

图 2: 稠密注意力与聚焦注意力的比较。聚焦注意力在 PoT 阶段屏蔽了问题 (Q) ，强迫模型依赖 CoT。

如 图 2 直观所示, 聚焦注意力在生成 PoT token 时屏蔽了问题 token。模型被迫关注 CoT token。

不过，这里有个陷阱。最近关于“注意力汇 (Attention Sinks) ”的研究表明，如果你屏蔽掉句子的最初几个 token (序列的开始) ，LLM 的性能会大幅下降，因为它们使用这些初始 token 作为注意力的锚点。为了解决这个问题，HTL 保留了序列的前四个 token (“注意力汇”) ，并屏蔽了问题的其余部分。

掩码矩阵 \(M_{ij}\) 的数学定义如下:

定义掩码矩阵的方程。它显示仅允许关注前 4 个 token 和 CoT token，否则将被阻断。

在这里，注意力分数是 \(-\infty\) (被屏蔽) ，除非被关注的 token (\(j\)) 是前四个 token 的一部分或者 CoT 的一部分。这强制信息流向为: 推理 \(\rightarrow\) 代码。

然后使用此掩码应用标准的注意力机制:

结合了掩码 M 的标准 Softmax 注意力方程。

2. 自适应训练策略 (Adaptive Training Strategy)

如果从第一天起就用这种严格的“聚焦注意力”训练模型，或者如果在推理过程中直接使用它而不进行训练，它的表现通常很差，因为这造成了与预训练数据 (使用稠密注意力) 的不匹配。

为了弥合这一差距，作者开发了一种 自适应训练策略 。 他们引入了一个随时间变化的“掩码覆盖函数”。

  1. 开始: 使用稠密注意力 (关注所有内容) 。
  2. 中间: 使用二次函数逐渐增加屏蔽 (聚焦注意力) 。
  3. 结束: 回到稠密注意力。

方程 3: 掩码覆盖函数。这是一个二次函数，根据训练步数决定被屏蔽条目的百分比。

这种“抛物线”式的训练计划允许模型在不破坏其处理序列的通用能力的情况下，学习 CoT 和 PoT 之间的依赖关系。

3. 基于 PPO 的强化学习

LLM 的另一个问题是它们有时会陷入死循环，一遍又一遍地重复相同的推理步骤。此外，有时 CoT 是对的但 PoT 是错的，反之亦然。

为了打磨模型，研究人员应用了强化学习 (具体来说是近端策略优化，即 PPO) 。他们设计了一个特定的 错误评估函数 作为奖励模型。

方程 4: 基于 CoT 和 PoT 正确性的奖励函数。

奖励函数 \(f_r\) 根据结果分配分数:

  • 1.0 分: CoT 和 PoT 都正确。 (理想状态) 。
  • 0.6 分: CoT 错误，但 PoT 正确。 (这表明模型可能只是运气好，或者代码修复了推理错误) 。
  • 0.3 分: CoT 正确，但 PoT 错误。 (这就是我们想要最小化的代码翻译错误，但我们仍然对正确的推理给予轻微奖励) 。
  • 0.0 - 0.1 分: 失败。

这种细粒度的奖励系统不仅鼓励模型得出正确答案，还鼓励其将其自然语言推理与代码执行对齐。

实验结果

研究人员在 8 个数据集 上测试了 HTL，范围从标准数学应用题 (GSM8K) 到更复杂的科学数学 (MATH) 和自然语言推理 (NumGLUE) 。他们使用 MAmmoTH (基于 CodeLlama-7B 和 Mistral-7B) 作为基础模型。

1. 它打败了基线模型吗？

是的，显著超越。

表 2: 比较 HTL 与 GPT-4、MAmmoTH 和 ToRA 等基线模型在各数据集上的实验结果。

表 2 详细列出了性能。以下是亮点:

  • 最先进水平 (SOTA) : HTL 在这些基准测试中取得了开源模型中的最高平均性能。
  • 超越基础模型: 在 Mistral-Base 上，HTL 将平均准确率从 67.33% (标准 PoT) 提高到了 71.67% 。
  • 域外迁移: 注意 NumGLUE (一个需要大量逻辑的数据集) 上的表现。HTL 得分为 78.3% , 显著高于标准 PoT 的 73.9%。这证实了“先思考”的方法对逻辑推理任务有显著帮助，而不仅仅是纯粹的计算。

2. 聚焦注意力和强化学习真的重要吗？

作者进行了消融实验 (移除系统的部分组件以观察影响) 。

  • HTL (-): 仅使用数据集格式 (Q -> CoT -> PoT) 而不使用特殊的注意力机制提供了一点提升。
  • +focus: 添加聚焦注意力提供了巨大的提升 (例如，在 Llama 上平均 +3%) 。
  • +RL: 强化学习进一步增加了收益，特别是在稳定性和防止在像 MATH 这样的困难数据集中出现重复循环方面。

3. 减少错误

我们在文章开头讨论了代码翻译错误 (CTE) 。HTL 修复了它们吗？

图 4: 柱状图显示了使用 HTL 后代码推理错误和代码执行错误相较于基线的减少情况。

图 4 显示了错误分类。浅蓝色柱 (HTL) 始终低于深蓝色柱 (Baseline) 。

  • 代码推理错误 (CTE) : 这是模型编写错误逻辑的地方。HTL 显著减少了这种情况 (例如，在 GSM8K 上从 40.4% 降至 33.5%) 。
  • 代码执行错误: 这是代码语法错误或不可执行的地方。HTL 也减少了这类错误，这可能是因为 CoT 提供了一个清晰的计划，使得编写有效代码变得更容易。

4. 数据集构成的影响

研究人员还探索了不同训练数据如何影响结果。他们使用了一种称为 自蒸馏 的技术，使用 MAmmoTH 模型本身生成自己的训练数据，并筛选出正确的答案。

表 4: 训练子集分析。显示混合数据集 (GSM8K + NumGLUE + MATH) 比在单个数据集上训练产生更好的平均性能。

表 4 揭示了多样性很重要。仅在 GSM8K 上训练使模型在 GSM8K 上表现出色，但在其他方面表现不佳。混合数据集 (“G+N+M”行) 提供了最稳健的“通才”数学解题器。

结论与启示

这篇“人类思维语言”论文为 AI 推理的未来提供了一个令人信服的叙述。它挑战了单纯靠增加参数来解决问题的趋势。相反，它表明 认知架构——信息处理的顺序和方式——同样重要。

通过承认大语言模型本质上是“语言”生物，HTL 利用它们的优势 (语言推理) 来支持它们的弱点 (符号计算) 。

主要结论:

  1. 思考先于编程: 强迫模型在编写代码之前用自然语言进行推理，可以减少逻辑错误。
  2. 注意力机制是灵活的: 我们不必接受标准的“关注所有内容”的注意力。通过巧妙地屏蔽输入，我们可以引导模型关注最相关的上下文 (推理) ，从而提高保真度。
  3. 强化学习微调: PPO 不仅仅用于聊天机器人；通过奖励思想和行动之间的一致性，它在对齐多阶段推理任务方面非常有效。

随着我们迈向能够执行复杂任务的智能体，这种“先思考，后行动”的范式很可能会成为可靠 AI 的标准蓝图。