標(biāo)題：Machine Learning Operations (MLOps): Overview, Definition, and Architecture

作者：Dominik Kreuzberger, Niklas Kühl, Sebastian Hirschl

來源：https://arxiv.org/abs/2205.02302

時間：2022年5月

摘要

所有工業(yè)級的機器學(xué)習(xí) (ML) 項目的最終目標(biāo)是開發(fā) ML 產(chǎn)品并快速將其投入生產(chǎn)。然而，機器學(xué)習(xí)產(chǎn)品的自動化和實施極具挑戰(zhàn)性，因此許多機器學(xué)習(xí)的努力未能達(dá)到他們預(yù)期的回報。MLOps(Machine Learning Operations) 的范式解決了這個問題。 MLOps包括幾個方面，例如最佳實踐、概念集和開發(fā)文化。然而，MLOps 仍然是一個模糊的術(shù)語，它對研究人員和專業(yè)人士的影響是模棱兩可的。為了彌補這一差距，我們進行了混合方法研究，包括文獻回顧、工具回顧和專家訪談。作為這些調(diào)查的結(jié)果，我們對必要的原則、組件和角色以及相關(guān)的架構(gòu)和工作流程進行了匯總概述。此外，我們提供了 MLOps 的定義，并強調(diào)了該領(lǐng)域的開放挑戰(zhàn)。最后，這項工作為希望使用一組指定的技術(shù)自動化和運維其機器學(xué)習(xí)產(chǎn)品的 ML 研究人員和從業(yè)者提供了指導(dǎo)。

一、簡介

機器學(xué)習(xí) (ML) 已成為利用數(shù)據(jù)潛力的重要技術(shù)，并使企業(yè)更具創(chuàng)新性、高效和可持續(xù)發(fā)展。然而，許多投入生產(chǎn)的機器學(xué)習(xí)應(yīng)用在現(xiàn)實環(huán)境中的成功并未達(dá)到預(yù)期。大量 ML 項目失敗了——許多 ML 概念從未進展到生產(chǎn)。從研究的角度來看，這并不令人意外，因為 ML 社區(qū)廣泛關(guān)注 ML 模型的構(gòu)建，而不是構(gòu)建可量產(chǎn)的機器學(xué)習(xí)產(chǎn)品以及復(fù)雜的機器學(xué)習(xí)系統(tǒng)組件和基礎(chǔ)設(shè)施，包括在現(xiàn)實環(huán)境中能使ML系統(tǒng)自動化以及運維ML 系統(tǒng)。例如，在許多工業(yè)應(yīng)用中，數(shù)據(jù)科學(xué)家仍然在很大程度上手動管理 ML 工作流，從而導(dǎo)致在各個 ML 解決方案的操作過程中出現(xiàn)許多問題。

為了解決這些問題，這項工作的目標(biāo)是研究如何將手動 ML 流程自動化以及可運維，以便將更多的 ML 概念證明投入生產(chǎn)。在這項工作中，我們探索了新興的 ML 工程實踐“Machine Learning Operations”——簡稱 MLOps（機器學(xué)習(xí)運維）——精確地解決了設(shè)計和維護高效 ML 的問題。我們從整體的角度來獲得對所涉及的組件、原則、角色和架構(gòu)的共識。雖然現(xiàn)有研究對 MLOps 的各個特定方面有所講述，但仍然缺少對 ML 系統(tǒng)設(shè)計的整體概念化、概括和澄清。對“MLOps”一詞的不同觀點和概念可能會導(dǎo)致誤解和溝通不暢，進而導(dǎo)致整個 ML 系統(tǒng)的整體設(shè)置出現(xiàn)錯誤。因此，我們提出研究問題：

RQ：什么是 MLOps？

為了回答這個問題，我們進行了一項混合方法研究，用于：

(a) 確定 MLOps 的重要原則，

(b) 劃分功能核心組件，

(c) 強調(diào)成功實施 MLOps 所必需的角色，

(d) 推導(dǎo)出一個ML 系統(tǒng)設(shè)計的通用架構(gòu)。

結(jié)合起來，這些見解導(dǎo)致了 MLOps 的定義，這有助于對該術(shù)語和相關(guān)概念的共同理解。

通過這樣做，我們希望為專業(yè)人士和研究人員提供明確的指導(dǎo)方針，對學(xué)術(shù)和實踐討論產(chǎn)生積極影響，并承擔(dān)明確的責(zé)任。這些見解可以通過減少系統(tǒng)設(shè)計中的錯誤，并最終在現(xiàn)實世界環(huán)境中實現(xiàn)更可靠的預(yù)測，從而有助于將更多的概念證明投入生產(chǎn)。

這篇文章的其余部分結(jié)構(gòu)如下：我們將首先詳細(xì)闡述該領(lǐng)域的必要基礎(chǔ)和相關(guān)工作；接下來，我們將概述所使用的方法，包括文獻回顧、工具回顧和訪談研究；然后，我們展示了從該方法的應(yīng)用中得出的見解，并通過提供統(tǒng)一的定義來概念化這些見解；我們以簡短的總結(jié)、局限性和展望來結(jié)束本文。

二、DevOps的基礎(chǔ)

過去，軟件工程領(lǐng)域出現(xiàn)了不同的軟件開發(fā)過程模型和開發(fā)方法。突出的例子包括瀑布模型和敏捷宣言。這些方法具有相似的目標(biāo)，即交付可量產(chǎn)的軟件產(chǎn)品。 2008/2009 年出現(xiàn)了一個名為“DevOps”的概念，旨在減少軟件開發(fā)中的問題。DevOps 不僅僅是一種純粹的方法，而是代表了解決從事軟件開發(fā)的組織中的社會和技術(shù)問題的范式。它的目標(biāo)是消除開發(fā)和運維之間的差距，并強調(diào)協(xié)作、溝通和知識共享。它通過持續(xù)集成、持續(xù)交付和持續(xù)部署 (CI/CD) 確保自動化，從而實現(xiàn)快速、頻繁和可靠地發(fā)布。此外，它旨在確保持續(xù)測試、質(zhì)量保證、持續(xù)監(jiān)控、日志記錄和反饋循環(huán)。

