为什么你的预测模型上线就翻车？聊聊模型漂移和在线学习

去年Q3，我们团队给河北一家钢厂做了一个轧机轴承的预测性维护模型。离线测试的时候，准确率97.3%，F1分数0.91，客户CTO看了直点头，说"这个好，下周就上线"。

结果上线第12天，车间主任打电话过来，说你们这个模型怎么最近天天报故障，拆开一看轴承好好的。更狠的是，真正出问题的那台，它一个预警都没给。

我当时就懵了。

后来复盘查了好几天日志才发现，问题根本不在模型本身------是数据变了。钢厂9月份换了一批润滑脂供应商，振动信号的基线整体偏移了大概15%。模型还是那个模型，但它见过的世界已经不存在了。

说白了，这就是模型漂移（Model Drift）。

什么是模型漂移？别被教科书绕晕了

教科书里会给你讲一堆概念：协变量偏移、概念漂移、标签漂移......说实话，第一次看我也头大。我用自己的话翻译一下：

数据漂移（Data Drift）------输入的分布变了，但输入和输出的关系没变。比如钢厂换了润滑脂，振动信号整体偏高，但"高多少算故障"这个标准没变。

概念漂移（Concept Drift）------输入和输出的关系本身变了。比如设备运行了一年，轴承磨损累积，同样的振动幅值在去年是正常的，今年可能就该报警了。

你可能会问：这俩有啥区别，反正都是模型不好使了？

区别大了。数据漂移你可以通过重新校准基线来解决，相对简单。概念漂移才是真正的杀手------你的业务逻辑本身在变，模型必须跟着学新东西。

监控比建模更重要：上线第一天就该搭好的东西

我团队现在的规矩是：模型不上线则已，上线必须同步部署监控。用的是PSI（Population Stability Index），这个指标金融行业风控用了好多年，但工业领域用的人不多，我觉得完全可以搬过来。

PSI的核心思想很简单：把训练时的特征分布和当前线上数据的特征分布做对比，分布差异越大，PSI越高。一般经验值是：

PSI < 0.1：稳定，别管它
0.1 ≤ PSI < 0.25：有漂移迹象，关注一下
PSI ≥ 0.25：漂移严重，该动手了

python 复制代码

import numpy as np
import pandas as pd

def calculate_psi(expected, actual, buckets=10):
    """
    计算PSI（Population Stability Index）
    expected: 训练集特征值
    actual:   当前线上特征值
    buckets:  分箱数量
    """
    # 按训练集的分位数切分，确保每个桶样本量接近
    breakpoints = np.quantile(expected, np.linspace(0, 1, buckets + 1))
    breakpoints[0] = -np.inf
    breakpoints[-1] = np.inf

    expected_pct = np.histogram(expected, breakpoints)[0] / len(expected) + 1e-6
    actual_pct = np.histogram(actual, breakpoints)[0] / len(actual) + 1e-6

    psi = np.sum((actual_pct - expected_pct) * np.log(actual_pct / expected_pct))
    return psi

# 实际用法：每天凌晨跑一次，对比上周训练集和昨天线上数据
train_rms = pd.read_parquet('data/train_features.parquet')['vibration_rms'].values
yesterday_rms = pd.read_parquet('data/online_20260724.parquet')['vibration_rms'].values

psi = calculate_psi(train_rms, yesterday_rms)
print(f'振动RMS的PSI = {psi:.4f}')
if psi >= 0.25:
    print('⚠️ 漂移严重，触发模型更新流程')
elif psi >= 0.1:
    print('⚠️ 有漂移迹象，持续观察')

踩坑提醒 ：1e-6 那个平滑项别省。我有个同事图省事去掉了，结果某个桶线上数据是0，log(0)直接炸了，监控脚本崩溃，整整三天没人发现模型已经飘了。

在线学习：听起来美好，用起来要命

发现漂移之后怎么办？最直觉的答案是"让模型持续学习"------这就是在线学习（Online Learning）。

