導(dǎo)讀

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

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

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

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

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

挑戰(zhàn)

機(jī)器學(xué)習(xí)有一些獨(dú)特的特性，使得大規(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ù)雜的，并且通常會(huì)降低原始模型的性能(速度、準(zhǔn)確性等)。

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

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

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

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

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

計(jì)算能力和GPU

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

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

可移植性

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

可擴(kuò)展性

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

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

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

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

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

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

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

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

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

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

更多的挑戰(zhàn)

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

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

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

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

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

測(cè)試和驗(yàn)證的問題

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

除了在離線測(cè)試中驗(yàn)證模型外，評(píng)估生產(chǎn)模型的性能也非常重要。通常，我們?cè)诓渴鸩呗院捅O(jiān)視部分對(duì)此進(jìn)行規(guī)劃。

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

自動(dòng)化機(jī)器學(xué)習(xí)平臺(tái)

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

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

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

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

發(fā)布策略

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

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

總結(jié)

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

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

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