简介

一旦您将机器学习模型部署到生产环境中，很快就会发现工作还没有结束。

在许多方面，旅程才刚刚开始。你怎么知道你的模型的行为是否符合你的预期？下周/月/年，当客户（或欺诈者）行为发生变化并且您的训练数据过时时呢？这些都是复杂的挑战，而且机器学习监控在工具和技术方面都是一个快速发展的领域。似乎这还不够，监控是一项真正的跨学科工作，但“监控”一词在数据科学、工程、DevOps 和业务中可能意味着不同的东西。鉴于这种复杂性和模糊性的强硬结合，许多数据科学家和机器学习 (ML) 工程师对监控感到不确定也就不足为奇了。

本综合指南旨在至少让您了解在生产中监控机器学习模型的复杂性来自何方，为什么它很重要，此外还将为实施您自己的机器学习监控解决方案提供一个切实可行的起点。如果您正在寻找示例代码、教程和示例项目，您可能会对我们专门针对该主题的在线课程感兴趣：测试和监控机器学习模型部署。

目录

1. 机器学习系统生命周期
2. 是什么让机器学习系统监控变得困难
3. 为什么需要监控
4. 监控机器学习系统的关键原则
5. 了解机器学习风险管理的范围
6. 数据科学监控问题
7. 运营监控问题
8. 将 Ops 和 DS 结合在一起 - Prometheus 和 Grafana 的 Metrics
9. 将 Ops 和 DS 结合在一起 - 日志
10. 不断变化的局势

1. 机器学习系统生命周期

机器学习模型的监控是指我们从数据科学和运营角度跟踪和了解生产中模型性能的方式。 不充分的监控可能导致不正确的模型在生产中未经检查，过时的模型停止增加业务价值，或者模型中的细微错误随着时间的推移而出现并且永远不会被发现。 当 ML 成为您业务的核心时，未能捕捉到这些类型的错误可能会引发破产事件——尤其是当您的公司在受监管的环境中运营时。

Martin Fowler 普及了机器学习持续交付 (CD4ML) 的概念，该概念的图表为机器学习生命周期和监控发挥作用提供了有用的可视化指南：

此图概述了 ML 模型生命周期中的六个不同阶段：

• 模型构建：理解问题、数据准备、特征工程和初始代码。典型的制品是粗糙的 Jupyter notebook。
• 模型评估和实验：特征选择、超参数调整以及比较不同算法在给定问题上的有效性。典型的制品包括带有统计数据和图表的notebook，用于评估特征权重、准确度、精度和ROC。
• 产品化模型：获取“研究”代码并对其进行准备以便可以部署。典型的制品是生产级代码，在某些情况下将使用完全不同的编程语言或框架。
• 测试：确保生产代码按照我们预期的方式运行，并且其结果与我们在模型评估和实验阶段看到的结果相匹配。典型的制品是测试用例。
• 部署：将模型投入生产，它可以通过提供预测来开始增加价值。典型的制品是用于访问模型的 API。
• 监控和可观察性：最后阶段，我们确保我们的模型在生产中按照我们期望的那样工作。这篇博文的主题。

在图中，请注意周期性方面，其中在最终“监控和可观察性”阶段收集的信息反馈给“模型构建”。对于大多数公司来说，这是一个从业务角度评估模型影响的非自动化过程，然后考虑现有模型是否需要更新、放弃或可能从补充模型中受益。在更先进的公司中，这可能意味着在监控阶段收集的数据以自动方式直接输入到模型更新的训练数据中（这带来了很多额外的挑战）。

您可以将图表的前两个阶段（“模型构建”和“模型评估”）视为研究环境，通常是数据科学家的领域，而后四个阶段则更多地属于工程和 DevOps 领域，尽管这些区别各不相同从一家公司到另一家公司。如果您不确定部署阶段需要什么，我已经写了一篇关于该主题的帖子。

监控场景

与软件中的大多数事情一样，真正的挑战在于可维护性。 在 Flask 中部署和服务 ML 模型并不太具有挑战性。 事情变得复杂的地方在于以可重复的方式执行此操作，尤其是在模型频繁更新的情况下。 我们的典型更新场景如下所示：

• 第一种场景只是部署一个全新的模型。
• 第二种情况是我们用完全不同的模型完全替换这个模型。
• 第三种情况（右侧）非常常见，意味着对我们当前的实时模型进行小幅调整。 假设我们在生产中有一个模型，但有一个变量不可用，所以我们需要在没有该特性的情况下重新部署该模型。 或者，我们开发了一个我们认为非常具有预测性的超级特征，并且我们想要重新部署我们的模型，但现在将这个新特征作为额外的输入。

