部署機器學習非常困難，並將一直如此...

按：機器學習技術正在令我們的生活發生日新月異的變化。對於學術界來說，科研人員的工作往往止步於原型演算法的研製。然而，在真實的工業生產場景下，將原型機器學習演算法部署到應用程式中又是一項充滿挑戰的課題。

經手過一些人工智慧專案後，我意識到：對於希望通過人工智慧創造價值的公司來說，大規模地部署機器學習（ML）模型是最重要的挑戰之一。如今，隨著模型變得越來越複雜，這隻會變得越來越難。

根據我作為顧問的經驗，我發現只有很小一部分機器學習專案能夠被成功投入生產。人工智慧專案失敗的原因有很多，而「難以部署」就是其中之一。對於每個決策者來說，充分理解專案部署的內在機制，以及如何降低在達到這個關鍵步驟時失敗的風險是至關重要的。

我們可以將部署的模型定義為任意被無縫整合到生產環境中的程式碼單元，它可以接收輸入並返回一個輸出結果。

我所看到的是，為了使他們的工作能夠被投入生產，資料科學家通常必須將他們的資料模型的構建工作移交給工程實現部分。正是在這一步中，出現了一些最為常見的資料科學問題。

挑戰

機器學習有一些獨特的特性，使其大規模部署更加困難。這也正是我們當前正在處理的一些問題：

1、資料科學語言管理

如你所知，機器學習應用程式通常由不同程式語言編寫的元素組成，而這些元素往往不能很好地進行互動。我總是能發現類似這樣的情況：在一個機器學習應用的工作流程中，可能開始使用的是 R 語言，接著則轉而使用 Python，最終又使用了另一種語言。

一般而言，對於機器學習應用來說，Python 和 R 是目前最流行的語言。但是我注意到，出於各種原因（包括執行速度），用於生產的模型很少使用這些語言進行部署。然而，將 Python 或 R 語言編寫的模型移植到 C++ 或 Java 這種生產環境下常用的語言是十分複雜的，通常會降低原始模型的效能（執行速度、準確率，等等）。

當軟體的新版本出現時，R 的程式包很可能會崩潰。此外，R 的執行速度也很慢，無法高效處理大資料。

R 是一種很好的原型開發語言，因為它使我們可以進行簡單的互動和問題求解，但是在生產環境下則需要將其轉換為 Python、C++ 或 Java。

容器化技術（Containerization，例如 Docker），可以解決由於工具型別繁多而引發的不相容性問題和可移植性的挑戰。然而，自動依賴檢查、誤差檢查、測試以及不同的構建工具這些問題則無法跨越語言障礙得以解決。

復現性也是一個巨大的挑戰。事實上，資料科學家可以使用不同的程式語言、程式庫或同一種程式庫的不同版本來構建各個版本的模型。想要手動跟蹤這些依賴是很困難的。為了解決這些挑戰，我們需要一個機器學習生命週期工具，它可以在訓練階段自動跟蹤並且以配置程式碼的形式記錄這些依賴，然後將它們與訓練好的模型捆綁在一個待部署的元件中。

我建議你使用能夠將程式碼從一中語言即時轉換為另一種語言的工具，或者使你的資料科學團隊能夠使用某種 API 部署模型，以便這些模型在任何地方整合。

2、算力和 GPU

現代神經網路往往非常深，這意味著訓練和使用它們進行推理需要耗費大量的算力。通常，我們希望我們的演算法能夠快速執行，而這對於很多使用者來說這可能是一大障礙。

此外，現在許多生產環境下的機器學習系統都依賴於 GPU。然而，GPU 既稀缺又昂貴，這很容易使機器學習的大規模部署變得更加複雜。

3、可移植性

模型部署的另一個有趣的問題是缺乏可移植性。我注意到，這往往是歷史遺留的分析系統所造成的問題。由於沒有能力輕鬆地將軟體元件移植到另一種主機環境下並在那裡執行它，這種軟體組合可能會被限制在一個特定的平臺上。這回給資料科學家在建立和部署模型時設定障礙。

4、可擴充套件性

對於許多人工智慧專案來說，可擴充套件性是一個很現實的問題。實際上，你需要確保你的模型能夠進行擴充套件，並且滿足生產中對效能和應用程式需求的增加。在專案的開始階段，我們通常依賴於可管理規模的相對靜態的資料。隨著模型向生產環境不斷變化，它通常需要面對更大量的資料和資料傳輸模式。你的團隊將需要多種工具來監管並解決效能和可擴充套件性方面的挑戰，隨著時間的推移，這些挑戰將會顯現出來。

我相信，通過採用一致的、基於微服務的方法進行生產分析，可以解決可擴充套件性的問題。團隊應該能夠通過簡單的配置更改，快速地將模型從批處理按照需求遷移到流處理模式下。類似地，團隊應該有擴充套件計算和記憶體佔用的選項，以支援更復雜的工作負載。

5、在極限狀態下進行機器學習計算

當你的演算法被訓練好後，他們並不總是會被立刻使用，你的使用者只會在他們需要的時候呼叫這些演算法。

這意味著，也許在上午 8 點時你只要支援 100 次 API 呼叫，但是到了 8 點半這一數值猛增到了 10,000 次。

根據我的經驗，我可以告訴你，要想在確保不為你不需要的服務付費的情況下，擴大和縮減部署規模都是一個巨大的挑戰。

由於上述這些原因，只有很少的資料科學專案最終真正落地到了生產系統中。

二、提升魯棒性使模型可以執行

