持续创作，加速成长！这是我参与「掘金日新计划 · 10 月更文挑战」的第20天，点击查看活动详情
当提到“ML监控”时，这可能意味着很多事情。您是否在跟踪服务延迟？模型精度？数据质量？点击推荐栏的访问者占比？
这个博客将所有指标组织到一个框架中。这是高水平的，但我们希望一个全面的概述。如果您是ML监视的新手，并且希望快速掌握它，请继续阅读。
除了博客之外，我们还将链接到Doordash、Nubank、Booking.com 和 Linkedin 等公司撰写的关于如何进行ML监控的文章。
为什么需要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 团队外部的专家领域知识。理想情况下，您希望自动从训练数据集中了解基本期望。
- 多个接触点。您最终可能还会进行大量检查，特别是如果您在后处理后，同时监控原始输入数据和特征值。关键是设计数据质量监控框架以检测关键问题，而不会不知所措。
- 数据血缘。检测到数据质量问题后，您需要追溯造成问题的原因。如果您有许多管道步骤和转换，这可能会非常混乱。您需要能够将错误的数据输入连接回原始源或管道中的特定组件，例如，这些组件没有及时更新。数据质量监控与血缘和溯源紧密相连；设置它可能需要额外的工作。
3. ML模型质量监控
即使软件系统运行良好且数据质量符合预期，这是否意味着您已被覆盖？没有！欢迎来到机器学习模型问题的陆地。
生产中的 ML 模型会出现什么问题？他们发生漂移了！
在突然变化的情况下，模型可能会突然中断，或者开始逐渐变差。我们可以大致将原因分为两种：
- 数据漂移：模型应用于看不见的输入，例如：新人口统计的用户。
- 概念漂移：现实世界的关系发生变化，例如：不断变化的用户行为。
以下是一些可能导致模型漂移的因素：
- 环境的变化。例如，通货膨胀率上升（或大流行的开始！）
- 刻意改变业务。您可能会在新位置或新用户群中启动应用程序。
- 对抗性适应。这通常用于垃圾邮件和欺诈检测案例，因为不良行为者试图适应模型行为。
- 模型反馈回路。模型本身可能会影响现实。例如，推荐系统会影响用户看到和点击的内容。
- 模型设计和使用不匹配。例如，您可以构建一个潜在客户评分模型来预测转化概率，但相反，用户开始使用该模型进行场景分析。他们尝试输入不同的输入组合，以了解哪些因素会影响模型决策。这是一个不同的用例，需要不同的分析工具。
当模型漂移时，您通常会看到模型误差或不正确预测的数量增加。在剧烈漂移的情况下，模型可能会在一夜之间变得不合适。
ML 模型质量监控的目标是什么？
让您放心，您信任该模型并继续使用它，并在出现问题时提醒您。一个好的监控设置应该提供足够的上下文来有效地解决模型退化问题。您需要评估根本原因并解决偏差，例如，触发重新训练、重建模型或使用回退策略。
这对ML监控有多具体？
这对于ML系统来说是非常独特的。您可以调整其他行业的一些模型监控实践，例如：金融中信用评分模型的验证和治理。正如您所知，这是ML监控。
谁通常随叫随到？
数据科学家或机器学习工程师。谁构建了模型并知道“特征 X 是什么”，或者向谁询问。
您可以监控哪些指标？什么因素会影响您的选择？
ML监控设置可能会有所不同。以下是一些影响它的因素：
- 模型和数据类型。您总是需要一些“准确率”指标来评估整体模型质量。您通常可以使用与模型训练中相同的指标。但是具体的指标列表会根据您是否有回归、分类或排名模型而有所不同。表格数据和图像数据等的监测数据漂移也不同。
- Ground truth 延迟。如果您在预测后不久获得标记数据或反馈，则可以直接评估模型质量。例如，在预测比萨饼的送达时间时，您很快就会知道需要多长时间。如果您预测下一季度的销售额，您需要等待才能知道这些预测有多好。当预测和反馈之间存在很长的滞后时，您无法计算质量本身。您可能需要监控代理指标，例如：数据和预测偏差。
- 模型风险和重要性。模型越重要，您的监控可能就越精细，您可能需要实施的指标（如公平性）和监控方法（如检测单个异常值）越具体。如果您有很多低风险模型，则只能监控与模型类型相关的标准指标。
CS 329S 教程中的Evidently性能仪表板示例
您可能可以计算数百种不同的指标！让我们尝试将它们分组以便快速查看。
模型质量指标。这组指标评估模型预测的真实质量。一旦掌握了ground truth或feedback（例如，关于点击、购买、实际交货时间等的数据），您就可以计算它们。以下是一些示例：
- 回归：MAE（平均绝对误差）、RMSE（均方根误差）。
- 分类：accuracy，precision，F1-score。
- 排名：top-k 准确率，MAP（平均平均精度）。
按段划分的模型质量。汇总指标是必不可少的，但通常还不够。您可能有 90% 的整体准确率，但在一些重要的子群体（如新用户）中只有 60%。要检测此类差异，您可以跟踪数据中已知细分的模型质量（例如，不同地理位置的准确性）或主动搜索表现不佳的细分。
预测漂移。这是第一种代理质量监控。如果你不知道你的模型有多好，你至少可以密切关注它的预测有多么不同。想象一下，垃圾邮件检测模型突然开始在每一秒的预测中分配“垃圾邮件”标签。你甚至可以在得到真正的标签之前发出警报。要评估预测漂移，您可以使用不同的漂移检测方法：
- 跟踪模型输出的描述性统计数据（例如，平均预测值、标准偏差）。
- 应用统计测试（例如，Kolmogorov-Smirnov 测试、卡方测试）将最新模型输出与旧模型输出进行比较。
- 使用概率距离度量来比较分布（例如，Wasserstein 距离）。
输入数据漂移。除了预测漂移之外，您还可以监控输入数据的变化并一起解释它们。目标是检测模型在不熟悉的环境中运行的情况，从数据中可以看出。检测方法类似于预测漂移。您可以监控各个特征的描述性统计数据（例如类别的频率）、运行统计测试或使用距离度量来检测分布变化。您还可以跟踪特定模式，例如特征和预测之间的线性相关性的变化。
CS 329S教程中的Evidently数据漂移仪表板示例
异常值。您可以检测出现异常以及模型可能无法按预期工作的个别案例。这与数据漂移不同，后者的目标是检测整体分布变化。当然，您仍然可以使用异常值的比率作为指标来绘制和警告。但是异常值检测的目标通常是识别个体异常输入并对其采取行动，例如，将它们标记为专家审查。您可以使用不同的统计方法（例如：孤立森林（isolation forests）或距离度量）来检测它们。
公平。这是模型质量的一个特定维度，由用例重要性和风险决定。如果 ML 决策像在金融、医疗保健和教育用例中经常发生的那样具有严重影响，您可能需要确保该模型在不同的人口群体中表现同样出色。有不同的指标来评估模型偏差，例如群体均等（demographic parity）或机会均等（equalized odds）。如果您有自动模型再训练，跟踪这些指标尤其重要，并且它的行为可能会随着时间而偏离。
您会注意到一些指标，例如：特征统计和异常值，同时出现在数据质量和模型质量上下文中。无论如何，当您查看数据时，ML 和数据监控通常是齐头并进的。但是，监控中以机器学习为重点的部分会查看数据以评估模型相关性。相比之下，监控中以数据质量为重点的部分会查找数据本身的损坏和错误。
ML监控有什么难点？
几乎没有蓝图！
- 模型质量是特定于上下文的。没有“标准准确度级别”或“明显的数据漂移”。模型质量期望取决于用例。例如，您可能非常关心个别特征的漂移，也可能很少关心。一些模型具有季节性；在设置比较窗口时应该考虑它。在某些情况下，您可能希望在几分钟内汇总数据；在其他情况中，超过几天。底线是您需要了解模型和数据以选择正确的监控指标和启发式方法。
- 没有ground truth的监测。这种半盲监控对于 ML 来说是非常特殊的。您可能还会有部分反馈（例如，当专家手动检查仅部分预测时）或ground truth标签以不同的时间间隔到达。在没有大量警报的情况下定义模型质量的合适代理是很困难的。
- 大规模计算指标。计算一小组现有数据的准确性可能是微不足道的。但是，随着规模的度量计算，它变得更加复杂。例如，您如何以分布式方式计算统计指标并快速完成？构建一个可扩展的、标准化的机器学习监控基础设施并不容易，尤其是对于实时应用程序。
如何实现机器学习监控：
我们致力于在我们创建的开源 ML 监控工具集 Evidently 中实施 ML 监控中的一些最佳实践。如果这是您想要解决的问题，请加入我们的 Discord 社区，在 GitHub 上聊天和分享或测试该工具！
4. 业务指标和KPI
终于到了来讨论商业价值了！
要判断 ML 模型的性能，您最终需要将其与业务 KPI 联系起来。 ML 模型是否完成了它所构建的工作？
业务指标监控的目标是什么？
估计 ML 系统的商业价值，并在事情偏离轨道时进行调整。 ML 模型质量和商业价值之间总是存在不匹配的风险。这可能是由于不断变化的现实或模型未按设计方式使用（或根本未使用！）
这对机器学习监控有多具体？
这部分是严格特定于业务的。指标和衡量它们的方式无处不在。它的范围可以从跟踪 Web 应用程序中的参与度指标到评估工业工厂中原材料的节省。这一切都归结为业务用例。
谁通常随叫随到？
产品经理、企业主或运营团队与数据科学家一起弥合差距。
你能监控什么？
- 直接业务 KPI。您可能会密切关注直接的业务和产品指标。例如，页面上的点击率或生产过程中使用的原材料数量（如果这是 ML 系统帮助优化的！）。如果幸运的话，您也许可以通过查看这些指标来跟踪 ML 解决方案的业务影响。例如，如果 ML 系统作为独立应用程序存在，您可以直接将一些收入或节省归因于它。
- A/B 测试性能。目标业务指标通常受多种因素影响。一个好的旧 A/B 测试可以帮助衡量 ML 系统的孤立影响。例如，您可以拆分流量以将基于 ML 的推荐块的性能与基线进行比较。 ML 系统是否比简单地推荐前 10 名最受欢迎的商品带来更多的销售？如果你有足够的流量，你甚至可以连续运行它，让一小部分远离 ML。如果您正在处理一个新的高风险区域并关注长期模型影响（例如:影响环境的模型），这可能是合理的。
- 间接指标。有时很难将 ML 性能与收入或转化等主要业务指标联系起来。在这种情况下，您仍然可以评估反映 ML 模型质量的辅助指标。如果您有启用 ML 的特征，您可以跟踪它的使用频率。如果您向用户推荐内容，您可以跟踪参与度以及点击推荐块后他们在页面上停留的时间。您还可以引入一些可解释的检查，以帮助企业主了解模型在做什么，例如，批准了多少贷款。
Nubank ML 团队关于监控策略层的一些建议：
监控使用该模型做出的决策。例如：每天有多少人获得风险模型批准的贷款？每天有多少人的账户被欺诈模型封锁？在这里监控绝对值和相对值通常很有用。
资料来源：ML Model Monitoring – 9 Tips From the Trenches，Nubank 博客。
监控业务 KPI 有什么技巧？
- 你不能总是测量它们。进行 A/B 测试可能过于昂贵、复杂或不可行。通常，您无法隔离 ML 系统的影响，因为有多种因素会影响目标 KPI。在信用评分等情况下，评估做出贷款决定的业务影响可能需要数月或数年的时间。您应该始终尝试找到一些代理，或者至少是业务利益相关者可以解释的健全性检查。但是你不能总是快速获得美元和美分的价值。
- 在模型退化的情况下，业务指标给出的上下文最少。如果指标下降，您必须遍历每个金字塔层以对其进行排序。是模型吗？是数据吗？是软件吗？业务指标是最关键的价值指标（它们位于金字塔顶端是有原因的）。尽管如此，您仍需要更多的可观察性才能获得及时的警报并有效地调试系统。
如果可以的话，跟踪它们，但也要跟踪其他的东西。
你需要所有这些吗？
我们知道，这是很多！
本概述的目的是介绍生产 ML 系统的所有不同方面。一旦部署了 ML 应用程序，它就不再只是一个模型，而是一个由数据、代码、基础设施和周围环境组成的复杂系统。您需要对其进行整体监控。
这并不意味着您应该一直查看数十个指标和图表。
首先，团队中的不同人员可能使用多个仪表板或视图。
您可以在现有的后端监控工具中进行操作监控。 您可以在业务利益相关者已经使用的 BI 仪表板中可视化产品指标。 根据设置，您可以将 ML 监控指标添加到同一个 Grafana 仪表板，通过 Airflow 编排的管道测试检查它们，或者启动 ML 团队使用的独立仪表板。 ML 监控的不同方面有不同的内部用户（和问题解决者）。 拥有多个仪表板很好。
以下是 Monzo 的案例：
了解模型的实时性能是模型开发过程的关键部分。 在这个阶段，我们依靠重用而非重建原则，并采用了在整个公司中使用的工具。 我们希望我们的监控工具可供所有人使用，包括机器学习以外的人。
来源：Monzo's machine learning stack，Monzo 博客。
其次，你应该区分监控和调试。 您可能只针对最能反映服务性能的少数指标主动监控和引入警报。 您的目标是了解潜在问题。 其余的指标和图表在调试过程中会很有帮助，因为它们提供了必要的上下文。 但是您不会主动设置警报或为其定义特定阈值。
例如，如果您快速获得模型反馈，您可能会跳过有关特征漂移的警报。 毕竟，您可以评估模型质量本身。 但是，如果您注意到性能下降，则需要确定原因并决定如何处理漂移。 为重要特征预先构建分布可视化或有一种简单的方法来按需旋转它可能是有意义的。 在其他情况下，您可能更喜欢监控数据漂移，即使您获得了标签。
总而言之，监控的目标是让人们确信系统运行良好，如果不是，则发出警报。如果发生故障，您需要必要的上下文来诊断和解决问题，这就是额外指标派上用场的地方，但您不需要一直查看它们。
总结
机器学习监控意味着监控机器学习系统。要观察和评估其性能，您通常需要一组描述系统状态的指标。该系统有几个方面值得关注。
我们可以将它们分组为：
- 软件系统运行状况。您可以像其他后端服务一样监控它。它并非特定于数据科学和机器学习，但仍需要适当的设置。
- 数据质量和完整性。应该查看流经特定 ML 预测管道的数据。目标是检查它没有错误或损坏，并且您仍然可以相信这些数据成为您的模型输入。您通常可以在生成预测之前引入管道测试来验证输入数据。
- ML 模型质量。这是最特定于 ML 的监控组件。您希望密切关注模型相关性，以确保它适合任务。如果您有延迟反馈，您可能会求助于监控数据和预测漂移作为模型质量的代理。
- 业务 KPI。业务或产品指标是模型投资回报率和价值的最终衡量标准，但通常是最难衡量的。
您可能不需要详细查看每个金字塔层。他们可能在后端工程师、数据工程、ML 团队和业务利益相关者之间有不同的内部消费者。
确切的监控策略还取决于模型是批处理还是实时模型、获得ground truth标签的速度、模型的重要性以及相关风险。您可能会使用一些指标进行实际监控（对它们设置警报），同时让其他指标可用于报告和调试目的（例如，预先计算并存储在某处）。
以下是一些指标示例的摘要：
原文链接：Monitoring ML systems in production. Which metrics should you track?
