病根：AI其实不“认字”

人类看单词“Google”，看到的是G、o、o、g、l、e这6个独立的字符。但对大模型来说，情况截然不同。它会把文本打碎成Token（词块）。这些词块可能是一个完整的词，也可能是词的一部分，甚至偶尔是一个单独的字符 。

简单来说，大模型在预处理时，可能会把“Google”直接打包成一个token ["Google"]，或者拆成两个如 ["Go", "ogle"]。但它绝不会将其记录为 ["G", "o", "o", "g", "l", "e"]。也就是说，在这个AI的大脑里，从来就没有储存过“Google”这几个字母的个体信息。它根本不“认得”字母本身。

这引发了两个致命的连锁问题：

其一，模型的嵌入层（Embedding Layer）其实是个半吊子。研究发现，LLM的嵌入层只对每个token的第一个字符保留了较强的字符信息，从第二个字符开始，细节就迅速模糊了 。当需要数“Google”里有几个p时，模型得从那个压根没保存字母信息的压缩包里“硬猜”字符序列。虽然后续的Transformer层可能会突然“开窍”拼出这个词，但这个过程极不稳定且充满随机性 。

其二，分词器对Token的内部结构“视而不见”。2024年一篇来自Arxiv的重磅论文将此弊病命名为**“分词的诅咒”**：分词器天生就对错别字、长度变化极度敏感，并且完全不清楚自己内部到底长啥样 。比如“journalism”可能就是一个整装Token，模型从未学过该如何把它拆成 j-o-u-r-n-a-l-i-s-m 的逐个字母，一旦被问到拼写，自然就信口胡诌了。

修好它？比想象中难得多

既然问题是“不拆字”，那最直观的解决办法就是把模型改成逐字阅读模式。确实有这种模型存在，比如ByT5，它直接处理最原始的字节 。但这条路走不通，因为代价太昂贵了。

一旦切换到纯字符级处理，序列长度瞬间暴涨3到5倍，计算成本成倍翻滚。更致命的是，这将让模型的学习难度陡增，难以捕捉上下文中的长距离依赖关系 。说白了，现在的分词技术就是用“模糊处理”换取了模型能流畅说话的“成本妥协”。

业内研究者普遍认为，根本不存在“完美的分词器” 。分词器时常产出“非唯一编码”，这种“表征失配”是刻在骨子里的架构缺陷，而不是简单的bug 。字符精准度和语义流畅度之间，目前看来是Transformer架构里没法两全的根本矛盾。

这些低级错误暴露了什么

除了让人啼笑皆非，这些错误也撕开了大模型的华丽外衣：

• AI是“猜谜高手”，不是“符号大师”：数出单词里有多少个p，对一段最简单的程序而言都是微不足道的事。但LLM不运行算法，它只是根据统计规律去预测下一个最可能出现的文本 。当被问到字母数量时，它给出的只是一个“看起来很对”的答案。
• 自信与真伪毫无关系：模型毫无语法瑕疵地给出了“两个”的回答，可它是错的。这就是所谓的“AI幻觉”——它总能生产出语法通顺、语气肯定的谎言，且不自知。谷歌自己在2024年就承认过，虽然AI概览只显示有顶级搜索结果支撑的内容，但当它误读语义或语言中的细微差别时就会出错 。
• 这是架构的天生盲区：无论是谷歌、OpenAI还是Meta，只要使用分词技术的LLM，在倒拼单词、数字母数、字形拆解等任务上，都会暴露类似的缺陷 。

行业为何不着急

一个连自己公司名都拼不对的AI，堪称顶级尴尬，但在AI业界看来，这算不上危机。因为LLM的极高价值点在于生成流畅文章、总结摘要、编写代码、逻辑推理等语义层的发挥，这时“词块”式的模糊处理反而是加分项 。

字符细节并不是这类模型的设计目标。所以最务实的解法，是让AI遇到拼写和计数的要求时，把任务转包给传统的、基于规则的软件去处理。事实上，一些AI概览的工程实现已经在尝试识别并转交这类查询，但从2026年5月的这次社死现场来看，识别环节本身也还很粗疏 。曾有研究发现，谷歌AI概览在倒序拼写单词时，错误率高达52%，而对于三个音节以上的词，倒拼准确率只有10% 。

谷歌确实在给这次曝光的计数字母问题打补丁 ，但在懂行的人眼里，这个故事讲出的真话是：驱动AI革命的核心架构，自带一个无解的先天缺陷。而要弥补这个缺陷，目前无人能在不牺牲LLM核心价值的前提下做到两全其美。