我們往往需要花費大量的時間試圖使我們的模型準備就緒。提升模型的魯棒性包括獲取原型並準備它，從而使它實際上能夠為所涉及的使用者服務，這通常需要大量的工作。

許多情況下，我們需要使用適合現有架構的語言重新編碼整個模型。僅這一點往往就會帶來大量痛苦的工作，導致部署工作推遲好幾個月。一旦完成，它必須被整合到公司的 IT 架構中，包括之前討論過的所有程式庫的問題。此外，在生產環境下訪問資料往往是一項困難的任務，這些資料往往承受著資料倉儲的技術上和組織上的負擔。

三、其它的挑戰

在我經手過的專案中，我還注意到以下問題：

• 如果我們改變了一個輸入特性，那麼剩餘特性的重要性、權值或用途都可能改變，也可能不改變。機器學習系統必須要被設計地能夠方便地跟蹤特性工程和選擇的變化。

• 當模型不斷地迭代並微妙地變化時，在保持配置的清晰性和靈活性的同時跟蹤配置的更新成為了一個新的負擔。

• 一些資料輸入可能會隨著時間而改變。我們需要一種方法來理解和跟蹤這些變化，以便能夠充分理解我們的系統

• 在機器學習應用程式中會出現一些傳統的單元測試/整合測試無法識別的問題。 例如，部署錯誤版本的模型，遺漏某個特徵，以及在過時的資料集上進行訓練。

四、測試和驗證的問題

正如你可能已經知道的那樣，由於資料變更、使用新的方法等原因，模型會不斷地演進。因此，每次發生這樣的變更時，我們都必須重新驗證模型的效能。這些驗證步驟帶來了如下挑戰：

• 必須使用相同的測試集和驗證集來評價模型，從而對比不同機器學習模型的效能。

• 如果我們更新了測試集和驗證集合，為了保證可比性，就需要對不同的機器學習模型重新進行評價。這使得在生產環境下自動訓練並部署新版本的機器學習模型的過程變得更加困難。

• 為了保證可比性，在不同的時間和不同的模型上，對於度量指標應該使用相同的程式碼。

• 對於某種新的模型來說，效能的提升可能也會帶來預測時間的增長。為了體現出這種影響，驗證過程應該包括基準對比測試和負載/壓力測試。
  

除了在離線測試中驗證模型之外，在生產環境下評估模型效能也十分重要。通常我們在部署策略和監管部分對此進行規劃。

機器學習模型需要比常規軟體應用更頻繁地更新。

自動化的機器學習平臺

你們可能對自動化機器學習平臺有所耳聞，這可能是用來更快地創造模型的一個很好的解決方案。此外，這樣的平臺還可以支援多個模型的開發和比較。因此企業可以選擇最適合他們對於預測準確率、計算延遲和計算資源需求的模型。

多達 90% 的企業級機器學習模型可以通過自動化的方式開發。資料科學家們可以與業務人員合作，開發目前自動化方法無法實現的小部分模型。

許多模型都會遭受「模型漂移」（效能隨著時間推移而下降）的問題。因此，我們需要對部署後的模型進行監管。每個部署後的模型應該記錄所有的輸入、輸出和異常。模型部署平臺需要提供日誌儲存和模型效能視覺化功能。密切關注模型的效能是有效管理機器學習模型生命週期的關鍵。

必須通過部署平臺監管的關鍵要素

五、釋出策略

探索各種不同的方法來部署軟體（這是一個值得長期學習的課題，可參考資料： https://medium.com/@copyconstruct/monitoring-in-the-time-of-cloud-native-c87c7a5bfa3e ），通過「影子模式」和「金絲雀模式」（注：17世紀，英國礦井工人發現，金絲雀對瓦斯這種氣體十分敏感。空氣中哪怕有極其微量的瓦斯，金絲雀也會停止歌唱；而當瓦斯含量超過一定限度時，雖然魯鈍的人類毫無察覺，金絲雀卻早已毒發身亡。當時在採礦裝置相對簡陋的條件下，工人們每次下井都會帶上一隻金絲雀作為「瓦斯檢測指標」，以便在危險狀況下緊急撤離。）部署機器學習應用程式是十分有效的。

在「影子模式」中，你可以獲知生產環境下的新模型的輸入和預測結果，而實際上並沒有基於這些預測展開服務。相反，你可以自由地分析結果，如果檢測到一個 bug 也不會造成重大的後果。

隨著架構的逐步成熟，你可以開始啟用這個漸進或「金絲雀模式」的釋出策略。在這裡，你可以向一小部分客戶釋出應用，而不是「全部都發布」或者「什麼都不釋出」。這樣做需要更成熟的工具，但是當錯誤發生時，可以將損失降到最小。

六、結語

機器學習技術方興未艾。實際上，軟體和硬體元件都在不斷地發展以滿足當前機器學習的需求。

我們可以使用「Docker/Kubernetes」和微服務架構來解決異構性和基礎環境的挑戰。現有的工具可以在很大程度上單獨解決一些問題。我相信，將所有這些工具結合起來在生產中使用機器學習是目前最大的挑戰。

部署機器學習是困難的，並將一直如此，而這正是我們需要面對的現實。值得慶幸的是，一些新的架構和產品正在成為資料科學家的「好幫手」。此外，隨著越來越多的公司擴充套件資料科學業務，它們也正在實現使得模型部署更方便的工具。

Via  https://towardsdatascience.com/why-is-machine-learning-deployment-hard-443af67493cd