雷鋒網(wǎng) AI 科技評論按：機器學(xué)習(xí)技術(shù)正在令我們的生活發(fā)生日新月異的變化。對于學(xué)術(shù)界來說，科研人員的工作往往止步于原型算法的研制。然而，在真實的工業(yè)生產(chǎn)場景下，將原型機器學(xué)習(xí)算法部署到應(yīng)用程序中又是一項充滿挑戰(zhàn)的課題。

經(jīng)手過一些人工智能項目后，我意識到：對于希望通過人工智能創(chuàng)造價值的公司來說，大規(guī)模地部署機器學(xué)習(xí)（ML）模型是最重要的挑戰(zhàn)之一。如今，隨著模型變得越來越復(fù)雜，這只會變得越來越難。

根據(jù)我作為顧問的經(jīng)驗，我發(fā)現(xiàn)只有很小一部分機器學(xué)習(xí)項目能夠被成功投入生產(chǎn)。人工智能項目失敗的原因有很多，而「難以部署」就是其中之一。對于每個決策者來說，充分理解項目部署的內(nèi)在機制，以及如何降低在達到這個關(guān)鍵步驟時失敗的風(fēng)險是至關(guān)重要的。

我們可以將部署的模型定義為任意被無縫集成到生產(chǎn)環(huán)境中的代碼單元，它可以接收輸入并返回一個輸出結(jié)果。

我所看到的是，為了使他們的工作能夠被投入生產(chǎn)，數(shù)據(jù)科學(xué)家通常必須將他們的數(shù)據(jù)模型的構(gòu)建工作移交給工程實現(xiàn)部分。正是在這一步中，出現(xiàn)了一些最為常見的數(shù)據(jù)科學(xué)問題。

挑戰(zhàn)

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

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

如你所知，機器學(xué)習(xí)應(yīng)用程序通常由不同編程語言編寫的元素組成，而這些元素往往不能很好地進行交互。我總是能發(fā)現(xiàn)類似這樣的情況：在一個機器學(xué)習(xí)應(yīng)用的工作流程中，可能開始使用的是 R 語言，接著則轉(zhuǎn)而使用 Python，最終又使用了另一種語言。

一般而言，對于機器學(xué)習(xí)應(yīng)用來說，Python 和 R 是目前最流行的語言。但是我注意到，出于各種原因（包括運行速度），用于生產(chǎn)的模型很少使用這些語言進行部署。然而，將 Python 或 R 語言編寫的模型移植到 C++ 或 Java 這種生產(chǎn)環(huán)境下常用的語言是十分復(fù)雜的，通常會降低原始模型的性能（運行速度、準確率，等等）。

當軟件的新版本出現(xiàn)時，R 的程序包很可能會崩潰。此外，R 的運行速度也很慢，無法高效處理大數(shù)據(jù)。

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

容器化技術(shù)（Containerization，例如 Docker），可以解決由于工具類型繁多而引發(fā)的不兼容性問題和可移植性的挑戰(zhàn)。然而，自動依賴檢查、誤差檢查、測試以及不同的構(gòu)建工具這些問題則無法跨越語言障礙得以解決。

復(fù)現(xiàn)性也是一個巨大的挑戰(zhàn)。事實上，數(shù)據(jù)科學(xué)家可以使用不同的編程語言、程序庫或同一種程序庫的不同版本來構(gòu)建各個版本的模型。想要手動跟蹤這些依賴是很困難的。為了解決這些挑戰(zhàn)，我們需要一個機器學(xué)習(xí)生命周期工具，它可以在訓(xùn)練階段自動跟蹤并且以配置代碼的形式記錄這些依賴，然后將它們與訓(xùn)練好的模型捆綁在一個待部署的組件中。

我建議你使用能夠?qū)⒋a從一中語言即時轉(zhuǎn)換為另一種語言的工具，或者使你的數(shù)據(jù)科學(xué)團隊能夠使用某種 API 部署模型，以便這些模型在任何地方集成。

2、算力和 GPU

現(xiàn)代神經(jīng)網(wǎng)絡(luò)往往非常深，這意味著訓(xùn)練和使用它們進行推理需要耗費大量的算力。通常，我們希望我們的算法能夠快速運行，而這對于很多用戶來說這可能是一大障礙。

此外，現(xiàn)在許多生產(chǎn)環(huán)境下的機器學(xué)習(xí)系統(tǒng)都依賴于 GPU。然而，GPU 既稀缺又昂貴，這很容易使機器學(xué)習(xí)的大規(guī)模部署變得更加復(fù)雜。

3、可移植性

模型部署的另一個有趣的問題是缺乏可移植性。我注意到，這往往是歷史遺留的分析系統(tǒng)所造成的問題。由于沒有能力輕松地將軟件組件移植到另一種主機環(huán)境下并在那里運行它，這種軟件組合可能會被限制在一個特定的平臺上。這回給數(shù)據(jù)科學(xué)家在創(chuàng)建和部署模型時設(shè)置障礙。

4、可擴展性

