LLM（大语言模型）无法对数字进行准确运算的底层原因是什么？

AI创造

The era of AI is in Blueeye Media

点开音乐边听边看☝（今天推荐《单身情歌》

当前主流 LLM 架构目前在一些长文本上的状态管理上就是有问题的，你不强制 LLM 遵循某个思维过程去解题，硬框住 LLM，只要求 LLM 依靠概率统计 decode，无论你如何修改 tokenize 都是徒劳，一定会给你飘。

打个比方，考虑两个超级大数字a 和 b的加法，旧版本的 LLM 仍然会概率出错，比如 gpt4 就能出错（我 gpt 问金融问题太多，被大爷 openai 封号了，可怜我 1000 多元，只能用 coze调用的 gpt-4-8k 演示）

我觉得大家关注LLM为什么做不好数字运算，是因为这触及到现有LLM的两个本质问题，而不单纯是数学运算：

OOD问题怎么办？我的数据集里根本没有许多数学算式，那我就得不到关于数学运算的好的tokenizer，也学不到好的预测分布

为何做不到reasoning？数学运算是一个很基本的reasoning问题，你让他计算两位数加法，他必须做到个位对齐、加法进位、高位到低位输出，这本身在强迫他进行reasoning。就好像很多很多采访里Hinton和ilya说的那样，next token pred在强制模型进行reasoning，只不过他们说这话的上下文是在自然语言的setting下。

这两个问题都没得到好的解决。数字运算是二者兼有的：缺少数据的问题下的reasoning。

但是如果你真正针对LLM做数学运算去设计inductive bias，其实有些走偏了。知乎有一个问题是神经网络能判断奇偶性吗，就是这个意思，如果你设计inductive bias比如给一个关于奇偶性的encoding比如三角函数，那神经网络当然能解决，但是这只是你在设计某种rule进去，能说明什么呢？你设计某种特殊的tokenizer去解决数字运算问题，他对一般的自然语言OOD或者reasoning问题能带来什么启示吗？没有。

“LLM能通向AGI”这一观点的反对者经常提这个问题：你们整天吹LLM会达到AGI，可为啥大模型连最简单的“多位数加法”都做不好？这质疑对很多AGI信奉者来说是很扎心的，不好反驳，因为大模型做多位数加法这种简单数学确实有困难。不过，目前基本已能理清其主要原因，大部分也获得了解决，我归纳了下，有如下几点：其一，LLM的 Tokenizer对数字切分问题早期LLM的Tokenizer一般不会对数字进行特殊处理，经常把连续的若干数字切在一起形成一个Token，比如“13579”，可能被切成三个Token ,“13”是一个，“57”是一个，“9”是一个Token，类似这种。谁和谁被切在一起组成Token，这取决于做Tokenizer的数据集合里的统计情况，俗称看命。在这种不确定哪些数字片段组成一个Token的情况下，LLM要想做对多位数字数值计算，不说不可能，即使可能也是非常困难的。不过，这个问题早已被解决掉了。

我记忆中最早看到解决这个问题的公开文献是LLama-1的技术报告（23年2月），里面提到了每个数字会被单独切分成一个Token，之后这基本是个标准做法，目前绝大多数大模型应该都是这么做的。把每个数字单独切开，这是必要条件，但是不充分，不是说这么做了之后LLM就能很好地做数学计算了。其二，数字序列输入LLM的顺序问题通常我们让LLM做数学题，都是正向输入的，比如要让LLM计算“13579+24680”，就按照这个顺序输入，高位在前，低位在后。但是………这么做从大模型的运行机制角度看，很明显是有点问题的（您可以想下为啥会有问题）。正确的做法应该是逆序输入，就是把“13579+24680”转成“97531+08642”，每个数值低位在前，高位在后。经过如此简单改造，LLM计算多位数加法效果提升非常明显（可参考下面的图2）。