病根：AI其实不“认字”

人类看单词“Google”，看到的是G、o、o、g、l、e这6个独立的字符。但对大模型来说，情况截然不同。它会把文本打碎成Token（词块）。这些词块可能是一个完整的词，也可能是词的一部分，甚至偶尔是一个单独的字符 。

简单来说，大模型在预处理时，可能会把“Google”直接打包成一个token ["Google"]，或者拆成两个如 ["Go", "ogle"]。但它绝不会将其记录为 ["G", "o", "o", "g", "l", "e"]。也就是说，在这个AI的大脑里，从来就没有储存过“Google”这几个字母的个体信息。它根本不“认得”字母本身。

这引发了两个致命的连锁问题：

其一，模型的嵌入层（Embedding Layer）其实是个半吊子。研究发现，LLM的嵌入层只对每个token的第一个字符保留了较强的字符信息，从第二个字符开始，细节就迅速模糊了 。当需要数“Google”里有几个p时，模型得从那个压根没保存字母信息的压缩包里“硬猜”字符序列。虽然后续的Transformer层可能会突然“开窍”拼出这个词，但这个过程极不稳定且充满随机性 。

其二，分词器对Token的内部结构“视而不见”。2024年一篇来自Arxiv的重磅论文将此弊病命名为**“分词的诅咒”**：分词器天生就对错别字、长度变化极度敏感，并且完全不清楚自己内部到底长啥样 。比如“journalism”可能就是一个整装Token，模型从未学过该如何把它拆成 j-o-u-r-n-a-l-i-s-m 的逐个字母，一旦被问到拼写，自然就信口胡诌了。

修好它？比想象中难得多

既然问题是“不拆字”，那最直观的解决办法就是把模型改成逐字阅读模式。确实有这种模型存在，比如ByT5，它直接处理最原始的字节 。但这条路走不通，因为代价太昂贵了。

一旦切换到纯字符级处理，序列长度瞬间暴涨3到5倍，计算成本成倍翻滚。更致命的是，这将让模型的学习难度陡增，难以捕捉上下文中的长距离依赖关系 。说白了，现在的分词技术就是用“模糊处理”换取了模型能流畅说话的“成本妥协”。

业内研究者普遍认为，根本不存在“完美的分词器” 。分词器时常产出“非唯一编码”，这种“表征失配”是刻在骨子里的架构缺陷，而不是简单的bug 。字符精准度和语义流畅度之间，目前看来是Transformer架构里没法两全的根本矛盾。

这些低级错误暴露了什么

除了让人啼笑皆非，这些错误也撕开了大模型的华丽外衣：

• AI是“猜谜高手”，不是“符号大师”：数出单词里有多少个p，对一段最简单的程序而言都是微不足道的事。但LLM不运行算法，它只是根据统计规律去预测下一个最可能出现的文本 。当被问到字母数量时，它给出的只是一个“看起来很对”的答案。
• 自信与真伪毫无关系：模型毫无语法瑕疵地给出了“两个”的回答，可它是错的。这就是所谓的“AI幻觉”——它总能生产出语法通顺、语气肯定的谎言，且不自知。谷歌自己在2024年就承认过，虽然AI概览只显示有顶级搜索结果支撑的内容，但当它误读语义或语言中的细微差别时就会出错 。
• 这是架构的天生盲区：无论是谷歌、OpenAI还是Meta，只要使用分词技术的LLM，在倒拼单词、数字母数、字形拆解等任务上，都会暴露类似的缺陷 。

行业为何不着急

一个连自己公司名都拼不对的AI，堪称顶级尴尬，但在AI业界看来，这算不上危机。因为LLM的极高价值点在于生成流畅文章、总结摘要、编写代码、逻辑推理等语义层的发挥，这时“词块”式的模糊处理反而是加分项 。

字符细节并不是这类模型的设计目标。所以最务实的解法，是让AI遇到拼写和计数的要求时，把任务转包给传统的、基于规则的软件去处理。事实上，一些AI概览的工程实现已经在尝试识别并转交这类查询，但从2026年5月的这次社死现场来看，识别环节本身也还很粗疏 。曾有研究发现，谷歌AI概览在倒序拼写单词时，错误率高达52%，而对于三个音节以上的词，倒拼准确率只有10% 。

谷歌确实在给这次曝光的计数字母问题打补丁 ，但在懂行的人眼里，这个故事讲出的真话是：驱动AI革命的核心架构，自带一个无解的先天缺陷。而要弥补这个缺陷，目前无人能在不牺牲LLM核心价值的前提下做到两全其美。