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 对齐