文章發布于公號【數智物語】 （ID：decision_engine），關注公號不錯過每一篇干貨。

來源 | 數據派THU（id：DatapiTHU）
作者：Julien Kervizic
翻譯：陳之炎 校對：李海明

本文整理比較模型部署到生產中使用的不同部署模型方式、生命周期管理方法及數據存儲格式。

Mantas Hesthaven拍的發表在 Unspash上的照片

機器學習模型的應用方法多種多樣，不一而足。 例如，在客戶流失預測中，當客戶呼叫服務時，系統中便可以查找到一個靜態統計值，但對于特定事件來說，系統則可以獲得一些額外值來重新運行模型。

通常，有很多方法可以對模型進行訓練，并將其轉化為應用產品：

1. 訓練：一次性訓練、批量訓練和實時訓練/在線訓練

2. 應用：批訓練、實時訓練 (數據庫觸發器、Pub/Sub、Web服務、inApp)

每種方法都有各自的優劣，需要折中考慮。

01一次性訓練

模型在應用前，無需進行連續的多次訓練。通常情況下，在數據科學家完成對模型的特定訓練之后，便可進行應用，待模型性能無法滿足使用要求時，再對其進行更新。

01從Jupyter到Prod

通常，數據科學家會在Jupyter Notebooks環境中組建原型和使用機器學習算法。Jupyter Notebooks是repl上的高級GUI，可以在這個環境中同時保存代碼和命令行輸出。

采用這種方法，完全可以將一個經過特別訓練的模型從Jupyter中的某個代碼推向量產。多種類型的庫和其他筆記本環境有助于加強數據科學家工作臺和最終產品之間的聯系。

02模型格式

Pickle將python對象轉換為比特流，并將其存儲到磁盤以便后續重新加載。它提供了一種很好的格式來存儲機器學習模型，亦可在python中構建其應用程序。

ONNX為開放式神經網絡交換格式，作為一種開放格式，它支持跨庫、跨語言存儲和移植預測模型。大多數深度學習庫都支持該格式， sklearn還有一個擴展庫來將模型轉換為ONNX格式。

PMML或預測模型標記語言，是另一種用于預測模型的交換格式。sklearn還有另一個擴展庫，可用于將模型轉換為PMML格式，這與ONNX是一致的。然而，它的缺點是只支持某些類型的預測模型，PMML從1997年開始出現，大量的應用程序均采用這種格式。例如：像SAP這樣的應用程序能夠利用PMML標準的某些版本，對于CRM應用程序(如PEGA)也是如此。

POJO和MOJO是兩種H2O.ai的導出格式，他們旨在為Java應用程序提供一個易于嵌入的模型。然而，這兩種導出格式只在H2O平臺上使用。

03訓練

對一次性訓練模型，可以由數據科學家專門對模型進行訓練和精調，或者也可以通過AutoML庫進行訓練。通過簡單設置，便可將模型產品化推進到下一個階段，例如批訓練。

02批訓練

雖然不是所有的模型都需要應用，但批訓練可以根據最新的訓練結果使模型的版本得到連續刷新。

批訓練受益于AutoML框架，其通過AutoML能夠自動執行一系列動作。例如：特征處理、特征選擇、模型選擇和參數優化。AutoML新近的表現與最勤奮的數據科學家不相上下，甚至超過了他們。

LinkedIn上的帖子

利用它們可以進行更為全面的模型訓練，而不是做預訓練：簡單地重新訓練模型的權重。

目前有多種不同的技術來支持連續的批訓練，例如，可以通過多種混合 airflow來管理不同的工作流和類似tpot的AutoML庫。

不同的云服務提供商為 AutoML 提供了各種解決方案，并把這些解決方案放到數據工作流中。例如，Azure將機器學習預測和模型訓練與其數據工廠進行了整合。

03實時訓練

實時訓練可以通過“在線機器學習”模型實現，支持這種訓練方法的算法包括：K-均值(通過小批處理)、線性回歸和 Logistic 回歸(利用隨機梯度下降)以及樸素貝葉斯分類器。

Spark 中包含 StreamingLinear 算法 / StreamingLinearRegressionWithSGD 算法來執行這些操作， Skinlear 具有 SGDRegressor 和 SGD 分類器，可實現增量訓練。在 sklearn 中，增量訓練通過 partial_fit 方法完成，如下所示：