由于 DevOps 的商業(yè)化，許多 DevOps 工具不斷涌現(xiàn)，可分為六類：協(xié)作和知識共享（例如 Slack、Trello、GitLab wiki）、源代碼管理（例如 GitHub、GitLab )、構(gòu)建過程（例如 Maven）、持續(xù)集成（例如 Jenkins、GitLab CI）、部署自動化（例如 Kubernetes、Docker）、監(jiān)控和日志記錄（例如 Prometheus、Logstash）。云環(huán)境越來越多地配備了專為云使用而設(shè)計的即用型 DevOps 工具，從而促進了價值的高效生成 [38]。隨著向DevOps這種新穎范式的轉(zhuǎn)變，開發(fā)人員需要關(guān)心他們開發(fā)的內(nèi)容，因為他們也需要操作它。正如實證結(jié)果所表明的那樣，DevOps 確保了更好的軟件質(zhì)量。業(yè)內(nèi)人士以及學(xué)術(shù)界人士通過使用 DevOps獲得了豐富的軟件工程方面的經(jīng)驗。這種經(jīng)驗現(xiàn)在被用于ML自動化和運維。

三、方法論

為了從學(xué)術(shù)知識庫中獲得見解，同時也利用該領(lǐng)域從業(yè)者的專業(yè)知識，我們采用混合方法方法，如圖 1 所示。作為第一步，我們進行結(jié)構(gòu)化文獻綜述以獲得相關(guān)研究的概述。此外，我們回顧了 MLOps 領(lǐng)域的相關(guān)工具支持，以更好地了解所涉及的技術(shù)組件。最后，我們與來自不同領(lǐng)域的專家進行半結(jié)構(gòu)式訪談（半結(jié)構(gòu)式訪談：事先有一定的題目和假設(shè)，但實際問題沒有具體化。其優(yōu)缺點介于結(jié)構(gòu)式訪談和非結(jié)構(gòu)式訪談之間）。在此基礎(chǔ)上，我們將“MLOps”一詞概念化，并在下一節(jié)（“結(jié)果”）中通過綜合文獻和訪談來詳細(xì)說明我們的發(fā)現(xiàn)。

圖1 研究方法綜述

3.1 文獻回顧

為確保我們的結(jié)果基于科學(xué)知識，我們根據(jù)Webster 和Watson，以及Kitchenham 等人的方法進行了系統(tǒng)的文獻回顧。我們查詢 Google Scholar、Web of Science、Science Direct、Scopus 和信息系統(tǒng)電子圖書館協(xié)會的科學(xué)數(shù)據(jù)庫。值得一提的是，將 DevOps 用于 ML，MLOps 以及與 ML 相結(jié)合的持續(xù)實踐是學(xué)術(shù)文獻中一個相對較新的領(lǐng)域。因此，在本研究進行時，只有少數(shù)同行評議的研究可用。然而，為了獲得這方面的經(jīng)驗，搜索也包括了非同行評審的文獻。搜索于 2021 年 5 月進行，共檢索到 1,864 篇文章。其中，我們詳細(xì)篩選了 194 篇論文。從該組中，根據(jù)我們的納入和排除標(biāo)準(zhǔn)選擇了 27 篇文章（例如，詳細(xì)描述了 MLOps 或 DevOps 和 CI/CD 與 ML 相結(jié)合的術(shù)語，文章是用英文寫的等）。所有 27 篇文章均經(jīng)過同行評審。

3.2 工具回顧

經(jīng)過 27 篇文章和 8 次采訪，確定了各種開源工具、框架和商業(yè)云 ML 服務(wù)。審查了這些工具、框架和 ML 服務(wù)，以了解它們所包含的技術(shù)組件。已識別工具的概述在下表中進行了描述。

技術(shù)名稱描述

開源示例TensorFlow 擴展TensorFlow Extended (TFX) 是一個配置框架，為端到端 ML 流程的每個任務(wù)提供庫。示例包括數(shù)據(jù)驗證、數(shù)據(jù)分布檢查、模型訓(xùn)練和模型服務(wù)。

AirflowAirflow 是一個任務(wù)和工作流編排工具，也可以用于 ML 工作流編排。它還用于編排數(shù)據(jù)工程作業(yè)。任務(wù)根據(jù)有向無環(huán)圖 (DAG) 執(zhí)行。

KubeflowKubeflow 是一個基于 Kubernetes 的端到端機器學(xué)習(xí)平臺。每個 Kubeflow 組件都包裝在一個容器中，并由 Kubernetes 進行編排。此外，ML 工作流的每個任務(wù)都由一個容器處理。

機器學(xué)習(xí)流MLflow 是一個允許端到端管理 ML 生命周期的 ML 平臺。它提供了高級實驗跟蹤功能、模型注冊表和模型服務(wù)組件。

商業(yè)示例Databricks 管理的 MLflowDatabricks 平臺提供基于其他云提供商基礎(chǔ)設(shè)施的托管服務(wù)，例如托管 MLflow。

亞馬遜代碼管道Amazon CodePipeline 是一種 CI/CD 自動化工具，用于促進構(gòu)建、測試和交付步驟。它還允許人們安排和管理 ML 管道的不同階段。

亞馬遜 SageMaker借助 SageMaker，Amazon AWS 提供了一個端到端的 ML 平臺。它提供開箱即用的功能存儲、使用 SageMaker Pipelines 進行編排以及使用 SageMaker 端點提供模型服務(wù)。

