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

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

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

時間：2022年5月

摘要

所有工業(yè)級的機器學習 (ML) 項目的最終目標是開發(fā) ML 產品并快速將其投入生產此衅。然而强戴，機器學習產品的自動化和實施極具挑戰(zhàn)性，因此許多機器學習的努力未能達到他們預期的回報炕柔。MLOps(Machine Learning Operations) 的范式解決了這個問題酌泰。 MLOps包括幾個方面媒佣，例如最佳實踐匕累、概念集和開發(fā)文化。然而默伍，MLOps 仍然是一個模糊的術語欢嘿，它對研究人員和專業(yè)人士的影響是模棱兩可的衰琐。為了彌補這一差距，我們進行了混合方法研究炼蹦，包括文獻回顧羡宙、工具回顧和專家訪談。作為這些調查的結果掐隐，我們對必要的原則狗热、組件和角色以及相關的架構和工作流程進行了匯總概述。此外虑省，我們提供了 MLOps 的定義匿刮，并強調了該領域的開放挑戰(zhàn)廉丽。最后承耿，這項工作為希望使用一組指定的技術自動化和運維其機器學習產品的 ML 研究人員和從業(yè)者提供了指導钧汹。

一黄痪、簡介

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

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

RQ：什么是 MLOps允蚣？

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

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

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

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

(d) 推導出一個ML 系統(tǒng)設計的通用架構冒晰。

結合起來章母，這些見解導致了 MLOps 的定義，這有助于對該術語和相關概念的共同理解翩剪。

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

這篇文章的其余部分結構如下：我們將首先詳細闡述該領域的必要基礎和相關工作；接下來浙巫，我們將概述所使用的方法金蜀，包括文獻回顧、工具回顧和訪談研究的畴；然后渊抄，我們展示了從該方法的應用中得出的見解，并通過提供統(tǒng)一的定義來概念化這些見解丧裁；我們以簡短的總結护桦、局限性和展望來結束本文。

二煎娇、DevOps的基礎

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

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

三核偿、方法論

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

圖1 研究方法綜述

3.1 文獻回顧

為確保我們的結果基于科學知識褒搔，我們根據(jù)Webster 和Watson，以及Kitchenham 等人的方法進行了系統(tǒng)的文獻回顧喷面。我們查詢 Google Scholar站超、Web of Science、Science Direct乖酬、Scopus 和信息系統(tǒng)電子圖書館協(xié)會的科學數(shù)據(jù)庫死相。值得一提的是，將 DevOps 用于 ML咬像，MLOps 以及與 ML 相結合的持續(xù)實踐是學術文獻中一個相對較新的領域算撮。因此，在本研究進行時县昂，只有少數(shù)同行評議的研究可用肮柜。然而，為了獲得這方面的經驗倒彰，搜索也包括了非同行評審的文獻审洞。搜索于 2021 年 5 月進行，共檢索到 1,864 篇文章待讳。其中芒澜，我們詳細篩選了 194 篇論文。從該組中创淡，根據(jù)我們的納入和排除標準選擇了 27 篇文章（例如痴晦，詳細描述了 MLOps 或 DevOps 和 CI/CD 與 ML 相結合的術語，文章是用英文寫的等）琳彩。所有 27 篇文章均經過同行評審誊酌。

3.2 工具回顧

經過 27 篇文章和 8 次采訪部凑，確定了各種開源工具、框架和商業(yè)云 ML 服務碧浊。審查了這些工具涂邀、框架和 ML 服務，以了解它們所包含的技術組件箱锐。已識別工具的概述在下表中進行了描述比勉。

技術名稱描述

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

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

KubeflowKubeflow 是一個基于 Kubernetes 的端到端機器學習平臺毙替。每個 Kubeflow 組件都包裝在一個容器中岸售，并由 Kubernetes 進行編排。此外厂画，ML 工作流的每個任務都由一個容器處理凸丸。

機器學習流MLflow 是一個允許端到端管理 ML 生命周期的 ML 平臺。它提供了高級實驗跟蹤功能袱院、模型注冊表和模型服務組件屎慢。

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

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

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

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

