什么是 分词器（Tokenizer）？
更新于
分词器（Tokenizer）是按照特定词表与配置，把文本或结构化消息转换为模型可处理的 Token ID，并把生成 ID 解码回文本的模型配套流水线。
快速了解
| 规范文档 | 官方规范 |
|---|
工作原理
流水线包含职责不同的阶段
Normalization 可以规范 Unicode 或空白，Pre-tokenization 建立候选边界，Model 阶段应用 BPE、WordPiece、Unigram、Byte-level 或其他学习词表，Post-processing 插入必要控制 Token，Decode 再将 ID 转回文本。具体实现并不相同，有些还会保留字节或 Offset，使未登录文本仍可表示并能对齐原文。
词表与合并规则属于模型状态
BPE 学习有优先级的字符对合并，WordPiece 按自身训练目标选择词表片段，Unigram 从候选集合出发再裁剪概率词表。这些算法名称不代表 ID 兼容。分词器必须匹配 Model Checkpoint，包括特殊 Token ID 与扩展词表，否则熟悉的文本也可能进入模型从未按该含义训练过的 Embedding。
聊天模板会改变编码后的请求
Chat API 会先通过模型专用模板把角色、消息、工具定义与 Generation Prompt 序列化，或让模板逻辑与编码阶段协同工作。手工拼接消息可能漏掉必要标记，也可能重复插入。Token 计数、截断、缓存和回归测试都应复用推理链路的同一模板，而不是孤立编码消息正文。
生产使用需要可复现与分片测试
分词器文件和版本应与模型一同固定，并用已知 Text-to-ID Fixture 验证升级前后行为。多语言、代码、标识符、数字、空白、异常 Unicode 与领域术语都要单独审计，因为英文平均值会掩盖高成本切分。RAG 还应统计完整格式化后的 Chunk 与 Query，保留引用 Offset，并验证截断不会删除必要证据。
主要特点
- 组合规范化、初步切分、词表模型、后处理与解码阶段
- 生成的整数 ID 只对特定词表与 Model Checkpoint 有意义
- 可以采用 BPE、WordPiece、Unigram、字节级、字符级或混合切分
- 处理特殊控制 Token，并通常与模型专用 Chat Template 协同
- 可保留字符或字节 Offset，支持对齐、高亮与引用链路
- 必须跨多语言、代码和结构化输入进行版本化与回归测试
常见用途
- 为部署中的语言模型生成准确输入 ID 与 Token 数
- 发现聊天模板、工具 Schema 和检索内容序列化后的上下文溢出
- 使用真实领域文本评估多语言模型，而不是套用英文平均比例
- 构建受 Token 上限约束且能保留来源 Offset 的 RAG 分块
- 固定模型服务产物，并在升级时检测分词器行为漂移
示例
Loading code...常见问题
LLM 分词器可能包含哪些阶段？
分词器可以先规范化输入并建立初步边界，再应用学习得到的词表模型、把片段转换为 ID，并在后处理阶段加入特殊 Token。解码会在表示允许的范围内把 ID 恢复为文本。阶段顺序与行为属于具体配置，不是所有分词器共有的固定属性。
BPE、WordPiece 和 Unigram 分词器有什么区别？
BPE 学习相邻符号的有序合并；WordPiece 使用自己的评分目标构建词表，并常按最长匹配规则切分；Unigram 从大量候选片段出发，按概率目标逐步裁剪。实际实现还会加入规范化和字节处理，因此只知道算法家族并不能推导 Token 数或 ID。
为什么分词器必须匹配 Model Checkpoint？
Embedding 矩阵的每一行都是围绕特定 Token ID 训练的。如果换用另一词表，同一 ID 可能指向不同片段，即使输入文本看起来正确，模型也会收到错误含义的 Embedding。特殊 Token、扩展词表、规范化文件、合并规则和 Chat Template 都应与 Checkpoint 一同固定。
逐个解码 Token 是否等同于解码完整序列？
不一定。一个 Token 可能只包含部分 UTF-8 字节，也可能依赖相邻片段、规范化或 Cleanup 规则才能正确显示。面向用户的文本应解码完整序列；分析边界时应使用字节安全 API 或 Offset Mapping，不能假设每个独立 ID 都对应有效单字符字符串。
分词器上线前应该如何测试？
固定版本，并保存预期 ID、特殊 Token 插入、Round Trip、Offset 与聊天序列化 Fixture。测试目标语言、代码、数字、空白、领域术语、异常输入、长请求和截断方向；再比较本地估算与服务端 Usage，模型与分词器组合出现意外漂移时应阻止发布。