機器學習運維(MLOps)：原理、組件、角色和架構

• 2022 年 8 月 16 日
• AI
• 強化學習, 深度學習

機器學習運維(MLOps)：原理、組件、角色和架構

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

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

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

時間：2022年5月

摘要

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

一、簡介

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

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

RQ：什麼是 MLOps？

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

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

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

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

(d) 推導出一個ML 系統設計的通用架構。

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

通過這樣做，我們希望為專業人士和研究人員提供明確的指導方針，對學術和實踐討論產生積極影響，並承擔明確的責任。這些見解可以通過減少系統設計中的錯誤，並最終在現實世界環境中實現更可靠的預測，從而有助於將更多的概念證明投入生產。

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

二、DevOps的基礎

過去，軟件工程領域出現了不同的軟件開發過程模型和開發方法。突出的例子包括瀑布模型和敏捷宣言。這些方法具有相似的目標，即交付可量產的軟件產品。 2008/2009 年出現了一個名為「DevOps」的概念，旨在減少軟件開發中的問題。DevOps 不僅僅是一種純粹的方法，而是代表了解決從事軟件開發的組織中的社會和技術問題的範式。它的目標是消除開發和運維之間的差距，並強調協作、溝通和知識共享。它通過持續集成、持續交付和持續部署 (CI/CD) 確保自動化，從而實現快速、頻繁和可靠地發佈。此外，它旨在確保持續測試、質量保證、持續監控、日誌記錄和反饋循環。由於 DevOps 的商業化，許多 DevOps 工具不斷湧現，可分為六類：協作和知識共享（例如 Slack、Trello、GitLab wiki）、源代碼管理（例如 GitHub、GitLab )、構建過程（例如 Maven）、持續集成（例如 Jenkins、GitLab CI）、部署自動化（例如 Kubernetes、Docker）、監控和日誌記錄（例如 Prometheus、Logstash）。雲環境越來越多地配備了專為雲使用而設計的即用型 DevOps 工具，從而促進了價值的高效生成 [38]。隨着向DevOps這種新穎範式的轉變，開發人員需要關心他們開發的內容，因為他們也需要操作它。正如實證結果所表明的那樣，DevOps 確保了更好的軟件質量。業內人士以及學術界人士通過使用 DevOps獲得了豐富的軟件工程方面的經驗。這種經驗現在被用於ML自動化和運維。

三、方法論

為了從學術知識庫中獲得見解，同時也利用該領域從業者的專業知識，我們採用混合方法方法，如圖 1 所示。作為第一步，我們進行結構化文獻綜述以獲得相關研究的概述。此外，我們回顧了 MLOps 領域的相關工具支持，以更好地了解所涉及的技術組件。最後，我們與來自不同領域的專家進行半結構式訪談（半結構式訪談：事先有一定的題目和假設，但實際問題沒有具體化。其優缺點介於結構式訪談和非結構式訪談之間）。在此基礎上，我們將「MLOps」一詞概念化，並在下一節（「結果」）中通過綜合文獻和訪談來詳細說明我們的發現。

3.1 文獻回顧

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

3.2 工具回顧

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

3.3 訪談研究

為了從實踐中獲得洞察力來回答研究問題，我們進行了半結構式的專家訪談。我們應用了一種理論抽樣方法，這使我們能夠選擇有經驗的採訪夥伴來獲得高質量的數據。這些數據可以通過有限數量的訪談提供有意義的見解。為了獲得足夠的樣本組和可靠的見解，我們使用 LinkedIn（一個面向專業人士的社交網絡）來識別在全球範圍內具有深厚 MLOps 知識的經驗豐富的 ML 專業人士。為了從不同的角度獲得見解，我們選擇了來自不同組織和行業、不同國家和民族以及不同性別的面試夥伴。進行訪談，直到在數據分析中沒有出現新的類別和概念。

四、結果

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

4.1 原則 

