> 文档中心 > 在生产中监控机器学习模型的指南

在生产中监控机器学习模型的指南


在生产中监控机器学习模型的指南

在生产中监控机器学习模型的指南

机器学习模型越来越多地用于做出重要的现实世界决策,从识别欺诈活动到在汽车中应用自动刹车。

一旦将模型部署到生产环境中,机器学习从业者的工作就远未结束。 您必须监控您的模型,以确保它们在面对现实世界的活动时继续按预期执行。 但是,像使用传统软件那样监视机器学习系统是不够的。

那么,如何有效监控生产中的机器学习模型呢? 需要监控哪些具体指标? 什么工具最有效? 这篇文章将为机器学习从业者回答这些关键问题。

监控机器学习模型的重要性

在机器学习的上下文中,监控是指跟踪已部署模型的行为以分析性能的过程。 部署后监控机器学习模型至关重要,因为模型可能会在生产中损坏和降级。 部署不是您执行并忘记的一次性操作。

为了确定在生产中更新模型的正确时间,必须有一个实时视图,使利益相关者能够不断地评估模型在实时环境中的性能。 这有助于确保您的模型按预期运行。 需要尽可能多地了解已部署的模型,以便在问题和来源造成负面业务影响之前检测到它们。

获得知名度听起来很简单,但事实并非如此。 监控机器学习模型是一项艰巨的任务。 下一节将更深入地探讨监控机器学习模型的挑战。

为什么机器学习系统监控难?

多年来,软件开发人员一直在将传统软件投入生产,因此这是评估使用机器学习模型进行相同操作的难度的一个很好的起点。

必须承认,在生产中对机器学习模型的任何讨论都类似于讨论机器学习系统。 机器学习系统面临传统软件的挑战以及机器学习特有的若干挑战。 要了解有关这些挑战的更多信息,请参阅机器学习系统中隐藏的技术。

机器学习系统行为

在构建机器学习系统时,从业者主要热衷于跟踪系统的行为。 三个组件决定了系统的行为:

  1. 数据(特定于 ML):机器学习系统的行为取决于训练模型所依据的数据集,以及在生产过程中流入系统的数据。
  2. 模型(特定于 ML):模型是在数据上训练的机器学习算法的输出。 它代表算法学到了什么。 最好将模型视为管道,因为它通常由所有步骤组成,以编排数据流进入模型和从模型输出。
  3. 代码:需要代码来构建机器学习管道并定义模型配置以训练、测试和评估模型。

正如 Christopher Samiullah 在机器学习模型的部署中所说,“如果没有一种方法来理解和跟踪这些数据(以及模型)的变化,你就无法理解你的系统。”

代码、模型和数据中指定的规则会影响整个系统的行为。 回想一下,数据来自一个永无止境的来源——“真实世界”——它不断变化,因此变得不可预测。

机器学习系统中的挑战

在构建机器学习系统时,这并不像说“我们还有两个额外的维度”那么简单。 由于以下挑战,代码和配置给机器学习系统带来了更多的复杂性和敏感性:

  • 纠缠:输入数据分布的任何变化都会影响目标函数的逼近,这可能会影响模型做出的预测。 换句话说,改变任何事情都会改变一切。 因此,任何特征工程和选择代码都必须经过仔细测试。

  • 配置:模型配置中的缺陷(例如,超参数、版本和功能)可以从根本上改变系统的行为,并且不会被传统的软件测试发现。 换句话说,机器学习系统可以在不引发异常的情况下预测不正确但有效的输出。

与受代码中指定规则约束的传统软件系统相比,这些因素结合在一起使得监控机器学习系统变得极其困难。 另一个需要考虑的因素是参与开发机器学习系统的利益相关者的数量。 这被称为责任挑战。

责任挑战

通常,在一个项目中拥有多个利益相关者可能会非常有益。 每个利益相关者都可以根据他们的专业知识提供对需求和约束的洞察力,使团队能够减少和发现项目风险。

但是,每个利益相关者可能会根据业务领域和职责对“监控”的含义有完全不同的理解。 可以在数据科学家和工程师之间进行示例区分。

数据科学家的观点

数据科学家最关心的是实现功能目标,例如输入数据的变化、模型以及模型做出的预测。 监控功能目标需要了解传入模型的数据、模型本身的指标以及对模型所做预测的理解。

