监督微调SFT：对话格式

可视化演示

动态展示监督微调中对话格式的Token结构与损失掩码机制，对比训练Token与掩码Token的分布差异。

对话格式基础

餐厅后厨最怕什么？怕顾客在纸上写一句“随便来点好吃的”——没有结构、没有分栏，厨师无从下手。于是餐厅设计了统一的点菜单：顾客信息栏、菜品栏、备注栏。对话格式（Chat Format） 就是这个道理：它是大模型与人之间约定的、结构化的消息组织方式。

在技术世界里，这张菜单通常包含三类角色：system（系统提示/餐厅规定）、user（用户指令/顾客点菜）、assistant（模型回复/服务员应答）。监督微调 SFT 的“监督”二字，正体现在这里——我们给模型提供“标准答案格式”，让它照着学。

为什么必须结构化？因为模型本质上一个劲地在预测“下一个 token”。如果对话内容像一条长流水账，模型无法分清哪些 token 是用户说的、哪些是自己该接的。格式就是“分栏”，让模型学会：看到用户栏的结尾，就知道该轮到自己开口了。

$$\displaystyle \text{对话样本} = \text{system 消息} + \sum_{i=1}^{n}\left(\text{user}_i + \text{assistant}_i\right)$$

1. 系统消息：扮演“餐厅规定”的角色，给出全局行为约束，放在整段对话最开头。

$$\text{system 消息}$$

2. 多轮求和：i 从 1 到 n 的每一轮，都是一对“用户问+助手答”，像点菜单上一行行菜品记录。

$$\sum_{i=1}^{n}$$

3. 交替拼接：user_i 和 assistant_i 必须严格交替，不能连续两条 user，否则模型会“精分”。

$$\text{user}_i + \text{assistant}_i$$

回到比喻：训练 SFT 模型，就是不断给它看“填好的点菜单”，让它掌握“看到顾客栏，我就该写菜品栏”的固定套路。格式一旦混乱，模型就会像新手服务员一样，把菜名写到备注栏里。

主流格式解析

不同餐厅有不同的菜单模板——中餐厅用三联单，西餐厅用桌边点单系统。不同模型家族也各有各的对话格式。目前主流的有三种，就像三种流传最广的“点菜单版本”。

llama-2 格式是 Meta 在 Llama 2 系列中使用的格式，用 [INST] 和 [/INST] 分别标记指令的开头和结尾，像在菜单上用粗线框出“顾客指令区”：

$$\displaystyle \text{<s>}[INST]\text{用户消息}[/INST]\text{模型回复}</s>$$

ChatML 格式由 OpenAI 在 ChatGPT 训练中推广，用 <|im_start|> 和 <|im_end|> 包裹每条角色消息，像每道菜都独立装盘、贴上标签：

\displaystyle \text{<|im_start|>user}\n\text{用户消息}\text{<|im_end|>}\n\text{<|im_start|>assistant}\n\text{模型回复}\text{<|im_end|>}

Alpaca 格式来自斯坦福的 Alpaca 项目，结构更简单，适合单轮指令跟随场景：

