了解ML监控债务

本文是持续系列的一部分,探索ML监测债务的主题,如何识别它以及管理和减轻其影响的最佳实践

我们都很熟悉软件工程中的技术债务,在这一点上,ML系统中隐藏的技术债务几乎是教条。但ML监控债务是什么呢?当模型监视被它想要监视的ML系统的规模所淹没时,ML监视债务。这让从业者只能在大海捞针,或者更糟的是,点击警报中的“删除所有”按钮。

ML监控远不及与传统的APM监控一样清晰。不仅在度量和基准方面没有绝对的真理,而且模型也不受规模经济的影响。启动一个新的Kubernetes集群很容易,并且集群将受到与之前集群相同的性能指标、基准、阈值和kpi的约束。但是,当您部署一个新模型时,即使它是一个预先存在的模型,并且没有对工件进行更改,实际上也可以保证您的引用将是不同的。这意味着您将为部署到生产和监控中的每个模型承担债务。

什么是糟糕的性能水平?

80%的准确率?60%的准确率?

需要考虑多个因素来确定一个好的/坏的性能水平,并且根据每个模型的用例、部分,当然还有数据,底线是不同的。在这篇文章中,我们将通过使用ML模型来解释债务维度“大数据的四个v”框架,这对这种比较感到惊奇。

1.真实性

高度

根据2-3个元素度量和监控数据驱动的过程是相当简单的。但是ML主要是利用大量的数据源和实体来定位底层的、可预测的模式。根据问题和相关数据,您可以查看几十个特性,甚至成百上千个特性,每个特性都应该独立监控。

模型指标

ML是一个面向随机数据的世界,由多个不同的生产管道组合而成。这意味着需要为每个实体跟踪和监视大量的指标和元素,例如特性平均值、std、数值元素和基数级别的缺失值、熵,以及分类元素的更多值。全面的模型度量超越了特征、数据和管道完整性,提供了可量化的度量来分析模型输入和输出的相对质量。

芯片Huyen最近出版了一本模型指标的全面列表涵盖了值得检查的整个模型生命周期。

2.体积

ML监控中的容量需要在两个维度上进行分析:吞吐量和粒度

吞吐量

模型通常在大量数据上工作,以实现决策过程的自动化。这对监视和观察数据集的分布和行为提出了一个工程挑战。监视解决方案需要在几分钟内检测数据质量和性能问题,同时分析长时间内的巨大数据流。

分辨率的数据

要在亚种群水平上检测事物,需要能够按段分割数据,但这也是一个分析挑战。在不同的子种群下,同一度量的数据和模型性能的性质可能会有很大的差异。

例如,缺失值指标在一个功能叫做“年龄”通常是总人口的20%,但对于一个特定的频道,说Facebook的价值可能是可选的,在60%的情况下是一个缺失值,这是一个对于所有其他人群在只有0.5%的情况下,缺失值。

高级视图只能提供有限的信息,特别是关于子种群和对支持业务需求和决策至关重要的详细解决方案的信息。影响整个数据集或群体的宏观事件是每个人都知道要注意的事情,通常可以相对快速地检测到。

但这意味着,在大量数据流中检测问题的工程和分析挑战现在要乘以需要监视的不同段的数量。

3.速度

模型以不同的速度服务于业务流程的自动化,从批量的每日\每周预测到实时的大规模决策。根据您的用例,您需要能够支持不同类型的速度。不过,和体积一样,速度还有一个额外的维度需要处理,即管道速度。将整个推理流视为持续改进的管道。为了在不破坏内容的情况下快速移动,您需要将延迟反馈重新整合到ML决策过程中。

在某些用例中,例如广告技术实时竞标算法,我们将希望监视每周效果,因为我们需要以分钟为避免业务灾难的方式检测数据质量或性能问题。

4.各种

最后但并非最不重要的是,我们来谈谈多样性。一个成功的具有业务ROI的模型跨越了更多的模型。一旦您通过了第一个模型障碍,并证明了ML对业务结果的积极影响,您的团队和您的业务都将希望复制这一成功并扩大其规模。有三种缩放模型的方法,它们之间并不相互排斥。

版本

ML是一个迭代的过程,我们就是这样做的。现实世界不是静态的,因此管道和模型必须不断优化。版本不断地为相同的现有模型创建,但是每个版本实际上是一个完全不同的模型实例,它可能具有不同的特性,甚至不同的基线。

用例的规模

将用例添加到您的库中意味着您实际上是从头开始重新启动整个MLOps循环。您可以保留许多东西,特别是涉及到特性工程时,但是当您部署到生产时,您将有一个新的模型度量集和规模来监视。除了ML监视的技术方面外,模型驱动业务流程,每个流程都是不同的。对于相同的贷款批准模型,风险和合规团队可能会担心由于监管方面的担忧而产生的潜在偏见,业务运营部门希望第一时间知道模型是否突然决定全面拒绝贷款,ML工程师需要了解完整性和管道问题,数据科学团队可能会对模型预测中的缓慢漂移感兴趣。重点是它是多学科的,您的涉众对ML决策过程的不同方面感兴趣。在一个新的过程中,你需要确保你正在快速地交付价值。

多租赁量表

多租户具有指数级扩展容量。当租户本身等于一个种群时,就需要决定跨多个原则部署模型。例如,部署一个学习过程来检测潜在的客户流失,但在每个国家(本例中为租户)分别进行。结果是每个国家都有一个独立的模式。

做出这样的决定可能会让你在一夜之间从一个单一的欺诈模型变成数百个欺诈模型。虽然它们可能共享相同的度量标准,但期望值和行为会有所不同。

关于模型监控债务,我们学到了什么

从表面上看,模型监测似乎很简单。公平地说,使用一两个模型,如果您愿意投入资源,手动监控ML是可行的。但在ML工程中,就像软件工程一样,一切都是债务和规模的问题。是否值得承担和支付之后?模型监视不是一项简单的任务,从技术和流程的角度来看,它也不是直接的,随着您的扩展,管理ML监视的难度也会增加。

4v说明了为什么模型监测是复杂的,作为量化这个问题的练习,让我们考虑以下数字:

现在,我们已经量化了ML监控的内在规模问题及其原因,下一步是识别债务。本系列的以下部分将讨论如何确定债务指标和管理和克服债务监测模式的最佳做法。

请继续关注!

奥伦Razon公司的联合创始人和首席执行官是超级领先的模型观测平台。为从业者提供完全自动化的企业级模型监控能力,这种能力需要数年时间才能在内部开发,封装在一个自助服务平台中。

领先的模型可观测平台Superwise的联合创始人兼CEO。Ex Intel和终身MLOps从业者。

Baidu
map