数据科学家可能更关心模型在生产环境中的准确性。 为了获得这样的洞察力,如果真正的标签实时可用,那将是理想的,这只是有时会出现这种情况。 因此,数据科学家经常使用代理值来了解他们的模型。

工程师的视角

另一方面,工程师通常负责实现确保机器学习系统资源健康的运营目标。 这需要监控传统软件应用程序指标,这在传统软件开发中很常见。 例子包括:

  • 潜伏
  • IO/内存/磁盘使用
  • 系统可靠性(正常运行时间)
  • 可审核性

尽管利益相关者的目标和责任存在差异,但对机器学习系统的充分监控会同时考虑这两个方面。 但是,仍然需要全面了解。 为了实现这样的壮举,所有利益相关者齐心协力确保术语定义明确,以便所有团队成员都说同一种语言仍然至关重要。

生产中需要监控什么?

监控分为两个级别:功能级和操作级。

功能级监控

在功能层面,数据科学家(或/和机器学习工程师)将监控三个不同的类别:输入数据、模型和输出预测。 监控每个类别可以让数据科学家更好地了解模型的性能。

输入数据

模型取决于作为输入接收到的数据。 如果模型接收到它不期望的输入,则模型可能会崩溃。 监控输入数据是检测功能性能问题并在它们影响机器学习系统性能之前消除它们的第一步。 从输入数据的角度监控的项目包括:

数据质量:为了保持数据完整性,您必须在生产数据看到机器学习模型之前使用基于数据属性的指标对其进行验证。 换句话说,确保数据类型是等价的。 有几个因素可能会损害您的数据完整性; 例如,源数据模式的更改或数据丢失。 这些问题改变了数据管道,使模型不再接收预期的输入。

数据漂移:可以监视训练数据和生产数据之间的分布变化以检查漂移:这是通过检测特征值的统计属性随时间的变化来完成的。 数据来自一个永无止境、不断变化的来源,称为现实世界。 随着人们行为的变化,您正在解决的业务案例的环境和背景可能会发生变化。 届时,是时候更新您的机器学习模型了。

模型

机器学习系统的核心是机器学习模型。 对于推动业务价值的系统,模型必须保持高于阈值的性能水平。 必须监控可能阻碍模型性能的各个方面以实现此目标,例如模型漂移和版本。

模型漂移:模型漂移是由于现实环境的变化导致模型预测能力的衰减。 应使用统计测试来检测漂移,并应监控预测性能以评估模型随时间的性能。

版本:始终确保正确的模型在生产中运行。 应该跟踪版本历史和预测。

输出

要了解模型的执行方式,您还必须了解模型在生产环境中输出的预测。 将机器学习模型投入生产以解决问题。 因此,监控模型的输出是确保其根据用作 KPI 的指标执行的有价值的方法。 例如:

Ground truth:对于某些问题,您可以获得 ground truth 标签。 例如,如果使用模型向用户推荐个性化广告(您正在预测用户是否会点击该广告),并且用户点击以暗示该广告是相关的,您几乎可以立即获得 ground truth。 在这种情况下,可以根据实际解决方案评估模型预测的聚合,以确定模型的性能。 然而,在大多数机器学习用例中,根据真实标签评估模型预测很困难,因此需要一种替代方法。

预测漂移:当无法获取地面实况标签时,必须监控预测。 如果预测的分布发生剧烈变化,则可能出现了问题。 例如,如果您正在使用一个模型来预测欺诈性信用卡交易,并且突然发现被识别为欺诈的交易比例猛增,那么情况就发生了变化。 也许输入数据结构已被更改,系统中的某些其他微服务行为不当,或者世界上存在更多欺诈行为。

运营层面监控

在运营层面,运营工程师关心的是确保机器学习系统的资源健康。 当资源不健康时,工程师负责采取行动。 他们还将监控三个类别的机器学习应用程序:系统、管道和成本。

机器学习系统性能

这个想法是要不断了解机器学习模型如何根据整个应用程序堆栈执行。 这个领域的问题将影响整个系统。 可以深入了解模型性能的系统性能指标包括:

  • 内存使用
  • 延迟
  • CPU/GPU 使用

管道

