大模型分词技术以及相关的有趣现象：论文笔记

来源 PDF：大模型分词技术以及相关的有趣现象.pdf

0. 一句话总结

Tokenizer 不是简单的文本预处理模块，而是大模型效率、语义表达、多语言能力、生成稳定性和推荐系统建模方式的重要组成部分。词表大小、分词算法、低频 token 覆盖、输入/输出词表设计都会影响模型训练和推理表现。

0.1 结构化阅读卡片

解决什么问题？

这篇文章主要解决的是：为什么大模型必须分词，以及 tokenizer 会如何影响模型效率、训练成本、多语言能力和生成稳定性。

具体包括五类问题：

1. 文本不能直接输入神经网络，必须先变成 token ID。
2. 字符级切分序列太长，词级切分词表太大，因此需要子词分词。
3. 不同 tokenizer 的词表大小不同，会导致压缩率、显存占用、推理速度差异。
4. 大词表会带来低频 token 学习不足的问题，例如“马嘉祺”案例。
5. 推荐系统中的用户行为序列也面临类似的 tokenization 问题，不能只用静态 item ID 表示。

用了什么方法？

文章主要介绍和串联了以下方法：

1. 子词分词方法：BPE、WordPiece、Unigram、SentencePiece。
2. 词表规模分析：通过压缩率、词表大小、embedding / LM Head 参数量分析 tokenizer 的效率和代价。
3. Tokenizer Scaling Law：讨论模型规模、训练 FLOPs 和最优词表大小之间的关系。
4. 输入/输出词表解耦：通过 Over-Tokenized Transformer 说明输入词表和输出词表的扩展收益不同。
5. 案例 Debug：用“马嘉祺”案例解释低频 token 在 SFT、LM Head 和采样阶段可能出现的生成失败。
6. 推荐系统迁移：用 ActionPiece 把 BPE 式 token 合并思想迁移到用户行为序列建模。

关键启发是什么？

关键启发是：

Tokenizer 是模型能力的一部分，不是无关紧要的预处理步骤。

具体启发包括：

• 词表越大，文本压缩率通常越高，但低频 token 更难训练好。
• tokenizer 一旦确定，就会绑定模型参数、训练数据和推理生态，所以大模型迭代时通常不轻易换词表。
• 多语言模型的效果不仅取决于训练数据，也取决于不同语言在 tokenizer 下被切得是否高效。
• 模型“知道但说不出”某个词，可能不是知识缺失，而是 token 生成概率、后训练覆盖和 LM Head 问题。
• 推荐系统也可以借鉴 tokenizer 思想，把 item ID 升级为上下文感知的行为 token。

作者想表达什么？

文章想表达的是：

分词器决定了模型如何“看见”和“生成”文本。它影响序列长度、计算成本、词表参数、低频词学习、多语言公平性和下游任务建模方式，因此应该被当成大模型系统设计的重要组成部分。

换句话说，tokenizer 不只是把字符串切一切，而是大模型输入输出空间的底层协议。

总结是什么？

可以总结为三句话：

1. 大模型需要 tokenizer，是因为模型只能处理数字，而子词分词能在字符级和词级之间取得平衡。
2. tokenizer 的词表大小会影响压缩率、训练成本和低频 token 稳定性，因此存在效率与模型容量之间的权衡。
3. 从 LLM 到推荐系统，tokenization 的本质都是把原始对象转成更适合模型学习的离散语义单元。

1. 为什么需要分词？

自然语言原始形态是文本，但神经网络只能处理数值。因此文本进入模型前必须被转换成整数 ID 序列：

文本 → Tokenizer → Token 序列 → Token ID 序列 → Embedding → 模型

最直接的两种方式都有明显问题：

现代大模型主流采用 子词分词（Subword Tokenization）：

• 高频词或常见片段保留为完整 token；
• 低频词、生僻词拆成更小的子词；
• 在词表大小、序列长度、语义表达和泛化能力之间取得折中。

核心目标是：

用有限词表表示开放词汇，同时尽量减少 token 数量。

2. 主流分词算法

现代 tokenizer 通常先把文本统一成 Unicode 字符序列，再进行子词学习。这样中文、英文、标点、emoji 等都能被统一处理，底层不需要依赖具体语言规则。

2.1 BPE：Byte Pair Encoding

BPE 的核心思想是：

从字符级开始，不断合并训练语料中出现频率最高的相邻 token 对。

基本流程：