无论情况如何，监控都是我们确定模型更改是否产生预期效果的方式，这是我们最终关心的。 这条规则的唯一例外是影子部署，我在这篇文章中对此进行了解释。 但在我们深入研究监控的细节之前，有必要讨论一下 ML 系统构建上下文所固有的一些挑战。

2. 是什么让机器学习系统监控变得困难

机器学习系统具有传统代码的所有挑战，以及一系列针对机器学习的额外考虑因素。 这在谷歌“机器学习系统中的隐藏技术债务”的论文中有很好的记录。

从上面提到的论文中得到的一个关键点是，一旦我们谈论生产中的机器学习模型，我们就是在谈论 ML 系统。

该模型只是整个 ML 系统的一小部分：

对于 ML 系统，我们从根本上投资于跟踪系统的行为，这归结为三个组成部分：

• 代码（和配置）
• 模型（ML 系统特定要求）
• 数据（ML 系统特定要求）

在 ML 系统中，我们有两个额外的组件需要考虑，即数据依赖和模型。与传统软件系统不同，ML 系统的行为不仅受代码中指定的规则支配，还受从数据中学习的模型行为支配。更复杂的是，数据输入是不稳定的，可能会随着时间而变化。

如果无法理解和跟踪这些数据（以及模型）更改，您将无法理解您的系统。

但它并没有就此结束。这不像“好吧，我们有两个额外的维度要考虑”那么简单（这已经足够具有挑战性了）。由于以下原因，代码和配置还会在 ML 系统中增加额外的复杂性和敏感性：

• 缠绕：当输入特征发生变化时，其余特征的重要性、权重或使用也可能发生变化。这也被称为“改变任何事情都会改变一切”的问题。 ML 系统特征工程和选择代码需要非常仔细地测试。
• 配置：由于模型超参数、版本和特征通常在系统配置中进行控制，因此这里最轻微的错误都可能导致完全不同的系统行为，而传统的软件测试无法识别这些行为。在模型不断迭代和微妙变化的系统中尤其如此。

希望机器学习系统的难点开始变得清晰起来。另一个需要考虑的挑战是系统中涉及的团队数量之多。

责任挑战

ML Systems跨多个团队（也可能包括数据工程师、DBA、分析师等）：

在我们继续分解监控之前，值得一提的是，这个词在业务的不同部分有不同的含义。

• 数据科学家：一旦我们解释说我们谈论的是后期生产监控而不是部署前评估（这是我们在研究环境中查看 ROC 曲线等的地方），这里的重点是模型的统计测试输入和输出（更多细节请参见第 6 节）。
• 工程师和 DevOps：当您说“监控”时，请考虑系统运行状况、延迟、内存/CPU/磁盘利用率（更多细节请参见第 7 节）

对于 ML 系统，您需要这两种观点。虽然在传统的软件实践中，监控和可观察性往往落在 DevOps 上，但在 ML 系统中，您的 DevOps 团队不太可能具备正确监控 ML 模型所需的专业知识。这意味着：

1. 整个团队需要共同努力进行监控并说彼此的语言，以使系统有效
2. 定义我们的术语以避免混淆很重要。

所有这些复杂性意味着，如果您在部署之后只考虑孤立的模型监控，您将非常低效。在我们的 ML 生命周期的生产阶段（与测试一起），应在系统级别计划监控。持续的系统维护、更新和实验、审计和细微的配置更改会导致技术债务和错误累积。在我们进一步进行之前，值得考虑未能监控的潜在影响。

3. 为什么需要监控

“没有做好准备，你就是在准备失败”

监控的设计应旨在为生产环境 ML 模型可能出错的无数事情提供提前警告，其中包括：

数据偏差

当我们的模型训练数据不能代表实时数据时，就会出现数据倾斜。也就是说，我们在研究或生产环境中用于训练模型的数据并不代表我们在现场系统中实际得到的数据。

发生这种情况的原因有多种：

