我们在 Besttech 构建首个大型 ML pipeline 时出现的 5 件问题（以及我们如何修复它们）
Source: Dev.to
机器学习的 “Hello World” 很简单。你只需导入 Scikit‑Learn，在干净的 CSV 上拟合模型，就能得到一个不错的准确率。
而生产环境下的机器学习却是一场噩梦。
在 Besttech，我们最近把客户的预测分析模型从一堆混乱的本地 Jupyter Notebook 中迁移到了一个全自动、云原生的流水线。我们以为已经把全局规划好了。我们以为自己懂 MLOps。
结果我们错了。我们把很多东西弄坏了——而且是大事。过程中我们构建了一个强大的引擎，现在它可以毫不迟疑地处理数 TB 的数据。
我们弄坏了：时间概念（数据泄漏） ⏳
失败
我们最初的模型在训练期间表现惊人——准确率 98%。但部署到线上环境后，准确率骤降至 60%。
根本原因
我们不小心使用了在预测时不存在的特征进行训练（例如，用于月初流失模型的 “Total Monthly Spend”）。模型实际上通过看到未来数据在“作弊”。
解决方案
实现了严格的特征库（使用 Feast），为每个特征打上时间戳。创建训练集时，系统执行点时间正确的关联，确保模型只能看到当时可用的数据。
我们弄坏了：云费用（资源囤积） 💸
失败
我们为整个流水线——提取、清洗、训练和部署——都启动了巨大的 GPU 实例。
根本原因
流水线中 90% 的工作是简单的数据清洗（CPU 工作），但我们却一直在为昂贵的 GPU 付费。
解决方案
使用 Kubernetes 容器将各步骤解耦：
- ETL – 在廉价的高内存 CPU 节点上运行。
- Training – 启动 GPU 节点进行模型训练，训练完成后立即关闭。
- Inference – 在轻量级无服务器函数上运行。
结果：计算成本降低约 65%。
我们弄坏了：Python 依赖（经典的 “在我机器上可以运行”） 🐍
失败
数据科学家使用 pandas 1.3.0，而生产服务器上是 pandas 1.1.5。由于函数签名变化，流水线悄然崩溃。
解决方案
禁止手动环境配置，转向严格的 Docker 化。每个流水线步骤现在都在自己的 Docker 容器中运行，并使用冻结的 requirements.txt。只要容器能构建，代码就能运行——就这么简单。
我们弄坏了：信任（静默失败） 🤫
失败
某个源数据流出现故障，开始对特定列发送全零。流水线没有崩溃，而是把零值读入，训练出一个垃圾模型并部署。客户收到的预测毫无意义。
根本原因
测试只关注代码错误，而没有覆盖数据错误。
解决方案
在摄取层引入 Data Expectations，使用 Great Expectations，例如：
- 列
age是否在 18 到 100 之间？ transaction_value是否为非负数？- 空值比例是否 < 5%？
如果数据违反任何规则，流水线会停止并在 Besttech 的 Slack 频道发出警报，防止进一步损害。
我们弄坏了：反馈循环（模型漂移） 📉
失败
部署后，三个月后客户报告说预测每周都在变差。
根本原因
市场已经变化，静态模型不再匹配当前的数据分布。
解决方案
自动化重新训练循环。我们现在使用 Evidently AI 等工具监控漂移指标。当线上数据的统计分布相对于训练数据的偏差超过阈值时，会自动触发新的训练任务。流水线现在具备自我修复能力。
结论
构建模型是科学，构建流水线是工程。
在 Besttech，我们弥合了这两者的差距。我们不仅仅交给你一个 Notebook 并祝你好运；我们还搭建了那套凌乱、复杂、并不光鲜的基础设施，让你的智能系统持续运行。