Press "Enter" to skip to content

构建更好的机器学习系统 —— 第4章 模型部署与发展

关于部署、监控、数据分发漂移、模型更新和生产中的测试。

图片来源

部署模型并在生产环境中支持它们更多地是与工程相关,而非与机器学习相关。

当一个机器学习项目接近生产阶段时,越来越多的人参与其中:后端工程师,前端工程师,数据工程师,DevOps,基础设施工程师…

他们选择数据存储方式,引入工作流程和流水线,将服务集成到后端和UI代码库中,自动化发布,制作备份和回滚,决定计算实例,设置监控和警报… 现在,几乎没有人期望数据科学家或机器学习工程师能够一手包办。即使在小型创业公司中,人们也会在某种程度上专门从事一些工作。

你可能会问:“为什么数据科学家或机器学习工程师要了解生产环境?”

这是我的回答:

将模型投入生产并不意味着我们完成了所有与机器学习相关的任务。哈!离完成还差得远呢。现在我们要面对一系列全新的挑战:如何在生产环境中评估模型并监控其准确性是否仍然令人满意,如何检测数据分布的变化并处理它们,多久重新训练模型以及如何确保新训练的模型更好。有办法解决这些问题,并且我们将对其进行广泛讨论。

在本文中,我有意只关注机器学习相关的话题,并省略了许多工程概念,或只是以高层次的方式涉及它们,以保持简单易懂,适合具有不同经验水平的读者。

这是“构建更好的机器学习系统”系列的最后一篇文章。该系列旨在帮助您掌握设计和构建机器学习系统的艺术、科学和(有时)魔力。在之前的章节中,我们已经讨论了项目规划和业务价值(第1章);数据收集、标记和验证(第2章);模型开发、实验跟踪和离线评估…(第3章)。如果你错过了之前的文章,我建议在阅读本文之前或之后阅读它们。

部署

在将模型部署到生产环境时,有两个重要问题需要问:

  1. 模型是否需要实时返回预测结果?
  2. 模型是否可以部署到云端?

第一个问题迫使我们在实时推断和批量推断之间做出选择,而第二个问题则涉及云端计算和边缘计算之间的选择。

实时推断 vs. 批量推断

实时推断是一种直观简单的使用模型的方式:输入数据,然后得到预测结果。这种方法适用于需要立即进行预测的情况。例如,银行可能会在最终确认交易之前使用实时推断来验证交易是否存在欺诈行为。

批量推断则更便宜且更易于实现。之前收集到的输入数据会一次性处理。批量推断用于评估(在静态测试数据集上运行时)、特定条件的活动(例如选择邮件营销活动的客户)或在不需要立即预测的情况下使用。批量推断还可以作为实时推断的成本或速度优化:您可以预先计算预测结果并在请求时返回。

实时推断 vs. 批量推断。图片作者

运行实时推断比批量推断更具挑战性和成本。这是因为模型必须始终保持运行且以低延迟返回预测结果。这需要 clever 的基础设施和监控设置,甚至对于同一公司的不同项目来说都可能是独一无二的。因此,如果对于业务来说立即得到预测结果并不关键,请坚持使用批量推断,并且找到快乐。

然而,对于许多公司来说,实时推断确实在准确性和收入方面产生了差异。这对于搜索引擎、推荐系统和广告点击预测都是如此,因此在实时推断基础设施上投资是完全合理的。

有关实时与批处理推断的更多详细信息,请查看以下文章:在生产环境中部署机器学习模型 (Microsoft)- 批处理推断 vs 在线推断 (Luigi Patruno)

云计算 vs 边缘计算

在云计算中,数据通常在互联网上传输并在集中服务器上进行处理。另一方面,在边缘计算中,数据在生成它的设备上进行处理,每个设备以分散的方式处理自己的数据。边缘设备的例子包括手机、笔记本电脑和汽车。

云计算 vs 边缘计算。作者提供的图片

