1. 从“字”到“词元”为什么大模型需要词元化如果你尝试过直接向一个未经词元化处理的原始大语言模型输入“你好世界”它大概率会一脸茫然或者输出一堆乱码。这背后的核心原因在于模型并不理解我们人类眼中的“字”或“词”。它只认识数字。因此将文本转化为模型能理解的数字序列是整个自然语言处理流水线的第一步也是最关键的一步。这个过程就是词元化。词元化简单来说就是把一段连续的文本切分成一个个更小的、可管理的单元这些单元被称为“词元”。你可以把它想象成我们学英语时把句子拆分成一个个单词。但大模型面临的挑战要复杂得多它需要处理多种语言包括中文这种没有天然空格分隔的语言、海量的词汇、以及层出不穷的新词和网络用语。一个糟糕的词元化方案会直接导致模型效率低下、理解偏差甚至无法处理某些输入。目前主流的预训练大模型如GPT系列、BERT、T5等几乎都采用了三种词元化算法之一BPE、WordPiece或Unigram。它们的目标一致——构建一个高效的词表将文本转化为词元序列——但背后的哲学和实现路径却截然不同。理解它们的差异不仅有助于你读懂模型的技术文档更能让你在微调模型、处理特定领域文本如代码、医学文献时做出更明智的选择。接下来我们就深入这三种算法的核心看看它们是如何工作的以及在实际应用中该如何取舍。2. BPE从字节到子词的迭代合并哲学BPE全称Byte Pair Encoding最初是一种数据压缩算法。它的核心思想非常直观迭代地合并最频繁共现的字节对。在NLP的语境下“字节”被替换成了“字符”或“子词单元”。2.1 BPE算法的运作流程BPE的训练是一个离线过程目的是从一个大型语料库中学习得到一个固定的词表。其步骤可以概括为初始化将语料库中的所有单词拆分为最基本的字符包括字母、标点对于中文可以是单字并在每个单词末尾添加一个特殊的结束符如/w用以区分单词边界。此时词表就是所有不重复的字符集合。统计与合并统计语料中所有相邻符号对的出现频率。找到出现频率最高的那个符号对比如e和s经常挨在一起。合并将这个最高频的符号对合并成一个新的符号并加入到词表中。例如将(e, s)合并为es。迭代重复步骤2和3直到合并操作进行了预定的次数例如合并10000次或者词表大小达到了预设的目标例如30000个词元。这个过程就像一个贪心算法每次都选择当前最“划算”的合并。最终词表中会包含单个字符、常见的子词如ing,ed,ation以及一些完整的高频单词。2.2 BPE的编码与解码训练好词表后如何对一个新句子进行编码呢编码首先将句子中的每个单词拆分为字符序列并加上结束符。然后我们尝试应用训练时学到的所有合并规则从最长的可能合并开始逐步向短的合并尝试直到无法再合并为止。最终得到的子词序列就是词元序列。解码解码则简单得多。将所有词元拼接起来然后将特殊的结束符/w替换为空格即可恢复原始文本近似。这是BPE的一个巨大优势解码是无损且确定的。举个例子假设词表里有low,lower,newest,widest以及字符l,o,w,e,r,n,w,s,t。对于单词lowest编码时我们可能先尝试合并low和est但est可能不在词表中。于是退而求其次拆分为[low, e, s, t, /w]或[low, est, /w]如果est是学到的子词。解码时直接拼接lowest得到lowest。2.3 BPE的实战心得与典型应用BPE是OpenAI的GPT系列从GPT-2到GPT-4以及开源社区众多模型如LLaMA系列、Bloom的默认选择。它的优势在于平衡了词表大小与序列长度相比单词级词表它大大压缩了词表规模相比字符级它又显著缩短了输入序列的长度提高了计算效率。能有效处理未知词任何新词都可以被分解为已知的子词或字符避免了“未登录词”问题。解码简单可靠如前所述无损解码是一大优点。然而在实际使用中我踩过几个坑注意合并顺序的敏感性。BPE的合并结果严重依赖于初始语料和合并次数。用新闻语料训练的BPE词表去处理代码或医学文本效果会大打折扣。因此如果你要在特定领域微调或应用模型强烈建议基于你的领域语料重新训练或扩展BPE词表。例如处理代码时“if(”、“){”这样的组合可能比自然语言中的常见子词更重要。注意中文BPE的特殊性。对于中文通常以字为初始单元。但这就导致BPE学到的“子词”往往是常见的双字词如“我们”、“可以”。这有时是有效的但有时也会产生不合语法的组合。一种改进方案是先用分词工具粗分再在分词结果上应用BPE但这又引入了分词误差。目前许多中文大模型直接采用字级别的BPE并依靠模型的强大能力来学习词汇信息。3. WordPiece基于概率的“最有价值”合并策略WordPiece是Google为BERT模型设计的词元化算法。它和BPE看起来很像都是通过合并子单元来构建词表但决定“合并谁”的标准完全不同。3.1 WordPiece的核心最大化语言模型概率WordPiece不再简单地统计频率而是有一个更“聪明”的目标使得词元化后的语料在语言模型下的概率最大。具体来说它的训练过程如下初始化和BPE一样以字符为初始词表。尝试合并考虑所有可能的符号对合并。评分与选择对于每一对可能的合并如(a, b)-ab计算如果将语料中所有该符号对替换为新符号ab后整个语料库的似然值增加了多少。这个似然值通常由一个简单的单语素语言模型来估计。执行合并选择那个能最大程度增加语料库似然值的符号对进行合并。迭代重复步骤2-4直到词表达到目标大小。这个标准可以理解为合并那些在一起出现时其组合的“惊喜度”低于其各部分独立出现时的“惊喜度”的符号对。换句话说合并那些“在一起比分开更自然”的片段。3.2 WordPiece与BPE的细微差别由于选择标准的不同WordPiece产生的词表与BPE常有差异。WordPiece更倾向于合并那些能形成有语言学意义或统计上非常紧密的单元。在实践中WordPiece词表可能包含更多像##ing,##ed这样的后缀##表示该词元是一个单词的中间或尾部部分不能独立成词而完整的单词相对较少。编码过程WordPiece的编码采用最长匹配优先的贪心算法。对于一个单词它从第一个字符开始寻找词表中最长的匹配子词然后对剩余部分重复此过程。这与BPE的全局合并尝试略有不同。解码过程和BPE一样简单直接拼接词元并处理##前缀即可在BERT中##开头的词元需要直接拼接到前一个词元后面。3.3 WordPiece的典型场景与注意事项WordPiece是BERT家族、ALBERT、ELECTRA等模型的标配。它的设计很好地匹配了BERT的掩码语言建模任务。我的使用经验是提示[UNK]令牌的处理。BERT的WordPiece实现中如果一个单词不能被完全拆分为词表中的子词整个单词会被替换为一个特殊的[UNK]未知令牌。这与BPE总能分解到字符不同。因此确保你的词表足够覆盖目标领域的词汇至关重要否则信息损失会很严重。在处理专业文本时这常常是个问题。注意大小写与子词标记。BERT的原始WordPiece词表对大小写敏感并且大量使用##来标记子词。这在处理英文时问题不大但在处理其他语言或大小写不规范的文本如社交媒体文本时可能需要额外的预处理或使用不区分大小写的变体。下表对比了BPE与WordPiece在几个关键维度的差异特性BPE (Byte Pair Encoding)WordPiece合并标准符号对的共现频率最高合并后语料语言模型概率提升最大哲学数据压缩导向贪心合并最常见组合语言学/概率导向合并最“可能”的组合典型应用GPT系列, LLaMA, Bloom, T5BERT, ALBERT, ELECTRA未知词处理总能分解到字符级别无[UNK]可能产生[UNK]令牌解码直接拼接无损直接拼接处理##基本无损训练复杂度相对较低只需统计频率相对较高需要计算概率增益4. Unigram先定词表再择优分配的逆向思维Unigram语言模型词元化算法代表了一种截然不同的思路。与BPE和WordPiece的“自底向上”合并不同Unigram是“自顶向下”的。4.1 Unigram算法的基本原理Unigram的出发点是一个假设每个词元的选择是独立的即一元语法。它的训练目标很直接给定一个目标词表大小 V找到能使得整个训练语料概率最大化的那个词表以及每个词元对应的概率。显然遍历所有可能的词表是不现实的。因此Unigram采用了一种迭代的近似算法初始化一个大词表通常先用BPE或其他方法生成一个远大于目标V的词表例如包含所有字符和常见子词共10万-20万个。EM算法迭代E步期望固定当前词表用维特比算法为语料中的每个句子找到概率最大的词元分割方式。M步最大化固定当前的分割方式根据每个词元在所有分割中出现的频率重新计算它的概率。然后丢弃那些概率最低的词元缩小词表。迭代重复E步和M步直到词表大小缩减到目标V。这个过程可以理解为我们一开始给模型很多可能的“零件”词元然后通过实际“组装”句子E步观察哪些零件最常用、最重要。接着我们淘汰掉那些最没用的零件M步。反复几次剩下的就是精华。4.2 Unigram的关键特性概率与多重分割Unigram有两个突出特点每个词元带有概率词表不仅包含词元列表还包含每个词元的出现概率。这使得在编码时可以选择概率最高的分割也可以保留多个可能的分割以供下游任务使用这在某些序列标注任务中可能有帮助。编码的灵活性编码过程就是寻找使句子整体概率最大的词元序列这通过维特比算法可以高效解决。4.3 Unigram的应用场景与实战思考Unigram是SentencePiece工具默认支持的算法之一另一种是BPE并被用于训练像T5、mT5、ALM等模型。它的优势在于更优的词表通过全局优化理论上能获得比贪心算法BPE/WordPiece更高效、更均衡的词表。概率信息为词元赋予概率为一些高级应用提供了可能性。灵活处理SentencePiece基于Unigram能够无缝处理多种语言且不需要预先分词直接将原始文本包括空格作为输入将空格也视为一个普通字符进行处理这对于处理多语言混合文本或代码非常友好。在实际项目中我的体会是提示SentencePiece是你的好朋友。绝大多数Unigram词表都是通过SentencePiece工具训练的。它接口简单支持超大语料并能输出模型文件和词表。如果你需要从头训练一个多语言或领域特定模型我通常推荐从SentencePiece的Unigram开始尝试。注意计算开销。Unigram的训练过程尤其是E步的维特比分割比BPE要慢得多对内存和计算资源的要求更高。对于超大规模语料需要做好分布式处理的准备。注意概率的利用。在大多数下游任务中我们只使用词元ID而忽略了Unigram提供的概率信息。这是一个潜在的浪费。在一些研究性工作中可以考虑利用这些概率来加权词元表示或者用于数据增强。5. 如何为你的项目选择词元化方案了解了三种主流算法后面对一个具体项目该如何选择呢这没有绝对答案但可以从以下几个维度考量5.1 根据任务类型与模型架构选择自回归模型如GPT通常选用BPE。其无损解码特性与生成任务天然契合生成文本时流畅自然。OpenAI的实践已经证明了其有效性。双向编码器模型如BERT传统上使用WordPiece。其子词标记##在掩码预测任务中工作良好。但值得注意的是一些新的BERT变体也开始使用BPE或Unigram。多语言或领域无关模型SentencePiece with Unigram是强有力的竞争者。其不依赖空格、直接处理原始字节的特性使其能优雅处理混合语言、代码、公式等非标准文本。资源受限场景如果训练语料不大或计算资源有限BPE是更简单、更快速的选择。WordPiece和Unigram的训练相对更重。5.2 词表大小与覆盖率的关键权衡词表大小是一个超参数需要仔细调整。词表过大例如10万以上优点是序列长度短计算效率高对常见词汇编码紧凑。缺点是模型嵌入层参数巨大增加内存消耗且可能使模型对罕见子词过拟合。词表过小例如几千优点是模型小训练快。缺点是序列长度会变得非常长严重影响训练和推理速度并且由于拆分过细模型需要学习更复杂的组合规律。一个实用的起点是对于英文或多语言模型3万-5万的词表大小是一个常见的甜点区。对于中文由于字符本身数量有限几千常用字但组合灵活词表大小可以在2万-6万之间探索。最好的方法是在验证集上评估不同词表大小对下游任务如分类、生成性能的影响。5.3 领域适应性当通用词表遇上专业文本这是微调或部署模型时最常遇到的问题。你拿到了一个在通用语料如维基百科、网页上预训练的模型例如LLaMA现在要用它处理法律合同或生物医学论文。方案一直接使用接受性能损失。对于专业术语通用词表会将其拆分成无意义的子词导致模型难以理解。例如“脱氧核糖核酸”可能被拆成“脱”、“氧”、“核”、“糖”、“核”、“酸”完全丢失了其作为专有名词的整体语义。方案二领域自适应词元化。这是更推荐的做法。使用你的领域语料在原有词表基础上用BPE或SentencePiece进行增量训练。工具如Hugging Face的tokenizers库允许你加载现有词表然后在新的语料上继续执行合并BPE或EM迭代Unigram从而将领域高频术语作为整体加入到词表中。这能显著提升模型在特定领域的理解和生成能力。方案三完全重新训练。如果你的领域与通用领域差异极大且数据充足从头训练一个词表也是可行的但成本最高。5.4 一个实战案例为代码助手模型构建词表假设我们要构建一个代码补全模型。代码文本与自然语言差异极大有大量括号、缩进、操作符-,::,以及标识符函数名、变量名。选择算法SentencePiece Unigram是上佳选择。因为它以字节为单位能自然学习到“if(”、“){”、“-”这样的代码特定序列而不会因为空格被错误分割。准备语料收集Python、JavaScript、Java等多种语言的源代码构成训练语料。训练参数spm_train --inputcode_corpus.txt --model_prefixcode_spm --vocab_size32000 --character_coverage1.0 --model_typeunigram--character_coverage1.0确保覆盖所有可能的字符对代码很重要。效果对比用这个“代码词表”训练的模型相比使用通用BERT词表的模型在标识符预测、API序列生成等任务上会有显著提升因为“HashMap”、“getElementById”这样的标识符很可能被保留为完整的词元。词元化虽是大模型流水线中一个相对“底层”的组件但其设计直接影响着模型的数据效率、计算性能和最终能力上限。理解BPE、WordPiece和Unigram背后的思想能让你在模型选择、微调优化乃至自主训练时都更加得心应手。记住没有最好的算法只有最适合你数据和任务的算法。下次当你看到模型输出一个奇怪的词元序列时不妨想想它的词表是怎么来的或许就能找到优化的突破口。