模型在 Notebook 里满分，上线就崩：聊聊 ML 生产环境的坑

很多机器学习项目最诡异的地方在于：离线测试时指标好得惊人，结果一部署到生产环境就直接“猝死”。这种现象其实揭露了一个残酷的真相——很多人把 ML 当成了传统软件开发，觉得只要代码写好、模型训练完、部署上去就完事了。

其实这种“训练完就不管”的思维是最大的陷阱。模型不是静态的代码，它是活在数据里的，而生产环境的数据永远在变。

我总结了几个导致模型上线后性能暴跌的实战坑点：

• 数据漂移（Data Drift）与概念漂移（Concept Drift）： 这是最隐蔽的杀手。比如你训练模型时用的用户行为数据是去年的，但今年用户口味变了，或者某种诈骗手段升级了，模型还在用旧逻辑判断，结果自然是预测精度直线下降。
• 训练-预测不一致（Training-Serving Skew）： 离线训练时用的特征处理脚本，和在线推理时用的预处理逻辑哪怕有一丁点细微差别（比如缺失值填充方式不同），都会导致输入特征分布偏移，模型直接罢工。
• 基础设施的资源瓶颈： 在开发机上跑得飞快，到了生产环境面对高并发请求，延迟直接爆表，或者内存溢出导致服务崩溃，这时候模型再强也没用。
• 监控盲区： 很多团队只监控 CPU 和内存占用（系统监控），却不监控模型的预测分布（模型监控）。结果就是系统运行正常，但模型给出的预测值全是垃圾，直到业务方投诉才发现。

想要避免这些问题，必须把重心从单纯的“调参”转向 MLOps 的建设。一个完整的工作流至少得包含：实时特征存储、自动化的漂移检测以及闭环的重新训练机制。

如果你还在用 Jupyter Notebook 跑完就觉得项目结束了，那大概率你的模型已经在生产环境下进入倒计时了。