分词与多语言处理

引论：为什么"分词"是 LLM 一切奇怪行为的根源

"We will see that a lot of weird behaviors and problems of LLMs actually trace back to tokenization. … Why someone out there ideally finds a way to delete this stage entirely." — Andrej Karpathy

打开任意一篇关于大语言模型（LLM）的论文，你会读到 transformer、attention、scaling laws、RLHF… 唯独很少有人花一整章去讲分词（tokenization）——这个把人类文字喂进模型之前的"预处理步骤"。 然而正是这个看似平凡的步骤，决定了：

• 模型为什么数不清 strawberry 里有几个 r；
• 为什么同样一句话，缅甸语用户要支付英语用户 15 倍的 API 费用；
• 为什么 GPT-3 听到 SolidGoldMagikarp 这种诡异字符串会"精神错乱"；
• 为什么 LLM 在低资源语言上的性能可以差 30 个百分点；
• 为什么算术、字符串反转、Python 缩进这些"小事"会成为 LLM 的死穴。

分词不是一个工程细节，而是语言模型的本体论——它定义了模型眼中"语言的原子"是什么。 原子选错了，下游一切都会跑偏。这门课要带你看到，tokenization 是 LLM 的隐形基石，也是隐形天花板。

第一部分：分词的语言学与计算基础

1.1 什么是"词"？语言学的尴尬定义

看似简单的问题："下面这句话有几个词？"

我们可以"凭空格"数出 17 个词，但这种朴素切分会立刻撞墙：

• We'd = we + had——这是 1 个词还是 2 个词？
• looked = look + -ed——后缀 -ed 携带过去式信息，难道不算独立单位？
• Milky Way 是一个专有名词实体（银河系），但被空格切成 2 个 token；
• sat = sit + -ed，但这是一个不规则变化（屈折），按形式根本切不开。

为了把上述模糊性收紧，语言学家用词素（morpheme）这个更精细的概念：

词素粒度也并非完美：sat（坐的过去式）显然包含 sit + 过去时的语义，但在拼写上无法机械拆出 -ed； 而 Milky Way 是一个整体专有名词，按词素切反而丢失语义。 这就是语言学家给我们的第一个教训：不存在一个"客观正确"的分词粒度。

1.2 词、词素、字符、短语：分词粒度的连续谱

不同粒度的分词如同把同一句话用不同分辨率显微镜观察：

当代主流 LLM（GPT、Llama、Gemini、Claude、DeepSeek）都没有选择上面任何一种原始方案，而是选择了一个数据驱动的折衷—— 子词（subword）分词，本教材的核心算法 BPE 即属于此。我们稍后会看到，子词的"token"通常并不对应任何语言学单位， 但凭借数据统计的力量，它意外地工作得非常好。

1.3 语言模型如何"看见"文本

要理解为什么 tokenization 如此关键，我们需要先把 LLM 的"视觉"过程完整还原一遍：

注意两个隐藏但关键的事实：

1. Tokenizer 是一段独立代码，不是 transformer 的一部分。它通常在预训练之前就被独立训练并冻结。
2. Decode 是 encode 的逆过程，但因为分词的多对一映射，decode 时必须使用相同的 tokenizer。 若你用 Llama tokenizer encode、用 GPT tokenizer decode，结果将是乱码。

1.4 词表大小如何影响参数量与序列长度

词表大小 $|V|$ 是 tokenizer 最重要的超参数。它通过两个独立通道影响模型：

(a) 参数量通道

嵌入矩阵 $\mathbf{E} \in \mathbb{R}^{|V| \times d_\text{model}}$ 与输出投影 $\mathbf{W}_\text{out} \in \mathbb{R}^{d_\text{model} \times |V|}$（在很多模型中权重共享）直接随 $|V|$ 线性增长：

(b) 序列长度通道

更细的分词 = 同样文本变成更长的 token 序列。Self-attention 的复杂度是序列长度的平方：

