为什么需要ML监控
首先，为什么还要谈论监控？
当您在生产中部署ML系统时，它会集成到业务中。是时候谈论ROI了！你希望它能带来价值。例如，推荐系统应该改善用户体验并增加收入。
但这些ML系统可能会失败。有些失败是显而易见的，比如：服务宕机。其他的则是无声的，特别是机器学习，例如：数据和概念漂移。您还可能面临严重的二阶效应。例如，信用评分系统可以显示对某些客户群体的偏见。
为了控制这些风险，您必须监视生产ML系统。
下面是 DoorDash 如何描述构建 ML 监控的动机：
过去，我们看到过模型过时并开始做出错误预测的情况。这些问题对业务和客户体验产生了负面影响，并迫使工程团队花费大量精力调查和修复它们。 发现这种模型漂移需要很长时间，因为我们没有办法监控它。
来源：通过监控维护机器学习模型的准确性，DoorDash 工程师博客。
我们曾经在博客中制作了一张冰山图片，它很受欢迎。 确实，它确实说明了一点。 在生产中监控 ML 模型不仅仅意味着跟踪软件性能。 还有一堆其他的东西！
但是这个冰山是一个二分类器。 我们将与软件相关的方面和使机器学习监控不同的看不见的“其他一切”进行比较。
现在让我们尝试组织其余部分。 你应该看什么？
认识监控金字塔！
这是一种构建 ML 系统监控的所有组件的方法：
让我们快速掌握每一层都有什么，自下而上。
首先，你仍然有软件后端。是的，你不能忽视这一点：让我们把它放在金字塔的底部。
要生成预测，您需要以某种方式调用 ML 模型。一个更简单的例子是批量推理。您可以每天、每小时或按需运行它，并使用工作流管理器来编排流程。它将访问数据源、运行模型并将预测写入数据库。在线推理要复杂一些。您可以将模型包装为服务并公开 REST API 以根据请求提供预测。有更多移动的部分要跟踪。
在底层，您仍然需要监控该软件组件的工作方式。预测作业是否成功执行？服务有响应吗？它的工作速度是否足够快？
其次，你有数据。生产环境 ML 模型将新数据作为输入，并且这些数据会随着时间而变化。在数据源或转换过程中也可能出现许多数据质量和完整性问题。
这些数据代表了模型的真实性，您必须监控这个关键组件。数据正常吗？你能用它来生成预测吗？您可以使用这些数据重新训练模型吗？
第三，ML模型本身。
最后，没有完美的模型，也没有永恒的模型。尽管如此，其中一些对于给定的任务是有用的和相关的。模型投入生产后，您必须确保其质量令人满意。
这个以模型为中心的 ML 监控组件是最具体的组件。该模型是否仍然适合该任务吗？预测准确吗？你能相信他们吗？
最后是业务或产品KPI。没有人使用机器学习在某件事上获得“90% 的准确率”。其背后有业务需求，例如：将用户转化为买家、让他们点击某些东西、获得更好的预测、降低交付成本等。您需要为模型指定一个美元价值、一个可测量的产品指标或您可以获得的最佳代替物。
这就是为什么您拥有 ML 系统和监控金字塔顶端的最终目标。该模型是否为业务带来价值？受模型影响的产品指标是否正常？
一个机器学习系统有这四个组成部分：软件、流动数据、机器学习模型，以及它存在的商业原因。
由于 ML 系统具备上述所有功能，因此， ML 监控也必须如此。
以下是 Booking.com 如何看待整个 ML 系统的质量：
每个模型都是整个机器学习系统的一部分，其中数据正在被预处理、预测，最后，这些预测被用来影响我们业务的日常运营。显然，我们希望这些模型质量好，但不仅仅是模型：整个系统需要质量好，以确保持久的业务影响。
来源：A Quality Model for Machine Learning Systems，Booking.com 数据科学博客。
模型监控指标是什么呢？
这个金字塔结构描述了机器学习监控的层次结构。 但您应该计算哪些指标？
现在让我们更详细地回顾金字塔的每一层。 我们会考虑：
- 监测各方面的目标是什么？
- 它对 ML 的具体程度怎样？
- 指标示例以及影响选择的因素有哪些？
- 监控还有什么困难？
我们不会详细介绍日志记录和监控架构，而是主要关注内容。
1. ML系统健康监测
运营指标有助于评估软件系统的健康状况。 毕竟，如果系统出现故障，您的 ML 模型有多好都没关系。
ML 中的软件组件会出现什么问题？ 几乎任何其他生产系统都可能出现问题。 代码中的错误、人为错误、基础设施问题，应有尽有。
ML 软件监控的目标是什么？
首先，要知道系统已启动并正在运行，如果出现故障，请立即进行干预。其次，了解更细粒度的性能特征，以确保您符合服务水平目标。如有必要，您可以进行更改，例如：随着服务使用量的增长启动新实例。
该软件监控对 ML 的具体程度如何？
一切照旧。在这种情况下，ML 和非 ML 软件之间没有区别。您可以从传统的软件监控堆栈中借鉴监控实践。
谁通常要随叫随到？
后端工程师或站点可靠性工程师。
您可以监控哪些指标？什么影响选择？
监控设置取决于模型部署架构，包括：
- 您如何为模型提供服务：批处理作业、实时服务或流式工作流。
- 无论您是在现有服务中嵌入模型还是部署独立服务。
- 您的服务要求有多苛刻，例如，您需要低延迟。
- 您的 ML 部署环境，例如，在云端或边缘。
这些因素不仅会影响指标的选择，还会影响整个监控系统的设计。
在最简单的形式中，机器学习系统可以看起来像一组不频繁的批处理作业。在这种情况下，您可以留在数据工程领域并像对待任何其他数据工作一样对待它。您可以监控执行时间和作业完成情况，并在它们失败时设置通知。
如果您将模型包装为 API 以根据请求提供预测，您将需要更多监控指标。您将需要检测您的服务以收集基于事件的指标。然后，您可以实时跟踪软件和基础架构运行状况的各种运营指标，包括：
- 服务使用指标，例如：模型调用总数、RPS（每秒请求数）和错误率。目标是跟踪模型使用情况并知道失败的推理。例如，当服务无法显示推荐块并且必须使用fallback时。
- 系统性能指标，例如：正常运行时间和延迟。例如，您可以查看 p90 或 p99 延迟，以了解处理预测请求通常需要多长时间。这对于实时用例很重要。以检测支付欺诈的模型为例：快速的模型推理对于良好的用户体验至关重要。您不想等待几分钟才能批准您的交易。
- 资源利用率指标，例如：内存和 GPU/CPU 利用率。
SRE 术语通常将这些运营指标称为 SLI（服务水平指标）。这个想法是仔细挑选一些量化服务绩效不同方面的指标。
以下是Linkedin如何作为ML健康保障系统的一部分监控延迟：
模型推理延迟是应用程序所有者的一个重要指标，因为它告诉模型在服务特定评分请求时所花费的总时间。我们通常监控平均、第 50、第 75、第 90 和第 99 个百分位数的延迟。这些延迟分位数可以以多种方式使用，例如：在请求的整个生命周期内帮助隔离模型的违规部分。
资料来源：Linkedin 的模型健康保障平台，Linkedin 博客。
2. ML数据质量监控
让我们跳到数据层。
假设 ML 服务启动并运行，所有工作都顺利完成。 但是流过的数据呢？ 数据质量是 ML 模型失败的常见罪魁祸首。 而且是，下一个要监控的大事！
ML 模型的数据会出现什么问题？
很多！ 以下是潜在数据质量问题的不完整列表。 一些例子是：
- 数据 schema 更改。 例如，第 3 方数据格式的未通知更新。
- 过时的数据源。 想象一下物理传感器损坏、应用内事件跟踪实现不正确、源表未按时刷新等。
- 上游损坏的模型。 一个模型的损坏输出可能是另一个模型的损坏输入。
- 意外的输入。 如果您处理面向用户的应用程序，则经常会发生错误，从输入信息时的简单拼写错误开始。
- 特征转换代码中的流水线损坏和 bugs。
ML 中数据质量监控的目标是什么？
要知道您可以信任数据来生成预测并在没有的情况下做出反应。
如果数据损坏或缺失，模型就没有用处。在恢复数据质量之前，您需要停止并使用回退。
在不太极端的情况下，您可以继续进行预测，但使用监控信号来调查和解决问题。
这种数据质量监控对 ML 的具体程度如何？
有些！当然，您还需要监控其他分析用例的数据。您可以重复使用一些现有的方法和工具。但是这种传统的数据监控往往是在宏观层面上进行的，例如，当您监控仓库中的所有数据资产和数据流时。
相比之下，机器学习数据监控是细粒度的。
您需要确保特定模型输入符合预期。在某些情况下，您仍然可以依赖现有的上游数据质量监控。例如，如果模型重新使用已经受到保护的共享数据表。但通常，您需要引入额外的检查来控制特征转换步骤、实时模型输入的质量，或者因为模型使用外部数据源。
从这个意义上说，ML 数据质量监控更接近于其他数据流水线中可能存在的数据测试和验证。它通常在您为模型提供服务之前作为对数据接入（ingestion）的检查来执行。
谁通常随叫随到？
数据工程师（如果问题与基础设施有关），或者数据分析师或数据科学家（如果问题与数据“内容”有关）。
您可以监控哪些指标？什么影响选择？
确切的数据监控设置再次取决于：
- 模型部署架构，无论是批处理、实时服务还是流式工作流。它将影响数据质量监控的复杂性。动态检测数据流中的问题不同于检查每天更新一次的表。
- 数据的细节及其背后的真实世界过程。例如，在制造业中，您可能对每个特征的可能值范围有严格的期望。使用用户生成的输入，您可能更愿意密切关注整体数据形状和完整性检查以检测主要问题。
- 用户场景重要性。如果失败的成本很高，您可能会设计复杂的数据质量检查。您还可以添加在线数据质量验证，在对预测采取行动之前返回通过/失败结果。在其他情况下，您可能会接受被动反应。您可以在仪表板上放置一些指标（例如：特定特征的平均值或缺失数据的份额）以跟踪随时间的变化。
Evidently 数据质量测试输出的示例
我们可以将数据度量和检查的类型大致分为几组。
- 缺失数据。您可以检查特定特征中丢失的数据以及模型输入中丢失数据的总体份额。
- 数据schema验证。您可以验证输入模式是否与定义的期望匹配。目标是检测错误输入并跟踪新列或类别的出现等问题。
- 对单个特征类型的约束。例如，如果您希望它只是数字，您可以断言特定的特征类型。这可以捕获一部分输入错误，例如：以错误格式到达的特征。
- 对单个特征范围的约束。人们通常可以制定对“正常”特征值的期望。这些可以从健全性检查（年龄小于 100）到特定领域的检查（正常传感器操作条件在 10 到 12 之间）不等。违反约束可能是数据质量问题的征兆。
- 特征统计。您还可以跟踪特定特征的平均值、最小-最大范围、标准差或百分位数分布。与硬约束相比，这有助于暴露不太明显的故障。例如，该特征可能保持在预期范围内，但开始表现异常。现实世界的解释可能是物理传感器停止工作，并且值在最近一次测量时被“冻结”。
- 异常影响。您还可以设置监视器以使用异常和异常值检测方法检测“异常”数据。他们将搜索与其他数据不同的数据点，并可能有助于捕获损坏的输入。您可以专注于检测单个异常值或跟踪它们的总体比率。
Evidently 数据质量仪表板示例，其中包含单个特征的描述性统计信息
Google 如何设计数据验证系统：
在 Data Validation for Machine Learning 一文中，谷歌团队展示了他们如何设计数据验证系统来评估和测试输入机器学习管道的数据。他们建议采用以数据为中心的机器学习方法，将数据与算法和基础设施一起视为重要的生产资产。
ML 数据质量监控有什么棘手之处？
- 我们都知道数据质量至关重要，但设置监控可能非常耗时。要设置数据质量约束，您可能需要大规模编纂 ML 团队外部的专家领域知识。理想情况下，您希望自动从训练数据集中了解基本期望。
- 多个接触点。您最终可能还会进行大量检查，特别是如果您在后处理后，同时监控原始输入数据和特征值。关键是设计数据质量监控框架以检测关键问题，而不会不知所措。
- 数据血缘。检测到数据质量问题后，您需要追溯造成问题的原因。如果您有许多管道步骤和转换，这可能会非常混乱。您需要能够将错误的数据输入连接回原始源或管道中的特定组件，例如，这些组件没有及时更新。数据质量监控与血缘和溯源紧密相连；设置它可能需要额外的工作。