原則被視為普遍或基本的真理、價值或行為指南。在 MLOps 的背景下，原則是如何在 MLOps 中實現事物的指南，並且與專業領域的「最佳實踐」一詞密切相關。根據概述的方法，我們確定了實現 MLOps 所需的九項原則。圖 2 提供了這些原則的說明，並將它們鏈接到與其相關聯的組件。 

原則1：CI/CD 自動化 

CI/CD 自動化地提供持續集成、持續交付和持續部署。它執行構建、測試、交付和部署步驟。它向開發人員提供有關某些步驟的成功或失敗的快速反饋，從而提高整體生產力。

原則2：工作流程編排

工作流編排根據有向無環圖 (DAG) 協調 ML 工作流管道的任務。 DAG 通過考慮關係和依賴關係來定義任務執行順序。

原則3：可復現性

可復現性是重現 ML 實驗並獲得完全相同結果的能力。

原則4：版本控制

版本控制確保數據、模型和代碼的版本控制不僅可以實現可復現性，還可以實現可追溯性（出於合規性和審計原因）。

原則5：協作

協作確保了在數據、模型和代碼上進行協作的可能性。除了技術方面，該原則強調協作和交流的工作文化，旨在減少不同角色之間的領域孤島。

原則6：持續 ML 訓練和評估

持續訓練意味着基於新的特徵數據定期重新訓練 ML 模型。通過監控組件、反饋循環和自動化 ML 工作流的支持，可以實現持續訓練。持續訓練的過程總是會伴隨着評估的運行，以評估模型質量的變化。

原則7：ML 元數據跟蹤/記錄

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

原則8：持續監測

持續監控意味着對數據、模型、代碼、基礎設施資源和模型服務性能（例如預測準確性）進行定期評估，以檢測影響產品質量的潛在錯誤或變化。

原則9：反饋迴路

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

4.2 技術組件

在確定需要納入 MLOps 的原則之後，我們現在詳細說明精確的組件並在 ML 系統設計中實現它們。在下文中，以通用方式列出並描述了這些組件及其基本功能。

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

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

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

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

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

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

組件4：特徵平台系統（原則3、4）

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

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

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

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

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

組件7：ML 元數據存儲（P4、P7）

ML 元數據存儲允許跟蹤各種元數據，例如，針對每個編排的 ML 工作流任務。可以在模型註冊表中配置另一個元數據存儲，用於跟蹤和記錄每個訓練工作的元數據（例如，訓練日期和時間、持續時間等），包括模型特定的元數據——例如，使用的參數和生成的性能指標，模型沿襲：使用的數據和代碼。示例包括具有內置元數據存儲的編排器，可跟蹤實驗流程的每個步驟，例如 Kubeflow Pipelines、AWS SageMaker Pipelines、Azure ML 和 IBM Watson Studio。MLflow 結合模型註冊表提供了高級元數據存儲。

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

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

組件9：監控組件（原則8、9）

監控組件負責持續監控模型服務性能（例如預測準確性）。此外，還需要監控 ML 基礎設施、CI/CD 和編製。示例包括帶有 Grafana的 Prometheus、ELK 堆棧（Elasticsearch、Logstash 和 Kibana）和簡單的TensorBoard。具有內置監控功能的示例包括 Kubeflow、MLflow和 AWS SageMaker模型監控器或雲觀察。

4.3 角色

在描述了組件的原理及其產生的實例化之後，我們確定了必要的角色，以便接下來實現 MLOps。 MLOps 是一個跨學科的小組過程，不同角色的相互作用對於在生產中設計、管理、自動化以及運維ML 系統至關重要。下面簡要介紹每個角色及其目的和相關任務：

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

業務利益相關者定義了要使用 ML 實現的業務目標，並負責業務層面的溝通，例如展示 ML 產品產生的投資回報 (ROI)。

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

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

角色3：數據科學家（類似角色：ML 專家、ML 開發人員）

數據科學家將業務問題轉換為 ML 問題並負責模型工程，包括選擇性能最佳的算法和超參數。

角色4：數據工程師（類似角色：DataOps工程師）

數據工程師建立並管理數據及特徵工程管道。此外，此角色可確保將正確的數據存儲到特徵憑條系統的數據庫中。

