AI审稿为何把数字说歪：大模型数字幻觉的成因与规避方案

打开EMNLP 2026的官方演示切片，屏幕上那个AI审稿助手正一本正经地核验一篇论文的参考文献。现场观众看到它把“NeurIPS 2021”写成“NeurIPS 2012”，又把正文里的“样本量N=128”念成了“N=182”——弹幕区一片“绷不住了”。标题那句“AI把数字说歪”，说的就是这种事：大模型聊概念、写摘要、总结论点的时候像个老练的学者，可一旦碰到具体数字，就立刻暴露出“心算不如小学生”的毛病。这次官方演示不是整活，而是把AI辅助审稿最尴尬的软肋放在聚光灯下晒了一遍。

这篇文章想把这件事拆透：数字说歪到底错在哪几个环节，为什么模型会一本正经地输出错误数字，作为普通研究者或工程人员，我们又该怎么复现、怎么规避。适合正在用大模型辅助论文阅读、实验数据汇总、格式审查的人，也适合自己搭过AI Agent、被模型“自信地报错数字”坑过的朋友。后面我会给出一套可以直接跑的测试脚本，再加几个我自己踩出来的经验。

1. “数字说歪”到底说的是什么

1.1 一个演示引发的震动

先还原那个演示的核心画面。组织方丢给AI审稿助手一篇真实的投稿论文，要求它完成几个最基本的数字核验任务：检查参考文献里的发表年份是否与原文引用一致、确认摘要里的统计数值是否和正文表格对得上、把混淆矩阵里的四个数字逐项读出来。模型给出的回答句子通顺、语气笃定，但逐项比对后会发现，它犯的错误简直像在“说梦话”。

最典型的一个错误是“年份错位”。论文引用了一篇发表于2019年的工作，但参考文献列表里写的是2019，模型在审稿意见里却写成了“该引文发表于2021年，建议核对”。这不是不小心，而是模型在生成时把“19”和“21”这两个数字当成了可以互相替换的符号，它根本不知道2019比2021早两年。

更离谱的是统计值的“近义替换”。原文写“准确率提升4.7%”，模型在总结时写成了“提升约5%”——在普通人看来这不算什么大问题，可放在学术评审里，4.7%和5%就是两个事实。演示到这一步，现场很多做NLP的人反而松了口气：大家平时自己用ChatGPT查资料时被坑过太多次，这次终于看到官方替我们把尴尬演出来了。

1.2 数字错误不只是“口误”

很多人会下意识替模型辩护：“它只是表述不精确，核心意思没错。”这个想法在学术审稿场景里非常危险。数字是论文的地基，地基歪一点，整栋楼都得重新验。

审稿人拿到一篇实证论文时，第一件事就是扫关键数字：实验组多少人、对照组多少人、p值是多少、置信区间是否包含0、效应量有多大。这些数字决定了一篇论文能不能通过同行评审。AI审稿助手如果在这些地方出错，轻则让作者花大量时间解释“是AI写错了不是我写错了”，重则直接误导审稿决定——一个本该被拒的论文因为AI把不显著写成显著而蒙混过关，或者一篇扎实的研究因为AI把样本量读少而被误判为统计力不足。

所以“数字说歪”不是模型的一种小幽默，而是可靠性的系统性缺口。在真实工作流里，数字错误的代价往往是隐藏的：你可能永远不会发现AI把某个百分比写错，因为你不一定去逐字验证它输出的每一个数字。这次演示的价值就在于，把“隐藏的不可靠”变成了“公开的翻车”，逼着所有使用者正视问题。

1.3 从演示看AI辅助审稿的定位

看完整个演示，我其实觉得官方并不是在否定AI审稿的价值，而是在划定边界。AI审稿助手真正适合的活儿，是那些“语义理解”任务：总结一段论述是否自洽、检查作者是否回答了审稿人提出的问题、判断相关工作是否遗漏了重要文献。这些任务需要的是语言理解能力，恰好是LLM的强项。

但一旦任务变成“精确读取并比较某个数值”，LLM就从学者退化成了“嘴瓢的复读机”。这次演示的深层含义是：AI辅助审稿的定位应该是“协查员”，而不是“裁判员”。协查员可以帮你圈出可疑的地方、提供初步判断、节省通读时间；裁判员则需要无条件的数字精确性，目前的大模型远远做不到。任何把AI审稿输出直接当最终意见用的流程，都是在拿论文质量开玩笑。

2. 为什么AI会把数字说歪：原理拆解

