翻译：监控生产中的机器学习模型

介绍

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

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

本综合指南旨在至少让您了解在生产中监控机器学习模型的复杂性来自哪里，为什么它很重要，此外还将为实施您自己的 ML 监控解决方案提供一个实用的起点。如果是您正在寻找的示例代码、分步教程和示例项目，您可能会对我们专门针对该主题的在线课程感兴趣：测试和监控机器学习模型部署。这篇文章不是针对初学者的，但不要担心。如果您准备好遵循各种链接，您应该能够跟随。让我们潜入……

内容

1. 机器学习系统生命周期
2. 是什么让机器学习系统监控变得困难
3. 为什么需要监控
4. 监控机器学习系统的关键原则
5. 了解机器学习风险管理的范围
6. 数据科学监控问题[从这里开始以获得实用建议]
7. 运营监控问题
8. 将 Ops 和 DS 结合在一起 - Prometheus 和 Grafana 的指标
9. 将 Ops 和 DS 结合起来 - 日志
10. 不断变化的景观

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

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

Martin Fowler 推广了机器学习持续交付 (CD4ML) 的概念，这个概念的图表为机器学习生命周期和监控发挥作用的地方提供了有用的视觉指南：

资料来源：martinfowler.com

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

1. 模型构建：理解问题、数据准备、特征工程和初始代码。典型的工件是粗糙的 Jupyter 笔记本。

2. 模型评估和实验：特征选择、超参数调整以及比较不同算法对给定问题的有效性。典型的工件包括带有评估特征权重、准确性、精度和接收器操作特性 (ROC) 的统计数据和图表的笔记本。

3. 生产模型：获取“研究”代码并准备它以便可以部署。典型的工件是生产级代码，在某些情况下，它们将采用完全不同的编程语言和/或框架。

4. 测试：确保生产代码按照我们期望的方式运行，并且其结果与我们在模型评估和实验阶段看到的结果相匹配。典型的工件是测试用例。

5. 部署：将模型投入生产，在那里它可以通过提供预测来开始增加价值。典型的工件是用于访问模型的 API。

6. 监控和可观察性：最后阶段，我们确保我们的模型在生产中按照我们的预期运行。这篇博文的主题。

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

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

1.1 监控场景

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

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

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

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

机器学习系统面临传统代码的所有挑战，以及一系列额外的特定于机器学习的注意事项。这在 Google 的论文“机器学习系统中的隐藏技术债务”中有详细记录

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

该模型是整个 ML 系统的一小部分（图片取自 Sculley 等人，2015 年）：

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

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

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

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

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

• 纠缠：当输入特征发生变化时，其余特征的重要性、权重或使用也可能发生变化。这也被称为“改变任何事物都会改变一切”的问题。ML 系统特征工程和选择代码需要非常仔细地测试。

• 配置：因为模型超参数、版本和功能通常在系统配置中控制，这里最轻微的错误都可能导致完全不同的系统行为，而传统软件测试不会发现这些行为。在模型不断迭代和微妙更改的系统中尤其如此。

希望人们开始清楚机器学习系统很难。另一个需要考虑的挑战是系统中涉及的团队数量之多。

2.1 责任挑战

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

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

数据科学家：一旦我们解释了我们谈论的是后期生产监控而不是部署前评估（这是我们在研究环境中查看 ROC 曲线等的地方），这里的重点是模型的统计测试输入和输出（更多关于第 6 节中的这些细节）。

工程师和 DevOps：当您说“监控”时，请考虑系统运行状况、延迟、内存/CPU/磁盘利用率（更多详情请参见第 7 节）

对于 ML 系统，您需要这两种观点。在传统的软件实践中，监控和可观察性往往属于 DevOps，而在 ML 系统中，您的 DevOps 团队不太可能具备正确监控 ML 模型所需的专业知识（除非您有一个独角兽 DevOps 工程师和数据科学家，你应该坚持并加薪的人）。这意味着：

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

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

3. 为什么需要监控

“不准备，你就准备失败”

本杰明·富兰克林

监控应旨在为生产 ML 模型可能出现的各种问题提供早期警告，其中包括：

3.1 数据倾斜

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

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

• 我们错误地设计了训练数据：训练数据 中变量的分布与实时数据中变量的分布不匹配。

• 一个功能在生产中不可用： 这通常意味着我们需要移除该功能，将其更改为生产中存在的替代类似变量，或者通过组合生产中存在的其他功能来重新创建该功能。