角色5：軟件工程師

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

角色6：開發運維工程師

DevOps工程師彌補了開發和運維之間的差距，並確保適當的 CI/CD 自動化、ML 工作流編排、模型部署到生產和監控。

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

ML 工程師或 MLOps 工程師結合了多個角色的各個方面，因此具有具備跨領域的知識。該角色融合了數據科學家、數據工程師、軟件工程師、DevOps工程師和後端工程師的技能（參見圖 3）。這個跨領域的角色建立和運營 ML 基礎設施，管理自動化的ML工作流和模型部署到生產，並監控模型和 ML 基礎設施。

五、架構和工作流程

在確定的原則、組件和角色的基礎上，我們推導出一個通用的 MLOps 端到端架構，為 ML 研究人員和從業者提供適當的指導，如圖 4 所示。此外，我們還描述了工作流，即不同任務在不同階段執行的順序。因此，機器學習研究人員和從業者可以選擇最適合他們需求的技術和框架。

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

(A) MLOps項目啟動步驟；

(B) 特徵工程流水線，包括特徵平台的數據攝取；

(C) 實驗；

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

(A) MLOps項目啟動

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

(2) 解決方案架構師(角色2)定義整個 ML 系統的架構設計，並在全面評估後決定要使用的技術；

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

(4) 數據工程師(角色4)和數據科學家(角色3)齊心協力，梳理解決這個問題需要哪些數據； (5) 明確答案後，數據工程師(角色4)和數據科學家(角色3)將協作定位原始數據源，以進行初始數據分析。他們檢查數據的分佈和質量，並執行驗證檢查。此外，他們確保來自數據源的數據被打上標籤，這意味着目標屬性是已知的，因為這是監督機器學習的強制性要求。在此示例中，數據源已經具有可用的標記數據，因為標記步驟在上游過程中被覆蓋。

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

特徵是模型訓練所需的相關屬性。在初步了解原始數據和初步數據分析後，定義特徵工程流水線的基本要求如下：

(6) 數據工程師(角色4)定義數據轉換規則（規範化、聚合）和清洗規則，將數據轉換為可用的格式；

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

(B2) 特徵工程流水線

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

(8) 首先，特徵工程流水線連接到原始數據，例如可以是流數據、靜態批處理數據或來自任何雲存儲的數據；

(9) 數據將從數據源中提取；

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

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

(12) 最後，將批量或流式數據加載到特徵平台系統(組件4)中。目標是離線或在線數據庫（或任何類型的數據存儲）。

（C）實驗

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

(13) 數據科學家(角色3)通過特徵平台系統(組件4)進行數據分析。或者，數據科學家也可以通過原始數據進行初步分析。如果需要進行任何數據調整，數據科學家會將所需的更改報告回數據工程區（反饋循環）；

(14) 然後，需要對來自特徵平台系統的數據進行準備和驗證。此任務還包括創建訓練和測試數據集；

(15) 數據科學家(角色3)估計性能最佳的算法和超參數，然後用訓練數據(組件5)觸發模型訓練。軟件工程師(角色5)支持數據科學家(角色3)創建精心設計的模型訓練代碼；

(16) 在多輪模型訓練中，對不同的模型參數進行交叉測試和驗證。一旦性能指標表明結果良好，迭代訓練就會停止。性能最佳的模型參數是通過參數調整來確定的。然後重複迭代模型訓練任務和模型驗證任務；這些任務一起可以稱為「模型工程」。模型工程旨在確定模型的最佳性能算法和超參數；

(17) 數據科學家(角色3)導出模型並將代碼提交到倉庫。

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

（D）自動化 ML工作流

DevOps工程師和 ML工程師負責管理自動化的 ML 工作流。他們還以硬件資源和支持計算框架（如 Kubernetes）的形式管理底層模型訓練基礎設施。工作流編排組件編排自動化 ML 工作流的任務。對於每個任務，從工件存儲（例如圖像註冊表）中提取所需的工件（例如圖像）。每個任務都可以通過一個隔離的環境（例如容器）執行。最後，工作流編排組件以日誌、完成時間等形式為每個任務收集元數據。

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

