机器视觉模型安全上线四步法：影子跑、灰度切、一键回滚与发布单

模型训练完成只是开始，产线部署才是真正的考验。本文从一次过杀率飙升的现场事故切入，拆解检测模型上线的四个关键动作：影子跑、灰度切、一键回滚、发布单，教你如何在机器不停的情况下安全换脑，避免“周五晚上”的翻车现场。

上一篇结尾我说，样本库建好、版本冻结、7:2:1 切明白，新模型训出来是水到渠成的事。有读者在评论区催更：模型训出来了，然后呢？拷到设备上，重启，收工？

这一篇就写“然后呢”。

先讲一个我印象很深的现场。一家做 3C 外观检测的客户，模型迭代是算法工程师自己管的。某个周五晚上，他觉得新版本测试集指标涨了 1.8 个点，稳了，直接推到产线。周一早上品质部炸锅：过杀率从 2% 飙到 11%，NG 品里清一色是同一种误判。倒查回去，新模型的训练集里这种瑕疵样本太少，模型把它当成了正常品的反面——凡是长得像的，全杀。

收场收了四个小时：把旧模型文件从备份里翻出来，手动替换，重启，重新跑。这四个小时产线没停，但检出来的每一批货都得人工复判。厂长没骂人，就问了一句：下次换模型，能不能提前告诉我是哪个时刻换的？

这件事给我的触动不在“模型不准”——迭代本来就是试错。触动我的是：在产线上换一个模型，跟给一台连轴转的机器换轴承是一个性质的事。你得有工艺，不能靠胆子。

网站发版出问题，挂个维护页，回滚代码，用户刷新一下就好。产线不行。二十四小时连轴转，你没法跟厂长说“停线半小时，我换个模型”。所以检测模型的发布流程，本质上是在回答一个问题：怎么在机器不停的情况下，把一颗新脑子换进去？

我把我见过的、踩过的、帮客户理过的做法，整理成四个动作：影子跑、灰度切、一键回滚、一张发布单。一个个说。

一、影子跑：新模型先当影子，别急着当裁判

第一个动作，最反直觉：新模型上线，第一件事是让它什么都别管。

具体叫影子模式。旧模型 v1 继续判，新模型 v2 在旁边跟着跑，每张图也推理、也出结果，但结果只写进日志，不影响任何判定。两个模型同题同卷，一个交卷算分，一个交卷存档。

有人问，测试集上不是已经考过了吗，干嘛还多此一举。因为测试集是死的，产线是活的。测试集那批图是上个月的料、上个月的光源、上个月的相机状态；产线上周换了批来料，前天灯管开始老化，下个月车间换季湿度一变，图像分布全变了。测试集考的是“过去的题”，影子跑考的是“现在的题”。

跑多久？我的经验值：一到两周，至少跨两个批次的来料轮换，过机图几十万张起步。再长没意义，新模型也该迭代了；再短，单一批次的运气成分去不掉。

影子期看什么？不是看准确率——没有标准答案的图，谈不上准确率。看分歧。每张图上 v1 和 v2 判的不一样，就是一笔分歧：v1 判 OK、v2 判 NG 是一笔，反过来又是一笔。分歧率，我的经验值压到 3% 以下，才有资格谈接管。超了别硬上，把分歧样本导出来人工看——八成能看出个名堂。

我见过一次分歧率 8% 的，吓出一身冷汗，导出来一看，分歧图里全是新供应商的来料，表面纹理跟老供应商不是一个风格，训练集里压根没有。赶紧补数据、重训，第二版影子跑分歧率 1.6%，稳稳接管。要是没跑影子直接推，就是又一个“周五晚上”的故事。

这里有个产品设计的钩子，接上一篇：分歧样本不该看完就扔。它天然是最高价值的训练素材——两个模型打架的地方，就是数据分布的边界。影子跑的分歧队列，应该一键回流样本库，进下一轮标注。这条河通了，迭代才有源头活水。