\displaystyle \text{### Instruction:}\n\text{用户指令}\n\text{### Response:}\n\text{模型回复}

1. 左尖括号：<s> 是句子起始符，告诉模型“菜单开始打印了”。

$$\text{<s>}$$

2. 框住指令：[INST] 和 [/INST] 配对出现，像点菜单上的“菜品栏从这里开始/到这里结束”。

$$[INST]\text{用户消息}[/INST]$$

3. 角色头：<|im_start|>user 是消息头，声明“下面这段话的说话人是用户”。

\text{<|im_start|>user}\n

4. 结束符：<|im_end|> 是一条消息的结束标记，像菜盘上盖的保鲜膜。

\text{<|im_end|>}

作为 AI 从业者，最大的坑是“混用格式”——今天用 llama-2 模板训练，推理时却用 ChatML 拼接，模型立刻进入“点菜单错版”状态，输出乱码式回复。选一种主流格式（推荐 ChatML），训练与推理全程锁死。

特殊标记作用

点菜单上的分隔线不是装饰——它能防止顾客把“不要香菜”写到“桌号”栏里。对话格式中的特殊标记（Special Tokens）扮演的正是“分隔线”的角色。它们的核心作用有三个。

第一，分隔角色。<|im_start|>user 和 <|im_start|>assistant 是两个不同的标记，模型看到它们，就像员工听到“顾客来了”和“轮到我了”两种不同的铃声。第二，定位边界。<|im_end|> 标记一条消息的结束，让模型知道“这句话讲完了”。第三，拼接多轮。多轮对话就是把多组消息按顺序串起来，标记像火车车厢之间的挂钩，保证每节车厢（每条消息）不脱节。

$$\displaystyle \text{多轮对话} = \text{M}_1 + \text{E}_1 + \text{M}_2 + \text{E}_2 + \cdots + \text{M}_n + \text{E}_n$$

1. 消息体：M_i 代表第 i 条消息的文本内容，如“推荐一道微辣招牌菜”。

$$\text{M}_i$$

2. 结束标记：E_i 是第 i 条消息的结束符，如 ChatML 中的 <|im_end|>。

$$\text{E}_i$$

3. 交替连接：M_i + E_i 保证每条消息都自包含、不串味。

$$\text{M}_i + \text{E}_i$$

想象一下传菜员按铃、上菜、按铃、再上菜——特殊标记就是那个“铃”。没有铃，后厨永远不知道哪句话是上一道菜的尾声。训练时如果漏掉结束符，模型就学不会“什么时候该闭嘴”。

模板构建方法

餐厅有了菜单模板还不够，得把它印成空白单，服务员随时拿出来套用。构建对话模板就是把“角色消息列表”渲染成“带标记的标准字符串”的过程。

在工程实现上，模板通常是一个配置化定义的字符串，而非硬编码。比如用 Hugging Face Transformers 里的 apply_chat_template，把消息列表作为输入，自动加上所有特殊标记。这样做的好处是：换模型时只需换模板，不用改数据管道。

$$\displaystyle \text{template}: \text{消息列表} \rightarrow \text{字符串}$$

一个标准的 ChatML 模板在代码里长这样："<|im_start|>{role}\n{content}<|im_end|>\n"，其中 {role} 替换为 user/assistant/system，{content} 替换为消息正文。

\displaystyle \text{渲染结果} = \text{f}(\text{role}, \text{content}) = \text{"<|im_start|>"} + \text{role} + \text{"}\n\text{"} + \text{content} + \text{"<|im_end|>}\n\text{"}

1. 角色拼接：把 user、assistant 等角色名嵌入到 <|im_start|> 之后。

\text{"<|im_start|>"} + \text{role}

2. 内容嵌入：把消息正文放在角色名之后的换行符后面。

\text{role} + \text{"}\n\text{"} + \text{content}

3. 收尾封闭：最后补上 <|im_end|> 和换行，完成一条完整消息的渲染。

\text{content} + \text{"<|im_end|>}\n\text{"}

照这个比喻，模板就是复印机——数据管道只负责往空白单上填内容，模板负责保证每一张单子格式一致。实战中建议用社区成熟的模板（如 ChatML）而不是自创，因为预训练模型已经在特定格式上见过大量数据。

损失掩码原理

后厨培训新厨师时，不会让他把顾客说的每句话都背下来，只让他学“如何做菜”。SFT 的损失计算（Loss Masking） 遵循同样的原则：只对“助手回复”部分计算损失，对“用户指令”和“系统提示”部分进行掩码屏蔽。

为什么？因为模型需要学会的是“如何回答”，而不是“如何提问”。如果对用户消息也计算损失，相当于逼厨师把顾客台词背得滚瓜烂熟，纯属浪费。同时，用户消息中的敏感信息也不该被模型刻意“背诵”。

$$\displaystyle \mathcal{L}_{\text{SFT}} = -\frac{1}{N}\sum_{i \in \text{答案位置}} \log p_\theta(y_i \mid y_{<i})$$

其中 答案位置 指 assistant 消息中所有 token 的下标集合。p_\theta(y_i \mid y_{<i}) 是模型对第 i 个 token 的预测概率。

1. 平均损失：1/N 表示对所有被计算损失的 token 取平均，N 是答案部分的总 token 数。

$$\frac{1}{N}\sum_{i}$$

2. 集合限定：i \in 答案位置 表示只遍历助手回复中的位置，跳过 prompt。

$$i \in \text{答案位置}$$

3. 对数概率：log p_\theta 表示模型对正确 token 预测概率的对数，越大说明学得越好。

$$\log p_\theta(y_i \mid y_{<i})$$

掩码机制就像培训手册上印的“红字答案”——学员只对着红字练，黑字（顾客台词）看一眼即可，不用背。实现时要注意：有些开源库默认不开启掩码，需要手动配置 ignore_index=-100 才能生效。

数据构建流程

有了模板和掩码，还差最重要的原材料——SFT 训练数据。就像餐厅需要把每天的顾客反馈整理成新菜谱，AI 工程师需要把真实对话清洗成标准训练样本。整个流程分四步。

第一步，清洗对话：去掉无关的闲聊、重复内容、敏感信息。第二步，格式转换：将原始对话转成 system/user/assistant 三段式，再套用模板渲染成字符串。第三步，质检校验：检查每一条数据的角色顺序是否正确、特殊标记是否闭合。第四步，规模配比：一般来说，对话数据中“多轮样本”要有一定占比，让模型学会上下文连贯。

$$\displaystyle \text{训练样本} = \text{clean}(\text{原始对话}) \xrightarrow{\text{模板}} \text{tokenizer}(\text{标准字符串})$$

1. 清洗函数：clean 指去除原始对话中的噪声（空行、乱码、格式不一致）。

$$\text{clean}(\text{原始对话})$$

2. 模板渲染：箭头 \xrightarrow{\text{模板}} 表示用配置好的模板把清洗结果转成标准字符串。

$$\xrightarrow{\text{模板}}$$

3. 编码器：tokenizer 把标准字符串切分成 token id 序列，交给模型训练。

$$\text{tokenizer}(\text{标准字符串})$$

回到比喻：后厨拿到一大堆顾客手写意见，先抄录、再分类、最后对账，才能变成标准菜谱。数据构建是 SFT 中最耗时、最决定上限的环节——垃圾进，垃圾出，格式错误的数据比没有数据更糟。

实战调优策略

最后是工程实战环节。即便理解了对仗格式的所有原理，实际微调时仍会遇到各种“菜单印刷错误”。这里给出三条核心调优策略。

第一，先检查模板。模型输出异常时，第一件事不是调学习率，而是打印一条训练样本，肉眼检查特殊标记是否正确闭合。第二，控制数据量。SFT 不是数据越多越好，通常几千到几万条高质量对话即可，重点是 format 一致性。第三，迭代实验。用固定模板训练一个小模型（或 LoRA），快速验证格式是否被模型学会，再做全量微调。

$$\displaystyle \text{评估指标} = \text{格式正确率} + \text{内容正确率},\quad \text{格式正确率} = \frac{\text{标记合法的回复数}}{\text{总回复数}}$$

1. 格式正确率：统计模型生成的回复中，角色标记是否按预期出现。

$$\text{格式正确率}$$

2. 内容正确率：统计语义是否满足用户指令，属于更高层次的质量。

$$\text{内容正确率}$$

3. 比值定义：分子是“标记合法的回复数”，分母是“总回复数”，两者相除得到百分比。

$$\frac{\text{标记合法的回复数}}{\text{总回复数}}$$

调优的过程就像餐厅根据差评不断修改菜单排版：顾客说“看不见辣度选项”，就加粗那一栏；模型说“不知道何时结束回答”，就检查是不是漏了 <|im_end|>。小步快跑、持续迭代，SFT 的工程质量就是这样打磨出来的。

AI 应用场景

Python 演示

# -*- coding: utf-8 -*-"""用 ChatML 格式构建 SFT 训练样本并演示 loss masking。"""from typing import List, Dict def build_chatml(messages: List[Dict[str, str]]) -> str:    """将消息列表渲染为 ChatML 格式字符串。"""    rendered = ""    for msg in messages:        role = msg["role"]        content = msg["content"]        rendered += f"<|im_start|>{role}\n{content}<|im_end|>\n"    return rendered def mask_prompt_tokens(input_ids: List[int], tokenizer, prompt_len: int) -> List[int]:    """将 prompt 部分的 token 标记为 -100（不参与 loss 计算）。"""    labels = list(input_ids)    for i in range(prompt_len):        labels[i] = -100    return labels def build_sft_sample(messages: List[Dict[str, str]], tokenizer) -> Dict[str, List[int]]:    """构建一条 SFT 训练样本：input_ids + labels（带掩码）。"""    text = build_chatml(messages)    input_ids = tokenizer(text, add_special_tokens=False)["input_ids"]    # 假设 prompt 是前 N-? 个 token，简单示例取前 2 条消息的长度    prompt_text = build_chatml(messages[:-1])    prompt_ids = tokenizer(prompt_text, add_special_tokens=False)["input_ids"]    labels = mask_prompt_tokens(input_ids, tokenizer, len(prompt_ids))    return {"input_ids": input_ids, "labels": labels} def main():    # 一个简化版 tokenizer：按字符切分    class DummyTokenizer:        def __call__(self, text: str, add_special_tokens: bool = False) -> Dict[str, List[int]]:            return {"input_ids": [ord(c) for c in text]}     tok = DummyTokenizer()    messages = [        {"role": "system", "content": "你是一位点餐助手。"},        {"role": "user", "content": "推荐一道微辣招牌菜。"},        {"role": "assistant", "content": "推荐宫保鸡丁，微辣。"},    ]    sample = build_sft_sample(messages, tok)    print("input_ids length:", len(sample["input_ids"]))    print("labels sample:", sample["labels"][:20], "...")    print("masked count:", sample["labels"].count(-100)) if __name__ == "__main__":    main()

1. rendered += f"<|im_start|>{role}\n{content}<|im_end|>\n"每一条消息按 ChatML 格式拼接，角色和内容填入模板。
2. for i in range(prompt_len): labels[i] = -100把 prompt 部分的标签设为 -100，让损失函数自动跳过这些位置。
3. tokenizer(text, add_special_tokens=False)分词时不额外添加全局特殊 token，保证格式完全由模板控制。
4. mask_prompt_tokens核心掩码函数，模拟了主流训练框架中 ignore_index=-100 的机制。
5. sample["labels"].count(-100)统计被掩码的 token 数，验证 prompt 部分确实被屏蔽。

常见误区

面试题