10.3 SFT 微调实战：数据集构建、训练配置、效果评估

在第 5.1 节中，我们已经从原理层解释了监督微调（SFT）如何让基座模型获得指令遵循能力；在第 10.2 节中，也对比了 LoRA、QLoRA 等参数高效方案的适用场景。本节进入工程落地——如何把一堆原始业务数据，稳定地炼成一个“听话且不忘本”的模型。这是绝大多数企业开发者接触最多的环节，也是“道理都懂，一训就废”的高发区。

一、数据集构建：质量是天花板，数量只是地板

SFT 的本质是行为模仿。你给模型看什么风格的“指令-回答”对，它就会朝那个方向收敛。因此，数据质量直接决定微调上限，而算法和算力只是帮你接近这个上限。

1.1 标准格式：别在起跑线上翻车

当前主流训练框架（Hugging Face TRL、Llama-Factory、Axolotl、DeepSpeed-Chat）普遍支持以下两种格式，务必在动手前统一：

Alpaca 格式（单轮/简单任务）

{
  "instruction": "请用一句话解释过拟合。",
  "input": "",
  "output": "过拟合是指模型在训练数据上表现过好，但在未见过的新数据上泛化能力差的现象。"
}

ShareGPT / OpenAI 格式（多轮对话）

{
  "messages": [
    {"role": "system", "content": "你是一位资深算法工程师。"},
    {"role": "user", "content": "什么是梯度消失？"},
    {"role": "assistant", "content": "梯度消失是指在深层网络中..."}
  ]
}

工程要点：

如果你的场景需要角色人设或安全拒答策略，必须在 system prompt 中显式定义，否则模型会沿用基座模型的默认风格，可能与业务预期冲突。
多轮对话必须保证对话轮次闭合（每轮 user/assistant 成对出现），且 EOS Token 截断正确，否则模型会学到“话只说一半”的坏习惯。

1.2 数据来源：开源 + 私域 + 合成

| 来源类型 | 典型代表 | 适用场景 | 注意事项 |
|---------|---------|---------|---------|
| 开源指令集 | Alpaca-GPT4、ShareGPT、COIG、BELLE、IDEAS-Instruction | 通用能力补强、快速验证 | 清洗程度参差不齐，需二次过滤 |
| 业务私域数据 | 客服记录、工单系统、专家 FAQ、内部知识库 | 垂直领域核心壁垒 | 往往是非结构化原始日志，需要重标注 |
| 合成数据 | Self-Instruct、用 GPT-4/Claude 蒸馏、Magpie | 快速冷启动、数据增强 | 需要校验事实准确性，防止“以讹传讹” |

实用建议：

垂直领域微调时，私域数据占比建议不低于 50%–70%，否则模型回答会带有强烈的开源数据集风格（例如过度口语化或中英文夹杂）。
合成数据是目前性价比最高的冷启动手段：用少量种子问题让 GPT-4 生成回答，再由人工审核，通常比从零标注效率高 5–10 倍。

1.3 质量控制：脏数据进去，脏模型出来

去重：字面重复（MD5 去重）+ 语义重复（Embedding 余弦相似度 > 0.95 的去重）。重复样本会导致该方向的 loss 权重被异常放大。
长度过滤：剔除过短（< 10 Tokens）和过长（超过你设定的 max_seq_length 的 95% 分位）的样本。过长样本会被截断，导致语义不完整。
答案校验：对于代码、数学、JSON 格式化输出，必须用脚本或沙箱自动校验正确性。一个错误答案被模型学到，后续纠正成本极高。
分布均衡：不要让某一类意图（如“问候”）占据 80% 样本。建议按业务意图分层采样，确保每类在训练集中占比相对均衡。

1.4 数量参考：够用就好

| 微调方式 | 推荐数据量 | 说明 |
|---------|-----------|------|
| 全参数微调 | 1万–10万条 | 需要覆盖足够模式，防止过拟合 |
| LoRA / QLoRA | 1000–5万条 | 参数少，少量高质量数据即可定型 |
| 二次微调（基于 Chat 模型） | 3000–3万条 | 基座已有通用能力，只需注入领域风格 |

