提示词模板不一致问题

[ZeyuTeng96]

官方在readme上给出的提示词模板，和调用openai api、web ui得到的结果存在不一致性：

readme上给出的提示词模板：https://github.com/THUDM/ChatGLM3/blob/main/PROMPT.md#%E6%95%B4%E4%BD%93%E7%BB%93%E6%9E%84

调用openai api、web ui时，历史对话和当前用户的输入通过'build_chat_input'方法来编码：
对于下述对话：
User -> 你好
Chatglm3 -> 你好👋！我是ChatGLM3，很高兴见到你，欢迎问我任何问题。
User -> 你是谁

input_ids为：
[64790, 64792, 64794, 30910, 13, 809, 383, 22011, 10461, 30944,
30966, 30932, 260, 1796, 3239, 2092, 7594, 422, 1192, 899,
30923, 30930, 23833, 30930, 5741, 267, 2795, 30953, 30917, 8417,
7724, 30930, 21911, 1227, 3478, 3536, 30930, 64795, 30910, 13,
36474, 54591, 64796, 30910, 13, 36474, 54591, 243, 162, 148,
142, 31404, 33030, 30942, 1960, 10461, 30944, 30966, 31123, 48895,
35214, 54622, 31123, 32616, 39905, 31901, 31639, 31155, 64795, 30910,
13, 30910, 34607, 55622, 64796]

如果用tokenizer进行解码，解码结果为：
[gMASK]sop<|system|> \n You are ChatGLM3, a large language model trained by Zhipu.AI. Follow the user's instructions carefully. Respond using markdown.<|user|> \n 你好<|assistant|> \n 你好👋！我是ChatGLM3，很高兴见到你，欢迎问我任何问题。<|user|> \n 你是谁<|assistant|>

readme上的提示词模板是不论special tokens，还是text都会跟着一个'\n'，但是代码实现上却没有。同时，对于special tokens和真正对话之间的seperator，也进行了单独的encode过程。

请问到底哪个输入构建的方式是合理的？

麻烦大佬指点@duzx16

[Btlmd]

整体结构 中给出的模板有些误导性，tokenizer 中的实现是正确的。角色 special token 前无需额外添加换行符。

[infwinston]

Hey @Btlmd 能否幫我們看一下哪一個實現是正確的，我們很希望能支持 ChatGLM3！
lm-sys/FastChat#2620
lm-sys/FastChat#2622

[ZeyuTeng96]

Hey @Btlmd 能否幫我們看一下哪一個實現是正確的，我們很希望能支持 ChatGLM3！ lm-sys/FastChat#2620 [lm-sys/FastChat#2622](https://github.com/lm-sys/FastChat/pu

整体结构 中给出的模板有些误导性，tokenizer 中的实现是正确的。角色 special token 前无需额外添加换行符。

还有另外一个问题是，为什么需要将{metadata}\n 和 conv text (交流中的对话) 分别作encoding呢，这样引入了多个“ ” @Btlmd

[ZeyuTeng96]

Hey @Btlmd 能否幫我們看一下哪一個實現是正確的，我們很希望能支持 ChatGLM3！ lm-sys/FastChat#2620 lm-sys/FastChat#2622

感觉需要引入tokenizer 来实现和官方推理方式的对齐了 @infwinston

[Btlmd]

出于防注入考虑，目前给出的 tokenizer 不支持将字符串直接编码为带有角色 special token 的 input_ids。
如果基于目前的 tokenizer 处理，参考 build_chat_input 进行拼接才能完成正确的转换。

[ZeyuTeng96]

出于防注入考虑，目前给出的 tokenizer 不支持将字符串直接编码为带有角色 special token 的 input_ids。 如果基于目前的 tokenizer 处理，参考 build_chat_input 进行拼接才能完成正确的转换。

还有另外一个问题是，为什么需要将{metadata}\n 和 conv text (交流中的对话) 分别作encoding呢，这样引入了多个“ ” @Btlmd

[Btlmd]

分别 encode 后 metadata 和 content 彻底解耦，这样做可能是考虑在训练时控制 loss mask 比较方便。

[ZeyuTeng96]

分别 encode 后 metadata 和 content 彻底解耦，这样做可能是考虑在训练时控制 loss mask 比较方便。

请问模型不是都是必须要去预测metadata 和 content嘛，具体是怎么更方便控制loss mask了呢？如果都需要预测的话，都是take loss的

[Btlmd]

当前应用场景中确实不大会用到两者计算 loss 情形不同的情况，这种设计可能是为 metadata 和 content 的 loss 计算情形不同的场景设计的。

[ZeyuTeng96]

当前应用场景中确实不大会用到两者计算 loss 情形不同的情况，这种设计可能是为 metadata 和 content 的 loss 计算情形不同的场景设计的。

谢谢您