从 badcase 到新版本：模型持续迭代的闭环

模型上线那天，不是项目结束，而是数据开始替你工作的第一天。线上跑出来的错误样本（badcase）是全世界最值钱的训练数据——它精确告诉你模型缺什么。这篇讲我们把 badcase 变成新版本的完整闭环。

把上线当作开始

传统的交付观是"验收通过即终点"，于是模型上线后精度停滞甚至缓慢劣化（场景会漂移：换了灯具、换了员工、上了新品）。数据飞轮的交付观是"验收通过即起点"：v1 的使命之一就是替你收集 v2 需要的数据。

badcase 从哪里来

• 告警复核：值班人员处置告警时标记"误报/漏报"，这是最天然的老师标注；
• 抽检机制：管理员定期从已标注图库抽样复核，错标与漏标本身就是 badcase；
• 低置信队列：模型输出的低置信样本往往覆盖了它"没见过"的形态，批量导出人工补标；
• 业务反馈：店长说"昨天那个场景没报"，按时间点回查录像定位帧。

回流与标注修正

收集到的样本回到训练平台的标准路径：上传入库（压缩包或单张）→ 按预设类别标注 → 与原有数据集合并或另立"迭代集"。这里平台化与手工的最大差别是可追溯：v2 = v1 数据集 + 某日回流批次，每个版本有 MD5，实验可以精确复现。修正也要有纪律：修正 v1 的错误标注时，同步更新标注规范，让同类错误不再发生。

版本策略与灰度

不是每个新版本都值得全量铺开。建议的版本纪律：数据集与模型版本一一对应、MD5 锁定；新版本先在 1~2 个点位灰度对比跑一周（新旧并行或按时间切换）；验证集指标与线上误报率双向确认后全量。回滚同样是版本能力——全量后发现问题，切回上一版是分钟级操作。

怎么证明变好了

• 验证集指标：整体 top1/mAP 之外，重点看 badcase 所在类别的指标变化；
• 线上误报率：每日误报数 / 总告警数，灰度期新旧对比；
• 业务指标：着装合规率、检查扣分次数——模型指标的终点是业务指标。

只看验证集会有"过拟合验证集"的风险，所以线上指标是最终裁判。

迭代节奏建议

上线首月每两周一轮（收集到的 badcase 多、业务在磨合）；稳定后降为每月或每季度一轮例行迭代；场景发生大变化（换灯、换货、装修）时立即加开一轮。迭代不是成本，是让模型资产保值增值的定期维护。

闭环里的三个角色

闭环能不能转起来，取决于三个角色是否各司其职：值班人员负责标记误报/漏报——这是零成本的数据收集，前提是标记动作足够简单（一键），所以工具设计比制度说教更重要；店长/主管负责确认与提交，并把业务语境（"那天换了新灯"）附在样本上；平台运营方负责定期汇总、标注修正与训练交付。实践中最容易断的一环是值班标记，对策是把"标记"做进告警处置流程本身，处置完成即完成标注。

延伸阅读：数据标注怎么做才高效、置信度阈值怎么调。