为什么 AI 数不清 strawberry 里有几个 r：它看到的不是十个字母，是三块

先说结论：它看到的不是十个字母，是三块

现象你大概率见过：问 ChatGPT「strawberry 里有几个 r」，它很自信地回答 2 个。 不是偶尔错，是很长一段时间里问谁都错，而且你说错了它还会给你一段解释，解释完了数字还是 2。

大多数人的结论是「AI 连数数都不会，真笨」，或者反过来「它是随机瞎答的」。两个都不对。真正的原因要等你看到它实际收到了什么，才会明白。

我在本地用官方的分词库把 strawberry 切开，结果是：st / raw / berry，三块。 换三个不同的词表都是三块，只是切法不同（GPT-2 和新版切成 st|raw|berry，中间那代 cl100k 切成 str|aw|berry）。

所以「十个字母」这个前提，在它这里根本不存在。它收到的是三个整体符号。

而三个 r 藏在哪？藏在第二块和第三块里：raw 里一个，berry 里两个。要答对，它必须做这么一串动作：把三块分别拆开 → 数每块里有几个 r → 把 1 和 2 加起来。

这三步里，它被训练过的只有第一步的反方向。 训练时它做的事是「给前面的块，猜下一个块」，从来没有人拿一个词让它拆开数字母。

这里有个中文用户专属的类比，非常好用：「矗」字里有几个「直」？ 你知道是三个。但你怎么得到的？你不是看一眼就报出来的，你是回过去一个字一个字看数出来的。而如果你只看这个词的整体意思——「高耸」——你完全可能顺口说成两个。

模型缺的不是智力，是「回过去看笔画」这个动作。 它平时读句子就像我们读「矗立」这两个字：认意思，不数笔画。

站内有篇讲幻觉的《AI 为什么会一本正经地胡说八道》，说的是同一族现象的另一种表现：它认得出自己的错，但不会主动回看。 这篇要给你的，是把「它到底收到了什么」这件事变成你自己能算的东西。

分词器在做什么：给常用片段提前起一个名字

OpenAI 官方的分词库叫 tiktoken，仓库第一句自我介绍是 “tiktoken is a fast BPE tokeniser for use with OpenAI's models.”（tiktoken 是供 OpenAI 模型使用的快速 BPE 分词器）。它对这套机制的定义写得很短，值得整段抄下来：

“Byte pair encoding (BPE) is a way of converting text into tokens.” （字节对编码，是把文本转换成 token 的一种方法。）

“It attempts to let the model see common subwords.” （它的目的是让模型看到常见的子词。）

“For instance, ‘ing’ is a common subword in English, so BPE encodings will often split ‘encoding’ into tokens like ‘encod’ and ‘ing’ (instead of e.g. ‘enc’ and ‘oding’).” （比如 ‘ing’ 是英文里常见的子词，所以 BPE 通常会把 ‘encoding’ 切成 ‘encod’ 和 ‘ing’ 这样的块，而不是 ‘enc’ 和 ‘oding’。）

“Because the model will then see the ‘ing’ token again and again in different contexts, it helps models generalise and better understand grammar.” （因为模型会在不同上下文里一次又一次看到 ‘ing’ 这个块，这有助于它归纳、更好地理解语法。）

先解释两个英文术语。 token（词元）就是切出来的那一块，一个块可以是一个完整单词、半个单词、两三个字母、甚至一个汉字或一个标点。BPE（Byte Pair Encoding，字节对编码）是造那本「常用块名单」的算法：从最小的单位开始，反复把出现频率最高的相邻两块合并成一块，直到名单够大为止。

Hugging Face 的官方 NLP 课程里对这段历史有句话很关键：“Byte-Pair Encoding (BPE) was initially developed as an algorithm to compress texts, and then used by OpenAI for tokenization when pretraining the GPT model.”（BPE 最早是文本压缩算法，后来被 OpenAI 拿去做 GPT 预训练的分词。）

这就是整件事的根：它天生是个压缩方案。 压缩的目标是「用尽量少的块表示尽量多的文本」，代价就是把细节合并掉。你压一张图，省下来的空间是丢失的纹理；BPE 压一段文本，省下来的 token 数是丢失的字母边界。