所以选择 $|V|$ 总是在权衡：更大的词表 → 更短的序列 + 更稀疏的语义 + 更多嵌入参数； 更小的词表 → 更密集的语义 + 更长的序列 + 更难训练的低频长尾。

第二部分：三大经典分词方案

2.1 词级分词：Zipf 定律与 OOV 的诅咒

最朴素的方案：按空格切，再加上标点处理。这有两个根本困难。

困难一：词表无上限增长

更糟糕的是，词频遵循 Zipf 定律——一个词排名为 $r$，频率与 $1/r$ 成正比：

困难二：Out-Of-Vocabulary (OOV) 必然发生

即使你把训练语料里所有词都收入词表，也无法防止：

• 新造词：Merriam-Webster 字典每版增 5000 个新词（rizz, doomscroll, vibe coding）；
• 拼写错误：importaNt；
• 专有名词：地名、人名、产品名层出不穷；
• 形态变化：英语屈折少，但希腊语动词有 100+ 形式，土耳其语理论上可以单词长到数十字符（凝集语）。

传统应对方案：

2.2 字符/字节级分词："tokenizer-free"的诱惑

另一个极端：把每个字符（或每个字节）当作 token。词表瞬间收缩到几十到几百个槽。

争议至今未息：字符级模型究竟更"难"还是更"清晰"？Karpathy 在 2024 年的播客里强烈支持"长期来说我们应该删掉 tokenization 这一步"。Part 8 我们会重新审视这个方向的最新研究。

2.3 子词分词：词与字符之间的最优中庸

工业界 2016 年以来的事实标准：子词（subword）分词。核心思想：

让数据告诉我们词表应该是什么。频繁组合的字符序列升级为单个 token； 罕见词自动被切成更小的字符片段。最频繁的"完整词"（如 the）保持为单个 token； 而 antidisestablishmentarianism 这种罕见词可能被切成多个有意义的子词单元。

子词的设计哲学：

• 从数据出发：用语料频率统计决定切分边界；
• 词表大小可控：通常 30k–250k，由超参数 $N$ 决定；
• 零 OOV：因为最基础的字节都在词表里，任何输入都可被表示；
• 子词重用：picked 和 picking 可共享 pick 子词，提升泛化。

三大主流子词算法：

本教材聚焦 BPE，因为它已成为 GPT、Llama、Gemini、Claude、DeepSeek、Qwen、Mistral 等所有前沿模型的事实标准。

第三部分：字节对编码 BPE 算法深度解析

3.1 为什么所有前沿模型都用 BPE？

看看 2025–2026 年度主流 LLM 的分词器：

为什么所有人都选 BPE？三大原因：

1. 历史遗产：GPT-2 (2019) 使用 BPE 并开源后，整个开源生态都跟进了；
2. 简单且确定：训练算法仅 ~30 行代码；测试时分词是贪心的，无歧义；
3. 压缩效率好：BPE 实际上是一个数据压缩算法（Gage, 1994），它会自动找出高频 n-gram。

3.2 BPE 训练算法的形式化描述

输入：
  D    — 训练语料（字符串集合）
  N    — 目标词表大小

输出：
  V    — 词表（token 集合）
  M    — 有序合并规则列表 [(v_a, v_b) → v_new, ...]

步骤：
  1. Pre-tokenize: 按空格切 D，得到"词序列"
  2. 初始化 V ← {所有字节} ∪ {空格符 _}
  3. 将 D 转换为字节序列（每个字符 → 1+ 字节）
  4. M ← []
  5. while |V| < N:
       a. 统计 D 中所有相邻 token 对 (v_i, v_j) 的频率
       b. 取频率最高的对 (v_a, v_b)
       c. 创建新 token v_new = v_a + v_b
       d. V ← V ∪ {v_new}
       e. M.append((v_a, v_b) → v_new)
       f. 将 D 中所有 (v_a, v_b) 替换为 v_new
  6. return V, M

关键设计选择：

