本文是機器學(xué)習(xí)平臺系列的第2部分。它由數(shù)字彈射器和 PAPIs支持。

在「機器學(xué)習(xí)」機器學(xué)習(xí)（ML)開發(fā)平臺概述，我概述了ML開發(fā)平臺，它們的工作是幫助創(chuàng)建和打包ML模型。模型構(gòu)建只是ML系統(tǒng)所需的眾多功能中的一項。在這篇文章的最后，我提到了其他類型的ML平臺以及構(gòu)建現(xiàn)實世界ML系統(tǒng)時的限制。在我們能夠討論這些之前，我們需要回顧這些系統(tǒng)的所有組件，以及它們是如何相互連接的。

「機器學(xué)習(xí)架構(gòu)」一個真實世界機器學(xué)習(xí)系統(tǒng)的架構(gòu)

上面的圖表關(guān)注的是“監(jiān)督學(xué)習(xí)”系統(tǒng)(例如分類和回歸)的客戶機-服務(wù)器架構(gòu)，其中預(yù)測由客戶機請求，在服務(wù)器上進行。(旁注:在某些系統(tǒng)中，最好有客戶端預(yù)測;其他的甚至可能鼓勵客戶端模型培訓(xùn)，但是在工業(yè)ML應(yīng)用程序中使其高效的工具還不存在。)

ML系統(tǒng)組件的概述

在進一步研究之前，我建議下載上面的圖表，并分割屏幕，以便在閱讀本文其余部分的同時可以看到圖表。

讓我們假設(shè)“數(shù)據(jù)庫”在創(chuàng)建ML系統(tǒng)之前就已經(jīng)存在了。深灰色和紫色的組件將是新的組件被建立。那些應(yīng)用ML模型進行預(yù)測的用紫色表示。矩形用于表示有望提供微服務(wù)的組件，這些組件通常通過具象狀態(tài)傳輸(representational state transfer, REST) api訪問并在無服務(wù)器平臺上運行。

ML系統(tǒng)有兩個“入口點”:請求預(yù)測的客戶端和創(chuàng)建/更新模型的協(xié)調(diào)器。客戶端代表將從ML系統(tǒng)獲益的最終用戶使用的應(yīng)用程序。這可以是你用來訂晚餐的智能手機應(yīng)用程序，例如UberEats請求預(yù)定的交貨時間——這在COVID-19封鎖期間是一個大用例!

封鎖前的照片，維基百科提供。有一個復(fù)雜的ML系統(tǒng)可以預(yù)測這個家伙什么時候到達(dá)他的目的地，每天成千上萬次，在世界上數(shù)以百計的城市!希望這個系統(tǒng)使用的模型在過去幾周內(nèi)得到了更新……

協(xié)調(diào)器通常是由調(diào)度程序調(diào)用的程序(以便模型可以定期更新，例如每周更新)，或者通過API調(diào)用(以便它可以成為持續(xù)集成/持續(xù)交付管道的一部分)。它負(fù)責(zé)在一個保密的測試數(shù)據(jù)集上評估模型構(gòu)建器創(chuàng)建的模型。為此，它將測試預(yù)測發(fā)送給求值器。如果一個模型被認(rèn)為足夠好，那么它將被傳遞到模型服務(wù)器，通過API使其可用。這個API可以直接公開給客戶端軟件，但是通常需要在前端中實現(xiàn)特定于領(lǐng)域的邏輯。

假設(shè)有一個或多個(基線)模型可以作為api使用，但還沒有集成到最終的應(yīng)用程序中，您將通過跟蹤生產(chǎn)數(shù)據(jù)的性能并通過監(jiān)視器可視化來決定要集成哪個模型(以及它是否安全)。在我們的晚餐遞送示例中，它將讓您比較一個模型的ETD與剛剛交付的訂單的實際交貨時間。當(dāng)新的模型版本可用時，客戶端對預(yù)測的請求將通過前端逐步定向到新模型的API。這將為越來越多的終端用戶完成，同時監(jiān)視性能并檢查新模型是否“破壞”了任何東西。ML系統(tǒng)的所有者和客戶機應(yīng)用程序的所有者將定期訪問監(jiān)視器的儀表板。

讓我們以列表的形式重述一下上圖中的所有組件:

事實（Ground-truth）收集器
數(shù)據(jù)貼標(biāo)機
評估者
性能監(jiān)視器
Featurizer(特征化器)
協(xié)調(diào)器
模型構(gòu)建器
模型服務(wù)器
前端

我們已經(jīng)簡單地提到了第3、4、6、7、8和9條。現(xiàn)在讓我們提供更多的信息，復(fù)習(xí)一下#1、# 2和# 5!

# 1:事實收集器