• 我们错误地设计了训练数据：训练数据中的变量分布与实时数据中的变量分布不匹配。
• 生产中不可用的特征：这通常意味着我们需要删除该特征，将其更改为生产中存在的替代类似变量，或者通过组合生产中存在的其他特征来重新创建该特征。
• 研究/实时数据不匹配：我们用于在研究环境中训练模型的数据来自一个来源，而实时数据来自不同的来源。这可能意味着变量的制造方式可能不同，因此即使管道对相同的输入数据返回相同的预测（这意味着我们的差异测试通过），不同的数据源可能会导致相同特征中固有的不同值，这将导致不同的预测。
• 数据依赖：我们的模型可能会摄取由其他系统（内部或外部）创建或存储的变量。这些系统可能会改变它们生成数据的方式，但遗憾的是，这种情况通常不会被清楚地传达。连锁反应是今天产生的变量与几年前产生的变量不等价。特征的代码实现会发生变化，产生略有不同的结果，或者特征的定义可能会发生变化。例如，外部系统可能会将投票年龄从 18 岁调整为 16 岁。如果投票年龄是模型中的一个重要特征，这将改变其预测。

模型陈旧

• 环境变化：如果我们使用历史数据来训练模型，我们需要预测当前的人口及其行为可能不同。例如，如果我们使用经济衰退时期的数据来训练我们的财务模型，那么在经济健康时期预测违约可能无效。
• 消费者行为的变化：客户偏好随着时尚、政治、道德等方面的趋势而变化。特别是在推荐机器学习系统中，这是一个必须不断监控的风险。
• 对抗场景：不良行为者（欺诈者、犯罪分子、外国政府）可能会积极寻找模型中的弱点并相应地调整他们的攻击。这通常是一场持续的“军备竞赛”。

负反馈循环

当模型根据生产中收集的数据自动训练时，会出现更复杂的问题。如果该数据以任何方式受到影响/损坏，那么随后基于该数据训练的模型将表现不佳。此处为 Twitter 的 Cortex AI 团队的 Dan Shiebler 描述这一挑战：

我们需要非常小心，我们部署的模型如何影响我们正在训练的数据，一个已经试图向用户展示它认为他们会喜欢的内容的模型正在破坏反馈到分布正在发生变化的模型。

4. 监控机器学习系统的关键原则

虽然学术机器学习起源于 1980 年代的研究，但机器学习系统在生产中的实际实施仍然相对较新。除了少数开创性的例外，大多数科技公司在大规模开展 ML/AI 方面才几年，而且许多公司才刚刚开始漫长的旅程。这意味着：

• 这些挑战经常被误解或完全忽视
• 框架和工具正在迅速变化（对于数据科学和 MLOps）
• 最佳实践通常是灰色的
• 监管要求一直在变化

没有什么比监控更真实的了，这或许可以解释为什么它经常被忽视。

由具有大规模 ML 部署经验的公司撰写的详细介绍系统设计、流程、测试和监控最佳实践的研究论文非常有价值。画出共同的主题和问题可以为您和您的公司节省大量的鲜血、汗水和泪水。机器学习领域最有经验的两家公司，谷歌和微软，已经发表了这方面的论文，以帮助其他面临类似挑战的人。这两篇论文是：

• The ML Test Score: A Rubric for ML Production Readiness and Technical Debt Reduction(2017) Breck 等人。（谷歌）
• 机器学习软件工程：案例研究(2019) Amershi 等人。（微软）

谷歌论文更多地关注机器学习系统测试和监控策略，这些策略可用于在可靠性、减少技术债务和减轻长期维护负担方面改进此类系统。谷歌的论文围绕 28 个测试进行了结构化，这是一个衡量给定机器学习系统对生产准备就绪程度的标准。这些测试“来自广泛的生产机器学习系统的经验”。

微软的论文采取了更广泛的视角，着眼于将 AI 功能集成到软件中的最佳实践。该论文介绍了对微软约 500 名工程师、数据科学家和研究人员的调查结果，这些工程师、数据科学家和研究人员参与了创建和部署 ML 系统，并提供了对所识别挑战的见解。

这两篇论文都强调，应用传统软件开发技术（例如：测试）以及一般可操作 ML 系统阶段的流程和标准尚未完善。

论文中与监测相关的关键原则

• 监视器 1：依赖项更改导致一个通知
• 监视器 2：数据不变量在训练和服务输入中保持不变，即监控训练/服务偏斜

有效监控学习模型的内部行为的正确性可能很困难，但输入数据应该更加透明。因此，分析和比较数据集是检测世界正在以可能混淆 ML 系统的方式变化的问题的第一道防线。