• 预分词（pre-tokenization）：先按空格切。这样合并不会跨越词边界，保证每个 token 不会同时包含两个不相关的词碎片。
• 最高频合并：贪心选择，不回溯；非常类似数据压缩中的 BPE。
• 有序合并规则：M 的顺序至关重要，测试时必须按相同顺序应用，否则结果不一致。

3.3 完整训练 Walkthrough：Peter Piper 示例

让我们用 PDF 课件里的小语料完整走一遍：

语料 D = "Peter Piper picked a peck of pickled peppers"

步骤 1：Pre-tokenize

按空格切，并在每个词前加上空格标记 _（表示"词首"，这是 GPT-2 BPE 的惯例）：

步骤 2：初始化词表

$V_0 = \{$_, a, c, d, e, f, i, k, l, o, p, P, r, s, t$\}$ — 共 15 个字节。

步骤 3：把语料转成 token 序列

P e t e r _ P i p e r _ p i c k e d _ a _ p e c k _ o f _ p i c k l e d _ p e p p e r s

步骤 4–N：迭代合并

统计所有相邻对的频率，找出最高的 7 个：

1. _ + p → _p

V = V_0 ∪ {_p}

1. _ + p → _p
2. c + k → ck

1. _ + p → _p
2. c + k → ck
3. e + r → er

1. _ + p → _p
2. c + k → ck
3. e + r → er
4. _p + e → _pe

5. _p + i → _pi

6. _pi + ck → _pick

…依此类推，直到 $|V| = N$。

3.4 测试时分词：贪心应用合并规则

训练完成后，得到了词表 $V$ 和有序合并规则 $M$。对新文本 _pier：

3.5 Python 实现：从零写一个 BPE

为了让你彻底吃透算法，下面是一份 可运行 的极简 BPE 实现（仅 ~50 行）：

from collections import Counter, defaultdict

def get_stats(corpus):
    """统计相邻 token 对的频率。corpus: List[List[str]]"""
    pairs = Counter()
    for word in corpus:
        for i in range(len(word) - 1):
            pairs[(word[i], word[i+1])] += 1
    return pairs

def merge_pair(corpus, pair):
    """把语料中所有 pair (a,b) 替换为 'a+b'"""
    a, b = pair
    new_corpus = []
    for word in corpus:
        i = 0
        new_word = []
        while i < len(word):
            if i < len(word) - 1 and word[i] == a and word[i+1] == b:
                new_word.append(a + b)
                i += 2
            else:
                new_word.append(word[i])
                i += 1
        new_corpus.append(new_word)
    return new_corpus

def train_bpe(text, vocab_size):
    """BPE 训练主函数"""
    # Step 1: pre-tokenize (按空格切，每个词前加 _ 标记词首)
    words = ["_" + w for w in text.split()]
    # 转成 List[List[str]]，每个内层 list 是字符序列
    corpus = [list(w) for w in words]
    # 初始化词表
    vocab = set(ch for word in corpus for ch in word)
    merges = []  # 有序合并规则

    while len(vocab) < vocab_size:
        pairs = get_stats(corpus)
        if not pairs:
            break
        best_pair = max(pairs, key=pairs.get)
        if pairs[best_pair] < 2:  # 不再有可合并对
            break
        corpus = merge_pair(corpus, best_pair)
        new_token = best_pair[0] + best_pair[1]
        vocab.add(new_token)
        merges.append(best_pair)

    return vocab, merges

def tokenize(text, merges):
    """测试时分词：按 merges 顺序贪心应用"""
    words = ["_" + w for w in text.split()]
    result = []
    for word in words:
        tokens = list(word)
        for pair in merges:
            tokens = merge_pair([tokens], pair)[0]
        result.extend(tokens)
    return result

# Demo
text = "Peter Piper picked a peck of pickled peppers"
vocab, merges = train_bpe(text, vocab_size=25)
print("Merges:", merges[:6])
# [('_', 'p'), ('c', 'k'), ('e', 'r'), ('_p', 'e'), ('_p', 'i'), ('_pi', 'ck')]