这是为啥呢？其实好理解。我们知道，LLM是通过Next Token预测，一次输出下一个Token来生成结果的。如果你按照“13579+24680=”顺序输入给LLM，Next Token就要求先输出计算结果的最高位，这意味着LLM必须在内部把完全正确的加法结果38259算完，而且得找地方存起来，然后再先输出高位3，再输出次高位8（这种类似想好了再说）…..这无疑人为给LLM增加了学习难度，不匹配LLM这种一次产生一个Token的模式（Next Token这种模式类似边说边想，而不是想好了再说，GPT在这方面确实有明显弱点）。即使是我们人类在计算多位数加法的时候，也是先把两个运算数值串中的各个数字由低位到高位一一对齐，然后从右到左，也就是先算低位两个数字加法，如果有进位则把进位往高位传。从低位往高位算降低了学习难度，这等于把一个复杂的多步推理问题，分解为连续的两个单位数加法的简单问题。两个单位数加法的组合空间相当有限，仅有100种组合（10*10），再加上有没有进位的两种情况（有进位／没有进位），则两个单位数加法只有200种组合可能性，这个组合空间很小，要让LLM学会这个看上去难度不大，哪怕你硬记也记住了。这是为何逆序输入数字能明显提升LLM数学计算能力的原因，一方面极大降低了学习难度，另一方面比较匹配LLM的Next Token这种“边说边想”的输出模式。其三，LLM数字对齐问题即使把数字逆序输入给LLM，整体效果虽然有明显提升，但仍然不足够好。前面提到过，人在计算多位数加法的时候，首先需要把两个数值串对应位的数字从低位到高位对齐，然后从低位到高位计算，这样学习任务就比较简单。

现在我们逆序输入数值，可以保证让LLM由低位到高位顺序运算，但是为啥效果仍然不够好呢？问题出在数字对齐上。目前研究发现，LLM在做数学运算的时候，经常对不齐相应位置的数字，比如“13579+24680”，3本来应该对齐4，但是LLM经常把3对到4附近的数字，比如2或者6上，这自然会产生运算错误。数字对不齐，这锅得Transformer里的Self Attention或者Position Embedding来背，说明相对位置编码（PE）或者检索字符(MHA)有问题。目前解决数字对不齐有两种很有效的做法。一种是加入位置提示（Hint），比如“13579+24680”，每个位置加入提示字符，形成“a1b3c5d7e9+a2b4c6d8e0”这种输入形式，相同位置数字有个共同的提示字符，这很可能利用了Induction Head的作用（我猜的），可以有效帮助LLM对齐数字。另外一种做法是对每个数字Chunk单独引入新的位置编码（Abacus Embedding），如下图所示：

图1: Abacus Embedding(from: Transformers Can Do Arithmetic with the Right Embeddings)

对于每个数字块，第一个字符引入位置编码1，后续数字依次递增。这样，因为相同位的数字有相同的位置编码，所以有利于解决LLM数字对不齐的问题。其四，LLM长度外推能力弱LLM长度外推能力弱的意思是：比如我们在训练LLM的时候，LLM见过的最长的数字串长度是10位，如果训练数据够多，LLM做10位数以内的加法问题不大，但实际使用的时候，若给出20位长度的数字要求做加法，就容易算错。“没在训练过程中见过类似长度的就做不好”，这就是LLM长度外推能力弱的表现。长度外推能力弱这个责任，Transformer里的Position Embedding需要扛起来。目前研究结论是，起码对于数值运算来说，FIRE（Functional Interpolation for Relative Position Embeddings ）是长度外推能力最强的相对位置编码。

图2:FIRE外推能力较强，即使不把数字逆序输入，外推能力也能达到很好的水准 (From：Transformers Can Achieve Length Generalization But Not Robustly)

增强数值计算长度外推，只用FIRE也不够，在训练过程中还要配合“Randomized Position Encodings”技巧,才能大幅增加LLM数学运算长度外推能力。所谓“Randomized Position Encodings”，我们拿Abacus Embedding做为例子来说明，比如训练数据中包含的数字最大长度为10，但是我想外推到100位的多位数加法。那么，在训练的时候，数值块中第一个数字的Abacus位置索引不要从1开始，而是在比如[0,100]之间随机取一个数值，后续数字位置索引在这个随机数基础上递增，以保持数字索引顺序。

当然，同一个加法运算涉及到的两个数，都要采取相同的起始编号（随机抽一次，两个数同时用），这样才符合上面讲的解决数字对齐问题的思路。训练时候随机抽，但在实际运用的时候，恢复从1开始的起始编号。这就是“Randomized Position Encodings”的具体含义与做法。它本质上做的是：在训练的时候，就把没有见过的[11,100]之间的外推位置，学到对应的Position Embedding，这样将来哪怕真碰见了这么长的位置编码也不怕。这么个思路。FIRE结合“Randomized Position Encodings”，以及上面提到的逆序输入和数字对齐，最长的长度外推能力可以达到6倍左右，就是说训练时见过的最大数值长度如果是10位，那就能支持60位长度的外推运算能力。其五，大模型幻觉（个人猜测，无依据）采取上述一系列措施，大体能解决较长的数字加减法或乘法问题，比如100位长度加法准确率可以达到92%到97%之间。但是，仍然有不太低的错误率，而且随着长度加大，错误率会更高。也就是说，看上去很容易的问题，LLM能解决得还不错，但不完美。

