作者：Robbe Sneyders

編譯：ronghuaiyang

導讀

給大家介紹一下如何在生產中部署基於嵌入的機器學習模型。

由於最近大量的研究，機器學習模型的性能在過去幾年裡有了顯著的提高。雖然這些改進的模型開闢了新的可能性，但是它們只有在可以部署到生產應用中時才開始提供真正的價值。這是機器學習社區目前面臨的主要挑戰之一。

部署機器學習應用通常比部署傳統軟體應用程式更複雜，因為引入了一個額外的變化維度。雖然典型的軟體應用程式可以更改其代碼和數據，但是機器學習應用程式還需要處理模型的更新。模型更新的速度甚至可以非常高，因為模型需要定期地根據最新的數據進行再訓練。

本文將描述一種更複雜的機器學習系統的一般部署模式，這些系統是圍繞基於嵌入的模型構建的。要理解為什麼這些系統特別難以部署，我們首先要看看基於嵌入的模型是如何工作的。

基於嵌入的模型

基於嵌入的模型正在所有機器學習領域中出現。它們最近在NLP領域掀起了一場革命，是大多數現代推薦系統的核心。谷歌使用嵌入來為搜索查詢找到最佳結果，而Spotify使用嵌入來生成個性化的音樂推薦。

簡單地說，這些模型將它們的輸入投射或「嵌入」到向量表示或嵌入中。視覺模型嵌入圖像，語言模型嵌入單詞或句子，而推薦系統對用戶和物品做同樣的事情。

生成的嵌入非常強大，因為它們可以以相對低的維數來描述數據集的結構。在得到的向量空間中，相似的輸入記錄被緊密地映射在一起，而不同的物品被映射到相隔很遠的地方。這可以用來比較複雜的物品，這在原始數據空間中是不可能的。

這些嵌入可以在不同數據域的模型之間共享，解決新問題的新模型可以構建在這些模型之上。不難想像，這樣一個完整的機器學習模型系統會有多大的價值。

基於嵌入的系統

不幸的是，單個嵌入本身並不是很有用，只有與其他嵌入進行比較才會變得強大。由於每次都重新計算所有嵌入是不可行的，而且常常是不可取的，所以它們通常是預先計算好的，並保存在實時數據存儲中以供比較。

這正是這些系統難以部署的原因。每次模型更新時，都需要重新計算所有的嵌入。對於具有數百萬條記錄的系統，這可能需要很長時間，在此期間，系統的正常操作不能受到影響。即使在較小的系統中，這樣的更新也不是即時的，如果管理不當，可能會導致不一致的結果。

我們將研究兩個基於嵌入的系統，搜尋引擎和推薦系統，並定義一個適用於這兩個系統的通用部署策略。雖然這些系統是相似的，但它們的差異足以為廣泛的基於嵌入的系統提供泛化。

搜尋引擎

我們的搜尋引擎的目標是為搜索查詢找到最匹配的文檔。它由三個組件組成：應用程式、模型和嵌入數據存儲。當應用程式接收到搜索查詢時，它調用模型將查詢轉換為嵌入，然後使用該模型在數據存儲中的文檔嵌入中執行相似性搜索。

推薦系統

我們的推薦系統的目標是向用戶推薦最感興趣的項目。它包含三個組件：應用程式、用戶嵌入數據存儲和物品嵌入數據存儲。要向用戶推薦物品，應用程式首先從用戶數據存儲中獲取用戶的嵌入，然後使用它在物品數據存儲中執行相似度搜索。

這兩個系統最大的區別是在搜尋引擎中存在一個在線模型，而所有的嵌入都是在推薦系統中預先計算好的。但是，在這兩個系統中可以識別出相同的三個功能組件：

• 嵌入生成器，根據其輸入返回嵌入結果。在搜尋引擎中，是通過模型將搜索查詢轉換為嵌入。在推薦系統中，是通過id來從數據存儲中得到用戶的嵌入。
• 嵌入伺服器，它託管預先計算的嵌入來進行相似度搜索。
• 應用程式，它從嵌入生成器中獲取嵌入，並將其發送到嵌入伺服器執行相似搜索。

我們使用這個通用系統演示部署模式。

不停機部署新模型

當對模型進行再訓練或調優時，數據在嵌入空間中表示的方式將發生變化。為了獲得一致的結果，嵌入生成器返回的嵌入和存儲在嵌入伺服器中的嵌入應該由相同的模型版本生成。

準備新模型部署的第一步是使用新模型重新計算系統中所有記錄的嵌入，並將它們存儲在新的數據存儲中。最直接的方法是批量計算，與實際系統分離。重新計算所有嵌入後，新的嵌入生成器和伺服器就可以部署到活動系統中。

