廣告和推薦系統是機器學習是最成熟的應用領域。那么廣告和推薦系統是怎么在線上部署機器學習模型的呢?

[[215577]]

1. 預測函數上線

剛剛學習機器學習時候，我認為廣告和推薦系統過程如下圖所示：

• 線下部分，從用戶和廣告(物品)屬性抽取用戶和物品特征，將抽取的特征合并進日志生成訓練數據，訓練機器學習模型;
• 線上部分，來了一個請求，從用戶和廣告(物品)屬性抽取請求中的用戶和物品的特征，將這些特征合并請求生成預測實例，用線上模型得到預測結果。

但是這個架構有兩個問題：

(1) 從用戶和廣告(物品)屬性抽取特征的程序有線上線下兩套，這兩套程序必須保持完全一致。但由于調參的原因，特征抽取是機器學習系統中最經常發生變化的模塊。經常變化的模塊需要保持一致，這很困難。

那么我們能不能強行地用一套程序呢?比如，我們把特征抽取和特征處理模塊寫成 .so 文件。這樣也有問題：線下要求快速變化以方便工程師調特征，可能會使用一些訓練框架(比如 Spark);

線上要求程序快速實時，要求工程師編碼嚴謹。寫成嚴謹的 .so 文件，能夠保證線上的需求，但無法快速變化，也不能在 Spark 上使用。

(2) 線上特征抽取要求非常快速，特別在線上吞吐量很大的情況。但有些重度特征不可能在短時間內抽取出來，比如廣告的歷史點擊率(生成這個特征需要遍歷一段時間的點擊日志)。

在讀書期間，這兩個問題困擾了我很久, 直到我知道了神器 Redis。Redis 是一個開源內存數據庫，支持集群模式、持久化和 Key-Value 數據結構。

在使用時，我們可以將 Redis 看成一個巨大的哈希表。Redis 在后臺開發中經常用作 cache 服務器, 后來被工程師們用于廣告和推薦系統中的特征服務器。

工程師將用戶和廣告(物品)的 ID 作為 Key，將用戶和廣告(物品)的特征作為 Value 存入 Redis，這樣線上程序只需要用戶和廣告(物品)的 ID 就能知道特征。

引入 Redis 之后，廣告和推薦系統過程如下所示：

• 線下部分，從用戶和廣告(物品)屬性抽取用戶和廣告(物品)特征，把抽取的特征合并進日志生成訓練數據用于訓練機，并把抽取的特征上載到線上 Redis 服務器;
• 線上部分，來了一個請求，從 Redis 服務器取出用戶和廣告(物品)特征，將特征合并進請求生成預測實例，用線上模型得到預測結果。

這種架構還有一個變種：在線下抽取特征之后不生成訓練數據而是直接送到 Redis，在線上用 Storm 實時拼接訓練數據。但我對這個變種的前因后果不太了解，就不展開討論了。

這種架構將預測函數(也就是訓練出來的模型)部署在線上。為了和下面的架構區分開來，我們將這種架構稱為預測函數上線架構。

2. 預測結果上線

了解預測函數上線架構之后，我將之作為廣告和推薦系統線上部署模型的 “正統”。 因此當我接觸到另一種架構時，我內心是拒絕的。

這種架構的要點在于把預測結果上線，具體過程如下所示：

• 在線上，從用戶和廣告(物品)屬性抽取用戶和物品特征，將抽取的特征合并進日志生成訓練數據，訓練機器學習模型;將幾乎所有可能的請求合并特征，進而生成預測實例，用模型得到預測結果;
• 線上就很簡單了，接入線下傳過來的預測結果。這里稍微難理解的是 “窮盡幾乎所有可能的請求”，疑惑那么多可能的請求怎么可能窮盡呢?微博廣告系統(虛構的)所有可能的請求貌似很多，但每個用戶只需要匹配若干個廣告就行了。因此微博廣告系統的預測結果 “userid,adid1,adid2…,adidn” 上載到線上，一旦線上傳一個 userid 請求展示廣告，線上模塊就按照一定的邏輯返回預測結果中這個用戶對應的廣告。

這種架構是將預測結果部署到線上，我們將之稱為預測結果上線架構。

慢慢地我也開始明白預測結果上線的好處了。預測結果上線架構將機器學習全過程和絕大部分控制邏輯都搬到線下，規避了線上的各種隱患。這樣不那么厲害的工程師用不那么厲害的機器也能搞定線上模塊了，畢竟線上模塊只需要實現少量的控制邏輯和展示。這大大降低了建立一個廣告系統或者推薦系統的難度。

我正式工作之后，組里支持運營活動的推薦系統采用了預測結果上線的架構。我發現有不少時間浪費在重跑數據上，原因在于有時需要臨時增加或者刪除物品。一旦增加或者刪除物品，預測結果上線的推薦系統就需要重新生成預測數據(因此之前跑的數據要么沒有要加的物品，要么有要刪的數據)。

另外一個問題就是預測結果上線架構有延時性：今天線上展示的是昨天準備的預測結果，今天準備的預測結果要等明天才能展示，這會導致節奏慢一些。***還有一個問題，預測結果上線架構只適用于幾乎所有可能的請求能夠窮盡的場景。比如，預測結果上線架構不適用于搜索廣告系統，因為搜索廣告系統不能窮盡所有可能的請求。

3. 總結

預測函數上線架構能夠覆蓋預測結果上線架構的適用場景，但是預測結果上線架構不能夠覆蓋預測函數上線架構的適用場景。同時預測函數上線架構更具靈活性。預測函數上線架構不愧為部署機器學習模型的 “堂堂正正” 之法。

預測結果上線架構的好處就是難度比較低。預測結果上線架構將機器學習全過程和絕大部分控制邏輯，規避了線上的各種隱患。在機器、時間和人力等各種條件不充足的情況，預測結果上線架構不失為一個好的選擇。預測結果上線架構是 “劍走偏鋒” 的機器學習模型部署之法。兵法有云：以正合以奇勝，選擇哪一種架構還是需要仔細的分析和權衡。

【本文為51CTO專欄作者“王森豐”的原創稿件，轉載請注明出處】

戳這里，看該作者更多好文