1. 从jieba到Tokenizer为什么分词这件事在大模型时代彻底变了“公主大人别再用jieba做分词了”——这个标题乍一看有点标题党但背后反映的是一个非常真实且普遍的现象。很多从传统NLP项目转向大模型开发的工程师在处理中文文本时第一反应还是调用那个熟悉的import jieba。这本身没错jieba在过去十年里凭借其简单易用、效果尚可的特点成为了中文分词领域的“国民工具”。但当你开始接触ChatGLM、GPT、Llama这些大模型时如果还试图用jieba的分词结果去“喂”给它们或者用jieba的逻辑去理解它们的输入输出那无异于用算盘去理解超级计算机的运算从一开始就走错了方向。问题的核心在于大模型LLM的“分词”Tokenization和我们传统NLP中的“分词”Word Segmentation虽然中文都叫“分词”但完全是两码事。jieba做的是“词语切分”它的目标是将一个连续的汉字序列按照中文的语言习惯切分成一个个有意义的词语如“我喜欢吃苹果” - [“我”, “喜欢”, “吃”, “苹果”]。这个过程依赖于词典、统计模型或深度学习模型来识别词语边界。而大模型的Tokenizer如ChatGLM用的、GPT用的tiktoken、Llama用的SentencePiece做的是“子词切分”Subword Tokenization。它的目标不是寻找语言学上的词语而是将一个文本无论中文、英文还是混合切分成模型词汇表Vocabulary中存在的、更小的基本单位Token。这些Token可能是完整的常见词如“apple”也可能是词根如“un-”、词缀如“-ing”甚至对于中文可能是单个汉字、汉字部件或高频汉字组合。例如“我喜欢吃苹果”在大模型Tokenizer看来可能被切分成 [“我”, “喜欢”, “吃”, “苹”, “果”] 或 [“我”, “喜”, “欢”, “吃”, “苹果”]这完全取决于它的训练语料和词汇表构建算法。这个根本性的差异导致了从工具选型、数据处理流程到问题排查思路的全方位变革。继续用jieba的思维去处理大模型你会遇到一系列令人困惑的问题为什么我算的文本长度和模型报的input_ids长度对不上为什么同样的提示词换了个说法效果天差地别为什么模型有时会对某些字符或符号产生“幻觉”要回答这些问题我们必须深入理解大模型Tokenizer这个“高科技”的核心机制。2. 拆解Tokenizer大模型如何“阅读”世界要理解为什么不能再用jieba我们必须先搞懂大模型的Tokenizer到底是什么以及它是如何工作的。这不仅仅是换一个工具而是换一套底层的数据表示哲学。2.1 核心目标在压缩与信息保留间走钢丝Tokenizer的首要任务是将人类可读的文本字符串转换为模型可处理的数字序列Token ID。这个过程需要平衡几个矛盾的目标压缩性词汇表不能无限大通常几万到几十万否则模型参数会爆炸查找效率也低。因此需要将海量可能的字符组合映射到有限的Token集合中。信息保留转换过程要尽可能保留原文的语义信息。一个糟糕的切分可能会改变意思比如“南京市长江大桥”的不同切分。泛化能力要能处理训练时没见过的词OOV, Out-Of-Vocabulary。基于词语的切分如jieba对此无能为力而子词切分通过将生词拆成已知子词来解决。语言无关性一个好的Tokenizer应对多种语言至少是训练语料中的语言都有不错的效果。基于词语的分词器如jieba主要关注目标2但在目标1、3、4上存在天然缺陷。而子词切分方案正是为了综合解决这些问题而诞生的。2.2 主流子词切分算法Byte-Pair Encoding与它的朋友们目前主流大模型的Tokenizer大多基于以下几种算法或其变种Byte-Pair Encoding (BPE)这是GPT系列、ChatGLM等模型广泛采用的算法。它从字符级别开始统计训练语料中相邻字节对最初是UTF-8字节对于中文就是单字的出现频率将最高频的配对合并成一个新的“Token”加入词汇表并不断迭代这个过程。举例假设语料中“喜欢”这个词出现得非常频繁。BPE算法会先看到“喜”和“欢”两个字统计发现它们紧挨着出现的次数极高于是在某一轮迭代中将“喜欢”合并为一个新的Token加入词汇表。之后遇到“喜欢”就不再切分成两个字而是直接用一个Token表示。对于不常见的词如“饕餮”如果语料中不常出现可能就不会被合并在编码时依然被切分成“饕”、“餮”两个单独的Token如果它们在词汇表中存在的话。优点能有效地平衡常见词合并和生僻词拆解压缩率高泛化能力强。ChatGLM的应用ChatGLM系列模型的Tokenizer就是基于BPE算法在大量中英文语料上训练得到的。它的词汇表包含了常见的汉字、词语、英文单词、符号等。这也是为什么它处理中文混合文本时相对流畅的原因。WordPieceBERT模型使用的算法。与BPE类似也是通过合并子词来构建词汇表但它的合并准则不是频率而是基于概率看合并后的子词是否能最大程度地提高语言模型的似然概率。它更倾向于合并能显著减少困惑度的单元。Unigram Language ModelSentencePiece工具支持的一种算法。它从一个很大的种子词汇表开始通过迭代移除对整体似然度贡献最小的Token来缩减词汇表最终得到一个固定大小的最优词汇表。这种方法得到的Token可能更“纯粹”。Byte-level BPE (BBPE)GPT-2/3/4等采用的tiktoken本质上是一种BPE但它是在字节Byte级别而非字符级别进行的。这意味着它的词汇表基于是256个字节理论上可以无损编码任何文本包括任何语言、任何符号、甚至文件二进制数据彻底解决了OOV问题。对于中文一个汉字通常由3个UTF-8字节组成可能会被切分成多个字节级的Token。注意选择哪种算法决定了词汇表的构成和Token的切分方式。当你看到模型对同一个词给出不同的Token数量时很可能就是底层算法不同导致的。例如一个中文成语在BPE-based的Tokenizer里可能是一个Token在BBPE里可能是三四个Token。2.3 词汇表大模型的“字典”词汇表Vocab是一个从Token字符串到ID整数的映射表。例如在ChatGLM的词汇表中“人工智能”可能对应ID 12345“的”对应ID 2043。模型训练和推理时只认识这些ID。词汇表大小通常在3万到10多万之间。例如ChatGLM-6B的词汇表大小是130528。这个数字是模型设计时的一个超参数需要在表达能力和模型效率之间权衡。特殊Token词汇表中除了常规文本Token还包含一系列具有特殊功能的Token这是大模型Tokenizer与jieba等传统工具又一个关键区别。常见的特殊Token包括[CLS],[SEP]在BERT中用于分类和分隔句子。|endoftext|在GPT系列中表示文本结束。s,/s在Llama等模型中表示序列的开始和结束。[UNK]代表未知Token当输入中出现词汇表中没有的字符时使用好的Tokenizer应尽量避免产生此Token。[PAD]用于将不同长度的序列填充到相同长度便于批量计算。ChatGLM的特殊TokenChatGLM有自己的对话格式包含像[gMASK]、[sop]等用于控制生成行为的特殊Token。在构造输入时必须按照其规定的模板加入这些Token模型才能正确理解指令和上下文。理解词汇表和特殊Token是正确与大模型“对话”的前提。用jieba分词然后拼接完全无法引入这些关键的控制信息。3. 实战对比jieba与ChatGLM Tokenizer处理同一文本的差异理论说了很多我们直接上代码看看用jieba和用ChatGLM的Tokenizer处理同一段文本结果到底有多大差别。这是最直观的“劝退”环节。假设我们有一段混合中英文的文本模拟一个典型的提示词Prompttext “请用Python编写一个函数计算斐波那契数列的第n项。要求高效并给出时间复杂度分析。”3.1 使用jieba进行分词import jieba seg_list jieba.lcut(text) print(“jieba分词结果”, seg_list) print(“分词数量”, len(seg_list))输出可能类似于jieba分词结果 [‘请’, ‘用’, ‘Python’, ‘编写’, ‘一个’, ‘函数’, ‘’, ‘计算’, ‘斐波那契’, ‘数列’, ‘的’, ‘第’, ‘n’, ‘项’, ‘。’, ‘要求’, ‘高效’, ‘’, ‘并’, ‘给出’, ‘时间’, ‘复杂度’, ‘分析’, ‘。’] 分词数量 24jieba将文本切分成了24个“词语”单元。它识别出了“斐波那契”作为一个专有名词分开了“时间复杂度”。对于英文“Python”和“n”它将其视为整体。标点符号也被单独切分出来。3.2 使用ChatGLM的Tokenizer进行编码这里以ChatGLM3-6B的Transformers实现为例from transformers import AutoTokenizer # 加载ChatGLM3的Tokenizer tokenizer AutoTokenizer.from_pretrained(“THUDM/chatglm3-6b”, trust_remote_codeTrue) # 对文本进行编码Tokenization encoded_input tokenizer(text) tokens tokenizer.convert_ids_to_tokens(encoded_input[‘input_ids’]) print(“ChatGLM Tokenizer Token列表”, tokens) print(“Token数量”, len(tokens)) print(“对应的Token IDs”, encoded_input[‘input_ids’])输出可能类似于ChatGLM Tokenizer Token列表 [‘请’, ‘用’, ‘Python’, ‘编写’, ‘一个’, ‘函数’, ‘’, ‘计算’, ‘斐’, ‘波’, ‘那’, ‘契’, ‘数列’, ‘的’, ‘第’, ‘n’, ‘项’, ‘。’, ‘要求’, ‘高效’, ‘’, ‘并’, ‘给出’, ‘时间’, ‘复杂度’, ‘分析’, ‘。’] Token数量 27 对应的Token IDs [‘请’对应的ID, ‘用’对应的ID, … ‘。’对应的ID]差异立刻显现切分粒度不同ChatGLM的Tokenizer将“斐波那契”拆成了‘斐’ ‘波’ ‘那’ ‘契’四个独立的Token而jieba将其视为一个整体。这是因为在ChatGLM训练语料中“斐波那契”作为一个整体出现的频率可能不够高未能被BPE算法合并成一个Token。相反“数列”被合并成了一个Token。Token数量不同jieba分出24个单元ChatGLM Tokenizer分出27个Token。这个数字至关重要因为大模型是按Token数量计费和消耗计算资源的对于按量付费的API或受上下文长度限制的。错误地使用jieba来估算长度会导致严重的预算或性能误判。特殊结构我们这里只是编码了纯文本。在实际调用ChatGLM时我们需要用tokenizer.apply_chat_template()或手动按照[Round 1]\n\n问{用户输入}\n\n答这样的格式来构造输入这些格式符号如[Round 1]、\n\n都会被Tokenizer转换成特定的Token进一步增加总Token数。这是jieba完全无法处理的。3.3 关键影响长度计算与成本控制这个差异在以下场景中会带来实际问题场景一上下文窗口限制假设你使用的模型上下文窗口是4096个Token。你用jieba统计你的提示词有2000个“词”以为绰绰有余。但实际上经过大模型Tokenizer编码后它可能变成了2800个Token。如果你还要预留生成答案的空间很可能在生成过程中就触发了长度限制导致生成截断或失败。场景二API调用成本像OpenAI的API是按输入和输出的总Token数计费的。如果你用基于字符或jieba分词的数量去估算成本会严重低估实际费用。一个精确的预算工具必须调用官方的Tokenizer如tiktoken来计算。正确的长度计算姿势# 对于ChatGLM input_ids tokenizer.encode(text) token_count len(input_ids) print(f”实际Token数量不含特殊控制符: {token_count}”) # 对于OpenAI GPT (使用tiktoken) import tiktoken enc tiktoken.encoding_for_model(“gpt-4”) token_count_openai len(enc.encode(text)) print(f”GPT-4编码下的Token数量: {token_count_openai}”)永远不要相信基于空格、字符或传统分词工具的长度估算。4. 超越分词Tokenizer在大模型工作流中的核心作用理解了Tokenizer是什么以及它如何工作之后我们来看看它在整个大模型应用开发流程中扮演着哪些jieba无法替代的关键角色。这不仅仅是“编码”和“解码”那么简单。4.1 提示工程Prompt Engineering的基石提示工程的核心是构造模型能“理解”的输入序列。Tokenizer直接决定了模型“看到”的是什么。符号与空格敏感英文中”word”和” word”前面有个空格在BPE Tokenizer下可能是完全不同的Token。例如在GPT的词汇表里”hello”和” hello”带空格的ID是不同的。一个提示词中多余或少一个空格可能导致模型接收到不同的信号。格式模板如之前提到的ChatGLM、Llama Chat、Qwen等对话模型都有严格的对话模板。这些模板由一系列特殊Token和文本结构组成。你必须使用官方的apply_chat_template方法或严格按照文档拼接才能让模型识别出角色用户/助手和对话轮次。手动拼接字符串极易出错。思维链Chain-of-Thought触发研究发现在提示词中加入”Let’s think step by step”这类短语能激发模型的推理能力。这背后的原因之一是这些短语作为特定的Token序列在训练数据中常常与高质量的推理过程相关联。Tokenizer确保了这些“魔法短语”被准确地传递。4.2 微调Fine-tuning中的数据预处理当你用自己的数据对大模型进行微调时数据预处理的第一步就是Tokenization。统一长度与填充Padding为了进行批量训练需要将样本处理成等长。Tokenizer提供了paddingTrue, truncationTrue, max_length512这样的参数自动完成截断和填充并生成对应的attention_mask来告诉模型哪些是真实内容哪些是填充的无效部分。标签对齐对于序列标注任务如果你在做命名实体识别NER微调你的标签是针对原始文本的字符或词语的。但模型处理的是Token。这就出现了对齐问题一个实体词可能被拆成多个Token。你需要将字符/词级别的标签精确地映射到Token级别例如采用BIO标注法并将被拆分词的首个Token标为B-后续Token标为I-。这个过程必须依赖同一个Tokenizer来完成用jieba分词的结果去对齐大模型的Token注定会失败。4.3 解码Decoding与生成控制模型生成文本是一个循环过程根据已有的Token ID序列预测下一个Token的概率分布然后根据某种策略如贪婪搜索、束搜索、采样选择一个Token ID将其追加到序列中再继续预测下一个。Tokenizer在这里负责将ID转换为可读文本在每一步生成后我们需要将新生成的Token ID通过Tokenizer的decode方法转换成字符串展示给用户。decode方法会智能地处理子词合并比如将[‘喜’, ‘欢’]正确地还原成“喜欢”。处理特殊Token解码过程需要识别停止符如|endoftext|当生成该Token时停止生成。不同的Tokenizer定义了不同的停止符。对数概率计算在一些高级应用中我们需要计算生成文本的困惑度Perplexity或特定序列的概率。这需要基于Tokenizer切分后的Token序列来计算每个Token的预测概率。4.4 检索增强生成RAG中的向量化在RAG架构中需要将文档库切成块Chunk并编码成向量Embedding存入向量数据库。这个“切块”的最佳单位不是字符数也不是jieba的词数而是Token数。为什么因为文本的向量表示Embedding是由模型产生的而模型的输入单位是Token。以Token数为准来切分能保证每个文本块被模型处理时不会因为意外的长Token如一个长单词被拆成很多子词而超出模型输入限制也能更均匀地分配语义信息。实操在构建RAG系统时应该使用与大模型配套的Tokenizer来计算文本块的Token长度并以此作为切分和筛选的依据。5. 避坑指南从jieba思维迁移到Tokenizer思维的常见问题习惯了jieba的开发者在刚接触大模型Tokenizer时肯定会踩不少坑。下面我总结几个最常见的问题和解决方案希望能帮你平稳过渡。5.1 坑一错误估算输入长度导致请求失败或成本超标这是最普遍的问题。如前所述用字符数/词数估算Token数极不准确。解决方案预计算在构建提示词或处理用户输入前先用目标模型的Tokenizer进行编码获取精确的Token数。设置安全边际如果你的上下文窗口是4096建议将系统提示词、用户输入和预留的回答空间总和控制在3500-3800左右为模型内部处理留出缓冲。动态截断对于可能超长的用户输入实现一个截断逻辑。不是简单地从中间截断字符而是用Tokenizer编码后从头部或尾部移除一部分Token再解码回文本这样能保证截断后的文本依然是合法的Token序列。5.2 坑二手动拼接对话格式导致模型无法理解角色很多开发者会像下面这样手动构造ChatGLM的输入# 错误示范 bad_prompt “用户你好\n助手” input_ids tokenizer.encode(bad_prompt, …)这忽略了ChatGLM需要的特殊控制Token和结构。解决方案永远使用官方推荐的格式构造方法。# 正确做法以ChatGLM3为例 from transformers import AutoTokenizer tokenizer AutoTokenizer.from_pretrained(“THUDM/chatglm3-6b”, trust_remote_codeTrue) messages [ {“role”: “system”, “content”: “你是一个乐于助人的助手。”}, {“role”: “user”, “content”: “你好请介绍一下你自己。”} ] # 使用apply_chat_template方法自动添加所有必要的特殊Token和格式 input_ids tokenizer.apply_chat_template(messages, tokenizeTrue, add_generation_promptTrue, return_tensors“pt”)对于不支持apply_chat_template的老版本或某些模型必须严格查阅其模型卡Model Card或源码中的tokenization_xxx.py文件找到对话模板如”[Round 1]\n\n问{query}\n\n答”并原样使用。5.3 坑三处理包含特殊符号或罕见字的文本时出现[UNK]当文本中含有词汇表外的字符如某些特殊数学符号、罕见古汉字、新造网络用语时Tokenizer可能会将其替换为[UNK]未知Token导致信息丢失。解决方案选择字节级Tokenizer像GPT-4使用的tiktokenBBPE理论上不会产生[UNK]因为任何字节都能被编码。如果你的应用场景涉及非常规文本优先考虑使用这类模型。文本清洗与规范化在预处理阶段将全角符号转为半角统一繁体字与简体字过滤或替换掉极端罕见的字符。后处理检查在编码后检查input_ids中是否包含tokenizer.unk_token_id。如果有可以对原始文本进行高亮提示或采用回退策略。5.4 坑四微调时标签与Token无法对齐这是序列标注微调中的经典难题。解决方案使用Tokenizer提供的offset_mapping功能。在编码时设置return_offsets_mappingTrue它会返回每个Token在原始文本中的起始位置结束位置元组。利用这个映射关系可以将字符级别的标签精确地分配到对应的Token上。encoding tokenizer(text, return_offsets_mappingTrue, truncationTrue, paddingTrue) offset_mapping encoding[“offset_mapping”] input_ids encoding[“input_ids”] # offset_mapping 是一个列表每个元素如 (0, 1) 代表第一个Token对应原文本第0到第1个字符左闭右开 # 根据这个映射将你的字符级标签列表转换为Token级标签列表这个过程需要仔细处理被拆分的词其offset是连续的以及被[CLS]、[SEP]、[PAD]等特殊Token占用的位置。从jieba到Tokenizer不仅仅是工具的切换更是思维模式的升级。它要求我们从“语言学家”的视角如何切分出有意义的词转向“模型架构师”的视角如何用有限的离散单元最有效地表示无限的语言信息。理解并熟练运用Tokenizer是构建高效、稳定、可控的大模型应用的必备技能。下次当你准备处理文本时第一件事不再是import jieba而是先问自己我的目标模型是什么它的Tokenizer该如何调用这才是通往“大模型时代”的正确起点。