大规模机器学习：在生产环境中管理多个模型

Source: Towards Data Science

在深入探讨可扩展性之前， 请随意阅读我关于生产就绪机器学习基础的介绍性文章：
Machine Learning in Production – What This Really Means

在我之前的文章中，我提到自己在行业里担任 AI 工程师已有 10 年。早期，我学到一个关键的教训：

笔记本中的模型只是一个数学假设。
只有当它的输出到达用户、驱动产品或产生收入时，它才有价值。

我已经向你展示了 单个 项目中“生产中的机器学习”是什么样子。
今天，话题转向 规模：同时管理 数十甚至上百 个机器学习项目。

演进过程：
• Sandbox Era → Infrastructure Era
• 部署模型现在是一项不可或缺的技能。
• 真正的挑战在于确保庞大的模型组合能够 可靠 且 安全 地运行。

1. 离开沙盒：可用性策略

要理解大规模机器学习，首先需要摆脱“沙盒”思维。在沙盒中，你只有静态数据和单一模型；如果模型漂移，你会看到它，停下来并修复它。

当你转向 Scale Mode 时，你不再只管理一个模型——而是管理一个 模型组合。这时 CAP 定理（一致性、可用性、分区容错）就成为你的现实。

• 在单模型设置下，你可以尝试平衡这三种权衡。
• 在规模化时，三项指标不可能全部完美。
• 你必须选择重点，而往往 可用性 成为首要优先级。

为什么优先考虑可用性？

• 在运行 100 个模型时，总会有东西 一直 出现故障。
• 如果每次模型漂移都停止服务，你的产品将会离线 ≈ 50 % 的时间。

由于我们无法停止服务，我们会设计模型 优雅失效。

示例：推荐系统

用户保持满意，系统保持可用，即使结果并非最佳。要实现这一点，你需要知道 何时 触发回退——这也将我们引向大规模环境中最大的挑战：监控。

2. 监控挑战以及传统指标在规模化时失效的原因

在大规模运行时，人们往往会误以为只要监控 accuracy（准确率）就能确保系统“干净地失败”。实际上，仅靠准确率是不够的，原因如下：

1. 缺乏人类共识

• 在计算机视觉等领域，真实标签通常很明确（例如 “dog” 与 “not‑dog”）。
• 在推荐或广告排序系统中，根本不存在统一的 “金标准”。
  • 如果用户没有点击，是模型的错，还是用户当时根本不感兴趣？

2. 特征工程陷阱

• 由于无法用单一指标衡量 “真相”，我们往往会过度补偿。
• 各团队常常会添加 数百个特征，希望 “更多数据” 能解决底层的不确定性。

3. 理论上限

• 团队追求边际提升（例如 0.1 % 的准确率提升），却没有确认数据是否已经噪声太大，无法支撑进一步的进步。
• 这导致在追逐一个看不见的性能上限。

---

为什么这很重要

因为在大规模环境下监控 “真相” 几乎不可能——会产生 dead zones（警报永不触发的死区），我们无法依赖简单的基于指标的报警来发现故障。因此必须优先考虑：

• 可用性 – 即使模型性能下降，也要保证系统仍然可用。
• 安全回退 – 设计能够在指标无法提供明确指引时，优雅地处理 “模糊” 故障的机制。

通过聚焦这些原则，我们能够构建能够在模糊、指标盲区的故障中仍然存活的系统。

3. 工程壁垒怎么办

现在我们已经讨论了策略和监控挑战，但由于尚未解决基础设施问题，仍然无法实现规模化。规模化同样需要工程技能，正如数据科学技能一样重要。

没有坚实、可靠的基础设施，就无法谈论规模化。由于模型复杂且 可用性 是我们的首要任务，我们必须认真考虑所搭建的架构。

在这个阶段，我的诚恳建议是让自己身边有一支——或是几位——在构建大规模基础设施方面经验丰富的团队或个人。你不一定需要庞大的集群或超级计算机，但需要考虑以下三个执行基本要点：

• Cloud vs. Device – 服务器提供强大算力且易于监控，但成本高昂。你的选择完全取决于成本与控制之间的权衡。
• The Hardware – 不能把所有模型都放在 GPU 上，否则会破产。采用分层策略：在廉价 CPU 上运行简单的“后备”模型，将昂贵的 GPU 留给重量级的“赚钱”模型。
• Optimization – 在大规模环境下，后备机制的 1 秒延迟就是一次失败。你不再只是写 Python；必须为特定芯片编译并优化代码，以便“清洁失败”开关在毫秒级完成。

4. 小心标签泄漏

您已经预见了故障，提升了可用性，整理了监控，并搭建了基础设施。您可能认为自己终于可以掌握可扩展性了。还没有。
如果您从未在真实环境中工作过，有一个问题是您根本无法预料的：标签泄漏。即使工程做到完美，泄漏也会毁掉您的策略以及任何运行多个模型的系统。

为什么重要

• 在单个项目中，您可能会在 notebook 中发现泄漏。
• 在规模化时——数据来自数十条管道——泄漏几乎变得不可见。

流失示例

想象您在预测哪些用户会取消订阅。您的训练数据中包含一个特征 Last_Login_Date。模型看起来完美，F1 分数达到 99 %。

实际发生的情况：

1. 数据库团队设置了一个触发器，在用户点击“取消”时立即清空 Last_Login_Date 字段。
2. 您的模型看到 NULL 登录日期，就推断：“啊哈！他们取消了！”

在生产环境中，模型必须在用户取消之前，即在字段变为 NULL 之前进行预测。模型不经意间在使用来自未来的答案。

这只是一个简单的示例，但在复杂的实时系统（例如 IoT）中，标签泄漏极其难以检测。避免它的唯一办法是从一开始就意识到这个问题。

我的建议

• 特征延迟监控 – 不仅要监控特征的值，还要监控它相对于事件时间戳的写入时间。
• 毫秒测试 – 始终问自己：“在预测的确切时刻，这一特定数据库行是否已经包含了该值？”

这些问题很简单，但评估它们的最佳时机是设计阶段，在您编写任何生产代码之前。

5. 最后，人类环路

最后一块拼图是 问责制。在大规模下，我们的指标模糊，基础设施复杂，数据泄漏，所以我们需要一个“安全网”。

实践

• 影子部署 – 在大规模时是强制性的。部署 Model B 但不要向用户暴露其结果。让它在“影子”中运行一周，将其预测与最终的“真实”进行比较。如果它证明是稳定的，就提升为“线上”。

• 人机交互环路 – 对于高风险模型，保持一个小团队审计“安全默认”。如果系统连续三天回退到“最受欢迎的项目”，则必须有人类调查 为什么 主模型没有恢复。

在大规模机器学习工作前的快速回顾

1. 首要可用性 – 因为我们不可能完美，所以保持在线并安全失败。
2. 模糊指标 – 大规模监控噪声大；传统指标不可靠。
3. 稳健基础设施 – 构建云/硬件流水线，使安全故障快速发生。
4. 防止数据泄漏 – 防止“作弊”数据导致模糊指标看起来不切实际地好。
5. 影子部署 – 在模型触达客户之前证明其安全。

你的规模只有在安全网足够好时才有意义。别让你的工作成为 87% 失败项目中的一员。

与我联系

• LinkedIn: Sabrine Bendimerad
• Medium: sabrine.bendimerad1
• Instagram: tinyurl.com/datailearn