跳至主要内容

您的数据团队运作有多顺畅?了解您组织的 MLOps 成熟度水平

本文为数据团队介绍 MLOps 成熟度模型,供在提升机器学习能力时参考与采用。
Adel Nehme
Adel Nehme

创建您的免费账户

实践并学习路径你的进步。

使用 Google 继续继续即表示您接受我们的 使用条款,我们的 隐私政策 ,并且您的数据存储在美国。

MLOps(机器学习运维)是机器学习工作流中不可或缺的一环,正逐步发展为一门独立领域。它将机器学习与软件工程的最佳实践相结合,确保模型能够从实验走向生产,同时减少数据团队的技术债务。

要在大规模机器学习中取得成功,评估组织的 MLOps 成熟度至关重要。部署模型常常面临各种障碍,例如基础设施、组织文化,或在模型漂移时无法重训。这会导致机器学习带来的价值远低于预期(更糟的是,可能对与模型交互的相关方造成伤害)。进而,人们会对数据团队通过机器学习创造价值的能力产生不信任。要充分释放机器学习与人工智能的潜力,需要对 MLOps 进行深思熟虑的整体规划。

MLOps 还能让数据科学家专注于真正重要的工作:采集与清洗数据、开发模型、并使用合适的方法。这是因为 MLOps 能在机器学习生命周期的每个阶段显著提升自动化程度。

本文假设您已具备 MLOps 的基本知识并理解其重要性;如需了解更多,请参阅我们的文章 MLOps 入门 和 MLOps 最佳实践。

为什么要设定成熟度等级?

MLOps 不只是采用工具或改变工作方式。实施需要以整体视角使用工具与技术,打破技术团队内部壁垒并提升自动化。这可能意味着重组组织或调整人员,但每家公司的解决方案都会不同且独一无二。

从成熟度的角度审视 MLOps,即衡量公司在 MLOps 落地过程中的进展,有助于明确组织所处阶段、可采取的提升举措,以及成熟度提升将带来的收益。这也意味着 MLOps 成熟度可以随组织规模而扩展。模型数量较少的小公司无需达到与大型复杂组织相同的成熟度。然而,即便是规模不大的组织,只要其核心价值主张依赖机器学习,也需要相对成熟的 MLOps 实践。

还需注意,成熟度的提升并非线性推进。您的组织在某些 MLOps 方面可能已相当成熟,而在其他环节仍较薄弱。下文我们将概述 微软的 MLOps 成熟度模型,它从整体上展示了 MLOps 在组织内如何演进。

微软的 MLOps 成熟度模型

微软的 MLOps 成熟度模型从三个广义维度来评估 MLOps 成熟度:

  • 人员:数据团队中的不同角色及其相互协作方式
  • 机器学习生命周期:从数据收集到模型创建与发布,如何进行全流程管理。
  • 应用:如何测试、实施、部署及重训机器学习模型。

此外,微软的 MLOps 成熟度模型将 MLOps 实践划分为五个阶段:

  1. 无 MLOps:系统割裂、如同黑箱;数据团队彼此孤立;模型训练、部署与测试均为手工完成。
  2. 有 DevOps、无 MLOps:数据团队负责训练模型,另有团队负责部署。模型性能的反馈闭环不透明,可复现性有限。
  3. 自动化训练:模型可复现,发布流程更少手工操作。训练自动化,广泛使用流水线。
  4. 自动化部署:部署实现自动化,并可追溯到原始数据。模型部署后可做 A/B 测试,测试实现自动化。
  5. 完整 MLOps:从数据摄取到模型部署与测试全程自动化,并对模型性能进行集中化监控与分析。这类系统通常为定制化打造。

下面的部分将逐一介绍各成熟度阶段,并提供涵盖要点的汇总表。

无 MLOps

此阶段几乎没有自动化,数据团队既与更广泛的组织隔离,内部之间也相互隔离。工具采用度低,某些职能(如数据工程)可能不存在,或由数据科学家兼任。在这一成熟度下,即便部署单个模型也十分困难且耗时,重训模型需要完全重新运行分析与训练任务。部署后没有模型追踪,因此可能无法评估其影响。

人员

数据科学家

与更广泛的团队缺乏沟通,独立工作。

数据工程师

可能不存在。

软件工程师

从数据科学家处接收模型,与数据团队相互隔离。

机器学习生命周期

数据准备

尽管可能有数据库,训练数据仍以手工方式收集。

模型训练

实验未被追踪,未建立数据与机器学习流水线。

模型部署

模型通常以手工方式交付,附带输入与输出。没有版本控制,评分脚本手工创建,部署通常由数据科学家负责。

应用

集成

每次模型准备部署时均需全手工测试与发布,严重依赖数据科学家。

有 DevOps,但无 MLOps