在現(xiàn)實世界中，關(guān)鍵是能夠不斷獲取新的數(shù)據(jù)供機器學(xué)習(xí)。有一種數(shù)據(jù)特別重要:地面真實數(shù)據(jù)。這與您希望ML模型預(yù)測的內(nèi)容相對應(yīng)，例如房地產(chǎn)的銷售價格、與客戶相關(guān)的事件(例如客戶流失)或分配給輸入對象的標(biāo)簽(例如傳入消息中的“spam”)。有時候，你觀察一個輸入對象，你只需要等待一段時間來觀察你想預(yù)測的對象;例如，您等待房產(chǎn)被出售，等待客戶續(xù)訂或取消訂閱，等待用戶與收件箱中的電子郵件交互。您可能希望用戶在ML系統(tǒng)預(yù)測錯誤時讓您知道(參見下面的插圖)。如果您想讓您的用戶能夠提供這種反饋，您將需要一個微服務(wù)來將其發(fā)送到其中。

# 2:數(shù)據(jù)貼標(biāo)機

有時，您可以訪問大量的輸入數(shù)據(jù)，但是您需要手動創(chuàng)建相關(guān)的ground-truth數(shù)據(jù)。構(gòu)建垃圾郵件檢測器或從圖像構(gòu)建對象檢測器時就是這樣。有現(xiàn)成的和開源的web應(yīng)用來簡化數(shù)據(jù)標(biāo)注(如Label Studio)，也有專門的外包手工標(biāo)注數(shù)據(jù)的服務(wù)(如圖8和谷歌的數(shù)據(jù)標(biāo)注服務(wù))。

飛機分類:標(biāo)簽工作室在行動

# 3:評估者

當(dāng)您有了供機器學(xué)習(xí)的初始數(shù)據(jù)集時，在開始構(gòu)建任何ML模型之前，定義如何評估計劃的ML系統(tǒng)是很重要的。除了測量預(yù)測精度，還需要通過特定于應(yīng)用程序的性能指標(biāo)和系統(tǒng)指標(biāo)(如延遲和吞吐量)來評估短期和長期的影響。

模型評估有兩個重要的目標(biāo):比較模型，以及決定將模型集成到應(yīng)用程序中是否安全。評估可以在一組預(yù)先確定的測試用例上執(zhí)行，因為它是已知的預(yù)測應(yīng)該是什么(即基本事實)。可以檢查錯誤分布，并將錯誤聚合到性能指標(biāo)中。為此，評估者需要訪問測試集的ground truth，這樣當(dāng)它在輸入中得到預(yù)測時，它就可以計算預(yù)測錯誤并返回性能指標(biāo)。

我建議在構(gòu)建ML模型之前優(yōu)先實現(xiàn)這個求值器。評估基線模型所作的預(yù)測，以提供參考。基線通常是基于輸入特征(也就是特性)的啟發(fā)式方法。它們可以是超級簡單的、手工制作的規(guī)則……

對于流失預(yù)測，你的基線可以說，如果一個客戶在過去30天內(nèi)登錄少于3次，他們很可能會流失;
對于食物送餐時間的預(yù)測，你的基線可以是上周所點餐餐廳和乘客的平均送餐時間。

在明天開發(fā)復(fù)雜的ML模型之前，看看你的基線今天是否能創(chuàng)造價值!

# 4: 性能監(jiān)視器

決定是否可以將(基線)模型集成到應(yīng)用程序中的下一步是在生產(chǎn)中遇到的輸入(稱為“生產(chǎn)數(shù)據(jù)”)上使用它，在類似于生產(chǎn)的設(shè)置中，并通過時間監(jiān)控它的性能。

計算和監(jiān)控生產(chǎn)數(shù)據(jù)的性能指標(biāo)需要在數(shù)據(jù)庫中獲取和存儲生產(chǎn)輸入、基本事實和預(yù)測。性能監(jiān)視器將由一個從數(shù)據(jù)庫讀取數(shù)據(jù)、調(diào)用評估器的程序和一個顯示性能指標(biāo)如何隨時間發(fā)展的儀表板組成。一般來說，我們希望檢查模型是否隨時間運行良好，以及它們是否持續(xù)對集成它們的應(yīng)用程序產(chǎn)生積極影響。還可以使用顯示生產(chǎn)數(shù)據(jù)分布的數(shù)據(jù)可視化小部件對監(jiān)視器進行增強，這樣我們就可以確保它們符合預(yù)期，或者我們可以監(jiān)視漂移和異常情況。

攪和模型的監(jiān)視儀表板(源)

# 5: FEATURIZER（特征化機器）

在設(shè)計預(yù)測API時，需要決定API應(yīng)該采用什么作為輸入。例如，在對客戶進行預(yù)測時，輸入應(yīng)該是客戶的全部特性表示，還是僅僅是客戶id?