在部署這類模型時，需要嚴格的操作支持和監控，因為模型對新的數據和噪聲很敏感，所以需要動態地監控模型性能。在離線訓練中，可以過濾掉高位的點值，并對輸入數據進行校正。當需要根據新的數據流不斷更新模型訓練時，難度系數會高出許多。

在線模型訓練的另一個挑戰是，過往歷史信息得不到衰減。 這意味著，如果數據集的結構有新的變化，則需要重新對模型訓練，這在模型生命周期管理中將是一個很大的挑戰。

04

批量預測與實時預測的比較

當選擇是設置批量預測還是設置實時預測時，必須了解實時預測的重要性。如果發生重大事件，有可能會獲得新的分數，例如當客戶呼叫聯絡中心時，客戶流失評分又會是多少。在實時預測時，需要對這些因素進行加權，以克服由于進行實時預測而產生的復雜性和成本影響。

01載荷的影響

在進行實時預測時，需要有一種處理高峰負荷的方法。需要根據所采用的途徑以及使用的預測如何結束，來選擇一種實時方法，可能還需要有具有額外計算能力的超級機器，以便在某個SLA中提供預測。這與批量預測的處理方法形成了對比，在批量預測中，可以根據可用容量將預測計算分散到一整天。

02架構的影響

在實時預測時，運營責任會更高一些，人們需要對系統是如何工作進行監測，在出現問題時有告警，并考慮到故障轉移責任。 對于批量預測來說，運營責任要低得多，只需要對告警進行一些必要的監測，而對于了解產生問題的直接原因的需求要低得多。

03成本的影響

實時預測也受成本因素的影響，一味追求高算力，而卻沒有選擇將計算負荷分散在全天進行，可能會迫使你購買那些超出算力需求的硬件設備或提高現貨價格。根據所用方法和需求，可能還需要投入額外的成本購買更強大的計算能力來滿足SLA的需求。此外，在選擇實時預測時，可能會有更高的架構要求。需要注意的是，在應用程序中，所做出的選擇要依賴應用程序的預測，對于這樣的特定場景，實時預測的成本最終可能會比批量預測的成本更低。

04評估的影響

實時預測的預測性能評估比批量預測的預測性能評估更具挑戰性。例如，當在短時間內遇到一連串的突發行為時，如何評估性能，會不會為特定的客戶產生多個預測結果？實時預測模型的評估和調試要復雜得多，它還需要一個日志收集機制，既允許收集不同的預測結果和特征，也可以生成分數以供進一步評估。

05批量預測集成

批量預測依賴于兩個不同的信息：一個是預測模型，另一個是提供給模型的特征。在大多數批處理預測體系結構中，ETL既可以從特定的數據存儲(特征存儲)中獲取預先計算的特征，也可以跨多個數據集執行某種類型的轉換，并向預測模型提供輸入。然后，預測模型對數據集中所有的行數據進行迭代，并輸出不同的分值。

用于批量預測的示例流模型

一旦計算得到所有的預測結果，便可以將分數“投入”到那些有信息使用需求的不同系統中。可以根據不同的應用實例，并通過不同的方式來實現分數的使用。例如，如果想在前端應用程序上使用分數，則很可能將數據推送到“緩存”或NoSQL數據庫：比如Redis，這樣可以提供毫秒的響應；而對于某些用例，比如創建電子郵件，可能只是依賴CSV SFTP導出或將數據加載到更傳統的RDBMS。

06實時預測集成

基于實時應用的模型使用需要3個基本組件：客戶/用戶配置文件、一組觸發器和預測模型。

配置文件：客戶配置文件包含和客戶相關的所有屬性，以及給出預測所必需的不同屬性(例如：計數器)。對于客戶級預測，為了減少從多個地方提取信息的延遲，以及簡化機器學習模型的量產化過程，配置文件是必須的。在大多數情況下，為了更有效地獲取數據，需要相似的數據存儲類型。

觸發器：觸發器是引導進程啟動的事件，它們可以用于客戶流失的預測。例如調用客戶服務中心、檢查訂單歷史記錄中的信息等。

