MLOps是什麼
MLOps是将實驗性機器學習模型帶入生産Web系統的過程。是機器學習與DevOps在軟體領域的持續開發實踐的結合，在實驗環境下測試和開發了機器學習模型。當準備好算法時，使用MLOps将資料科學家、AI工程師、DevOp工程師工作串聯起來，将算法過渡到生産系統。MLOps尋求提高自動化程度并改善生産模型的品質，同時還要關注業務和法規要求。雖然MLOps是從一組最佳實踐開始的，但它正逐漸演變成一種獨立的ML生命周期管理方法。MLOps适用于整個機器學習生命周期：從資料分析、開發訓練、模型生成和評估、編排和部署，業務效果跟蹤。
機器學習生命周期--概念
資料分析-->算法開發-->模型訓練-->模型評估/驗證-->模型部署上線
機器學習生命周期，涵蓋從資料分析、模型開發、至模型落地部署全過程，針對已産生的模型，還會根據新的資料、知識進行疊代更新。
過程與資源
MLOps是機器學習的DevOps實作，既包含機器學習階段的資料分析、算法訓練、模型評估等環節，也包含軟體工程階段的CI/CD、運維監控、性能調優等環節。此過程會有多個角色參與協助實作。
導讀《再談MLOps，為企業注入新的競争力》
參與角色
一個完整的項目研發實施，需要不同角色的人員配合完成
項目成本
從以上分析可以看出，生産一個模型，隻是整個機器學習項目漫長過程的第一步，許多組織低估了将機器學習投入生産所需的工作量，導緻整個項目半途而廢（據統計75%的ml實驗項目從未進入生産階段，這個比例甚至會更高），其消耗的資源和時間遠超預期。
MLOps
MLOps專注于資料科學、機器學習工程與現有DevOps實踐的結合，以降低整個機器學習開發生命周期（MLDC）的模型傳遞難度。
面臨的幾個階段：
1）企業或團隊在投入機器學習初期，機器學習過程通常采用一些手動的方式來完成。
缺少ML項目協作經驗
缺少ML資産管理與共享機制
落地方案不明确、不清晰
項目周期預估偏差較大
2）随着項目的推進，與經驗的積累，企業和團隊逐漸建立良好的協作開發模式，采用更多自動化的方式應用到項目當中。
自動化資料，訓練和部署管道。
減少手動交接的次數
環境資源隔離、保障資料安全
3）可靠性優化，為生産提供更成熟的MLOps方案
将更進階别的MLOps實踐（例如CI / CD）與以下功能內建：基礎配置，實驗代碼，推理代碼，資料，模型實作版本控制，端到端可追溯性（即管道可追溯性）
自動化品質評測
持續監控對業務結果的影響，模型監控（例如，資料漂移，延遲）和系統監控
内置持續回報機制，用于模型性能和再訓練。
建構靈活的管道以支援進階部署方案，例如A / B測試，推理管道和多模型端點
自動化生成可使用的API
保障實驗和部署環境的可持續監控
建立項目管理機制
結合前面介紹，回顧一下定義，MLOps專注于資料科學、機器學習工程與DevOps實踐的結合，以降低整個機器學習開發生命周期（MLDC）的模型傳遞難度。
如何确定什麼時候開始MLOps
模型開發全靠手動
機器學習為您的系統提供了從資料中學習和改進的能力，在這裡您不需要對所有的過程進行重複程式設計。在使用機器學習時，你訓練和測試模型的方式非常重要，即使是微小的訓練變化也會導緻預測的不一緻。是以，最重要的是記錄你如何收集使用的資料，如何對資料進行預處理，使用什麼參數等等。MLOps平台的好處是，它們将這些步驟整齊地打包成了程式化的機器學習管道，是可以自我記錄的。
如果都是手動完成的話：訓練模型的過程越複雜，就越難讓新的團隊成員上崗處理。MLOps平台大大減少了教育訓練新人以保持生産模型更新的時間。
它不僅可以讓你的團隊内部更好地溝通，而且還可以幫助其他團隊，因為他們可以獨立審查你建立的模組化管道--而不是觀察手動工作流程。MLOps打開了生産力瓶頸，減少了在你的生産模型上工作的不同小組之間的摩擦。同樣，當你在處理複雜的機器學習系統時，你會發現它特别有用。
項目交接困難
當同僚離開團隊時，手動和無記錄的工作流程會帶來巨大的風險，導緻知識丢失。MLOps從外部和内部守護和保護您的企業利益，以防止與人員流動有關的損失。
如果您在 MLOps 的最佳實踐中工作，您的代碼和資料始終是版本化的，并且您的生産模型可以追溯到它們是如何産生的（即中繼資料）。理想情況下，你的整個模型訓練過程是元件化的，并建立在一個管道中，在你的團隊中共享所有權。對比我們經常聽到的恐怖故事—所有的模型資料都在本地機器上的一個筆記本裡。
圍繞機器學習流水線工作還有助于将測試正規化，并設定基準，以確定生産模型的品質不會在工作變化時降低。為生産模型設定監控和警報也是如此。
模型更新維護困難
更新生産的原因有很多。最常見的原因是，由于底層資料的變化，您的生産模型所服務的預測不再準确。例如，新聞周期已經下線或過期，你的新聞推薦引擎不再提供有價值的推薦。另一個原因可能是你進一步優化了你的代碼，并希望釋出這些新功能。
無論哪種情況，更新模型都是一項漫長而繁瑣的任務，因為模型的訓練可能需要幾分鐘到幾周的時間。我們經常看到，重新訓練一個模型成為那些以臨時方式圍繞機器學習工作的團隊的救火工作。
最初，模型可以建立在資料科學家的本地機器上，但随着模型的成熟和資料的積累，訓練必須轉移到雲機器上。這又涉及到更多的人參與到運維雲機的工作中來（希望在模型訓練完成後将其關閉）。此外，雲環境與本地機器不同，需要DevOps知識将正确的依賴項打包到Docker容器或隔離環境中，以便訓練和部署運作。
如果沒有MLOps平台，每次重新訓練模型時都會發生這種麻煩。一個受管理的MLOps平台可以減少--如果不是消除--與機器協調、依賴性管理和擴充相關的消防工作，這意味着你的團隊可以更新舊模型和開發模型，而不需要更多的DevOps資源。
此外，MLOps平台一般都有API。您的模型訓練管道可以與現有系統內建，以避免手動啟動訓練過程或移交檔案。例如，您的資料湖中的新資料可以觸發再訓練，訓練後的模型可以推送到您的終端使用者應用程式的CI/CD。
模型效果無法跟蹤
如果你沒有使用任何MLOps系統，你将無法看到生産模型的表現。對于生産模型來說，對請求數、延遲和正常運作時間的标準監控相當普遍，但我們看到一個新的趨勢出現了。機器學習的可觀察性是現在最流行的，我們看到很多新進入市場的公司，比如Arize AI和Fiddler，他們都在關注這個問題。它不僅是關于測量資料漂移的總量，而且是關于你所服務的預測中的離群值，并弄清楚你的模型是否偏向于某個特定的使用者群體。
一個MLOps平台可能會給你提供一些開箱即用的監控功能，但更重要的是它應該能夠與更先進的監控和可觀察性工具內建，以滿足你的需求。這些工具應該能夠自動向您發出警報，并在您的MLOps平台中觸發再訓練和重新部署，以確定您始終為最佳預測服務。
其實從最開始的調查中就可以發現，在ML項目初期，就需要同時考慮MLOps，也就是越早開始越好。
如何開始MLOps實踐
自研MLOps能力
将成熟的MLOps工具內建至内部系統
使用第三方MLOps平台
一些公司，在項目中會結合自身需求，自研MLOps工具集，而完成這項工作，需要投入額外的資源和精力。随着MLOps生态的不斷發展，産生了有許多優秀的開源工具，基于和借鑒開源的産品實作内部閉源的需求是一個不錯的選擇。當然如果想要快速獲得MLOps的體驗與使用，業界也有許多成熟的MLOps産品，可提供商業使用版本。
下面是一張AI技術生态圖譜可供參考（https://landscape.lfai.foundation/）
MLOps産品
目前業界已有不少成熟的MLOps産品和工具，可以作為參考或引入至自己的MLOps項目中使用。
MLOps産品對比（省略了部分相似産品）：
想要獲得MLOps能力，并不是一蹴而就，而需要結合實際，逐漸建設和完善。
準備工作：
0）獲得組織或上司的支援；
1）進行内部調研，發現團隊成員在機器學習過程中的痛點；
2）綜合調查評估：團隊規模、使用範圍、項目價值等等；
3）了解已具備哪些資源：很多公司或團隊已經有相應的DevOps或MLOps實踐，比如開發工具、持續內建工具、版本庫等等；
4）還需引入哪些新的技術和工具：結合MLOps技術棧圖譜進行評估；
5）設計可實施技術方案；
7）制定計劃并持續推進。
MLOps項目路線圖
本文作者:CIO之家的朋友 來源:火龍果
CIO之家 www.ciozj.com 微信公衆号:imciow