Azure 機器學習Microsoft Azure 結合 Azure DevOps Pipelines 和 Azure ML 提供了一個端到端的 ML 平臺酷鸦。

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

IBM Cloud Pak for Data(IBM Watson

Studio)

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

3.3 訪談研究

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

四敲街、結果

我們應用了可描述的方法并將由此得到的見解構建為：重要原則的介紹、組件的實例化严望、必要角色的描述多艇，以及對這些方面組合產生的架構和工作流程的建議。最后像吻，我們推導了該術語的概念化并提供了 MLOps 的定義墩蔓。

4.1 原則

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

圖 2. 技術組件中原則的實施

原則1：CI/CD 自動化

CI/CD 自動化地提供持續(xù)集成、持續(xù)交付和持續(xù)部署览爵。它執(zhí)行構建置鼻、測試、交付和部署步驟蜓竹。它向開發(fā)人員提供有關某些步驟的成功或失敗的快速反饋箕母，從而提高整體生產力储藐。

原則2：工作流程編排

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

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

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

原則4：版本控制

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

原則5：協(xié)作

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

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

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

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

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

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

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

原則9：反饋回路

需要多個反饋循環(huán)來將來自質量評估步驟的見解整合到開發(fā)或工程過程中（例如室谚，從實驗模型工程階段到前一個特征工程階段的反饋循環(huán)）。從監(jiān)控組件（例如崔泵，觀察模型服務性能）到調度程序需要另一個反饋循環(huán)秒赤，以啟用再訓練。

4.2 技術組件

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

組件1：CI/CD 組件（原則1潮售、6痊项、9）

CI/CD 組件確保持續(xù)集成、持續(xù)交付和持續(xù)部署饲做。它負責構建线婚、測試、交付和部署步驟盆均。它向開發(fā)人員提供有關某些步驟的成功或失敗的快速反饋塞弊，從而提高整體生產力。例如 GitHub Actions泪姨。

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

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

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

工作流編排組件通過有向無環(huán)圖 (DAG) 提供 ML 工作流的任務編排婆誓。這些圖表示工作流的單個步驟的執(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ù)庫作為在線存儲骑篙，為生產中的預測提供低延遲的特征。示例包括 Google Feast森书、Amazon AWS Feature Store靶端、Tecton.ai 和 Hopswork.ai。這是用于訓練 ML 模型的大部分數(shù)據(jù)的來源拄氯。此外躲查，數(shù)據(jù)也可以直接來自任何類型的數(shù)據(jù)存儲。

組件5：模型訓練基礎設施 (原則6)

模型訓練基礎設施提供基礎計算資源译柏，例如 CPU镣煮、RAM 和 GPU。提供的基礎設施可以是分布式的或非分布式的鄙麦。一般來說典唇，建議使用可擴展的分布式基礎設施镊折。示例包括本地機器（不可擴展）或云計算，以及非分布式或分布式計算（多個工作節(jié)點）介衔。支持計算的框架是 Kubernetes和 Red Hat OpenShift恨胚。

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

模型注冊表集中存儲經過訓練的 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 工作流任務蓖柔。可以在模型注冊表中配置另一個元數(shù)據(jù)存儲风纠，用于跟蹤和記錄每個訓練工作的元數(shù)據(jù)（例如况鸣，訓練日期和時間、持續(xù)時間等）议忽，包括模型特定的元數(shù)據(jù)——例如懒闷，使用的參數(shù)和生成的性能指標十减，模型沿襲：使用的數(shù)據(jù)和代碼栈幸。示例包括具有內置元數(shù)據(jù)存儲的編排器，可跟蹤實驗流程的每個步驟帮辟，例如 Kubeflow Pipelines速址、AWS SageMaker Pipelines、Azure ML 和 IBM Watson Studio由驹。MLflow 結合模型注冊表提供了高級元數(shù)據(jù)存儲芍锚。

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

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

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