print(tokenize("pier picked", merges))
# ['p', 'i', 'er', '_pick', 'e', 'd']

3.6 BPE 的姐妹算法：WordPiece 与 Unigram LM

WordPiece

BERT、DistilBERT、ELECTRA 使用。改动很简单：合并准则不是频率，而是合并后对训练数据似然的提升：

Unigram Language Model

Kudo (2018) 提出，被 SentencePiece 默认采用，T5、XLM-R、Llama 2 都基于它。哲学完全相反：

1. 初始化：从一个超大词表开始（数百万个候选子词，包括所有可能的字符 n-gram）；
2. EM 迭代：
   • E 步：对每个词，计算用当前词表分词的所有可能切分及其概率；
   • M 步：根据当前切分的统计量更新每个子词的 unigram 概率；
3. 修剪：删除对总似然贡献最小的 X% 子词；
4. 重复 2–3 直到词表大小达到目标 $N$。

Unigram LM 的一个独特优势：测试时可以产生多个可能的切分，每个切分有概率。这支持 BPE 不支持的子词正则化（subword regularization）——训练时随机采样不同切分，等价于数据增强。

第四部分：超越 BPE — SentencePiece 与 SuperBPE

4.1 Pre-tokenization 的代价：为什么按空格切并不普适

回顾 BPE 算法的第 1 步：按空格切。这个"无害"假设隐含着两个大问题：

问题 1：很多语言不用空格

• 中文：「我喜歡自然語言處理」没有空格；
• 日文：「私は自然言語処理が好きです」混合假名汉字；
• 泰文：「ผมชอบประมวลผลภาษาธรรมชาติ」整段没有空格。

按空格切，对这些语言相当于不切，整个句子是一个"词"，BPE 完全失去其设计前提。

问题 2：多词表达（multi-word expressions）

英文里 on the other hand、depend on、kick the bucket 是固定搭配， 但按空格切后变成多个独立 token，模型必须靠 attention 重新把它们"粘"起来。

4.2 SentencePiece：把空格当字符的库

Google 2018 年发布的 SentencePiece 库提出了一个简洁方案：

这样：

• 中文句子可以"自然"形成子词，不需要任何中文分词器；
• 分词与还原是无歧义可逆的（reversible），只要 "".join(tokens).replace("▁", " ")；
• 多语言可统一处理。

SentencePiece 不是一个算法——它是一个实现库，里面同时支持 BPE 和 Unigram。 T5、Llama 2、XLM-R、Gemma 都用 SentencePiece + Unigram；Llama 3、4 切换到 SentencePiece + BPE。

4.3 SuperBPE：跨越空格的"超级词"

2025 年 Liu et al. 提出 SuperBPE，对预分词的"教条"做了进一步突破：

直观看效果：

效果：

• 同等 $|V|$ 下，序列长度减少约 30%；
• 推理计算成本同步下降；
• 多词表达自动成为单 token（By the way,、Milky Way）。

第五部分：分词的隐秘代价

即使 BPE 已是 LLM 的事实标准，它远未"解决所有问题"。本部分聚焦三个广为人知的失败模式。

5.1 草莓里有几个 r？Spelling 的根本失败

2024 年最有名的 LLM "笑话"：

用户：How many 'r's are in 'strawberry'？
ChatGPT (GPT-4o)：There are two "r"s in the word "strawberry."
用户：Verify with code.
ChatGPT：There are three "r"s in the word "strawberry."

为什么连"数字母"这种小学一年级问题，最强 LLM 都数不对？根源就在分词：

两者都没法让模型"看到"单个字符 r。模型必须从"strawberry"这个不透明 token 的嵌入向量里"反推"出它的字符组成——而这从未在训练目标里被监督过。

更广义地说，子词模型在以下任务上系统性失败：

5.2 故障 Token：SolidGoldMagikarp 之谜

2023 年 2 月，一组研究者发现 GPT-3 对某些字符串表现出极端诡异行为：

