2018年，在專業界和專門針對AI的專題會議上，出現了MLOps的概念，並迅速在業界站穩腳跟，目前正在作為一個獨立的方向發展。 未來，MLOps 可能會成為 IT 中需求最大的領域之一。 它是什麼，和什麼一起吃，我們在切下了解。
什麼是 MLOps
MLOps（機器學習技術和流程的合併以及在業務流程中實施開發模型的方法）是業務代表、科學家、數學家、機器學習專家和 IT 工程師在創建人工智能係統時合作的一種新方式。
換句話說，它是一種將機器學習方法和技術轉化為解決業務問題的有用工具的方法。
必須明白，生產力鏈早在模型開發之前就開始了。 它的第一步是定義業務目標、關於可以從數據中提取的價值的假設，以及應用它的商業理念。
MLOps 的概念起源於與模型和機器學習技術相關的 DevOps 概念的類比。 DevOps 是一種軟件開發方法，它允許您提高單個更改的速度，同時使用多種方法保持靈活性和可靠性，包括持續開發、將功能分離為多個獨立的微服務、自動測試和部署單個更改、全局健康監測，檢測故障的快速響應系統等。
DevOps 定義了軟件生命週期，軟件社區中出現了將相同技術應用於大數據的想法。 DataOps 是一種調整和擴展方法論的嘗試，考慮到在各種交互平台中存儲、傳輸和處理大量數據的特殊性。
隨著嵌入企業業務流程中的一定數量的機器學習模型的出現，人們注意到機器學習數學模型的生命週期與軟件生命週期之間的強烈相似性。 唯一的區別是模型算法是使用機器學習工具和方法創建的。 因此，自然而然地產生了將已知方法應用於機器學習模型軟件開發的想法。 因此，在機器學習模型的生命週期中可以區分以下關鍵階段：
- 定義商業理念；
- 模型訓練；
- 在業務流程中測試和實施模型；
- 模型操作。
當在操作過程中需要根據新數據更改或重新訓練模型時，循環會重新開始——模型完成、測試並部署新版本。
撤退。 為什麼要再教育而不是再教育？ 術語“模型再訓練”有雙重解釋：在專家中，它意味著模型中的缺陷，當模型預測良好時，實際上在訓練集上重複預測參數，但在外部數據集上效果更差。 自然地，這樣的模型是一個缺陷，因為這個缺陷不允許它的應用。
在這個生命週期中，使用 DevOps 工具似乎合乎邏輯：自動化測試、部署和監控、將模型計算註冊為單獨的微服務。 但是有許多功能會阻止在沒有額外的 ML 綁定的情況下直接使用這些工具。
如何讓模型發揮作用並盈利
作為示例，我們將在其中演示 MLOps 方法的應用，我們將執行現在的經典任務，即為銀行（或任何其他）產品的支持聊天自動化。 典型的聊天支持業務流程如下：客戶在聊天中輸入問題，然後在預定義的對話樹中收到專家的回复。 自動化此類聊天的任務通常使用專家定義的規則集來解決，這些規則集的開發和維護非常費力。 根據任務的複雜程度，這種自動化的效率可以達到 20-30%。 自然而然地，出現了實施人工智能模塊更有益的想法 - 一種使用機器學習開發的模型：
- 能夠在沒有操作員參與的情況下處理更多的請求（根據主題，在某些情況下，效率可以達到 70-80%）；
- 更好地適應對話中的非標準措辭 - 能夠確定意圖，用戶對不明確表述的請求的真正願望；
- 能夠確定模型的答案何時足夠，以及何時對該答案的“意識”有疑問並且有必要提出額外的澄清問題或切換到操作員；
- 可以自動重新訓練（而不是一組開發人員不斷調整和糾正響應場景，模型由數據科學家使用適當的機器學習庫重新訓練）。
如何讓這樣一個先進的模型發揮作用？
與解決任何其他任務一樣，在開發此類模塊之前，有必要定義業務流程並正式描述我們將使用機器學習方法解決的特定任務。 在這一點上，由縮寫 Ops 表示的操作化過程開始了。
下一步是數據科學家與數據工程師合作，檢查數據的可用性和充分性以及關於業務創意可行性的業務假設，開發模型原型並檢查其實際有效性。 只有在業務確認後，才能開始從開發模型到將其嵌入到執行特定業務流程的系統中的過渡。 端到端的實施規劃，即在每個階段對模型將如何使用以及它將帶來什麼經濟影響的深刻理解，是將 MLOps 方法引入公司技術領域的過程中的一個基本時刻。
隨著人工智能技術的發展，借助機器學習可以解決的任務的數量和種類正在像雪崩一樣增加。 每個這樣的業務流程都通過自動化大量職位（呼叫中心、檢查和分類文件等）員工的勞動來拯救公司，它通過添加新的有吸引力和方便的功能來擴大客戶群，通過優化他們的方式節省資金資源的使用和重新分配等等。 歸根結底，任何過程都以創造價值為重點，因此必須帶來一定的經濟效益。 在這裡，清楚地闡明商業理念併計算在公司價值創造的整體結構中實施該模型的預期利潤非常重要。 在某些情況下，模型的實施並不能證明自己是正確的，機器學習專家花費的時間比執行此任務的操作員的工作場所要昂貴得多。 這就是為什麼有必要在創建人工智能係統的早期階段嘗試識別此類案例。
因此，只有在 MLOps 流程中正確制定業務任務、設置優先級以及在開發的早期階段製定將模型引入系統的流程時，模型才開始帶來利潤。
新工藝-新挑戰
對 ML 模型如何適用於解決問題這一基本業務問題的詳盡回答，對 AI 信任的一般問題是 MLOps 方法開發和實施中的主要挑戰之一。 最初，企業對將機器學習引入流程持懷疑態度——在過去人們通常工作的地方很難依賴模型。 對於企業而言，這些程序似乎是一個“黑匣子”，其答案的相關性仍有待證明。 此外，在銀行業、電信運營商等業務中，國家監管機構的要求也很嚴格。 在銀行流程中實施的所有系統和算法都要接受審計。 為了解決這個問題，向企業和監管機構證明人工智能答案的有效性和正確性，監控工具與模型一起被引入。 此外，還有一個獨立的驗證程序，對監管模型是強制性的，符合中央銀行的要求。 一個獨立的專家組在考慮輸入數據的情況下審核模型獲得的結果。
第二個挑戰是在實施機器學習模型時評估和考慮模型風險。 即使一個人不能絕對肯定地回答那件衣服是白色還是藍色的問題，人工智能也有犯錯的權利。 還值得考慮的是，數據會隨時間變化，需要重新訓練模型才能產生足夠準確的結果。 為了使業務流程不受影響，有必要管理模型風險並監控模型的性能，定期對新數據進行再培訓。
但在第一階段的不信任之後，相反的效果開始出現。 流程中成功引入的模型越多，企業對使用人工智能的興趣就越大——可以使用機器學習方法解決新的任務。 每個任務都會啟動一個需要特定能力的整個過程：
- 數據工程師準備和處理數據；
- 數據科學家應用機器學習工具並開發模型；
- IT 將模型實施到系統中；
- ML 工程師根據模型應用模式的要求，考慮請求流、響應時間等，確定如何正確地將此模型集成到流程中，使用哪些 IT 工具。
- ML 架構師設計如何在工業系統中物理實施軟件產品。
整個週期需要大量高素質的專家。 在某個發展點和 ML 模型對業務流程的滲透程度，事實證明，根據任務數量的增長線性擴展專家數量變得昂貴且低效。 因此，出現了自動化 MLOps 過程的問題 - 定義機器學習問題的幾個標準類別，開發典型的數據處理管道和再訓練模型。 在理想情況下，要解決此類問題，需要同樣精通大數據、數據科學、DevOps 和 IT 交叉能力的專業人員。 因此，數據科學行業最大的問題和組織 MLOps 流程的最大挑戰是現有培訓市場缺乏這種能力。 滿足此類要求的專家目前在勞動力市場上很少見，而且價值不菲。
關於能力問題
理論上，所有 MLOps 任務都可以使用經典的 DevOps 工具解決，而無需借助專門的角色模型擴展。 然後，正如我們上面提到的，數據科學家不僅應該是數學家和數據分析師，還應該是整個管道的大師——架構開發、根據架構使用多種語言編程模型、準備數據集市和部署落在他的肩上 應用程序本身。 然而，在端到端的 MLOps 過程中實現的技術綁定的創建佔用了高達 80% 的勞動力成本，這意味著一個合格的數學家，也就是高質量的數據科學家，只會投入 20% 的人力成本。時間到了他的專長。 因此，區分實施機器學習模型過程中專家的角色變得至關重要。
角色劃分的詳細程度取決於企業的規模。 當一家初創公司擁有一名專家、一名電力工程師後備人員、一名工程師、一名架構師和獨立的 DevOps 時，這是一回事。 當在大型企業中，所有模型開發過程都集中在少數高級數據科學家身上時，情況就完全不同了，而程序員或數據庫專家——勞動力市場上更常見、成本更低的能力——可以承擔大多數日常任務。
因此，邊界在於選擇專家以確保 MLOps 過程以及如何組織開發模型的操作過程直接影響開發模型的速度和質量、團隊的生產力和其中的小氣候。
我們的團隊已經做了什麼
我們最近開始構建能力框架和 MLOps 流程。 但是現在，我們關於管理模型生命週期和使用模型即服務的項目已經處於 MVP 測試階段。
我們還確定了大型企業的最佳能力結構以及流程中所有參與者之間互動的組織結構。 敏捷團隊的組織是為了解決所有業務客戶的問題，以及與項目團隊互動以創建平台和基礎設施的過程，這是正在建設的 MLOps 大樓的基礎。
未來的問題
MLOps 是一個不斷發展的領域，正在經歷缺乏能力的問題，但在未來會獲得發展勢頭。 同時，最好以 DevOps 的開發和實踐為基礎。 MLOps 的主要目標是更有效地使用 ML 模型來解決業務問題。 但這引發了許多問題：
- 如何減少在生產中發布模型的時間？
- 如何減少不同能力團隊之間的官僚摩擦並增加對合作的關注？
- 如何跟踪模型、管理版本和組織有效監控？
- 如何為現代 ML 模型創建真正的循環生命週期？
- 如何標準化機器學習過程？
這些問題的答案將在很大程度上決定 MLOps 發揮其全部潛力的速度。
來源： www.habr.com