模型： 模型需要經過預先訓練，通常導出到前面提到的 3 種格式之一 (pickle、 ONNX 或 PMML) ，以便可以將其移植到量產中。

還有許多方法可以將模型應用至評分產品中：

1. 取決于數據庫集成：諸多數據庫供應商為在數據庫中綁定高級分析用例做出了重大努力，既可以直接集成Python或R代碼，也可以導入PMML模型。

2. 利用Pub/Sub模型：預測模型本質上是對數據流的輸入執行某些操作，例如提取客戶配置信息等。

3. Webservice：圍繞模型預測設置API封裝器，并將其部署為Web服務。根據Web服務的設置方式，它可能執行或不執行驅動模型所需的數據操作。

4. inApp:也可以將模型直接部署到本地或Web應用程序中，并讓模型在本地或外部數據源上運行。

07

數據庫集成

如果數據庫的總體大小不大 (用戶配置文件<1M)，并且更新頻率也不大，那么將一些實時更新過程直接集成到數據庫中會很有意義。

Postgres允許將Python代碼作為函數或稱為PL/Python的存儲過程來運行。該實現可以訪問所有作為PYTHONPATH的一部分庫，也可以使用Pandas和SKLearning等庫來運行某些操作。

此外，還可以與Postgres的觸發器機制相結合來運行數據庫，并更新客戶流失分數。比如，如果在投訴表中輸入了一個新條目，那么讓模型實時重新運行的話便很有價值。

01流程

流程以如下方式設置：

1. 新事件： 當在投訴表中插入新行時，將生成事件觸發器。

2. 觸發器： 觸發器功能將更新該客戶在客戶配置文件表中提出的投訴數量，并為客戶更新記錄。

3. 預測請求：使用PL/Python重新運行客戶流失模型并檢索預測結果。

4. 用戶配置文件的更新：根據更新后的預測結果重新更新客戶配置文件。然后，當檢查客戶配置文件是否已經用客戶流失預測值進行更新時，就會生成下游流。

02技術

Different databases are able to support the running of多種數據庫支持Python腳本的運行，如前所述， Postgres集成有本地Python， MSSQL Server也可以通過其“機器學習服務(在數據庫中)”運行R/Python腳本，諸如Teradata等其他數據庫可以通過外部腳本命令運行R/Python腳本。Oracle通過其數據挖掘擴展支持PMML模型。

08Pub/Sub

通過pub/sub模型實現實時預測，可以通過節流正確地處理負載。對于工程師而言，這也意味著可以通過一個單獨的“日志”提要來輸入事件數據，不同的應用程序均可以訂閱這個提要。

設置示例：

頁面查看事件被觸發到特定的事件主題，在該主題中，兩個應用程序訂閱一個頁面查看計數器和一個預測器。這兩個應用程序都從主題中篩選出特定的相關事件，并在該主題中使用不同的消息。頁面查看計數器為儀表板提供數據，而預測應用程序則負責更新客戶配置文件。

01流程

事件消息在發生時被推送到pub/sub主題，預測應用程序會輪詢新消息的主題。當預測應用程序檢索到新消息時，該程序將請求并檢索客戶配置文件，并使用消息和配置文件信息進行預測，預測結果最終返回客戶配置文件以供進一步使用。

還可以設置一個稍微不同的流程：數據首先被一個“富集應用程序”使用，該應用程序將配置文件信息添加到消息中，然后返回一個新主題，并最終交由預測應用程序推送到客戶配置文件上。

02技術

您會發現，在數據生態系統中支持這種用例的典型的開源組合是Kafka和SPark流的組合，但是云上可能有不同的設置。值得注意的是：Google發布的pub-sub /數據流(BEAM)提供了一個很好的替代方案，在Azure上，Azure-Service總線或Eventub和Azure函數的組合可以作為一種很好的方式來利用消息生成這些預測。

09網絡服務Web Service

我們還可以將模型作為互聯網服務產品。將預測模型作為互聯網服務產品對于工程團隊尤為有用，這些團隊通常需要處理Web、桌面和移動等多個不同的接口。

可以有多種方式設置Web服務的接口：

1. 提供標識符，然后讓web服務提取所需的信息，計算預測值，然后返回該值