这又是为啥呢？我个人猜测：这估计跟大模型幻觉脱不了干系。假设LLM输出Token有一个量化的幻觉衡量标准叫做“幻觉率”，就是说LLM输出100个Token，有多少是幻觉Token，如果有3个，那“幻觉率”就是3%。幻觉率并不好测量，因为有些幻觉Token你觉察不出来，比如生成创意问题，里面肯定有幻觉Token，但是你感知不到。只有输出答案每一个都有标准答案的场景，才能正确检测大模型的“幻觉率”（目前也有用事实性知识来量化测量大模型幻觉程度的）。

我觉得多位数加法可能是个检测大模型“幻觉率”的好的场景，因为输出结果每一Token都有标准答案，而且目前该做的改进也基本都做了，从错误分析来看很难再找出系统性的错误方向，那剩下的错误貌似只能靠幻觉来背了。之所以大模型仍然有3%到7%的加法运算错误，大概因为目前大模型的幻觉率在这两个数字之间，所以每输出100个数字Token，就会有相应比例的幻觉Token，导致计算错误 。当然，个人猜测未必对。如果万里有一是对的，这意味着，如果幻觉问题不解决，LLM的长数字运算很难达到完美准确率，基本无解。当然你说可以用外挂计算器，那是另外的思路，不在这个主题的讨论范围。

先说设计目的，大语言模型（LLM），例如GPT系列，最初设计的目标是处理和生成自然语言文本。它们的主要任务是理解上下文、生成连贯的句子和段落，而不是进行精确的数值计算。

这就像训练一个人写小说和训练一个人做数学题，用到的方法和目标完全不同。写小说需要创造力和语言技巧，而做数学题需要逻辑和精确性。

LLM在“写小说”方面表现得很出色，但在“做数学题”方面则显得力不从心。

再说训练数据的问题，LLM通过大量的互联网文本数据进行训练，这些数据主要包括书籍、文章、对话等，内容广泛但杂乱。这些文本数据帮助模型学习语言模式和上下文关系。

然而，数学计算需要的精确性和一致性在这些文本中并没有得到特别强调。虽然这些数据中也包含一些数学内容，但占比非常小，导致模型没有足够的机会学习和掌握数学计算的细节。

LLM使用的架构（比如Transformer）非常适合处理语言模式和上下文关系。Transformer通过一种叫“注意力机制”的方法来理解句子中各个部分之间的关系。这个机制可以有效地捕捉文本中的依赖关系，使得模型能够生成上下文连贯的语言。然而，这种机制并不擅长处理需要精确步骤和逻辑的数学计算。

换句话说，LLM擅长理解语言中的模糊性和灵活性，而数学则要求严格的准确性和逻辑性。数学计算需要一步步推导和精确的数值操作，而LLM在这种任务上容易出现错误。

先说最著名的Tokenizer问题。

在LLM中，tokenizer负责将输入文本拆分成更小的部分（tokens）供模型处理。然而，现有的tokenizer并没有专门为数学设计。这导致数字在分割时可能被拆成不合理的部分。

举一个大家都不陌生的例子，数字“1234”可能被分成“12”和“34”，或者小数“3.14”被分成“3”、“.”和“14”，破坏了数字的整体性，使得模型难以理解和计算这些数字。

就因为这样的分割不仅使得模型在处理单个数字时变得困难，还会在运算过程中产生额外的误差。所以，Tokenizer问题也是最直观认为影响LLM运算准确性的一个常见原因。

LLM在处理文本时受制于上下文窗口的长度限制。对于复杂的数学计算，尤其是涉及多步计算的问题，这个限制可能导致模型无法一次性处理所有必要的信息。

例如，假设你要解一个复杂的数学方程，这个方程需要多步推导才能得到最终结果。如果模型的上下文窗口只能容纳方程的部分信息，它就无法同时看到所有的推导步骤。这就像在解一道复杂的数学题时，如果你只能看到题目的一部分，而看不到完整的步骤和中间结果，你很难做出正确的解答。甚至，即使能看到题目的一部分，解答过程中你也可能需要频繁地回头看前面的步骤，但由于上下文窗口的限制，模型可能无法记住所有之前的步骤，导致在后续推导中出错。

此外，对于涉及长公式或需要记住多步中间结果的计算问题，这个限制尤为明显。例如，在进行积分计算、求导步骤或者长时间的代数运算时，模型可能无法保留所有中间步骤的信息，从而导致结果不准确。