像Netflix和YouTube这样的流媒体服务通常在云中运行其推荐系统。他们的应用程序和网站将用户数据发送到数据服务器以获取推荐。云计算相对容易设置,并且可以几乎无限地扩展计算资源(或者至少在经济上合理的范围内)。然而,云基础设施严重依赖稳定的互联网连接,敏感的用户数据不应通过互联网传输。

边缘计算的发展是为了克服云的限制,能够在云计算无法运行的地方工作。自驾驶引擎运行在汽车上,因此即使没有稳定的互联网连接,它仍然可以快速运行。智能手机的认证系统(如iPhone的FaceID)在智能手机上运行,因为通过互联网传输敏感的用户数据不是一个好主意,并且用户确实需要在没有互联网连接的情况下解锁手机。然而,为了使边缘计算可行,边缘设备需要足够强大,或者模型必须轻量且快速。这催生了模型压缩方法,例如低秩逼近、知识蒸馏、修剪和量化。如果想了解更多关于模型压缩的内容,可以从这个很棒的Awesome ML Model Compression项目开始。

要深入了解边缘计算和云计算,请阅读以下文章:边缘计算和云计算之间的区别是什么?(NVIDIA)- 边缘计算 vs 云计算:主要区别(Mounika Narang)

简单部署和演示

“生产是一个光谱。对于一些团队来说,生产意味着从笔记本结果生成好看的图表以向业务团队展示。对于其他团队来说,生产意味着为每天数百万用户保持模型正常运行。” Chip Huyen,为什么数据科学家不需要了解Kubernetes

将模型部署用于为数百万用户提供服务是一个大型团队的任务,因此作为数据科学家/机器学习工程师,您不会被单独留下来。

然而,有时候您确实需要单独进行部署。也许您正在进行宠物项目或学习项目,并希望创建一个演示。也许您是公司里的第一位数据科学家/机器学习工程师,需要在公司决定扩大数据科学团队之前带来一些业务价值。也许您的同事们都在忙于自己的任务,所以您在思考是否更容易自己部署而不是等待支持。您不是第一个也不会是最后一个遇到这些挑战的人,有解决方案可以帮助您。

要部署一个模型,您需要一个服务器(实例),在该服务器上运行模型,一个用于与模型通信的API(发送输入,获取预测),以及(可选)一个接受用户输入并显示预测的用户界面。

Google Colab是强化版的Jupyter Notebook。它是一个创建可以共享的演示的强大工具。用户不需要进行任何特殊安装,它提供了免费的带有GPU的服务器来运行代码,您可以轻松自定义它以接受用户的任何输入(文本文件、图像、视频)。它在学生和机器学习研究员中非常受欢迎(这里是DeepMind研究员如何使用它)。如果您对Google Colab想了解更多,请从这里开始。

FastAPI 是一个用于在 Python 中构建 API 的框架。你可能听说过 Flask,FastAPI 类似,但更简单、更专注于 API,并且更快。更多细节请参阅 官方文档。有关实际示例,请阅读 Goku Mohandas 的 APIs for Model Serving

Streamlit 是一个创建 Web 应用程序的易用工具。非常简单,我是真的。应用程序的效果也很好,具有图片、绘图、输入窗口、按钮、滑块等交互功能。Streamlit 提供 Community Cloud,您可以免费发布应用程序。要开始,请参考 官方教程

云平台。谷歌和亚马逊在使部署过程变得轻松和可访问方面做得很好。他们提供有偿的端到端解决方案来训练和部署模型(存储、计算实例、API、监控工具、工作流等)。这些解决方案易于入门,还具有广泛的功能来支持特定需求,因此许多公司都使用云提供商构建其生产基础设施。

如果您想了解更多信息,请查看以下资源:
– Alex Olivier 的 Deploy your side-projects at scale for basically nothing
– 亚马逊的 Deploy models for inference
– 谷歌的 Deploy a model to an endpoint

监控

与所有生产中的软件系统一样,机器学习系统也需要进行监控。这有助于快速检测和定位错误,并防止系统发生灾难性故障。

从技术上讲,监控意味着收集日志,从中计算指标,将这些指标显示在像 Grafana 这样的仪表板上,并设置当指标超出预期范围时的警报。