Azure DevOps 管道Azure DevOps Pipelines 是一種 CI/CD 自動化工具，用于促進構(gòu)建、測試和交付步驟。它還允許人們安排和管理 ML 管道的不同階段。

Azure 機器學(xué)習(xí)Microsoft Azure 結(jié)合 Azure DevOps Pipelines 和 Azure ML 提供了一個端到端的 ML 平臺。

GCP - 頂點人工智能GCP 與 Vertex AI 一起提供了一個完全托管的端到端平臺。此外，他們還提供了一個托管 Kubernetes 集群，其中包含 Kubeflow 即服務(wù)。

IBM Cloud Pak for Data(IBM Watson

Studio)

IBM Cloud Pak for Data 將一系列軟件組合在一個包中，提供數(shù)據(jù)和 ML 功能。

3.3 訪談研究

為了從實踐中獲得洞察力來回答研究問題，我們進行了半結(jié)構(gòu)式的專家訪談。我們應(yīng)用了一種理論抽樣方法，這使我們能夠選擇有經(jīng)驗的采訪伙伴來獲得高質(zhì)量的數(shù)據(jù)。這些數(shù)據(jù)可以通過有限數(shù)量的訪談提供有意義的見解。為了獲得足夠的樣本組和可靠的見解，我們使用 LinkedIn（一個面向?qū)I(yè)人士的社交網(wǎng)絡(luò)）來識別在全球范圍內(nèi)具有深厚 MLOps 知識的經(jīng)驗豐富的 ML 專業(yè)人士。為了從不同的角度獲得見解，我們選擇了來自不同組織和行業(yè)、不同國家和民族以及不同性別的面試伙伴。進行訪談，直到在數(shù)據(jù)分析中沒有出現(xiàn)新的類別和概念。

四、結(jié)果

我們應(yīng)用了可描述的方法并將由此得到的見解構(gòu)建為：重要原則的介紹、組件的實例化、必要角色的描述，以及對這些方面組合產(chǎn)生的架構(gòu)和工作流程的建議。最后，我們推導(dǎo)了該術(shù)語的概念化并提供了 MLOps 的定義。

4.1 原則

原則被視為普遍或基本的真理、價值或行為指南。在 MLOps 的背景下，原則是如何在 MLOps 中實現(xiàn)事物的指南，并且與專業(yè)領(lǐng)域的“最佳實踐”一詞密切相關(guān)。根據(jù)概述的方法，我們確定了實現(xiàn) MLOps 所需的九項原則。圖 2 提供了這些原則的說明，并將它們鏈接到與其相關(guān)聯(lián)的組件。

圖 2. 技術(shù)組件中原則的實施

原則1：CI/CD 自動化

CI/CD 自動化地提供持續(xù)集成、持續(xù)交付和持續(xù)部署。它執(zhí)行構(gòu)建、測試、交付和部署步驟。它向開發(fā)人員提供有關(guān)某些步驟的成功或失敗的快速反饋，從而提高整體生產(chǎn)力。

原則2：工作流程編排

工作流編排根據(jù)有向無環(huán)圖 (DAG) 協(xié)調(diào) ML 工作流管道的任務(wù)。 DAG 通過考慮關(guān)系和依賴關(guān)系來定義任務(wù)執(zhí)行順序。

原則3：可復(fù)現(xiàn)性

可復(fù)現(xiàn)性是重現(xiàn) ML 實驗并獲得完全相同結(jié)果的能力。

原則4：版本控制

版本控制確保數(shù)據(jù)、模型和代碼的版本控制不僅可以實現(xiàn)可復(fù)現(xiàn)性，還可以實現(xiàn)可追溯性（出于合規(guī)性和審計原因）。

原則5：協(xié)作

協(xié)作確保了在數(shù)據(jù)、模型和代碼上進行協(xié)作的可能性。除了技術(shù)方面，該原則強調(diào)協(xié)作和交流的工作文化，旨在減少不同角色之間的領(lǐng)域孤島。

原則6：持續(xù) ML 訓(xùn)練和評估

持續(xù)訓(xùn)練意味著基于新的特征數(shù)據(jù)定期重新訓(xùn)練 ML 模型。通過監(jiān)控組件、反饋循環(huán)和自動化 ML 工作流的支持，可以實現(xiàn)持續(xù)訓(xùn)練。持續(xù)訓(xùn)練的過程總是會伴隨著評估的運行，以評估模型質(zhì)量的變化。

原則7：ML 元數(shù)據(jù)跟蹤/記錄

為每個編排的 ML 工作流任務(wù)跟蹤和記錄元數(shù)據(jù)。每次訓(xùn)練迭代都需要元數(shù)據(jù)跟蹤和記錄（例如訓(xùn)練日期和時間、持續(xù)時間等），包括模型特定的元數(shù)據(jù)——例如，使用的參數(shù)和產(chǎn)生的性能指標(biāo)、模型沿襲：用于的數(shù)據(jù)和代碼確保實驗運行的完全可追溯性。

原則8：持續(xù)監(jiān)測

持續(xù)監(jiān)控意味著對數(shù)據(jù)、模型、代碼、基礎(chǔ)設(shè)施資源和模型服務(wù)性能（例如預(yù)測準(zhǔn)確性）進行定期評估，以檢測影響產(chǎn)品質(zhì)量的潛在錯誤或變化。

原則9：反饋回路

需要多個反饋循環(huán)來將來自質(zhì)量評估步驟的見解整合到開發(fā)或工程過程中（例如，從實驗?zāi)Ｐ凸こ屉A段到前一個特征工程階段的反饋循環(huán)）。從監(jiān)控組件（例如，觀察模型服務(wù)性能）到調(diào)度程序需要另一個反饋循環(huán)，以啟用再訓(xùn)練。

