‍♂️ 个人主页小李同学_LSH的主页✍ 作者简介LLM学习者 希望大家多多支持我们一起进步如果文章对你有帮助的话欢迎评论 点赞 收藏 加关注目录一、词表设计为什么这么重要1. 你怎么“看世界”2. 你的序列有多长二、为什么中文词表设计比英文更难三、中文大模型常见的 4 种词表设计思路1. 字级别Character-level优点缺点2. 词级别Word-level优点缺点3. 子词级别Subword-level优点缺点4. 字节级别Byte-level优点缺点四、为什么现在主流中文大模型大多走“子词级别”路线五、词表大小到底怎么选1. 词表太小的问题2. 词表太大的问题六、中文大模型词表设计时必须考虑的 6 个现实问题1. 中文常用字与高频词的覆盖2. 中英混输能力3. 数字、日期、金额、符号4. 代码与路径5. 领域术语6. 特殊 token 设计七、chatGML4的词表在很多人眼里大模型的核心总是注意力机制、训练数据、参数规模、对齐方法。但如果你真的做过中文大模型训练很快就会发现一个经常被低估、却极其关键的环节词表设计。它看起来像是训练前的一个“小步骤”但实际上会直接影响序列长度训练效率显存占用中文表达能力稀有词覆盖英文/代码/数字混合能力下游任务表现换句话说词表不是模型前面的“附件”而是模型理解世界的最底层入口。尤其在中文场景里词表设计比英文更难。因为中文天然没有空格分词既可以按字切也可以按词切还会遇到多义词新词专有名词中英混输数字与符号混合代码片段领域术语所以中文大模型的词表设计从来不是“随便训练一个 tokenizer”这么简单。这篇文章我就把这个问题彻底拆开讲清楚为什么词表设计这么重要中文词表设计为什么比英文更难常见分词方案分别有什么优缺点词表大小到底怎么权衡做中文大模型时词表到底该怎么设计一、词表设计为什么这么重要先说一个最核心的事实大模型不是直接理解“文本”而是先把文本切成 token再处理 token。也就是说模型真正看到的不是一句自然语言而是一串离散符号序列。模型后续学习的其实是 token 序列的条件概率所以词表设计会直接决定两件事1. 你怎么“看世界”比如“人工智能”这个词按字切人 / 工 / 智 / 能按词切人工智能模型学到的最小语义单元完全不同。2. 你的序列有多长如果同一句话被切成更多 token那么上下文更长训练更慢推理更贵注意力成本更高因为 Transformer 的注意力复杂度和序列长度 n 近似平方相关所以词表设计不是“美观问题”而是语义粒度 训练效率 表达能力的联合设计问题。二、为什么中文词表设计比英文更难英文天然有一个优势空格本身就提供了初级词边界。比如I love large language models至少单词边界是天然存在的。但中文不是这样我喜欢大语言模型这里没有空格你可以按不同粒度切我 / 喜欢 / 大语言模型我 / 喜 / 欢 / 大 / 语 / 言 / 模 / 型我 / 喜欢 / 大 / 语言 / 模型我 / 喜欢 / 大语言 / 模型这些切法都“不是完全错”但对模型来说差异极大。难点说明影响无天然空格分词中文没有单词边界切分粒度难统一新词频繁出现网络词、行业词更新快固定词表容易失效多字词语义强如“人工智能”“知识图谱”按字切会损失整体语义单字也有意义如“税”“法”“药”按词切太重会丢失灵活性中英混输普遍如“RAG系统”“Python环境”词表需兼容多语言数字符号复杂日期、金额、公式、代码粒度选择困难所以中文词表设计最难的不是“怎么切”而是怎么在“细粒度灵活性”和“粗粒度语义完整性”之间找到平衡。三、中文大模型常见的 4 种词表设计思路1. 字级别Character-level最简单的方式就是按单字切。例如大语言模型切成大 / 语 / 言 / 模 / 型优点不依赖分词器不怕未登录词中文覆盖很稳词表规模可以很小缺点序列变长多字词整体语义被拆散模型需要自己从上下文中重新组合语义如果一句文本长度为 L按字级切分时token 数大致可以写成2. 词级别Word-level这类方案先做中文分词再按词入表。例如大语言模型 / 词表设计 / 很重要优点语义单元完整序列更短对常见词表达效率高缺点依赖中文分词器新词、错分词问题严重词表会迅速膨胀OOV未登录词难处理如果词表中没有一个新术语比如“多模态蒸馏增强检索”那词级方案会很难受。3. 子词级别Subword-level这是目前主流做法。核心思路是不完全按字也不完全按词而是通过统计方法自动学习高频片段。最常见的是BPEWordPieceUnigram例如人工智能大模型可能切成人工 / 智能 / 大 / 模型或者人工智能 / 大模型这类方案的本质是让高频语义片段尽量保留让低频词还能退化成更小单元。优点比字级更短比词级更灵活能较好处理未登录词是当前大模型最常见的平衡方案缺点分词结果不总是“人类直觉最优”训练语料分布会强烈影响词表质量中文、英文、数字、符号混合时需要额外设计4. 字节级别Byte-level这类方法不直接关心“字”或“词”而把文本进一步映射到更底层的字节表示。优点真正没有 OOV任意字符都能编码对乱码、特殊符号、混合文本更鲁棒缺点序列通常更长可读性差对中文未必是最优起点它更像一个“兜底型设计”而不是最适合中文大模型主干建模的优先方案。四、为什么现在主流中文大模型大多走“子词级别”路线因为它最像一个折中最优点。你可以把词表设计看成同时优化两个目标方案词表规模序列长度OOV 风险中文语义完整性工程复杂度字级别小长很低中低词级别很大短高高高子词级别中等中等低高中字节级别很小/固定很长极低中中五、词表大小到底怎么选这是中文大模型里最容易被问到的问题之一词表越大越好吗答案是不是。词表大小本质上是一种取舍。1. 词表太小的问题如果词表太小很多词都得拆得很碎。例如“知识图谱” 被拆成知识 / 图 / 谱“大语言模型” 被拆成大 / 语言 / 模 / 型这样会导致序列变长注意力成本增加语义组合压力转移给模型本身2. 词表太大的问题如果词表太大又会带来另一个问题embedding 层参数暴涨输出层参数暴涨稀有 token 学不充分长尾 token 浪费参数六、中文大模型词表设计时必须考虑的 6 个现实问题1. 中文常用字与高频词的覆盖这决定了基础中文能力的下限。如果高频词覆盖不好模型会序列变长高频概念被切碎常见语义表达效率低2. 中英混输能力这是今天中文场景里最容易被忽略、但极其重要的问题。真实输入经常是这样的Python 环境怎么配置RAG 系统怎么做用 FastAPI 接 OpenAI APICUDA 驱动版本不兼容如果词表只对纯中文友好而对英文缩写、技术名词支持差模型体验会明显下降。3. 数字、日期、金额、符号例如2025年3.14¥299910^664GB这些在真实应用里很常见。如果切分设计不合理数字表达会被切得很乱。4. 代码与路径很多中文大模型现在都会被拿来做编程辅助。那词表必须考虑import torch python -m venv .venv C:\Users\Admin /home/user/project如果这类模式切得太碎代码生成和理解能力都会受影响。5. 领域术语如果你训练的是通用中文大模型还要考虑医疗术语法律术语金融术语科研术语这些术语往往多字、长尾、高语义密度。如果词表中完全没有支持就会严重依赖模型后期去“组合理解”。6. 特殊 token 设计例如bos eos pad unk user assistant system这些 token 决定了模型在训练和对话阶段的格式理解能力。设计维度要解决的问题如果处理不好会怎样中文高频词覆盖保证常见语义表达效率中文被切太碎中英混输支持技术文本、缩写、命令英文片段异常碎裂数字符号支持日期、金额、公式数值表达混乱代码支持适应编程场景代码理解与生成变差领域术语支持专业场景专有名词表达不稳特殊 token适配训练与对话模板模型格式能力变差七、chatGML4的词表ChatGLM4公开的glm-4-9b-chat的“中文词表”不是那种纯中文词表列表也不是vocab.txt风格它更像一个中英混合、支持代码/数字/符号的 BPE 式 tokenizer 词表文件名叫tokenizer.model。从官方tokenization_chatglm.py来看这个 tokenizer 用的是tiktoken.Encoding会从tokenizer.model里逐行读取token rank把 token 做base64解码后作为 mergeable ranks 载入所以它本质上更接近BPE / tiktoken 风格词表不是 SentencePiece protobuf 那一路。它不是一个“中文词典式”的词表而是一个面向多语言和混合文本场景的 subword/BPE 风格词表。中文高频片段、英文单词片段、数字、标点、代码符号以及对话 special tokens 都在同一套词表体系里。普通文本 token - 中文高频字/词片段 - 英文单词或子词片段 - 数字、符号、代码片段 特殊 token - |system| - |user| - |assistant| - |observation| - [MASK] - [gMASK] - |begin_of_image| - |end_of_image| ...从tokenization_chatglm.py里还能看出它的切分模式会显式照顾英文缩写和词形变化如s,reUnicode 字母类数字片段\p{N}{1,3}非空白符号串空白与换行这说明它在设计上就不是“纯中文按字切”而是为了兼顾中文 英文 数字 标点 指令格式的真实输入。