应该监控哪些指标?由于机器学习系统是软件系统的子类,因此从操作指标开始。例子包括机器的 CPU/GPU 利用率、内存和磁盘空间;发送给应用程序的请求数量和响应延迟、错误率;网络连接。要深入了解操作指标的监控,请查看 Justin Ellingwood 的文章 An Introduction to Metrics, Monitoring, and Alerting

而操作指标与机器、网络和应用程序的健康状况有关,与机器学习相关的指标则检查模型的准确性和输入的一致性。

准确性是我们最关心的最重要的事情。这意味着模型可能仍然返回预测结果,但这些预测结果可能完全错误,你直到评估模型才会意识到。如果您有幸在一个能够快速获得自然标签的领域工作(比如推荐系统),只需在标签可用时收集这些标签,评估模型,并持续进行。然而,在许多领域中,标签可能需要很长时间才能到达,或者根本不会到达。在这种情况下,监控某些可能间接指示准确性下降的东西是有益的。

为什么模型的准确性可能会下降?最普遍的原因是生产数据与训练/测试数据发生了偏移。在计算机视觉领域,你可以直观地看到数据发生了变化:图像变暗、变亮,分辨率发生变化,或者室内图像比室外图像多了。

为了自动检测数据漂移(也称为“数据分布偏移”),持续监控模型的输入和输出。模型的输入应与训练期间使用的输入保持一致;对于表格数据来说,这意味着列名以及特征的均值和方差必须相同。监控模型预测的分布也是有价值的。例如,在分类任务中,可以跟踪每个类别的预测比例。如果发生明显变化(例如以前将 5% 的实例分类为 A 类,现在将 20% 的实例分类为 A 类),这表明肯定发生了某些变化。要了解有关数据漂移的更多信息,请查阅 Chip Huyen 的精彩文章:Data Distribution Shifts and Monitoring

关于监控还有很多要说的,但我们必须继续前进。如果你需要更多信息,可以查看以下帖子:监控机器学习系统 by Goku Mohandas- 生产环境中如何监控你的模型的全面指南 by Stephen Oladele

模型更新

如果将模型部署到生产环境并不做任何改动,其准确率会随时间降低。在大多数情况下,这是由于数据分布的变化所解释的。输入数据可能会改变格式。用户行为持续变化而没有任何有效理由。流行病、危机和战争可能突然发生并打破以前有效的所有规则和假设。“变化是唯一不变的。”- 赫拉克利特斯。

这就是为什么生产模型必须定期更新。更新的类型有两种:模型更新和数据更新。模型更新是指更改算法或训练策略。模型更新不需要定期进行,通常是在业务任务变化、发现错误或团队有时间进行研究时进行。相比之下,数据更新是指使用更新的数据对相同的算法进行训练。对任何机器学习系统来说,定期进行数据更新是必须的。

定期进行数据更新的前提是建立一个可以支持自动数据流、模型训练、评估和部署的基础设施。

需要强调的是,数据更新应该尽可能少或不需要人工干预。人工工作应主要用于数据注释(同时确保数据流到注释团队和从注释团队的过程是完全自动化的)、可能需要做出最终部署决策以及解决训练和部署阶段可能出现的任何错误。

一旦基础设施建立好了,更新的频率只是需要在配置文件中进行调整的一个数值。模型应该以多频繁的数据进行更新?答案是:尽可能频繁和经济上可行的频繁。如果增加更新频率带来的价值超过了成本,那肯定要增加频率。然而,在某些情况下,即使增加频率会带来高额利润,每小时进行训练可能也是不可行的。例如,如果模型依赖于人工注释,这个过程可能成为瓶颈。

从头开始训练还是仅在新数据上微调?这不是一个二元决策,而是两者的结合。频繁进行模型微调是明智的,因为它比从头开始训练更具成本效益且更快速。然而,偶尔从头开始训练也是必要的。需要明白的是,微调主要是对成本和时间的优化。通常,公司会从最简单的方法开始,即最初从头开始训练,然后逐渐将微调纳入项目的扩展和发展过程中。