4.2 技術(shù)組件

在確定需要納入 MLOps 的原則之后，我們現(xiàn)在詳細(xì)說明精確的組件并在 ML 系統(tǒng)設(shè)計中實現(xiàn)它們。在下文中，以通用方式列出并描述了這些組件及其基本功能。

組件1：CI/CD 組件（原則1、6、9）

CI/CD 組件確保持續(xù)集成、持續(xù)交付和持續(xù)部署。它負(fù)責(zé)構(gòu)建、測試、交付和部署步驟。它向開發(fā)人員提供有關(guān)某些步驟的成功或失敗的快速反饋，從而提高整體生產(chǎn)力。例如 GitHub Actions。

組件2：源代碼倉庫（原則4、5）

源代碼倉庫確保代碼存儲和版本控制。它允許多個開發(fā)人員提交以及合并代碼，示例包括 Bitbucket、GitLab、GitHub和 Gitea。

組件3：工作流程編排組件（原則2、3、6）

工作流編排組件通過有向無環(huán)圖 (DAG) 提供 ML 工作流的任務(wù)編排。這些圖表示工作流的單個步驟的執(zhí)行順序和工件使用情況，示例包括 Apache Airflow、 Kubeflow Pipelines、Luigi、AWS SageMaker Pipelines和 Azure Pipelines。

組件4：特征平臺系統(tǒng)（原則3、4）

特征平臺（feature store）系統(tǒng)確保常用特征的集中存儲。它配置了兩個數(shù)據(jù)庫：一個數(shù)據(jù)庫作為離線特征存儲，為實驗提供具有正常延遲的特征，一個數(shù)據(jù)庫作為在線存儲，為生產(chǎn)中的預(yù)測提供低延遲的特征。示例包括 Google Feast、Amazon AWS Feature Store、Tecton.ai 和 Hopswork.ai。這是用于訓(xùn)練 ML 模型的大部分?jǐn)?shù)據(jù)的來源。此外，數(shù)據(jù)也可以直接來自任何類型的數(shù)據(jù)存儲。

組件5：模型訓(xùn)練基礎(chǔ)設(shè)施 (原則6)

模型訓(xùn)練基礎(chǔ)設(shè)施提供基礎(chǔ)計算資源，例如 CPU、RAM 和 GPU。提供的基礎(chǔ)設(shè)施可以是分布式的或非分布式的。一般來說，建議使用可擴展的分布式基礎(chǔ)設(shè)施。示例包括本地機器（不可擴展）或云計算，以及非分布式或分布式計算（多個工作節(jié)點）。支持計算的框架是 Kubernetes和 Red Hat OpenShift。

組件6：模型注冊表（原則3、4）

模型注冊表集中存儲經(jīng)過訓(xùn)練的 ML 模型及其元數(shù)據(jù)。它有兩個主要功能：存儲 ML 工件和存儲 ML 元數(shù)據(jù)（參見 組件7）。高級存儲示例包括 MLflow、AWS SageMaker 模型注冊表、Microsoft Azure ML 模型注冊表和Neptune.ai。簡單的存儲示例包括 Microsoft Azure Storage、Google Cloud Storage 和 Amazon AWS S3。

組件7：ML 元數(shù)據(jù)存儲（P4、P7）

ML 元數(shù)據(jù)存儲允許跟蹤各種元數(shù)據(jù)，例如，針對每個編排的 ML 工作流任務(wù)?？梢栽谀Ｐ妥员碇信渲昧硪粋€元數(shù)據(jù)存儲，用于跟蹤和記錄每個訓(xùn)練工作的元數(shù)據(jù)（例如，訓(xùn)練日期和時間、持續(xù)時間等），包括模型特定的元數(shù)據(jù)——例如，使用的參數(shù)和生成的性能指標(biāo)，模型沿襲：使用的數(shù)據(jù)和代碼。示例包括具有內(nèi)置元數(shù)據(jù)存儲的編排器，可跟蹤實驗流程的每個步驟，例如 Kubeflow Pipelines、AWS SageMaker Pipelines、Azure ML 和 IBM Watson Studio。MLflow 結(jié)合模型注冊表提供了高級元數(shù)據(jù)存儲。

組件8：模型服務(wù)組件 (原則1)

模型服務(wù)組件可以針對不同的目的進行配置。例如用于實時預(yù)測的在線推理或使用大量輸入數(shù)據(jù)進行預(yù)測的批量推理。作為基礎(chǔ)設(shè)施層，推薦使用可擴展的分布式模型服務(wù)基礎(chǔ)設(shè)施。模型服務(wù)組件配置的一個示例是使用 Kubernetes 和 Docker 技術(shù)來容器化 ML 模型，并利用 Python Web 應(yīng)用程序框架（如 Flask）和用于服務(wù)的 API。其他 Kubernetes支持的框架是 Kubeflow的 KServing、TensorFlow Serving 和 Seldion.io 服務(wù)。推理也可以使用 Apache Spark 來實現(xiàn)，用于批量預(yù)測。云服務(wù)的示例包括 Microsoft Azure ML REST API、AWS SageMaker Endpoints、IBM Watson Studio和 Google Vertex AI 預(yù)測服務(wù)。

組件9：監(jiān)控組件（原則8、9）

監(jiān)控組件負(fù)責(zé)持續(xù)監(jiān)控模型服務(wù)性能（例如預(yù)測準(zhǔn)確性）。此外，還需要監(jiān)控 ML 基礎(chǔ)設(shè)施、CI/CD 和編制。示例包括帶有 Grafana的 Prometheus、ELK 堆棧（Elasticsearch、Logstash 和 Kibana）和簡單的TensorBoard。具有內(nèi)置監(jiān)控功能的示例包括 Kubeflow、MLflow和 AWS SageMaker模型監(jiān)控器或云觀察。