血泪教训：见过太多团队盲目追求“10 万条指令”，结果里面夹杂着大量未清洗的爬虫数据和错误标注。1000 条精标数据 + 5 轮迭代，往往比 10 万条脏数据效果更好。

二、训练配置：在“学会新业务”和“不忘老本”之间走钢丝

2.1 基座模型选择

基于 Chat 模型二次微调（如 Llama-3-8B-Instruct、Qwen2-7B-Instruct）：这是 90% 业务的推荐路径。基座已经具备对话格式遵循和安全拒答能力，你只需叠加垂直领域行为。
基于 Base 模型从头做 SFT：只有当你需要完全重塑模型人格（例如特定角色扮演、严格受限的专业领域），或基座模型的默认对齐方向与你的业务冲突极大时才考虑。此时你需要准备覆盖通用能力的全量指令数据，成本倍增。

2.2 核心超参数：有业界共识，也有业务变量

| 参数 | 全参数微调推荐值 | LoRA 推荐值 | 说明 |
|------|----------------|------------|------|
| 学习率 (LR) | 1e-5 ~ 5e-5 | 1e-4 ~ 2e-4 | LoRA 因参数量小，LR 可放大 5–10 倍 |
| Scheduler | Cosine with Warmup | Cosine with Warmup | Warmup 步数通常占总步数的 5%–10% |
| 全局 Batch Size | 64–512 | 64–256 | 显存不够时用梯度累积凑 |
| Epoch | 1–3 | 1–3 | 超过 3 个 epoch 极易过拟合 |
| Max Seq Length | 按数据分布的 90% 分位设置 | 同上 | 不要无脑设 4096/8192，浪费显存 |
| 优化器 | AdamW (β1=0.9, β2=0.999) | AdamW | 标配 |
| 精度 | BF16 / FP16 | BF16 / FP16 | 优先 BF16（训练更稳定） |

关键工程细节：

学习率是关键中的关键。太大会导致模型“发疯”（输出乱码、重复、崩溃）；太小则微调不动。建议先做小规模 LR 范围测试（如 1e-5、5e-5、1e-4 各跑 100 步看 eval loss）。
Epoch 宁少勿多。SFT 不是预训练，数据反复喂几遍会让模型对训练集过度拟合，同时损伤通用能力（灾难性遗忘）。如果 loss 在 1 个 epoch 内就收敛 plateau，不要强行跑满 3 个 epoch。

2.3 LoRA 实战配置（如果选用 PEFT）

# 典型 LoRA 配置示例
LoraConfig(
    r=16,                    # 秩，通常 8–64。任务越复杂、数据越多，r 可适当增大
    lora_alpha=32,           # 缩放参数，通常 alpha = 2r
    target_modules=["q_proj", "k_proj", "v_proj", "o_proj", 
                    "gate_proj", "up_proj", "down_proj"],  # 全线性层参与效果通常更好
    lora_dropout=0.05,       # 0.05–0.1，防止过拟合
    bias="none",
    task_type="CAUSAL_LM"
)

经验之谈：

只改 q_proj + v_proj 是早期论文做法，但把所有线性层都加 LoRA（如 Llama-Factory 默认的全模块）通常效果更稳定，代价是参数略增。
r 不是越大越好。对于简单风格迁移任务，r=8 足够；对于需要注入大量领域知识的任务，可尝试 r=64 甚至 128。

2.4 显存与效率估算

假设使用 7B 模型、序列长度 2048：

| 方案 | 显存占用估算 | 单卡可行性（24GB） |
|------|-------------|------------------|
| 全参数 FP16 | ~60–80 GB | ❌ 需多卡/DeepSpeed ZeRO-3 |
| LoRA FP16 | ~16–20 GB | ✅ 可跑 |
| QLoRA (4bit + 分页优化) | ~8–12 GB | ✅ 宽裕，甚至可试更大的 batch |

提速技巧：

Gradient Checkpointing：用时间换空间，激活值重计算，显存降 30%–40%，训练速度降 20% 左右。
样本 Packing：将多条短样本拼接成一条长序列（需配套正确的 position ids 和 attention mask），把 GPU 利用率从 50% 拉到 90% 以上。