应监控两个关键管道:数据管道和模型管道。 未能监控数据管道可能会引发导致系统崩溃的数据质量问题。 关于模型,您希望跟踪和监控可能导致模型在生产中失败的因素,例如模型依赖项。

费用

从数据存储到模型训练等等,机器学习涉及财务成本。 虽然机器学习系统可以为企业创造大量价值,但利用机器学习也有可能变得极其昂贵。 持续监控您的组织的机器学习应用程序成本是确保维持成本的负责任步骤。

例如,您可以使用 AWS 或 GCP 等云供应商设置预算,因为他们的服务会跟踪您的账单和支出。 当预算达到最大值时,云提供商将发送警报以通知团队。

如果您在本地托管机器学习应用程序,监控系统使用情况和成本可以更深入地了解应用程序的哪个组件成本最高,以及您是否可以做出某些妥协以削减成本。

用于监控机器学习模型的工具

现在开始使用机器学习模型监控比以往任何时候都容易。 一些企业已经生产了工具来简化在生产中监控机器学习系统的过程。 没有必要重新发明轮子。

用于监控系统的工具取决于您要监控的具体项目。 值得浏览以找到最适合您的方法,然后再做出最终决定。 下面列出了一些您可能希望开始使用的解决方案。

Prometheus and Grafana

Prometheus 是一个用于事件监控和警报的开源系统。 它的工作原理是从检测作业中抓取实时指标并将抓取的样本存储在本地作为时间序列数据。

Grafana 是一种开源分析和交互式可视化 Web 应用程序,可与 Prometheus 协作使用以可视化收集的数据。

简而言之,您可以结合 Prometheus 和 Grafana 的强大功能来创建仪表板,让您可以在生产环境中跟踪您的机器学习系统。 您还可以使用这些仪表板设置警报,以便在发生意外事件时通知您。

如果您使用 NVIDIA Triton 推理服务器在生产中部署、运行和扩展 AI 模型,您可以利用 NVIDIA Triton 以 Prometheus 格式导出的操作指标。 您可以使用 NVIDIA Triton 从运行推理的系统中收集 GPU/CPU 使用、内存和延迟指标。 这些指标可用于扩展和负载平衡请求,从而满足应用程序 SLA。

了解有关 Prometheus 和 Grafana 的更多信息。

显然是人工智能

显然,AI 是一种开源 Python 工具,用于在生产环境中分析、监控和调试机器学习模型。 联合创始人 Emeli Dral 和 Elena Samuylova 撰写了有关模型监控的内容丰富的文章,包括:

  • 监控生产中的机器学习模型
  • 机器学习监控:它是什么,我们缺少什么
    要了解更多信息,请参阅 Evidently AI 文档。

Amazon SageMaker 模型监视器

一目了然,Amazon SageMaker Model Monitor 可以提醒您模型质量的任何偏差,以便可以采取纠正措施,例如重新训练、审计上游系统或修复质量问题。 开发人员可以利用无代码监控功能或通过编码进行自定义分析。 有关更多详细信息,请参阅 Amazon SageMaker 文档。

机器学习模型监控的最佳实践

作为机器学习从业者,部署模型只是您职责的一部分。 您工作的其他部分涉及确保模型在实时环境中按预期执行,这需要监控机器学习系统。 监控机器学习系统时要遵循的一些一般最佳实践包括:

监控不会在部署阶段开始

构建机器学习模型通常需要多次迭代才能得出可接受的设计。 因此,跟踪和监控指标和日志构成了模型开发的重要组成部分,一旦开始试验就应该强制执行。

严重退化是一个危险信号,需要进行调查

应该预料到模型性能会下降。 然而,突然的大幅下降令人担忧,应立即进行调查。

创建故障排除框架

应该鼓励团队记录他们的故障排除框架。 一个让团队从警报状态到故障排除状态的系统对于模型维护是有效的。

制定行动计划

在您的机器学习系统不可避免地出现中断的情况下,应该有一个框架来响应。 一旦团队收到问题警报,框架应将团队从警报转变为行动,然后最终调试问题以确保模型得到有效维护。

当真实情况不可用时使用代理

始终了解您的机器学习模型在生产环境中的性能至关重要。 如果无法根据真实情况评估模型,则预测漂移等代理就足够了。