真实面经题目 · 原创解析
这题考的是多轮 SFT 的 token 级训练目标设计：候选人要能说明 system/user/padding 通常不算 loss，assistant 答案 token 通常算 loss，并进一步讲清多轮全部 assistant turn、last-turn-only、label shift、packing 边界和模板一致性。
多轮 Instruction Tuning 的 loss mask 核心原则是：模型应该学习在给定 system、历史 user 和历史 assistant 上下文后，生成 assistant 的回复，而不是学习复读用户输入或系统提示。具体实现上，tokenizer 按 chat template 拼出完整序列后，labels 通常从 input_ids 拷贝一份，再把不参与训练的 token 置为 -100，例如 system prompt、user 消息、角色分隔符中不希望模型学习的部分、padding、跨样本 packing 的边界 token 等；assistant 回复正文以及必要的 assistant 结束符通常保留 label，让 causal LM 在 label shift 后预测这些目标 token。多轮数据有两种常见策略：一种是 all-assistant-turns，把每一轮 assistant 回复都纳入 loss，适合充分利用多轮监督；另一种是 last-turn-only，只训练最后一轮答案，适合样本前文包含噪声、历史 assistant 质量不一致或任务只关心最终回复的场景。无论哪种，都要保证 attention mask 允许当前位置看见左侧上下文，但 loss mask 只控制哪些位置贡献损失。还要特别检查模板和推理一致、结束符是否参与学习、packing 后样本之间不能互相 attention、截断不能截掉关键答案尾部。最后用可视化或单样本单步检查 labels，确认 user token 全是 -100、assistant token 对齐正确，否则训练 loss 再正常也可能学出复读用户、角色错乱或多轮能力差。
attention mask 控制 token 能看到哪些上下文，loss mask 控制哪些 token 对训练损失有贡献。多轮 SFT 里，assistant 回复需要看见 system、user 和历史对话，但 system/user token 本身通常不应该作为预测目标。混淆这两种 mask 会导致模型要么看不到上下文，要么被训练去复读输入。
最常见做法是只对 assistant 需要生成的内容计算 loss。system prompt、用户问题、角色标记、padding 和样本间分隔 token 通常置为 -100；assistant 回复正文以及必要的 eos 或 stop token 保留 label。这样训练目标与推理场景一致：给定上下文，生成下一段 assistant 回复。
all-assistant-turns 策略会让每一轮 assistant 回复都参与 loss。优点是充分利用多轮样本中的监督信号，模型学习在不同历史长度下回复；缺点是如果早期 assistant 回复质量不稳定、风格不一致或包含系统不想继承的错误，会把噪声也学进去。
last-turn-only 只让最后一轮 assistant 回复参与 loss，把历史 assistant 当作上下文。它适合训练目标只关心最终回答，或历史回复来自不同模型、质量不可控、包含中间草稿的场景。代价是监督信号更少，模型对中间轮回复的学习弱一些。
Causal LM 通常用当前位置 hidden state 预测下一个 token，框架会在计算 loss 时做 shift。实现 labels 时不要手动错位两次，也不要把 assistant 起始边界漏掉。最稳的做法是拿一条样本打印 input_ids、tokens、labels、loss_mask，人工确认第一个 assistant 内容 token、结束符和下一轮 user 边界都对齐。
多轮 SFT 很依赖 chat template。训练里的 system/user/assistant 标记、换行、特殊 token、工具调用格式和结束符，应该与推理请求保持一致。若训练模板和推理模板不一致，模型可能学会一种格式，却在上线时收到另一种格式，表现为角色错乱、漏答、复读或提前结束。
padding token 必须不计 loss。长样本截断时要避免只保留问题而截掉答案尾部，否则模型学不到完整结束。多样本 packing 时，每个样本之间要有边界，loss 不能跨样本预测，attention 也不能让后一个样本看到前一个样本的无关内容，除非实现了严格的 block diagonal mask。
如果 assistant 需要生成 tool call JSON、函数参数或结构化中间消息，这些 token 可以参与 loss；如果 tool result 是外部环境返回，不是模型应生成的内容，就不应参与 loss。关键原则是：模型上线时应该生成什么，训练就让它对什么负责。
如果 user token 参与 loss，模型容易复读用户、学习问题句式或把用户话术当答案。如果 assistant token 被错置为 -100，训练 loss 可能很低但模型学不到回答。如果结束符没学好，模型容易不停生成或跨轮串话。这些问题通常比模型规模或学习率更基础。
不一定。若每轮 assistant 回复都是高质量目标，训练所有 assistant turn 可以充分利用数据；若历史回复质量不一、包含中间草稿或只关心最终答案，可以只训练最后一轮。选择取决于数据质量和任务目标。
模型会被训练去预测用户输入，相当于学习复读问题或学习用户话术。这会浪费容量，还可能导致推理时角色混乱、复述用户问题、把输入当输出格式。
取决于模板和生成协议。如果上线时模型需要生成 assistant 内容后的 eos 或 stop token，结束符通常应该学习；角色起始标记如果由服务端模板固定注入，就不一定需要模型生成。核心是和推理时谁负责产生这些 token 保持一致。
最容易让样本之间互相 attention，或者让前一条样本的最后 token 去预测后一条样本的开头。需要样本边界、position 处理、attention block 和 labels=-100 一起正确，否则会产生跨样本污染。
抽几条样本把 token、role、label 和是否计 loss 打印成表格，确认 system/user/padding 是 -100，assistant 正文和必要结束符有 label；再用极小数据过拟合，看模型是否能生成目标回复而不是复读输入。
