你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站,请访问 https://docs.azure.cn

机器学习操作成熟度模型

Azure 机器学习

此成熟度模型的目的是帮助阐明机器学习操作 (MLOps) 原则和做法。 成熟度模型显示了生产级机器学习应用程序环境的创建和操作的持续改进。 可以将其用作建立衡量机器学习生产环境及其关联流程成熟度所需的渐进式要求的指标。

成熟度模型

MLOps 成熟度模型有助于阐明运行成功 MLOps 环境所需的开发操作 (DevOps) 原则和做法。 它旨在确定现有组织尝试实现此类环境时存在的差距。 这也是一种展示如何以增量增强 MLOps 功能的方法,而不是通过完全成熟环境的要求让你感觉不堪重负。 将其用作指南执行以下操作:

  • 估计新项目的工作范围。

  • 建立切合实际的成功标准。

  • 确定在项目结束时将交付的可交付结果。

与大多数成熟度模型一样,MLOps 成熟度模型定性地评估人员/文化、流程/结构和对象/技术。 随着成熟度提高,事件或错误将导致开发和生产流程质量提高的概率增加。

MLOps 成熟度模型包含五个技术能力级别:

Level 说明 亮点 技术
0 无 MLOps
  • 难以管理完整的机器学习模型生命周期
  • 团队不同,发布非常棘手
  • 大多数系统都以“黑盒”的形式存在,在部署期间/部署后几乎没有反馈
  • 手动生成和部署
  • 手动测试模型和应用程序
  • 没有对模型性能进行集中跟踪
  • 模型训练是手动的
1 DevOps,但无 MLOps
  • 相比无 MLOps,发布没有那么棘手,但每个新模型都依赖于数据团队
  • 关于模型在生产中表现如何的反馈仍然有限
  • 难以跟踪/重现结果
  • 自动化生成
  • 自动化测试应用程序代码
2 自动化训练
  • 训练环境完全托管且可跟踪
  • 易于重现模型
  • 发布是手动的,但摩擦较低
  • 自动化模型训练
  • 集中跟踪模型训练性能
  • 模型管理
3 自动化模型部署
  • 发布摩擦较低且是自动的
  • 从部署回到原始数据的完整可跟踪性
  • 整个环境托管:训练 > 测试 > 生产
  • 用于部署的模型性能的集成 A/B 测试
  • 所有代码的自动化测试
  • 集中跟踪模型训练性能
4 完整的 MLOps 自动化操作
  • 全系统自动化且易于监视
  • 生产系统提供了有关如何改进的信息,以及在某些情况下如何使用新模型自动改进的信息
  • 接近零停机时间系统
  • 自动化模型训练和测试
  • 已部署模型的详细集中式指标

下面的表标识了该进程成熟度级别的详细特征。 该模型将继续改进。 此版本上次更新时间为 2020 年 1 月。

级别 0:无 MLOps

人员 模型创建 模型发布 应用程序集成
  • 数据科学家:孤立,没有与更大的团队进行定期通信
  • 数据工程师(如果存在):孤立,没有与更大的团队进行定期通信
  • 软件工程师:孤立,从其他团队成员远程接收模型
  • 手动收集的数据
  • 计算可能未托管
  • 无法以可预见的方式跟踪试验
  • 最终结果可能是使用输入/输出手动移交的单个模型文件
  • 手动过程
  • 评分脚本可以在试验后手动创建,不受版本控制
  • 由数据科学家或数据工程师单独处理的发布
  • 严重依赖数据科学家的专业知识来实现
  • 每次手动发布

级别 1:DevOps,无 MLOps

人员 模型创建 模型发布 应用程序集成
  • 数据科学家:孤立,没有与更大的团队进行定期通信
  • 数据工程师(如果存在):孤立,没有与更大的团队进行定期通信
  • 软件工程师:孤立,从其他团队成员远程接收模型
  • 数据管道自动收集数据
  • 计算是否托管
  • 无法以可预见的方式跟踪试验
  • 最终结果可能是使用输入/输出手动移交的单个模型文件
  • 手动过程
  • 评分脚本可以在试验后手动创建,可能受版本控制
  • 移交给软件工程师
  • 模型存在基本集成测试
  • 严重依赖数据科学家的专业知识来实现模型
  • 自动发布
  • 应用程序代码具有单元测试

级别 2:自动化训练

人员 模型创建 模型发布 应用程序集成
  • 数据科学家:直接与数据工程师合作,将试验代码转换为可重复的脚本/作业
  • 数据工程师:与数据科学家合作
  • 软件工程师:孤立,从其他团队成员远程接收模型
  • 数据管道自动收集数据
  • 托管的计算
  • 跟踪的试验结果
  • 训练代码和生成的模型均受版本控制
  • 手动发布
  • 评分脚本通过测试受版本控制
  • 软件工程团队管理的发布
  • 模型存在基本集成测试
  • 严重依赖数据科学家的专业知识来实现模型
  • 应用程序代码具有单元测试

级别 3:自动化模型部署

人员 模型创建 模型发布 应用程序集成
  • 数据科学家:直接与数据工程师合作,将试验代码转换为可重复的脚本/作业
  • 数据工程师:与数据科学家和软件工程师合作来管理输入/输出
  • 软件工程师:与数据工程师合作,自动化模型与应用程序代码的集成
  • 数据管道自动收集数据
  • 托管的计算
  • 跟踪的试验结果
  • 训练代码和生成的模型均受版本控制
  • 自动发布
  • 评分脚本通过测试受版本控制
  • 由持续交付 (CI/CD) 管道管理的发布
  • 每个模型版本的单元和集成测试
  • 较少依赖数据科学家的专业知识来实现模型
  • 应用程序代码具有单元/集成测试

级别 4:完整 MLOps 自动化重新训练

人员 模型创建 模型发布 应用程序集成
  • 数据科学家:直接与数据工程师合作,将试验代码转换为可重复的脚本/作业。 与软件工程师合作,为数据工程师识别标记
  • 数据工程师:与数据科学家和软件工程师合作来管理输入/输出
  • 软件工程师:与数据工程师合作,自动化模型与应用程序代码的集成。 实现部署后指标收集
  • 数据管道自动收集数据
  • 根据生产指标自动触发重新训练
  • 托管的计算
  • 跟踪的试验结果
  • 训练代码和生成的模型均受版本控制
  • 自动发布
  • 评分脚本通过测试受版本控制
  • 由持续集成和 CI/CD 管道管理的发布
  • 每个模型版本的单元和集成测试
  • 较少依赖数据科学家的专业知识来实现模型
  • 应用程序代码具有单元/集成测试

后续步骤