在我們的產業中，很多關注都集中在開發分析模型來解決關鍵商業問題以及預測消費者行為上。但是，當數據科學家研發完模型，需要部署模型以供更大的組織使用時，會發生什么情況？

沒有嚴格流程就部署模型會引發后患，看一下這個金融服務業的實例就知道了。

擁有自己的高頻貿易算法的Knight曾是美國最大的股票貿易商，在紐約證券交易所（NYSE）有17．3％的市場份額，在納斯達克（NASDAQ）有16．9％的市場占有率。但是，2012年由于一次計算機交易的小故障，Knight在不到一小時之內蒙受了4．4億美元的損失。那年年底，公司被收購。這充分證明：未經適當測試就輕易部署使用分析模型會有很大風險，那些系統漏洞會給公司帶來嚴重后果。

在這篇博文中，我們將談談如何通過合理的模型管理和部署流程來避免后患。在部署模型之前，有幾個必須解決的問題：

·模型結果是如何到達那些會從這一分析中獲益的決策者或者應用程序那里的？

·這個模型能不出問題的自主運行嗎？如何從失敗中恢復運行的？

·因為訓練數據是不再相關的歷史數據，模型也因此變得陳舊，會導致什么后果？

·在不阻斷下游消費者的情況下，如何部署和管理新版模型？

我們可以把數據科學的開發和應用看作是兩個不同的流程，但是，這兩個過程又是更大的模型生命周期流程的一部分。下面示例圖說明了這一過程。

1． 終端用戶與應用程序交互，產生的數據存儲在應用的線上產品數據庫中。

2． 然后這些數據會被傳到一個線下的歷史數據庫中（如 Hadoop 或 S3），由數據科學家進行分析，搞清楚用戶是如何與應用交互的。這些數據也有別的用處，比如構建一個模型，根據用戶在應用中的行為把他們進行分類，這樣我們就可以利用這些信息對用戶進行營銷。

3． 一旦構建出了一個模型，我們可以把它登記到一個模型注冊表中，這時一個治理程序會對模型進行評估，批準其投放產業應用，并對模型部署要求進行評估。

4． 當模型的產業應用被批準后，我們就開始部署模型。為此，我們要搞清楚組織會如何使用這個模型，作出相應調整，確保模型能在特定性能約束下自主端到端運行，同時也要進行測試，以確保在部署之后模型仍與開發出來的一致。一旦完成這些步驟，我們就在投入生產前，再次對模型進行了評估和批準。

5．最后，一旦部署完畢，模型所做出的預測就能服務于應用程序，這些預測的權值都是根據用戶交互行為計算出的。這些信息有助于改進模型，或提出一個新的商業問題，這就又回到了過程（2）。

為了確保周期運行成功，我們需要理解數據科學的開發和部署有著不同的要求，這些要求都需要被滿足。這就是為什么你需要一個實驗室，同時也需要一個工廠。

實驗室

數據實驗室是數據科學家進行研究的地方，關注點不同于應用產品。最終目標也許是利用數據驅動組織內的決策制定，但是，實現這個之前，我們需要先弄清楚對組織而言，那些假設有意義，并證明其價值。因此，我們主要關注的是創造出一個環境——實驗室，在這里，數據科學家可以提出問題，構建模型，并用數據進行測試。

正如以下基于  CRISP－DM 模型的圖表所示，這個過程基本上迭代式的。

我們不會在本文討論太多細節，但是我們有一個深入這個主題的教程。

在這里，我們關心的問題是需要實驗室來研發模型，還需要一個工廠，用以部署這個模型并將之自動應用到實時數據，在約束條件下把結果傳送給適當的客戶，并且監管整個過程，以防運行失敗或異常。

工廠

在工廠里，我們要做的是優化價值創造并降低成本，評估穩定性和結構彈性，確保在約束條件下把結果傳送給適當的客戶，同時能監控和管理程序故障。我們需要給模型提供一個結構，根據生產中的情況進行預期。

為了理解工廠的運行過程，我們來看一下如何通過模型注冊表來管理模型，以及部署時需要考慮哪些問題。

模型注冊表

為了給模型一個結構，我們會根據模型的組件進行定義，包括數據依存性，腳本，配置以及文件。另外，我們會捕獲模型上的元數據及其不同版本，提供額外的商業環境和模型特定信息。給模型提供一個結構，接著就能將模型目錄清單存在模型注冊表中，包括了不同模型版本，以及執行過程反饋的關聯結果。下面的圖示解釋了這個概念。

通過注冊表，我們可以：

·明確哪個版本的模型正在被使用，并控制它。

·查看發布說明，搞清楚某個特定版本發生了什么變化。

·查看與模型相關聯的資產和文件，這對于創建一個已有模型的新版本或管理維護是有用的。

