跳转至

Step1 报告：SFT 风险控制

中文邮政客服任务 SFT 训练方案与风险控制报告

1. 目标

这份文件主要把两件事说清楚：

  1. 在 k 级别中文客服数据上，SFT 的实施路径应如何设计
  2. 训练过程中应该看哪些指标，避免模型出现“训崩 / crash / collapse / 明显退化”

这里说的“风险控制”，不是泛泛而谈训练安全，而是围绕这套数据和任务，怎么把训练过程看住、把问题尽早发现。

2. 当前数据特点决定不能激进训练

按现在的数据情况，至少有三个很现实的约束：

2.1 数据量不大

当前数据是 k 级别，不是百万级别。
对应的训练约束是：

  • 很难支撑激进的大模型全参训练
  • 很容易过拟合
  • 很容易把模型原有通用能力训坏

2.2 数据更像客服监督数据，而不是 reasoning 数据

当前数据核心内容是：

  • 对话
  • summary
  • intent

它适合做：

  • 客服风格适配
  • 领域知识适配
  • 工单总结与结构化输出

但它并不天然适合做：

  • 高质量思维链监督
  • reasoning 行为强化

2.3 输出目标很明确

本项目最终希望模型能稳定完成：

  1. 中文客服对话
  2. 领域问答
  3. 工单总结
  4. JSON 输出

所以训练设计的重点必须放在“输出稳不稳、任务贴不贴”上，而不是去追 reasoning 分数。

3. 微调实施方案

3.1 采用 LoRA / 参数高效微调方案

当前阶段不采用全参微调，训练方案确定为采用：

  • LoRA
  • 或其他参数高效微调方案

原因：

  • 算力成本低
  • 调参成本低
  • 更符合小数据场景
  • 更不容易把底模能力整体训坏

3.2 分阶段推进模型规模

本项目采用如下实施顺序：

  1. Qwen2.5-3B
  2. Qwen2.5-7B
  3. 视资源情况再考虑 gpt-oss:20b

该实施路径的价值在于：

  • 小模型更快暴露数据问题
  • 小模型更利于快速试验超参数
  • 等流程稳定后，再把经验迁移到更大模型

3.3 不采用一步到位的超大模型路线

这里不是否定大模型本身，而是当前不走这条路线，原因很简单：

  • 训练慢
  • 验证慢
  • debug 成本高
  • 在当前时间窗口下性价比不高

4. 训练时最需要监控的指标

下面这些指标统一作为训练过程的健康度监控项。

4.1 训练 loss

最基础指标。
需要观察：

  • 是否稳定下降
  • 是否突然震荡
  • 是否在某一阶段开始异常升高

风险信号：

  • loss 长时间不降：说明学习率、数据、模板或训练目标有问题
  • loss 突然暴涨：可能是学习率过高、梯度不稳定、数据脏样本影响

4.2 验证 loss

这一项比训练 loss 更重要。
需要观察：

  • 验证集 loss 是否同步改善
  • 是否出现明显过拟合

风险信号：

  • 训练 loss 继续下降，但验证 loss 开始上升
  • 说明模型开始记忆训练集而不是学到泛化能力

4.3 结构化输出成功率

这个项目不能只看语言模型的通用 loss，还需要同时跟踪任务指标。
本方案中专门统计：

  • JSON 可解析率
  • 字段完整率
  • 字段格式正确率

风险信号：

  • loss 看起来下降了，但 JSON 经常不闭合
  • 字段缺失率很高
  • 输出开始变长、变乱、格式漂移

这类情况通常说明：

  • 模型表面上更会生成了，但没有真正学会按要求输出

4.4 客服回复质量抽样

本方案要求每个 checkpoint 固定抽样同一批验证样本，人工检查：

  • 回复是否礼貌
  • 是否答非所问
  • 是否出现明显幻觉
  • 是否与邮政场景匹配

原因也很直接：

  • 纯 loss 指标很难完全反映客服体验
  • 报告材料中也需要能展示“人工质检结果”