在任何情況下，完整的數(shù)字表示都是很常見的(就像文本或圖像輸入一樣)，但是在傳遞給模型之前必須對其進行計算。對于客戶輸入，有些特性已經(jīng)存儲在數(shù)據(jù)庫中(例如，出生日期)，而其他特性則需要進行計算。這可能是描述客戶在某段時間內(nèi)如何與產(chǎn)品交互的行為特性的情況:它們將通過查詢和聚合記錄客戶與產(chǎn)品交互的數(shù)據(jù)來計算。

如果特性本質(zhì)上不經(jīng)常變化，則可以批量計算它們。但在ML用例中，比如UberEats的預(yù)期交付時間，我們可能會有快速變化的“熱點”特性，需要實時計算;例如，某家餐廳在過去X分鐘內(nèi)的平均送餐時間。

這需要創(chuàng)建至少一個特性化微服務(wù)，它將根據(jù)輸入的id為一批輸入提取特性。您可能還需要一個實時的特性化微服務(wù)，但是這會增加ML系統(tǒng)的復(fù)雜性。

功能分析器可以查詢各種數(shù)據(jù)庫，并對查詢的數(shù)據(jù)執(zhí)行各種聚合和處理。它們可能具有參數(shù)(如上面示例中的分鐘數(shù)X)，這些參數(shù)可能會對模型的性能產(chǎn)生影響。

# 6 協(xié)調(diào)器

工作流

協(xié)調(diào)器位于ML系統(tǒng)的核心，并與許多其他組件交互。下面是它的工作流/管道中的步驟:

提取-轉(zhuǎn)換-加載和分割(原始)數(shù)據(jù)到訓(xùn)練，驗證，測試集
發(fā)送功能飽和化的培訓(xùn)/驗證/測試集(如果有的話)
準(zhǔn)備專用的訓(xùn)練/驗證/測試集
將準(zhǔn)備好的訓(xùn)練/驗證集的uri以及要優(yōu)化的指標(biāo)發(fā)送到模型構(gòu)建器
得到最優(yōu)模型，應(yīng)用于測試集，并將預(yù)測發(fā)送給評估者
獲取性能值并決定是否可以將模型推到服務(wù)器(例如，用于對生產(chǎn)數(shù)據(jù)的卡納塔測試)。

關(guān)于步驟3(“準(zhǔn)備專用培訓(xùn)/驗證/測試集”)的更多細(xì)節(jié):

增強訓(xùn)練數(shù)據(jù)(例如，過采樣/過采樣，或旋轉(zhuǎn)/翻轉(zhuǎn)/裁剪圖像)
預(yù)處理訓(xùn)練/驗證/測試集，包括數(shù)據(jù)消毒(以便可以安全地用于建模或預(yù)測)和針對特定問題的準(zhǔn)備(例如，圖像去飽和和調(diào)整大小)。

運行工作流的方法

整個工作流可以手動執(zhí)行，但是要頻繁地更新模型，或者聯(lián)合調(diào)優(yōu)建模器和建模器的超參數(shù)，就必須實現(xiàn)自動化。這個工作流可以實現(xiàn)為一個簡單的腳本并在單個線程上運行，但是通過并行運行可以提高計算效率。端到端ML平臺允許這樣做，并且可以提供一個環(huán)境來定義和運行完整的ML管道。與谷歌AI平臺,例如,你可以使用谷歌云數(shù)據(jù)產(chǎn)品,如Dataprep (Trifacta爭吵工具提供的數(shù)據(jù)),數(shù)據(jù)流(一個簡化的流和批量數(shù)據(jù)處理工具),BigQuery (serverless云數(shù)據(jù)倉庫),您可以定義一個培訓(xùn)應(yīng)用程序基于TensorFlow或內(nèi)置算法(例如XGBoost)。在處理重要的數(shù)據(jù)量時，Spark是一個流行的選擇。Spark背后的Databricks公司也提供端到端平臺。

或者，工作流的每一步都可以在不同的平臺或不同的計算環(huán)境中運行。一種選擇是在不同的Docker容器中執(zhí)行這些步驟。Kubernetes是ML從業(yè)者中最流行的開源容器編排系統(tǒng)之一。Kubeflow和Seldon Core是開源工具，允許用戶描述ML管道并將其轉(zhuǎn)換為Kubernetes集群應(yīng)用程序。這可以在本地環(huán)境中完成，并且應(yīng)用程序可以運行在Kubernetes集群上，該集群可以安裝在本地，也可以在云平臺中提供——例如谷歌Kubernetes引擎，它被谷歌AI平臺或Azure Kubernetes服務(wù)或Amazon EKS使用。Amazon還提供了一種與Kubernetes相對應(yīng)的Fargate和ECS。Apache氣流是另一個開源工作流管理工具，最初由Airbnb開發(fā)。氣流已經(jīng)成為協(xié)調(diào)一般IT任務(wù)(包括ML任務(wù))執(zhí)行的流行方式，它還與Kubernetes集成。

