微调数据中的 System Prompt 为什么要保持一致？
简化版
System Prompt 定义模型角色、能力边界和输出约束。训练数据中如果同一系统指令对应互相冲突的行为，或训练时有完整 System Prompt、上线时却换成另一套模板，模型会学到不稳定条件映射，表现为角色漂移、格式失败和安全边界混乱。
“保持一致”不是每条都必须逐字相同，而是语义规则、优先级和序列化协议一致。允许多个角色时，应显式区分场景并覆盖相应数据；固定产品规则可使用版本化模板，部署端必须使用训练兼容的 Chat Template。
真正要一致的是“条件—目标行为”映射：相同规则不能教出冲突答案，不同规则必须有可辨认的条件。
详细版
模型学习条件概率：
pθ(assistant_tokens | system, conversation, tool_state)如果相同 system=S 和相似用户请求，在数据中一半要求 JSON、一半要求自由文本，交叉熵会把两种模式同时当正确，推理时输出容易随机漂移。
| 数据状态 | 结果 |
|---|---|
| System 语义稳定、答案一致 | 条件映射清晰 |
| System 相同、答案规则冲突 | 学习噪声、行为不稳定 |
| System 不同但未显式区分 | 模型无法判断场景 |
| 训练/服务模板不同 | Token 分布偏移 |
| 永远只有一个固定 System | 该场景稳，但换角色泛化弱 |
完整版教学
1. System Prompt 在 SFT 中扮演什么角色
它不是训练外的附加说明，而是输入 Token 的一部分。模型通过监督学习建立 System 条件与 Assistant 输出之间的关联。
训练时忽略它、上线却依赖它实现全部控制，通常会导致边界不稳。
2. 一致性不等于逐字相同
可以有多个合法 System Prompt，例如客服、代码助手和摘要器；关键是每个版本的角色、工具和输出要求明确，且样本能区分。
同义措辞可增强鲁棒性，但不能改变核心政策和优先级。
工程上可把 System Prompt 拆成稳定约束与变量槽位：稳定部分定义安全边界和优先级，变量部分承载角色、地区或租户配置。数据增强只能改写表达，不能偷偷改变槽位含义，否则模型学到的是互相冲突的条件分布。
3. 什么是语义冲突
同一场景一条要求“必须引用来源”，另一条参考答案没有引用；一条允许退款，另一条同条件拒绝。模型无法从输入解释差异。
应把地区、政策版本、权限等决定因素显式放入上下文，而不是保留矛盾标签。
4. Chat Template 为什么与 System 一起治理
角色 Token、消息结束符、换行和 Generation Prompt 决定模型实际看到的序列。同一文本用不同模板编码可能完全不同。
<bos><system>S<eot><user>U<eot><assistant>A<eot>训练和服务要对结构化消息生成相同 Token IDs。
5. 固定 System Prompt 有什么利弊
固定模板减少条件方差，适合单一产品；但模型可能把固定文字当背景忽略，对 Prompt 变体或缺失非常脆弱。
| 策略 | 优点 | 风险 |
|---|---|---|
| 完全固定 | 稳定、易部署 | 换模板泛化差 |
| 受控改写 | 提升措辞鲁棒性 | 改写可能引入语义漂移 |
| 多角色显式标识 | 支持多产品 | 数据配比与路由复杂 |
6. 如何生成安全的模板变体
先把不变量结构化，例如角色、允许工具、禁止行为和输出 Schema，再只改写表述。使用规则或人工验证变体仍包含全部不变量。
模板增强的目标是对等价表达鲁棒，不是让模型在互相矛盾的政策之间“自行理解”。
7. System Prompt 是否应该计入 Loss
Decoder-only SFT 通常把 System/User Token 标签设为 -100，只对 Assistant 输出计算 Loss；但它们仍参与 Attention，作为条件影响预测。
若错误地对 System 文本计 Loss，模型可能学习复述系统指令；若 Assistant 起止 Token 全被 Mask，又可能学不会协议边界。
8. 多轮对话如何保持规则稳定
System 通常只在会话开头出现，后续所有轮次共享。Packing 或截断不能把 System 切掉却保留后续 Assistant 答案。
长会话裁剪时可保留 System 和最近相关轮次，或重新构造合法上下文；不能产生没有规则来源的监督样本。
9. 工具协议冲突会怎样
System 可能声明允许的工具与参数约束。如果训练答案调用未声明工具、伪造结果或跳过确认，模型会学习越权行为。
用状态机验证每条 Trace：工具是否存在、参数合法、调用结果来自真实 Tool Role、最终陈述与状态一致。
10. 安全策略版本如何处理
政策变化时在数据中标注版本和生效范围，避免把旧新规则无条件混合。线上 System Prompt 也带相同版本或由数据上下文决定。
旧数据可重标、退役或只用于历史回归，不能让模型猜哪个版本有效。
11. 如何检测一致性问题
对 System Prompt 做语义聚类，检查同簇下答案格式、政策决策和工具权限的分布。寻找相同输入条件却标签相反的对。
自动规则发现候选，领域专家判断是真冲突还是缺少条件字段。
12. 上线前如何做模板契约测试
保存黄金结构化消息与 Token IDs，训练脚本、离线评测和服务端分别序列化并比较。测试有/无 System、多轮、Tool、空消息和长截断。
再在模板轻微改写、额外空格等情况下做鲁棒性测试，明确哪些变化受支持。
13. System Prompt 是否能被微调“写进权重”
模型可内化稳定风格和行为，但运行时规则、权限和时效政策仍应显式提供并由外部系统强制执行。
把所有策略写进权重难以更新、审计和按租户区分，也不能替代工具权限。
适合内化的是长期稳定的语气、回答结构和通用工作习惯；不适合内化的是价格、法规、授权范围等频繁变化的规则。后者必须在运行时注入，并由策略引擎或工具层做确定性校验。
14. 常见误区与追问
- 误区：一致性就是每条 System 文本完全相同。 可以受控多样，但语义规则与条件必须清晰。
- 误区：System 不计 Loss，所以内容不重要。 它仍作为条件参与所有 Assistant Token 预测。
- 误区：微调后上线可以换任意 Chat Template。 Token 协议变化会造成分布偏移。
- 误区：冲突政策混在一起能增强模型判断。 缺少显式条件只会形成标签噪声。
- 误区：权重学会安全规则后无需外部权限。 软行为不能替代工具网关和授权。
- 追问：多租户不同 System 怎么训练？ 显式租户/角色条件、平衡数据，并分别做策略隔离评测。
- 追问：政策更新如何避免冲突？ 版本化条件、重标旧数据，并同步模板和回归集。
15. 加强记忆
- System 是训练条件，不是装饰文本。
- 一致的是语义规则与行为映射，不要求逐字相同。
- 模板协议必须对齐：角色 Token、结束符、顺序和 Loss Mask。
- 冲突要补条件或重标，不能让模型猜政策版本。
- 权重学行为，外部系统管权限和时效规则。