2.1 数字在Token化时被“大卸八块”

要理解模型为什么对数字“没感觉”，得先看它怎么读数字。大模型处理文本的最小单位是token，不是单词或数字符号。一个像“128”这样的数字，在分词器里可能被切成“1”“28”两个token，也可能被切成“128”一个token，具体取决于分词表的设置。更长的数字甚至会被切成四五个片段。

这带来一个要命的问题：模型在内部表示里根本看不到完整的“128”，它看到的是几个离散符号的拼接。符号之间的大小关系、进位关系完全丢失。人看到“128”知道它比“127”大1，模型只知道当前上下文里出现过一些token，跟“127”之间没有任何“数值连续体”的概念。

我用生活类比解释一下：这就像让一个只认识汉字不认识阿拉伯数字的人去判断“一百二十八”和“一百二十七”哪个大，他只能通过死记硬背“二十八在二十七后面”来回答。一旦数字变成“一百八十二”，他就彻底晕了。大模型本质上也是靠训练数据里的共现规律来“背”数字关系，而不是真正理解数轴。

2.2 概率生成天生倾向“均值”

LLM的生成过程是逐token采样，每个token的概率来自Softmax分布。这种机制在生成自然语言时效果很好，因为语言的多样性是优势；但在生成数字时，它会导致一个系统性的偏差——回归均值。

什么意思？当你问模型“某个随机变量在0到1之间的期望值是多少”，训练语料里最常见、最“安全”的答案往往落在0.5附近。模型不是通过计算得出0.5，而是因为0.5在文本中出现的频率远高于0.71或0.29，所以它有更大概率被采样出来。这就像考试时遇到不会做的选择题，大家都蒙C，因为C项出现频率高——模型也在做类似的事，只是它蒙的是统计意义上“看起来正常的数字”。

这也是为什么模型在回答“从1到100随机选一个数”时，结果总是集中在20到80之间，极少出现7或93这种“边缘数字”。在审稿场景里，这种回归均值倾向表现为：样本量“看起来正常”就被接受、百分比“看起来合理”就直接搬用、年份“看起来在范围内”就不去精确校验。模型不是在回答事实，而是在回答“什么数字在这个语境里最像样”。

2.3 训练数据里充满了“合理但不正确”的数字

第三个原因藏在训练数据里。大模型学习的是海量文本，而文本中的数字天然具有两个特征：一是稀疏，二是噪声多。论文里可能写着“样本量为256”，下一段引用另一篇论文时又写着“样本量为128”，两处数字出现在上下文里，模型学到的只是“这些数字都可能和样本量关联”，而不是“特定这篇论文的样本量到底是什么”。

更麻烦的是，训练语料里存在大量“不一致的数字”。同一篇新闻的不同报道可能对同一事件给出不同统计值；同一篇论文的预印本和正式版可能修改过数据。模型在学习时把这些矛盾信息一起吞进去，生成时就可能“张冠李戴”——把A论文的数据安到B论文头上，再把B论文的年份套到A论文上。人类审稿人在看论文时能通过“这句话出现在第几节、表格编号是几”来定位上下文，但LLM没有这种稳定的指称能力。

我在实际测试中经常见到一个现象：让模型看一段摘要，再让它复述其中的数字，它往往能复述对；但如果中间穿插了三段其他内容，再让它回忆“第一段的样本量是多少”，错误率会急剧上升。因为模型的工作记忆中数字被“稀释”了，它只能依靠概率去猜一个看起来合理的结果。

2.4 没有外部验证回路

最后一条也是最本质的一条：自回归生成过程没有“回头检查”机制。模型是一个token一个token往后生成的，一旦某个数字token被采样出来，后续的所有生成都会基于它继续。模型不会在生成完一整句后回头想“等等，我刚才那个数字是不是抄错了”，除非你额外给它设计一个反思模块。

这跟你自己写论文完全不同。人写完“样本量是128”后，如果记得原文写着182，会有一种“违和感”触发你去翻原文。LLM没有这种违和感，它对自己生成的内容有一种“结构性自信”——只要句子通顺、语法正确、上下文连贯，它就认为这段话是好的。数字错误在语言模型的自洽评估中几乎不产生任何信号，因为模型评估的是语义合理性，不是数值精确性。

这也是为什么很多修复策略都要引入“外部工具”：计算器、查表、数据库查询。只有这些东西能提供模型自身生成过程中缺失的验证回路。

3. 官方审稿现场演示了一遍：场景拆解