三、效果评估：Loss 下降只是起点，不是终点

SFT 训完后，最大的陷阱是只看 training loss 和 eval loss，然后直接上线。必须建立多维评估体系。

3.1 训练过程监控

Loss 曲线：Training loss 应平滑下降；Eval loss 同步下降或持平。若 eval loss 连续上升，立即停训——这是过拟合的明确信号。
学习率检查：确认 Cosine decay 已走到尾部，不要早停在一个过高的 LR 上。
梯度范数（Gradient Norm）：若出现剧烈震荡或 NaN，说明数据中有脏样本或 LR 过大。

3.2 自动评估：防止“偏科”与“失忆”

| 评估维度 | 方法 | 目的 |
|---------|------|------|
| 领域能力 | 自建测试集（如 500 条领域 QA）+ 规则/模型判分 | 验证微调是否达到业务指标 |
| 通用能力保留 | MMLU、C-Eval、GSM8K（选测） | 检测灾难性遗忘 |
| 指令遵循 | IFEval 或自建格式测试集 | 检查模型是否还能稳定输出 JSON、Markdown、指定语言等 |
| 安全性 | 有害请求测试集 | 确保二次微调没有破坏基座的安全护栏 |

灾难性遗忘的快速检测：保留 50–100 条通用能力 prompt（写古诗、翻译、常识问答），对比 SFT 前后输出。如果通用能力下跌超过可接受阈值，需要在训练集中混入 10%–30% 的通用指令数据作为“正则化”。

3.3 人工评估：最终裁判权

自动指标对开放生成任务参考价值有限。建议组织 3 人以上评估团队，对模型输出做盲评：

有用性（Helpfulness）：是否直接回答了用户问题，而非绕圈子。
准确性（Accuracy）：事实是否正确，代码是否能跑通。
遵循性（Instruction Following）：是否严格遵守了 system prompt 和格式要求。
幻觉率（Hallucination）：是否编造了不存在的事实、引用、参数。

评估方式：Side-by-Side（SBS）对比——同一问题，同时展示基座模型和 SFT 模型的回答，让标注者选择胜者或打平。最终统计 Win/Tie/Lose 比例。

3.4 A/B 测试与线上回滚策略

即使离线评估通过，上线初期也应：

开启 Shadow Mode（影子模式）：新模型与旧模型并行运行，只记录不展示，观察 1–3 天。
设置 自动回滚阈值：如幻觉率 > 5%、用户负面反馈率环比上升 20%，自动切回基座版本。

四、实战 Checklist：从数据到上线的标准动作

数据层：清洗 → 格式化（Alpaca/ShareGPT）→ 去重 → 分层采样 → 划分 Train/Eval（建议 9:1 或 95:5）。
配置层：选基座（Chat 模型）→ 选微调策略（优先 LoRA/QLoRA）→ 设学习率 + Epoch ≤ 3 → 开 Warmup + Cosine decay。
训练层：监控 loss / eval loss / 梯度范数 → 保存多个 checkpoint（每个 epoch 或每 10% 步数）→ 异常即停。
评估层：跑通用能力基线 → 跑领域测试集 → 人工 Side-by-Side → 幻觉/安全抽检。
部署层：合并 LoRA 权重（merge）→ 量化导出（可选）→ 推理一致性校验 → 灰度上线。

小结

SFT 是“大模型应用开发”中技术门槛最低、但工程细节最繁的环节。它的核心矛盾在于：用极少量的领域数据，去调整一个已经在万亿 Token 上预训练好的巨型模型，既让它学会新技能，又不破坏旧能力。

记住三个数字：Epoch ≤ 3，学习率全参 1e-5 级 / LoRA 1e-4 级，通用数据保留 10%–30%。守住这三条红线，再配合严格的数据清洗和多维评估，你的 SFT 项目就已经战胜了市面上 80% 的粗糙实践。

在 10.4 节中，我们将进入更高阶的对齐环节——RLHF 落地流程：如何收集偏好数据、训练奖励模型、以及用 PPO 算法让模型真正学会“投人类所好”。