ChatGLM4 的 tokenizer 配置文件解析

tokenizer_config.json是 ChatGLM-4 的"对话协议 + Token 体系 + 工具调用模板"定义文件

一、auto_map------ 自动加载 Tokenizer

"auto_map": {
  "AutoTokenizer": [
    "tokenization_chatglm.ChatGLM4Tokenizer",
    null
  ]
}

告诉 HuggingFace：当你调用 AutoTokenizer.from_pretrained() 时，用 ChatGLM4Tokenizer

二、added_tokens_decoder ------ 特殊 Token 定义（极重要）

2.1、added_tokens_decoder结构解析

|-----------------|----------------------|
| content | Token 对应的字符串表现形式 |
| lstrip | 左侧是否自动去空格 |
| rstrip | 右侧是否自动去空格 |
| normalized | 是否参与文本规范化 |
| single_word | 是否只能作为"独立词"出现 |
| normalized | 是否参与文本规范化 |
| special | 是否是特殊控制的Token |

2.2、不同content结构解析

|-------------------------|-------------------------------------------|
| <|endoftext|> | 1、EOS（生成停止）2、PAD（batch 填充） |
| [MASK] | 掩码 |
| [gMASK] | 是ChatGLM的生成起点锚点，用于上下文 |
| [sMASK] | 是ChatGLM的生成起点锚点，用于补全文本 |
| <sop> | Prompt 正式开始，后面所有内容都算"上下文" |
| <|system|> | 定义模型身份，回答模型会以你指定的身份回答问题 |
| <|user|> | 明确这是用户提问，即我们向模型提出的问题 |
| <|assistant|> | 模型开始生成答案 |
| <|observation|> | 工具 / 设备 / 接口返回的"客观事实"模型不会质疑，只会基于它继续推理 |
| <eop> | 标记一次完整推理结束，防止模型继续"幻觉生成"，但可以继续对话 |

不理解MASK的可以我的另一篇文章，看看Transformer是如何mask的，他们的机理是一样的。
https://blog.csdn.net/weixin_42715977/article/details/124151870?fromshare=blogdetail&sharetype=blogdetail&sharerId=124151870&sharerefer=PC&sharesource=weixin_42715977&sharefrom=from_link

2.3、gMASK和sMASK区别解析

对比项	[sMASK]	[gMASK]
掩码范围	一段（局部）	整段（全局）
常见用途	补全文本	对话生成
是否常用于 Chat	❌ 少	✅ 多
是否适合 QA	⚠️ 一般	✅

gMASK：我给你全部上下文，你生成完整回复。

sMASK：空一段，让你补充。用于文本补全、句子续写和标准补全任务。

三、additional_special_tokens

"additional_special_tokens": [
  "<|endoftext|>",
  "[MASK]",
  "[gMASK]",
  "[sMASK]",
  "<sop>",
  "<eop>",
  "<|system|>",
  "<|user|>",
  "<|assistant|>",
  "<|observation|>",
  "<|begin_of_image|>",
  "<|end_of_image|>",
  "<|begin_of_video|>",
  "<|end_of_video|>"
]

告诉 tokenizer：这些 token 是"不可拆分的整体"

否则 tokenizer 可能把 <|assistant|> 拆成 < | assist ant | >

四、剩余参数

4.1、clean_up_tokenization_spaces

去掉多余空格，当微调时，还是应采用Flase，保留完整的结构化。

！！！注意：该参数的作用阶段为解码阶段，decode（token → 文本），是否将生成的文本进行去空格，使你看到的更为舒服。

4.2、do_lower_case

强制小写，微调是，还是应采用Flase

4.3、eos_token

整个对话样本结束，注意区分他和eop的区别

|---------------------------|---------------------------|
| eop | eos |
| 本轮回答结束，但对话还活着 | 整个对话样本结束 |
| 可以继续下一轮（用户再问 / 工具再调用） | 推理/生成器直接 stop，不能再继续对话 |

用"状态机"来解释

[生成中] → [本轮结束] → [整体结束]

状态变化	触发 token
生成 → 等下一轮	<eop>
任意 → 强制结束	eos_token

4.4、pad_token

用于将不同长度的序列填充到相同的长度，以便它们可以被批处理。

4.5、padding_side": "left"

左填充，从左侧开始填充，将句子补齐。

4.6、model_max_length

最大的处理的token数量。

4.7、remove_space

同样也是去空格，但是作用阶段和clean_up_tokenization_spaces完全相反，

作用于分词编码阶段，encode（文本 → token）

4.8、tokenizer_class

指定了模型对应的 分词器（Tokenizer）类，也就是告诉框架该用哪个 Python 类来处理文本的 分词、编码、解码、特殊 token 管理。

"tokenizer_class": "ChatGLM4Tokenizer"

• 编码文本 ：会自动处理 <sop>， <eop>，[gMASK]，[sMASK] 等特殊 token

• 解码 token：能正确生成含特殊 token 的文本

• 配合 LoRA / PEFT：保证训练/微调时 token ID 对齐