4.3 角色

在描述了組件的原理及其產(chǎn)生的實例化之后，我們確定了必要的角色，以便接下來實現(xiàn) MLOps。 MLOps 是一個跨學(xué)科的小組過程，不同角色的相互作用對于在生產(chǎn)中設(shè)計、管理、自動化以及運維ML 系統(tǒng)至關(guān)重要。下面簡要介紹每個角色及其目的和相關(guān)任務(wù)：

角色1：業(yè)務(wù)利益相關(guān)者（類似角色：產(chǎn)品負(fù)責(zé)人、項目經(jīng)理）

業(yè)務(wù)利益相關(guān)者定義了要使用 ML 實現(xiàn)的業(yè)務(wù)目標(biāo)，并負(fù)責(zé)業(yè)務(wù)層面的溝通，例如展示 ML 產(chǎn)品產(chǎn)生的投資回報 (ROI)。

角色2：解決方案架構(gòu)師（類似角色：IT 架構(gòu)師）

解決方案架構(gòu)師設(shè)計架構(gòu)，并經(jīng)過全面評估定義要使用的技術(shù)。

角色3：數(shù)據(jù)科學(xué)家（類似角色：ML 專家、ML 開發(fā)人員）

數(shù)據(jù)科學(xué)家將業(yè)務(wù)問題轉(zhuǎn)換為 ML 問題并負(fù)責(zé)模型工程，包括選擇性能最佳的算法和超參數(shù)。

角色4：數(shù)據(jù)工程師（類似角色：DataOps工程師）

數(shù)據(jù)工程師建立并管理數(shù)據(jù)及特征工程管道。此外，此角色可確保將正確的數(shù)據(jù)存儲到特征憑條系統(tǒng)的數(shù)據(jù)庫中。

角色5：軟件工程師

軟件工程師應(yīng)用軟件設(shè)計模式、廣泛接受的編碼指南和最佳實踐將原始 ML 問題轉(zhuǎn)化為設(shè)計良好的產(chǎn)品。

角色6：開發(fā)運維工程師

DevOps工程師彌補了開發(fā)和運維之間的差距，并確保適當(dāng)?shù)?CI/CD 自動化、ML 工作流編排、模型部署到生產(chǎn)和監(jiān)控。

角色7：ML 工程師/MLOps 工程師

ML 工程師或 MLOps 工程師結(jié)合了多個角色的各個方面，因此具有具備跨領(lǐng)域的知識。該角色融合了數(shù)據(jù)科學(xué)家、數(shù)據(jù)工程師、軟件工程師、DevOps工程師和后端工程師的技能（參見圖 3）。這個跨領(lǐng)域的角色建立和運營 ML 基礎(chǔ)設(shè)施，管理自動化的ML工作流和模型部署到生產(chǎn)，并監(jiān)控模型和 ML 基礎(chǔ)設(shè)施。

圖 3. MLOps 范式的角色及其交叉點

五、架構(gòu)和工作流程

在確定的原則、組件和角色的基礎(chǔ)上，我們推導(dǎo)出一個通用的 MLOps 端到端架構(gòu)，為 ML 研究人員和從業(yè)者提供適當(dāng)?shù)闹笇?dǎo)，如圖 4 所示。此外，我們還描述了工作流，即不同任務(wù)在不同階段執(zhí)行的順序。因此，機器學(xué)習(xí)研究人員和從業(yè)者可以選擇最適合他們需求的技術(shù)和框架。

如圖 4 所示，我們展示了從 MLOps 項目啟動到模型服務(wù)的端到端流程。它包括：

(A) MLOps項目啟動步驟；

(B) 特征工程流水線，包括特征平臺的數(shù)據(jù)攝?。?/p>

(C) 實驗；

(D) 到模型服務(wù)的自動化的 ML 工作流。

(A) MLOps項目啟動

(1) 業(yè)務(wù)利益相關(guān)者(角色1)分析業(yè)務(wù)并確定可以使用 ML 解決的潛在業(yè)務(wù)問題；

(2) 解決方案架構(gòu)師(角色2)定義整個 ML 系統(tǒng)的架構(gòu)設(shè)計，并在全面評估后決定要使用的技術(shù)；

(3) 數(shù)據(jù)科學(xué)家(角色3)從業(yè)務(wù)目標(biāo)推導(dǎo)出 ML 問題，例如是否應(yīng)該使用回歸或分類模型；

(4) 數(shù)據(jù)工程師(角色4)和數(shù)據(jù)科學(xué)家(角色3)齊心協(xié)力，梳理解決這個問題需要哪些數(shù)據(jù)； (5) 明確答案后，數(shù)據(jù)工程師(角色4)和數(shù)據(jù)科學(xué)家(角色3)將協(xié)作定位原始數(shù)據(jù)源，以進行初始數(shù)據(jù)分析。他們檢查數(shù)據(jù)的分布和質(zhì)量，并執(zhí)行驗證檢查。此外，他們確保來自數(shù)據(jù)源的數(shù)據(jù)被打上標(biāo)簽，這意味著目標(biāo)屬性是已知的，因為這是監(jiān)督機器學(xué)習(xí)的強制性要求。在此示例中，數(shù)據(jù)源已經(jīng)具有可用的標(biāo)記數(shù)據(jù)，因為標(biāo)記步驟在上游過程中被覆蓋。

(B1) 特征工程流水線的要求

特征是模型訓(xùn)練所需的相關(guān)屬性。在初步了解原始數(shù)據(jù)和初步數(shù)據(jù)分析后，定義特征工程流水線的基本要求如下：

(6) 數(shù)據(jù)工程師(角色4)定義數(shù)據(jù)轉(zhuǎn)換規(guī)則（規(guī)范化、聚合）和清洗規(guī)則，將數(shù)據(jù)轉(zhuǎn)換為可用的格式；

