大模型 Tokenizer从字符到 Byte再到大词表Tokenizer 是大语言模型处理文本的第一步。简单来说它负责把一句话转换成模型能够理解的 Token。例如我喜欢机器学习 ↓ [我] [喜欢] [机器] [学习] ↓ [Token ID]Tokenizer 的核心问题其实很简单怎么让文本既能被完整表示又尽量使用更少的 Token一、为什么不能直接按词切最简单的方法是按照完整单词切分I love machine learning ↓ [I] [love] [machine] [learning]这种方法很直观但有一个明显的问题新词怎么办如果词表里没有某个词就会出现 OOVOut-of-Vocabulary登录外词。所以后来出现了Character-level Tokenizer把词拆成一个个字符machine ↓ [m] [a] [c] [h] [i] [n] [e]这样基本不会遇到新词问题但 Token 数量会明显增加导致模型处理序列变长。于是就有了折中方案Subword Tokenizer。它既不把整个词作为一个 Token也不把所有东西拆成单个字符而是学习常见的词片段。二、BPE 是怎么做的BPEByte Pair Encoding是目前非常经典的一种 Subword 方法。它的基本思路就是常见的组合就把它们合并起来。例如a b → ab ab c → abc训练 Tokenizer 时它会根据训练数据学习这些合并规则。到了真正使用的时候就按照已经学好的规则进行切分。除了 BPE还有 WordPiece 和 Unigram 等方法它们的训练方式不同但目的类似找到一套合适的 Token让文本表示更加高效。三、为什么又出现 Byte-levelSubword 已经解决了很多 OOV 问题但还有一个问题Unicode 字符非常多。如果把大量 Unicode 字符直接作为基础单元词表会变得很复杂。UTF-8 提供了一个更简单的办法。一个 Byte 只有 256 种可能0 ∼ 255 0 \sim 2550∼255因此可以先把文本转换成 UTF-8 Byte再在 Byte 上进行 BPE。例如中 ↓ UTF-8 ↓ E4 B8 AD所以Character ≠ Byte ≠ Token \boxed{\text{Character} \neq \text{Byte} \neq \text{Token}}CharacterByteToken“中”是一个字符E4 B8 AD是它的 UTF-8 编码而 Token 是 Tokenizer 最终生成的离散单位。四、什么是 BBPEBBPE 就是 Byte-Level BPE。它的过程可以简单理解为文本 ↓ UTF-8 Byte ↓ BPE 合并 ↓ Token ↓ Token ID它最大的优势是Byte作为一种通用的基础表示让各种 UTF-8 文本都有基本的表示路径解决基础表示问题。BPE把常见的 Byte 序列组合成更大的 Token从而减少 Token 数量提高文本压缩效率。五、为什么现在词表越来越大当 Tokenizer 能够表示各种文本之后另一个问题就出现了能不能用更少的 Token 表示相同的内容例如如果一个常见词组总是一起出现那么把它作为一个 Token显然比拆成很多 Token 更高效。因此现在一些大模型的词表从早期的几十 K逐渐扩大到 100K 甚至更大。大词表的好处是词表更大 ↓ 可以容纳更多常见模式 ↓ Token 数量可能减少 ↓ 文本表示更加紧凑特别是在中文、多语言、代码和数字等场景中大词表可能带来更好的 Token 压缩效果。六、大词表是不是越大越好当然不是。词表越大也意味着更高的系统成本。例如 Embedding 参数量大致为V × d model V \times d_{\text{model}}V×dmodel其中V VV是词表大小。所以词表变大 ↓ 可以容纳更多高频文本模式 ↓ 在合适的训练条件下Token 数量可能减少 ↓ 但 Embedding / LM Head 等成本增加因此Tokenizer 实际上一直在做一个平衡覆盖能力 Token 压缩效率 ↔ 词表成本 \boxed{\text{覆盖能力} \text{Token 压缩效率} \leftrightarrow \text{词表成本}}覆盖能力Token压缩效率↔词表成本七、总结从 Word-level 到 Character-level再到 Subword、Byte-level BPETokenizer 的发展可以简单理解为按词 ↓ (解决语义粒度问题) 按字符 ↓ (减少 OOV) Subword ↓ (在词和字符之间寻找平衡) Byte-level ↓ (提供通用的基础表示) 大词表 ↓ (进一步减少 Token 数量)最终Tokenizer 要解决的并不是“怎么分词”这么简单而是一个很实际的工程问题如何用尽可能少的 Token稳定、高效地表示尽可能多的文本同时控制词表带来的成本。 大模型 Tokenizer：从字符到 Byte，再到大词表
大模型 Tokenizer从字符到 Byte再到大词表Tokenizer 是大语言模型处理文本的第一步。简单来说它负责把一句话转换成模型能够理解的 Token。例如我喜欢机器学习 ↓ [我] [喜欢] [机器] [学习] ↓ [Token ID]Tokenizer 的核心问题其实很简单怎么让文本既能被完整表示又尽量使用更少的 Token一、为什么不能直接按词切最简单的方法是按照完整单词切分I love machine learning ↓ [I] [love] [machine] [learning]这种方法很直观但有一个明显的问题新词怎么办如果词表里没有某个词就会出现 OOVOut-of-Vocabulary登录外词。所以后来出现了Character-level Tokenizer把词拆成一个个字符machine ↓ [m] [a] [c] [h] [i] [n] [e]这样基本不会遇到新词问题但 Token 数量会明显增加导致模型处理序列变长。于是就有了折中方案Subword Tokenizer。它既不把整个词作为一个 Token也不把所有东西拆成单个字符而是学习常见的词片段。二、BPE 是怎么做的BPEByte Pair Encoding是目前非常经典的一种 Subword 方法。它的基本思路就是常见的组合就把它们合并起来。例如a b → ab ab c → abc训练 Tokenizer 时它会根据训练数据学习这些合并规则。到了真正使用的时候就按照已经学好的规则进行切分。除了 BPE还有 WordPiece 和 Unigram 等方法它们的训练方式不同但目的类似找到一套合适的 Token让文本表示更加高效。三、为什么又出现 Byte-levelSubword 已经解决了很多 OOV 问题但还有一个问题Unicode 字符非常多。如果把大量 Unicode 字符直接作为基础单元词表会变得很复杂。UTF-8 提供了一个更简单的办法。一个 Byte 只有 256 种可能0 ∼ 255 0 \sim 2550∼255因此可以先把文本转换成 UTF-8 Byte再在 Byte 上进行 BPE。例如中 ↓ UTF-8 ↓ E4 B8 AD所以Character ≠ Byte ≠ Token \boxed{\text{Character} \neq \text{Byte} \neq \text{Token}}CharacterByteToken“中”是一个字符E4 B8 AD是它的 UTF-8 编码而 Token 是 Tokenizer 最终生成的离散单位。四、什么是 BBPEBBPE 就是 Byte-Level BPE。它的过程可以简单理解为文本 ↓ UTF-8 Byte ↓ BPE 合并 ↓ Token ↓ Token ID它最大的优势是Byte作为一种通用的基础表示让各种 UTF-8 文本都有基本的表示路径解决基础表示问题。BPE把常见的 Byte 序列组合成更大的 Token从而减少 Token 数量提高文本压缩效率。五、为什么现在词表越来越大当 Tokenizer 能够表示各种文本之后另一个问题就出现了能不能用更少的 Token 表示相同的内容例如如果一个常见词组总是一起出现那么把它作为一个 Token显然比拆成很多 Token 更高效。因此现在一些大模型的词表从早期的几十 K逐渐扩大到 100K 甚至更大。大词表的好处是词表更大 ↓ 可以容纳更多常见模式 ↓ Token 数量可能减少 ↓ 文本表示更加紧凑特别是在中文、多语言、代码和数字等场景中大词表可能带来更好的 Token 压缩效果。六、大词表是不是越大越好当然不是。词表越大也意味着更高的系统成本。例如 Embedding 参数量大致为V × d model V \times d_{\text{model}}V×dmodel其中V VV是词表大小。所以词表变大 ↓ 可以容纳更多高频文本模式 ↓ 在合适的训练条件下Token 数量可能减少 ↓ 但 Embedding / LM Head 等成本增加因此Tokenizer 实际上一直在做一个平衡覆盖能力 Token 压缩效率 ↔ 词表成本 \boxed{\text{覆盖能力} \text{Token 压缩效率} \leftrightarrow \text{词表成本}}覆盖能力Token压缩效率↔词表成本七、总结从 Word-level 到 Character-level再到 Subword、Byte-level BPETokenizer 的发展可以简单理解为按词 ↓ (解决语义粒度问题) 按字符 ↓ (减少 OOV) Subword ↓ (在词和字符之间寻找平衡) Byte-level ↓ (提供通用的基础表示) 大词表 ↓ (进一步减少 Token 数量)最终Tokenizer 要解决的并不是“怎么分词”这么简单而是一个很实际的工程问题如何用尽可能少的 Token稳定、高效地表示尽可能多的文本同时控制词表带来的成本。