• 研究/实时数据不匹配： 我们用于在研究环境中训练模型的数据来自一个来源，而实时数据来自不同的来源。这可能意味着变量可能不会完全相同，因此即使管道对相同的输入数据返回相同的预测（这意味着我们的差异测试通过），不同的数据源可能会导致相同特征中固有的不同值，这将导致不同的预测。

• 数据依赖性：我们的模型可能会摄取由其他系统（内部或外部）创建或存储的变量。这些系统可能会改变它们产生数据的方式，遗憾的是，这种情况并没有清楚地传达是很常见的。连锁反应是今天产生的变量与几年前产生的变量不同。要么功能的代码实现发生变化，产生略有不同的结果，要么功能的定义可能会发生变化。例如，外部系统可能会将投票年龄从 18 岁调整为 16 岁。如果投票年龄是模型中的一个重要特征，这将改变其预测。

3.2 模型陈旧

• 环境变化： 如果我们使用历史数据来训练模型，我们需要预测当前时代的人口及其行为可能会有所不同。例如，如果我们使用经济衰退时期的数据训练我们的金融模型，则在经济健康时期预测违约可能无效。

• 消费者行为的变化： 客户偏好随着时尚、政治、道德等趋势而变化。特别是在推荐机器学习系统中，这是一种必须持续监控的风险。

• 对抗性场景： 不良行为者（欺诈者、罪犯、外国政府）可能会积极寻找模型中的弱点并相应地调整他们的攻击。这通常是一场正在进行的“军备竞赛”。

3.3 负反馈回路

当模型根据生产中收集的数据进行自动训练时，会出现一个更复杂的问题。如果此数据以任何方式受到影响/损坏，那么在该数据上训练的后续模型将表现不佳。在37:00分钟，你可以在这里 Twitter 的 Cortex AI 团队的 Dan Shiebler 描述这个挑战：

“我们需要非常小心我们部署的模型如何影响我们正在训练的数据 […]模型，因为分布正在发生变化。”

这篇文章涵盖了相关挑战的示例，例如标签概念漂移，非常值得一读。

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

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

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

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

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

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

Google 的论文更侧重于 ML 系统测试和监控策略，这些策略可用于在可靠性、减少技术债务和降低长期维护负担方面改进此类系统。谷歌论文围绕 28 个测试构建，这是衡量给定机器学习系统为生产做好准备的标准。这些测试“来自广泛的生产机器学习系统的经验”。

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

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

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

来自Breck等人，2017 年：

• Monitor 1：依赖项更改导致 [a] 通知
• Monitor 2：数据不变量在训练和服务输入中保持不变，即监控
  Training/Serving Skew

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

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

也许最重要和最少实施的测试是用于训练/服务倾斜的测试（Monitor 3）。这类错误是造成大量团队生产问题的原因，但它是最不常实施的测试之一。部分原因是因为这很困难 […]。

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

重要的是要注意，许多这些最佳实践取决于可重复性，Sole Galli 和我在本次演讲中讨论了这一点

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

所有测试和监控最终归结为风险管理。它们都是我们用来增加我们对系统功能是我们期望的那样的信心的技术，即使我们对系统进行了更改。存在一系列风险管理。一方面，我们拥有没有测试和监控的系统。这是一个未来前景黯淡的系统（甚至不太可能在生产中启动），但也是一个确实很容易调整的系统。另一方面，我们拥有经过最严格测试的系统，其中包含所有可以想象的可用监控设置。这是一个我们对其行为非常有信心的系统，但对系统进行更改是极其痛苦和耗时的。通过这种方式，测试和监控就像战斗盔甲。太少了，你很脆弱。太多了，你几乎不能移动。

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

图片改编自 Cindy Sridharan 的生产测试系列

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

当我们谈论监控时，我们专注于后期制作技术。我们的目标是确定我们的 ML 系统行为中与我们的期望相冲突的变化。

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

• 数据科学问题（数据监控、预测监控）
• 操作问题（系统监控）
  
  资料来源：布雷克等人。(2017)
  正如我们将在接下来的部分中看到的，要获得有效的解决方案，这两个领域需要结合在一起，但随着我们越来越熟悉，首先单独考虑它们是有用的。

6. 数据科学监控

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

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

6.1 模型输入监控

给定输入特征的一组期望值，我们可以检查 a) 输入值是否在允许的集合内（对于分类输入）或范围（对于数字输入）和 b) 集合中每个相应值的频率与我们过去看到的一致。

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