那为什么切法会「encod + ing」而不是「enc + oding」？因为名单是数出来的，哪个组合出现得多，哪个就被收进名单。所以同一个词在不同词表下切法不一样——这条我实测到了很直接的证据：

HF 课程在讲「预分词」那一步时举过一个例子：“The word ‘bug’ will be tokenized as [‘b’, ‘ug’].”（‘bug’ 这个词会被切成 [‘b’, ‘ug’]。）我实测成品词表里 bug 是一整块。这两个说法不冲突：课件讲的是训练过程中名单还没长大时的样子，成品名单里 bug 已经被收成一个整块了。 顺带看，官方 README 举例的 “encod + ing” 在 cl100k 里也没出现——‘encoding’ 太常用，直接是一整块，反而是老词表给出的正是它说「不会这样切」的 enc / oding。

教训：任何关于「某个词怎么切」的说法，都要先问是哪一本名单。 这跟《怎么读一份大模型发布稿》里那条老规矩是同一个：先问口径，再信数字。

词表就是它的视力表：50,257、100,264、200,006

那本「常用块名单」有多大，直接决定它看文字有多「清楚」。名单越大，越多的东西是一个整块，越少的东西被切碎。

三个能查到的数：GPT-2 的名单是 50,257（这个数字写在模型目录的配置文件里，字段名是 vocab_size，值是 50257，任何人可以打开 huggingface.co/openai-community/gpt2 的 config.json 看到）；我用官方库实测 cl100k 报 100,264、o200k 报 200,006。

这里必须给你一句诚实话：后两个数我在 OpenAI 官方源码里没找到「词表总数」这个字段。 官方 tiktoken_ext/openai_public.py 里只有 special token（特殊标记，比如 ENDOFTEXT、ENDOFPROMPT）的编号，cl100k 那组最大编号到 100,276，o200k 到 200,018，但没有写明总规模。所以 100,264 / 200,006 是「我这份库报的数」，不同实现会因为是否把特殊标记计入而略有出入。网上直接写「cl100k 词表 100,277」的文章，多数没交代这一点。

名单大小不是厂商随便定的，它牵动三件事，每一件都会到你账上：

• 切得越碎，同一段话 token 越多，越贵、越占上下文窗口。
• 切得越粗，越多样本进不了名单，罕见词、新词、专有名词就得被拆成碎片。
• 名单越大，模型第一层「查表」的参数越多，起步成本越高。

厂商换名单时不会跟你商量，但会留一句话。Anthropic 官方 token 计数文档的原句是：“Claude 4.7 and later models and Claude Mythos Preview use a newer tokenizer.”（Claude 4.7 及之后的模型用了更新的 tokenizer。）紧接着那句才是你真正要关心的：

“The same input text produces approximately 30 percent more tokens than on earlier models.” （同样的输入文本，会比之前的模型多出约 30% 的 token。）

“The exact increase depends on the content and workload shape.” （具体增加多少，取决于内容和负载形态。）

换句话说：你什么都没改，只是把模型升到新版，同一段提示词的计费单位就可能涨三成。 这条我在中文语料上自己复算过，见下一节。

中文是另一套账：17 个字能切成 15 块，也能切成 34 块

OpenAI 官方 Cookbook 里那句常被引用的话，完整版是这样的：“In English, tokens commonly range in length from one character to one word”（在英文里，一个 token 的长度通常从一个字母到一个单词），后半句是 “though in some languages tokens can be shorter than one character or longer than one word.”（但在某些语言里，一个 token 可能比一个字符还短，也可能比一个单词还长。）

中文就是那个「某些语言」。 我拿一句 17 个汉字的话实测，三个词表给出的块数差得很夸张：

三件事值得停下来看：

一，老词表把中文切成了 34 块，比字数还多。 我打印了它切出来的内容，里面大量是那种显示不出来的替换符——字符编码里管它叫 U+FFFD，在终端和网页上都画成一个空心小方块。因为 GPT-2 那本 50,257 的名单里几乎没有中文，它只能退回到最底层：按字节切。一个汉字在 UTF-8 里是三个字节，于是「冬天笔记本」这种最常用的词，在它那里是一堆碎片。这就是「词表决定视力」最直白的画面。