4.5 通用能力退化信号

本方案保留一小批通用样本用于观察：

  • 常识问答
  • 一般对话
  • 简单结构化输出

风险信号：

  • 客服领域内效果提升了
  • 但通用输出明显退化，甚至基础表达能力下降

这通常意味着模型已经出现明显的灾难性遗忘。

5. 重点防崩指标

若只保留最关键的监控项，本方案重点采用以下 5 个：

  1. 训练 loss 是否突然暴涨
  2. 验证 loss 是否在训练 loss 继续下降时反向上升
  3. JSON 可解析率是否下降
  4. 固定验证样本输出是否出现明显格式漂移
  5. 同一 checkpoint 的人工抽样质量是否突然恶化

和只盯着一个总 loss 相比，这几项更能看出模型是不是已经开始往坏的方向走。

6. 为什么会训崩

常见原因包括：

6.1 学习率过高

最常见。
表现：

  • loss 抖动大
  • 输出开始乱
  • 验证波动明显

6.2 数据质量不稳定

当前数据本身就不算特别规整，存在：

  • summary / intent / 对话粒度混杂
  • 样本风格不统一
  • 部分样本噪声较大

若不完成必要清洗，模型就容易学到不稳定模式。

6.3 模板设计不一致

若训练样本的输入输出模板不统一，比如：

  • 有的样本像对话
  • 有的样本像摘要
  • 有的样本像 JSON 生成

但又没有清楚区分任务头，模型会学得很乱。

6.4 小数据下训练太久

k 级别数据很容易过拟合。
所以在这类数据上：

  • 训练步数过多
  • checkpoint 选得太晚

都可能让模型“越训越差”。

7. 如何降低训崩概率

7.1 保守超参数起步

起步策略定为：

  • 先用保守学习率
  • 小步试跑
  • 先看 1 个 epoch 内的趋势

一开始不把训练强度拉满，先看趋势，再决定是否继续加。

7.2 固定频率保存 checkpoint

本方案要求：

  • 按固定 step 保存 checkpoint
  • 不默认最后一个就是最好

这样后面如果开始退化，还能回退到更稳的中间 checkpoint。

7.3 每个 checkpoint 做同一套验证

固定验证内容包括：

  • 验证集 loss
  • JSON 可解析率
  • 字段完整率
  • 客服回复人工抽样

这样不同 checkpoint 才有横向可比性。

7.4 单独监控 JSON 任务

这个项目里，JSON 输出能力是单独的核心能力。
本方案不将其混入总评价，而是单独列成一项核心指标。

7.5 先做 3B，再做 7B

原因很现实：

  • 3B 更快出结果
  • 更快暴露数据 / 模板问题
  • 先把方案跑稳，再迁移到 7B，成功率更高

8. 报告中采用的训练流程表述

成稿里，训练流程按下面这套写法展开：

  1. 先对原始客服数据做清洗、筛选和 EDA
  2. 统一训练模板，区分客服对话任务与工单总结 / JSON 任务
  3. 先使用 Qwen2.5-3B 做 LoRA 微调，验证训练流程和指标体系
  4. 固定 step 保存 checkpoint，并持续监控训练 loss、验证 loss、JSON 可解析率和人工抽样效果
  5. 在训练稳定后，再迁移到 Qwen2.5-7B 获取更强效果
  6. 以 gpt-oss:20b 作为更大模型基线或补充对照，不纳入第一阶段 SFT 主力路线

9. 最终实施结论

最后把训练方案收束成一句话，就是：

  • 主力模型：Qwen2.5-3B / 7B
  • 训练方式：LoRA
  • 关键监控：训练 loss + 验证 loss + JSON 可解析率 + 人工抽样
  • checkpoint 策略：固定 step 保存，中途选优，不迷信最后一个

归纳来看：

这套 SFT 方案的重点，不是继续把模型做大，而是先把训练跑稳、把输出格式管住、把结果做成可复现的完整闭环。