(7) 數(shù)據(jù)科學(xué)家(角色3)和數(shù)據(jù)工程師(角色4)共同定義特征工程規(guī)則，例如基于其他特征計算新的和更高級的特征。這些最初定義的規(guī)則必須由數(shù)據(jù)科學(xué)家(角色3)根據(jù)來自實驗?zāi)Ｐ凸こ屉A段的反饋或來自觀察模型性能的監(jiān)控組件的反饋進行迭代調(diào)整。

(B2) 特征工程流水線

數(shù)據(jù)工程師(角色4)和軟件工程師(角色5)以最初定義的特征工程流水線需求為起點，構(gòu)建特征工程流水線的原型。最初定義的要求和規(guī)則根據(jù)來自實驗?zāi)Ｐ凸こ屉A段或來自觀察模型在生產(chǎn)中的性能的監(jiān)控組件的迭代反饋進行更新。作為一項基本要求，數(shù)據(jù)工程師(角色4)定義了 CI/CD (組件1)和編排組件(組件3)所需的代碼，以確保特征工程流水線的任務(wù)編排。此角色還定義了底層基礎(chǔ)架構(gòu)資源配置。

(8) 首先，特征工程流水線連接到原始數(shù)據(jù)，例如可以是流數(shù)據(jù)、靜態(tài)批處理數(shù)據(jù)或來自任何云存儲的數(shù)據(jù)；

(9) 數(shù)據(jù)將從數(shù)據(jù)源中提??；

(10) 數(shù)據(jù)預(yù)處理從數(shù)據(jù)轉(zhuǎn)換和清洗任務(wù)開始。在需求收集階段定義的轉(zhuǎn)換規(guī)則工件用作此任務(wù)的輸入，此任務(wù)的主要目的是將數(shù)據(jù)轉(zhuǎn)換為可用格式。這些轉(zhuǎn)換規(guī)則會根據(jù)反饋不斷改進；

圖 4. 具有功能組件和角色的端到端 MLOps 架構(gòu)和工作流

(11) 特征工程任務(wù)基于其他特征計算新的和更高級的特征。預(yù)定義的特征工程規(guī)則用作此任務(wù)的輸入。這些特征工程規(guī)則會根據(jù)反饋不斷改進；

(12) 最后，將批量或流式數(shù)據(jù)加載到特征平臺系統(tǒng)(組件4)中。目標(biāo)是離線或在線數(shù)據(jù)庫（或任何類型的數(shù)據(jù)存儲）。

（C）實驗

實驗階段的大多數(shù)任務(wù)由數(shù)據(jù)科學(xué)家(角色3)領(lǐng)導(dǎo)。數(shù)據(jù)科學(xué)家由軟件工程師(角色5)提供支持。

(13) 數(shù)據(jù)科學(xué)家(角色3)通過特征平臺系統(tǒng)(組件4)進行數(shù)據(jù)分析?；蛘?，數(shù)據(jù)科學(xué)家也可以通過原始數(shù)據(jù)進行初步分析。如果需要進行任何數(shù)據(jù)調(diào)整，數(shù)據(jù)科學(xué)家會將所需的更改報告回數(shù)據(jù)工程區(qū)（反饋循環(huán)）；

(14) 然后，需要對來自特征平臺系統(tǒng)的數(shù)據(jù)進行準(zhǔn)備和驗證。此任務(wù)還包括創(chuàng)建訓(xùn)練和測試數(shù)據(jù)集；

(15) 數(shù)據(jù)科學(xué)家(角色3)估計性能最佳的算法和超參數(shù)，然后用訓(xùn)練數(shù)據(jù)(組件5)觸發(fā)模型訓(xùn)練。軟件工程師(角色5)支持?jǐn)?shù)據(jù)科學(xué)家(角色3)創(chuàng)建精心設(shè)計的模型訓(xùn)練代碼；

(16) 在多輪模型訓(xùn)練中，對不同的模型參數(shù)進行交叉測試和驗證。一旦性能指標(biāo)表明結(jié)果良好，迭代訓(xùn)練就會停止。性能最佳的模型參數(shù)是通過參數(shù)調(diào)整來確定的。然后重復(fù)迭代模型訓(xùn)練任務(wù)和模型驗證任務(wù)；這些任務(wù)一起可以稱為“模型工程”。模型工程旨在確定模型的最佳性能算法和超參數(shù)；

(17) 數(shù)據(jù)科學(xué)家(角色3)導(dǎo)出模型并將代碼提交到倉庫。

作為一項基本要求，DevOps工程師或 ML工程師定義自動化 ML工作流的代碼并將其提交到倉庫。一旦數(shù)據(jù)科學(xué)家提交新的 ML 模型，或者 DevOps 工程師和 ML工程師將新的 ML 工作流代碼提交到倉庫，CI/CD 組件就會檢測到更新的代碼并自動觸發(fā) CI/CD流程執(zhí)行構(gòu)建、測試和交付步驟。構(gòu)建步驟包含 ML模型和 ML工作流的任務(wù)的工件。測試步驟驗證 ML 模型和 ML 工作流代碼。交付步驟將版本化的工件（例如圖像）推送到工件存儲（例如，圖像注冊表）。

（D）自動化 ML工作流

DevOps工程師和 ML工程師負(fù)責(zé)管理自動化的 ML 工作流。他們還以硬件資源和支持計算框架（如 Kubernetes）的形式管理底層模型訓(xùn)練基礎(chǔ)設(shè)施。工作流編排組件編排自動化 ML 工作流的任務(wù)。對于每個任務(wù)，從工件存儲（例如圖像注冊表）中提取所需的工件（例如圖像）。每個任務(wù)都可以通過一個隔離的環(huán)境（例如容器）執(zhí)行。最后，工作流編排組件以日志、完成時間等形式為每個任務(wù)收集元數(shù)據(jù)。