二，新词表已经学会把中文当词看。 o200k 给出的 15 块里，我逐块打印是这样的：冬 / 天 / 笔 / 记 / 本 / 的 / 续 / 航 / 从 / 六 / 小时 / 变 / 成 / 三 / 小时。注意「小时」是一整块——它认得这个词，但「续航」被拆成了「续」和「航」。所以中文在新词表里是一半词、一半字的状态，比英文糙得多（英文那句 11 个词就是 11 块，几乎一对一）。

三，中文比英文贵，是数量级的。 同样一句话，17 个汉字 15 块，11 个英文单词 11 块。但信息量是相当的——也就是说，每个「字」的成本，中文高得多。 官方 README 给过一个粗略口径：“On average, in practice, each token corresponds to about 4 bytes.”（实践中平均一个 token 约对应 4 个字节。）英文一个字母 1 字节，所以约 4 个字母一块；中文一个汉字 3 字节，按这个口径算下来还不到一块，实测也确实如此：o200k 是 1.13 字一块，cl100k 是 0.85 字一块。

中文模型在这件事上是有优势的，而且它们自己知道。Qwen2 技术报告（arXiv:2407.10671）的原句是：“this tokenizer exhibits high encoding efficiency, as evidenced by its better compression rate relative to alternatives”（这个分词器表现出很高的编码效率，证据是它相对其他方案有更好的压缩率），同一段还写明它的名单是 “a common vocabulary consisting of 151,643 regular tokens and 3 control tokens”（151,643 个常规 token 加 3 个控制 token）。智谱 ChatGLM-6B 的配置文件里 vocab_size 是 130528，比 GPT-2 的 50,257 大了两倍多——多出来的绝大部分是中文和日文块。

但要说清一句：Qwen 官方只说了「压缩率更高」，没有给「1 个 token 等于几个汉字」这个数字。 网上流传的那些换算表基本是第三方自己数的。你要用，就自己数，方法在第九节。

同一篇稿子，换家厂商贵 33%

上下文窗口和费用都是按 token 计的，微软官方文档里那句写得最直接：“Token counting and estimation: Helps manage costs and context limits when working with AI services.”（token 计数与估算：帮助你在调用 AI 服务时管理成本和上下文上限。）

我拿站内已经发布的《冬天掉的电会还给你，夏天掉的不会》整篇正文当样本，实测结果：

9,491 ÷ 7,112 = 1.33。 同一篇稿子，一个字没改，换一本名单就多三成的计费单位——和我前面引的 Anthropic 那句「约 30%」几乎对得上，只不过他们说的是英文为主的工作负载，我这里是一篇中文稿。

再顺手算个你更关心的：这篇稿子 5,500 汉字，在 o200k 下是 7,112 块，约 0.77 个汉字一块（整篇含英文术语和标点）。如果你要估中文长文的成本，用「汉字数 ÷ 0.77 ≈ token 数」，别用英文社区那句「1 token ≈ 0.75 个英文单词」。 后者套中文会低估一半以上。

这条直接接上站内那篇《每百万 tokens 到底是多少字：三步算清一次 AI 调用要花多少钱》——那篇负责把 token 换算成钱，这篇负责告诉你为什么中文的 token 数天生就比你想的多。同一个道理还解释了另一件常被误会的事：为什么聊着聊着它就忘了前面。因为窗口是按 token 扣的，《AI 为什么聊着聊着就忘了你说的话》里那笔账，中文要按上面这个比例重算一遍才准。

数字为什么也翻车：9.11 在它眼里是「9」「.」「11」

数字比较是另一批著名翻车现场。我核到的、带时间的公开记录是 OpenAI 官方社区论坛上一个 2024 年 7 月 17 日的用户帖，标题就是 “Issue with number comparison in ChatGPT”，里面把 ChatGPT 的原话抄了下来：

“Mathematically, 9.11 is greater than 9.9.” （从数学上讲，9.11 大于 9.9。）

要如实标注两点：这是用户提交的论坛帖，帖内没有 OpenAI 官方回复，也没有解释原因；而且出圈的是 9.11 和 9.9 这组，不是很多人转述的 17.8 和 17.15。 后者我没找到可靠出处，所以不写。

为什么是 9.11？我实测了一下，答案非常干净：

• 9.11 切成三块：9 / . / 11
• 9.9 切成三块：9 / . / 9