一種簡單的方法可能是嘗試同時部署新的嵌入生成器和伺服器。但是，即使它們都可以完全同步地切換到新版本，這在實踐中很難實現，這種方法仍然不足以保證一致的結果。來自舊的嵌入生成器的過時的嵌入可能已經在運行中，並且只有在更新之後才能到達嵌入伺服器，從而導致相似度搜索不匹配。

很明顯，為了確保連續性，從單個應用程式調用的角度來看，更新應該是原子性的。當應用程式從生成器獲取嵌入時，它應該始終在具有匹配版本的嵌入伺服器中執行相似度搜索。為了實現這一點，兩個組件的新舊版本至少需要同時部署，在此期間，兩個版本之間的切換可以在應用程式調用級別進行。之後，舊版本可以簡單地刪除。

圖3顯示了如何以這種方式將連續的應用程式調用切換到新版本，而不會導致任何停機或不一致。

進入流模式

現代系統通常比我們最初引入的簡單系統更複雜，因為它們處理的數據需要不斷更新。新文件需要添加到我們的搜尋引擎，或現有的文件可能得到更新。新用戶可以訂閱我們的推薦系統或更新他們的資料，而新的物品可以定期添加到目錄中。

有些系統可能可以通過批量計算這些更改，並定期用新的數據存儲替換舊的數據存儲，但是這樣做會在系統中出現新的或更新的記錄之前增加很大的延遲。隨著流更新成為越來越多系統的需求，需要一種流本地部署策略。為了得到這個策略，我們將首先重新引入我們的搜尋引擎和推薦系統作為流式系統。

升級我們的搜尋引擎流更新幾乎是微不足道的，因為它已經託管了一個在線嵌入計算模型，可以在數據加載期間重用該模型進行流推理。系統中引入了一個新的數據加載器組件，用於編排傳入的文檔更新。它首先將傳入文檔嵌入在線模型，並將生成的嵌入寫入嵌入數據存儲。

升級我們的推薦系統需要更多的努力，因為流式更新需要一個在線模型，這以前不是系統的一部分。在添加了在線模型和數據加載器組件之後，數據加載流相當於搜尋引擎的數據加載流。數據加載器首先調用在線模型來嵌入項和用戶，並將生成的嵌入寫入相應的數據存儲。

由於兩個系統是等價的，為了簡單起見，我們將使用搜尋引擎來演示流模型的部署。

流式模型的部署

我們現在將把它集成到流系統本身中，而不是在批處理中單獨預先計算新版本的所有嵌入。作為第一步，模型的新版本和新的數據存儲將與原始版本一起部署。為了確保在加載期間沒有流更新丟失，它們被定向到兩個版本。然後啟動系統中所有記錄的大容量負載，並僅將其路由到模型和數據存儲的新版本。

當批量加載完成時，兩個版本包含相同的數據記錄，但是使用各自模型計算的嵌入。這種狀態與我們討論的批處理系統的狀態相同，就像之前應用程式可以輕鬆地將流量切換到新版本一樣。一旦切換完成，就可以刪除舊版本。

這種方法的另一個優點是，流計算和批量負載計算都使用相同的組件，從而始終得到一致的結果。對於搜尋引擎，同樣的模型組件也用於在線搜索嵌入，以防止在線計算和預計算嵌入之間的不匹配。

模型的A/B測試

對於部署在生產環境中的系統，很有可能活動版本的組件已經擴展以處理傳入的負載。版本之間的硬切換可能會給新版本帶來太多的負載。由於兩個版本應該同時可用，所以流量可以逐漸地轉移到新版本，使其有時間根據根據需要進行擴展。這也減少了在部署新版本時可能出現的任何問題的影響，因為如果需要，可以停止或逆轉轉換。

同樣的機制可以用於新模型A/B測試，以固定的百分比凍結流量。然後可以評估新模型並與活動模型進行比較，然後再決定是否應該完成部署或回滾部署。由於加載完整的數據集可能很貴，因此自動測試可以在加載期間使用相同的機制在有限的生產數據集上對新模型進行基準測試。

總結

為了開始享受機器學習研究帶來的模型改進，我們需要能夠將它們部署到生產應用中。基於嵌入的模型為跨域開發了新的可能性，但由於系統中的所有嵌入都需要針對每個模型版本重新計算，因此很難部署。

我們描述了這些基於嵌入的模型的一般部署策略，它部署了模型和嵌入存儲的新版本，與以前的版本一起，因此系統可以輕鬆地切換。我們擴展了流系統的策略，並展示了它是如何支持A/B測試的。

有了這個部署策略和A/B測試，我們可以快速疊代新的模型改進並加速進一步的研究。

英文原文：https://blog.ml6.eu/a-general-pattern-for-deploying-embedding-based-machine-learning-models-bf12e8979070