微调上线：评测、灰度、回滚与持续迭代

模型能训出来，只是起点；真正难的是上线后还能稳定变好。
这一篇把“训练后半程”讲清楚，重点回答三件事：如何评测、如何灰度、如何把 badcase 变成持续改进。

离线评测通常在相对干净的样本上进行，线上则更复杂：

  • 输入噪声更大，边界情况更多；
  • 工具调用、检索质量、上下游依赖都会影响结果；
  • 用户目标不固定，分布会漂移。

所以上线前后都要评估，但指标分层要不同。

一个可执行的评测结构是：

  • 离线评测：任务指标（正确率、格式合规、拒答质量）；
  • 灰度评测：小流量真实请求，观察失败类型与延迟；
  • 全量评测：长期监控业务指标和用户反馈。

核心原则是：

  • 用同一套基线对照；
  • 用同一批关键回归题防回退；
  • 每次上线都能回答“比上一版好在哪、差在哪”。

灰度阶段建议先把风险收口：

  • 按租户/场景/流量比例分批放量；
  • 关键业务保守策略优先（必要时保持旧模型）；
  • 异常阈值触发自动回切。

你可以把灰度看成一个问题：

  • 这版模型在真实请求里，是否稳定优于旧版？

如果结论不确定，不要急着全量。

很多项目的问题不是“不能回滚”，而是“回滚代价太大”。
常见做法：

  • 保留旧模型可快速切换；
  • 模型版本、数据版本、Prompt 版本一起记录；
  • 关键配置支持开关级别回退。

这样出问题时能做到：

  • 快速止损；
  • 可复盘；
  • 可定位到是模型、数据还是编排逻辑的问题。

badcase 回流不只是“把错题扔进训练集”，还要先归因：

  • 是模型理解问题；
  • 还是检索召回问题；
  • 还是工具调用/数据源问题。

只有归因清楚，回流才有意义。
否则会出现“训练了很多轮，症状没变”的假迭代。

在微调体系里，建议控制发布节奏：

  • 小版本高频迭代，每次解决少量明确问题；
  • 固定回归集长期追踪，避免反复踩回头路；
  • 对高风险场景维持人工抽检或 Reviewer 兜底。

这类节奏的好处是：

  • 问题定位更清楚；
  • 业务方更容易建立信任；
  • 团队能持续积累“可复用样本与策略”。
  • 评测要分层，不能只看离线分数；
  • 灰度和回滚是上线前置条件，不是出事后补救；
  • badcase 回流要先归因，再进入训练。

当你把“训练、评测、发布、回流”串成闭环，微调才会从一次性动作，变成稳定的工程能力。