前不久GPT-5正式发布，预计着大模型创新又到一个新高度。那么，不断推新的模型究竟处于何种水平，我们用这道经典且极具迷惑性的算术题来测试。

9.9-9.11=？

测试了市面上常使用的DeepSeek、通义、豆包、任度、GPT-5、Gemini2.5Pro六种大模型，分别给出的答案是-0.21、-0.21、0.79、0.79、-0.21、-0.21。

很奇怪吧，为什么错误率很高？

DeepSeek

通义

豆包

任度

GPT—5

Gemini 2.5Pro

备注：特别强调，第一次测试没有开启深度思考模式。第二次测试，统一打开深度思考模式，结果都修正了，统一为0.79。

01

大模型为什么比不上小学生？

一个非常有意思的结果，这就引发了两个疑问，一是为什么如此简单的数学题，这么多大模型竟然算不对？二是为什么那么多大模型会出现共性的错误？

回答第一个问题相对容易，大模型（更准确的说通用大模型）的优势在于信息整理，对于数学、逻辑问题它没有那么擅长。

回答第二个问题，则相对复杂。知乎上关于9.9大还是9.11大？有一个非常细致的讨论，包括tokenizer、注意力错误、语义建模等技术问题都有很多人在讨论，但都不能明确指出是什么问题导致了这一结果，都是猜测。

列举几个，比如：

分词机制问题：大模型通常将文本转换为tokens进行处理。对于“9.9”和“9.11”，分词器可能会将其拆分为不同的 tokens，如“9.9”被拆成“9”“.”“9”三个 token，“9.11” 被拆成“9”“.”“11”三个 token。模型在比较时，可能会简单地将小数点后的9和11进行比较，从而得出 9.11 更大的错误结论。

训练数据偏差：在训练数据中，9.11作为日期（9月11日）或软件版本号等其他非数值意义的情况可能出现频率较高，而专门用于训练基础数学数值比较的语料相对较少。模型基于训练数据进行学习，就容易受到这些常见语境的影响，将9.11默认为某种序列或特定标识，而不是单纯的数值进行比较。

注意力机制缺陷：大模型的注意力机制在处理数字时，可能对小数点后的数字分配了过高的注意力权重，从而忽略了整体数值的比较逻辑。例如在比较9.9和9.11时，过于关注11比9大，而没有从整体上判断两个数值的大小关系。

以上都可能导致错误结果出现，可见这并不是一个非常小的问题。

还有一个比较重要的因素是：这些大模型的体系是不是相似,要不然怎么会犯同样的错误？

02

大模型“共同错误”的根源：同源同缺陷

为什么这么说，从大模型的核心组成聊起。

简单说，大模型的核心组成有四部分，模块（骨架）、方法（学习规则）、框架（运行平台），以及训练数据。无论是分词机制问题、训练数据问题，还是注意力缺陷问题……基本都可以归结为四个部分之一。

换句话说，之所以这些大模型会出现同样的错误，很大可能性是它们脱胎于同一个开放平台，就像生命体共享基因会继承相同的缺陷一样，大模型共性错误源于对同一底层架构、类似数据的依赖。事实也确实在侧面印证这一猜想。

拿最核心的大模型底层架构来说，当前全球主流大模型90%以上基于相同算法架构开发，采用近似的训练数据集与优化方法。比如都以Transformer架构为基础，这种架构的自回归生成机制，使得模型核心目标是文本连贯性而非事实准确性，可能为流畅性牺牲正确性，从而导致一些共性的错误模式，如在复杂推理任务中容易出错。

再比如，学习规则的制定、训练数据都面临同样的问题。传统的评估指标如BLEU、ROUGE等侧重文本匹配而非事实正确性，被广泛使用；错误的、带偏见的训练数据被广泛复用……

以上不难看出，在大模型不断发展的过程中，普遍存在相互借鉴、使用其它模型修改等情况，并非独立研发导致共同基因不断被强化，于是出现了共同的缺陷。

可以进一步推论，如果某些大模型在测试中不出现这个BUG，大概率有三个原因。

1. 基于开源平台，发现这个问题后修正了——这个可能性不大，因为这是小Bug,只能冒头一个查处一个；

2.基于开源平台，但学习方法、训练数据、推理模式是自研的，避免了这个错误，阿里通义大概率属于这类。

3.完全使用了自己的架构，全自研，就不会出现这个低级的错误。典型如一直坚持“根原创”的任度大模型。他们的特色是，体系（架构）自研、代码自研、训练方法、推理方式、训练数据等等统统都是自研的，在国内独树一帜，并非“开源”或者“蒸馏”而来。

顺便说一下，这里只是基于当前的测试结果做合理的推测。

03

共同基因缺陷的潜在风险：

从“卡脖子”到体系性崩塌

