这是智能化项目里最经典的一幕：验收时指标漂亮，三个月后业务方开始抱怨「不好用了」，半年后系统被搁置，最后结论是「AI 不靠谱」。但复盘下来，问题通常不在算法上——而在环境变了，模型没变。
漂移在工程上具体长什么样
「数据漂移」这个词听起来很学术，但它的现场表现非常朴素。
- 换了供应商：同一型号的设备，来料的表面反光率变了，视觉模型的分割边界开始偏
- 换了季节：环境温度与湿度改变，传感器的基线读数整体平移，异常判据失效
- 改了工艺：生产节拍提速，原本在静止状态下采集的样本变成了带运动模糊的样本
- 换了人：操作习惯变化，工件的摆放角度分布与训练集不再一致
- 传感器老化：漂移是缓慢累积的，在几个月内跨过了判定阈值，而没有任何一天看起来是「突然坏了」
这些变化都不是「故障」，因此监控系统的告警不会响。但模型的输入分布已经偏离了训练分布，效果衰减由此开始。
为什么这类问题总在交付后才暴露
因为在项目制的交付模式下，验证通常集中在两周到一个月。这个时间窗口太短，短到漂移现象根本来不及显现。而验收标准往往只看「当前准确率」，不看「准确率的稳定性」。
| 验收方式 | 看到了什么 | 漏掉了什么 |
|---|---|---|
| 离线测试集准确率 | 模型在历史数据上的静态表现 | 数据分布变化后的表现 |
| 短期现场试运行 | 当前环境下的可用性 | 季节性、批次性等慢变量的影响 |
| 功能清单逐项确认 | 功能是否实现 | 实现后的效果能否长期维持 |
把漂移变成可管理的常规动作
我们的做法是在第二阶段（闭环）把三件事制度化，而不是指望「出问题时再找人修」。
- 监控输入而不是只监控输出：持续统计输入数据的分布特征，与训练集基线做比对，偏离到阈值就预警
- 保留人工反馈通道：让现场操作者能以最低成本标记「这个判断不对」，这些标注是最高价值的再训练数据
- 把再训练做成例行流程：约定固定的校准周期与触发条件（如漂移预警、准确率跌破阈值），并保证模型下发可灰度、可回滚
把模型当成一次性的交付物，它一定会在几个月后失效；把模型当成一个需要持续维护的资产，它才会随时间变好。
给正在评估方案的人的三个问题
在签下一份智能化项目合同前，建议问清楚这三件事：
- 上线后，如何发现模型效果在下降？谁来发现？
- 再训练需要什么条件？数据从哪里来？周期是多久？
- 模型更新如何下发？出问题时能不能快速回滚到上一版？
如果对方对这三个问题答得很含糊，那么验收时的准确率数字，大概就是这套系统未来能交出的最好成绩。