中国建设工程协会网站东胜区建设局网站

当前位置： 首页 > news >正文

中国建设工程协会网站,东胜区建设局网站,天元建设集团有限公司张国庆,展位搭建简介 一旦您将机器学习模型部署到生产环境中#xff0c;很快就会发现工作还没有结束。 在许多方面#xff0c;旅程才刚刚开始。你怎么知道你的模型的行为是否符合你的预期#xff1f;下周/月/年#xff0c;当客户#xff08;或欺诈者#xff09;行为发生变化并且您的训练…简介 一旦您将机器学习模型部署到生产环境中很快就会发现工作还没有结束。 在许多方面旅程才刚刚开始。你怎么知道你的模型的行为是否符合你的预期下周/月/年当客户或欺诈者行为发生变化并且您的训练数据过时时呢这些都是复杂的挑战而且机器学习监控在工具和技术方面都是一个快速发展的领域。似乎这还不够监控是一项真正的跨学科工作但“监控”一词在数据科学、工程、DevOps 和业务中可能意味着不同的东西。鉴于这种复杂性和模糊性的强硬结合许多数据科学家和机器学习 (ML) 工程师对监控感到不确定也就不足为奇了。 本综合指南旨在至少让您了解在生产中监控机器学习模型的复杂性来自何方为什么它很重要此外还将为实施您自己的机器学习监控解决方案提供一个切实可行的起点。如果您正在寻找示例代码、教程和示例项目您可能会对我们专门针对该主题的在线课程感兴趣测试和监控机器学习模型部署。 目录 机器学习系统生命周期是什么让机器学习系统监控变得困难为什么需要监控监控机器学习系统的关键原则了解机器学习风险管理的范围数据科学监控问题运营监控问题将 Ops 和 DS 结合在一起 - Prometheus 和 Grafana 的 Metrics将 Ops 和 DS 结合在一起 - 日志不断变化的局势 1. 机器学习系统生命周期 机器学习模型的监控是指我们从数据科学和运营角度跟踪和了解生产中模型性能的方式。 不充分的监控可能导致不正确的模型在生产中未经检查过时的模型停止增加业务价值或者模型中的细微错误随着时间的推移而出现并且永远不会被发现。 当 ML 成为您业务的核心时未能捕捉到这些类型的错误可能会引发破产事件——尤其是当您的公司在受监管的环境中运营时。 Martin Fowler 普及了机器学习持续交付 (CD4ML) 的概念该概念的图表为机器学习生命周期和监控发挥作用提供了有用的可视化指南 image.png 此图概述了 ML 模型生命周期中的六个不同阶段 模型构建理解问题、数据准备、特征工程和初始代码。典型的制品是粗糙的 Jupyter notebook。模型评估和实验特征选择、超参数调整以及比较不同算法在给定问题上的有效性。典型的制品包括带有统计数据和图表的notebook用于评估特征权重、准确度、精度和ROC。产品化模型获取“研究”代码并对其进行准备以便可以部署。典型的制品是生产级代码在某些情况下将使用完全不同的编程语言或框架。测试确保生产代码按照我们预期的方式运行并且其结果与我们在模型评估和实验阶段看到的结果相匹配。典型的制品是测试用例。部署将模型投入生产它可以通过提供预测来开始增加价值。典型的制品是用于访问模型的 API。监控和可观察性最后阶段我们确保我们的模型在生产中按照我们期望的那样工作。这篇博文的主题。 在图中请注意周期性方面其中在最终“监控和可观察性”阶段收集的信息反馈给“模型构建”。对于大多数公司来说这是一个从业务角度评估模型影响的非自动化过程然后考虑现有模型是否需要更新、放弃或可能从补充模型中受益。在更先进的公司中这可能意味着在监控阶段收集的数据以自动方式直接输入到模型更新的训练数据中这带来了很多额外的挑战。 您可以将图表的前两个阶段“模型构建”和“模型评估”视为研究环境通常是数据科学家的领域而后四个阶段则更多地属于工程和 DevOps 领域尽管这些区别各不相同从一家公司到另一家公司。如果您不确定部署阶段需要什么我已经写了一篇关于该主题的帖子。 监控场景 与软件中的大多数事情一样真正的挑战在于可维护性。 在 Flask 中部署和服务 ML 模型并不太具有挑战性。 事情变得复杂的地方在于以可重复的方式执行此操作尤其是在模型频繁更新的情况下。 我们的典型更新场景如下所示 image.png 第一种场景只是部署一个全新的模型。第二种情况是我们用完全不同的模型完全替换这个模型。第三种情况右侧非常常见意味着对我们当前的实时模型进行小幅调整。 假设我们在生产中有一个模型但有一个变量不可用所以我们需要在没有该特性的情况下重新部署该模型。 或者我们开发了一个我们认为非常具有预测性的超级特征并且我们想要重新部署我们的模型但现在将这个新特征作为额外的输入。 无论情况如何监控都是我们确定模型更改是否产生预期效果的方式这是我们最终关心的。 这条规则的唯一例外是影子部署我在这篇文章中对此进行了解释。 但在我们深入研究监控的细节之前有必要讨论一下 ML 系统构建上下文所固有的一些挑战。 2. 是什么让机器学习系统监控变得困难 机器学习系统具有传统代码的所有挑战以及一系列针对机器学习的额外考虑因素。 这在谷歌“机器学习系统中的隐藏技术债务”的论文中有很好的记录。 从上面提到的论文中得到的一个关键点是一旦我们谈论生产中的机器学习模型我们就是在谈论 ML 系统。 该模型只是整个 ML 系统的一小部分 image.png 对于 ML 系统我们从根本上投资于跟踪系统的行为这归结为三个组成部分 image.png 代码和配置模型ML 系统特定要求数据ML 系统特定要求 在 ML 系统中我们有两个额外的组件需要考虑即数据依赖和模型。与传统软件系统不同ML 系统的行为不仅受代码中指定的规则支配还受从数据中学习的模型行为支配。更复杂的是数据输入是不稳定的可能会随着时间而变化。 如果无法理解和跟踪这些数据以及模型更改您将无法理解您的系统。 但它并没有就此结束。这不像“好吧我们有两个额外的维度要考虑”那么简单这已经足够具有挑战性了。由于以下原因代码和配置还会在 ML 系统中增加额外的复杂性和敏感性 缠绕当输入特征发生变化时其余特征的重要性、权重或使用也可能发生变化。这也被称为“改变任何事情都会改变一切”的问题。 ML 系统特征工程和选择代码需要非常仔细地测试。配置由于模型超参数、版本和特征通常在系统配置中进行控制因此这里最轻微的错误都可能导致完全不同的系统行为而传统的软件测试无法识别这些行为。在模型不断迭代和微妙变化的系统中尤其如此。 希望机器学习系统的难点开始变得清晰起来。另一个需要考虑的挑战是系统中涉及的团队数量之多。 责任挑战 ML Systems跨多个团队也可能包括数据工程师、DBA、分析师等 image.png 在我们继续分解监控之前值得一提的是这个词在业务的不同部分有不同的含义。 数据科学家一旦我们解释说我们谈论的是后期生产监控而不是部署前评估这是我们在研究环境中查看 ROC 曲线等的地方这里的重点是模型的统计测试输入和输出更多细节请参见第 6 节。工程师和 DevOps当您说“监控”时请考虑系统运行状况、延迟、内存/CPU/磁盘利用率更多细节请参见第 7 节 对于 ML 系统您需要这两种观点。虽然在传统的软件实践中监控和可观察性往往落在 DevOps 上但在 ML 系统中您的 DevOps 团队不太可能具备正确监控 ML 模型所需的专业知识。这意味着 整个团队需要共同努力进行监控并说彼此的语言以使系统有效定义我们的术语以避免混淆很重要。 所有这些复杂性意味着如果您在部署之后只考虑孤立的模型监控您将非常低效。在我们的 ML 生命周期的生产阶段与测试一起应在系统级别计划监控。持续的系统维护、更新和实验、审计和细微的配置更改会导致技术债务和错误累积。在我们进一步进行之前值得考虑未能监控的潜在影响。 3. 为什么需要监控 “没有做好准备你就是在准备失败” 监控的设计应旨在为生产环境 ML 模型可能出错的无数事情提供提前警告其中包括 数据偏差 当我们的模型训练数据不能代表实时数据时就会出现数据倾斜。也就是说我们在研究或生产环境中用于训练模型的数据并不代表我们在现场系统中实际得到的数据。 发生这种情况的原因有多种 我们错误地设计了训练数据训练数据中的变量分布与实时数据中的变量分布不匹配。生产中不可用的特征这通常意味着我们需要删除该特征将其更改为生产中存在的替代类似变量或者通过组合生产中存在的其他特征来重新创建该特征。研究/实时数据不匹配我们用于在研究环境中训练模型的数据来自一个来源而实时数据来自不同的来源。这可能意味着变量的制造方式可能不同因此即使管道对相同的输入数据返回相同的预测这意味着我们的差异测试通过不同的数据源可能会导致相同特征中固有的不同值这将导致不同的预测。数据依赖我们的模型可能会摄取由其他系统内部或外部创建或存储的变量。这些系统可能会改变它们生成数据的方式但遗憾的是这种情况通常不会被清楚地传达。连锁反应是今天产生的变量与几年前产生的变量不等价。特征的代码实现会发生变化产生略有不同的结果或者特征的定义可能会发生变化。例如外部系统可能会将投票年龄从 18 岁调整为 16 岁。如果投票年龄是模型中的一个重要特征这将改变其预测。 模型陈旧 环境变化如果我们使用历史数据来训练模型我们需要预测当前的人口及其行为可能不同。例如如果我们使用经济衰退时期的数据来训练我们的财务模型那么在经济健康时期预测违约可能无效。消费者行为的变化客户偏好随着时尚、政治、道德等方面的趋势而变化。特别是在推荐机器学习系统中这是一个必须不断监控的风险。对抗场景不良行为者欺诈者、犯罪分子、外国政府可能会积极寻找模型中的弱点并相应地调整他们的攻击。这通常是一场持续的“军备竞赛”。 负反馈循环 当模型根据生产中收集的数据自动训练时会出现更复杂的问题。如果该数据以任何方式受到影响/损坏那么随后基于该数据训练的模型将表现不佳。此处为 Twitter 的 Cortex AI 团队的 Dan Shiebler 描述这一挑战 我们需要非常小心我们部署的模型如何影响我们正在训练的数据一个已经试图向用户展示它认为他们会喜欢的内容的模型正在破坏反馈到分布正在发生变化的模型。 4. 监控机器学习系统的关键原则 虽然学术机器学习起源于 1980 年代的研究但机器学习系统在生产中的实际实施仍然相对较新。除了少数开创性的例外大多数科技公司在大规模开展 ML/AI 方面才几年而且许多公司才刚刚开始漫长的旅程。这意味着 这些挑战经常被误解或完全忽视框架和工具正在迅速变化对于数据科学和 MLOps最佳实践通常是灰色的监管要求一直在变化 没有什么比监控更真实的了这或许可以解释为什么它经常被忽视。 由具有大规模 ML 部署经验的公司撰写的详细介绍系统设计、流程、测试和监控最佳实践的研究论文非常有价值。画出共同的主题和问题可以为您和您的公司节省大量的鲜血、汗水和泪水。机器学习领域最有经验的两家公司谷歌和微软已经发表了这方面的论文以帮助其他面临类似挑战的人。这两篇论文是 The ML Test Score: A Rubric for ML Production Readiness and Technical Debt Reduction(2017) Breck 等人。谷歌机器学习软件工程案例研究(2019) Amershi 等人。微软 谷歌论文更多地关注机器学习系统测试和监控策略这些策略可用于在可靠性、减少技术债务和减轻长期维护负担方面改进此类系统。谷歌的论文围绕 28 个测试进行了结构化这是一个衡量给定机器学习系统对生产准备就绪程度的标准。这些测试“来自广泛的生产机器学习系统的经验”。 微软的论文采取了更广泛的视角着眼于将 AI 功能集成到软件中的最佳实践。该论文介绍了对微软约 500 名工程师、数据科学家和研究人员的调查结果这些工程师、数据科学家和研究人员参与了创建和部署 ML 系统并提供了对所识别挑战的见解。 这两篇论文都强调应用传统软件开发技术例如测试以及一般可操作 ML 系统阶段的流程和标准尚未完善。 论文中与监测相关的关键原则 监视器 1依赖项更改导致一个通知监视器 2数据不变量在训练和服务输入中保持不变即监控训练/服务偏斜 有效监控学习模型的内部行为的正确性可能很困难但输入数据应该更加透明。因此分析和比较数据集是检测世界正在以可能混淆 ML 系统的方式变化的问题的第一道防线。 监视器 3训练和服务特征计算相同的值监视器 4模型不太陈旧监视器 5模型在数值上是稳定的监视器 6该模型在训练速度、服务延迟、吞吐量或 RAM 使用率方面没有出现剧烈或缓慢的泄漏回归监视器 7模型在服务数据上的预测质量没有出现回归 也许最重要且实施最少的测试是用于训练/服务偏差的测试监视器 3。这种错误会导致大量团队的生产问题但它是最不常实施的测试之一。部分原因是因为这很困难。 尽管缺乏优先级但值得称赞的是谷歌论文明确呼吁采取行动特别是将其测试作为清单应用。我非常同意这一点任何熟悉 Atul Gawande 的清单宣言的人都同意。 值得注意的是这些最佳实践中的许多都依赖于可重复性。 5. 了解机器学习风险管理的范围 所有测试和监控最终归结为风险管理。这两种技术都是我们用来增加我们对系统功能是我们所期望的功能的信心的技术即使我们对系统进行了更改。有一系列风险管理。 一方面我们拥有没有测试和监控的系统。这是一个前景黯淡的系统甚至不太可能投产但也确实是一个非常容易调整的系统。 另一方面我们拥有经过最严格测试的系统具有所有可以想象的可用监控设置。在这个系统中我们对其行为有非常高的信心但是对系统进行更改是非常痛苦和耗时的。这样测试和监控就像战甲一样。太少了你很脆弱。太多了你几乎不能动。 还要注意测试和监控的价值随着变化而最明显。大多数机器学习系统一直在变化——业务增长、客户偏好发生变化以及新法律的颁布。 image.png 上图详细说明了您可以使用的所有生产前和生产后的风险缓解技术。 当我们谈论监控时我们关注的是生产后的技术。 我们的目标是确定与我们的预期相冲突的 ML 系统行为的变化。 从广义上讲我们可以将 ML 系统出错的方式分为两类 数据科学问题数据监控、预测监控运营问题系统监控 image.png 正如我们将在接下来的部分中看到的那样要获得有效的解决方案这两个领域需要结合在一起但是随着我们越来越熟悉首先单独考虑它们是有用的。 6.数据科学监控 当然我们对生产中运行的模型的准确性感兴趣。然而在许多情况下不可能立即知道模型的准确性。以欺诈检测模型为例只有在发生警方调查或进行其他检查例如与已知欺诈者交叉检查客户数据的情况下才能在新的实况案例中确认其预测准确性。类似的挑战也适用于我们无法获得即时反馈的许多其他领域例如疾病风险预测、信用风险预测、未来财产价值、长期股市预测。考虑到这些限制监控代理值以在生产中建模准确性是合乎逻辑的特别是 模型预测分布回归算法或频率分类算法模型输入分布数字特征或频率分类特征以及缺失值检查模型版本 模型输入监控 给定一组输入特征的预期值我们可以检查 a输入值是否在允许的集合对于分类输入或范围对于数字输入内 b集合内每个值的频率是否与我们过去看到的一致。 例如对于“婚姻状况”的模型输入我们将检查输入是否在图中所示的预期值范围内 image.png 根据我们的模型配置我们将允许某些输入特性为空或不为空。这是我们可以监控的。如果我们预期的特性通常不会是空的开始更改这可能表明数据倾斜或消费者行为的更改这两个都是进一步调查的原因。 模型预测监控 在自动化或手动流程中我们可以将模型预测分布与统计测试进行比较 基本统计数据中值、平均值、标准差、最大值/最小值 例如如果变量是正态分布的我们期望平均值在平均区间的标准误差范围内。当然这是一种非常简单的统计方法。 image.png 模型版本 这是一个经常被忽视的需要监控的基本领域——您希望确保能够在配置错误发生时轻松跟踪模型的哪个版本已经部署。 高级技术 我们还可以实施全面的统计测试来比较变量的分布。哪个测试这取决于变量特性。 如果变量是正态分布的我们可以进行t检验或方差分析 如果它们不是正态分布也许像Kruskall Wallis或Kolmogorov Smirnov这样的非参数检验更合适。 如果训练数据中的变量分布与生产中看到的变量类似我们希望逐个变量进行比较。 实际上在监测系统中实施高级统计测试可能很困难尽管理论上是可行的。更典型的是随着时间的推移自动化基本统计测试尤其是输入/输出的标准偏差并进行特别的手动测试以应用更高级的检查。我们现在将深入探讨自动化选项。 7.运营监控问题 软件工程领域的监控是一个成熟得多的领域也是站点可靠性工程的一部分。谷歌的SRE手册是一本很棒的免费参考书。我们ML系统的运营问题包括以下方面 系统性能延迟系统性能IO/内存/磁盘利用率系统可靠性正常运行时间可审计性尽管这也适用于我们的模型 在软件工程中当我们谈论监控时我们谈论的是事件。事件几乎可以是任何事情包括 接收HTTP请求发送HTTP 400响应输入函数可能包含或不包含ML代码到达if语句的else离开函数登录的用户将数据写入磁盘从网络读取数据从内核请求更多内存 所有事件都有上下文。例如HTTP请求将具有其发出和发送的IP地址、请求的URL、设置的cookie以及发出请求的用户。涉及函数的事件上面有函数的调用堆栈以及触发堆栈这一部分的任何内容例如HTTP请求。掌握所有事件的所有上下文对于调试和理解系统在技术和业务方面的表现都是很好的但处理和存储这些数据量并不实际。 因此监控被分解为不同的领域每个领域都与将数据量减少到可行的程度有关。 所谓的“可观察性三大支柱”描述了我们可以利用事件上下文并将上下文数据简化为有用数据的关键方法。他们是 MetricsLogs分布式跟踪 根据您询问的对象偶尔会有一些额外的成员例如 Profiling警报/可视化尽管这通常被纳入metrics/logs中 监控与可观察性对比 那么监控和可观察性之间有什么区别呢简单地说可观察性是指你通过观察系统外部来回答系统内部发生的任何问题的能力。要了解可观性的伟大历史我建议Cindy Sridharan撰写的这篇文章以及她的书分布式系统可观性 此时维恩图很有用 image.png 此图包含 测试-我们尽最大努力验证正确性监控-我们尽最大努力跟踪可预测的故障 可观察性是监控和测试的超集它提供了无法监控或测试的不可预测故障模式的信息。 监控和警报是相互关联的概念共同构成监控系统的基础。监控系统负责存储、聚合、可视化并在值满足特定要求时启动自动响应。 image.png 在监控ML系统时分布式跟踪的细节往往与非ML系统的设置非常相似。因此我不会在这里讨论它们。然而对于日志和metrics有一些值得注意的ML系统注意事项我现在将深入探讨。 8.将Ops和DS结合在一起-Prometheus和Grafana的指标 Metrics表示可以在整个系统中观察和收集的资源使用或行为的原始度量。这些可能是运营系统提供的低级使用概要也可能是与组件的特定功能或工作相关联的高级数据类型如每秒处理的请求或特定函数的输出。 Metrics的优点来自分布式系统可观察性Distributed Systems Observability中丰富的解释 与日志生成和存储不同metrics传输和存储的开销是恒定的。由于数字针对存储进行了优化因此指标可以延长数据保留时间并简化查询。这使得指标非常适合创建反映历史趋势的仪表盘可以每周/每月切片等。度量非常适合于统计转换例如采样、聚合、汇总和关联。度量也更适合触发警报因为对内存中的时间序列数据库运行查询要高效得多。 Metrics的缺点 Metrics允许您从整个流程收集有关事件的信息但通常不超过一个或两个上下文字段。基数问题集合元素的数量使用高基数值如ID作为metrics标签可能会淹没时间序列数据库。作用域为一个系统即一组微服务中只有一个服务 机器学习指标 鉴于上述利弊指标非常适合我们的ML系统的两个运营问题 调用ML API端点时的延迟执行预测时的内存/CPU使用率磁盘利用率如果适用 以及以基本统计指标为中心的预测监测 给定时间段内的中值和平均预测值最小/最大预测值给定时间段内的标准偏差 image.png 实际工具 Prometheus和Grafana的组合是监控指标最流行的开源堆栈之一。 为了避免这篇文章变成一本书我不会详细解释这些技术。了解更多信息的最佳场所是Brian Brazil的书籍和培训课程。文档中的快速摘要 Prometheus直接或通过中介推送网关从插入指令的作业中获取度量值用于短期作业。它将所有收集的样本存储在本地并对这些数据运行规则以便从现有数据中聚合和记录新的时间序列或生成警报。Grafana或其他API使用者可用于可视化收集的数据。 image.png 来源Prometheus文档 我们可以使用PrometheusGrafana创建仪表盘以跟踪我们的模型标准统计指标可能如下所示 image.png 您可以使用这些仪表板创建警报当模型预测超出特定时间段内的预期范围即异常检测时通过电子邮件/SMS通知您从而调整此处描述的ML方法。然后这将提示对常见疑似点进行全面调查例如 流水线中有bug吗我们部署了错误的模型吗数据集有问题吗模型过时了吗 9.将Ops和DS结合在一起-日志 事件日志通常称为“日志”是一个不可变的、带有时间戳的记录记录了一段时间内发生的离散事件。 日志的优点 日志很容易生成因为它只是一个字符串、一个JSON blob或类型化键值对。事件日志在提供有价值的洞察力和足够的上下文方面表现出色提供了平均值和百分位数无法显示的细节。虽然指标显示服务或应用程序的趋势但日志关注特定事件。日志的目的是保存关于特定事件的尽可能多的信息。日志中的信息可用于调查事件并帮助进行根本原因分析。 日志的缺点 日志记录过多会对系统性能产生负面影响由于这些性能问题日志上的聚合操作可能代价高昂因此应谨慎处理基于日志的警报。在处理方面原始日志几乎总是由Logstash、fluentd、Scribe或Heka等工具进行规范化、过滤和处理然后再保存到Elasticsearch或BigQuery等数据存储中。设置和维护此工具会带来巨大的运营成本。 机器学习日志 如果我们考虑监控ML的关键领域我们在前面看到了如何使用指标来监控预测输出即模型本身。然而通过指标调查数据输入值可能会导致高基数挑战因为许多模型都有多个输入包括分类值。虽然我们可以在一些关键输入上检测指标但如果我们想在没有高基数问题的情况下跟踪它们最好使用日志来跟踪输入。如果我们使用的是带有文本输入的NLP应用程序那么由于语言的基数非常高我们可能不得不更加依赖日志监视。 监视ml日志 我们将检查输入的危险信号例如 某个特征变得不可用要么从输入中消失要么大量NA关键输入值分布的显著变化例如在训练数据中相对罕见的分类值变得更加常见特定于模型的模式例如在NLP场景中训练数据中看不到的单词数量突然增加 实际工具 Kibana是一个开源分析和可视化平台它是弹性堆栈的一部分以前是ELK堆栈。您可以使用Kibana搜索、查看和交互存储在Elasticsearch索引中的日志。您可以轻松执行高级数据分析并在各种图表、表格中可视化日志。这是构建日志监控系统最常见的开源堆栈之一 监视ml日志 在Kibana中您可以设置仪表板来跟踪和显示ML模型输入值以及在值出现意外行为时自动发出警报。这样的仪表板可能看起来有点像 监视ml日志 这是日志记录系统的一种可能选择还有logz.io和Splunk等选项。 10. 不断变化的局势 希望本文能让您更清楚地了解机器学习监控的真正含义以及它的重要性。正如我希望的那样这是一个需要跨学科努力和规划才能有效的领域。有趣的是这些工具将如何发展以满足许多企业日益增长的挫败感这些企业经历了 ML 部署的高峰期但随后却没有能力监控该部署并因几个月后环境的变化而被烧毁。值得关注的有趣发展包括 大型 AI 玩家努力改进他们的机器学习模型解决方案监控例如微软在 Azure ML Studio 中引入了“数据漂移“。自然的这些都伴随着通常的供应商锁定和非内部构建的灵活性限制。零星创业公司试图构建创新工具以简化模型监控例如Seldon、Data Robot、MLFlow、superwise.ai 和 hydrosphere.io 等。MLOps 领域的开源倡议。我认为 KF Serving 可能会提供一些急需的标准化这可以简化构建监控解决方案的挑战。 到明年这个时候局势可能看起来会大不相同…… 原文链接Monitoring Machine Learning Models in Production