2. 或者通過接受有效載荷，將其轉換為數據幀，進行預測并返回該值。

當發生大量交互，并且使用本地緩存與后端系統的同步，或者當需要在不同的粒度上進行預測時，比如：在進行基于會話的預測時，通常建議使用第二種方法。

使用本地存儲的系統往往具有還原功能，其作用是計算客戶配置文件的內容，因此，它提供了基于本地數據的客戶配置文件的近似值。

01流程

使用移動應用程序處理預測的流程可分為4個階段進行描述：

1. 應用程序初始化(1至3)階段：應用程序初始化，向客戶配置文件發出請求，檢索其初始值，在本地存儲中初始化配置文件。

2. 應用程序(4)階段：應用程序將與該程序中出現的不同事件存儲到本地存儲區的數組中。

3. 預測準備階段(5-8)：如果應用程序想要檢索一個新的客戶流失預測，那么它需要將互聯網服務所需的信息準備好。首先對本地存儲進行初始請求，并檢索客戶配置文件的值及其存儲的事件數組，檢索完成后，向還原器函數提出請求，將這些值作為參數，還原器函數輸出一個更新后的客戶配置文件，并將本地事件合并到這個客戶配置文件中。

4. Web服務預測階段(9至10)：應用程序向客戶流失預測的互聯網服務產品發出請求，將第8步驟中的有效載荷提供給更新后的客戶配置文件。然后，互聯網服務產品可以使用載荷提供的信息生成預測并將其值輸出給應用程序。

02技術

有很多技術可以用來支持互聯網服務產品預測：

1. 函數

AWS Lambda函數、GoogleCloud函數和MicrosoftAzure函數(盡管目前只支持Beta版Python)提供了一個易于設置的界面，可以輕松地部署可伸縮的Web服務。
例如，在Azure上，可以通過如下函數實現web-service預測：

2. 容器

除了函數之外的另一種選擇是通過docker容器(AmazonECS、Azure容器實例或Google Kubernetes引擎)部署一個Flask或Django應用程序。例如，Azure通過“AzureMachineLearning服務”提供了一種簡單的方法來設置預測容器。

3. 筆記簿

不同的筆記薄提供商，如Databricks和dataiku，都致力于簡化其環境中的模型部署。它們具有將webservice設置到本地環境或部署到外部系統(如Azure ML服務、Kubernetes引擎等)的功能。

10應用程序內部

在某些情況下，因為法律和隱私的要求，不允許數據被存儲在應用程序外部時，或者必須上傳大量文件時，往往會在應用程序內部調用模型。

Android-MLKit 或 Caffe2類似的工具允許在本地應用程序中調用模型，而Tensorflow.js和ONNXJS允許直接在瀏覽器中或在JavaScript的應用程序中運行模型。

11需要綜合考慮的幾點

除了模型的部署方法外，部署模型到量產時需要考慮以下重要因素。

01模型的復雜度

模型本身的復雜程度，是應首先要考慮的因素。像線性回歸和Logistic回歸這樣的模型非常容易部署，通常不會占用太多的存儲空間。使用更為復雜的模型，如神經網絡或復雜集成決策樹，計算將占用更長時間，冷啟動時加載到內存中的時間也會更長，而且運行成本會更高。

02數據來源

需要著重考慮的是實際應用中的數據源與用于訓練的數據源之間可能存在的差異。雖然用于訓練的數據必須與生產中實際使用數據內容同步，但是重新計算每個值以使其完全同步是不切實際的。

03實驗框架

建立一個實驗框架，用于客觀度量不同模型性能的A/B測試，并確保有足夠的跟蹤來準確地調試和評估模型的性能。

11小結

選擇如何將預測模型部署到生產中是一件相當復雜的事情，可以有多種不同的方法來處理預測模型的生命周期管理，也可以用不同的格式來存儲它們，從多種方法中選取恰當的方法來部署模型，包含非常寬泛的技術含量。

深入理解特定的用例、團隊的技術和分析成熟度、整體組織結構及其交互，有助于找到將預測模型部署到生產中的正確方法。

星標我，每天多一點智慧

總結

以上是生活随笔為你收集整理的机器学习方法_机器学习模型应用方法综述的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。