两边都是三块，小数点后面那块一个是「11」，一个是「9」。 而「11」在名单里是一个整块——它的身份更接近「十一」这个概念，而不是「1 后面跟一个 1」。于是模型看到的比较，很容易变成「小数点后第一位：11 对 9，11 大」。版本号 9.11 和 9.9 谁新，本来就该按版本号规则比，它答的其实没错；错的是把它当成十进制小数比。 这正好是同一批 token 造成的歧义。

但别把这条推得太远。我顺手数了手机号 13812345678，cl100k 给的是 138 / 123 / 456 / 78——四块，不是逐位切。 所以「数字翻车」不能全算在分词头上，它是「整块身份」和「训练里没见过几位小数比较」两件事叠出来的。

另一条能自己量的、更实用的账：罕见字符串有多贵。

同样长度的文本，UUID 的 token 成本约是普通英文的三倍。 这解释了你日常会遇到的两件事：贴一堆 ID、base64、哈希值进去，账单涨得比预期快；而且它抄长 ID 更容易错——因为它不是在「复制」，是在按块重新生成，一块里三个字符是一个整体，错一个整块就整块错。

顺带一句：把 token 当成「文本的原子」这个视角，还能理解另一件事——做检索时把长文档切开（chunking）为什么切不好就查不准，《AI 是怎么翻到你要的那一页的》里讲的是这一层。

别全甩锅给分词：研究给出的三个更麻烦的事实

写到这里，最省事的结论是「因为 tokenizer，所以数不对」。但这是错的，而且错得很典型。 我把三篇论文的摘要逐条打开核对了，它们给的图景更麻烦。

事实一：认得出，但数不出。 arXiv:2412.18626《Why Do Large Language Models (LLMs) Struggle to Count Letters?》（2024 年 12 月）摘要原句：“they struggle with other simple tasks, such as counting the occurrences of letters in a word, as illustrated by the inability of many LLMs to count the number of 'r' letters in 'strawberry'”（它们在很多简单任务上会卡住，比如数一个词里某个字母出现几次，「数 strawberry 里有几个 r」就是典型），更关键的是后面这句：“models are capable of recognizing the letters but not counting them”（模型认得出这些字母，但数不出来）。同篇还给了个规律：“most models being unable to correctly count words in which letters appear more than twice”（多数模型数不出字母出现超过两次的词）。

这条比「分词说」更值钱：如果只要出现三次就崩，那说明问题在「计数」这个动作本身，不在切法。 因为「berry」是一整块，它认得这块里有 r，它只是不会累加。

事实二：切法长短确实有影响，但和答对答错关系很弱。 arXiv:2508.02591《CharBench》（2025 年 8 月）是专门做这套评测的，摘要里写：“Tasks that require character-level reasoning, such as counting or locating characters within words, remain challenging for contemporary language models”（需要字符级推理的任务，比如数一个词里某个字符出现几次、定位某个字符的位置，对当代语言模型仍然有挑战），实测平均准确率 43.6%，某些子任务只有 32.3%。它给的分词解释是 “longer tokens obscure character position information for LLMs”（更长的块会掩盖字符位置信息）——但同一篇也明确写了：在计数任务上，“tokenization properties are weakly correlated with correctness”（分词属性和答对与否只有很弱的相关）。

事实三：这个能力是「后期突然长出来的」。 arXiv:2505.14172 直接把标题起成了《The Strawberry Problem: Emergence of Character-level Understanding in Tokenized Language Models》（草莓问题：在分词的语言模型里字符级理解如何涌现），摘要原句 “such capabilities emerge suddenly and only late in training”（这类能力是突然出现的，而且只在训练后期）。arXiv:2506.01687《StochasTok》则写了现状：“current large language models (LLMs) still struggle disproportionally with simple subword-level tasks like 'How many r's in strawberry?'”，并给出它的归因：“A key factor behind these failures is tokenization, which obscures the fine-grained structure of words.”（这些失败的一个关键因素是分词，它掩盖了词的内部细粒度结构。）

所以正确的说法是：分词是「关键因素之一」，不是唯一原因。 这和《隔一堵墙，WiFi 为什么慢一半》里那条一样重要：一个现象有多个来源时，谁单独被写成「根本原因」，谁就在卖结论。