對于許多人工智能項目來說，可擴展性是一個很現(xiàn)實的問題。實際上，你需要確保你的模型能夠進行擴展，并且滿足生產(chǎn)中對性能和應(yīng)用程序需求的增加。在項目的開始階段，我們通常依賴于可管理規(guī)模的相對靜態(tài)的數(shù)據(jù)。隨著模型向生產(chǎn)環(huán)境不斷變化，它通常需要面對更大量的數(shù)據(jù)和數(shù)據(jù)傳輸模式。你的團隊將需要多種工具來監(jiān)管并解決性能和可擴展性方面的挑戰(zhàn)，隨著時間的推移，這些挑戰(zhàn)將會顯現(xiàn)出來。

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

5、在極限狀態(tài)下進行機器學(xué)習(xí)計算

當你的算法被訓(xùn)練好后，他們并不總是會被立刻使用，你的用戶只會在他們需要的時候調(diào)用這些算法。

這意味著，也許在上午 8 點時你只要支持 100 次 API 調(diào)用，但是到了 8 點半這一數(shù)值猛增到了 10,000 次。

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

由于上述這些原因，只有很少的數(shù)據(jù)科學(xué)項目最終真正落地到了生產(chǎn)系統(tǒng)中。

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

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

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

三、其它的挑戰(zhàn)

在我經(jīng)手過的項目中，我還注意到以下問題：

• 如果我們改變了一個輸入特性，那么剩余特性的重要性、權(quán)值或用途都可能改變，也可能不改變。機器學(xué)習(xí)系統(tǒng)必須要被設(shè)計地能夠方便地跟蹤特性工程和選擇的變化。

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

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

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

四、測試和驗證的問題

正如你可能已經(jīng)知道的那樣，由于數(shù)據(jù)變更、使用新的方法等原因，模型會不斷地演進。因此，每次發(fā)生這樣的變更時，我們都必須重新驗證模型的性能。這些驗證步驟帶來了如下挑戰(zhàn)：

• 必須使用相同的測試集和驗證集來評價模型，從而對比不同機器學(xué)習(xí)模型的性能。

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

• 為了保證可比性，在不同的時間和不同的模型上，對于度量指標應(yīng)該使用相同的代碼。

• 對于某種新的模型來說，性能的提升可能也會帶來預(yù)測時間的增長。為了體現(xiàn)出這種影響，驗證過程應(yīng)該包括基準對比測試和負載/壓力測試。
  

除了在離線測試中驗證模型之外，在生產(chǎn)環(huán)境下評估模型性能也十分重要。通常我們在部署策略和監(jiān)管部分對此進行規(guī)劃。

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

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

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

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

許多模型都會遭受「模型漂移」（性能隨著時間推移而下降）的問題。因此，我們需要對部署后的模型進行監(jiān)管。每個部署后的模型應(yīng)該記錄所有的輸入、輸出和異常。模型部署平臺需要提供日志存儲和模型性能可視化功能。密切關(guān)注模型的性能是有效管理機器學(xué)習(xí)模型生命周期的關(guān)鍵。

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

五、發(fā)布策略

探索各種不同的方法來部署軟件（這是一個值得長期學(xué)習(xí)的課題，可參考資料：https://medium.com/@copyconstruct/monitoring-in-the-time-of-cloud-native-c87c7a5bfa3e），通過「影子模式」和「金絲雀模式」（注：17世紀，英國礦井工人發(fā)現(xiàn)，金絲雀對瓦斯這種氣體十分敏感?？諝庵心呐掠袠O其微量的瓦斯，金絲雀也會停止歌唱；而當瓦斯含量超過一定限度時，雖然魯鈍的人類毫無察覺，金絲雀卻早已毒發(fā)身亡。當時在采礦設(shè)備相對簡陋的條件下，工人們每次下井都會帶上一只金絲雀作為「瓦斯檢測指標」，以便在危險狀況下緊急撤離。）部署機器學(xué)習(xí)應(yīng)用程序是十分有效的。

在「影子模式」中，你可以獲知生產(chǎn)環(huán)境下的新模型的輸入和預(yù)測結(jié)果，而實際上并沒有基于這些預(yù)測展開服務(wù)。相反，你可以自由地分析結(jié)果，如果檢測到一個 bug 也不會造成重大的后果。

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

六、結(jié)語

機器學(xué)習(xí)技術(shù)方興未艾。實際上，軟件和硬件組件都在不斷地發(fā)展以滿足當前機器學(xué)習(xí)的需求。

我們可以使用「Docker/Kubernetes」和微服務(wù)架構(gòu)來解決異構(gòu)性和基礎(chǔ)環(huán)境的挑戰(zhàn)。現(xiàn)有的工具可以在很大程度上單獨解決一些問題。我相信，將所有這些工具結(jié)合起來在生產(chǎn)中使用機器學(xué)習(xí)是目前最大的挑戰(zhàn)。

部署機器學(xué)習(xí)是困難的，并將一直如此，而這正是我們需要面對的現(xiàn)實。值得慶幸的是，一些新的架構(gòu)和產(chǎn)品正在成為數(shù)據(jù)科學(xué)家的「好幫手」。此外，隨著越來越多的公司擴展數(shù)據(jù)科學(xué)業(yè)務(wù)，它們也正在實現(xiàn)使得模型部署更方便的工具。

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

雷鋒網(wǎng) AI 科技評論編譯。雷鋒網(wǎng) 

雷峰網(wǎng)原創(chuàng)文章，未經(jīng)授權(quán)禁止轉(zhuǎn)載。詳情見轉(zhuǎn)載須知。