1. 初始化：每个字符都是一个 token；
2. 统计所有相邻 token pair 的出现频率；
3. 合并频率最高的 token pair；
4. 更新语料中的 token 序列；
5. 重复直到词表达到目标大小。

示例：

lower, lowest
可能学到：low, er, est

特点：

• 简单、高效；
• 贪心合并，只保证局部最优；
• 常用于 GPT 系列、RoBERTa 等模型。

2.2 WordPiece

WordPiece 和 BPE 类似，也从小词表逐步扩展，但合并依据不是单纯频率，而是：

选择能最大化训练数据似然的子词。

常见标记方式是用 ## 表示非词首子词：

playing → play + ##ing

特点：

• 相比 BPE 更强调语言模型概率；
• BERT、DistilBERT 等模型采用 WordPiece；
• 对英文词缀、词根结构比较友好。

2.3 Unigram Language Model

Unigram 的方向和 BPE / WordPiece 相反：

先构造一个很大的候选词表，再逐步剪枝，删除贡献较小的子词。

基本流程：

1. 初始化一个尽可能完整的候选词表；
2. 用语言模型和 EM 算法估计每个子词的重要性；
3. 删除对整体似然影响最小的一批子词；
4. 重复剪枝直到词表达到目标大小。

特点：

• 支持概率化切分；
• 同一句话可以有多种合理分词路径；
• 算法根据概率选择最优切分；
• T5、XLM 等模型采用过该类方法。

2.4 SentencePiece

传统 BPE 往往先做预分词，例如按空格切成单词，再在单词内部做 BPE。这对英语自然，但对中文、日文等无空格语言不友好。

SentencePiece 的核心创新是：

直接在原始文本上学习分词，不依赖空格作为词边界。

它还会把空格显式编码成普通字符，常见形式是 ▁。这样分词结果可以无损还原回原始文本。

特点：

• 不依赖语言特定规则；
• 对中文、日文、多语言混合更稳健；
• LLaMA、Mistral 等主流开源模型常用 SentencePiece 或类似思想。

2.5 四种算法对比

3. 分词对大模型的影响

3.1 词表大小与压缩率

压缩率可以理解为：

同一段文本下：

Token 数越少 → 序列越短 → 压缩率越高

大词表通常能提高压缩率，因为它能收录更多常见长片段。

例如：

人工智能

小词表可能切成：

人 / 工 / 智 / 能

大词表可能切成：

人工智能

所以大词表的直观效果是：

词典更厚，常见词或短语可以直接查到，不必拆得太碎。

需要注意：原文中“更细粒度的常用词被整体保留”更准确应表述为“更粗粒度的常用片段被整体保留”。

3.2 大词表的代价

词表不是免费扩大的。词表大小为 (V)，隐藏维度为 (d) 时，输入 embedding 参数约为：

输出层 LM Head 通常也与词表大小相关。词表越大：

• embedding 参数越多；
• LM Head 参数越多；
• softmax 输出维度越大；
• 训练通信和显存压力增加；
• 低频 token 更难被充分训练。

因此 tokenizer 设计本质上是在做权衡：

3.3 PDF 中给出的模型词表大小

下表为 PDF 中的摘录，实际工程中建议以官方 tokenizer 配置为准。

3.4 为什么大模型迭代时通常不迭代词表？

主要原因有两个。

第一，生态惯性。

Tokenizer 绑定了：

• token-id 映射；
• embedding 参数；
• LM Head 参数；
• 预处理后的训练数据；
• LoRA / adapter；
• 推理引擎；
• 量化和部署工具链。

换词表相当于改变模型底层接口。

第二，收益边际递减。

当词表已经达到 100K 以上时，继续扩大词表带来的压缩率提升有限，但参数、训练、兼容性和低频 token 问题仍然存在。

所以大模型一般在预训练前确定 tokenizer，后续版本尽量沿用。少量追加特殊 token 可以做，但大规模换词表通常只会发生在新一代模型重新训练时。

3.5 分词与多语言能力：Token Tax

Token Tax 指不同语言在同一个 tokenizer 下会被切成不同数量的 token，从而承担不同计算成本。

例如：

• 英语、拉丁文字语言通常 tokenization 效率较高；
• 非拉丁文字语言、形态复杂语言可能需要更多 token；
• token 数越多，同样语义表达需要更长序列，训练和推理成本更高。

相关概念：

Token Fertility：平均每个词被切成多少 token。