顺手做一个读稿训练。有篇很有名的论文 arXiv:2309.12288《The Reversal Curse》，摘要里那句 “GPT-4 correctly answers questions like the former 79% of the time, compared to 33% for the latter”（GPT-4 答前者类问题正确率 79%，答后者只有 33%）经常被媒体拿去配「AI 不会把单词倒过来拼」的图。它测的是事实关系的反转（知道「A 是 B 的儿子」推不出「B 是 A 的妈妈」），不是拼写倒序。 这两件事都跟 token 有关，但混着说就是错的。

「后来它又会数了」——厂商没有公开解释过这件事

现在你去问新模型「strawberry 里有几个 r」，很多确实答对了。于是网上流传一套解释：「因为换了 tokenizer，新词表把 strawberry 切得更细，所以会数了」。

这套说法我给过自己一次否证：我实测的三本词表里，strawberry 全都是 3 块。 新词表 o200k 和老词表 GPT-2 给的是同一种切法（st|raw|berry）。如果「切得更细」是原因，这里就该看到差别，但它没有。

我也没找到任何厂商官方页面解释过这件事。诚实交代我查过的边界：OpenAI 的 GPT-4o 发布公告页我这次打不开（返回 403）；我能打开的官方书面材料是 GPT-4o 的 Model Spec（版本号日期 2024-05-08），里面完全没有提到字符级任务、数字母或分词。所以：

「因为换 tokenizer 所以修好了」这句话，目前没有一手来源，别信，也别在自己的文章里写。

那有没有一手来源说「怎么让它会数」？有，而且是做模型的人给的。Andrej Karpathy 在他自己项目的官方指导帖里（github.com/karpathy/nanochat 讨论区第 164 楼，标题 “Guide: counting r in strawberry (and how to add abilities in general)”，日期 2025 年 10 月 24 日），写的是怎么教一个小程序数对，原句有两句特别值得抄：

“Tokenization makes whitespace annoying, the model has to translate tokens with and without space all the time” （分词让空格变得很烦，模型得不停地换算带空格和不带空格的同一种块。）

“The model has to break up tokens (chunks of characters) into tokens of all the individual characters” （模型必须把块（一串字符）拆开，变成「每个字符一个块」。）

注意他给的解法：不是换词表，是训练模型主动把块拆成单字符，再逐个计数，最后用代码校验。 也就是说，「回过去看笔画」这个动作，是要专门教的，它不会自己长出来。

这条对普通用户的价值，比「模型变聪明了」大得多：它说明让 AI 做字符级任务的正确姿势，是显式要求它先展开。 具体怎么写，看第十节。

你自己三分钟能复现

上面所有数字你都能自己跑出来，不需要 API key、不需要登录任何网页（官方网页版计数工具多数要登录，本地跑反而省事）。

第一步，在一个空目录里装官方口径的库：npm i gpt-tokenizer。第二步，建一个 t.cjs，三行核心代码：

const cl = require('gpt-tokenizer/cjs/encoding/cl100k_base');
const ids = cl.encode('strawberry');
console.log(ids.map((i) => cl.decode([i])));
// 输出：[ 'str', 'aw', 'berry' ]

第三步，把任意字符串换进去就行。想比对两本词表，就多 require 一行 encoding/o200k_base；想知道自己的稿子多贵，就把整篇 Markdown 读进来 encode 一下再除字符数。

我用的就是这个方法，本文所有块数、每字符成本、0.77 字一块这些数，全部来自这台机器上的实跑输出，不是抄来的。这一条也是我对你的建议：凡是「AI 到底收到了什么」这种问题，先切一次看看，比看十篇解读都快。

这对你日常用 AI 的四条实际影响

一，凡是「数字母、找位置、倒着拼、数几个字」这类字符级任务，别让它凭印象答，要求它先逐字展开。 依据就是 Karpathy 那句 “break up tokens into tokens of all the individual characters”。你可以直接写进提示词：「先把这个单词一个字母一行列出来，再数，最后报总数。」 这一句话就能把 43.6% 那个数字拉上去——因为你替它把「回过去看笔画」这个动作写成了流程。

二，中文长文进窗口之前，按 0.77 汉字一块重算预算。 我在自己两篇已发布的稿子上实测的比例是 0.76 到 0.77，比英文社区那句「1 token ≈ 0.75 词」低得多。直接后果：你以为还剩一半窗口，其实只剩三分之一。 该分段的分段，该摘要的先摘要。如果你正在跑本地模型省钱，《把 AI 账单砍掉 90%》里那套按 token 记账的方法，换成中文比例要重跑一遍。