想了解更多关于模型更新的内容,请阅读这篇文章:重新训练还是不重新训练?让我们通过机器学习模型更新进行分析 by Emeli Dral 等。

在生产环境中进行测试

在将模型部署到生产环境之前,必须进行彻底的评估。我们已经在之前的文章中讨论了预生产(离线)评估(请查看“模型评估”部分)。然而,在部署模型之前,你无法知道它在生产环境中的表现如何。这催生了在生产环境中进行测试,也被称为在线评估。

在生产环境中进行测试并不意味着鲁莽地将可靠的旧模型替换为新训练的模型,然后焦急地等待第一个预测结果,随时准备在出现最小问题时回滚。千万不要这样做。有更聪明和更安全的策略可以在生产环境中测试你的模型,而不会冒着损失金钱或客户的风险。

A/B 测试是行业中最流行的方法。使用这种方法,流量会以一定比例随机分配给现有模型和新模型。现有模型和新模型为真实用户进行预测,预测结果被保存并稍后进行仔细检查。比较模型准确率之外,还比较一些与业务相关的指标,如转化率或收入,有时可能与准确率呈负相关。

A/B 测试高度依赖于统计假设检验。如果你想了解更多相关内容,请阅读这篇文章:A/B 测试:统计检验的完整指南 by Francesco Casalegno。有关 A/B 测试的工程实现,请查看Online AB test pattern

影子部署是测试模型最安全的方式。其思想是将所有的流量都发送到现有模型,并以通常的方式将其预测返回给终端用户,同时也将所有的流量发送到一个新的(影子)模型。影子模型的预测不在任何地方使用,只是存储以供将来分析。

A/B测试与影子部署。图片由作者提供

金丝雀发布。您可以将其视为“动态”A/B测试。新模型与现有模型并行部署。起初,只有很小的流量发送到新模型,例如1%,其他99%仍由现有模型提供。如果新模型的性能足够好,它所占的流量将逐渐增加并再次评估,然后再增加并再次评估,直到所有的流量都由新模型提供。如果在某个阶段,新模型的表现不佳,它将被从生产环境中删除,并且所有流量都将重新定向到现有模型。

这是一篇更详细解释的文章:影子部署与金丝雀发布的机器学习模型,作者是Bartosz Mikulski。

结论

在本章中,我们学习了一整套新的挑战,这些挑战在模型部署到生产环境后出现。必须持续监控模型的运营和与机器学习相关的指标,以便迅速检测并修复错误。模型必须定期在新数据上重新训练,因为其准确性随时间而降低,主要是由于数据分布的变化。我们讨论了在部署模型之前要做出的高层次决策——实时与批量推理,云计算与边缘计算,每个决策都有其优势和局限性。我们介绍了一些简化部署和演示的工具,以及在极少数情况下必须单独完成部署的情况。我们了解到除了离线数据集上的离线评估之外,模型还必须在生产环境中进行评估。直到实际发布它,你永远不知道模型在生产环境中的工作情况。这个问题引发了“安全”和受控的生产测试——A/B测试、影子部署和金丝雀发布。

这也是“构建更好的机器学习系统”系列的最后一章。如果您从一开始就一直和我在一起,你现在知道一个机器学习系统远不止是一个花哨的算法。我真诚地希望这个系列对您有所帮助,拓宽了您的视野,并教会您如何构建更好的机器学习系统。

感谢您的阅读!

如果您错过了前几章,这里是完整的列表:

构建更好的机器学习系统。第1章:每个项目必须从计划开始。

关于机器学习项目的生命周期、设计文档、商业价值和要求。关于从小开始和快速失败。

towardsdatascience.com

构建更好的机器学习系统。第2章:驯服数据混乱。

关于以数据为中心的人工智能、训练数据、数据标注和清理、合成数据,以及一点数据工程知识…

towardsdatascience.com

构建更好的机器学习系统 —— 第3章:建模。让乐趣开始

关于基准、实验追踪、适当的测试集和指标。关于让算法正常工作。

towardsdatascience.com

Leave a Reply

Your email address will not be published. Required fields are marked *