Token Fertility 越高，说明一种语言被切得越碎，模型处理成本越高，效果也可能下降。

4. Tokenizer 也有 Scaling Law 吗？

这一部分的核心问题是：

模型变大时，词表大小和 tokenizer 设计是否也应该一起 scaling？

答案是：应该考虑，而且不能只看模型参数量，还要看输入词表、输出词表和训练 FLOPs。

4.1 Scaling Laws with Vocabulary

核心观点：

更大的模型通常需要更大的词表。

传统 scaling law 主要关注：

• 模型参数量；
• 训练数据量；
• 训练 FLOPs。

但这篇工作把词表大小也纳入 scaling law，认为在给定 FLOPs 预算下存在一个最优词表大小。

词表太小：

• 文本切得碎；
• 序列变长；
• 上下文窗口被浪费；
• 计算效率下降。

词表太大：

• embedding / LM Head 参数增加；
• 输出 softmax 更贵；
• 低频 token 训练不足。

所以最优词表大小取决于计算预算和模型规模。

4.2 Over-Tokenized Transformer

这篇工作的关键洞察是：

输入词表和输出词表的作用不同，应该解耦分析。

因此，大输入词表通常更划算，而大输出词表不一定总是有益，尤其对小模型可能有害。

Over-Encoding

扩大输入词表，例如加入更多 n-gram 输入 token，让输入表示更紧凑。

作用：

• 缩短序列；
• 提升输入信息密度；
• 成本相对可控。

Over-Decoding

扩大输出侧监督，例如预测 n-gram token 或引入更丰富的输出监督。

作用：

• 给模型更细粒度或更高阶的生成信号；
• 对大模型可能有效；
• 对小模型可能增加学习难度。

4.3 Visual Tokenizer 的 Scaling Law

图像生成模型中也存在 tokenizer，只是它不是文本 BPE，而是 visual tokenizer，例如 VAE、VQ-VAE 或 latent encoder。

它的作用是：

图像像素 → latent token → 生成模型建模

普通 visual tokenizer 如果只优化重建，容易过度关注低层像素细节，而生成模型更需要高层语义。

MiniMax 相关工作强调：

• 图文对比学习；
• 自监督学习；
• 重建损失；
• 面向生成任务的 latent 表示。

核心结论：

tokenizer 训练本身也值得 scale；更好的 latent token 会提升后续生成模型效果。

5. 新闻热点：为什么大模型不认识马嘉祺？

这一部分讲的是一个典型 tokenizer 案例：

模型知道一个实体，但生成时打不出对应文字。

5.1 现象

模型能够讲清楚马嘉祺的履历，却可能无法稳定输出“嘉祺”两个字。

这说明问题未必是知识缺失，而可能是：

语义知识存在，但 token 生成通道出了问题

5.2 Minimax Debug 的关键发现

“嘉祺”被分词为一个独立 token。

如果模型生成“马嘉祺”时实际路径是：

马 / 嘉祺

而不是：

马 / 嘉 / 祺

那么“嘉祺”这个整体 token 的训练覆盖就非常关键。

PDF 中提到：

• 预训练阶段该 token 的 embedding 和 LM Head norm 看起来正常；
• 相似 token 包括“亚轩、千禧、祺、耀文、嘉”等；
• 说明预训练阶段可能学到了一定语义；
• 问题主要出在后训练 SFT 阶段。

如果 SFT 数据中“嘉祺”出现极少，低频中文 token 的输出权重可能被挤压，导致生成概率很低。

5.3 top-p 采样会放大低频 token 问题

生成时如果使用 top-p，例如 (p=0.95)，模型只保留累计概率前 95% 的候选 token。

如果“嘉祺”概率过低，即使模型有一定知识，也可能在采样前就被过滤掉。

表现就是：

模型知道这个人，但打不出这个名字

5.4 解决方案

PDF 中给出两个方向。

方案一：复读全词表

把全词表切成若干份，例如每份约 8K token，构造简单监督任务：

请重复以上内容：<一批 token>

输出就是相同 token。

目的：

保证 SFT 阶段每个 token 至少被覆盖，防止低频 token 生成能力退化。

方案二：删除尾部分布 token

对于后训练和实际使用中几乎没有场景的尾部 token，可以考虑不放入词表，避免训练不足的整体 token 干扰生成。

本质上，这是 BPE 合并结果和训练数据分布不匹配导致的问题。

5.5 LM Head 梯度瓶颈

PDF 关联到论文《Lost in Backpropagation: The LM Head is a Gradient Bottleneck》。

