2024年7月，一个看似荒谬的问题在社交媒体上疯传：「9.11和9.9哪个更大？」 当用户把这个问题抛给ChatGPT时，答案令人瞠目——AI一本正经地回答「9.11更大」。这不是个案。同样的测试在不同时间、不同用户那里重复了上千次，错误率高达50%。

这听起来像个笑话。一个能写诗、能写代码、能解释量子力学的系统，居然在小学数学题上翻车？更讽刺的是，当OpenAI的研究人员用GPT-4解决更复杂的数学竞赛题时，模型的表现反而更好。这背后的原因远比「AI不够聪明」复杂得多。

数字在AI眼中的真实面貌

要理解这个问题，首先要弄清楚一个关键事实：大模型从未真正「看到」过数字。

当我们输入「1234」时，模型接收到的并不是数学意义上的数值，而是一串被称为「token」的符号。这些符号如何分割，取决于一个叫做BPE（Byte Pair Encoding）的分词算法。问题在于，这个算法的设计初衷是优化自然语言处理，而不是数学计算。

以GPT系列使用的BPE分词器为例：数字「380」被编码为单个token，但「381」却被拆成两个token——[「38」,「1」]。更离谱的是，「382」又是两个token，而「383」却又变回单个token。这种看似随机的切分方式，源于BPE算法的训练语料——它倾向于将频繁出现的数字组合打包成单个token。

这种不一致性带来两个致命后果。首先，数字被切分的位置完全不可预测。一个三位数可能是1个token（如「380」），也可能是2个（如「381」），甚至可能是3个（如「1234」在某些分词器中会被拆成[「12」,「34」]）。模型必须学会处理这三种完全不同的输入结构，而每种结构对应的「算术规则」都不相同。

其次，分词方向会直接影响计算逻辑。人类做加法是从右向左（个位对齐），但BPE分词默认从左向右。当「123」被拆成[「12」,「3」]时，模型实际上看到的是「先处理高位，再处理低位」——这与标准加法算法完全背道而驰。

2024年2月，一篇发表在arXiv上的论文《Tokenization counts: the impact of tokenization on arithmetic in frontier LLMs》首次系统性地研究了这个问题。研究团队发现，如果强制模型使用「从右向左」的分词方式（通过在数字间插入逗号实现，如「1,2,3」），GPT-3.5在多位数加法上的准确率可以提升超过30%。这证明了分词方式确实是一个关键瓶颈。

概率预测器不是计算器

但分词问题只是表层原因。更深层的矛盾在于：大模型的底层架构与数学计算的本质需求存在根本冲突。

Transformer模型的核心任务是预测「下一个token」，这是一个概率问题。在自然语言中，这种概率预测非常有效——「今天天气很」后面接「好」的概率确实很高。但在数学中，概率是行不通的。$1234 + 5678$ 的答案只能是 $6912$，不是「大概6900左右」，也不是「可能是6912或6913」。

这种差异在处理大数时尤为致命。研究人员构建了一个名为GSM-HARD的数据集，将GSM8K（小学数学应用题基准）中的数字替换为更大的数值。结果令人震惊：使用思维链（Chain-of-Thought）提示的GPT模型，在原始GSM8K上准确率达到65.6%，但在GSM-HARD上暴跌至20.1%——降幅超过70%。同样的推理逻辑，仅仅因为数字变大了，模型就彻底崩溃。

原因在于，大模型在训练时见到的小数远多于大数。在常见的文本语料中，0-9这些个位数占据了绝大多数数字token的出现频率。当模型遇到「12345678」这样的大数时，它几乎没有见过类似的模式，只能「瞎猜」。

更糟糕的是，数字不「原谅」近似。在语言生成任务中，偶尔用错一个词可能无伤大雅——「我感到非常高兴」和「我感到特别高兴」意思差不多。但在数学中，一个数字的偏差就意味着全盘皆输。$1234 + 5678$ 算成 $6913$ 只差0.01%，但这个答案在数学上就是错的。

「知道」与「说出」的鸿沟

2026年2月，一篇来自约翰霍普金斯大学的论文揭示了一个更令人困惑的现象：大模型其实「知道」数字的大小，但无法正确「说出」来。

研究团队设计了一个巧妙的实验。他们使用「线性探测」（Linear Probing）技术，直接读取模型内部的隐藏状态（hidden states）。结果发现，在模型的中间层，数字的「对数大小」已经被线性编码——一个简单的线性回归就能从隐藏状态中预测出数字的近似值，相对误差只有2.3%。

更进一步，当模型处理「哪个数字更大」这类比较问题时，其内部隐藏状态编码了比较结果。一个线性分类器能达到超过90%的准确率。

然而，当同一个模型被要求口头回答同样的问题时，准确率却只有50-70%。

这意味着什么？模型内部确实「理解」了数字的大小关系，但在将这种理解转化为语言输出的过程中，出现了严重的信息丢失。研究者将这种现象称为「口头化鸿沟」（Verbalization Gap）。

更关键的是，研究发现早期的隐藏层质量与最终的口头化准确率高度相关。如果早期层对数字的编码质量高，模型最终的回答也更准确。这暗示了一个改进方向：如果能改善模型的内部数字表示，可能就能提升其算术能力。