用户：Tell me about SolidGoldMagikarp.
GPT-3：（输出关于宝可梦 Magikarp 的内容，但坚持把"SolidGold"误读为"distribute"）

用户：Is there a difference between SolidGoldMagikarp and SolidGoldMagikarp？
GPT-3：（声称两者完全不同，回答语无伦次）

还有比如 petertodd、attRot、NOTHING IS FAIR IN THIS WORLD OF MADNESS 等等。这些被称为 glitch tokens（故障 token）。

有名的研究 "Fishing for Magikarp" (Land & Bartolo, 2024) 系统性地在 GPT-2、Llama 2/3、OLMo、Qwen 等模型上自动检测了这类 token，发现每个模型都有数百到数千个。

故障 token 的危害不仅是"好奇心"：

• 浪费词表槽位：本应给低资源语言的 token 被废 token 占用；
• 对抗攻击面：攻击者用故障 token 触发不可预测行为，绕过 safety filter；
• API 不稳定：用户输入若包含故障 token，可能突然得到乱码或重复输出。

5.3 Tokenization 与所有"奇怪行为"的对照表

Karpathy 在 2024 年播客里给出的"症状—病因"表，至今仍准确：

第六部分：多语言 NLP — 当世界不只是英语

6.1 7000 种语言与 40% 英语的 Common Crawl

全世界有超过 7000 种活语言。但 NLP 的全部训练数据严重偏向英语：

• 约 20% 的人口能说英语；只有 5% 是英语母语者；
• Common Crawl（最大的开放网络爬虫语料）中40–45% 是英语；
• 许多低资源语言（Tagalog 他加禄语、Amharic 阿姆哈拉语、Yoruba 约鲁巴语）不到 0.01%。

推荐资源：

• World Atlas of Language Structures (WALS)：2700 种语言的形态/句法/音系特征数据库；
• Ethnologue：人口统计学层面的语言数据；
• Glottolog：语言谱系树与分类学。

6.2 多语言语言模型的架构演化

多语言语言模型（multilingual LM）架构上和单语言完全相同。唯一差别是训练数据和分词器都覆盖多语言。

2018 年至今主要里程碑：

6.3 跨语言迁移：XLM-R 的奇迹

多语言 LM 最神奇的能力是 cross-lingual transfer（跨语言迁移）：

在英语标注数据上 fine-tune 一个分类头，然后直接在从未见过任何标注数据的法语、中文、Swahili 上做预测——竟然也能 work。

为什么这能 work？两个核心机制：

1. 共享子词词表：相近语言（如英语、法语）会有大量重叠 token，比如 nation、solution；
2. 对齐的语义空间：MLM 训练迫使模型把"上下文相似"的词放到向量空间的相近位置，这一性质跨语言传递。

6.4 词表重叠与跨语言对齐

研究表明（Limisiewicz et al., 2023；Kallini et al., 2025a）：

反例：XLM-V 把词表扩大到 100 万 token（XLM-R 的 4 倍），给每种语言更多专属 token。 覆盖率确实更好，但推理效率代价巨大，且某些跨语言任务上表现反不如 XLM-R。

6.5 多语言的诅咒：容量与覆盖的取舍

"既然跨语言迁移这么神奇，那加上几千种语言不就完美了吗？"——并非如此。

应对方案：

• 扩大模型容量：mT5-XXL (13B)、BLOOM (176B) 在更多语言下仍保持性能；
• 语言特定模块：MAD-X (Pfeiffer et al., 2020) 给每种语言加 adapter，避免参数冲突；
• 专家混合 (MoE)：让不同 expert 处理不同语言族。

第七部分：分词的公平性问题

7.1 Token 通胀：同样意思在缅甸语要多花 15 倍

回到 PDF 课件里那张表——同一句话在不同语言里被切成多少 token：

更刺眼的对比来自 Petrov et al. 2023：

7.2 子词肥沃度与下游性能的负相关

Rust et al. (2021) 给出了关键论断：

