模型漂移与再标定：什么时候必须重新训一遍

视觉系统上线之后的表现不是一条水平线，而通常是一条缓慢下滑的曲线。照明会老化、镜头会积灰、工装会磨损、来料会换代、工艺会微调——这些变化都不会触发任何报警，却持续侵蚀判定准确率。等到现场终于发觉「最近误报有点多」时，往往已经漂移了几周，而这几周的数据已经混进了追溯记录里。应对办法不是频繁重训（那样成本高且会引入新的不确定性），而是先分清是哪一类漂移：硬件条件的漂移靠清洁与重标定解决，数据分布的漂移才需要重新训练。分不清这一点，很容易用重训去解决一个脏镜头的问题。

两类漂移，先分清

区分方法其实很简单：拿一组固定的标准样本跑一遍，先看图像本身有没有变化。如果图像就已经变了（变暗、变糊、位置偏了），那是硬件漂移，调模型没有用；如果图像看起来一样但判定结果变了，才需要考虑数据层面。这组标准样本应当在系统上线时就固定下来——可以是几件标准工件，也可以是一批封存的图像，关键是每次复核都用同一组，这样才能比较。这项动作每次只要几分钟，却能在问题扩大之前发现它，是所有运维动作里投入产出比最高的一项。

什么时候真的需要重新训练

重新训练是有成本的：需要采集新数据、标注、训练、验证、再上线，还要承担新模型在老工况上表现退化的风险。因此它应该由明确的信号触发，而不是按固定周期无脑执行。常见的触发信号有三种：一是出现了训练集里从未覆盖过的新工况（新型号、新来料、新工装），且用阈值调整无法解决；二是按批次统计发现某几批的表现系统性变差，说明数据分布确实漂了；三是判据本身发生了变化，比如工艺要求把容忍范围收紧了。反过来，如果只是整体指标轻微下滑，而标准样本复核显示图像本身变了，那应该先做清洁与重标定，而不是重训。

• 新增数据要覆盖新工况：只把最近的数据全量喂进去，等于稀释掉旧工况的能力，模型会「学会新的、忘掉旧的」。
• 训练集与验证集要分开：验证集里必须包含老工况的样本，否则看不出退化。
• 上线前用标准样本回归：新模型必须先在标准样本上跑一遍，确认没有比旧模型差，再切到产线。
• 保留回退路径：新模型上线后要能快速回退到旧版本，这个能力应当在第一次重训之前就准备好。

版本记录：不写就等着扯皮

每一次清洁、重标定、阈值调整、重新训练，都会让系统的行为发生变化。如果这些变化没有版本记录，历史判定就失去了可解释性——同样一张图，上个月判合格这个月判不合格，却没人知道中间发生了什么，追溯时无法交代。因此模型版本与阈值版本必须写进每一条判定记录，这与回写字段设计里强调「阈值版本」是同一件事。版本记录另有一个好处：当现场抱怨「最近变差了」，可以直接拿版本切换的时间点去比对，很快就能确认是不是那次变更造成的，而不是从头排查。

运维周期的建议值

给一个参考节奏：标准样本复核对班次敏感的场景建议每周一次、其余场景每月一次；镜头与防尘窗清洁按现场粉尘浓度定，通常一到三个月；相机角度与焦点复校每季度一次，或在大修、搬迁之后立即执行；模型层面的重新评估建议每半年做一次，即使没有明显问题，也应当用最新的数据回看一次表现，为下一次变更做准备。这些周期不是硬性规定，但把它们写进运维约定，能让系统在两三年后仍然处于可用的状态，而不是变成一台「装了但没人信」的设备。关于厂内自建运维能力还是依赖供应商，可参考服务与响应约定。