还有一句要说的：影子跑不能做成算法工程师的本地脚本。要做成产品里的一个开关加一张看板——开关打开，选目标版本，跑起来；看板上分歧率、分歧趋势、典型样本一屏看全。脚本在工程师手里，工程师休假，影子跑就休假；开关在系统里，谁当班谁看着。

二、灰度切：产线没有“5% 用户”，只有整条线

影子跑及格，v2 证明了自己跟 v1 想的差不多。下一步接管，也不是一把全切。

做互联网产品的朋友对灰度熟：5% 用户、20%、50%、全量，逐步放量。这套搬到产线，第一个不适应：产线没有“5% 的工位”。一个工位要么跑 v1，要么跑 v2，没有半个。一张图要么这个模型判，要么那个模型判，混着来，判定口径就乱了。

所以产线灰度，切的不是流量，是单位。三个切法，按风险从低到高：

按用途切。检测系统里往往不止一个模型岗位：主检直接判废，复检给人工把第二道关。先让 v2 只上复检工位——复检天然有人工兜底，模型判错了，人接得住。跑三天，没事，再谈主检。

按产线切。一个车间三条线，先上一条。这条线就是全公司的试验田，出了事影响面一条线，别的是安全的。

按班次切。夜班先上新版本，白天有人盯着的时候切回旧版对比。这个切法慎用，两版来回切，判定记录的对账成本高，适合人手紧的小厂应急。

我推荐的标准顺序：复检工位三天，单条主线三天，然后逐步扩到全部产线。每一步都有验收门：漏检率、过杀率对着 v1 的基线看，偏差在正负 0.5% 以内，放行下一档；超了，停下——注意，是停下，不是回滚。灰度本身就是缓冲垫，跑出疑点，先冻结在灰度里查清楚，查明白了再决定往前走还是往回退，别一惊一乍。

对了，还有一种做法叫 AB，得跟灰度分清楚。灰度是“一部分工位用新版”，AB 是“同一批料、同一个时段，v1 v2 交替判，各记各的账”。AB 的价值是把变量摁死：上午的料和下午的料不是一批，昨天的环境和今天的环境不是一天，隔天对比是拿西瓜比芝麻，只有同时段同物料的对比才算数。AB 的产出是一张对账表：同一批图，两个模型各判成什么样，差异样本人工复核。代价是双倍推理和一套对账逻辑，一般是有多条并行产线的大客户才用得起；小客户，影子跑加灰度足够。

产品设计上，AB 模式要给操作员一个“以谁为准”的切换：一个模型管判定，另一个只记账，随时可换。这个开关看着小，出事的时候就是方向盘。

三、回滚按钮比发布按钮值钱

三个动作里，最值钱的不是发布，是回滚。

回滚的第一个要求是快。从发现不对劲到恢复旧版判定，分钟级。这就决定了回滚不能是“从服务器重新下载旧模型”——得是本地随时待命的一个完整版本包。

第二个要求，是很多人栽过的坑：回滚不是退一个文件，是退一套东西。

检测模型的判定结果，是模型和配置一起算出来的。v2 的过杀阈值调到 0.62，是配合 v2 的特性调的；v1 的阈值是 0.55。要是回滚的时候只把模型文件退回去，阈值还停在 0.62，等于给 v1 装了 v2 的螺丝，白回。所以版本包必须是个快照：模型文件、判定阈值、前后处理参数、检测配置，捆在一起，一退全退。

上一篇讲训练集版本冻结，模型版本、数据版本对得上账。到这里凑成三元组：模型版本、数据版本、配置版本，三个号一起挂在设备上。谁都不能单独动。质量追溯的时候，三个号一起报出来：出事那天，这条线跑的是模型 v2.1、数据 D-0915、配置 C-88——这才叫说得清。

第三个要求是权限，而且要故意不对称。

发布，要审批。发布意味着变更，变更要品质和产线两边都点头，一个按钮两个人会签，缺一个不让点。回滚，不要审批。回滚意味着回到昨天还在正常工作的状态，现场工程师一个人就能点，点完系统记录一笔就行。