三，贴 ID、哈希、base64、长数字串时，明确要求「原样复制，不要改写」，并且自己核对一遍。 因为它按块重生成，一块错就整块错，而且这类文本每字符成本约是普通英文的三倍。工程场景里这条更硬：如果你让 AI 带着这些串去调工具、执行操作，权限怎么收口在《让 AI 替你办事的安全清单》里。

四，重要要求别写在长提示词的中间。 这条严格说不是分词造成的，但它是「token 序列」这一层的另一条硬约束。arXiv:2307.03172《Lost in the Middle》摘要原句：“performance is often highest when relevant information occurs at the beginning or end”（相关信息出现在开头或结尾时，性能通常最高），“significantly degrades when models must access relevant information in the middle”（需要读取中间的信息时显著下降），结论是 “current language models do not robustly make use of information in long input contexts”（当前模型对长输入中间内容的利用并不稳健）。所以把最硬的要求写在开头和结尾，中间放背景。 把要求写成可验收的条目，《12 个真正好用的提示词》里那套写法正好接得上。

三道判断题

一、「strawberry 数错，是因为新模型词表把它切得太粗。」

错。我实测三本词表，strawberry 都是 3 块，包括最新那本。切法解释不了「换模型就会数了」，而 arXiv:2412.18626 给的规律是「字母出现超过两次就数不出」——问题在累加这个动作，不在切块。 分词是关键因素之一，不是唯一原因。

二、「同样是 5,500 汉字的中文稿，喂给哪家模型 token 数都差不多。」

差很多。我实测同一篇 12,634 字符的中文稿，cl100k 数出 9,491 块，o200k 数出 7,112 块，差 33%。而 Anthropic 官方对自家新版 tokenizer 的说法也是 “approximately 30 percent more tokens”。换模型版本，账单单位会自己变，你一行代码都不用改。

三、「问它 9.11 和 9.9 谁大答错，纯粹是数学没学好。」

不完全对。9.11 和 9.9 都是三块，差别在小数点后那块是整块「11」还是整块「9」——「11」的身份更接近一个概念，不是两个 1。 同时按版本号规则 9.11 确实更新，所以它有一半是对的。这类翻车是「整块身份」和「场景歧义」叠出来的，不是单一原因。

现在能做的几件事

一，把这句加进你的常用提示词：「先逐字符列出来，再数，再报结论。」 它能修掉一整类字符级错误，成本是多花几十上百个 token。

二，用 npm i gpt-tokenizer 跑一次你自己的稿子。 三个数就出来了：字符数、块数、汉字每块。以后估中文预算用你自己那个比例，别用别人的换算表。

三，长提示词把硬要求放开头和结尾。 中间只放背景材料，这是 Lost in the Middle 那篇给的唯一可直接执行的结论。

四，看到「因为换了 tokenizer 所以修好了」这类解释，先问一句：有没有厂商自己说过。 我查到的情况是厂商没说过，能查到的解法来自 Karpathy 那份 2025 年 10 月的帖子，而他给的是「专门训练它拆块」，不是「换词表自然就好」。

五，把「单位」这个习惯留住。 格数不等于网速（WiFi 那篇）、百分比不等于电量（电池那篇）、token 不等于字数（这篇）。同一个道理在三个完全不同的领域反复出现：厂商给你的读数，和被测量的东西之间，永远隔着一层换算。 而模型报的那些漂亮上限数字也一样，《Gemini 4 登场了》里那个「单次输出 100 万 token」就是典型——它是上限，不是你每次能拿到的量。

一句话版本

AI 读到的不是一百个字母，是几十到几百个「整块」——因为分词本质是一套压缩名单，谁在名单里谁就成为一个不可拆的字。 这解释了它为什么数不出 strawberry 里的 r（三个 r 分散在两块里，而「逐块累加」这个动作没人教过）、为什么 9.11 会大于 9.9（小数点后是一整块「11」）、为什么中文比英文贵（我实测 5,500 汉字是 7,112 块，约 0.77 字一块，同一篇稿子换本名单还多 33%）。你只需要改两个习惯：字符级的活让它先逐字展开再回答，中文长文按 0.77 字一块重算预算。