想法很好。但说实话，工业场景下做纯在线学习，坑多得能填满一个游泳池。

第一个坑：标签延迟。预测性维护的标签是"这个轴承到底有没有坏"，但你得等它真坏了才知道。可能是一周后，也可能是一个月后。这期间你拿什么更新模型？没标签的在线学习就是个伪命题。

第二个坑：灾难性遗忘。你喂新数据，模型就忘了旧数据。我用 River 0.21 做过一个在线随机森林的实验，新工况一进来，旧工况的预测准确率掉了20个百分点。

第三个坑：坏数据会把模型带沟里。传感器故障、数据采集中断、异常工况......在线学习会把这些全学进去。你得有非常强的数据质量过滤，否则模型越学越歪。

我的建议是：别做纯在线学习，做"定期增量重训练"。

具体来说就是：PSI触发告警 → 人工确认漂移原因 → 积累一批新数据（带标签的）→ 用增量数据加旧数据做重训练 → A/B测试新模型 → 确认效果后热更新。这套流程比纯在线学习慢，但稳。

python 复制代码

from river import tree, metrics
from river import preprocessing as pp

# 如果你非要做在线学习，River是Python里最成熟的库
# 这是一个Hoeffding Adaptive Tree的例子
model = pp.StandardScaler() | tree.HoeffdingAdaptiveTreeClassifier(
    grace_period=200,      # 看到200个样本才考虑分裂
    split_confidence=1e-5, # 分裂置信度，越小越保守
    drift_detector=tree.drift.ADWIN(delta=0.002)  # ADWIN检测概念漂移
)

acc = metrics.Accuracy()
# 模拟在线学习：一条一条喂
for x, y in online_stream:
    pred = model.predict_one(x)
    if pred is not None:
        acc.update(y, pred)
    model.learn_one(x, y)

print(f'在线准确率: {acc.get():.4f}')
# 注意：实际工业部署时，pred为None的阶段（冷启动期）可能有几小时
# 这段时间你得有兜底策略，比如用旧模型的预测结果

注意这里有个细节 ：grace_period 设太小，模型会在噪声上分裂，过拟合；设太大，模型反应慢，漂移来了迟迟不更新。我一般从200开始调，结合PSI告警的频率来平衡。

一个争议点：到底要不要自动触发重训练？

现在很多MLOps文章都在推"全自动模型更新pipeline"，PSI超阈值就自动触发重训练、自动部署。听着很酷。

但我反对。

原因很简单：工业现场的数据质量根本撑不起全自动。我见过太多案例------传感器松了导致振动数据异常，PSI飙到0.5，自动重训练触发，模型把异常数据学进去，上线后疯狂误报。本来只是传感器螺丝拧紧就解决的问题，最后演变成"AI模型不可靠"的信任危机。

所以我团队的流程是：PSI监控全自动 → 触发告警 → 工程师确认数据质量 → 手动决定是否重训练。慢一点，但不会出幺蛾子。

你说这不够"智能"？那等你被半夜叫起来回滚模型的时候，你就知道"稳"比"智能"重要一百倍。

工具链推荐

最后说两句工具链。我们现在的MLOps栈是这样的：

监控：Evidently 0.4.30 做数据漂移报告，Grafana 10.4 做实时PSI看板
实验管理：MLflow 2.11 记录每次重训练的参数和指标
模型部署：FastAPI + ONNX Runtime，热更新靠蓝绿部署
数据版本：DVC 管理训练数据快照，重训练时知道用的是哪版数据

这套组合不是最先进的，但每一步都有人盯着，出了问题能定位到具体环节。预测性维护这行，你模型翻车的代价不是丢几个点击率，是产线停机的真金白银。慎重点。

写在最后：模型漂移不是"会不会发生"的问题，是"什么时候发生"的问题。与其纠结怎么建一个永远不漂移的模型，不如老老实实把监控搭好，把重训练流程跑通。上线不是终点，是运维的起点。