監(jiān)控組件負責持續(xù)監(jiān)控模型服務性能（例如預測準確性）妨退。此外妇萄，還需要監(jiān)控 ML 基礎設施、CI/CD 和編制咬荷。示例包括帶有 Grafana的 Prometheus嚣伐、ELK 堆棧（Elasticsearch、Logstash 和 Kibana）和簡單的TensorBoard萍丐。具有內置監(jiān)控功能的示例包括 Kubeflow轩端、MLflow和 AWS SageMaker模型監(jiān)控器或云觀察。

4.3 角色

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

角色1：業(yè)務利益相關者（類似角色：產品負責人根灯、項目經理）

業(yè)務利益相關者定義了要使用 ML 實現(xiàn)的業(yè)務目標，并負責業(yè)務層面的溝通掺栅，例如展示 ML 產品產生的投資回報 (ROI)烙肺。

角色2：解決方案架構師（類似角色：IT 架構師）

解決方案架構師設計架構，并經過全面評估定義要使用的技術氧卧。

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

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

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

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

角色5：軟件工程師

軟件工程師應用軟件設計模式星著、廣泛接受的編碼指南和最佳實踐將原始 ML 問題轉化為設計良好的產品。

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

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

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

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

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

五、架構和工作流程

在確定的原則捞蚂、組件和角色的基礎上，我們推導出一個通用的 MLOps 端到端架構跷究，為 ML 研究人員和從業(yè)者提供適當?shù)闹笇昭福鐖D 4 所示。此外俊马，我們還描述了工作流丁存，即不同任務在不同階段執(zhí)行的順序。因此柴我，機器學習研究人員和從業(yè)者可以選擇最適合他們需求的技術和框架解寝。

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

(A) MLOps項目啟動步驟聋伦；

(B) 特征工程流水線，包括特征平臺的數(shù)據(jù)攝冉缯觥觉增；

(C) 實驗；

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

(A) MLOps項目啟動

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

(2) 解決方案架構師(角色2)定義整個 ML 系統(tǒng)的架構設計卵佛，并在全面評估后決定要使用的技術杨赤；

(3) 數(shù)據(jù)科學家(角色3)從業(yè)務目標推導出 ML 問題，例如是否應該使用回歸或分類模型截汪；

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

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

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

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

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

(B2) 特征工程流水線

數(shù)據(jù)工程師(角色4)和軟件工程師(角色5)以最初定義的特征工程流水線需求為起點爬虱，構建特征工程流水線的原型。最初定義的要求和規(guī)則根據(jù)來自實驗模型工程階段或來自觀察模型在生產中的性能的監(jiān)控組件的迭代反饋進行更新腾它。作為一項基本要求跑筝，數(shù)據(jù)工程師(角色4)定義了 CI/CD (組件1)和編排組件(組件3)所需的代碼，以確保特征工程流水線的任務編排瞒滴。此角色還定義了底層基礎架構資源配置曲梗。

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

(9) 數(shù)據(jù)將從數(shù)據(jù)源中提仁榔省定罢；

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

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

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

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

（C）實驗

實驗階段的大多數(shù)任務由數(shù)據(jù)科學家(角色3)領導。數(shù)據(jù)科學家由軟件工程師(角色5)提供支持权埠。

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

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

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

(16) 在多輪模型訓練中与柑，對不同的模型參數(shù)進行交叉測試和驗證。一旦性能指標表明結果良好蓄坏，迭代訓練就會停止价捧。性能最佳的模型參數(shù)是通過參數(shù)調整來確定的。然后重復迭代模型訓練任務和模型驗證任務涡戳；這些任務一起可以稱為“模型工程”结蟋。模型工程旨在確定模型的最佳性能算法和超參數(shù)；

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

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

（D）自動化 ML工作流

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

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

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

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

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

(21) 如果需要，執(zhí)行自動化的模型評估和超參數(shù)的迭代調整耘子。一旦性能指標表明結果良好果漾，自動迭代訓練就會停止。自動化模型訓練任務和自動化模型驗證任務可以反復重復谷誓，直到取得良好的結果绒障；

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