这种情况下，模型无法在一个统一的上下文中保持所有相关的计算步骤，计算的连贯性和准确性就会受到影响。

还有就是，数学运算涉及各种符号（如+、-、*、/）和操作。LLM在处理这些符号时，可能会因为训练数据中符号使用的多样性和不一致性而产生误解。在自然语言中，同样的符号可能有不同的含义。例如，“+”在自然语言中可能表示积极的态度，而在数学中它表示加法运算。这样的歧义会导致模型在数学计算时无法正确识别和应用这些符号，进而影响计算结果的准确性。

如何提升LLM在数学计算上的能力？

除了设计与训练以及技术限制之外，LLM在实际应用中的数学计算能力也受到了诸多因素的影响。

在多步数学计算中，即使初始步骤中的误差非常小，也可能在后续步骤中逐步放大，最终导致结果出现显著偏差。

LLM在生成每一步计算时，依赖于前一步的输出。如果前一步存在误差，那么这个误差会传递到下一步，并且可能会被放大。

LLM的设计目的是广泛适应各种语言任务，这意味着模型的参数被优化以处理多种多样的语言输入。然而，这并不意味着模型能够很好地处理所有类型的数学问题。模型在面对不同类型的数学运算时，可能会因为缺乏足够的专门训练数据而表现不佳。

传统的数学软件通过显式编码数学规则和公式来进行计算。而LLM主要依赖于从训练数据中学习到的模式，这种方式在处理复杂数学推理和计算时显得力不从心，因为它缺乏对数学定理和算法的深层理解。

例如，当要求LLM进行复杂的数学推导或证明时，模型只能依赖它从文本中学到的模式，而不是明确的数学规则。这种方式在面对复杂的数学问题时，容易出现错误或不准确的结果。

这些都是造成LLM数学能力显得很弱的原因。但这也不代表LLM本身强大的能力被否定。

通过增加包含数学计算和推理的数据集，模型可以更好地学习如何进行精确的数学运算。例如，收集和使用更多数学教科书、论文以及包含复杂数学问题和解答的数据库，可以帮助模型更好地理解数学概念和运算步骤。

在LLM的基础上，集成专门的数学计算模块，使其在需要进行复杂数学运算时能够调用这些模块来提高准确性。这些模块可以使用传统的数学计算方法和算法来确保结果的精确性。

例如，在处理复杂的积分或微分计算时，可以调用数学模块来进行精确计算，而不是依赖于LLM的推测。

开发能够识别和保留数字整体性的tokenizer，使得模型在处理数字时不至于破坏其结构。例如，设计一个专门针对数学表达式的tokenizer，确保数字和运算符在分割时保持正确的整体性和顺序。这将大大提高模型在处理数学问题时的准确性。就像在阅读数学书时，确保公式和符号不被拆散和误解。

随着人工智能技术的快速发展，现在已经有更多更新的模型和方法来实现LLM和其他专业模型的协同工作。

一些最新的研究工作致力于开发混合模型，这些模型结合了自然语言处理和数学推理的能力。例如，一个模型可能在底层使用Transformer架构来理解自然语言，同时集成了符号推理引擎来处理数学问题。

在模块化的AI系统中，不同的模块负责不同的任务。例如，一个模块可能专门用于解析自然语言中的问题描述，而另一个模块则使用数学逻辑来执行计算和推理。

还有集成学习方法，通过结合多个模型的预测来提高整体性能。例如，一个集成系统可能同时使用LLM来理解问题，同时使用一个或多个专门针对数学问题的模型来提供计算结果。

还有些模型选择采用端到端的训练方法，这意味着模型在训练过程中同时学习理解自然语言和执行数学计算，而不是将这两个任务分开处理。

在交互式学习环境中，模型甚至可以通过与用户的交互来改进其对数学问题的理解。

还有一些针对特定领域（如金融、物理或工程）的模型正在被开发，这些模型会结合对特定领域语言的理解以及执行相关数学计算的能力。

总的来说，LLM在数学计算上的限制，从根本上来说，是因为它是一个为理解和生成自然语言而设计的系统，而不是专门为数学计算设计的。

要改善这一点，我们需要为LLM提供更多数学方面的训练，改进它的架构，以及开发更适合数学计算的方法和工具。这样，LLM才能在数学领域发挥出它在语言处理方面的潜力。

面对这些挑战，不要指望LLM在短时间内完全取代传统的数学软件或专家的工作。相反，我们应该看到其潜力，并结合专门的数学工具来发挥更大的作用。未来的发展方向可能在于更加紧密的跨领域合作，充分利用各个领域的优势，打造更智能、更高效的计算工具。