3.1 AI审稿到底要处理哪些数字

既然演示带上了“官方审稿”的帽子，我们得先梳理一个真实审稿流程里，AI助手会被要求处理哪些数字。这些数字可以分成四类，每一类都有自己的坑。

第一类是参考文献元数据：年份、卷号、期号、页码、DOI里的数字。这类数字需要“精确匹配”，但LLM对“远远页”和“稍后页”没有感知，经常出现页码+1或-1的偏移。第二类是统计推断结果：p值、置信区间、效应量、自由度。这类数字不仅要求精确，还要求理解“p<0.05意味着什么”，模型经常把“p=0.04”和“p=0.40”搞混，因为它们在token层面长得太像。第三类是实验设计参数：样本量、分组人数、轮次、随机种子。第四类是元分析或对比中的数据：多个研究的效应量排序、不同方法的准确率对比。

演示现场的AI审稿助手处理的恰恰就是这四类，而它的错误率排序也很有意思：参考文献年份的错误率最高，抽样统计数值其次，实验组人数第三，反倒是“全文一共多少个图表”这种简单计数任务表现还行——因为这类任务通常可以从目录结构推断，不需要真正理解数字。

3.2 现场“翻车”的几个典型瞬间

虽然我无法逐字还原官方演示的每一步，但从它公开的画面和讨论来看，有几个瞬间特别有代表性，我按自己的观察给大家复述一下。

第一个瞬间是“参考文献年份穿越”。模型建议作者把某条参考文献的年份从2019改成2021，理由是“当前语境显示该领域在2021年有重要进展”。这就是典型的“语义联想覆盖精确读取”——模型不是在看那一条具体的引用，而是在泛泛地“回忆”这个领域哪年火。审稿现场最怕这种错误，因为作者一眼就能看出AI在胡扯，但审稿效率已经被拉低了。

第二个瞬间是“写错统计值还给出解释”。模型把原文的“F(2,57)=3.84”写成了“F(2,57)=3.48”，然后自己补充了一句“该结果显示组间差异显著”。数字错了一个数位，结论却照样编圆了。这种“错得有理有据”的情况比单纯报错更可怕，因为它完全避开了人的直觉检查——人看到一段论证自洽的文字时，默认不会去质疑细节数字。

第三个瞬间最日常也最烦人：模型把正文里的“N=128”和表格里的“N=182”混在一起，在审稿意见里写“样本量前后不一致，请作者核对”。实际上原文是对的，是模型自己把两个数读岔了。这种“制造假问题”的情况会让作者浪费大量时间去澄清一个根本不存在的问题。

3.3 这次演示的真正含义

如果只是把模型骂一顿，那这次演示就没什么价值。我看到的真正含义是：AI审稿这个方向已经进入了“可靠性验证期”。

前两年大家还在兴奋地讨论“LLM能不能审稿”，到了2026年，行业已经开始做“LLM审稿会在哪里出错”的系统性压力测试。官方愿意在EMNLP这样的顶会上公开演示失败案例，说明这个领域正在走向成熟——大家都意识到了，AI辅助工具的价值不在于“零错误”，而在于“错误可知、可控、可拦截”。

这也给所有想用AI审稿的人提了个醒：不要问“AI审稿准不准”，而要问“它在哪些任务上可靠、在哪些任务上不可靠、怎么把不可靠的部分拦截下来”。数字核验恰恰是目前最不可靠、又最容易设计拦截机制的部分，因为它可以被规则校验。语义判断不好拦截，数字总是可以拿原文去对。

4. 三步复现：你自己也可以测出“数字说歪”

4.1 准备一块“数字压力测试集”

看不懂演示没关系，这类问题你在本地就能复现。我建议你设计一块数字压力测试集，专门用来测模型在数字任务上的可靠性。下面是我自己常用的几类任务，你可以直接抄。

测的时候有个关键技巧：不要只测一次，最好用同一组Prompt跑5次以上，用不同温度参数。你会发现模型的错误不是偶发的，而是有“闪崩”规律——同一道题，温度0时答对，温度0.7时答错；或者上午跑全对，下午换一个推理路径就错了。

4.2 动手跑起来：用Python调用大模型实测

这里我给出一个可直接运行的测试脚本，假设你用的是OpenAI兼容接口，无论后端是官方API还是本地部署的模型都可以。代码也不复杂，本质上是把上面的测试集逐条丢给模型，并把回答记录下来。