语言模型最后通常有一层 LM Head：

其中：

• (D)：hidden size；
• (V)：词表大小。

当 (V) 远大于 (D) 时，梯度通过 LM Head 反向传播会被压缩。低频 token 本来梯度就少，再经过这个瓶颈后更难学到稳定表示。

这解释了为什么大词表里的尾部 token 容易出现：

• 训练慢；
• 生成概率低；
• 输出区分度差；
• 生僻中文、人名、外语 token 生成失败。

6. 对推荐系统的启发

第六部分讨论的是将 NLP 分词思想迁移到推荐系统，代表方法是 ActionPiece。

6.1 传统生成式推荐的问题

生成式推荐通常把用户行为序列看成：

item_1, item_2, item_3, ...

然后像语言模型预测下一个词一样预测下一个 item。

问题是：

同一个 item 在不同用户上下文中可能有不同语义。

例如同一件 T 恤：

运动鞋 → 健身裤 → T恤

更像“运动穿搭”语义。

而：

项链 → 半身裙 → T恤

更像“时尚搭配”语义。

如果始终用固定 item ID 表示该商品，就会忽略上下文语义。

6.2 ActionPiece 的核心思想

ActionPiece 不直接把 item 当成单一 token，而是把一个用户行为表示成特征集合：

{品牌: Nike, 类目: T恤, 颜色: 白色, 价格: 中等, 风格: 运动}

然后借鉴 BPE：

频繁共现的特征或行为片段 → 合并成更高层 token

这样可以学习：

• item 内部特征组合；
• 相邻行为之间的转移模式；
• 用户行为上下文中的高阶语义。

6.3 两类 token pair 合并

ActionPiece 统计两类共现。

第一，同一行为内部的特征共现：

Nike + 运动鞋
白色 + T恤
高价 + 奢侈品牌

第二，相邻行为之间的特征共现：

运动鞋 → 健身裤
手机 → 手机壳
奶粉 → 纸尿裤

这样得到的 token 不只是商品 ID，而是有上下文含义的行为片段。

6.4 SPR：Set Permutation Regularization

Set Permutation Regularization 可译为：

集合排列正则化 / 集合内元素随机重排正则化

原因是一个行为的特征集合本身无序：

{品牌: Nike, 类目: T恤, 颜色: 白色}

和：

{颜色: 白色, 品牌: Nike, 类目: T恤}

语义相同。

SPR 会随机打乱集合内部特征顺序，生成多个等价训练样本，避免模型错误依赖特征排列顺序。

6.5 训练与推理

训练阶段：

1. 把用户行为序列转换成特征集合序列；
2. 使用 ActionPiece 做上下文感知 tokenization；
3. 通过 SPR 构造多个等价序列；
4. 用 Transformer 做自回归训练。

推理阶段：

1. 对同一输入生成多个 SPR 版本；
2. 分别推理；
3. ensemble 得到更稳定的推荐结果。

6.6 对推荐系统的核心启发

核心思想：

推荐系统的 tokenization 不应该只是静态 item ID 映射，而应该考虑上下文、属性组合和行为转移模式。

7. 关键概念速查

8. 个人整理版结论

1. 分词器决定了模型看世界的基本单位。
   它不是无关紧要的预处理，而是模型架构和训练体系的一部分。

2. 大词表能提高压缩率，但也会带来尾部 token 学习问题。
   压缩率、参数量、softmax 成本、低频 token 覆盖必须同时考虑。

3. 词表通常在预训练开始前确定。
   后续小版本一般不改 tokenizer，最多追加少量特殊 token。

4. 多语言模型的 tokenizer 直接影响语言公平性。
   被切得越碎的语言，训练和推理成本越高，模型效果也可能更差。

5. Tokenizer 存在 scaling 问题。
   大模型可能需要更大词表，但输入词表和输出词表应分别设计。

6. 低频 token 生成失败不一定是知识缺失。
   也可能是 SFT 覆盖不足、LM Head 梯度瓶颈和采样策略共同导致。

7. 推荐系统可以借鉴分词思想。
   用户行为不一定只能表示为 item ID，也可以构造成上下文感知的行为 token。

Tokenizer 是大模型的“输入输出接口层”：它既决定文本如何被压缩成序列，也决定模型输出空间如何组织。一个好的 tokenizer 需要在压缩率、词表规模、多语言公平性、低频 token 学习和下游生态兼容性之间取得平衡。