一旦觸發(fā)了自動化 ML 工作流，就會自動管理以下每個任務(wù)：

(18) 從特征平臺系統(tǒng)中自動提取版本化的特征（數(shù)據(jù)提?。?。根據(jù)用例，從離線或在線數(shù)據(jù)庫（或任何類型的數(shù)據(jù)存儲）中提取特征；

(19) 自動化數(shù)據(jù)準(zhǔn)備和驗證；此外，訓(xùn)練集和測試集的拆分是被自動定義；

(20) 對新的未遇見過的數(shù)據(jù)進行自動模型訓(xùn)練。算法和超參數(shù)已經(jīng)根據(jù)前一個實驗階段的設(shè)置進行了預(yù)定義。這樣，模型就被重新訓(xùn)練和改進了；

(21) 如果需要，執(zhí)行自動化的模型評估和超參數(shù)的迭代調(diào)整。一旦性能指標(biāo)表明結(jié)果良好，自動迭代訓(xùn)練就會停止。自動化模型訓(xùn)練任務(wù)和自動化模型驗證任務(wù)可以反復(fù)重復(fù)，直到取得良好的結(jié)果；

(22) 然后，訓(xùn)練后的模型被導(dǎo)出并推送到模型注冊表，在那里它被存儲為代碼或與其相關(guān)的配置和環(huán)境文件一起容器化。

對于所有訓(xùn)練任務(wù)迭代，ML元數(shù)據(jù)存儲記錄元數(shù)據(jù)，例如用于訓(xùn)練模型的參數(shù)和生成的性能指標(biāo)。這還包括跟蹤和記錄訓(xùn)練任務(wù)ID、訓(xùn)練日期和時間、持續(xù)時間以及工件來源。此外，為每個新注冊的模型跟蹤模型特定元數(shù)據(jù)（也稱為“模型沿襲”），該元數(shù)據(jù)結(jié)合了數(shù)據(jù)和代碼的沿襲，這包括用于訓(xùn)練模型的特征數(shù)據(jù)和模型訓(xùn)練代碼的來源和版本。此外，還會記錄模型版本和狀態(tài)（例如暫存或生產(chǎn)就緒）。

一旦一個表現(xiàn)良好的模型從暫存狀態(tài)切換到生產(chǎn)狀態(tài)，它就會自動移交給 DevOps工程師或 ML工程師進行模型部署。從那里，CI/CD 組件觸發(fā)持續(xù)部署流程。生產(chǎn)就緒的 ML模型和模型服務(wù)代碼被拉取（最初由軟件工程師準(zhǔn)備）。持續(xù)部署流程執(zhí)行 ML模型和服務(wù)代碼的構(gòu)建和測試步驟，并將模型部署到生產(chǎn)服務(wù)；

(23) 模型服務(wù)組件對來自特征平臺系統(tǒng)的新的、沒遇見過的數(shù)據(jù)進行預(yù)測。該組件可由軟件工程師設(shè)計為用于實時預(yù)測的在線推理或用于大量輸入數(shù)據(jù)的預(yù)測的批量推理。對于實時預(yù)測，特征必須來自在線數(shù)據(jù)庫（低延遲），而對于批量預(yù)測，特征可以來自離線數(shù)據(jù)庫（正常延遲）。模型服務(wù)應(yīng)用程序通常在容器中配置，預(yù)測請求通過 REST API 處理。作為一項基本要求，ML工程師管理模型服務(wù)計算基礎(chǔ)設(shè)施；

(26) 監(jiān)控組件 (組件9) 持續(xù)實時觀察模型服務(wù)性能和基礎(chǔ)設(shè)施。一旦達(dá)到某個閾值，例如檢測到預(yù)測精度較低，信息就會通過反饋回路轉(zhuǎn)發(fā)。反饋回路連接到監(jiān)控組件并確保快速和直接的反饋，從而實現(xiàn)更穩(wěn)健和更好的預(yù)測。它支持持續(xù)訓(xùn)練、重新訓(xùn)練和改進。在反饋回路的支持下，信息從模型監(jiān)控組件傳遞到多個上游接收點，例如實驗階段、數(shù)據(jù)工程區(qū)和調(diào)度器（觸發(fā)器）。

數(shù)據(jù)科學(xué)家將反饋到實驗階段，以進一步改進模型。對數(shù)據(jù)工程區(qū)的反饋允許調(diào)整為特征平臺系統(tǒng)準(zhǔn)備的特征。此外，作為反饋機制，模型漂移的檢測可以實現(xiàn)持續(xù)訓(xùn)練（模型漂移指的是舊的模型隨著時間的改變,在最新特征下模型的效果會越來越差）。例如，一旦模型監(jiān)控組件檢測到數(shù)據(jù)中的模型漂移，信息就會被轉(zhuǎn)發(fā)到調(diào)度程序，然后調(diào)度程序觸發(fā)自動化ML工作流進行重訓(xùn)練（持續(xù)訓(xùn)練）?？梢允褂梅植急容^的方法檢測已部署的模型的充分變化，進而識別漂移現(xiàn)象是否發(fā)生。重新訓(xùn)練不僅會在達(dá)到統(tǒng)計閾值時自動觸發(fā)；它也可以在有新的特征數(shù)據(jù)可用時觸發(fā)，也可以被定期安排。

六、概念化

很明顯，MLOps是機器學(xué)習(xí)、軟件工程、DevOps 和數(shù)據(jù)工程的交叉領(lǐng)域（參見圖 5）。

圖 5. MLOps 范式的學(xué)科交叉

我們將 MLOps 定義如下：

