【DataWhale组队学习】DIY-LLM Task1分词器

原文链接0. 引言为什么要学分词器分词器常被视为LLM的一部分但它其实有独立的训练生命周期。Tokenizer本质上是将原始文本转换为模型可处理的离散符号序列的组件它可以决定模型看到世界的基本粒度是字符、单词、子词还是字节片段而这个粒度的选择会进一步影响序列长度、OOV、词表的规模还有训练效率等。显然模型并不能直接处理文字模型的上下文也并不是无限的那么一个好的合适的Tokenizer便是影响模型效果甚至是否可用十分重要的因素。所以我们需要学习Tokenizer了解其基本训练流程、种类和主要的评价指标。1. 分词器的整体训练流程准备语料初始化基础单元统计并迭代更新输出产物并用于编码与解码​​​​分词器训练是一个有如上四个步骤的完整流程。不同分词算法的差异将主要体现在“初始单元如何选”、“相邻片段如何合并”、“何时停止迭代”这三个问题上。2. 预处理Tokenizer的输入并不是原始文本本身而是经过清洗、脱敏、预分词后得到的可统计序列。后续所有BPE、WordPiece、Unigram的统计学习都是建立在这个输入之上。2.1 数据脱敏高确定性规则先处理如手机号、邮箱中确定性规则再处理如地址关键词低确定性规则最后兜底如姓名模板NER即命名实体识别Named Entity RecognitionNER技术则补充语义级脱敏。脱敏不仅仅是出于隐私保护考虑更是在降低高熵、低复用的信息对统计学习的干扰有利于下面分词过程和模型的稳定性。2.2 多语言语料应该根据模型目标能力设定合适的采样策略避免词表被高频的语言英文/中文主导会挤占低频语言merge的机会加剧token碎片化。2.3 预分词预分词的主要任务是将原始文本切分成可统计、可合并的基础单元例如字符、字节或Unicode片段。常见策略基于空格和标点的切分按Unicode类别划分字节级切分并不是所有的分词器都需要显式进行预分词。例如基于SentencePiece的分词器将标准化和预分词逻辑内置因此无需在外部额外执行预分词步骤。3. 常见分词器的原理与优缺点3.1 字符级原理将文本拆解为最小的字符单位即单个字符。优点词表小英文26个字母中文几千个汉字、无OOV任何词都是字符组成的。缺点序列太长、语义稀疏单个字符一般不具什么语义需要更深的网络来组合出语义。适用场景中文等无空格语言、低资源小语种、短文本对话。3.2 字节级原理在UTF-8编码中英文字母占1个字节汉字占3个字节直接对二进制字节进行操作。优点基础词表固定为256天然覆盖所有字符和emoji无OOV。缺点压缩率恒为1一个字节就对应一个token无压缩能力。适用场景多语言混合、生僻字、特殊字符。3.3 词级原理深度学习早期如RNN时代最主流的方法。基于空格英文或分词算法中文将文本切成有独立语义的“词”。优点语义完整、token数少。缺点词表爆炸语言中词很多OOV严重人名、新造词等、中文分词容易产生歧义。适用场景语法规则规范、词汇固定的领域如新闻、公文、正规书面语。3.4 BPE原理目前LLM最主流的分词算法统计相邻字符对出现的频率迭代地将最频繁出现的字符对合并成一个新的Token。优点在字符级和词级之间取得平衡通过统计学习得到高频子词。缺点训练过程更复杂需要迭代统计和合并。适用场景目前主流。4. BPE核心逻辑BPEByte Pair Encoding是一种基于频率统计的贪心合并算法是在字符级过细和词级过粗之间寻找平衡。其核心思想如3.4所说非常简单。BPE不是一次统计然后一直合并而是一个不断循环的过程定义初始基础单元统计所有相邻pair的频率找到最高频pair合并为新token用新token重写语料重复直到达到目标词表大小或继续合并收益很小为止因此BPE的本质可以理解为一种数据驱动压缩让高频同现的片段逐渐变成更长更稳定的子词单元从而减少token数量同时降低OOV。5. DeepSeek 分词器细节为什么字节级 BPE 要借助 latin1DeepSeek风格tokenizer的一个关键工程点是在字节级BPE中使用latin-1做了中间编解码。原因在于BPE训练实现需要把字节按“字符”来操作因为BPE完全不管你是不是一个完整的字而是字节片段高频同现就合并所以一些中文的token的字节数可能不是3的倍数一个汉字3个字节压根就不是正常的中文词组如果使用UTF-8解码汉字、emoji等多字节字符的字节序列会因不完整而导致信息丢失。而latin-1可以把0–255的每个字节值机械地映射为一个Unicode字符并且这个映射是可逆的这样就可以直接拿这些字符去操作之后再反向还原。所以UTF-8负责把原始文本变成字节流latin1负责把字节流映射成“字符”BPE再在这个壳上做pair合并使用latin1的目的是为了确保任意字节序列都能完整、可逆地参与BPE训练与编码过程。6. 压缩率、OOV 与效率评估6.1 压缩率压缩率可以理解为同样一段文本被编码后是否足够紧凑。常用的口径是原始UTF-8字节长度 / token数量token 越少通常说明压缩率越高表示效率越好。字节级分词器的压缩率恒为1而BPE的优势在于能够通过学习高频片段减少token数量实现数据驱动压缩。6.2 OOVOOV是当LLM模型在处理新的、实际应用的文本时如果遇到一个词汇表中没有的Token那么这个Token就被视为一个OOV。词级分词器最容易出现OOV因为新词、人名等词一旦不在词表中就只能映射成UNK字符级和字节级天然没有OOV因为任何文本都能拆成字符或字节字节级BPE进一步通过“合并token→字节token→unk”的回退链增强了鲁棒性从以下代码中可以体现defencode_chunk(self,chunk:str)-List[str]: 对一个预分词做BPE编码 - 转字节token - 逐步应用merges - 处理OOV未知token拆回字节或标记为unk ......# OOV token拆回字节out[]fortintokens:iftinself.token2id:out.append(t)else:# 拆分成字节token如果字节token也不在词表 → unkout.extend([chifchinself.token2idelseself.unk_tokenforchint])returnout6.3 效率评估指标训练完成后应关注这些指标平均token数最大长度分布碎片化程度跨语言token平衡度这些指标会直接影响模型的上下文利用率、训练显存开销和推理速度。7. 理解与反思Tokenizer本身并不理解语义它更像一个基于统计规律和工程约束来构建离散输入空间的模块。真正的“语言理解”发生在后续Transformer中但显然更合理的token划分会直接影响模型训练的稳定性、上下文窗口的利用率以及处理多语言和特殊字符的能力。我认为最有价值的并不只是BPE的合并逻辑而是它背后的工程问题如何处理多字节字符如何保证编码可逆如何处理OOV如何平衡压缩率与跨语言能力以及如何进行版本管理和回归测试保证训练与推理的一致性。最后提出的思考也很有启发性tokenizer不一定只是静态前处理模块可以与更动态的选择机制结合例如借鉴MoE的思想在不同任务之间自适应选择更合适的表示方式或者通过某些机制使训练好的分词器仍能在下游任务中动态优化还可以利用强化学习等方法让分词器能从少量样本中学习最合适的token划分方式。最后又回到开头Tokenizer并不是一个附属小模块而是连接原始文本与大模型训练之间的重要桥梁。8. 关键代码解析原文“2.3.2 DeepSeek分词器的处理逻辑”下面关于训练BPE的代码很值得一看但是并不需要摸清每一行的细节重要的是这些函数如何组成完整的流水线。pretokenize作用先按正则把文本切成chunk。意义避免整句直接进入BPE减少无意义的跨块合并。build_corpus作用把每个chunk转成UTF-8字节序列再进一步转成可操作token序列。意义构建BPE训练使用的底层语料。pair_freq作用统计整个语料中所有相邻token pair的频率。意义决定当前最值得合并的方向。merge_pair作用把指定pair在token序列中替换成新token。意义完成一轮合并并重写语料。train_bpe作用把“统计→选最高频 pair→合并→重写语料”串成完整训练循环。意义这是BPE的核心训练过程。encode_chunk作用对单个chunk应用已学到的merges规则进行编码。意义除了正常合并外它还体现了工程上的OOV处理逻辑如果合并后的token不在词表中先拆回字节token再不行才退化到unk。所以从代码层面看BPE的核心不只是贪心合并而是一条可训练、可编码、可逆、可解码的闭环。