从 chat 接口内部调用 generate 接口的处理逻辑看，使用上述拼接方式生成的 input_ids 不符合你们对于特殊符（如<|user|>、<|assistant|>）的 id 定义，这部分是否只是为了兼容通用的 generate 接口？且存在对模型性能的损失？

[Tesla-jiang]

          从 chat 接口内部调用 generate 接口的处理逻辑看，使用上述拼接方式生成的 input_ids 不符合你们对于特殊符（如<|user|>、<|assistant|>）的 id 定义，这部分是否只是为了兼容通用的 generate 接口？且存在对模型性能的损失？

Originally posted by @Tesla-jiang in https://github.com/THUDM/ChatGLM3/issues/1238#issuecomment-2144113809

[zRzRzRzRzRzRzR]

这个是我们训练的时候用的special token，模板是这样，所以对话需要使用这种模板 chat方案出来的编码是能对上的呀

在glm-4仓库中我们做了一个对齐apply_chat_template的版本

[Tesla-jiang]

谢谢你的回答哈，我理解您的意思是<|user|>\n讲个故事\n<|assistant|>是底座 chatglm3-6b-base 模型的训练模板，原始对话数据与 special token（<|user|>、<|assistant|>） 拼接后一次性进入 tokenizer 分词后进行训练；现有的 chat 接口对多轮对话数据的语句挨个 tokenizer 分词后再与 special token id 进行 id 拼接 的处理逻辑只是为了方便多轮交互？ 我纠结的点其实是多轮对话数据拼接成这样 <|user|>\n讲个故事\n<|assistant|> 一次性进行 tokenizer 并送入 genrate 接口得到的结果和 chat 接口中分别 tokenizer 再进行id 拼接得到的结果似乎不太一致，不确定我这样操作是否合理，多有打扰，实在抱歉。

另我看到了你们新上线的 THUDM/glm-4-9b-chat，这个是 chatGLM3 的迭代版本么？或者是功能相同，但底层路线有很大差异的模型才在命名上做出区别？ 我也看到了 glm-4-9b-chat 里的 apply_chat_template 方法，我会先仔细研究下，谢谢您的回答和指导哈，祝心情愉悦，笑口常开，手动笔芯

[zRzRzRzRzRzRzR]

是GLM3 的迭代，技术路线是相同的， 关于你提到的模板。 预训练模型不存在模板一说，模板是chat模型才有的哦。 也就是在微调的时候，如果微调chat模型，才要求严格根据模板的。