導(dǎo)讀

根據(jù)我作為顧問的經(jīng)驗，只有非常少的機(jī)器學(xué)習(xí)項目能夠投入生產(chǎn)。一個人工智能項目可能會因為多種原因而失敗，其中之一就是部署。

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

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

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

我曾經(jīng)看到，為了將他們的工作投入生產(chǎn)，數(shù)據(jù)科學(xué)家通常必須將他或她的數(shù)據(jù)模型進(jìn)行工程實現(xiàn)。在這一步中，出現(xiàn)了一些最常見的數(shù)據(jù)科學(xué)問題。

挑戰(zhàn)

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

管理數(shù)據(jù)科學(xué)語言

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

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

當(dāng)軟件的新版本發(fā)布時，R包可能會崩潰。此外，R速度慢，無法高效地處理大數(shù)據(jù)。

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

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

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

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

計算能力和GPU

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

此外，現(xiàn)在許多生產(chǎn)上的機(jī)器學(xué)習(xí)都依賴于GPU。然而，它們既稀缺又昂貴，這很容易給機(jī)器學(xué)習(xí)的擴(kuò)展任務(wù)增加另一層復(fù)雜性。

可移植性

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

可擴(kuò)展性

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

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

機(jī)器學(xué)習(xí)峰值計算

一旦你的算法被訓(xùn)練好了，它們并不是時時刻刻被使用——你的用戶只會在需要的時候調(diào)用它們。

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

根據(jù)我的經(jīng)驗，我可以告訴你，使用動態(tài)擴(kuò)大或縮小你的服務(wù)來確保不為你不需要的服務(wù)器付費(fèi)是一個挑戰(zhàn)

由于所有這些原因，只有少數(shù)數(shù)據(jù)科學(xué)項目最終真正進(jìn)入生產(chǎn)系統(tǒng)。

模型的穩(wěn)定和魯棒

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

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

更多的挑戰(zhàn)

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

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

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

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

在機(jī)器學(xué)習(xí)應(yīng)用程序中會出現(xiàn)一些傳統(tǒng)的單元/集成測試無法識別的錯誤。部署錯誤的模型版本、忘記某個特征以及在過時的數(shù)據(jù)集上進(jìn)行訓(xùn)練只是其中的幾個例子。

測試和驗證的問題

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

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

與常規(guī)軟件應(yīng)用程序相比，機(jī)器學(xué)習(xí)模型需要更頻繁地更新。

自動化機(jī)器學(xué)習(xí)平臺

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

多達(dá)90%的企業(yè)機(jī)器學(xué)習(xí)模型可以自動開發(fā)。數(shù)據(jù)科學(xué)家可以與業(yè)務(wù)人員合作，開發(fā)目前自動化無法實現(xiàn)的一小部分模型

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

必須通過部署平臺監(jiān)視的關(guān)鍵元素

發(fā)布策略

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

當(dāng)你的體系結(jié)構(gòu)成熟時，請考慮啟用漸進(jìn)的或“Canary”版本。這種做法是指你可以向一小部分客戶發(fā)布產(chǎn)品，而不是“要么全部發(fā)布，要么什么都不發(fā)布”。這需要更成熟的工具，但它可以最小化錯誤。

總結(jié)

機(jī)器學(xué)習(xí)仍處于初級階段。實際上，軟件和硬件組件都在不斷發(fā)展，以滿足機(jī)器學(xué)習(xí)的當(dāng)前需求。

Docker/Kubernetes和微服務(wù)體系結(jié)構(gòu)可以用來解決異構(gòu)性和基礎(chǔ)設(shè)施方面的挑戰(zhàn)。現(xiàn)有的工具可以單獨地極大地解決一些問題。我認(rèn)為，將所有這些工具結(jié)合起來以使ML運(yùn)作化是當(dāng)今最大的挑戰(zhàn)。

部署機(jī)器學(xué)習(xí)是并且將繼續(xù)是困難的，這只是組織將需要處理的一個現(xiàn)實。值得慶幸的是，一些新的架構(gòu)和產(chǎn)品正在幫助數(shù)據(jù)科學(xué)家。此外，隨著越來越多的公司擴(kuò)展數(shù)據(jù)科學(xué)操作，他們也在實現(xiàn)使模型部署更容易的工具。