根据我们的模型配置，我们将允许某些输入特征为空或不为空。这是我们可以监控的。如果我们通常期望不是null 的特征开始发生变化，这可能表明数据倾斜或消费者行为发生了变化，这两者都将成为进一步调查的原因。

6.2 模型预测监控

在自动化（在接下来的部分中将详细介绍）或手动过程中，我们可以将我们的模型预测分布与统计测试进行比较：

基本统计：中位数、平均值、标准差、最大值/最小值
例如，如果变量呈正态分布，我们希望平均值在平均区间的标准误差内。这当然是一种非常简单的统计方法。

6.3 型号版本

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

先进技术
我们还可以实施全面的统计测试来比较变量的分布。哪个测试？这取决于可变特性。如果变量是正态分布的，我们可以进行 t 检验或方差分析，如果不是，也许像Kruskall Wallis或Kolmogorov Smirnov这样的非参数检验更合适。如果训练数据中变量的分布与我们在生产中看到的该变量的分布相似，我们希望逐个比较变量。

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

7. 运营监控问题

软件工程领域的监控是一个更为完善的领域，并且是站点可靠性工程的一部分。一本很棒的（免费）参考书是Google 的 SRE 手册。我们机器学习系统的运营问题包括以下几个方面：

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

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

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

所有事件也有上下文。例如，一个 HTTP 请求将包含它来自和去往的 IP 地址、被请求的 URL、设置的 cookie 以及发出请求的用户。涉及函数的事件具有其上方函数的调用堆栈，以及触发该部分堆栈的任何内容，例如 HTTP 请求。拥有所有事件的所有上下文对于调试和了解您的系统在技术和业务方面的表现非常有用，但处理和存储大量数据并不实用。

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

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

1. 指标
2. 日志
3. 分布式跟踪

根据您询问的对象，偶尔会有一些额外成员，例如 (4) 分析 (5) 警报/可视化（尽管这通常会被纳入指标/日志）

7.1 监控与可观察性

那么监控和可观察性有什么区别呢？简而言之，可观察性是您通过观察系统外部来回答有关系统内部发生的任何问题的能力。对于可观察性的伟大历史，我会推荐 Cindy Sridharan 的著作，例如这篇文章，以及她的书分布式系统可观察性

此时，维恩图很有用：

该图捕获：

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

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

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

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

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

指标表示可以在整个系统中观察和收集的资源使用或行为的原始测量值。这些可能是操作系统提供的低级使用摘要，也可能是与特定功能或组件工作相关的高级数据类型，例如每秒提供的请求或特定功能的输出。

度量的优点（从分布式系统可观察性中自由地释义）：

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

指标的缺点：

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

8.1 机器学习指标

鉴于上述优点和缺点，指标非常适合我们 ML 系统的两个操作问题：

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

以及以基本统计措施为中心的预测监测：

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

8.2 实际实施

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

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

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

来源：普罗米修斯文档
我们可以使用 Prometheus 和 Grafana 创建仪表板来跟踪我们的模型标准统计指标，它可能如下所示：

通过 GIPHY

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

管道中是否存在错误？
我们是否部署了错误的模型？（出乎意料的普遍）
数据集有问题吗？
模型已经过时了吗？

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

事件日志（通常简称为“日志”）是随时间发生的离散事件的不可变的、带有时间戳的记录。

日志的优点：

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

日志的缺点：

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

9.1 机器学习的日志记录

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

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

• 功能变得不可用 -（从输入中消失，或大量 NA）
• 关键输入值分布的显着变化，例如，在训练数据中相对罕见的分类值变得更加普遍
• 特定于您的模型的模式，例如在 NLP 场景中训练数据中看不到的单词数量突然增加

9.2 实际实施

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

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

这是日志系统的一种可能选择，还有诸如logz.io和Splunk 之类的托管选项。

10. 不断变化的景观

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

• 大AI玩家努力改进他们的机器学习模型解决方案监控，例如微软在Azure ML Studio中引入了“Data Drift”，或者贪婪书店在SageMaker中的改进。当然，这些都带有通常的供应商锁定和非内部构建的灵活性限制。

• 斗志旺盛的启动尝试构建创新工具，以缓解模型监控，例如塞尔顿，数据机器人，MLFlow，superwise.ai和hydrosphere.io在其他之中。

• MLOps 领域的开源计划。我认为KF Serving可能会提供一些急需的标准化，这可以简化构建监控解决方案的挑战。关注此空间。

到明年这个时候，风景可能会大不相同……

参考

https://christophergs.com/machine%20learning/2020/03/14/how-to-monitor-machine-learning-models/