·監管模型執行的性能標準，以及什么程序在使用它。這些信息是在模型執行過程中產生的，會把權值反饋給注冊表。

你同樣也可以選擇在模型某個版本中加入 Jupyter Notebook 。這可以讓一個審閱者或開發者遍歷此版本原始開發者最初開發時的思維過程和假設。有助于模型維護，也有助于組織探索。

這里有一個矩陣，解構了一個模型的不同元素：

注冊表需要捕捉到數據、腳本和訓練過的模型對象之間的聯系，圖中說明了與一個模型特定版本相關的文件。

這對我們的實踐有什么幫助？

·通過收集如何運行一個模型所需的資產和元數據，我們就能驅動一個執行工作流，將模型的特定版本用于實時數據，為終端用戶預測結果。如果這是批量程序的一部分，我們就可以利用這些信息為模型創造一個暫態的執行環境，來提取數據、腳本、運行模型、在目標存貯里保存結果，并在程序完成后關閉環境，在最大化資源的同時將成本最小化。

·從監管角度來看，我們可以支持那些決定模型何時被推向產業化的商業工作流，這些工作流負責允許運行中的模型監視程序去做出一些決定，比如，當我們發現模型預測已不再符合現實情況時是否應該重新訓練它。如果你有審計要求，你可能需要跟顧客解釋你是如何得到某個特定結論的。為了做到這一點，你需要去考察在特定時間運行的某個特定版本的模型，并且需要知道復現這個結果用到了什么樣的數據。

·如果我們在一個已有模型中發現了漏洞，我們可以把它標記成不應該使用，修復后發布此模型的新版本。對所有使用漏洞版本的用戶發送通知，他們就可以轉而使用新的修復版。

如果不進行以上這些步驟，我們就有可能讓模型維護變成需要試圖理解原始開發者意圖的冒險行為，部署后的模型不再與那些正在開發中模型相匹配，產生不正確的結果，在已有模型升級后還會擾亂下游用戶的正常使用。

模型部署

一旦模型被批準部署，我們需要通過幾個步驟來確保模型能被部署。要有驗證正確性的測試，還要測試提取原始數據的管道流程、特征生成，以及分析模型評分以確定模型可以自主運行，以消費者需要的方式產生出結果，滿足行業定義的性能要求。還要確保模型的執行過程處于監控中，以防發生錯誤或模型過時不再產生準確的結果。

在部署之前，我們要確保測試了下面幾項：

·部署后的模型是否達到了原始模型開發者的預期。通過采用一個在開發過程中產生有效結果的測試輸入集，我們就能驗證部署的代碼是否與開發中的預期吻合。

·部署后的模型是否在多種不同的輸入下都能良好運行，測試輸出的極端情況，以及由于數據質量問題潛在丟失的數值。同時應該有防止這些輸入毀掉模型并最終影響下游顧客的的控制手段。

我們通過兩種方式來最小化部署后模型與開發模型匹配時的風險：1）部署到生產環節之前就運行測試，2）捕獲環境細節，比如特定的語言版本和模型的庫依存性（例如，一個Python requirements．txt 文件）。
一旦部署到生產環節后，我們就想對用戶顯示模型的預測結果。有多少用戶會使用這一模型進行預測？在為模型打分時，提供特征數據的速度要有多快？比如，欺詐偵測中，如果特征信息每24小時產生一次，那么，從事件發生到詐騙偵測模型檢測到此事件之間，會存在嚴重滯后。這就是我們需要解決的一些可擴展性和性能方面的問題。

就一個應用程序來說，最理想的方式是通過網頁服務向用戶展示結果，方式是通過模型實時得分或是以線下批處理過程展示評分結果。或者是，模型需要支持一個商業過程，我們需要把模型的結果放在一個為決策者生成報告并遵照該這些結果予以行事的地方。無論是那種情況，如果沒有模型注冊表，想要知道哪里可以找到并使用當前模型的結果是很困難的。

另一個應用實例是想要搞清楚模型如何背離實時數據運行，以考察模型是否變得陳舊，或者確定一個新開發的模型性能是否超過舊模型。一個簡單的例子就是用回歸模型來對比預期值和實際值。如果我們沒有監測到模型結果隨時間變化，那么，我們可能是在根據不再適用于當前情勢的歷史數據在做決策。

結論

這篇文章中，我們遍歷了模型周期，討論了對實驗室和工廠的需要，意在降低部署那些可能影響商業決策（并且還可能帶來高成本）壞模型帶來的風險。另外，注冊表也提供了組織中模型的透明性和可發現性。這有利于通過呈現組織使用的現有技術，來研發新模型，解決相似問題，也有利于現有模型維護或通過澄清模型當前版本、目前相關資產情況等來提升模型。

在SVDS ，我們正在研發一個架構，它能支持模型管理，把不同模型版本登入注冊表，并管理如何將這些模型版本部署到一個執行引擎中。