尧图网页设计 
1. 从“词”到“元”理解大语言模型的第一道工序如果你刚接触大语言模型LLM可能会被“Transformer架构”、“注意力机制”、“预训练”这些术语搞得晕头转向。但无论模型多么复杂它处理文本的第一步和我们人类阅读一样都是先“认字”。只不过模型认的不是我们眼中的“字”或“词”而是一种叫做“Token”的东西。这个过程就是Tokenization分词/标记化。今天我们就来深入聊聊这个看似基础实则深刻影响模型性能、成本乃至行为的关键环节。这不仅是斯坦福CS336等前沿课程的开篇也是每个想真正理解LLM的从业者必须跨过的第一道门槛。简单来说Tokenization就是把一段原始文本比如“Hello, world!”切割、转换成一系列模型能够理解和处理的数字ID的过程。这些切割后的最小单元就是Token。它远不止是“按空格切分”那么简单其背后的算法选择、词表构建直接决定了模型能认识哪些“概念”、处理效率如何甚至会产生哪些奇怪的“故障”。理解Tokenization你就能明白为什么模型有时会对一个简单的拼写错误束手无策为什么生成中文时偶尔会夹杂乱码以及如何更经济高效地使用API。接下来我将结合原理、实操和踩坑经验带你彻底搞懂它。2. 核心思路为什么“分词”是LLM的基石而非琐事在深度学习处理文本的早期常见的方法是字符级Character-level或单词级Word-level处理。字符级把每个字母、标点都当作一个Token词表很小几十到几百个但序列会变得极长模型难以捕捉语义。单词级以空格为分隔符语义单元清晰但词表会爆炸式增长动辄数十万还会遭遇“未登录词OOV”问题——遇到没见过的词就傻眼了。现代LLM采用的是一种折中且更聪明的方案子词分词Subword Tokenization。它的核心思想是将频繁出现的字符串作为一个整体Token而将不常见的长词拆分成更小的、可重复使用的子词单元。这就像我们背单词时会认识“un-”否定、“-able”能够这样的词根词缀然后用它们去理解“unbelievable”这类新词。这种方案带来了几个根本性优势解决OOV问题即使“ChatGPT”这个词没在训练中出现过只要词表里有“Chat”、“G”、“PT”这些子词模型就能组合出它。平衡效率与语义相比字符级序列长度更短计算更高效相比单词级词表大小可控通常在几万到十万量级减少了模型参数和内存占用。跨语言兼容性对于英语这类空格分隔的语言效果很好通过精心设计也能较好地适配中文、日文等非空格语言。目前主流的大模型如GPT系列、LLaMA系列大都基于BPEByte-Pair Encoding或其变种如GPT-2/3/4使用的BPESentencePiece库。因此理解BPE就成了理解现代LLM分词的关键。3. 算法深潜BPE是如何“学”出一个词表的BPE算法并不复杂但其设计非常巧妙。它从一个基础字符集开始通过迭代合并最高频的相邻符号对逐步构建出词表。下面我们通过一个极简的例子拆解它的训练过程。假设我们的训练语料只有三句话“low lower”“newest newest”“widest widest”第一步初始化基础词表首先我们将所有文本拆分成最基础的单元比如UTF-8字节或字符。这里我们用字符并在每个词末尾添加一个特殊的结束符/w来标记词边界这对后续合并很重要。 初始词汇表就是所有字符{‘l’, ‘o’, ‘w’, ‘e’, ‘r’, ‘n’, ‘s’, ‘t’, ‘i’, ‘d’, ‘/w’}。此时语料表示为l o w /w l o w e r /wn e w e s t /w n e w e s t /ww i d e s t /w w i d e s t /w第二步迭代合并统计所有相邻符号对的出现频率。第一次迭代中e和s出现了4次在“newest”和“widest”中频率最高。于是我们将es合并为一个新的符号单元。 现在词表变为{‘l’, ‘o’, ‘w’, ‘e’, ‘r’, ‘n’, ‘s’, ‘t’, ‘i’, ‘d’, ‘/w’, ‘es’}。语料更新为l o w /w l o w e r /wn e w es t /w n e w es t /ww i d es t /w w i d es t /w第三步持续合并重复这个过程。接下来es和t经常相邻出现4次合并为est。然后est和/w合并为est/w这意味着“est”经常作为一个词的结尾。再然后w和i合并为wiwi和d合并为wid最终wid和est/w合并为widest/w。经过多轮迭代我们可能会得到一个包含low/w,lower/w,newest/w,widest/w等完整单词以及est,es,wid等子词的词表。算法会在达到预设词表大小例如50,000时停止。关键理解BPE的词表是从数据中“学习”出来的它反映了训练语料的统计特征。高频词如“the”“ing”会作为整体保留低频长词则被拆解。这解释了为什么同一个模型用不同领域语料训练出的分词器其行为会有差异。3.1 BPE的实战变种与工具在实际应用中我们直接使用成熟库而非从头实现。最常用的是tiktoken(OpenAI) 和sentencepiece(Google)。tiktokenGPT系列模型的官方分词器。速度快与模型完全匹配。它有几个不同的编码器如cl100k_base(用于GPT-4 Turbo, ChatGPT)p50k_base(用于GPT-3系列)。使用起来非常简单import tiktoken enc tiktoken.get_encoding(“cl100k_base”) tokens enc.encode(“Hello, world! This is a test.”) print(tokens) # 输出一串数字ID print([enc.decode_single_token_bytes(t).decode(‘utf-8’, errors‘replace’) for t in tokens]) # 查看Token对应的原始字节sentencepiece支持BPE和Unigram算法不依赖空格进行预分词因此对中文、日文等语言更友好。LLaMA、T5等模型都使用它。import sentencepiece as spm sp spm.SentencePieceProcessor(model_file‘llama.model’) tokens sp.encode(“你好世界”, out_typestr) # 直接输出子词字符串 print(tokens) # 可能输出 [‘▁你’, ‘好’, ‘’, ‘▁世界’] (‘▁’代表空格)实操心得选择分词器时必须与你的目标模型严格匹配。用GPT的分词器去处理LLaMA的输入或者用自己的词表去加载预训练模型都会导致灾难性的后果——模型看到的全是乱码。这就像用英语词典去查中文句子一样荒谬。4. 影响与陷阱分词如何暗中支配模型行为理解了原理我们来看看分词在实际中引发的那些“坑”。这些往往是API调用成本异常、模型生成质量波动的元凶。4.1 Token与计费为什么我的API账单这么贵几乎所有云LLM API如OpenAI, Anthropic都按Token数量计费。这里的Token不是单词数。一个经验法则是英文中1个Token约等于0.75个单词中文中1个汉字约等于1.3-2个Token。这是因为中文常被拆分成更小的子词。示例对比输入“The quick brown fox jumps over the lazy dog.” (9个单词)Token化使用GPT-4编码器[“The”, “ quick”, “ brown”, “ fox”, “ jumps”, “ over”, “ the”, “ lazy”, “ dog”, “.”] -10个Tokens。基本符合0.75倍关系。输入“深度学习是人工智能的核心领域。” (13个汉字)Token化使用GPT-4编码器[“深”, “度”, “学”, “习”, “是”, “人工”, “智能”, “的”, “核心”, “领域”, “。”] -11个Tokens。平均每个汉字约0.85个Token但这个比例会随词频变化很大。像“人工智能”可能被合并为一个Token而“深度学习”可能被拆开。成本优化技巧精简提示词Prompt去除冗余的礼貌用语、不必要的解释。用更简洁的指令达到相同效果。使用系统消息在对话API中将相对固定的指令放在system角色中这部分内容通常在计费中权重较低或处理方式不同需查阅具体API文档。缓存重复内容如果多次请求中有相同的长文本如知识库文档可以考虑先将其编码为Token ID并缓存避免重复分词计算虽然API端可能已优化但客户端预处理也有意义。预估与监控在发送长文本前先用本地分词器如tiktoken估算Token数。大多数API有输入长度限制超限会直接失败。4.2 分词边界与模型“幻觉”分词器不认识词边界只认识统计规律。这会导致一些反直觉的现象拼写错误与鲁棒性用户输入“acommodation”少一个‘c’。如果词表里有“accommodation”作为一个整体Token那么模型完全无法理解这个错词因为它会被拆分成像[“a”, “com”, “mod”, “ation”]这样奇怪的子词语义完全丢失。模型可能因此开始胡言乱语。相比之下字符级模型对拼写错误更鲁棒。数字处理难题“123,456”这个数字可能被分词为[“123”, “,”, “456”]。当要求模型进行算术运算时它需要先理解这三个Token组合起来是一个数字这增加了任务的难度。这也是为什么早期LLM数学能力普遍较弱的原因之一。跨语言混编问题在中文中夹杂英文单词如“我用了GitHub”。分词器可能将“GitHub”作为一个整体Token如果它在词表中也可能拆成“Git”和“Hub”。如果拆分了模型可能无法准确识别这是一个专有名词。4.3 中文分词的独特挑战英文有天然空格分隔BPE效果很好。中文是连续书写没有空格因此需要额外的预分词步骤或者使用像SentencePiece这样不依赖空格的分词器。常见策略是在BPE之前先用一个基础的中文分词器如jieba将句子切分成词再对词序列应用BPE。风险是基础分词器的错误会传导给LLM。直接对汉字序列或UTF-8字节序列应用BPE/SentencePiece。这是目前更主流的方法但可能导致一个汉字被拆成多个字节Token尤其在UTF-8下效率降低。中文分词的一个典型现象同一个词在不同上下文可能被分成不同的样子。例如“机器学习”可能在高频语料中被合并为一个Token但在某个专业子领域中可能被保持为“机器”和“学习”两个Token。这要求我们在设计针对中文的提示词时对关键术语要保持一致。5. 实操指南如何与分词器正确打交道5.1 估算与截断处理长文本的必备技能LLM有上下文窗口限制如4K, 8K, 128K Tokens。你需要确保输入输出的Token总数不超过这个限制。import tiktoken def truncate_text_by_tokens(text, model_name, max_tokens): “””根据特定模型的分词器截断文本。””” try: encoding tiktoken.encoding_for_model(model_name) except KeyError: print(f“Warning: Model {model_name} not found. Using cl100k_base as default.”) encoding tiktoken.get_encoding(“cl100k_base”) tokens encoding.encode(text) if len(tokens) max_tokens: tokens tokens[:max_tokens] truncated_text encoding.decode(tokens) # 注意直接decode可能在不完整的UTF-8边界截断导致末尾乱码 # 更安全的方法是尝试解码如果出错则逐步回退Token直到解码成功 try: truncated_text encoding.decode(tokens) except UnicodeDecodeError: for i in range(1, len(tokens)): try: truncated_text encoding.decode(tokens[:-i]) break except UnicodeDecodeError: continue print(f“Text truncated from {len(tokens) (len(tokens)max_tokens? i:0)} to {max_tokens} tokens.”) return truncated_text else: return text # 使用示例 long_text “…” # 你的长文本 model “gpt-4” max_input_tokens 8000 # 假设模型输入限制为8000 processed_text truncate_text_by_tokens(long_text, model, max_input_tokens)重要提示截断时直接在Token序列层面截断再解码回文本可能会在某个多字节字符的中间截断导致末尾出现乱码如。上述代码提供了一个简单的回退机制但更健壮的做法是预留一部分Token余量或者确保在句子边界、段落边界处截断。5.2 调试与可视化看清模型“眼中”的世界当你怀疑模型因为分词问题而表现不佳时可视化分词结果至关重要。def visualize_tokens(text, encoder_name‘cl100k_base’): encoding tiktoken.get_encoding(encoder_name) tokens encoding.encode(text) decoded_pieces [] for token_id in tokens: # 将Token ID解码回原始的字节再尝试转换为字符串 bytes_repr encoding.decode_single_token_bytes(token_id) try: # 对于可打印字符显示字符串 piece bytes_repr.decode(‘utf-8’) # 对空格等不可见字符进行转义便于观察 piece piece.replace(‘ ‘, ‘▁‘) except UnicodeDecodeError: # 对于无效字节如被截断的显示十六进制 piece f0x{bytes_repr.hex()} decoded_pieces.append(piece) print(“原始文本:”, text) print(“Token IDs:”, tokens) print(“Token数量:”, len(tokens)) print(“Token片段:”, decoded_pieces) # 以对齐方式打印看得更清楚 for i, (tid, piece) in enumerate(zip(tokens, decoded_pieces)): print(f“{i:3d}: ID{tid:6d} - ‘{piece}‘”) # 测试中英文混合 visualize_tokens(“Hello世界 OpenAI‘s GPT-4 is impressive.”)运行上述代码你会清晰地看到每个空格可能被编码为▁、标点、英文单词、中文字符是如何被映射成Token的。这能帮你诊断问题例如是否因为一个关键术语被拆得太碎而影响了模型理解5.3 针对分词的提示工程技巧关键术语保护对于模型可能不熟悉的专业术语、产品名、人名可以在提示词中给出明确定义或拼写变体。例如“以下内容中‘Neuro-Symbolic AI’神经符号人工智能指的是一种结合神经网络与符号推理的技术…”数字处理如果需要模型进行精确计算将数字以文本形式如“一百二十三”而非数字形式“123”呈现有时效果更好或者明确要求模型“逐步推理”。对于编程任务数字格式影响较小。指令位置重要的指令尽量放在提示词的开头。一些研究表明尽管不是绝对模型对序列开头部分的注意力可能更高。避免将关键要求埋没在长篇背景文档的末尾。6. 进阶议题分词器的训练与选择如果你要从头开始预训练一个模型或者在一个非常特殊的领域如古生物文献、编程语言方言微调模型可能需要训练自己的分词器。使用SentencePiece训练分词器的简化流程准备语料收集大量、干净、代表目标领域的文本数据。配置训练参数主要参数包括vocab_size目标词表大小通常介于30k-100k之间。越大压缩率越高序列越短但模型嵌入层参数越多。model_typebpe默认或unigram。Unigram算法从一个大词表开始逐步裁剪在某些情况下效果更好。character_coverage对于包含生僻字的语言如日语可能需要提高到0.9995以上以确保覆盖。byte_fallback设置为true可以让分词器对未知字符回退到UTF-8字节表示极大提高鲁棒性。训练与评估训练后需要在验证集上评估分词质量例如计算平均句子长度Token数、检查常见词汇是否被合理合并。选择预训练分词器的考量领域匹配度如果你的领域是生物医学使用在通用网页文本上训练的分词器如GPT的可能不如使用PubMed论文训练的分词器高效。多语言支持如果需要处理多种语言应选择在多语言语料上训练的分词器如mBERT、XLM-R所用的。效率tiktoken用Rust编写速度极快。sentencepiece也高度优化。对于超大规模数据处理分词速度会成为瓶颈。7. 常见问题与排查清单在实际使用中你会遇到各种与分词相关的问题。下面这个清单可以帮助你快速定位问题现象可能原因排查步骤与解决方案API调用返回“上下文长度超限”错误输入文本Token数超过模型限制。1. 使用对应模型的编码器本地计算Token数。2. 压缩提示词删除冗余信息。3. 采用“分而治之”策略将长文本拆分后多次询问再综合。模型对拼写错误或生僻词反应异常该词被拆分成无意义的子词模型无法理解。1. 可视化出错词汇的分词结果。2. 在提示词中提供该词的正确拼写或同义词解释。3. 对于产品/项目名可考虑在微调时将其加入词表或作为特殊Token。生成的中文文本出现乱码或奇怪空格分词器对中文的处理不理想或解码时字节序列错误。1. 确认使用的分词器是否针对中文优化如使用sentencepiece的.model文件。2. 检查截断逻辑是否破坏了UTF-8字符边界。3. 尝试在提示词中明确要求“输出流畅、无乱码的中文”。相同的提示词在不同模型上效果差异巨大不同模型的分词器不同导致同一段文本被编码成完全不同的Token序列。1. 这是正常现象。2. 为每个模型单独优化提示词是必要的。3. 可以尝试将提示词的核心部分用更基础、通用的词汇表达。微调后模型性能下降微调数据的分词方式与预训练不一致或引入了大量未在预训练词表中的特殊Token。1. 确保微调时使用的分词器与原始模型完全一致。2. 谨慎添加新Token过多新Token会稀释原有嵌入表示。3. 检查微调数据中是否包含大量异常格式如HTML标签、乱码这些会被分成很多无意义Token。分词作为大语言模型流水线上静默的第一环其重要性怎么强调都不为过。它塑造了模型认知世界的“词汇量”和“语法直觉”。下次当你与ChatGPT对话时或者调用一个LLM API时不妨想想你输入的文字正在被如何切割、编码。理解这个过程不仅能帮你优化成本、规避陷阱更能让你以一种更本质的视角去理解这些强大模型的行为逻辑。从某种意义上说掌握了分词你就拿到了与模型在“元语言”层面沟通的钥匙。 大语言模型分词技术解析：从BPE算法到工程实践
1. 从“词”到“元”理解大语言模型的第一道工序如果你刚接触大语言模型LLM可能会被“Transformer架构”、“注意力机制”、“预训练”这些术语搞得晕头转向。但无论模型多么复杂它处理文本的第一步和我们人类阅读一样都是先“认字”。只不过模型认的不是我们眼中的“字”或“词”而是一种叫做“Token”的东西。这个过程就是Tokenization分词/标记化。今天我们就来深入聊聊这个看似基础实则深刻影响模型性能、成本乃至行为的关键环节。这不仅是斯坦福CS336等前沿课程的开篇也是每个想真正理解LLM的从业者必须跨过的第一道门槛。简单来说Tokenization就是把一段原始文本比如“Hello, world!”切割、转换成一系列模型能够理解和处理的数字ID的过程。这些切割后的最小单元就是Token。它远不止是“按空格切分”那么简单其背后的算法选择、词表构建直接决定了模型能认识哪些“概念”、处理效率如何甚至会产生哪些奇怪的“故障”。理解Tokenization你就能明白为什么模型有时会对一个简单的拼写错误束手无策为什么生成中文时偶尔会夹杂乱码以及如何更经济高效地使用API。接下来我将结合原理、实操和踩坑经验带你彻底搞懂它。2. 核心思路为什么“分词”是LLM的基石而非琐事在深度学习处理文本的早期常见的方法是字符级Character-level或单词级Word-level处理。字符级把每个字母、标点都当作一个Token词表很小几十到几百个但序列会变得极长模型难以捕捉语义。单词级以空格为分隔符语义单元清晰但词表会爆炸式增长动辄数十万还会遭遇“未登录词OOV”问题——遇到没见过的词就傻眼了。现代LLM采用的是一种折中且更聪明的方案子词分词Subword Tokenization。它的核心思想是将频繁出现的字符串作为一个整体Token而将不常见的长词拆分成更小的、可重复使用的子词单元。这就像我们背单词时会认识“un-”否定、“-able”能够这样的词根词缀然后用它们去理解“unbelievable”这类新词。这种方案带来了几个根本性优势解决OOV问题即使“ChatGPT”这个词没在训练中出现过只要词表里有“Chat”、“G”、“PT”这些子词模型就能组合出它。平衡效率与语义相比字符级序列长度更短计算更高效相比单词级词表大小可控通常在几万到十万量级减少了模型参数和内存占用。跨语言兼容性对于英语这类空格分隔的语言效果很好通过精心设计也能较好地适配中文、日文等非空格语言。目前主流的大模型如GPT系列、LLaMA系列大都基于BPEByte-Pair Encoding或其变种如GPT-2/3/4使用的BPESentencePiece库。因此理解BPE就成了理解现代LLM分词的关键。3. 算法深潜BPE是如何“学”出一个词表的BPE算法并不复杂但其设计非常巧妙。它从一个基础字符集开始通过迭代合并最高频的相邻符号对逐步构建出词表。下面我们通过一个极简的例子拆解它的训练过程。假设我们的训练语料只有三句话“low lower”“newest newest”“widest widest”第一步初始化基础词表首先我们将所有文本拆分成最基础的单元比如UTF-8字节或字符。这里我们用字符并在每个词末尾添加一个特殊的结束符/w来标记词边界这对后续合并很重要。 初始词汇表就是所有字符{‘l’, ‘o’, ‘w’, ‘e’, ‘r’, ‘n’, ‘s’, ‘t’, ‘i’, ‘d’, ‘/w’}。此时语料表示为l o w /w l o w e r /wn e w e s t /w n e w e s t /ww i d e s t /w w i d e s t /w第二步迭代合并统计所有相邻符号对的出现频率。第一次迭代中e和s出现了4次在“newest”和“widest”中频率最高。于是我们将es合并为一个新的符号单元。 现在词表变为{‘l’, ‘o’, ‘w’, ‘e’, ‘r’, ‘n’, ‘s’, ‘t’, ‘i’, ‘d’, ‘/w’, ‘es’}。语料更新为l o w /w l o w e r /wn e w es t /w n e w es t /ww i d es t /w w i d es t /w第三步持续合并重复这个过程。接下来es和t经常相邻出现4次合并为est。然后est和/w合并为est/w这意味着“est”经常作为一个词的结尾。再然后w和i合并为wiwi和d合并为wid最终wid和est/w合并为widest/w。经过多轮迭代我们可能会得到一个包含low/w,lower/w,newest/w,widest/w等完整单词以及est,es,wid等子词的词表。算法会在达到预设词表大小例如50,000时停止。关键理解BPE的词表是从数据中“学习”出来的它反映了训练语料的统计特征。高频词如“the”“ing”会作为整体保留低频长词则被拆解。这解释了为什么同一个模型用不同领域语料训练出的分词器其行为会有差异。3.1 BPE的实战变种与工具在实际应用中我们直接使用成熟库而非从头实现。最常用的是tiktoken(OpenAI) 和sentencepiece(Google)。tiktokenGPT系列模型的官方分词器。速度快与模型完全匹配。它有几个不同的编码器如cl100k_base(用于GPT-4 Turbo, ChatGPT)p50k_base(用于GPT-3系列)。使用起来非常简单import tiktoken enc tiktoken.get_encoding(“cl100k_base”) tokens enc.encode(“Hello, world! This is a test.”) print(tokens) # 输出一串数字ID print([enc.decode_single_token_bytes(t).decode(‘utf-8’, errors‘replace’) for t in tokens]) # 查看Token对应的原始字节sentencepiece支持BPE和Unigram算法不依赖空格进行预分词因此对中文、日文等语言更友好。LLaMA、T5等模型都使用它。import sentencepiece as spm sp spm.SentencePieceProcessor(model_file‘llama.model’) tokens sp.encode(“你好世界”, out_typestr) # 直接输出子词字符串 print(tokens) # 可能输出 [‘▁你’, ‘好’, ‘’, ‘▁世界’] (‘▁’代表空格)实操心得选择分词器时必须与你的目标模型严格匹配。用GPT的分词器去处理LLaMA的输入或者用自己的词表去加载预训练模型都会导致灾难性的后果——模型看到的全是乱码。这就像用英语词典去查中文句子一样荒谬。4. 影响与陷阱分词如何暗中支配模型行为理解了原理我们来看看分词在实际中引发的那些“坑”。这些往往是API调用成本异常、模型生成质量波动的元凶。4.1 Token与计费为什么我的API账单这么贵几乎所有云LLM API如OpenAI, Anthropic都按Token数量计费。这里的Token不是单词数。一个经验法则是英文中1个Token约等于0.75个单词中文中1个汉字约等于1.3-2个Token。这是因为中文常被拆分成更小的子词。示例对比输入“The quick brown fox jumps over the lazy dog.” (9个单词)Token化使用GPT-4编码器[“The”, “ quick”, “ brown”, “ fox”, “ jumps”, “ over”, “ the”, “ lazy”, “ dog”, “.”] -10个Tokens。基本符合0.75倍关系。输入“深度学习是人工智能的核心领域。” (13个汉字)Token化使用GPT-4编码器[“深”, “度”, “学”, “习”, “是”, “人工”, “智能”, “的”, “核心”, “领域”, “。”] -11个Tokens。平均每个汉字约0.85个Token但这个比例会随词频变化很大。像“人工智能”可能被合并为一个Token而“深度学习”可能被拆开。成本优化技巧精简提示词Prompt去除冗余的礼貌用语、不必要的解释。用更简洁的指令达到相同效果。使用系统消息在对话API中将相对固定的指令放在system角色中这部分内容通常在计费中权重较低或处理方式不同需查阅具体API文档。缓存重复内容如果多次请求中有相同的长文本如知识库文档可以考虑先将其编码为Token ID并缓存避免重复分词计算虽然API端可能已优化但客户端预处理也有意义。预估与监控在发送长文本前先用本地分词器如tiktoken估算Token数。大多数API有输入长度限制超限会直接失败。4.2 分词边界与模型“幻觉”分词器不认识词边界只认识统计规律。这会导致一些反直觉的现象拼写错误与鲁棒性用户输入“acommodation”少一个‘c’。如果词表里有“accommodation”作为一个整体Token那么模型完全无法理解这个错词因为它会被拆分成像[“a”, “com”, “mod”, “ation”]这样奇怪的子词语义完全丢失。模型可能因此开始胡言乱语。相比之下字符级模型对拼写错误更鲁棒。数字处理难题“123,456”这个数字可能被分词为[“123”, “,”, “456”]。当要求模型进行算术运算时它需要先理解这三个Token组合起来是一个数字这增加了任务的难度。这也是为什么早期LLM数学能力普遍较弱的原因之一。跨语言混编问题在中文中夹杂英文单词如“我用了GitHub”。分词器可能将“GitHub”作为一个整体Token如果它在词表中也可能拆成“Git”和“Hub”。如果拆分了模型可能无法准确识别这是一个专有名词。4.3 中文分词的独特挑战英文有天然空格分隔BPE效果很好。中文是连续书写没有空格因此需要额外的预分词步骤或者使用像SentencePiece这样不依赖空格的分词器。常见策略是在BPE之前先用一个基础的中文分词器如jieba将句子切分成词再对词序列应用BPE。风险是基础分词器的错误会传导给LLM。直接对汉字序列或UTF-8字节序列应用BPE/SentencePiece。这是目前更主流的方法但可能导致一个汉字被拆成多个字节Token尤其在UTF-8下效率降低。中文分词的一个典型现象同一个词在不同上下文可能被分成不同的样子。例如“机器学习”可能在高频语料中被合并为一个Token但在某个专业子领域中可能被保持为“机器”和“学习”两个Token。这要求我们在设计针对中文的提示词时对关键术语要保持一致。5. 实操指南如何与分词器正确打交道5.1 估算与截断处理长文本的必备技能LLM有上下文窗口限制如4K, 8K, 128K Tokens。你需要确保输入输出的Token总数不超过这个限制。import tiktoken def truncate_text_by_tokens(text, model_name, max_tokens): “””根据特定模型的分词器截断文本。””” try: encoding tiktoken.encoding_for_model(model_name) except KeyError: print(f“Warning: Model {model_name} not found. Using cl100k_base as default.”) encoding tiktoken.get_encoding(“cl100k_base”) tokens encoding.encode(text) if len(tokens) max_tokens: tokens tokens[:max_tokens] truncated_text encoding.decode(tokens) # 注意直接decode可能在不完整的UTF-8边界截断导致末尾乱码 # 更安全的方法是尝试解码如果出错则逐步回退Token直到解码成功 try: truncated_text encoding.decode(tokens) except UnicodeDecodeError: for i in range(1, len(tokens)): try: truncated_text encoding.decode(tokens[:-i]) break except UnicodeDecodeError: continue print(f“Text truncated from {len(tokens) (len(tokens)max_tokens? i:0)} to {max_tokens} tokens.”) return truncated_text else: return text # 使用示例 long_text “…” # 你的长文本 model “gpt-4” max_input_tokens 8000 # 假设模型输入限制为8000 processed_text truncate_text_by_tokens(long_text, model, max_input_tokens)重要提示截断时直接在Token序列层面截断再解码回文本可能会在某个多字节字符的中间截断导致末尾出现乱码如。上述代码提供了一个简单的回退机制但更健壮的做法是预留一部分Token余量或者确保在句子边界、段落边界处截断。5.2 调试与可视化看清模型“眼中”的世界当你怀疑模型因为分词问题而表现不佳时可视化分词结果至关重要。def visualize_tokens(text, encoder_name‘cl100k_base’): encoding tiktoken.get_encoding(encoder_name) tokens encoding.encode(text) decoded_pieces [] for token_id in tokens: # 将Token ID解码回原始的字节再尝试转换为字符串 bytes_repr encoding.decode_single_token_bytes(token_id) try: # 对于可打印字符显示字符串 piece bytes_repr.decode(‘utf-8’) # 对空格等不可见字符进行转义便于观察 piece piece.replace(‘ ‘, ‘▁‘) except UnicodeDecodeError: # 对于无效字节如被截断的显示十六进制 piece f0x{bytes_repr.hex()} decoded_pieces.append(piece) print(“原始文本:”, text) print(“Token IDs:”, tokens) print(“Token数量:”, len(tokens)) print(“Token片段:”, decoded_pieces) # 以对齐方式打印看得更清楚 for i, (tid, piece) in enumerate(zip(tokens, decoded_pieces)): print(f“{i:3d}: ID{tid:6d} - ‘{piece}‘”) # 测试中英文混合 visualize_tokens(“Hello世界 OpenAI‘s GPT-4 is impressive.”)运行上述代码你会清晰地看到每个空格可能被编码为▁、标点、英文单词、中文字符是如何被映射成Token的。这能帮你诊断问题例如是否因为一个关键术语被拆得太碎而影响了模型理解5.3 针对分词的提示工程技巧关键术语保护对于模型可能不熟悉的专业术语、产品名、人名可以在提示词中给出明确定义或拼写变体。例如“以下内容中‘Neuro-Symbolic AI’神经符号人工智能指的是一种结合神经网络与符号推理的技术…”数字处理如果需要模型进行精确计算将数字以文本形式如“一百二十三”而非数字形式“123”呈现有时效果更好或者明确要求模型“逐步推理”。对于编程任务数字格式影响较小。指令位置重要的指令尽量放在提示词的开头。一些研究表明尽管不是绝对模型对序列开头部分的注意力可能更高。避免将关键要求埋没在长篇背景文档的末尾。6. 进阶议题分词器的训练与选择如果你要从头开始预训练一个模型或者在一个非常特殊的领域如古生物文献、编程语言方言微调模型可能需要训练自己的分词器。使用SentencePiece训练分词器的简化流程准备语料收集大量、干净、代表目标领域的文本数据。配置训练参数主要参数包括vocab_size目标词表大小通常介于30k-100k之间。越大压缩率越高序列越短但模型嵌入层参数越多。model_typebpe默认或unigram。Unigram算法从一个大词表开始逐步裁剪在某些情况下效果更好。character_coverage对于包含生僻字的语言如日语可能需要提高到0.9995以上以确保覆盖。byte_fallback设置为true可以让分词器对未知字符回退到UTF-8字节表示极大提高鲁棒性。训练与评估训练后需要在验证集上评估分词质量例如计算平均句子长度Token数、检查常见词汇是否被合理合并。选择预训练分词器的考量领域匹配度如果你的领域是生物医学使用在通用网页文本上训练的分词器如GPT的可能不如使用PubMed论文训练的分词器高效。多语言支持如果需要处理多种语言应选择在多语言语料上训练的分词器如mBERT、XLM-R所用的。效率tiktoken用Rust编写速度极快。sentencepiece也高度优化。对于超大规模数据处理分词速度会成为瓶颈。7. 常见问题与排查清单在实际使用中你会遇到各种与分词相关的问题。下面这个清单可以帮助你快速定位问题现象可能原因排查步骤与解决方案API调用返回“上下文长度超限”错误输入文本Token数超过模型限制。1. 使用对应模型的编码器本地计算Token数。2. 压缩提示词删除冗余信息。3. 采用“分而治之”策略将长文本拆分后多次询问再综合。模型对拼写错误或生僻词反应异常该词被拆分成无意义的子词模型无法理解。1. 可视化出错词汇的分词结果。2. 在提示词中提供该词的正确拼写或同义词解释。3. 对于产品/项目名可考虑在微调时将其加入词表或作为特殊Token。生成的中文文本出现乱码或奇怪空格分词器对中文的处理不理想或解码时字节序列错误。1. 确认使用的分词器是否针对中文优化如使用sentencepiece的.model文件。2. 检查截断逻辑是否破坏了UTF-8字符边界。3. 尝试在提示词中明确要求“输出流畅、无乱码的中文”。相同的提示词在不同模型上效果差异巨大不同模型的分词器不同导致同一段文本被编码成完全不同的Token序列。1. 这是正常现象。2. 为每个模型单独优化提示词是必要的。3. 可以尝试将提示词的核心部分用更基础、通用的词汇表达。微调后模型性能下降微调数据的分词方式与预训练不一致或引入了大量未在预训练词表中的特殊Token。1. 确保微调时使用的分词器与原始模型完全一致。2. 谨慎添加新Token过多新Token会稀释原有嵌入表示。3. 检查微调数据中是否包含大量异常格式如HTML标签、乱码这些会被分成很多无意义Token。分词作为大语言模型流水线上静默的第一环其重要性怎么强调都不为过。它塑造了模型认知世界的“词汇量”和“语法直觉”。下次当你与ChatGPT对话时或者调用一个LLM API时不妨想想你输入的文字正在被如何切割、编码。理解这个过程不仅能帮你优化成本、规避陷阱更能让你以一种更本质的视角去理解这些强大模型的行为逻辑。从某种意义上说掌握了分词你就拿到了与模型在“元语言”层面沟通的钥匙。