為更高級的工作流程的主動學(xué)習(xí)

正如前面所暗示的，可能需要領(lǐng)域?qū)＜以L問一個數(shù)據(jù)標(biāo)簽器，在那里他們將被顯示輸入并被要求標(biāo)記它們。這些標(biāo)簽將存儲在數(shù)據(jù)庫中，然后編配人員可以在培訓(xùn)/驗證/測試數(shù)據(jù)中使用這些標(biāo)簽。提供標(biāo)記的輸入可以手動選擇，也可以在協(xié)調(diào)器中進行編程。這可以通過觀察模型正確但不確定的生產(chǎn)投入，或非常確定但不確定的生產(chǎn)投入——這是“主動學(xué)習(xí)”的基礎(chǔ)。

# 7 模型構(gòu)建器

模型構(gòu)建器負(fù)責(zé)提供一個最佳的模型。為此，它在訓(xùn)練集上訓(xùn)練各種模型，并在驗證集上評估它們，使用給定的度量，以評估最優(yōu)性。注意，這與上一篇文章中探討的OptiML示例相同:

$ curl https://bigml.io/optiml?$BIGML_AUTH -d '{"dataset": "<training_dataset_id>", "test_dataset": "<test_dataset_id>", "metric": "area_under_roc_curve", "max_training_time": 3600 }'

BigML通過它的API自動使模型可用，但是對于其他ML開發(fā)平臺，您可能希望打包模型，將其保存為文件，并讓您的模型服務(wù)器加載該文件。

在Azure ML上進行的“自動化ML”實驗的結(jié)果。您可以下載找到的最佳模型，或者在Azure上部署它。

如果您使用不同的ML開發(fā)平臺，或者根本不使用平臺，那么以一種由專用服務(wù)自動創(chuàng)建模型的方式來構(gòu)建您的系統(tǒng)是值得的，該服務(wù)需要對訓(xùn)練集、驗證集和性能度量進行優(yōu)化。

# 8 模型服務(wù)器

模型服務(wù)器的角色是處理針對給定模型的預(yù)測的API請求。為此，它加載保存在文件中的模型表示，并通過模型解釋器將其應(yīng)用到API請求中的輸入;然后在API響應(yīng)中返回預(yù)測。服務(wù)器應(yīng)該允許并行處理多個API請求和模型更新。

下面是一個情緒分析模型的請求和響應(yīng)示例，它只接受一個文本特性作為輸入:

$ curl https://mydomain.com/sentiment-H 'X-ApiKey: MY_API_KEY'-d '{"input": "I love this series of articles on ML platforms"}'{"prediction": 0.90827194878055087}

存在不同的模型表示，如ONNX和PMML。另一個標(biāo)準(zhǔn)實踐是將模型作為計算環(huán)境中的對象保存在文件中。這還需要保存計算環(huán)境的表示，特別是它的依賴關(guān)系，這樣就可以再次創(chuàng)建模型對象。在這種情況下，模型“解釋器”僅僅由像model.predict(new_input)這樣的東西組成。

# 9 前端

前端可以服務(wù)多種用途:

簡化模型的輸出，例如將一個類概率列表轉(zhuǎn)換為最可能的類;
添加到模型的輸出中，例如使用黑盒模型解釋器并提供預(yù)測解釋(與Indico的方法相同);
實現(xiàn)特定領(lǐng)域的邏輯，例如基于預(yù)測的決策，或接收到異常輸入時的回退;
發(fā)送生產(chǎn)輸入和模型預(yù)測，以便存儲在生產(chǎn)數(shù)據(jù)庫中;
測試新模型，通過查詢預(yù)測(除了“實時”模型之外)并存儲它們;這將允許監(jiān)視器為這些新的候選模型繪制性能指標(biāo)。

模型生命周期管理

如果一個新的候選模型在測試數(shù)據(jù)集中提供了比當(dāng)前模型更好的性能，那么通過讓前端返回這個模型對一小部分應(yīng)用程序的最終用戶的預(yù)測(金絲雀測試)，就可以測試它對應(yīng)用程序的實際影響。這要求評估者和監(jiān)控器實現(xiàn)特定于應(yīng)用程序的性能指標(biāo)。測試用戶可以從列表中選取，也可以通過他們的某個屬性、地理位置選擇，或者完全隨機選擇。在監(jiān)視性能并確信新模型不會破壞任何東西時，開發(fā)人員可以逐步增加測試用戶的比例，并執(zhí)行A/B測試，進一步比較新模型和舊模型。如果新模型被證實更好，前端就會通過總是返回新模型的預(yù)測來“取代”舊模型。如果新模型最終破壞了系統(tǒng)，也可以通過前端實現(xiàn)回滾。