改进并修复的 GPT-OSS 模板（再次）。包含 preserve_thinking 和针对 Unsloth 引发的 bug 的修复

我几个月前发布了一个更新的 GPT-OSS 模板，基于 Unsloth 的版本。结果发现 Unsloth 的版本（以及因此我的版本）中存在一个非常严重的 bug。当聊天历史被重播并包含之前的推理（即分析通道）回合时，这个 bug 会导致模型性能下降。据我所知，现在许多工具默认保留历史记录，并且这肯定可以在 API 层面发生——工具可以整合推理和答案。您能否在这个代码片段中发现问题？（取自 Unsloth 的模板）： jinja {%- elif "thinking" in message %} {#- CoT is dropped during all previous turns, so we never render it for inference #} {{- "<|start|>assistant<|channel|>analysis<|message|>" + message.thinking + "<|end|>" }} {%- set last_tool_call.name = none %} {%- else %} {#- CoT is dropped during all previous turns, so we never render it for inference #} {{- "<|start|>assistant<|channel|>final<|message|>" + message.content + "<|end|>" }} {%- set last_tool_call.name = none %} 当渲染聊天历史时，如果一条消息同时包含内容（模型的答案）和思考（推理），则只有推理部分被渲染给模型，而答案本身被丢弃！这会在多轮对话中显著地混淆模型。注释也是错误的——整个分支看起来像是复制粘贴错误。OpenAI 的参考模板中没有这个。我注意到在某些情况下，GPT-OSS 20B 可能会完全偏离轨道，现在我明白原因了。有趣的是，GPT-OSS 120B 似乎足够聪明，仅使用推理痕迹就能恢复对话的上下文和方向。经过这次经历，我也在我的模板中实现了 preserve_thinking，因为模型处理得很好，不会失去连贯性。这应该会通过前缀缓存使多轮推理在测试框架中更快，但代价是更高的 token 使用量。所以，这就是了：https://huggingface.co/arbv/gpt-oss-fixed-jinja-template 如果您无聊的话，可以给 GPT-OSS 一个第二次机会。这是在修复 Laguna XS/S 2.1 的模板时偶然发现的，但更多内容改天再说。P.S. 正在邀请 u/danielhanchen 也来看看。