• 监视器 3：训练和服务特征计算相同的值
• 监视器 4：模型不太陈旧
• 监视器 5：模型在数值上是稳定的
• 监视器 6：该模型在训练速度、服务延迟、吞吐量或 RAM 使用率方面没有出现剧烈或缓慢的泄漏回归
• 监视器 7：模型在服务数据上的预测质量没有出现回归

也许最重要且实施最少的测试是用于训练/服务偏差的测试（监视器 3）。这种错误会导致大量团队的生产问题，但它是最不常实施的测试之一。部分原因是因为这很困难。

尽管缺乏优先级，但值得称赞的是，谷歌论文明确呼吁采取行动，特别是将其测试作为清单应用。我非常同意这一点，任何熟悉 Atul Gawande 的清单宣言的人都同意。

值得注意的是，这些最佳实践中的许多都依赖于可重复性。

5. 了解机器学习风险管理的范围

所有测试和监控最终归结为风险管理。这两种技术都是我们用来增加我们对系统功能是我们所期望的功能的信心的技术，即使我们对系统进行了更改。有一系列风险管理。

一方面，我们拥有没有测试和监控的系统。这是一个前景黯淡的系统（甚至不太可能投产），但也确实是一个非常容易调整的系统。

另一方面，我们拥有经过最严格测试的系统，具有所有可以想象的可用监控设置。在这个系统中，我们对其行为有非常高的信心，但是对系统进行更改是非常痛苦和耗时的。这样，测试和监控就像战甲一样。太少了，你很脆弱。太多了，你几乎不能动。

还要注意，测试和监控的价值随着变化而最明显。大多数机器学习系统一直在变化——业务增长、客户偏好发生变化以及新法律的颁布。

上图详细说明了您可以使用的所有生产前和生产后的风险缓解技术。

当我们谈论监控时，我们关注的是生产后的技术。 我们的目标是确定与我们的预期相冲突的 ML 系统行为的变化。

从广义上讲，我们可以将 ML 系统出错的方式分为两类：

• 数据科学问题（数据监控、预测监控）
• 运营问题（系统监控）

正如我们将在接下来的部分中看到的那样，要获得有效的解决方案，这两个领域需要结合在一起，但是随着我们越来越熟悉，首先单独考虑它们是有用的。

6.数据科学监控

当然，我们对生产中运行的模型的准确性感兴趣。然而，在许多情况下，不可能立即知道模型的准确性。以欺诈检测模型为例：只有在发生警方调查或进行其他检查（例如与已知欺诈者交叉检查客户数据）的情况下，才能在新的实况案例中确认其预测准确性。类似的挑战也适用于我们无法获得即时反馈的许多其他领域（例如：疾病风险预测、信用风险预测、未来财产价值、长期股市预测）。考虑到这些限制，监控代理值以在生产中建模准确性是合乎逻辑的，特别是：

• 模型预测分布（回归算法）或频率（分类算法），
• 模型输入分布（数字特征）或频率（分类特征），以及缺失值检查
• 模型版本

模型输入监控

给定一组输入特征的预期值，我们可以检查

a）输入值是否在允许的集合（对于分类输入）或范围（对于数字输入）内，

b）集合内每个值的频率是否与我们过去看到的一致。

例如，对于“婚姻状况”的模型输入，我们将检查输入是否在图中所示的预期值范围内：

根据我们的模型配置，我们将允许某些输入特性为空或不为空。这是我们可以监控的。如果我们预期的特性通常不会是空的开始更改，这可能表明数据倾斜或消费者行为的更改，这两个都是进一步调查的原因。

模型预测监控

在自动化或手动流程中，我们可以将模型预测分布与统计测试进行比较：

基本统计数据：中值、平均值、标准差、最大值/最小值

例如，如果变量是正态分布的，我们期望平均值在平均区间的标准误差范围内。当然，这是一种非常简单的统计方法。

模型版本

这是一个经常被忽视的需要监控的基本领域——您希望确保能够在配置错误发生时轻松跟踪模型的哪个版本已经部署。

高级技术：

我们还可以实施全面的统计测试来比较变量的分布。哪个测试？这取决于变量特性。

如果变量是正态分布的，我们可以进行t检验或方差分析，

如果它们不是正态分布，也许像Kruskall Wallis或Kolmogorov Smirnov这样的非参数检验更合适。

如果训练数据中的变量分布与生产中看到的变量类似，我们希望逐个变量进行比较。

实际上，在监测系统中实施高级统计测试可能很困难，尽管理论上是可行的。更典型的是随着时间的推移自动化基本统计测试（尤其是输入/输出的标准偏差），并进行特别的手动测试以应用更高级的检查。我们现在将深入探讨自动化选项。

