1. 项目概述从jieba到Tokenizer的认知跃迁如果你还在用jieba处理大模型相关的文本任务那感觉就像是在用算盘给超级计算机做数据预处理。这并非贬低jieba它在过去十年里确实是中文NLP领域的“瑞士军刀”轻便、稳定、开箱即用。但时代变了朋友们。当我们的对话对象从传统的分类、情感分析模型升级到ChatGLM、GPT这类拥有千亿参数、理解能力接近人类的“智能体”时文本处理的底层逻辑已经发生了根本性的转变。这个项目的核心就是带你彻底搞明白为什么在大模型时代我们需要告别像jieba这样的传统分词器拥抱像ChatGLM所使用的Tokenizer分词器/标记器这类“高科技”。简单来说jieba做的是“物理分词”它根据词典和统计规则努力把一句话切成一个个有明确语义的“词”比如“我喜欢吃苹果”会被切成[‘我’ ‘喜欢’ ‘吃’ ‘苹果’]。而大模型的Tokenizer做的是“语义编码”它不再追求切分出完美的“词”而是将文本转换成模型能理解的、最基础的“语义碎片”Token。这些Token可能是一个字、一个词、一个词根甚至是一个常见的字符组合。关键在于这个过程是与模型训练深度绑定的Tokenizer的“词汇表”本身就是从海量训练数据中学习出来的它和模型的理解能力是一体的。所以别再问“ChatGLM用的是什么分词工具”了。它用的不是“工具”而是一个专属于它、为它而生的Tokenizer组件。这个转变是从“工具思维”到“系统思维”的升级。接下来我会拆解这背后的技术逻辑、实操差异并分享如何正确地在你的大模型项目中应用Tokenizer。2. 核心原理拆解Tokenizer vs. 传统分词的本质区别要理解为什么必须换“装备”我们得深入到它们的工作原理层面去看。这不仅仅是速度或准确率的比拼更是两种不同范式的较量。2.1 jieba的传统分词范式基于规则与统计的“切割术”jieba代表了经典的中文分词思路其核心是局部最优匹配。词典匹配加载一个庞大的中文词库采用前缀树Trie等数据结构尽可能地将句子中最长的、在词典中存在的词匹配出来最大匹配法。这保证了基础词汇的识别。统计模型HMM对于未登录词如人名、新词jieba利用隐马尔可夫模型根据字符之间的转移概率来“猜”最可能的分词边界。例如“马云”两个字一起出现的概率远高于“马”和“云”单独作为词边界的概率。结果输出最终输出一个由词语组成的列表。它的目标是还原人类书写时的词语单元。它的局限性在大模型场景下被放大词汇表固定且有限jieba的词库再大也无法覆盖互联网上源源不断产生的新词、网络用语、专业术语。遇到“栓Q”、“芭比Q了”、“LLM”它大概率会切成单字。与模型语义空间脱节jieba分出的词对于大模型来说只是一个陌生的字符串。模型需要重新学习这些字符串与语义的关联这中间存在信息损失和效率低下。例如jieba把“人工智能”切为一个词但大模型的Tokenizer可能将其编码为[“人工” “智能”]两个Token而这两个Token在训练时已经习得了丰富的上下文关联。无法处理子词和形态变化对于英文或中英文混合场景jieba能力薄弱。“unhappiness”它无法理解成[“un” “happi” “ness”]这种有语义的词根词缀组合。2.2 大模型Tokenizer的范式基于子词切分的“编码器”以ChatGLM、GPT系列使用的Byte-Pair Encoding (BPE)或其变种如SentencePiece为例这是一种数据驱动的、从底向上的合并算法。它的工作流程是这样的初始化词汇表最初只包含所有单字节字符比如英文的字母、数字、标点中文的每个字。统计与合并在海量训练语料上统计所有相邻的“符号对”出现的频率。将频率最高的一对合并成一个新的“符号”并加入词汇表。迭代重复步骤2直到词汇表达到预设的大小例如5万、10万。这个过程就像玩拼图把最常一起出现的碎片粘起来。编码对于一个新句子采用贪心匹配使用最终词汇表里最长的可能符号来切分文本。举个例子假设语料中“人工”和“智能”频繁共现BPE算法就会把它们合并成“人工智能”作为一个Token。如果“人工智能”和“技术”也频繁共现可能会进一步合并成“人工智能技术”。但合并到多大是由算法根据频率和词汇表大小决定的。它的核心优势数据驱动词汇表自适应Tokenizer直接从模型的训练数据中学习“什么该成为一个Token”完美契合该数据领域的语言特性。训练代码多的模型其Tokenizer识别代码片段的能力就强。解决未登录词问题任何新词都可以回退到子词甚至单字的组合来表示实现了“零”未登录词。例如“ChatGLM”可能被切分为[“Chat” “G” “L” “M”]或[“Chat” “GL” “M”]模型能根据这些子Token推测其含义。共享语义信息因为“智能”这个Token可能在“人工智能”、“智能制造”、“智能家居”中都出现模型学习到的关于“智能”的语义表示可以在不同上下文中共享和泛化效率极高。统一的多语言处理BPE基于字节天生可以处理任何语言的混合文本非常适合多语言大模型。注意这里有一个关键认知点。我们常说“大模型理解文本”实际上模型理解的从来不是汉字或词语本身而是这些Token对应的高维向量表示Embedding。Tokenizer是文本世界与模型向量世界的“翻译官”。一个设计良好的Tokenizer能让这个翻译过程损失的信息最少。2.3 为什么混用会出问题很多人在部署本地大模型如用Ollama、vLLM时图省事用jieba对用户输入进行预处理再把分词结果送给模型。这会导致灾难性后果对齐失败模型的Embedding层是在自己的Tokenizer输出的Token上训练的。你输入jieba的结果相当于给一个只懂英语的人看中文拼音他根本无法理解。位置信息混乱大模型尤其是Transformer严重依赖位置编码。jieba分出10个词模型Tokenizer可能将其编码成15个Token。模型预期的位置信息第5个Token是什么完全错乱生成的结果将是胡言乱语。功能失效一些特殊Token如[CLS]、[SEP]、|im_start|对话开始、|im_end|对话结束是模型理解任务格式如分类、问答、对话的关键。jieba完全无法处理这些。结论就是对于一个大模型必须使用它原生的Tokenizer没有任何商量余地。3. 实操指南如何正确使用大模型的Tokenizer理论说完了我们上实战。这里我以ChatGLM系列模型常用的Tokenizer为例但原理适用于绝大多数开源大模型LLaMA、Qwen、Baichuan等。3.1 获取与加载Tokenizer通常Tokenizer文件和模型文件是捆绑在一起的。从Hugging Face或ModelScope下载模型时你会看到类似tokenizer.model、tokenizer.json或tokenizer_config.json的文件。from transformers import AutoTokenizer # 方式1从Hugging Face模型库加载 model_name THUDM/chatglm3-6b tokenizer AutoTokenizer.from_pretrained(model_name, trust_remote_codeTrue) # trust_remote_codeTrue 对于ChatGLM等自定义模型是必须的 # 方式2从本地目录加载 local_path ./models/chatglm3-6b tokenizer AutoTokenizer.from_pretrained(local_path, trust_remote_codeTrue)实操心得首次加载时transformers库会自动下载词汇表和配置文件。在国内网络环境下这可能会很慢或失败。建议使用镜像源如清华源配置pip和git。更稳妥的方式是直接从Hugging Face网站或国内镜像站如ModelScope手动下载所有文件包括tokenizer.*文件放到本地目录然后从本地加载。3.2 Tokenizer的核心API与使用Tokenizer的主要任务就两个编码Encode和解码Decode。text 公主大人别再使用jieba了 # 1. 编码文本 - Token IDs encoded_input tokenizer(text) print(encoded_input) # 输出类似{input_ids: [64790, 64792, 103, 104, 105, ...], attention_mask: [1, 1, 1, ...]} # input_ids 就是模型真正需要的数字序列。 # 更常用的方式直接获取ID列表 input_ids tokenizer.encode(text) print(fToken IDs: {input_ids}) # 2. 查看Token切分结果 tokens tokenizer.tokenize(text) print(fTokens: {tokens}) # 输出可能类似[公, 主, 大, 人, , 别, 再, 使, 用, jie, ba, 了, ] # 注意‘jieba’被切分成了[jie, ba]这就是BPE子词切分的典型表现。 # 3. 解码Token IDs - 文本 decoded_text tokenizer.decode(input_ids) print(fDecoded: {decoded_text}) # 应该能无损地还原回原始文本。3.3 处理对话与特殊格式大模型对话如ChatGLM、GPT有严格的格式要求。Tokenizer会提供相应的工具方法。# 以类ChatML格式为例ChatGLM3、Qwen等常用 messages [ {role: system, content: 你是一个乐于助人的AI助手。}, {role: user, content: 你好请介绍一下你自己。} ] # 使用apply_chat_template方法推荐最规范 text tokenizer.apply_chat_template(messages, tokenizeFalse, add_generation_promptTrue) print(Formatted text:\n, text) # 输出会是一个拼接好的、包含特殊Token的字符串例如 # |system|\n你是一个乐于助人的AI助手。|end|\n|user|\n你好请介绍一下你自己。|end|\n|assistant|\n # 然后对这个格式化后的文本进行编码 input_ids tokenizer.encode(text, add_special_tokensFalse) # 因为template里已包含这里通常不加注意事项add_special_tokens参数默认为True会在文本首尾添加模型特定的开始/结束Token如s,/s。在拼接好的对话文本上编码时通常需要设为False避免重复添加。return_tensors参数如果想直接得到PyTorch或TensorFlow的Tensor可以设置return_tensors‘pt’或‘tf’方便直接输入模型。截断与填充模型有最大上下文长度限制如ChatGLM3-6B是8192。需要使用tokenizer(..., truncationTrue, max_length512, padding‘max_length’)来处理长文本。3.4 关键技巧计数与成本估算Token数量直接关联API调用成本对于云服务和推理速度。text “这是一段需要估算成本的文本。” # 方法1编码后计算长度 input_ids tokenizer.encode(text) num_tokens len(input_ids) print(fToken数量: {num_tokens}) # 方法2使用专门的encode_plus或直接调用 encoded tokenizer(text) num_tokens len(encoded[input_ids]) # 对于对话计算整个对话的Token数 def count_tokens_in_messages(messages, tokenizer): text tokenizer.apply_chat_template(messages, tokenizeFalse) return len(tokenizer.encode(text))一个重要的经验公式对于中文一个汉字通常对应1-2个Token取决于是否在常用词中。对于英文一个单词平均对应1.3个Token。你可以用这个快速估算。例如一段1000字的中文文章大致需要1500-2000个Token。4. 深入解析Tokenizer的类型与选型除了BPE市面上还有几种主流的Tokenization算法了解它们有助于你理解不同模型的行为。算法类型代表模型核心原理优点缺点BPEGPT系列 LLaMA ChatGLM从字符开始迭代合并最高频对平衡了词汇表大小和效率能有效表示常见词对罕见词可能切分过细编码结果可能不是全局最优WordPieceBERT ALBERT类似BPE但合并依据是概率似然值而非频率产生的词汇表在语言模型任务上可能更优训练稍复杂结果与BPE差异不大SentencePieceT5 部分ChatGLM版本将BPE/Unigram算法直接应用于原始字节流无需预分词完全语言无关可处理任意字符如表情符号无需预处理词汇表可能包含无意义的字节片段UnigramSentencePiece的一种模式从一个巨大词汇表开始逐步移除对整体似然度贡献最小的单元能直接优化词汇表对于语言模型的整体质量训练计算量更大选型建议对于绝大多数开发者你不需要选择Tokenizer而是选择模型。模型决定了Tokenizer。当你在训练自己的大模型时SentencePiece是一个强大且通用的选择因为它省去了繁琐的文本清洗和预分词步骤。如果你在处理多语言混合或包含大量特殊符号的文本SentencePiece或基于它的Tokenizer表现更稳健。5. 常见问题与故障排查实录在实际对接和部署大模型时Tokenizer是问题高发区。下面是我踩过的一些坑和解决方案。5.1 编码解码不一致出现特殊字符或乱码问题描述tokenizer.decode(tokenizer.encode(text))得到的结果和原文本不一样多出了0xE5之类的乱码或空格。根本原因额外空格处理Tokenizer如GPT系列的tiktoken可能在编码时规范化文本如将连续空格合并解码时按自己的规则还原。中英文混合空格英文Tokenizer通常会在单词前后加空格中文处理时可能产生混乱。解决方案检查Tokenizer的clean_up_tokenization_spaces参数尝试设为False。decoded_text tokenizer.decode(input_ids, clean_up_tokenization_spacesFalse)对于中文确保使用针对中文优化的Tokenizer如ChatGLM、Qwen的它们对中文空格的处理更友好。最重要的原则不要对Tokenizer的输入做复杂的预处理如随意增删空格。保持文本“原汁原味”让Tokenizer自己处理。5.2 对话历史拼接后模型输出混乱问题描述自己拼接对话格式后模型回复质量下降或开始胡言乱语。排查步骤格式检查严格对照模型文档要求的对话格式。是[INST][/INST]LLaMA2还是|im_start||im_end|ChatML一个符号都不能错。特殊Token检查使用tokenizer.special_tokens_map查看所有特殊Token及其对应的ID确保你在拼接时使用了正确的ID。使用官方工具绝对优先使用tokenizer.apply_chat_template()函数来拼接对话。这是最安全、最兼容的方式。验证编码将你拼接好的字符串和用apply_chat_template生成的字符串都进行编码对比它们的input_ids是否完全一致。5.3 本地部署时Tokenizer文件缺失或报错问题描述从网上下载的模型文件在加载Tokenizer时提示缺少tokenizer.json或tokenizer.model。解决方案完整下载模型文件通常包括pytorch_model.bin模型权重、config.json模型配置、tokenizer.json/tokenizer.model分词器、tokenizer_config.json分词器配置。缺一不可。手动指定如果文件存在但命名不规范可以尝试手动指定tokenizer AutoTokenizer.from_pretrained(./model_dir, tokenizer_file./model_dir/tokenizer.model)回退策略如果实在找不到Tokenizer文件可以尝试使用同一个模型系列其他版本的Tokenizer风险较高可能导致性能下降。例如用chatglm2-6b的Tokenizer临时替代chatglm3-6b的。5.4 Token数量超限Context Length Exceeded问题描述输入文本或对话历史过长超过模型最大上下文长度如8192导致推理失败或结果截断。处理策略主动截断在编码时设置truncationTrue和max_length。inputs tokenizer(text, truncationTrue, max_length4096, return_tensorspt)智能摘要对于长文档先使用其他模型或方法如提取式摘要将内容缩短再输入大模型。滑动窗口对于超长文本可以将其分成重叠的片段分别输入模型获取结果后再整合。这是RAG检索增强生成系统中处理长文档的常见思路。模型选型如果经常需要处理长文本应选择上下文窗口更大的模型如支持128K、200K的模型。一个实用的长度计算函数def check_and_truncate_conversation(messages, tokenizer, max_length8192, reserve_for_output512): 检查并截断对话历史确保为模型输出预留空间。 total_ids [] # 从最新消息开始倒序添加直到快满 for message in reversed(messages): new_text tokenizer.apply_chat_template([message], tokenizeFalse) new_ids tokenizer.encode(new_text, add_special_tokensFalse) if len(total_ids) len(new_ids) (max_length - reserve_for_output): break total_ids new_ids total_ids # 注意顺序 # 将截断后的ID重新组装成messages格式这里需要根据实际情况实现较为复杂 # 更简单的做法是直接对拼接后的整个文本进行截断 full_text tokenizer.apply_chat_template(messages, tokenizeFalse) inputs tokenizer(full_text, truncationTrue, max_lengthmax_length-reserve_for_output, return_tensorspt) return inputs6. 进阶微调与自定义Tokenizer当你需要让模型适应一个全新的领域如医疗、法律、代码时领域特有的术语可能会被原有Tokenizer切得很碎影响效率。这时可以考虑领域自适应分词。注意完全从头训练一个Tokenizer成本很高。更实用的方法是在原有Tokenizer基础上增加新词汇。步骤简述收集领域语料准备大量你所在领域的纯文本数据。识别新词用统计方法如词频或规则方法从语料中找出未在现有Tokenizer词汇表中、但又频繁出现的字符序列。扩展词汇表使用Hugging Face的tokenizers库将新词作为特殊Token添加到原有Tokenizer中。from transformers import AutoTokenizer tokenizer AutoTokenizer.from_pretrained(THUDM/chatglm3-6b) new_tokens [冠状动脉粥样硬化, Transformer架构, Python装饰器] # 你的新词列表 num_added_toks tokenizer.add_tokens(new_tokens) print(fAdded {num_added_toks} tokens) # **关键**必须同步扩展模型词嵌入矩阵的大小 model.resize_token_embeddings(len(tokenizer))继续预训练或微调用扩展后的Tokenizer和模型在你的领域语料上进行进一步的训练让模型学习这些新Token的向量表示。警告这个过程需要大量的计算资源和数据并且可能轻微影响模型原有的通用能力。对于大多数应用使用原版Tokenizer已经足够。从jieba到Tokenizer本质上是从一个孤立的数据预处理工具切换到与模型生命体紧密相连的“感知器官”。理解并正确使用Tokenizer是你驾驭大模型这项“高科技”的基础中的基础。它不再是一个可替换的组件而是模型不可分割的一部分。下次当你启动你的ChatGLM或任何其他大模型时请对它的Tokenizer抱有敬意——它正在默默地将人类模糊的语言精准地翻译成机器可以运算的星辰大海。
1. 项目概述从jieba到Tokenizer的认知跃迁如果你还在用jieba处理大模型相关的文本任务那感觉就像是在用算盘给超级计算机做数据预处理。这并非贬低jieba它在过去十年里确实是中文NLP领域的“瑞士军刀”轻便、稳定、开箱即用。但时代变了朋友们。当我们的对话对象从传统的分类、情感分析模型升级到ChatGLM、GPT这类拥有千亿参数、理解能力接近人类的“智能体”时文本处理的底层逻辑已经发生了根本性的转变。这个项目的核心就是带你彻底搞明白为什么在大模型时代我们需要告别像jieba这样的传统分词器拥抱像ChatGLM所使用的Tokenizer分词器/标记器这类“高科技”。简单来说jieba做的是“物理分词”它根据词典和统计规则努力把一句话切成一个个有明确语义的“词”比如“我喜欢吃苹果”会被切成[‘我’ ‘喜欢’ ‘吃’ ‘苹果’]。而大模型的Tokenizer做的是“语义编码”它不再追求切分出完美的“词”而是将文本转换成模型能理解的、最基础的“语义碎片”Token。这些Token可能是一个字、一个词、一个词根甚至是一个常见的字符组合。关键在于这个过程是与模型训练深度绑定的Tokenizer的“词汇表”本身就是从海量训练数据中学习出来的它和模型的理解能力是一体的。所以别再问“ChatGLM用的是什么分词工具”了。它用的不是“工具”而是一个专属于它、为它而生的Tokenizer组件。这个转变是从“工具思维”到“系统思维”的升级。接下来我会拆解这背后的技术逻辑、实操差异并分享如何正确地在你的大模型项目中应用Tokenizer。2. 核心原理拆解Tokenizer vs. 传统分词的本质区别要理解为什么必须换“装备”我们得深入到它们的工作原理层面去看。这不仅仅是速度或准确率的比拼更是两种不同范式的较量。2.1 jieba的传统分词范式基于规则与统计的“切割术”jieba代表了经典的中文分词思路其核心是局部最优匹配。词典匹配加载一个庞大的中文词库采用前缀树Trie等数据结构尽可能地将句子中最长的、在词典中存在的词匹配出来最大匹配法。这保证了基础词汇的识别。统计模型HMM对于未登录词如人名、新词jieba利用隐马尔可夫模型根据字符之间的转移概率来“猜”最可能的分词边界。例如“马云”两个字一起出现的概率远高于“马”和“云”单独作为词边界的概率。结果输出最终输出一个由词语组成的列表。它的目标是还原人类书写时的词语单元。它的局限性在大模型场景下被放大词汇表固定且有限jieba的词库再大也无法覆盖互联网上源源不断产生的新词、网络用语、专业术语。遇到“栓Q”、“芭比Q了”、“LLM”它大概率会切成单字。与模型语义空间脱节jieba分出的词对于大模型来说只是一个陌生的字符串。模型需要重新学习这些字符串与语义的关联这中间存在信息损失和效率低下。例如jieba把“人工智能”切为一个词但大模型的Tokenizer可能将其编码为[“人工” “智能”]两个Token而这两个Token在训练时已经习得了丰富的上下文关联。无法处理子词和形态变化对于英文或中英文混合场景jieba能力薄弱。“unhappiness”它无法理解成[“un” “happi” “ness”]这种有语义的词根词缀组合。2.2 大模型Tokenizer的范式基于子词切分的“编码器”以ChatGLM、GPT系列使用的Byte-Pair Encoding (BPE)或其变种如SentencePiece为例这是一种数据驱动的、从底向上的合并算法。它的工作流程是这样的初始化词汇表最初只包含所有单字节字符比如英文的字母、数字、标点中文的每个字。统计与合并在海量训练语料上统计所有相邻的“符号对”出现的频率。将频率最高的一对合并成一个新的“符号”并加入词汇表。迭代重复步骤2直到词汇表达到预设的大小例如5万、10万。这个过程就像玩拼图把最常一起出现的碎片粘起来。编码对于一个新句子采用贪心匹配使用最终词汇表里最长的可能符号来切分文本。举个例子假设语料中“人工”和“智能”频繁共现BPE算法就会把它们合并成“人工智能”作为一个Token。如果“人工智能”和“技术”也频繁共现可能会进一步合并成“人工智能技术”。但合并到多大是由算法根据频率和词汇表大小决定的。它的核心优势数据驱动词汇表自适应Tokenizer直接从模型的训练数据中学习“什么该成为一个Token”完美契合该数据领域的语言特性。训练代码多的模型其Tokenizer识别代码片段的能力就强。解决未登录词问题任何新词都可以回退到子词甚至单字的组合来表示实现了“零”未登录词。例如“ChatGLM”可能被切分为[“Chat” “G” “L” “M”]或[“Chat” “GL” “M”]模型能根据这些子Token推测其含义。共享语义信息因为“智能”这个Token可能在“人工智能”、“智能制造”、“智能家居”中都出现模型学习到的关于“智能”的语义表示可以在不同上下文中共享和泛化效率极高。统一的多语言处理BPE基于字节天生可以处理任何语言的混合文本非常适合多语言大模型。注意这里有一个关键认知点。我们常说“大模型理解文本”实际上模型理解的从来不是汉字或词语本身而是这些Token对应的高维向量表示Embedding。Tokenizer是文本世界与模型向量世界的“翻译官”。一个设计良好的Tokenizer能让这个翻译过程损失的信息最少。2.3 为什么混用会出问题很多人在部署本地大模型如用Ollama、vLLM时图省事用jieba对用户输入进行预处理再把分词结果送给模型。这会导致灾难性后果对齐失败模型的Embedding层是在自己的Tokenizer输出的Token上训练的。你输入jieba的结果相当于给一个只懂英语的人看中文拼音他根本无法理解。位置信息混乱大模型尤其是Transformer严重依赖位置编码。jieba分出10个词模型Tokenizer可能将其编码成15个Token。模型预期的位置信息第5个Token是什么完全错乱生成的结果将是胡言乱语。功能失效一些特殊Token如[CLS]、[SEP]、|im_start|对话开始、|im_end|对话结束是模型理解任务格式如分类、问答、对话的关键。jieba完全无法处理这些。结论就是对于一个大模型必须使用它原生的Tokenizer没有任何商量余地。3. 实操指南如何正确使用大模型的Tokenizer理论说完了我们上实战。这里我以ChatGLM系列模型常用的Tokenizer为例但原理适用于绝大多数开源大模型LLaMA、Qwen、Baichuan等。3.1 获取与加载Tokenizer通常Tokenizer文件和模型文件是捆绑在一起的。从Hugging Face或ModelScope下载模型时你会看到类似tokenizer.model、tokenizer.json或tokenizer_config.json的文件。from transformers import AutoTokenizer # 方式1从Hugging Face模型库加载 model_name THUDM/chatglm3-6b tokenizer AutoTokenizer.from_pretrained(model_name, trust_remote_codeTrue) # trust_remote_codeTrue 对于ChatGLM等自定义模型是必须的 # 方式2从本地目录加载 local_path ./models/chatglm3-6b tokenizer AutoTokenizer.from_pretrained(local_path, trust_remote_codeTrue)实操心得首次加载时transformers库会自动下载词汇表和配置文件。在国内网络环境下这可能会很慢或失败。建议使用镜像源如清华源配置pip和git。更稳妥的方式是直接从Hugging Face网站或国内镜像站如ModelScope手动下载所有文件包括tokenizer.*文件放到本地目录然后从本地加载。3.2 Tokenizer的核心API与使用Tokenizer的主要任务就两个编码Encode和解码Decode。text 公主大人别再使用jieba了 # 1. 编码文本 - Token IDs encoded_input tokenizer(text) print(encoded_input) # 输出类似{input_ids: [64790, 64792, 103, 104, 105, ...], attention_mask: [1, 1, 1, ...]} # input_ids 就是模型真正需要的数字序列。 # 更常用的方式直接获取ID列表 input_ids tokenizer.encode(text) print(fToken IDs: {input_ids}) # 2. 查看Token切分结果 tokens tokenizer.tokenize(text) print(fTokens: {tokens}) # 输出可能类似[公, 主, 大, 人, , 别, 再, 使, 用, jie, ba, 了, ] # 注意‘jieba’被切分成了[jie, ba]这就是BPE子词切分的典型表现。 # 3. 解码Token IDs - 文本 decoded_text tokenizer.decode(input_ids) print(fDecoded: {decoded_text}) # 应该能无损地还原回原始文本。3.3 处理对话与特殊格式大模型对话如ChatGLM、GPT有严格的格式要求。Tokenizer会提供相应的工具方法。# 以类ChatML格式为例ChatGLM3、Qwen等常用 messages [ {role: system, content: 你是一个乐于助人的AI助手。}, {role: user, content: 你好请介绍一下你自己。} ] # 使用apply_chat_template方法推荐最规范 text tokenizer.apply_chat_template(messages, tokenizeFalse, add_generation_promptTrue) print(Formatted text:\n, text) # 输出会是一个拼接好的、包含特殊Token的字符串例如 # |system|\n你是一个乐于助人的AI助手。|end|\n|user|\n你好请介绍一下你自己。|end|\n|assistant|\n # 然后对这个格式化后的文本进行编码 input_ids tokenizer.encode(text, add_special_tokensFalse) # 因为template里已包含这里通常不加注意事项add_special_tokens参数默认为True会在文本首尾添加模型特定的开始/结束Token如s,/s。在拼接好的对话文本上编码时通常需要设为False避免重复添加。return_tensors参数如果想直接得到PyTorch或TensorFlow的Tensor可以设置return_tensors‘pt’或‘tf’方便直接输入模型。截断与填充模型有最大上下文长度限制如ChatGLM3-6B是8192。需要使用tokenizer(..., truncationTrue, max_length512, padding‘max_length’)来处理长文本。3.4 关键技巧计数与成本估算Token数量直接关联API调用成本对于云服务和推理速度。text “这是一段需要估算成本的文本。” # 方法1编码后计算长度 input_ids tokenizer.encode(text) num_tokens len(input_ids) print(fToken数量: {num_tokens}) # 方法2使用专门的encode_plus或直接调用 encoded tokenizer(text) num_tokens len(encoded[input_ids]) # 对于对话计算整个对话的Token数 def count_tokens_in_messages(messages, tokenizer): text tokenizer.apply_chat_template(messages, tokenizeFalse) return len(tokenizer.encode(text))一个重要的经验公式对于中文一个汉字通常对应1-2个Token取决于是否在常用词中。对于英文一个单词平均对应1.3个Token。你可以用这个快速估算。例如一段1000字的中文文章大致需要1500-2000个Token。4. 深入解析Tokenizer的类型与选型除了BPE市面上还有几种主流的Tokenization算法了解它们有助于你理解不同模型的行为。算法类型代表模型核心原理优点缺点BPEGPT系列 LLaMA ChatGLM从字符开始迭代合并最高频对平衡了词汇表大小和效率能有效表示常见词对罕见词可能切分过细编码结果可能不是全局最优WordPieceBERT ALBERT类似BPE但合并依据是概率似然值而非频率产生的词汇表在语言模型任务上可能更优训练稍复杂结果与BPE差异不大SentencePieceT5 部分ChatGLM版本将BPE/Unigram算法直接应用于原始字节流无需预分词完全语言无关可处理任意字符如表情符号无需预处理词汇表可能包含无意义的字节片段UnigramSentencePiece的一种模式从一个巨大词汇表开始逐步移除对整体似然度贡献最小的单元能直接优化词汇表对于语言模型的整体质量训练计算量更大选型建议对于绝大多数开发者你不需要选择Tokenizer而是选择模型。模型决定了Tokenizer。当你在训练自己的大模型时SentencePiece是一个强大且通用的选择因为它省去了繁琐的文本清洗和预分词步骤。如果你在处理多语言混合或包含大量特殊符号的文本SentencePiece或基于它的Tokenizer表现更稳健。5. 常见问题与故障排查实录在实际对接和部署大模型时Tokenizer是问题高发区。下面是我踩过的一些坑和解决方案。5.1 编码解码不一致出现特殊字符或乱码问题描述tokenizer.decode(tokenizer.encode(text))得到的结果和原文本不一样多出了0xE5之类的乱码或空格。根本原因额外空格处理Tokenizer如GPT系列的tiktoken可能在编码时规范化文本如将连续空格合并解码时按自己的规则还原。中英文混合空格英文Tokenizer通常会在单词前后加空格中文处理时可能产生混乱。解决方案检查Tokenizer的clean_up_tokenization_spaces参数尝试设为False。decoded_text tokenizer.decode(input_ids, clean_up_tokenization_spacesFalse)对于中文确保使用针对中文优化的Tokenizer如ChatGLM、Qwen的它们对中文空格的处理更友好。最重要的原则不要对Tokenizer的输入做复杂的预处理如随意增删空格。保持文本“原汁原味”让Tokenizer自己处理。5.2 对话历史拼接后模型输出混乱问题描述自己拼接对话格式后模型回复质量下降或开始胡言乱语。排查步骤格式检查严格对照模型文档要求的对话格式。是[INST][/INST]LLaMA2还是|im_start||im_end|ChatML一个符号都不能错。特殊Token检查使用tokenizer.special_tokens_map查看所有特殊Token及其对应的ID确保你在拼接时使用了正确的ID。使用官方工具绝对优先使用tokenizer.apply_chat_template()函数来拼接对话。这是最安全、最兼容的方式。验证编码将你拼接好的字符串和用apply_chat_template生成的字符串都进行编码对比它们的input_ids是否完全一致。5.3 本地部署时Tokenizer文件缺失或报错问题描述从网上下载的模型文件在加载Tokenizer时提示缺少tokenizer.json或tokenizer.model。解决方案完整下载模型文件通常包括pytorch_model.bin模型权重、config.json模型配置、tokenizer.json/tokenizer.model分词器、tokenizer_config.json分词器配置。缺一不可。手动指定如果文件存在但命名不规范可以尝试手动指定tokenizer AutoTokenizer.from_pretrained(./model_dir, tokenizer_file./model_dir/tokenizer.model)回退策略如果实在找不到Tokenizer文件可以尝试使用同一个模型系列其他版本的Tokenizer风险较高可能导致性能下降。例如用chatglm2-6b的Tokenizer临时替代chatglm3-6b的。5.4 Token数量超限Context Length Exceeded问题描述输入文本或对话历史过长超过模型最大上下文长度如8192导致推理失败或结果截断。处理策略主动截断在编码时设置truncationTrue和max_length。inputs tokenizer(text, truncationTrue, max_length4096, return_tensorspt)智能摘要对于长文档先使用其他模型或方法如提取式摘要将内容缩短再输入大模型。滑动窗口对于超长文本可以将其分成重叠的片段分别输入模型获取结果后再整合。这是RAG检索增强生成系统中处理长文档的常见思路。模型选型如果经常需要处理长文本应选择上下文窗口更大的模型如支持128K、200K的模型。一个实用的长度计算函数def check_and_truncate_conversation(messages, tokenizer, max_length8192, reserve_for_output512): 检查并截断对话历史确保为模型输出预留空间。 total_ids [] # 从最新消息开始倒序添加直到快满 for message in reversed(messages): new_text tokenizer.apply_chat_template([message], tokenizeFalse) new_ids tokenizer.encode(new_text, add_special_tokensFalse) if len(total_ids) len(new_ids) (max_length - reserve_for_output): break total_ids new_ids total_ids # 注意顺序 # 将截断后的ID重新组装成messages格式这里需要根据实际情况实现较为复杂 # 更简单的做法是直接对拼接后的整个文本进行截断 full_text tokenizer.apply_chat_template(messages, tokenizeFalse) inputs tokenizer(full_text, truncationTrue, max_lengthmax_length-reserve_for_output, return_tensorspt) return inputs6. 进阶微调与自定义Tokenizer当你需要让模型适应一个全新的领域如医疗、法律、代码时领域特有的术语可能会被原有Tokenizer切得很碎影响效率。这时可以考虑领域自适应分词。注意完全从头训练一个Tokenizer成本很高。更实用的方法是在原有Tokenizer基础上增加新词汇。步骤简述收集领域语料准备大量你所在领域的纯文本数据。识别新词用统计方法如词频或规则方法从语料中找出未在现有Tokenizer词汇表中、但又频繁出现的字符序列。扩展词汇表使用Hugging Face的tokenizers库将新词作为特殊Token添加到原有Tokenizer中。from transformers import AutoTokenizer tokenizer AutoTokenizer.from_pretrained(THUDM/chatglm3-6b) new_tokens [冠状动脉粥样硬化, Transformer架构, Python装饰器] # 你的新词列表 num_added_toks tokenizer.add_tokens(new_tokens) print(fAdded {num_added_toks} tokens) # **关键**必须同步扩展模型词嵌入矩阵的大小 model.resize_token_embeddings(len(tokenizer))继续预训练或微调用扩展后的Tokenizer和模型在你的领域语料上进行进一步的训练让模型学习这些新Token的向量表示。警告这个过程需要大量的计算资源和数据并且可能轻微影响模型原有的通用能力。对于大多数应用使用原版Tokenizer已经足够。从jieba到Tokenizer本质上是从一个孤立的数据预处理工具切换到与模型生命体紧密相连的“感知器官”。理解并正确使用Tokenizer是你驾驭大模型这项“高科技”的基础中的基础。它不再是一个可替换的组件而是模型不可分割的一部分。下次当你启动你的ChatGLM或任何其他大模型时请对它的Tokenizer抱有敬意——它正在默默地将人类模糊的语言精准地翻译成机器可以运算的星辰大海。
![[光学原理与应用-521]：对光的错误理解与纠偏](http://pic.xiahunao.cn/yaotu/[光学原理与应用-521]：对光的错误理解与纠偏)
