Skip to content

Step1 / SFT Risk Report

The current site directly includes the original Chinese report source below. English translation can be added later without changing the source organization.

中文邮政客服任务 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 方案的重点，不是继续把模型做大，而是先把训练跑稳、把输出格式管住、把结果做成可复现的完整闭环。