1. 工业缺陷检测的底层逻辑与方案选型1.1 为什么工业缺陷检测和通用目标检测是两码事做过通用目标检测的人第一次接触工业缺陷检测最容易犯的错误就是把它当成“COCO数据集换个类别”来做。我刚开始也这么想结果第一个项目就翻车了——模型在验证集上mAP跑到0.85上线后漏检率却高得离谱产线班长直接打电话过来骂人。工业缺陷检测和通用目标检测的本质区别在于三点。第一缺陷样本极度稀缺。一条产线一天可能产出十万个零件其中缺陷件只有几十个甚至几个而且缺陷类型还会随批次波动。第二缺陷的形态极其细微。划痕可能只有几个像素宽气泡可能和背景灰度差不到10个灰度级这和COCO里那些占据画面三分之一的大目标完全不是一个难度量级。第三评价标准完全不同。通用检测看mAP工业检测看的是漏检率和过杀率这两个指标直接和产线良率、成本挂钩漏检一个缺陷件流到客户手里可能就是几十万的索赔。所以做工业缺陷检测思路要从“检测得准”切换到“不漏检、少过杀、能落地”。这三个词贯穿整个项目的始终后面所有的技术选型、训练策略、部署方案都是围绕它们展开的。1.2 小样本训练的核心矛盾与解决路径小样本训练的核心矛盾就一句话模型参数量大缺陷样本少强行训练必然过拟合。你拿一个YOLO模型几百万甚至上千万参数喂给它几十张缺陷图它能把训练集背得滚瓜烂熟但一上测试集就原形毕露。解决这个矛盾业界目前有几条主流路径我按实际项目中的优先级排一下。第一条路是数据增强做到极致。注意这里的增强不是随便翻转旋转就完事了。工业缺陷有很强的方向性和纹理特征比如金属表面的划痕你水平翻转后划痕方向变了但光照反射方向没变模型学到的就是错误特征。我常用的增强组合是随机亮度对比度扰动模拟光照变化、高斯噪声模拟传感器噪声、随机擦除模拟遮挡、以及基于缺陷形态的定向增强比如划痕类缺陷做沿划痕方向的拉伸。Mosaic和MixUp在工业场景要慎用因为拼接后的图像可能产生不存在的缺陷形态反而引入噪声。第二条路是迁移学习加分层冻结。用COCO或ImageNet预训练的权重做初始化然后冻结backbone的前几层只训练后面的层。具体冻多少层我的经验是缺陷样本少于100张时冻结backbone全部只训练neck和head样本在100到500张之间时解冻backbone最后两个stage样本超过500张再考虑全量微调。这个策略在多个项目上验证过比直接全量微调稳定得多。第三条路是异常检测算法做补充。当缺陷样本实在少到无法训练监督模型时可以考虑用无监督或半监督的异常检测方法比如基于特征重建的PatchCore、基于归一化流的FastFlow等。这类方法只需要正常样本就能训练对未知缺陷类型也有一定的检出能力。但它们的缺点是过杀率通常偏高适合作为监督模型的补充而不是替代。1.3 YOLO系列在工业场景的选型考量YOLO系列是目前工业缺陷检测落地最主流的框架没有之一。原因很简单速度快、精度够用、部署生态成熟。但YOLOv5、v8、v9、v10、v11这么多版本到底选哪个这里面有讲究。我的选型逻辑是这样的。如果项目对推理速度要求极高比如产线节拍要求单帧推理在10ms以内优先考虑YOLOv8n或YOLOv10n这种nano版本配合TensorRT INT8量化在T4上跑640分辨率可以轻松做到几百FPS。如果精度优先缺陷又特别细微那就上YOLOv8m或YOLOv11m但要做好推理速度下降的心理准备。这里重点说一下Efficient Head YOLO这个改进方向。传统YOLO的检测头是解耦的分类和回归各走各的分支参数量不小。Efficient Head的思路是把检测头做轻量化用共享卷积加分组卷积的方式减少参数量同时保持精度。我在一个PCB缺陷检测项目上试过把YOLOv8的检测头换成Efficient Head后参数量降了约30%推理速度提升15%左右mAP只掉了0.3个点。对于边缘设备部署来说这个 trade-off 非常划算。还有一个值得关注的是NWDNormalized Wasserstein Distance改进YOLO。工业缺陷里有很多小目标传统IoU对小目标的定位误差非常敏感几个像素的偏移就可能导致IoU从0.7掉到0.3。NWD用高斯分布建模边界框把位置差异转化为分布距离对小目标的定位更鲁棒。我在一个连接器引脚缺陷项目上对比过用NWD替换IoU后小目标召回率提升了约8个百分点效果非常明显。2. 小样本训练全流程拆解与实操要点2.1 数据采集与标注的坑数据采集这一步很多人觉得就是拿相机拍拍照没什么技术含量。但我要说数据采集的质量直接决定了项目的上限后面模型再强也救不回来。首先是成像方案。工业缺陷检测的成像核心是让缺陷和背景的对比度最大化。我常用的手段包括同轴光适合检测平面划痕、低角度环形光适合检测凹凸缺陷、背光适合检测孔洞和透明件、以及多角度组合光。有一次做玻璃盖板缺陷检测用普通环形光怎么都拍不出微裂纹后来换成暗场照明裂纹立刻清晰可见。所以成像方案一定要在项目初期就反复调试不要等到模型训练不出来才回头怀疑数据。其次是标注规范。工业缺陷的标注比通用目标检测严格得多。我要求标注员遵循几条铁律边界框要紧贴缺陷外沿不能多标也不能少标对于模糊不清、无法确定是否为缺陷的区域统一标为“不确定”训练时忽略对于同一区域有多种缺陷的情况分别标注不同类别不要合并。另外标注一致性检查非常重要我通常会随机抽10%的标注结果做交叉复核如果一致性低于95%就要重新培训标注员。还有一个容易被忽视的点是负样本采集。很多人只采集缺陷样本正常样本随便拍几张就完事。但实际上负样本的质量直接影响过杀率。我通常会采集至少和缺陷样本等量的正常样本而且要覆盖不同的光照条件、不同的产品批次、不同的工位状态。这样才能让模型学到“什么是正常的”而不是把所有没见过的纹理都当成缺陷。2.2 数据增强策略的定向设计前面提到了数据增强的重要性这里展开讲一下具体怎么设计。工业缺陷检测的数据增强核心原则是增强后的图像必须符合真实产线的物理规律。什么意思就是你增强出来的缺陷在现实中是可能出现的。比如你做一个金属表面的缺陷检测你把图像旋转90度划痕方向变了但光照方向没变这在现实中是不可能的模型学到的就是错误特征。我常用的增强组合如下表所示增强方法参数设置适用场景注意事项随机亮度对比度亮度±20%对比度±15%所有场景模拟光照波动高斯噪声sigma0.01~0.05所有场景模拟传感器噪声随机擦除面积比0.02~0.1有遮挡场景模拟灰尘、遮挡定向拉伸沿缺陷方向1.1~1.3倍划痕类缺陷保持方向一致性弹性变形alpha50, sigma5柔性材料模拟形变色彩抖动色调±10饱和度±20%彩色相机模拟色温变化Mosaic和MixUp我一般不用原因前面说了会引入不存在的缺陷形态。但有一个例外当缺陷样本极少少于50张时可以谨慎使用Mosaic但要把拼接后的图像人工过一遍剔除明显不合理的样本。另外Copy-Paste增强在小样本场景下非常有效。具体做法是把缺陷区域抠出来随机粘贴到正常样本的不同位置。这样可以在不增加新缺陷形态的前提下大幅增加缺陷样本的数量和位置多样性。我在一个只有30张缺陷图的项目上用Copy-Paste把缺陷样本扩充到300张模型召回率从60%提升到85%以上。2.3 模型训练的关键参数与技巧小样本训练的参数设置和常规训练有很大不同核心思路是降低学习率、增加正则化、早停要果断。学习率方面我通常从预训练模型的默认学习率除以10开始。比如YOLOv8默认lr0是0.01小样本场景我从0.001开始配合余弦退火调度。如果训练过程中loss震荡明显再降到0.0005。这里有个经验小样本训练宁可学习率低一点、训练轮次多一点也不要学习率高导致模型在少数样本上反复震荡。正则化方面weight_decay我通常设到0.001~0.005比默认值高一个量级。Dropout在YOLO里默认没有但可以在neck部分手动加rate设0.1~0.2。另外标签平滑label smoothing在小样本场景下很有用把分类标签从0/1改成0.05/0.95可以防止模型对少数样本过度自信。早停策略要果断。我通常设patience30如果30个epoch验证集指标没有提升就停止训练。但这里有个坑小样本场景下验证集本身也很小指标波动大可能连续几个epoch不提升然后又突然提升。所以我会同时监控训练loss和验证loss如果训练loss持续下降但验证loss开始上升那就是过拟合的信号果断停。还有一个技巧是EMA指数移动平均。YOLO默认开启EMA但在小样本场景下EMA的decay参数可以调小一点比如从0.9999调到0.999让模型更快地适应新数据。这个改动很小但在几个项目上都带来了1~2个点的召回率提升。2.4 BN层崩溃的排查与解决“yolo训练中bn崩溃”是热搜里经常出现的问题我在实际项目中也遇到过好几次。BN崩溃的典型表现是训练过程中loss突然变成NaN或者验证集指标断崖式下跌。BN崩溃的根本原因是小批量统计量不稳定。BN层在训练时用当前batch的均值和方差做归一化如果batch size太小比如小于8或者某个batch里的样本分布和整体差异太大统计量就会剧烈波动导致梯度爆炸。解决方法有几个。第一增大batch size。如果显存不够可以用梯度累积比如batch size设4累积4次等效batch size就是16。第二改用GroupNorm或SyncBN。GroupNorm不依赖batch统计量在小batch下更稳定。第三冻结BN层。如果用的是预训练模型可以把backbone的BN层冻结只训练后面的层。第四降低学习率。BN崩溃往往伴随着梯度爆炸降低学习率可以缓解。我在一个项目上遇到过BN崩溃排查了半天发现是数据增强里的随机擦除把某个batch的图像擦得只剩背景了导致该batch的统计量和整体差异巨大。后来把随机擦除的面积比上限从0.4降到0.1问题就解决了。所以遇到BN崩溃除了调模型参数也要回头检查数据增强策略。3. 漏检控制的核心技术与落地实践3.1 漏检率的定义与度量陷阱漏检控制的第一步是把漏检率定义清楚。听起来很简单但实际项目中我见过太多因为定义不一致导致的扯皮。漏检率通常定义为漏检缺陷数 / 总缺陷数。但这里有几个陷阱。第一缺陷的计数单位是什么一个零件上有三条划痕算一个缺陷还是三个如果算三个那漏检一条就算漏检如果算一个那漏检两条但检出第三条算不算漏检这个必须在项目初期和产线、质量部门对齐。第二置信度阈值怎么定模型输出的是概率你设0.5和设0.3漏检率能差好几个点。我的做法是先定一个可接受的过杀率上限比如5%然后在这个约束下找使漏检率最低的阈值。第三测试集怎么构建如果测试集里缺陷样本太少漏检率的置信区间会非常宽今天测出来2%明天可能就变成5%。我通常要求测试集至少包含200个缺陷样本这样漏检率的95%置信区间大约在±3%以内。3.2 从损失函数层面抑制漏检漏检的本质是模型对缺陷的响应不够强或者被背景抑制了。从损失函数层面有几个手段可以直接抑制漏检。第一个是提高正样本的损失权重。YOLO默认的分类损失和回归损失权重是固定的但在漏检敏感的场景下可以把正样本的分类损失权重调高比如从1.0调到2.0。这样模型会更关注缺陷样本减少漏检。但要注意权重调太高会导致过杀率上升需要权衡。第二个是使用Focal Loss的变体。Focal Loss本身是为了解决正负样本不平衡但标准Focal Loss的alpha参数是固定的。在漏检敏感场景下可以把alpha调高比如从0.25调到0.5让正样本的损失占比更大。更进一步可以用Asymmetric Loss对正样本和负样本分别设置不同的聚焦参数正样本用较小的gamma比如1.0负样本用较大的gamma比如4.0这样既关注难正样本又抑制易负样本。第三个是NWD损失替代IoU损失。前面提到了NWD对小目标定位更鲁棒其实它对漏检也有帮助。因为NWD的梯度更平滑小目标的定位误差不会导致梯度消失模型能持续学习小缺陷的特征。我在一个连接器项目上对比过用NWD替换CIoU后小目标漏检率从12%降到5%左右。3.3 后处理阶段的漏检补救模型输出之后后处理阶段还有机会补救漏检。常用的手段包括多尺度测试TTA。把输入图像缩放到不同尺度分别推理然后融合结果。小缺陷在放大尺度下更容易被检出大缺陷在缩小尺度下上下文信息更丰富。TTA通常能带来1~3个点的召回率提升代价是推理时间翻倍。如果产线节拍允许这是一个性价比很高的手段。滑动窗口推理。对于高分辨率图像比如4K直接缩放到640会丢失大量细节。滑动窗口把图像切成多个640x640的patch分别推理然后合并结果。这样小缺陷不会被缩放丢失但要注意patch之间的重叠区域要做NMS去重。我通常设重叠率为20%~30%既能保证不漏又不会引入太多重复框。低阈值后过滤。推理时把置信度阈值设低比如0.1让模型输出更多候选框然后用一个轻量级的分类器或规则引擎做二次过滤。比如对于划痕类缺陷可以用形态学操作检查候选框内的区域是否呈线状对于气泡类缺陷可以检查是否呈圆形且内部灰度均匀。这样可以在不增加漏检的前提下把过杀率压下来。3.4 漏检与过杀的平衡艺术漏检和过杀是一对矛盾体降低漏检通常意味着提高过杀反之亦然。实际项目中不存在同时让漏检率和过杀率都极低的完美模型只有根据业务需求找到最佳平衡点。我的做法是画一条P-R曲线Precision-Recall曲线然后根据业务需求选工作点。如果漏检一个缺陷的代价是1000元过杀一个良品的代价是10元那显然应该选高召回率的工作点哪怕过杀率到10%也划算。反过来如果过杀会导致产线频繁停机那就要选高精确率的工作点。具体操作上我会在验证集上跑一遍模型得到所有候选框的置信度和IoU然后画P-R曲线。在曲线上标注几个关键点漏检率0时的过杀率、过杀率5%时的漏检率、以及F1最大的点。然后和产线、质量部门一起决定选哪个点。这个决策过程一定要有业务方参与不能由算法工程师拍脑袋决定。还有一个技巧是分级报警。把模型输出分成三级高置信度0.8直接报警停机中置信度0.4~0.8标记为待复核低置信度0.4忽略。这样既不会漏掉高置信度的缺陷又不会因为低置信度的噪声频繁停机。待复核的样本可以人工快速过一遍或者用更复杂的模型做二次判断。4. 部署落地与性能优化实战4.1 TensorRT加速与多路视频流支持工业缺陷检测最终要落到产线上推理速度是硬指标。TensorRT是目前NVIDIA平台上的首选推理加速方案我以T4显卡、YOLO 640分辨率、1080p25帧的视频流为例算一下能支持多少路。先看单路推理耗时。YOLOv8n在T4上用TensorRT FP16推理640x640输入单帧耗时大约在3~5ms。加上前后处理图像缩放、NMS等单路总耗时大约8~10ms。1080p25帧的视频流每帧间隔40ms所以单路推理只占用了约25%的GPU时间。理论上T4可以支持3~4路。但实际项目中还要考虑视频解码、内存拷贝、CPU预处理等开销我通常按理论值的60%~70%来估算也就是2~3路比较稳妥。如果用INT8量化单帧耗时可以降到2~3ms总耗时5~6ms理论上可以支持6~8路。但INT8量化需要校准集而且精度会有一定损失。我的经验是如果缺陷对比度高、形态规则INT8量化后精度损失在1个点以内可以接受如果缺陷细微、背景复杂建议还是用FP16。多路视频流的部署架构我通常用生产者-消费者模式。每路视频流一个解码线程解码后的帧放入队列一个推理线程从队列取帧批量推理推理结果放入结果队列由后处理线程消费。这样解码、推理、后处理并行GPU利用率最高。注意队列长度要设上限防止内存溢出。4.2 一键部署脚本的设计思路“一键部署脚本”是热搜里经常出现的需求我在每个项目交付时都会写一个。核心思路是把环境配置、模型转换、服务启动全部自动化让产线人员只需要执行一条命令就能跑起来。脚本通常包含以下步骤#!/bin/bash # 1. 检查环境 check_gpu() { if ! command -v nvidia-smi /dev/null; then echo 未检测到NVIDIA驱动 exit 1 fi } # 2. 安装依赖 install_deps() { pip install -r requirements.txt -i https://pypi.tuna.tsinghua.edu.cn/simple } # 3. 转换模型 convert_model() { python export.py --weights best.pt --include engine --device 0 --half } # 4. 启动服务 start_service() { nohup python infer_server.py --engine best.engine --source rtsp://xxx --conf 0.3 log.txt 21 }这里有几个坑要注意。第一依赖版本要锁死。TensorRT、PyTorch、CUDA的版本兼容性非常敏感我通常在requirements.txt里写死版本号比如torch2.1.0cu118。第二模型转换要在目标机器上做。TensorRT引擎和GPU架构绑定在A100上转换的引擎不能直接在T4上用。第三服务要加守护进程。产线环境可能断电重启用systemd或supervisor做守护保证服务异常退出后能自动拉起。4.3 产线环境下的稳定性保障实验室里跑得好的模型到产线上可能各种问题。我总结了几条产线环境下的稳定性保障经验。光照稳定性。产线的光照条件可能随环境光、灯具老化而变化。我通常会在相机旁加一个标准色卡每隔一段时间拍一张用色卡的颜色值做白平衡校正。另外模型训练时要加入足够的光照增强让模型对光照变化鲁棒。相机稳定性。工业相机长时间运行可能发热导致图像噪声增加。我通常会在相机旁加散热风扇并定期检查相机的暗场噪声。如果暗场噪声明显增加说明相机需要维护了。模型漂移监控。产线换批次、换材料后模型性能可能下降。我通常会在产线上定期抽检把抽检结果和模型输出对比如果发现漏检率或过杀率明显上升就触发模型重新训练。这个监控机制非常重要很多项目上线后就不管了结果几个月后模型性能严重下降才发现。日志与回溯。所有推理结果、原始图像、模型版本都要记录日志至少保存一个月。这样出现漏检投诉时可以回溯当时的图像和模型输出分析是模型问题还是成像问题。我通常用SQLite或轻量级时序数据库存日志每天自动清理过期数据。4.4 常见问题速查表问题现象可能原因排查方法解决方案训练loss变NaNBN崩溃/学习率过高检查batch size和lr增大batch/降低lr/冻结BN验证集指标震荡验证集太小/过拟合检查验证集样本量增加验证集/加正则化/早停小目标漏检严重输入分辨率不够/IoU敏感检查小目标像素尺寸提高分辨率/用NWD损失/TTA过杀率偏高负样本不足/阈值过低检查负样本数量增加负样本/提高阈值/后过滤推理速度慢未用TensorRT/输入分辨率高检查推理后端TensorRT FP16/INT8/降低分辨率多路视频卡顿解码和推理未并行检查线程模型生产者-消费者模式/队列缓冲模型上线后性能下降数据漂移/光照变化对比新旧数据分布定期重训练/加光照校正部署脚本报错依赖版本不兼容检查CUDA/TensorRT版本锁死版本/目标机转换模型5. 异常检测算法的补充与融合5.1 什么时候该用异常检测监督式缺陷检测有一个前提你知道缺陷长什么样。但实际产线上经常出现新的缺陷类型或者缺陷样本少到无法训练监督模型。这时候就需要异常检测算法来补充。异常检测的核心思路是只学习正常样本的分布任何偏离正常分布的样本都判为异常。这样不需要缺陷样本就能训练对未知缺陷类型也有检出能力。但代价是过杀率通常偏高因为正常样本的多样性很难被完全覆盖。我通常在以下场景引入异常检测项目初期缺陷样本少于50张先用异常检测快速上线同时收集缺陷样本产线出现新缺陷类型监督模型漏检严重用异常检测做兜底以及作为监督模型的补充两个模型的输出做融合降低漏检率。5.2 主流异常检测算法对比目前工业异常检测的主流算法有几类我按实际项目中的使用体验排一下。PatchCore是基于特征记忆库的方法。它用预训练CNN提取正常样本的特征存到一个记忆库里推理时计算测试样本特征和记忆库的最近邻距离距离超过阈值就判为异常。优点是训练快不需要梯度下降、对小缺陷敏感缺点是记忆库占用内存大推理速度随正常样本数量增加而下降。我通常用coreset采样把记忆库压缩到原来的10%精度损失很小。FastFlow是基于归一化流的方法。它学习一个从正常样本分布到标准正态分布的可逆变换推理时计算测试样本的似然低似然判为异常。优点是推理速度快、内存占用小缺点是对复杂纹理的建模能力有限。适合纹理规则、缺陷对比度高的场景。DRAEM是基于重建的方法。它用编码器-解码器结构重建正常样本推理时计算重建误差误差大的区域判为异常。优点是对各种缺陷类型都有一定检出能力缺点是重建质量依赖训练数据正常样本多样性不足时重建效果差。我的选型建议是如果正常样本充足200张优先用PatchCore如果推理速度要求高用FastFlow如果缺陷类型复杂多样用DRAEM。实际项目中我经常把PatchCore和监督YOLO融合两个模型的输出做加权漏检率能再降2~3个点。5.3 监督模型与异常检测的融合策略融合策略有三种我按复杂度从低到高排。第一种是级联融合。先用监督模型推理如果监督模型的最高置信度低于某个阈值比如0.3再用异常检测模型做二次判断。这样只在监督模型不确定时才调用异常检测推理开销小。但缺点是如果监督模型给出了高置信度的错误结果漏检但置信度高异常检测就没有机会介入。第二种是并行融合。两个模型同时推理输出做加权平均或投票。权重的确定可以用验证集上的漏检率和过杀率来优化。这种策略漏检率最低但推理开销翻倍。第三种是特征级融合。把监督模型和异常检测模型的特征拼接再训练一个轻量级的分类器做最终判断。这种策略效果最好但实现复杂度最高需要重新训练分类器。我在实际项目中用得最多的是并行融合因为工业场景对漏检率的要求通常很苛刻推理开销翻倍可以接受。权重方面我通常给监督模型0.7异常检测0.3这个比例在多个项目上验证过比较均衡。6. 从项目实战中沉淀的经验6.1 数据比模型重要这句话听起来像废话但真正做项目时很多人还是把80%的时间花在调模型上只花20%的时间在数据上。我的经验是反过来80%的时间花在数据采集、标注、增强上20%的时间调模型。一个真实的案例我在一个手机壳缺陷检测项目上模型换了三代从YOLOv5换到YOLOv8再到YOLOv11mAP从0.82提升到0.86提升很有限。后来花了两周时间重新设计成像方案把暗场照明换成同轴光缺陷对比度大幅提升同样的YOLOv5模型mAP直接到0.93。所以数据质量的上限决定了模型的上限模型只是逼近这个上限。6.2 漏检控制要从项目第一天开始漏检控制不是模型训练完之后才考虑的事情而是要从项目第一天就贯穿始终。数据采集时就要考虑缺陷的多样性标注时就要考虑边界框的精确性模型选型时就要考虑小目标的检测能力损失函数设计时就要考虑正样本的权重后处理时就要考虑多尺度融合。每一个环节都在影响最终的漏检率。我见过太多项目前期不关注漏检模型训练完上线后发现漏检严重再回头改成本高得多。所以我的建议是在项目启动会上就把漏检率目标定下来然后倒推每个环节的要求。6.3 产线验证不可跳过实验室环境和产线环境差异巨大。实验室里光照稳定、相机固定、产品干净产线上光照波动、相机震动、产品有油污灰尘。我见过太多模型在实验室里表现完美一到产线上就各种问题。所以我的原则是模型在实验室验证通过后必须到产线上做至少一周的试运行。试运行期间要记录所有推理结果和原始图像每天分析漏检和过杀案例找出规律。通常试运行第一周会发现很多实验室里想不到的问题比如某个工位的光照特别暗、某个批次的产品有特殊纹理、某个时段的环境光变化剧烈。这些问题解决后模型才能真正稳定运行。6.4 持续迭代是常态工业缺陷检测不是一锤子买卖而是一个持续迭代的过程。产线换材料、换工艺、换批次缺陷的形态和分布都会变化。所以模型上线后要建立持续迭代机制定期抽检、收集新样本、重新训练、灰度发布。我通常建议客户每季度做一次模型评估每半年做一次重训练。如果产线变化频繁迭代周期还要缩短。重训练时不要完全抛弃旧模型而是用旧模型做初始化加入新数据做微调这样既能适应新数据又不会遗忘旧知识。最后分享一个小技巧在产线上部署一个影子模型用新数据持续训练但不参与实际推理定期对比影子模型和线上模型的输出。如果影子模型在近期数据上明显优于线上模型就触发模型更新。这样可以在不影响产线的前提下持续监控模型性能及时发现性能下降。