7.运营监控问题

软件工程领域的监控是一个成熟得多的领域，也是站点可靠性工程的一部分。谷歌的SRE手册是一本很棒的（免费）参考书。我们ML系统的运营问题包括以下方面：

• 系统性能（延迟）
• 系统性能（IO/内存/磁盘利用率）
• 系统可靠性（正常运行时间）
• 可审计性（尽管这也适用于我们的模型）

在软件工程中，当我们谈论监控时，我们谈论的是事件。事件几乎可以是任何事情，包括：

• 接收HTTP请求
• 发送HTTP 400响应
• 输入函数（可能包含或不包含ML代码）
• 到达if语句的else
• 离开函数
• 登录的用户
• 将数据写入磁盘
• 从网络读取数据
• 从内核请求更多内存

所有事件都有上下文。例如，HTTP请求将具有其发出和发送的IP地址、请求的URL、设置的cookie以及发出请求的用户。涉及函数的事件上面有函数的调用堆栈，以及触发堆栈这一部分的任何内容，例如：HTTP请求。掌握所有事件的所有上下文对于调试和理解系统在技术和业务方面的表现都是很好的，但处理和存储这些数据量并不实际。

因此，监控被分解为不同的领域，每个领域都与将数据量减少到可行的程度有关。

所谓的“可观察性三大支柱”描述了我们可以利用事件上下文并将上下文数据简化为有用数据的关键方法。他们是：

• Metrics
• Logs
• 分布式跟踪

根据您询问的对象，偶尔会有一些额外的成员，例如：

• Profiling
• 警报/可视化（尽管这通常被纳入metrics/logs中）

监控与可观察性对比

那么监控和可观察性之间有什么区别呢？简单地说，可观察性是指你通过观察系统外部来回答系统内部发生的任何问题的能力。要了解可观性的伟大历史，我建议Cindy Sridharan撰写的这篇文章，以及她的书分布式系统可观性

此时，维恩图很有用：

此图包含：

• 测试-我们尽最大努力验证正确性
• 监控-我们尽最大努力跟踪可预测的故障

可观察性是监控和测试的超集：它提供了无法监控或测试的不可预测故障模式的信息。

监控和警报是相互关联的概念，共同构成监控系统的基础。监控系统负责存储、聚合、可视化，并在值满足特定要求时启动自动响应。

在监控ML系统时，分布式跟踪的细节往往与非ML系统的设置非常相似。因此，我不会在这里讨论它们。然而，对于日志和metrics，有一些值得注意的ML系统注意事项，我现在将深入探讨。

8.将Ops和DS结合在一起-Prometheus和Grafana的指标

Metrics表示可以在整个系统中观察和收集的资源使用或行为的原始度量。这些可能是运营系统提供的低级使用概要，也可能是与组件的特定功能或工作相关联的高级数据类型，如每秒处理的请求或特定函数的输出。

Metrics的优点：（来自分布式系统可观察性（Distributed Systems Observability）中丰富的解释）

• 与日志生成和存储不同，metrics传输和存储的开销是恒定的。
• 由于数字针对存储进行了优化，因此，指标可以延长数据保留时间并简化查询。这使得指标非常适合创建反映历史趋势的仪表盘，可以每周/每月切片等。
• 度量非常适合于统计转换，例如：采样、聚合、汇总和关联。度量也更适合触发警报，因为，对内存中的时间序列数据库运行查询要高效得多。

Metrics的缺点：

• Metrics允许您从整个流程收集有关事件的信息，但通常不超过一个或两个上下文字段。
• 基数问题（集合元素的数量）：使用高基数值（如ID）作为metrics标签可能会淹没时间序列数据库。
• 作用域为一个系统（即一组微服务中只有一个服务）

机器学习指标

鉴于上述利弊，指标非常适合我们的ML系统的两个运营问题：

• 调用ML API端点时的延迟
• 执行预测时的内存/CPU使用率
• 磁盘利用率（如果适用）

以及以基本统计指标为中心的预测监测：

• 给定时间段内的中值和平均预测值
• 最小/最大预测值
• 给定时间段内的标准偏差

实际工具

Prometheus和Grafana的组合是监控指标最流行的开源堆栈之一。

为了避免这篇文章变成一本书，我不会详细解释这些技术。了解更多信息的最佳场所是Brian Brazil的书籍和培训课程。文档中的快速摘要：

