譯者| 崔皓
審校| 孫淑娟
#開篇
##一般而言，企業不會主動建構自有的雲端運算基礎設施是有原因的。過去十年，IT 基礎架構團隊試圖建立自己的私有雲，因為他們認為與公有雲相比，私有雲會以性價比更高的方式支撐他們的業務。但事與願違，最終花在私有雲上的時間和成本都超過了預期，建成私有雲以後反而需要更多的資源來對其進行維護，並且在安全和擴展方面都比公有雲略遜一籌。這導致那些自建私有雲的企業最終沒有更多的資源投資於核心業務，而是將大量的時間和人員投入到無法擴展業務需求的基礎設施上。
現在，許多企業透過各種開源工具（如 Apache Spark）產生解決方案，但對於 MLOps 的大多數行為都需要重複地手動操作。
這會導致模型部署需要數週甚至數月的時間、低效的運行時間（透過計算和所需時間運行的推理來衡量），同時也缺乏對模型測試和監控的觀察。並且，所用方法過於客製化，無法為企業的不同部門的多個用例提供可擴展、可重複使用的業務流程。
誤診問題的案例
此外，透過與業務線負責人、首席資料分析官的對話得出這樣的結論，雖然組織僱用了很多的資料科學家，但並沒有看到任何回報。隨著研究的深入，他們會不斷提出各種問題，透過這些問題去辨識人工智慧面臨的困難和障礙。他們很快意識到關鍵問題在「最後一哩路」——部署模型並應用於即時數據，有效地執行它們，這樣一來才能使收益大於成本，從而更好地衡量其效能。
為了解決業務問題和製定業務決策，資料科學家將資料轉化為模型。這個過程需要兩類技能的支持，一類是，建立出色模型所需的專業知識和技能；其二是，使用程式碼在現實世界中推動模型，同時監控和更新模型的技能。然而這兩類技能卻完全不同。
正因為這種差異就有了ML 工程師的用武之地。 ML 工程師負責將工具和框架進行集成，以確保資料、管道和基礎設施協同工作，在此前提下大規模生產 ML 模型。
那麼，現在怎麼辦？僱用更多的機器學習工程師？
即使擁有最好的ML 工程師，企業在擴展AI 時仍面臨兩個主要問題：
無法快速僱用ML 工程師：對ML 工程師的需求變得非常強烈，ML 工程師的職缺成長速度比IT 服務成長的速度快了 30 倍。有時需要等待數月甚至數年來填補職位空缺，由此MLOps 團隊需要找到一種高效的方式來支持更多的 ML 模型和用例，而無需通過增加 ML 工程師的人數來滿足對ML應用的需求。但這項措施又會帶來了第二個瓶頸…- 無論在何處以及如何建立模型，都缺乏部署模型的可重複、可擴展的最佳實踐：現代企業資料生態系統的現狀是，不同的業務部門根據數據和技術的要求會使用不同的數據平台（例如，產品團隊可能需要支援流數據，而財務需要為非技術用戶提供簡單的查詢介面）。此外，數據科學還需要將應用分散到各個業務部門而不是集中應用。換句話說，不同的資料科學團隊中針對他們關注的用例（領域）都有一套特有的模型訓練框架，這意味著一刀切的訓練框架針對整個企業（包含多個部門/領域）而言是無法成立的。
-
如何從人工智慧中獲得最大價值
為了提高自動化能力；為了提供大規模的用戶個人化體驗；為了兌現更準確、更精細、可預測的用戶承諾，企業已經在人工智慧投入了數十億美元。但到目前為止，人工智慧的承諾和結果之間存在著巨大差距，只有大約 10%的人工智慧投資產生了可觀的投資報酬率。
最後，為了解決 MLOps 問題，首席資料分析長需要圍繞業務核心的資料科學來建立自己的能力，同時也要投資其他的與 MLOps自動化相關的技術。這是常見的「建構與購買」困境，不僅從營運的角度（成本效益）去考量，更需要考慮人工智慧投資在整個企業中滲透的速度和效率，以及是否透過更好的方式產生新的收入產品和客戶群，或透過提高自動化程度和減少浪費來削減成本。
譯者介紹
崔皓，51CTO社群編輯，資深架構師，擁有18年的軟體開發與架構經驗，10年分散式架構經驗。曾任惠普技術專家。樂於分享，寫了許多熱門科技文章，閱讀量超過60萬。 《分散式架構原理與實務》作者。
原文標題：MLOps | Is the Enterprise Repeating the Same DIY Mistakes?
以上是MLOps：企業是否在重複同樣的 DIY 錯誤？的詳細內容。更多資訊請關注PHP中文網其他相關文章！