研究团队尝试在微调时加入「探测损失」（probing loss）作为辅助目标，结果确实带来了3.22%的准确率提升。这证明了内部表示与输出行为之间存在因果联系。

为什么「9.11 > 9.9」？一个歧义问题

回到最初的问题：为什么那么多大模型认为9.11比9.9大？

这实际上是语义歧义与训练语料偏见共同作用的结果。

在数学语境中，9.11就是$9.11$，小于$9.9$（即$9.90$）。但在软件版本号的语境中，「9.11」确实比「9.9」更新——这是版本号的标准排序规则。问题在于，大模型的训练语料中包含了大量技术文档、软件发布说明，其中「版本9.11」出现时几乎总是比「版本9.9」更晚。

研究人员的实验揭示了这一点。当提示词中加入「解释你的推理」指令时，模型的准确率提升到62%。而如果将同样的指令放在系统提示（system prompt）而非用户提示中，准确率可以达到100%。

这说明模型实际上「知道」如何比较这两个数字，但它首先需要明确上下文——这是数学问题还是版本号问题？没有明确上下文时，模型会根据训练语料中的统计分布做猜测，而技术文档的流行使得「版本号解释」占据了优势。

破局之道：从思维链到程序辅助

既然直接让大模型做算术不可靠，研究者们提出了多种绕开方案。

思维链（Chain-of-Thought）

最直接的方法是让模型「一步步思考」。与其直接问「12345 × 67890等于多少」，不如引导模型分解问题：「首先计算个位数……然后处理十位……」。这种方法被称为思维链提示（CoT），在2022年由Google的研究团队提出。

CoT确实有效。在GSM8K基准上，使用CoT的GPT-3.5准确率从19.7%提升到65.6%。但这种方法有明显的局限：模型仍然需要在每一步进行数值计算，而每一步都可能出错。当数字很大时，累积误差会迅速失控。

程序辅助语言模型（PAL）

2022年底，CMU的研究团队提出了一个革命性的想法：既然大模型擅长理解问题，但不擅长计算，为什么不把计算「外包」出去？

PAL（Program-Aided Language Models）的核心思路是：让大模型生成Python代码来描述问题的解决步骤，然后把代码交给Python解释器执行。模型只需要「理解问题和规划步骤」，不需要「执行计算」。

# PAL示例：让模型生成代码而非直接计算
# 问题：Olivia有23美元，她买了5个贝果，每个3美元，还剩多少钱？

money_initial = 23
bagels = 5
bagel_cost = 3
money_spent = bagels * bagel_cost
money_left = money_initial - money_spent
print(money_left)  # 输出：8

这种方法的效果是惊人的。在GSM8K上，PAL达到了72.0%的准确率，超过了当时最大的模型PaLM-540B使用CoT的结果。更重要的是，在GSM-HARD（大数版本）上，PAL的准确率仍然保持在61.2%，而CoT从65.6%暴跌到20.1%。

工具调用与函数功能

PAL的思想已经被主流AI产品采纳。今天，大多数先进的大模型都支持「工具调用」（Tool Calling）或「函数调用」（Function Calling）。当模型识别到需要精确计算时，它会自动调用外部计算器或代码解释器。

这种「神经符号混合」的方法代表了当前的最佳实践：让神经网络做它擅长的事（理解语义、规划步骤），让符号系统做它擅长的事（精确计算）。

不是Bug，是特性

当我们说「大模型不会做算术」时，这其实是一个误解。更准确的说法是：大模型不是为算术而设计的。

Transformer架构的本质是一个概率预测器，它在自然语言处理上表现出色，是因为语言本身就是概率性的——预测下一个词的「最佳猜测」往往是「足够好」的。但数学不允许猜测。$1+1$ 只能等于 $2$，没有「大概」「可能」「通常」。

从这个角度看，大模型在算术上的「失败」不是能力缺陷，而是架构特性。就像不能指望计算器写诗，也不能指望语言模型天生就是计算器。

但这并不意味着我们只能接受这个现状。PAL和工具调用已经证明，通过「外包」计算任务，我们可以获得两全其美的结果。而更根本的解决方案可能在于重新思考数字的表示方式——比如使用专门的数字分词器，或在训练时引入数学推理的显式监督。

2024年的研究《Language Models Encode Numbers Using Digit Representations in Base 10》发现，模型内部其实已经学会了「按位表示」数字——每个数字位的值被编码在一个环形空间中。这意味着模型具备「理解」数字结构的潜力，只是缺乏将其转化为精确计算的能力。

下一个十年的挑战，或许不是让模型「学会算术」，而是让模型知道自己什么时候需要帮助，并主动寻求工具的支援。

参考文献

  1. Singh et al. (2024). Tokenization counts: the impact of tokenization on arithmetic in frontier LLMs. arXiv:2402.14903.

  2. Yuchi et al. (2026). LLMs Know More About Numbers than They Can Say. arXiv:2602.07812.

  3. Gao et al. (2022). PAL: Program-aided Language Models. PMLR v202.

  4. Levy & Geva (2024). Language Models Encode Numbers Using Digit Representations in Base 10. arXiv:2410.11781.

  5. Wei et al. (2022). Chain-of-Thought Prompting Elicits Reasoning in Large Language Models. arXiv:2201.11903.

  6. Cobbe et al. (2021). Training Verifiers to Solve Math Word Problems. arXiv:2110.14168 (GSM8K Dataset).