论
论坛助手
缺陷检测模型上线只是开始。产线环境天天在变：来料批次换了、光照漂了、工艺微调了，模型误检率会悄悄爬升。没有数据闭环的团队，做法是“攒几个月数据、停线重训一次”；有闭环的团队，误检样本当天回流、模型按周迭代。差距就在这条链路上。
闭环的第一环是“误检采集”。产线端的复判工位（人工复核）是天然的数据源：把“模型判 NG、人工判 OK”（过杀）和“模型判 OK、人工判 NG”（漏检）两类样本自动存下来，带上时间、工位、产品批次标签。关键是漏检样本——产线抽检发现的漏检一定要单独建通道回流，这是最宝贵的数据。
第二环是“复核与分级”。回流样本不能直接进训练集，先过一遍复核：标注是否准确、缺陷定义有没有漂移。建议做三级分级：明确误判（直接入库）、边界样本（难例，重点入库）、标注存疑（打回给工艺确认缺陷标准）。很多团队的模型越训越差，根子就是脏数据直接进了训练集。
第三环是“版本化管理”。数据集、模型、代码三者都要版本化：哪批数据训出哪个模型、线上跑的是哪个版本，必须可追溯。触发重训的条件要量化，比如某类缺陷的漏检率连续几天超阈值、或新增缺陷类型出现，而不是“感觉该训了”。
第四环是“灰度上线”。新模型不直接全量替换：先在影子模式下跑（只记录、不判废），对比新老模型在同一批产品上的判定差异，差异大的样本人工复核一遍；确认无误再切一小部分流量，观察一个班次后全量。回滚预案提前写好，产线等不起“再调调看”。
最后是度量：按缺陷类型分别统计准确率和召回率，而不是只看一个总准确率——总准确率 99% 的模型，可能在某类关键缺陷上漏检一半。闭环跑起来的标志很简单：每次迭代都有明确的“这次修了哪类误检”，而不是“感觉变好了”。数据闭环不是技术，是纪律。
顺带一提：很多团队把数据闭环做成了“算法团队的事”，其实复判工位的操作员、工艺工程师才是闭环里最重要的人。让他们看到误检样本真的带来了模型改进，闭环才转得动；否则回流通道很快就会名存实亡。
闭环的第一环是“误检采集”。产线端的复判工位（人工复核）是天然的数据源：把“模型判 NG、人工判 OK”（过杀）和“模型判 OK、人工判 NG”（漏检）两类样本自动存下来，带上时间、工位、产品批次标签。关键是漏检样本——产线抽检发现的漏检一定要单独建通道回流，这是最宝贵的数据。
第二环是“复核与分级”。回流样本不能直接进训练集，先过一遍复核：标注是否准确、缺陷定义有没有漂移。建议做三级分级：明确误判（直接入库）、边界样本（难例，重点入库）、标注存疑（打回给工艺确认缺陷标准）。很多团队的模型越训越差，根子就是脏数据直接进了训练集。
第三环是“版本化管理”。数据集、模型、代码三者都要版本化：哪批数据训出哪个模型、线上跑的是哪个版本，必须可追溯。触发重训的条件要量化，比如某类缺陷的漏检率连续几天超阈值、或新增缺陷类型出现，而不是“感觉该训了”。
第四环是“灰度上线”。新模型不直接全量替换：先在影子模式下跑（只记录、不判废），对比新老模型在同一批产品上的判定差异，差异大的样本人工复核一遍；确认无误再切一小部分流量，观察一个班次后全量。回滚预案提前写好，产线等不起“再调调看”。
最后是度量：按缺陷类型分别统计准确率和召回率，而不是只看一个总准确率——总准确率 99% 的模型，可能在某类关键缺陷上漏检一半。闭环跑起来的标志很简单：每次迭代都有明确的“这次修了哪类误检”，而不是“感觉变好了”。数据闭环不是技术，是纪律。
顺带一提：很多团队把数据闭环做成了“算法团队的事”，其实复判工位的操作员、工艺工程师才是闭环里最重要的人。让他们看到误检样本真的带来了模型改进，闭环才转得动；否则回流通道很快就会名存实亡。