分词器的选择对下游性能的影响，可以和预训练数据集规模相当。 也就是说，给一个语言适配的 tokenizer 可能比单纯堆更多数据更重要。

7.3 API 定价不公的伦理含义

商业 LLM API 几乎都按 token 数计费。这意味着：

这是双重不公：(1) 价格更高；(2) 质量更低。 分词不再只是工程细节，而成为数字鸿沟的算法化。

第八部分：字符/字节级模型的复兴

本课最有 inspirational 价值的部分。多语言公平性、Spelling 失败、Glitch token 这一切问题， 都可以被一个根本方案绕过：不要 tokenizer 了。直接在字节上训练。

8.1 CANINE：mBERT 的字符级对手

Clark et al. (2022) 提出的 CANINE 是字符级 multilingual 模型：

• 输入是 Unicode codepoint（覆盖所有语言）；
• 用 hash embedding 把巨大的 codepoint 空间压缩到固定维度；
• 用一个 downsample CNN 把字符级序列降采样到子词级长度，再喂给 Transformer。

在 MasakhaNER（11 种非洲语言 NER 基准）上的尤其抢眼结果——CANINE-C 在 Amharic 上 F1 = 50.0，mBERT = 0.0。 原因：mBERT 完全没在 Amharic 上训练；CANINE-C 字符级覆盖让它能"看懂"全 Unicode。

8.2 ByT5 与 MrT5：动态删除的字节序列

ByT5 把 T5 的 SentencePiece 替换成纯字节输入，证明字节级模型可以匹敌子词模型，但代价是更长的序列和更慢的训练。

2025 年 MrT5 (Kallini et al.) 在 ByT5 基础上加入一个可学习的"删除门"（delete gate），让模型动态决定哪些字节可以丢弃：

MrT5 的精彩之处：学到的删除模式因语言而异——中文的 codepoint 被大量保留（信息密度高），英文的字节被大量删除（冗余多）。这本质上是把分词学进了模型架构，而非作为预处理步骤。

8.3 Byte Latent Transformer (BLT)：熵驱动的动态 patch

Meta 2024 年的 BLT (Pagnoni et al., 2025) 提出更激进的设计：

• Local Encoder：用小型 transformer 处理原始字节；
• 动态 patch 划分：根据局部熵把字节序列切成可变长度的"patch"；
• Latent Transformer：在 patch 级别上做主要计算；
• Local Decoder：把 patch 表示解码回字节。

BLT 在 8B 参数级别上首次匹敌 Llama 3 8B（subword 模型），同时使用 50% 更少的推理 FLOP。

8.4 H-Nets 与层次化自回归 Transformer

两条平行的新方向：

• H-Nets (Hwang et al., 2025)：用 chunking/dechunking 层在不同分辨率间转换；
• Hierarchical Autoregressive Transformers (Neitemeier et al., 2025)：encoder-decoder 在词级聚合，主 backbone 在词级 attention；
• Bolmo (Minixhofer et al., 2025) 和 EvaByte (Zheng et al., 2025)：相似哲学的变体。

8.5 潜在分词：把"切词"也学进去

字符/字节级模型解决的不只是公平性，还包括：

2025–2026 年最重要的开放问题：动态字节级 / latent tokenization 能否在保持质量的同时把推理效率推到与 BPE 相当？ 若答案是肯定的，整个 tokenizer 这一层有可能在未来 5 年内消失。

第九部分：练习题与研究方向

课后练习

研究方向

1. 更好的多语言分词器：能否设计一个分词算法，给所有语言一个"公平"的 fertility 上限？
2. 潜在分词的可解释性：BLT/H-Nets 学到的 patch 划分对应什么语言学单元？
3. 分词鲁棒性：能否在 BPE 训练时加入对抗扰动，让 token 序列对错别字更稳定？
4. 分词器与对齐：tokenizer 训练数据的偏差如何传播到下游 RLHF / DPO 中？
5. 字符级智能体：字节级 LLM 在工具调用（需要精确字符串处理）上表现是否优于 BPE？