看似9.9比9.11小是个小问题，但折射出的风险是巨大的。因为知名大模型的底层架构就像人的基因，一旦开源被广泛采用后，导致大模型的错误和问题被无限复制。

由此可见，时至今日，我们对于大模型的理解和运用尚处于初级阶段，对大模型的了解还只是冰山一角。

大模型共同基因缺陷犹如一把高悬的达摩克利斯之剑，给整个行业乃至更多产业带来了不容忽视的风险。

其一，许多大模型在构建过程中，大部分代码来源于国外开源项目，一旦底层出现安全隐患，极有可能引发全行业的多米诺骨牌效应。类似的案例数不胜数。

其二，如果国外突然断供，风险将被无限放大。这方面EDA（电子设计自动化）前车之鉴历历在目，这不仅仅是卡脖子问题，而是性命攸关的问题了。

第三，对产业链的灭顶之灾，进而导致一个产业的消失，这也不是危言耸听。这些就不用论再述了吧。

除此之外，底层代码若被恶意潜伏，将对产业安全构成直接且致命的威胁。想象一下，在金融领域，如果大模型被恶意控制，可能会错误地评估信用风险，导致金融机构做出错误的贷款决策，引发系统性金融风险；在医疗领域，大模型若被操控，可能会给出错误的诊断建议，危及患者的生命安全。

以上显然是大家不愿意看到的，这也是如今国家自上而下都在追求自主可控的根本用意。

然而，很多企业都跑偏了。

04

拒绝认知偏差，大模型时代更要根创新

由此引发另一个问题，我们该如何面对当前“千篇一律”的大模型应用创新？或者说，我们该不该以“拿来主义”当做大模型的必经之路？

答案是否定的。

减少或者是从根本上杜绝大模型的“共同基因缺陷”问题，唯一的出路是加强对大模型底层架构的研究和创新，构建自下而上的全栈创新能力，这样才能避免“卡脖子”和同质化缺陷。

遗憾的是，业内还有不少认知上的偏差。

第一类认知偏差，不需要从头搞创新，只需要在技术集成层面搞创新。例如基于国外开源框架（如Transformer衍生架构）进行参数调优、功能叠加，却忽视了底层架构的原创性突破。这种模式看似能快速实现商业化落地，却如同在他人地基上盖房子，始终受限于底层框架的设计逻辑与安全隐患。

第二类认知偏差是，“开源 = 安全”。大模型的开源与传统软件开源存在本质区别，传统软件开源通常包含完整代码，可通过社区协作快速验证安全性；而多数大模型仅开源模型权重（即训练结果），其底层架构、训练数据逻辑、安全防护机制仍处于黑箱状态，要全面验证其安全性、排查潜在后门，需投入极高的算力与技术成本，实际安全可控性远低于传统开源软件。就算全部源代码公开，有多少公司愿意有精力、有时间、有能力去一行行解读？

第三类认知偏差是，自主创新需要大量资金支持，企业没时间没精力没人才去搞这个。如果这是小公司的理由，我们还能理解。但如果这是大公司的理由，则显得“急功近利”。在创新体系中，一般以20%的公司精力孵化一个新项目，不求速成，只求日拱一卒。而且有了原创技术的加持，只要能寻找到合适的商业路径，就容易形成独立的商业化闭环，完全反哺技术原创，让“中国原创”走得更远，形成生态。

实际上，华为鸿蒙5.0已经给业内做出了榜样。尽管在过去6年中，华为鸿蒙这条道路走得很艰辛，投入百亿研发费用以及每年万人团队，但最终鸿蒙5.0实现全栈自研和自主可控。央视新闻在社交媒体上为其“点赞”，强调没有自主操作系统就意味着“被卡脖子”。

AI对社会的影响远远高于安卓，如听任根植于国外开源底层的大模型占领渗透中国市场，那么如果再被迫切换“本土原创”大模型时，其难度将远远大于鸿蒙替换安卓。

所以，在当前大模型还没有全面渗透的当下，最好的办法是“撸起袖子加油干”。当然，世界上只有华为一家可以在国家战略的指引下不计价成本“压强式”投入获得成功。要想在大模型领域走出“自主创新”之路，单纯靠一家或者几家创新公司的力量毕竟有限。只有所有立志于中国大模型技术原创的公司，相互支持，以“自主可控”生态圈的群体力量，就能够一步一个脚印，做出中国特色的“原创大模型”，从而立足于世界。

全文观点总结如下

大模型时代的竞争，本质是原创能力与独立体系的竞争。只有跳出集成思维，聚焦底层创新、构建自主商业化逻辑，才能真正摆脱同源风险，打破卡脖子的困局，实现从跟跑到领跑的跨越，这可能就是一直坚持“根原创”的任度等众多国内大模型的意义所在。