这条原则说出来朴素：回滚永远要比发布容易。让回滚也走三层审批，等于逼着现场工程师在“走流程”和“看着产线冒过杀”之间做选择——人都是选后者的，然后你就有了第二次四小时手动恢复。好的流程设计，是承认人心，顺着人性给出路。

落到产品上：设备本地至少留两个历史版本包，一键可回；每一次发布和回滚都进操作日志；每一条检测记录带上当时的模型版本号——上一篇的数据反哺讲了记录的价值，这里再加一层：版本号进记录，质量事故倒查的时候，“那批货是哪个版本检的”一句话就能答上来。

四、这套东西，别做成脚本，做成一张单子

前面三个动作讲完，剩最后一个问题：谁记得住这一整套？

答案是不靠记性，靠单子。发布这件事，产品形态不是按钮，是单子——一张发布单。

发布单上有什么？我拆给你看：

从哪版到哪版：模型 v2.0 到 v2.1，配置 C-87 到 C-88，明明白白。变更内容：这次动了什么，勾选项——数据加了一千二百张新批次样本、模型重训、阈值从 0.58 调到 0.62。灰度计划：复检三天，单线三天。验收门：漏检率不高于基线、过杀率偏差正负 0.5% 以内。回滚条件：过杀率超基线 1.5 个点，或连续两小时分歧样本人工复核不合格。责任人：谁提的、谁审的、谁执行。

这张单子走完审批，发布动作就是照单执行；出了事，单子就是事故记录的第一页。

为什么强调是单子不是脚本？我见过不少团队，上面说的影子跑、灰度、回滚全都做了——在算法工程师的笔记本上，一套 Python 脚本，跑得挺溜。问题不在于脚本不好使，在于脚本长在人身上。工程师离职、休假、或者单纯那天忘了，流程就断了。而发布单活在系统里：品质看得见、产线看得见、审计也看得见。脚本管的是这一次发布，单子管的是这家客户未来三年的两百次发布。

还有一个角色问题，说给做产品的同行听。在很多项目里，算法工程师眼里的模型，是一个准确率数字；而产线眼里的模型，是一个会影响良率、会影响判废、会被审计倒查的“部署物”。这两重视角之间的落差，就是产品经理的位置。把发布做成单子、把回滚做成按钮、把版本做成三元组，这些没有一个像素长在“算法”上，但它们决定了客户敢不敢把检测这件事，放心交给你的系统。

五、链条快齐了

回头看这个系列：（3）选设备做 POC，（4）把算子做成产品，（5）检测数据反哺制造端，（6）算法选型算三笔账，（7）标注数据怎么管，到这一篇模型怎么上线。检测系统从买回到迭代的主链条，基本走完了。

细心的读者可能注意到，这一篇里我反复在用几个数：漏检率、过杀率、复现性。这三个词说出来轻飘飘，真到验收的时候就吵成一锅粥：漏检率的分母是缺陷图还是缺陷点？过杀的账算谁头上？验收当天 99%，量产一个月 95%，这官司怎么打？

下一篇就写这个：检测算法的验收指标体系——漏检率、过杀率、复现性怎么定义、怎么测、怎么写进合同不吵架。

你如果经历过模型上线翻车，或者正在被验收指标扯皮，评论区说说，你的故事可能就是下一篇的案例。

（系列前篇：《我所了解的机器视觉检测产品应用（7）：标注数据怎么管？样本库、版本冻结，和 7:2:1 的门道》《（6）：深度学习还是传统算法？先别比准确率，算三笔账》）

专栏作家

互联网产品经理Mik，公众号：逆袭产品汪，人人都是产品经理专栏作家。专注于ToB领域产品，包括机器视觉、工业大数据、MES、ERP和物联网等方面。

本文原创发布于人人都是产品经理，未经许可，禁止转载

题图来自 Unsplash，基于 CC0 协议