MLOps（機器學(xué)習(xí)運維）是一種范式，包括：最佳實踐，概念集，端到端概念化、實施、監(jiān)控、部署等方面的開發(fā)文化，以及機器學(xué)習(xí)產(chǎn)品的可擴展性。最重要的是，它是一種利用3個學(xué)科的工程實踐：機器學(xué)習(xí)、軟件工程（尤其是 DevOps）和數(shù)據(jù)工程。MLOps旨在通過彌合開發(fā)(Dev)和運維(Ops)之間的差距來構(gòu)建機器學(xué)習(xí)系統(tǒng)。從本質(zhì)上講，MLOps旨在通過利用以下原則促進機器學(xué)習(xí)產(chǎn)品的生產(chǎn)：CI/CD 自動化、工作流編排、可重復(fù)性；數(shù)據(jù)、模型和代碼的版本控制；合作；持續(xù)的機器學(xué)習(xí)訓(xùn)練和評估；ML元數(shù)據(jù)跟蹤和記錄；持續(xù)監(jiān)控；反饋回路。

七、開放挑戰(zhàn)

MLOps的幾個挑戰(zhàn)被分成組織上的、機器學(xué)習(xí)系統(tǒng)的和運維的挑戰(zhàn)。

（1）組織挑戰(zhàn)

數(shù)據(jù)科學(xué)實踐的思維方式和文化是組織機構(gòu)環(huán)境中的典型挑戰(zhàn)。正如我們從文獻和采訪中獲得的見解所表明的那樣，要成功開發(fā)和運維ML產(chǎn)品，就需要從模型驅(qū)動的機器學(xué)習(xí)轉(zhuǎn)向以產(chǎn)品為導(dǎo)向的行為準(zhǔn)則。最近，以數(shù)據(jù)為中心的 AI 的趨勢通過“更多地關(guān)注在 ML 模型構(gòu)建之前的數(shù)據(jù)”在解決這一方面的問題，尤其是與這些活動相關(guān)的角色在設(shè)計 ML 產(chǎn)品時應(yīng)該具有以產(chǎn)品為中心的視角。MLOps需要大量的技能和個人角色，正如我們所指出的那樣，這些角色缺乏高技能的專家——尤其是在架構(gòu)師、數(shù)據(jù)工程師、ML工程師和 DevOps工程師方面。這與未來專業(yè)人員的必要教育有關(guān)——因為 MLOps 通常不是數(shù)據(jù)科學(xué)教育的一部分。也就是說，機器學(xué)習(xí)工程師不僅應(yīng)該學(xué)習(xí)模型創(chuàng)建，還必須了解構(gòu)建功能性 ML 產(chǎn)品所需的技術(shù)和組件。單靠數(shù)據(jù)科學(xué)家無法實現(xiàn) MLOps 的目標(biāo)。需要一個多學(xué)科的團隊，因此 MLOps 需要一個小組團隊才能完成。這通常會受到阻礙，因為團隊在孤島中工作而不是在合作中工作。此外，不同的知識水平和專業(yè)術(shù)語使交流變得困難。為了給更富有成效的設(shè)置奠定基礎(chǔ)，各自的決策者需要確信提高 MLOps 成熟度和以產(chǎn)品為中心的思維方式將產(chǎn)生明顯的業(yè)務(wù)改進。

（2）機器學(xué)習(xí)系統(tǒng)挑戰(zhàn)

MLOps系統(tǒng)的一個主要挑戰(zhàn)是針對波動的需求進行設(shè)計，特別是與 ML 訓(xùn)練過程相關(guān)的。這源于潛在的大量和變化的數(shù)據(jù)，這使得精確估計必要的基礎(chǔ)設(shè)施資源（CPU、RAM 和 GPU）變得困難，并且在基礎(chǔ)設(shè)施的可擴展性方面需要高度的靈活性。

（3）運營挑戰(zhàn)

在生產(chǎn)環(huán)境中，由于軟硬件組件的不同堆棧及其相互作用，手動運維ML具有挑戰(zhàn)性。因此，需要強大的自動化能力。此外，源源不斷的新數(shù)據(jù)流會高度依賴重新訓(xùn)練能力。這是一項重復(fù)性任務(wù)，同樣需要高度自動化。這些重復(fù)性任務(wù)產(chǎn)生大量工件，需要強大的治理以及數(shù)據(jù)、模型和代碼的版本控制，以確保穩(wěn)健性和可重復(fù)性。最后，解決潛在的支持請求（例如通過查找根本原因）具有挑戰(zhàn)性，因為涉及到許多部分和組件，故障可能是 ML 基礎(chǔ)設(shè)施和軟件的組合。

八、結(jié)論

隨著數(shù)據(jù)可用性和分析能力的提升，以及不斷創(chuàng)新的壓力，比以往更多的機器學(xué)習(xí)產(chǎn)品正在被源源不斷的開發(fā)出來。但是，這些概念證明中只有一小部分會進入部署和生產(chǎn)階段。此外，學(xué)術(shù)領(lǐng)域?qū)Ｗ⒂跈C器學(xué)習(xí)模型的構(gòu)建和基準(zhǔn)測試，但在現(xiàn)實世界場景中操作復(fù)雜的機器學(xué)習(xí)系統(tǒng)方面卻很少。在現(xiàn)實世界中，我們觀察到數(shù)據(jù)科學(xué)家仍在很大程度上手動管理 ML工作流。機器學(xué)習(xí)運維MLOps的范式解決了這些挑戰(zhàn)。在這項工作中，我們更加了解了 MLOps。通過對現(xiàn)有文獻和工具進行混合方法研究，并采訪該領(lǐng)域的專家，我們發(fā)現(xiàn)了 MLOps的4主要方面：原理、組件、角色和架構(gòu)?；诖耍覀兘o出了MLOps的定義，希望可以幫助大家在未來搭建成功的ML項目。