如今,过多的机器学习模型没有部署到生产环境中,而是停留在数据实验室。与任何新兴领域一样,现代数据团队需要采纳的一整套最佳实践、工具、技术和角色分工尚未成熟与标准化。这让希望大规模从机器学习中获取价值的企业感到困扰,也让希望走出笔记本实验阶段的数据科学家倍感挫折。MLOps (Machine Learning Operations,机器学习运维)在过去几年中应运而生,旨在解决数据团队在部署方面面临的挑战。
顾名思义:正如 DevOps 围绕业务需求塑造了敏捷应用的快速开发,MLOps 也致力于通过弥合复杂性与机器学习模型部署之间的鸿沟,实现同样的目标。
MLOps 究竟如何应对这些挑战?本文旨在厘清这一新兴学科中的一些概念,并回答以下关键问题:
- 什么是 MLOps,以及成功的 MLOps 实践包含哪些关键组成部分?
- MLOps 与 DevOps 有何不同?
- MLOps 如何重塑机器学习工作流?
- 您今天如何开始实践 MLOps?
什么是 MLOps?
WhyLabs(专注于模型监控的 MLOps 初创公司)CEO Alessya Visnjic对 MLOps 有精准的描述,称其为 “一套确保机器学习系统可靠、可扩展部署的工具、实践、技术、文化与思维模式”。
从这个定义出发,MLOps 构建在既有的 DevOps 学科之上——DevOps 是高效编写、部署和运行企业应用的现代实践。它是一种跨职能、协作、迭代的过程,让数据科学走向工程化。MLOps 将机器学习视为一门工程学科,将模型视作可复用的软件制品,并通过可重复的流程进行部署。
MLOps 还包括对生产环境中的模型进行持续监控与再训练,以确保其在数据随时间变化的情况下依然表现最佳,这种现象也被称为数据漂移。
简而言之,MLOps 让数据团队通过以下方式扩大其价值创造规模:
- 借助自动化流程,更快地部署更多模型
- 通过协作与模型复用提升生产力
- 降低那些无法进入生产的模型所带来的风险与成本
- 在发生数据漂移时持续监控并更新模型
回到 Visnjic 对 MLOps 的定义,实现上述目标既需要为现代数据团队带来工具层面的创新,也需要许多数据科学家转变思维方式。
为什么 MLOps 很重要?
我们已经讨论了 MLOps 如何致力于解决当今众多数据团队的部署难题。那么,机器学习到底有哪些独特之处,以至于需要像 MLOps 这样全新的专业化运维职能?
机器学习应用与传统软件有本质区别。以下是组织在将机器学习系统部署到生产环境时面临的一些重大挑战。
- 所有权与协作: 传统上,数据科学家倾向于创建和开发机器学习模型,而 IT 团队负责部署与运维。然而,这两个团队之间的协作往往不够高效,容易产生摩擦。比如,数据科学团队越来越多地被业务各方征用去解决不断增长的问题。鉴于现代 IT 系统的复杂性,数据科学家通常很少关注现有的生产环境与 IT 系统——因为那是 IT 团队的职责。同样,IT 团队也往往不关注数据科学家所产出方案的内部机理——这导致许多模型在可部署性上的预期落空。这种动态会带来摩擦,并形成必须不惜一切代价避免的反模式——数据团队满足于“把模型造出来,交给 IT,后面他们接手”的思路。
- 数据是机器学习驱动软件的决定性要素: 数据是机器学习系统的生命线。不同于传统软件由工程师设计良好的流程来处理一组输入并给出一组输出,机器学习系统依赖统计方法,以混乱的现实世界数据为输入,输出预测结果。这意味着机器学习系统的行为会随数据变化而改变。此外,这也意味着评估机器学习模型的性能需要观察与分析。最后,这意味着机器学习工作流本就杂乱、富有实验性,天然需要与传统软件工程不同的技能组合。
- 部署复杂性: 机器学习模型系统的复杂性不断增加。与传统软件不同,部署机器学习模型需要编排来自不同工具的一系列互相关联步骤,包括数据采集、存储、转换、特征工程等。此外,可重现性与版本控制对数据团队来说也是重大挑战。鉴于机器学习的实验属性,数据科学团队会用同一数据集的不同版本构建出多个模型版本。因此,传统的版本控制需要更为健壮。
MLOps 与 DevOps——有何区别?
上一节我们分解了为什么机器学习需要专业化的运维职能。那么,MLOps 在实践中与 DevOps 有哪些不同之处?
DevOps 是 Development(开发)与 Operations(运维)的合称。它将 IT 部门的两个关键职能——应用开发与系统工程——结合起来。DevOps 致力于缩短开发周期,加速软件工程团队的产出速度。其方法是在开发团队中引入自动化、更新流程与工作方式。更广义地说,DevOps 将两大原则带入软件开发流程:
- 持续集成(CI)——对版本库进行频繁的小步迭代。借助频繁发布到生产来缓解部署问题。
- 持续交付(CD)——将应用和软件交付到生产环境所需步骤实现自动化的过程。
鉴于机器学习的独特性,以下是 MLOps 与 DevOps 在实践中的一些差异:
- 持续集成从仅测试与验证代码,扩展为同时测试与验证模型和数据
- 持续交付从仅自动化将应用交付到生产,扩展为自动交付触发机器学习预测的数据管道
- 持续训练被引入——这对机器学习而言独一无二——即模型会被自动再训练以便部署
- 持续监控被引入——用于监测生产数据的质量断裂、模型性能,以及与机器学习模型相关的业务指标
MLOps 工作流
为 MLOps 重新想象数据科学工作流
鉴于将机器学习模型部署到生产的额外复杂性——数据团队如何开始在数据科学工作流中采纳 MLOps?本节介绍一个简化的 MLOps 分步流程:
- 构建(Building):模型创建完成后,通常会放入受版本控制、可审计的代码库中,以支持在企业范围内复用。
- 评估(Evaluation):在此阶段,通过在全新且独立的数据集上衡量新训练模型的性能,量化其预测质量。
- 生产化(Productionizing):将模型或流水线导出、部署并集成到生产系统与应用中。
- 测试(Testing):对基于 ML 的应用而言,持续测试十分重要,关注于自动再训练与服务模型。
- 部署(Deployment):需要持续监控以确保最佳性能。随着数据变化,可对模型进行再训练或以新模型替换。
- 监控与可观测性(Monitoring and observability):许多公司在将机器学习模型迁入生产环境时都会面临挑战。
为 MLOps 重新定义数据角色
在较小的数据科学团队中,一人可能身兼数职。而在更大、更流程化的数据团队里,不同角色与技能会分别负责 MLOps 工作流的各个环节。常见角色包括:
- 数据科学家: 通常被视为任何 MLOps 团队的关键角色。数据科学家是利用公司数据创造价值的专家。他们的职责是理解、构建并解释数据,通过预测模型将洞见带给业务。他们创建、测试并评估机器学习模型。在一些公司中,他们还会在模型进入生产后负责部署与性能监控。
- 数据工程师: 数据工程师负责创建与维护支撑数据团队其他职能运行的环境。他们负责开发、构建、维护与测试诸如数据库与处理系统等架构。通俗来说,他们实现数据从抽取、到转换、再到交付的流动。
- 软件工程师: 在 MLOps 流程中,软件工程师负责将机器学习模型集成到公司的应用与系统中。他们还需确保机器学习模型与公司内的非机器学习应用能够顺畅协同工作。
- 机器学习工程师: 机器学习工程师处于数据科学与数据工程的交汇点。其职责是在数据工程师准备的基础设施上,对数据科学家开发的模型进行优化并将其投入生产。
开始实践 MLOps
正如本文所述,MLOps 仍是一个新兴领域,许多工具、最佳实践与方法论仍在不断涌现。以下将介绍您开始实践 MLOps 的多种路径、可供试验的工具,以及可立即学习的资源。
可考虑的 MLOps 工具
-
Data Version Control (DVC):DVC(Data Version Control)是一个 Python 包,可让您的数据科学项目管理更为轻松。正如其主要贡献者 Dmitry Petrov 在一次演讲中所述,该工具是面向机器学习的 Git 扩展。DVC 与 Git 既相似又互补。
-
Pachyderm:Pachyderm 是一款类似 DVC 的机器学习与数据科学版本控制工具。更进一步,它基于 Docker 和 Kubernetes,从而有助于在任意云平台上运行与部署机器学习项目。此外,Pachyderm 确保导入机器学习模型的所有数据均具备版本与可追溯性。
学习资源:走进 MLOps
机器学习基础
数据工程基础
深入 MLOps
我们希望这套资源能助您开启 MLOps 的学习之旅。关于 MLOps 的更多文章与资源,您还可以查看以下内容:
如今,过多的机器学习模型没有部署到生产环境中,而是停留在数据实验室。与任何新兴领域一样,现代数据团队需要采纳的一整套最佳实践、工具、技术和角色分工尚未成熟与标准化。这让希望大规模从机器学习中获取价值的企业感到困扰,也让希望走出笔记本实验阶段的数据科学家倍感挫折。MLOps (Machine Learning Operations,机器学习运维)在过去几年中应运而生,旨在解决数据团队在部署方面面临的挑战。
顾名思义:正如 DevOps 围绕业务需求塑造了敏捷应用的快速开发,MLOps 也致力于通过弥合复杂性与机器学习模型部署之间的鸿沟,实现同样的目标。
MLOps 究竟如何应对这些挑战?本文旨在厘清这一新兴学科中的一些概念,并回答以下关键问题:
什么是 MLOps?
WhyLabs(专注于模型监控的 MLOps 初创公司)CEO Alessya Visnjic对 MLOps 有精准的描述,称其为 “一套确保机器学习系统可靠、可扩展部署的工具、实践、技术、文化与思维模式”。
从这个定义出发,MLOps 构建在既有的 DevOps 学科之上——DevOps 是高效编写、部署和运行企业应用的现代实践。它是一种跨职能、协作、迭代的过程,让数据科学走向工程化。MLOps 将机器学习视为一门工程学科,将模型视作可复用的软件制品,并通过可重复的流程进行部署。
MLOps 还包括对生产环境中的模型进行持续监控与再训练,以确保其在数据随时间变化的情况下依然表现最佳,这种现象也被称为数据漂移。
简而言之,MLOps 让数据团队通过以下方式扩大其价值创造规模:
回到 Visnjic 对 MLOps 的定义,实现上述目标既需要为现代数据团队带来工具层面的创新,也需要许多数据科学家转变思维方式。
为什么 MLOps 很重要?
我们已经讨论了 MLOps 如何致力于解决当今众多数据团队的部署难题。那么,机器学习到底有哪些独特之处,以至于需要像 MLOps 这样全新的专业化运维职能?
机器学习应用与传统软件有本质区别。以下是组织在将机器学习系统部署到生产环境时面临的一些重大挑战。
MLOps 与 DevOps——有何区别?
上一节我们分解了为什么机器学习需要专业化的运维职能。那么,MLOps 在实践中与 DevOps 有哪些不同之处?
DevOps 是 Development(开发)与 Operations(运维)的合称。它将 IT 部门的两个关键职能——应用开发与系统工程——结合起来。DevOps 致力于缩短开发周期,加速软件工程团队的产出速度。其方法是在开发团队中引入自动化、更新流程与工作方式。更广义地说,DevOps 将两大原则带入软件开发流程:
鉴于机器学习的独特性,以下是 MLOps 与 DevOps 在实践中的一些差异:
MLOps 工作流
为 MLOps 重新想象数据科学工作流
鉴于将机器学习模型部署到生产的额外复杂性——数据团队如何开始在数据科学工作流中采纳 MLOps?本节介绍一个简化的 MLOps 分步流程:
为 MLOps 重新定义数据角色
在较小的数据科学团队中,一人可能身兼数职。而在更大、更流程化的数据团队里,不同角色与技能会分别负责 MLOps 工作流的各个环节。常见角色包括:
开始实践 MLOps
正如本文所述,MLOps 仍是一个新兴领域,许多工具、最佳实践与方法论仍在不断涌现。以下将介绍您开始实践 MLOps 的多种路径、可供试验的工具,以及可立即学习的资源。
可考虑的 MLOps 工具
Kubeflow:Kubeflow 是一套在 Kubernetes 集群上运行机器学习工作流的工具。其目标是在简洁、可移植、可扩展的方式下,让最优秀的开源机器学习解决方案运行在 Kubernetes 集群上。Kubeflow 最初是 TensorFlow Extended(TFX)的开源实现,TFX 是一种在生产中部署机器学习流水线的端到端平台。因此,Kubeflow 使得在 Kubernetes 上简化执行 TensorFlow 作业成为可能MLFlow:MLflow 是用于将机器学习项目的端到端开发过程工业化的工具。其愿景是在企业中简化机器学习项目的开发,通过便捷的模型监控、复现、管理与部署来实现。
Data Version Control (DVC):DVC(Data Version Control)是一个 Python 包,可让您的数据科学项目管理更为轻松。正如其主要贡献者 Dmitry Petrov 在一次演讲中所述,该工具是面向机器学习的 Git 扩展。DVC 与 Git 既相似又互补。
Pachyderm:Pachyderm 是一款类似 DVC 的机器学习与数据科学版本控制工具。更进一步,它基于 Docker 和 Kubernetes,从而有助于在任意云平台上运行与部署机器学习项目。此外,Pachyderm 确保导入机器学习模型的所有数据均具备版本与可追溯性。
学习资源:走进 MLOps
机器学习基础
数据工程基础
深入 MLOps
我们希望这套资源能助您开启 MLOps 的学习之旅。关于 MLOps 的更多文章与资源,您还可以查看以下内容: