導讀

根據我作為顧問的經驗，只有非常少的機器學習項目能夠投入生產。一個人工智能項目可能會因為多種原因而失敗，其中之一就是部署。

在做了幾個人工智能項目之后，我意識到，對于那些愿意通過人工智能創造價值的公司來說，大規模部署機器學習(ML)模型是最重要的挑戰之一。

根據我作為顧問的經驗，只有非常少的機器學習項目能夠投入生產。一個人工智能項目可能會因為多種原因而失敗，其中之一就是部署。對于每個決策者來說，完全理解部署是如何工作的，以及在達到這一關鍵步驟時如何降低失敗的風險是非常關鍵的。

部署的模型可以定義為無縫集成到生產環境中的任何代碼單元，并且可以接收輸入并返回輸出。

我曾經看到，為了將他們的工作投入生產，數據科學家通常必須將他或她的數據模型進行工程實現。在這一步中，出現了一些最常見的數據科學問題。

挑戰

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

管理數據科學語言

你可能知道，機器學習應用程序通常由使用不同的編程語言編寫組成。它們之間的相互作用并不是很好。我曾多次看到，機器學習pipeline從R開始，在Python中繼續，并以另一種語言結束。

一般來說，Python和R是機器學習應用程序中最流行的語言，但我注意到，由于各種原因(包括速度)，很少使用這些語言部署生產模型。將Python或R模型移植到像c++或Java這樣的生產語言中是很復雜的，并且通常會降低原始模型的性能(速度、準確性等)。

當軟件的新版本發布時，R包可能會崩潰。此外，R速度慢，無法高效地處理大數據。

對于原型設計來說，它是一種很棒的語言，因為它允許簡單的交互和解決問題，但是需要將它翻譯成Python或c++或Java來進行生產。

諸如Docker之類的容器化技術可以解決由大量工具引入的不兼容性和可移植性挑戰。然而，自動依賴項檢查、錯誤檢查、測試和構建工具將不能解決跨越語言障礙的問題。

可復現性也是一個挑戰。實際上，數據科學家可以使用不同的編程語言、庫或同一庫的不同版本來構建模型的多個版本。手動跟蹤這些依賴關系很困難。為了解決這些挑戰，需要一個機器學習生命周期工具，它可以在訓練階段自動跟蹤并記錄這些依賴項，并將它們作為代碼的配置，然后將它們與訓練的模型一起打包到一個隨時可以部署的工件中。

我建議你使用一種工具或平臺，它可以立即將代碼從一種語言轉換為另一種語言，或者允許你的數據科學團隊在API背后部署模型，以便在任何地方集成它們。

計算能力和GPU

神經網絡通常會非常深，這意味著訓練和使用它們進行推理需要大量的計算能力。通常，我們希望我們的算法運行得更快，對于很多用戶來說，這可能是一個障礙。

此外，現在許多生產上的機器學習都依賴于GPU。然而，它們既稀缺又昂貴，這很容易給機器學習的擴展任務增加另一層復雜性。

可移植性

模型部署的另一個有趣的挑戰是缺乏可移植性。我注意到這通常是遺留分析系統的問題。由于缺乏將軟件組件輕松遷移到另一個主機環境并在那里運行的能力，組件可能會被鎖定在特定的平臺上。這可能為數據科學家在創建和部署模型時制造障礙。

可擴展性

對于許多AI項目來說，可擴展性是一個真正的問題。實際上，你需要確保你的模型能夠擴展并滿足生產中性能和應用程序需求的增長。在項目開始時，我們通常依賴于可管理范圍內的相對靜態數據。隨著模型進入生產環境，它通常會接觸到大量的數據和數據傳輸模式。你的團隊將需要一些工具來監視和解決性能和可擴展性方面的問題，這些問題將隨著時間的推移而出現。

我認為，可擴展性問題可以通過采用一致的、基于微服務的方法來進行生產分析來解決。團隊應該能夠通過簡單的配置更改快速地將模型從批處理遷移到隨需應變的流處理。類似地，團隊應該有擴展計算和內存占用的選項，以支持更復雜的工作負載。

機器學習峰值計算

一旦你的算法被訓練好了，它們并不是時時刻刻被使用——你的用戶只會在需要的時候調用它們。

這可能意味著你只需要支持上午8:00時的100個API調用，而在8:30時需要支持10,000個API調用。

根據我的經驗，我可以告訴你，使用動態擴大或縮小你的服務來確保不為你不需要的服務器付費是一個挑戰

由于所有這些原因，只有少數數據科學項目最終真正進入生產系統。

模型的穩定和魯棒

我們總是花很多時間準備模型。我們需要把原型變得穩定和魯棒，這樣它就可以實際服務于大量的用戶，這通常需要大量的工作。

在許多情況下，整個模型需要用一種適合體系結構的語言重新編碼。僅這一點往往就會導致大量痛苦的工作，從而導致幾個月的部署延遲。完成之后，必須將其集成到公司的IT體系結構中，包括前面討論的所有庫問題。此外，在生產環境中訪問數據也常常是一項困難的任務。

更多的挑戰

在做項目的過程中，我也注意到了以下問題:

如果我們改變了一個輸入特征，那么其余特征的重要性、權重或使用可能也會改變。機器系統必須設計得易于跟蹤特征工程和選擇更改。

當模型被不斷迭代和微妙地改變時，跟蹤配置更新同時保持配置的清晰性和靈活性將成為額外的負擔。

有些數據輸入可能隨時間而改變。我們需要一種方法來理解和跟蹤這些變化，以便能夠完全理解我們的系統。

在機器學習應用程序中會出現一些傳統的單元/集成測試無法識別的錯誤。部署錯誤的模型版本、忘記某個特征以及在過時的數據集上進行訓練只是其中的幾個例子。

測試和驗證的問題

正如你可能已經知道的，模型由于數據更改、新方法等而不斷發展。因此，每次發生這樣的變化時，我們都必須重新驗證模型的性能。這些驗證步驟引入了幾個挑戰：

除了在離線測試中驗證模型外，評估生產模型的性能也非常重要。通常，我們在部署策略和監視部分對此進行規劃。

與常規軟件應用程序相比，機器學習模型需要更頻繁地更新。

自動化機器學習平臺

有些人可能聽說過自動化機器學習平臺。這可能是一個快速生成模型的好方法。此外，該平臺可以支持多個模型的開發和比較，因此企業可以選擇最適合其預測準確性、延遲和計算資源需求的模型。

多達90%的企業機器學習模型可以自動開發。數據科學家可以與業務人員合作，開發目前自動化無法實現的一小部分模型

許多模型經歷了漂移(性能隨時間降低)。因此，需要監視已部署的模型。每個部署的模型都應該記錄所有的輸入、輸出和異常。模型部署平臺需要提供日志存儲和模型性能可視化。密切關注模型性能是有效管理機器學習模型生命周期的關鍵。

必須通過部署平臺監視的關鍵元素

發布策略

探索許多不同的方式來部署你的軟件，“shadow mode”和“Canary”部署對機器學習應用程序特別有用。在“shadow mode”中，你捕獲生產中新模型的輸入和預測，而實際上并不服務于這些預測。相反，你可以自由地分析結果，如果檢測到錯誤，則不會產生重大后果。

當你的體系結構成熟時，請考慮啟用漸進的或“Canary”版本。這種做法是指你可以向一小部分客戶發布產品，而不是“要么全部發布，要么什么都不發布”。這需要更成熟的工具，但它可以最小化錯誤。

總結

機器學習仍處于初級階段。實際上，軟件和硬件組件都在不斷發展，以滿足機器學習的當前需求。

Docker/Kubernetes和微服務體系結構可以用來解決異構性和基礎設施方面的挑戰。現有的工具可以單獨地極大地解決一些問題。我認為，將所有這些工具結合起來以使ML運作化是當今最大的挑戰。

部署機器學習是并且將繼續是困難的，這只是組織將需要處理的一個現實。值得慶幸的是，一些新的架構和產品正在幫助數據科學家。此外，隨著越來越多的公司擴展數據科學操作，他們也在實現使模型部署更容易的工具。