在线 -
搜索
← 返回题目列表

预训练前为什么要训练 Tokenizer？

中等 第 18 / 25 题 更新于 2026/09/18
大模型预训练TokenizerBPE词表

简化版

Tokenizer 定义模型看到的基本符号、序列长度和词表输出层，因此必须在预训练前冻结。它要覆盖目标语言、代码、数字与特殊标记，在词表大小、压缩率和稀有片段泛化之间权衡。训练后应按语言和领域评估 chars/bytes per token、未知/字节回退、数字代码切分及往返一致性，不能只看平均压缩率。

详细版

常见 BPE/Unigram 从代表性语料学习子词，频繁片段合并成一个 Token，稀有词拆成更小单元。词表大可缩短序列，却增大 embedding/LM head 参数与稀有 Token 学习难度；词表小则序列更长、注意力和推理成本上升。多语言采样若按原始量，会让高资源语言占满词表。

训练流程包括规范化策略、预分词、样本混合、词表与特殊 Token 设计，再做 encode/decode 可逆测试。代码要保留空白和符号，数字切分影响算术，emoji/低资源文字需 byte fallback。模型训练后随意换 Tokenizer 会让 embedding ID 语义错位；新增 Token 也需初始化和继续训练。

代表性语料 -> 规范化/预分词 -> 子词学习 -> 加特殊Token -> 冻结词表
                                             -> 分桶评测 -> 模型预训练

完整版教学

一、Tokenizer 决定模型的输入坐标系

语言模型不直接接收字符串，而接收整数 Token ID；每个 ID 在 embedding 表中对应一个向量。Tokenizer 一旦改变，同一个 ID 可能代表不同片段，已训练权重就失去含义。因此它不是可随时替换的前端工具，而是模型参数定义的一部分。

输出层通常也按词表预测下一个 Token，词表大小直接决定 logits 维度。特殊 Token 还定义对话边界、padding、图像占位和工具标记，设计错误会一直传递到训练和推理协议。

二、子词为什么折中字符与整词

整词词表无法覆盖所有新词、姓名和变形，规模巨大；字符词表通用，却让序列很长。子词把高频片段合并、低频词拆分，既限制词表又保留开放词汇。BPE 迭代合并最高频相邻单元，Unigram 则从候选词表中选择概率模型较优的集合。

“tokenization” -> [“token”, “ization”]   高频片段较短
罕见新词        -> [更小子词/字节]        仍可表示

分词边界没有唯一语义真值，目标是统计与工程上的有效表示，而不是复原语言学词法。

三、词表大小有什么代价

若隐藏维度 4096，词表从 32K 增到 128K，单个 FP16 embedding 表由约 262MB 增到约 1.05GB；若输入输出不共享还会翻倍。大词表减少序列长度和注意力成本，但许多稀有 Token 训练次数不足。

词表方案序列长度参数/softmax稀有片段
较小词表长小拆得细、泛化好
较大词表短大稀有 Token 学不充分
Byte fallback最坏更长保证覆盖无 UNK，但效率可能低

应扫描多个词表大小，在目标语料上比较压缩率、参数与吞吐，而非套用固定 32K。

记忆钩子：大词表用更多参数换更短序列，小词表用更长序列换更强组合能力；两边都在付成本。

四、多语言采样决定谁被切得更碎

若训练语料 90% 是英语，直接训练的合并规则会优先服务英语，中文、阿拉伯语或低资源语言可能每个字符甚至每个字节一个 Token。同样一句话因此占用更多上下文，推理更贵，训练中每个语言获得的有效字符也更少。

可以按语言温度采样，提升低资源语料在 Tokenizer 训练集中的占比，并为关键脚本保留字符。评测要逐语言报告 bytes/token 或 chars/token 的分布。公平并非让每种语言压缩率完全相同，而是避免不可接受的系统性劣势。

五、规范化与预分词的陷阱

Unicode NFC/NFKC、大小写、空白和全半角处理会影响可逆性。NFKC 可能把视觉不同字符合并，适合搜索却未必适合代码和精确文本生成。代码中的缩进与换行有语义，不能沿用自然语言的空白压缩。

数字可按单字符、固定三位或常见片段切分，不同设计影响算术与长度。预分词若强制按空格切，会不利于不以空格分词的语言。所有规则要做 decode(encode(x)) == x 测试，并明确允许的规范化例外。

六、特殊 Token 如何规划

至少要考虑 BOS/EOS、PAD、UNK 或 byte fallback、对话角色、文档边界和多模态占位。特殊 Token 应来自保留 ID 区间，不被普通文本编码意外产生；聊天模板在训练与推理必须一致。过多预留会浪费词表，完全不预留又让以后扩展困难。

如果 pad 与 eos 共用，训练 loss mask 和生成停止逻辑必须格外谨慎，否则模型可能把 padding 学成结束。新增工具或图像 Token 后，需要扩展 embedding/LM head 并训练这些行，随机初始化后直接推理没有语义。

七、怎样评估一个 Tokenizer

除平均压缩率，还要看各语言、代码、数学、URL、数字、emoji 和长尾实体的 Token 数；统计最大碎片长度、byte fallback 比例、特殊 Token 冲突和往返一致性。最终用目标模型或代理模型比较 validation loss 与 Token/s，因为最短分词不一定最易学习。

例如 A 在英语 4.0 chars/token、中文 1.0 chars/token，B 分别 3.8 和 1.6。A 平均可能更好，但中文请求更昂贵；选择取决于目标用户分布。还应在 8K 上下文中计算真实文档能容纳的字符数，而非只报词表大小。

八、常见误区与追问

  • 误区：词表越大，Tokenizer 越好。 参数和稀有 Token 学习成本会增加，收益有拐点。
  • 误区：平均压缩率足以评价。 它会掩盖低资源语言、代码和数字的严重碎片化。
  • 误区：模型训练后可以无成本更换 Tokenizer。 Token ID 与 embedding 已绑定，直接替换会破坏模型。
  • 追问：为什么需要 byte fallback？ 保证任意 Unicode/字节串可表示，避免未知 Token 丢信息。
  • 追问：Tokenizer 数据是否也要去重？ 要，重复模板会过度影响合并频率和词表资源。
  • 追问：如何扩展词表？ 保留原 ID，新增 embedding 行并继续训练，同时验证旧能力和模板兼容。

九、加强记忆

Tokenizer 可记成“表、长、覆、规、冻”：词表大小在参数与序列长度间权衡；训练语料决定语言覆盖；规范化、代码空白和特殊 Token 定义协议；通过分桶压缩率与可逆性验证后，在预训练前冻结。它决定模型如何切分世界，设计偏差会以成本和能力差异贯穿整个生命周期。