(18) 從特徵平台系統中自動提取版本化的特徵（數據提取）。根據用例，從離線或在線數據庫（或任何類型的數據存儲）中提取特徵；

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

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

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

(22) 然後，訓練後的模型被導出並推送到模型註冊表，在那裡它被存儲為代碼或與其相關的配置和環境文件一起容器化。

對於所有訓練任務迭代，ML元數據存儲記錄元數據，例如用於訓練模型的參數和生成的性能指標。這還包括跟蹤和記錄訓練任務ID、訓練日期和時間、持續時間以及工件來源。此外，為每個新註冊的模型跟蹤模型特定元數據（也稱為「模型沿襲」），該元數據結合了數據和代碼的沿襲，這包括用於訓練模型的特徵數據和模型訓練代碼的來源和版本。此外，還會記錄模型版本和狀態（例如暫存或生產就緒）。

一旦一個表現良好的模型從暫存狀態切換到生產狀態，它就會自動移交給 DevOps工程師或 ML工程師進行模型部署。從那裡，CI/CD 組件觸發持續部署流程。生產就緒的 ML模型和模型服務代碼被拉取（最初由軟件工程師準備）。持續部署流程執行 ML模型和服務代碼的構建和測試步驟，並將模型部署到生產服務；

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

(26) 監控組件 (組件9) 持續實時觀察模型服務性能和基礎設施。一旦達到某個閾值，例如檢測到預測精度較低，信息就會通過反饋迴路轉發。反饋迴路連接到監控組件並確保快速和直接的反饋，從而實現更穩健和更好的預測。它支持持續訓練、重新訓練和改進。在反饋迴路的支持下，信息從模型監控組件傳遞到多個上游接收點，例如實驗階段、數據工程區和調度器（觸發器）。數據科學家將反饋到實驗階段，以進一步改進模型。對數據工程區的反饋允許調整為特徵平台系統準備的特徵。此外，作為反饋機制，模型漂移的檢測可以實現持續訓練（模型漂移指的是舊的模型隨着時間的改變,在最新特徵下模型的效果會越來越差）。例如，一旦模型監控組件檢測到數據中的模型漂移，信息就會被轉發到調度程序，然後調度程序觸發自動化ML工作流進行重訓練（持續訓練）。可以使用分佈比較的方法檢測已部署的模型的充分變化，進而識別漂移現象是否發生。重新訓練不僅會在達到統計閾值時自動觸發；它也可以在有新的特徵數據可用時觸發，也可以被定期安排。

六、概念化

很明顯，MLOps是機器學習、軟件工程、DevOps 和數據工程的交叉領域（參見圖 5）。

我們將 MLOps 定義如下：

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

七、開放挑戰 

MLOps的幾個挑戰被分成組織上的、機器學習系統的和運維的挑戰。

（1）組織挑戰

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

（2）機器學習系統挑戰

MLOps系統的一個主要挑戰是針對波動的需求進行設計，特別是與 ML 訓練過程相關的。這源於潛在的大量和變化的數據，這使得精確估計必要的基礎設施資源（CPU、RAM 和 GPU）變得困難，並且在基礎設施的可擴展性方面需要高度的靈活性。

（3）運營挑戰

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

八、結論

隨着數據可用性和分析能力的提升，以及不斷創新的壓力，比以往更多的機器學習產品正在被源源不斷的開發出來。但是，這些概念證明中只有一小部分會進入部署和生產階段。此外，學術領域專註於機器學習模型的構建和基準測試，但在現實世界場景中操作複雜的機器學習系統方面卻很少。在現實世界中，我們觀察到數據科學家仍在很大程度上手動管理 ML工作流。機器學習運維MLOps的範式解決了這些挑戰。在這項工作中，我們更加了解了 MLOps。通過對現有文獻和工具進行混合方法研究，並採訪該領域的專家，我們發現了 MLOps的4主要方面：原理、組件、角色和架構。基於此，我們給出了MLOps的定義，希望可以幫助大家在未來搭建成功的ML項目。