大模型处理文本的第一步：分词 —— 为什么 “汉字“ 和 “token“ 不是一回事

前言：几乎所有用过 ChatGPT、DeepSeek、Kimi 的人都见过 "token" 这个词 ——API 按 token 计费、上下文窗口按 token 计算。但 token 到底是什么？为什么它不是 "字"，也不是 "词"？本文从底层机制出发，做一次全面的拆解。

一、模型为什么 "看不懂" 文字

大语言模型（LLM）本质上是一个巨型数字运算机器。Transformer 的全部计算 —— 矩阵乘法、注意力机制、位置编码 —— 都只作用于整数和浮点数。一段文本从输入模型到产生输出，要经过这样一条流水线：

原始文本 → 规范化(Normalization) → 分词(Tokenization) → 查表得到 token ID
→ Embedding 层把 ID 转成向量 → Transformer 逐层计算 → 输出 token ID
→ 反向解码回文本

所以严格说，第一步是分词（Tokenization），而分词的本质是：把连续的字符序列切成一个个 "词元"（token），并为每个 token 映射到一个整数 ID。模型从头到尾只见到一串整数 ID，一个汉字都不认识。

下面逐层拆开讲。

二、Token 到底从哪里来：BPE 的底层逻辑

现代大模型（GPT、LLaMA、Qwen 等）几乎全部使用 BPE（Byte Pair Encoding，字节对编码） 或其变体（BBPE、SentencePiece、Unigram）来构建词表。

1. 训练过程：贪心合并

假设词表初始只有 256 个字节（0x00–0xFF）。BPE 在海量语料上反复做一件事：

举例：语料里 "t", "h" 总是挨着出现，就把它俩合并成 "th"；接着 "th", "e" 又高频出现，再合并成 "the"。

关键洞察：哪些序列会成为 token，完全取决于 "什么在语料中出现得最多"。 词表里的几万～十几万个 "条目"，是训练语料频率分布的直接产物。

2. 推理过程：查表 + 回退

来了新文本后，分词器做反向操作：从左到右贪心查找词表里最长能匹配的子串。匹配不上时，字节级 BPE 还有个保底机制 —— 退回到单字节，再两两合并编码。

这就是为什么：

• 英文常见词 the、of、intelligent 都是 1 个 token；
• 但长而罕见的词如 uncharacteristically 会被切成 un、character、istic、ally 等多个 token；
• 不同语言、不同领域的常见度不同，切法就完全不同。

三、为什么 "汉字" 和 "token" 不是一回事

这是本文的核心。两者混淆的根源是：人们把 token 当成 "字" 或 "词" 的近义词，实际上它是词表中一个整数条目的代号，与 "字" 没有任何天然对应关系。

1. 一个汉字可能恰好是一个 token—— 纯属巧合

中文语料在互联网上极其庞大，所以高频汉字（的、是、我、在、国、人……）在 BPE 训练时自然被合并成独立 token。这造成一种错觉："一个汉字 = 一个 token"。实际上这只是统计规律的巧合，不是设计保证。高频字是 1 个 token，低频字可能切成 2～3 个甚至更多 token。

2. 低频汉字会被拆成字节

汉字用 UTF‑8 编码时占 3 个字节。如果一个生僻字（如 "犇"" 鬰 "）从未在训练语料中出现过足够次数，词表里没有它的完整条目，分词器只能退回字节级编码：一个字会被表示成 2～3 个 "字节 token"。

也就是说：一个汉字 ≠ 1 个 token，它可能是 1 个，也可能是 3 个，甚至跨汉字的组合被切进同一个 token。

3. Token 边界可以落在任何位置

因为是 "最长匹配 + 频率驱动"，token 边界与语义边界经常错位：

• 英文：ChatGPT 可能被切成 Chat + G + PT—— 既不是字也不是词；
• 数字：123456789 常按 3 位一段切成多个 token；
• 中文词组：训练语料中高频的双字 / 多字组合（如 "中国"" 人工智能 "）可能被合并成一个 token—— 这时是多个汉字 = 1 个 token；
• 标点、空格、换行、emoji，各自都是独立的 token。

token 是统计单元，不是语言单元。这就是为什么下面这条恒等式几乎总是错的：

token 数 ≈ 字数 ❌

4. "字" 与 "字" 在模型眼中也不同

"汉字" 指语义上的字符（Unicode 码点），但底层还有字形渲染、归一化（全角 / 半角、简体 / 繁体被视为不同码点）等层次。模型看到的连 "汉字" 都不是，是字节序列 → 词表条目的映射结果。繁体 "國" 和简体 "国" 在多数词表里就是不同 token，虽然人眼看来 "是同一个字"。

四、从 ID 到向量：模型真正 "吃" 的东西

拿到 token ID 后，Embedding 层做一个简单的查表操作：

向量 = Embedding矩阵[ID] （矩阵规模 = 词表大小 × 隐藏维度，如 151k × 4096）

这个查出来的高维向量，再叠加位置编码，才进入 Transformer 的自注意力计算。所以：

• 模型不认识 "中" 这个字，它只认识某个 ID（如 49374）这个索引在 Embedding 矩阵里对应的那行向量；
• 两个不同的 token 即使字形相同（如全角 "中" vs 半角 "中"），ID 不同，向量也完全不同，模型眼中的它们毫无关系；
• 词表是每个模型专属的：Qwen、DeepSeek、GPT‑4 的词表互不相同，同一个句子在不同模型里切出来的 token 序列、数量都不一样。

五、这个区别为什么重要：四个实际后果

1. 计费与上下文长度都按 token 算。 API 价格、上下文窗口（128k 等）全部以 token 计数。中文通常 1 个汉字约 1～2 个 token，英文 1 个 token 约 0.75 个单词 —— 所以中文使用成本普遍高于英文用户的直觉。

2. 模型在 "token 边界" 上是笨拙的。 模型无法可靠地 "数汉字"、反转字符串、数标点 —— 因为这些操作需要在字节 / 字符层面处理，而模型只在 token 层面做注意力计算。strawberry 里有几个 r 曾难倒一大片模型，根源就在此。

3. Prompt 设计要顺应 token 分布。 高频表达模型 "更熟练"；生造词、混合语言、无空格英文黏连、异常大小写，都会让 token 化变得不可预测，影响输出稳定性。

4. 语言之间不平等是词表造成的。 英语等高频语言 1 个 token 携带的信息量大；某些小语种一个字需要多个 token，同样的信息量要花更多算力和钱 —— 这是技术结构带来的隐性偏差，而非模型 "歧视"。

六、总结

大模型处理文本的第一步是分词：用 BPE 等算法把文本切成语料频率驱动下的离散单元（token），映射为整数 ID，再查 Embedding 表变成向量。"汉字" 是人类语言里的字符概念，"token" 是词表里一个条目的整数索引 —— 一个汉字可能是 1 个 token，可能是 3 个字节 token，多个汉字也可能合并成 1 个 token。二者唯一的关系是统计上的偶尔重合，不是概念上的对应。