import openai import time client = openai.OpenAI( api_key="sk-your-key", # 换成你自己的key base_url="https://api.example.com/v1" # 换成你的接口地址 ) test_cases = [ {"task": "数字比较", "prompt": "128和182哪个大？只回答数字。"}, {"task": "数字回忆", "prompt": "记住：实验样本量N=128。现在请回答：样本量是多少？只回答数字。"}, {"task": "算术计算", "prompt": "3.84除以2.57等于多少？保留两位小数。"}, {"task": "年份倒置", "prompt": "2019和2021，哪个年份更早？只回答年份。"}, {"task": "统计声称", "prompt": "原文写：准确率提升4.7%。请完整复述这句话。"}, {"task": "长数字", "prompt": "请逐个读出 ISBN 号 978-3-030-12345-6 中的所有数字。"}, ] def run_test(model: str, temperature: float = 0.2): print(f"\n===== 模型: {model} | 温度: {temperature} =====") for case in test_cases: try: resp = client.chat.completions.create( model=model, messages=[ {"role": "system", "content": "你是一个严谨的论文审稿助手。请精确回答问题。"}, {"role": "user", "content": case["prompt"]} ], temperature=temperature, max_tokens=200 ) answer = resp.choices[0].message.content.strip() print(f"[{case['task']}] {case['prompt']}\n 模型回答: {answer}") except Exception as e: print(f"[{case['task']}] 请求失败: {e}") time.sleep(1) # 避免触发限流 if __name__ == "__main__": run_test("qwen-plus", temperature=0.1) run_test("gpt-4o-mini", temperature=0.7)

跑完这个脚本，你大概率会看到几个典型现象：算术任务第一题可能就翻车；年份倒置基本能答对但在“哪一年更早”和“相差几年”混合出现时会懵；最稳定的是“只回答数字”这种约束性Prompt，但如果你把约束去掉，让模型自由发挥，它就会开始“润色数字”——把4.7%写成约5%，把128写成一百多人。

4.3 怎么看测试结果：判断“说歪”的几个维度

拿到模型输出后，不要只看对错，要按下面几个维度给它打分，这样你会更清楚它到底在哪个环节出问题。

第一个维度是精确匹配率：回答里的数字和标准答案是否逐字符一致。第二个维度是语义等价率：比如“约5%”和“4.7%”，虽然能理解是同一个意思，但在论文里不能算对。第三个维度是“错误自信度”：模型回答错误时，是完全不知道、吞吞吐吐，还是像现场演示那样“自信地给出一套错误解释”？后者风险更高。第四个维度是自相矛盾率：比如先写“N=128”，后文又说“样本量为182”，这个是最隐蔽的坑。

我自己跑下来，多数通用模型的精确匹配率在40%到70%之间，远低于我们做文本分类任务时动辄90%以上的准确率。这说明数字任务对LLM来说确实是一个独立维度，不能拿普通文本任务的性能去推断它的数字能力。跑完测试之后，你对自己的AI助手能有多信任，心里大概就有数了。

5. 让AI不把数字说歪的几条实用路子

5.1 外挂计算器与工具调用

面对数学计算类的数字错误，最直接的解法是别让模型“心算”，而是让它“按键”。在大模型应用框架里，这个思路叫工具调用或函数调用。

你可以给模型挂一个计算器工具，当它遇到算术或统计运算时，改为调用工具。比如Python环境里的eval函数，或者更安全的数学表达式解析库。示例逻辑很简单：模型生成一个结构化请求，把需要计算的表达式交给计算器，再把计算结果注入回上下文。

import ast import operator def safe_calc(expr: str) -> str: """安全计算纯数学表达式，避免eval执行任意代码""" tree = ast.parse(expr, mode="eval") allowed_ops = (ast.Add, ast.Sub, ast.Mult, ast.Div, ast.Pow) for node in ast.walk(tree): if isinstance(node, (ast.Module, ast.Expression, ast.Constant)): continue if isinstance(node, ast.BinOp) and type(node.op) not in allowed_ops: raise ValueError("不支持的运算") result = eval(compile(tree, "", "eval"), {"__builtins__": {}}, {}) return f"{result:.6f}" # 示例：让LLM在回答前调用该函数 print(safe_calc("3.84/2.57")) # 输出 1.494163

这个方法的收益立竿见影：加减乘除、百分比换算、标准差计算等任务，错误率可以直接降到接近零。但它只解决“计算类”数字问题，解决不了“读取类”数字问题——也就是从原文里精确定位某个数字再复述出来。后者需要另一种思路。

5.2 约束解码与格式化输出

对付“读取类”数字错误，可以试试约束解码。核心思想是：不让模型自由生成数字，而是强制它按照你定义好的格式输出，并在格式里对数字范围、精度做硬性限制。

举个例子，如果你让模型输出一个样本量，正常的Prompt可能得到一堆废话：“根据原文可知，实验组共选择了128名参与者。”如果加上约束，你可以让模型输出一个JSON对象，并且明确要求样本量必须是三位以内的整数。

{ "样本量": 128, "统计方法": "t检验", "置信区间": "[1.23, 4.56]" }

在实际操作中，我会用两层约束：第一层用System Prompt明确规定输出结构，第二层用Response Format或正则解析做兜底校验。如果模型输出的数字不在合理范围内，就让整个回答作废，重新生成。虽然会牺牲一点响应速度，但换来的是“要么正确、要么不输出”的可靠行为。

这里有一个容易忽略的细节：即使在JSON格式化输出里，模型仍然可能把“128”写成“182”。所以正则校验不能只检查“是不是JSON”，还要检查“数值是否在合理区间内”。比如样本量不会超过10万，年份在1900到2030之间，p值在0到1之间。把这些业务规则写进校验器，才能拦住模型的“说歪”。

5.3 生成后再校验一轮：用“双重提取”对抗幻觉

我自己最常用的方法，是给AI审稿加一道“双重提取校验”。具体分三步：第一次调用，让模型通读全文并用自然语言给出审稿意见；第二次调用，让模型专门提取所有关键数字，输出成一个结构化清单；然后把两份输出交给一个规则脚本，逐一比对清单中的数字是否与第一次意见中的描述一致。

这个方法的原理很简单：同一个模型在被要求“通读并综述”时的数字处理方式，和在被要求“专门提取数字”时完全不同。后者因为任务单一，往往能更精确。两份输出一旦互相矛盾，基本可以确定那一处数字有问题，需要人工复核。这就像让两个人分别抄一遍数字再对账，虽然抄写员可能是同一个AI，但在不同提示下的“抄写模式”差异能暴露不少错误。

5.4 针对审稿场景的落地建议

结合上面这些方法，我给真正要搭AI审稿流程的朋友几条落地建议。

第一，把审稿任务拆成“语义任务”和“数字任务”两条流水线。语义任务交给LLM直接生成，数字任务先抽出来，交给专门的抽取程序或外挂校验工具处理，不要混在一起让模型一口说完。第二，把模型的数字输出全部用高亮或特殊标记呈现，让审稿人第一眼就能看到哪些数字是AI生成的，哪些是原文引用。这样即使出错，也容易定位。

第三，设置一个“数字错误率阈值”：在测试集上跑一轮，如果模型的精确匹配率低于60%，就不让它直接参与作者意见的撰写，只让它做初筛。第四，也是最重要的一条，所有涉及论文能否录用的结论，都必须由人类审稿人确认。AI可以快速列出“可疑数字清单”，但“是否真的有问题”必须由人去看原文。AI审稿是放大镜，不是判决书。

6. 一些踩过坑之后的心里话

最后说点我自己的经验。我曾经搭过一个AI论文预审工具，用来帮组里快速筛查投稿前的格式问题。前期测试时大家都觉得不错，直到有一个已接收的论文被期刊编辑发回来说“摘要里的样本量与正文不符”——我们一查，发现是AI在整理摘要时把正文里的“128”当成“182”写进了摘要，而全流程没有任何人发现。那次之后，我给所有AI数字输出都加上了原文对照链接，鼠标悬停就能看到原文截取片段。这个改动让团队对AI工具的信心恢复了不少。

还有一次，我在测试中问模型“下面这组数字里哪个最大：7， 38， 4， 19”，它回答“38”，但又补了一句“7更大，因为它是一个幸运数字”。这个例子后来成了我培训新人的经典段子，专门用来提醒大家：语言模型的流畅性和可靠性是两码事。它能把“想当然”包装得比真知灼见还像真的。

如果你也准备把AI引入审稿或数据分析流程，我个人建议把“数字正确率”作为核心评估指标，而不是只看回答的流畅度和满意度。在论文这种一错就要命的场合，一句漂亮但数字错误的总结，比一百句笨拙但精确的话更有破坏力。至于官方在EMNLP 2026上的那段演示视频，我建议所有AI应用开发者都存一份，开会时放给团队看，比任何PPT都管用。