随着引入 DevOps 最佳实践,数据团队依然是孤立的,但可能已配备专职数据工程师。云计算技术或已采用,但未充分发挥其潜力。此阶段会将数据库中数据的收集与机器学习准备工作,自动化到可复用的流水线中。模型部署时也可能进行集成测试。数据科学家身兼数职,并在模型部署后深度参与测试。

人员

数据科学家

与更广泛的团队缺乏沟通,独立工作。

数据工程师

与更广泛的团队缺乏沟通,独立工作。

软件工程师

从数据科学家处接收模型,与数据团队相互隔离。

机器学习生命周期

数据准备

已有自动化数据流水线,可能运行在托管云资源上。

模型训练

实验不可复现,且并非都能被稳定追踪。

模型部署

模型通常以手工方式交付,并附输入与输出。已有版本控制,但评分脚本仍为手工创建,部署通常由数据科学家或工程师处理。

应用

集成

发布已实现自动化,并配有基础集成测试,但仍高度依赖数据科学家的专业能力。

自动化训练

此阶段数据团队内的协作显著提升。数据科学家将与工程师合作,把模型训练代码转化为可复用脚本,并利用自动化数据流水线。实验将被追踪,版本控制更为普及。部署实现更高程度自动化,但模型文件仍需交由软件工程师。

人员

数据科学家

数据科学家与数据工程师合作,将实验代码转化为可复用脚本。

数据工程师

软件工程师

从数据科学家处接收模型,与数据团队相互隔离。

机器学习生命周期

数据准备

在托管云资源上运行的自动化数据流水线。

模型训练

实验被追踪,训练代码与模型均纳入版本控制。

模型部署

模型仍以手工方式部署,但评分脚本已纳入版本控制,发布现由软件工程团队管理。

应用

集成

发布已实现自动化,并配有基础集成测试,但仍高度依赖数据科学家的专业能力。

自动化模型部署

软件工程师如今与数据工程师更紧密合作,负责部署模型以及其训练与数据收集流水线。实验实现全量追踪,每次模型发布与应用本身均具备自动化的单元与集成测试。部分领域可能已引入 CI/CD。

人员

数据科学家

数据科学家与数据工程师合作,将实验代码转化为可复用脚本。

数据工程师

软件工程师

与数据工程师协作,将模型集成到应用中并实现自动化。

机器学习生命周期

数据准备

在托管云资源上运行的自动化数据流水线。

模型训练

实验被追踪,训练代码与模型均纳入版本控制。

模型部署

模型实现自动化部署,评分脚本纳入版本控制,发布由持续交付(CI/CD)流水线管理

应用

集成

应用代码中的集成对数据科学家的依赖更低,每次模型发布均具备单元与集成测试

完整 MLOps 下的自动化重训

在最终成熟阶段,数据工程师、数据科学家与软件工程师紧密协作,尽可能在开发与部署过程中实现自动化。此外,实验与模型训练/重训会基于生产指标实现自动化,模型自动发布并由 CI/CD 流水线管理,且模型会在应用代码中进行测试。

人员

数据科学家

数据科学家与数据工程师合作,将实验转化为可复用脚本,并与软件工程师协作实现流程自动化。


数据工程师与软件工程师协同,将模型自动集成进应用,并收集部署后的性能指标。

数据工程师

软件工程师

机器学习生命周期

数据准备

在托管云资源上运行的自动化数据流水线。

模型训练

实验被追踪,训练代码与模型纳入版本控制;基于性能指标,模型在部署后会自动重训。

模型部署

模型实现自动化部署,评分脚本纳入版本控制,发布由持续交付(CI/CD)流水线管理

应用

集成

应用代码中的集成对数据科学家的依赖更低,每次模型发布均具备单元与集成测试

主流 MLOps 模型的差异

该 MLOps 成熟度模型与谷歌模型的一个显著差异在于 CI/CD 概念的落位。谷歌认为这通常出现在最终成熟阶段,而微软认为重训才是最终阶段。

实际上,重训是推动采用 MLOps 的关键驱动因素之一,可能会在最终阶段之前就被引入。不过,实现模型重训存在前提条件,例如较强的自动化与基础设施,以及高质量的数据与模型训练流水线。CI/CD 的相关实践会在迈向 MLOps 成熟度的最后阶段持续改进。

谷歌与微软等高度成熟的组织,通常拥有运行在自家云计算环境上的定制软件,并将特定工具的效能发挥到极致。软件工程师常说,这些公司的技术“开箱即用”,模型部署流畅、数据访问高效。这是必需的,因为它们为广泛的产品线在生产中运行着数以百计的模型。

如何提升您的 MLOps 成熟度

MLOps 依然是数据科学中最关键的领域之一,许多组织在将模型投入生产方面仍面临挑战。MLOps 成熟度模型为数据团队提供了极佳的框架,帮助它们了解当前的机器学习能力所处位置,以及未来如何演进。

如需进一步学习 MLOps,请查看以下资源:



主题