對于所有訓練任務迭代，ML元數(shù)據(jù)存儲記錄元數(shù)據(jù)费封，例如用于訓練模型的參數(shù)和生成的性能指標焕妙。這還包括跟蹤和記錄訓練任務ID、訓練日期和時間弓摘、持續(xù)時間以及工件來源焚鹊。此外，為每個新注冊的模型跟蹤模型特定元數(shù)據(jù)（也稱為“模型沿襲”）韧献，該元數(shù)據(jù)結合了數(shù)據(jù)和代碼的沿襲末患，這包括用于訓練模型的特征數(shù)據(jù)和模型訓練代碼的來源和版本。此外锤窑，還會記錄模型版本和狀態(tài)（例如暫存或生產就緒）璧针。

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

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

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

數(shù)據(jù)科學家將反饋到實驗階段坑律，以進一步改進模型岩梳。對數(shù)據(jù)工程區(qū)的反饋允許調整為特征平臺系統(tǒng)準備的特征。此外晃择，作為反饋機制冀值，模型漂移的檢測可以實現(xiàn)持續(xù)訓練（模型漂移指的是舊的模型隨著時間的改變,在最新特征下模型的效果會越來越差）。例如宫屠，一旦模型監(jiān)控組件檢測到數(shù)據(jù)中的模型漂移列疗，信息就會被轉發(fā)到調度程序，然后調度程序觸發(fā)自動化ML工作流進行重訓練（持續(xù)訓練）浪蹂〉终唬可以使用分布比較的方法檢測已部署的模型的充分變化告材，進而識別漂移現(xiàn)象是否發(fā)生。重新訓練不僅會在達到統(tǒng)計閾值時自動觸發(fā)竭讳；它也可以在有新的特征數(shù)據(jù)可用時觸發(fā)创葡，也可以被定期安排浙踢。

六绢慢、概念化

很明顯，MLOps是機器學習洛波、軟件工程胰舆、DevOps 和數(shù)據(jù)工程的交叉領域（參見圖 5）。

圖 5. MLOps 范式的學科交叉

我們將 MLOps 定義如下：

MLOps（機器學習運維）是一種范式蹬挤，包括：最佳實踐缚窿，概念集，端到端概念化焰扳、實施倦零、監(jiān)控、部署等方面的開發(fā)文化吨悍，以及機器學習產品的可擴展性扫茅。最重要的是，它是一種利用3個學科的工程實踐：機器學習育瓜、軟件工程（尤其是 DevOps）和數(shù)據(jù)工程葫隙。MLOps旨在通過彌合開發(fā)(Dev)和運維(Ops)之間的差距來構建機器學習系統(tǒng)。從本質上講躏仇，MLOps旨在通過利用以下原則促進機器學習產品的生產：CI/CD 自動化恋脚、工作流編排、可重復性焰手；數(shù)據(jù)糟描、模型和代碼的版本控制；合作书妻；持續(xù)的機器學習訓練和評估船响；ML元數(shù)據(jù)跟蹤和記錄；持續(xù)監(jiān)控驻子；反饋回路灿意。

七、開放挑戰(zhàn)

MLOps的幾個挑戰(zhàn)被分成組織上的崇呵、機器學習系統(tǒng)的和運維的挑戰(zhàn)缤剧。

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

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

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

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

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

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

八橙凳、結論

隨著數(shù)據(jù)可用性和分析能力的提升蕾殴，以及不斷創(chuàng)新的壓力，比以往更多的機器學習產品正在被源源不斷的開發(fā)出來痕惋。但是区宇，這些概念證明中只有一小部分會進入部署和生產階段娃殖。此外值戳，學術領域專注于機器學習模型的構建和基準測試，但在現(xiàn)實世界場景中操作復雜的機器學習系統(tǒng)方面卻很少炉爆。在現(xiàn)實世界中堕虹，我們觀察到數(shù)據(jù)科學家仍在很大程度上手動管理 ML工作流。機器學習運維MLOps的范式解決了這些挑戰(zhàn)芬首。在這項工作中赴捞，我們更加了解了 MLOps。通過對現(xiàn)有文獻和工具進行混合方法研究郁稍，并采訪該領域的專家赦政，我們發(fā)現(xiàn)了 MLOps的4主要方面：原理、組件耀怜、角色和架構恢着。基于此财破，我們給出了MLOps的定義掰派，希望可以幫助大家在未來搭建成功的ML項目。