Prometheus直接或通过中介推送网关从插入指令的作业中获取度量值，用于短期作业。它将所有收集的样本存储在本地，并对这些数据运行规则，以便从现有数据中聚合和记录新的时间序列，或生成警报。Grafana或其他API使用者可用于可视化收集的数据。

来源：Prometheus文档

我们可以使用Prometheus&Grafana创建仪表盘，以跟踪我们的模型标准统计指标，可能如下所示：

您可以使用这些仪表板创建警报，当模型预测超出特定时间段内的预期范围（即异常检测）时，通过电子邮件/SMS通知您，从而调整此处描述的ML方法。然后，这将提示对常见疑似点进行全面调查，例如：

• 流水线中有bug吗？
• 我们部署了错误的模型吗？
• 数据集有问题吗？
• 模型过时了吗？

9.将Ops和DS结合在一起-日志

事件日志（通常称为“日志”）是一个不可变的、带有时间戳的记录，记录了一段时间内发生的离散事件。

日志的优点：

• 日志很容易生成，因为它只是一个字符串、一个JSON blob或类型化键值对。
• 事件日志在提供有价值的洞察力和足够的上下文方面表现出色，提供了平均值和百分位数无法显示的细节。
• 虽然指标显示服务或应用程序的趋势，但日志关注特定事件。日志的目的是保存关于特定事件的尽可能多的信息。日志中的信息可用于调查事件并帮助进行根本原因分析。

日志的缺点：

• 日志记录过多会对系统性能产生负面影响
• 由于这些性能问题，日志上的聚合操作可能代价高昂，因此应谨慎处理基于日志的警报。
• 在处理方面，原始日志几乎总是由Logstash、fluentd、Scribe或Heka等工具进行规范化、过滤和处理，然后再保存到Elasticsearch或BigQuery等数据存储中。设置和维护此工具会带来巨大的运营成本。

机器学习日志

如果我们考虑监控ML的关键领域，我们在前面看到了如何使用指标来监控预测输出，即模型本身。然而，通过指标调查数据输入值可能会导致高基数挑战，因为许多模型都有多个输入，包括分类值。虽然我们可以在一些关键输入上检测指标，但如果我们想在没有高基数问题的情况下跟踪它们，最好使用日志来跟踪输入。如果我们使用的是带有文本输入的NLP应用程序，那么由于语言的基数非常高，我们可能不得不更加依赖日志监视。

我们将检查输入的危险信号，例如：

• 某个特征变得不可用（要么从输入中消失，要么大量NA）
• 关键输入值分布的显著变化，例如，在训练数据中相对罕见的分类值变得更加常见
• 特定于模型的模式，例如，在NLP场景中，训练数据中看不到的单词数量突然增加

实际工具

Kibana是一个开源分析和可视化平台，它是弹性堆栈的一部分，以前是ELK堆栈。您可以使用Kibana搜索、查看和交互存储在Elasticsearch索引中的日志。您可以轻松执行高级数据分析，并在各种图表、表格中可视化日志。这是构建日志监控系统最常见的开源堆栈之一

在Kibana中，您可以设置仪表板来跟踪和显示ML模型输入值，以及在值出现意外行为时自动发出警报。这样的仪表板可能看起来有点像：

这是日志记录系统的一种可能选择，还有logz.io和Splunk等选项。

10. 不断变化的局势

希望本文能让您更清楚地了解机器学习监控的真正含义以及它的重要性。正如我希望的那样，这是一个需要跨学科努力和规划才能有效的领域。有趣的是，这些工具将如何发展以满足许多企业日益增长的挫败感，这些企业经历了 ML 部署的高峰期，但随后却没有能力监控该部署，并因几个月后环境的变化而被烧毁。值得关注的有趣发展包括：

• 大型 AI 玩家努力改进他们的机器学习模型解决方案监控，例如：微软在 Azure ML Studio 中引入了“数据漂移“。自然的，这些都伴随着通常的供应商锁定和非内部构建的灵活性限制。
• 零星创业公司试图构建创新工具以简化模型监控，例如：Seldon、Data Robot、MLFlow、superwise.ai 和 hydrosphere.io 等。
• MLOps 领域的开源倡议。我认为 KF Serving 可能会提供一些急需的标准化，这可以简化构建监控解决方案的挑战。

到明年这个时候，局势可能看起来会大不相同……

原文链接：Monitoring Machine Learning Models in Production