這裡是「王喆的機器學習筆記」的第二十九篇文章。
最近寫書的時候在總結一些深度學習模型線上serving的主流方法。之前的專欄文章也有所涉及（如何解決推薦系統工程難題——深度學習推薦模型線上serving）。
但是看到阿里媽媽去年KDD上的文章 Practice on Long Sequential User Behavior Modeling for Click-Through Rate Prediction 之後，還是有種相見恨晚的感覺，因為文中提供的model serving的解決方案是自己想實現還未來得及實現的。。所以趕快跟大家分享一下，我想應該能解決不少同學實踐中的問題。
什麼是Model Serving？
一句話解釋就是：
Model Serving解決的是模型離線訓練好之後，如何進行線上實時推斷的問題。
在每個服務器節點動輒幾千上萬QPS的壓力下，必然不可能在tensorflow，spark mllib等訓練環境中進行實時推斷。必須有一個模型服務器來承載模型相關的參數或者數據，進行幾十毫秒級別的實時推斷，這就是model serving面臨的主要挑戰。
Model Serving的主要方法
在之前的專欄文章如何解決推薦系統工程難題——深度學習推薦模型線上serving 中提到了幾種主流的方法，分別是：
- 自研平臺
- 預訓練embedding+輕量級模型
- PMML等模型序列化和解析工具
- TensorFlow serving等平臺原生model serving工具
這裡就不再詳細介紹，感興趣的同學可以回顧一下之前的文章。今天主要想跟大家探討的還是阿里媽媽提出的Model Serving方法 User Interest Center。
什麼是User Interest Center？
先上架構圖
UIC server的架構圖
上圖的(A)和(B)分別代表了兩種不同的模型服務架構，兩圖中部橫向的虛線代表了在線環境和離線環境的分隔。
那麼A架構就代表著一個非常經典的解決方案：離線部分做模型訓練，在線部分根據用戶各類特徵（User Demography Features 和 User Behavior Features）以及廣告特徵（Ad Features），在模型服務器（Real-Time Prediction Server）中進行預估。
這個過程是直觀的，也是看上去天經地義的。但“盛世之下潛藏著危機“啊，問題的關鍵就在於在模型越來越複雜之後，特別是像DIEN或者MIMN這類模型加入序列結構之後，這些序列結構的推斷時間實在是太長了。結構已經複雜到模型服務器在幾十毫秒的時間內根本沒有可能推斷完的地步。
阿里最新的MIMN（Multi-channel user Interest Memory Network）模型
怎麼辦？
阿里的解決方案是圖中的B架構，包括兩大部分：
1.用戶興趣“表達”模塊
B架構將A架構的“用戶行為特徵(User Behavior Features)在線數據庫”替換成了“用戶興趣表達(User Interest Representation)在線數據庫”。
這一變化對模型推斷過程非常重要。無論是 DIEN 還是 MIMN，它們表達用戶興趣的最終形式都是興趣 Embedding 向量。如果在線獲取的是用戶行為特徵序列，那麼對實時預估服務器(Real-time Prediction Server)來說，還需要運行復雜的序列模型推斷過程生成用戶興趣向量。
而如果在線獲取的是用戶興趣向量，那麼實時預估服務器就可以跳過序列模型階段，直接開始 MLP 階段的運算。MLP 的層數相較序列模型大大減少，而且便於並行計算，因此整個實時預估的延遲可以大幅減少。
當然，雖然“用戶興趣表達模塊”這個名字很fancy，但本質上應該是以類似redis的內存數據庫為主實現的。
2. 用戶興趣“中心”模塊
B架構增加了一個服務模塊——用戶興趣中心(User Interest Center，UIC)。 UIC 用於根據用戶行為序列生成用戶興趣向量，對 DIEN 和 MIMN 來說，UIC 運行著生成用戶興趣向量的部分模型。
與此同時，實時用戶行為事件(realtime user behavior event)的更新方式也發生著變化，對A架構來說，一個新的用戶行為事件產生時，該事件會被插入用戶行為特徵數據庫中，而對B架構來說，新的用戶行為事件會觸發 UIC 的更新邏輯，UIC 會利用該事件更新對應用戶的興趣Embedding向量。
這個解決方案讓我覺得優雅的地方在於：
在大幅降低了模型在線推斷複雜度的同時，它居然是準實時的。因為UIC的更新邏輯是用戶的行為發生改變，也就是說用戶的embedding會在行為發生改變時通過模型離線推斷完成更新。某種意義上說，這也可以算是一種模型online learning的方法之一了。
由於embedding的更新過程是離線進行的，與線上實時預估服務器是異步的，因此就不會拖累線上預估的速度。
而由於embedding異步更新的觸發條件是用戶行為的變化，所以embedding的更新也是準實時的。而不像有些embedding一樣，一旦生成，除了下次模型訓練，就不再更新。
採用UIC後Model Serving延遲大幅減少
我們可以根據UIC架構圖中從1到4的圓圈編號再捋一遍Model Serving的過程：
- 流量請求(traffic request)到來，其中攜帶了用戶 ID(User ID)和待排序的候選商品 ID(Ad ID)。
- 實時預估服務器根據用戶 ID 和候選商品 ID 獲取用戶和商品特徵(Ad Features)，用戶特徵具體包括用戶的人口屬性特徵(User Demography Features) 和用戶行為特徵(a 架構)或用戶興趣表達向量(b 架構)。
- 實時預估服務器利用用戶和商品特徵進行預估和排序，返回最終排序結果給請求方。b架構對最耗時的序列模型部分進行了拆解，因此大幅降低了模型服務的總延遲。
- 返回模型預估結果。
根據阿里巴巴公開的數據，每個服務節點在 500 QPS(Queries Per Second， 每秒查詢次數)的壓力下，DIEN 模型的預估時間從 200 毫秒降至 19 毫秒。這無疑是從工程角度優化模型服務過程的功勞。
當然也可以看到，阿里的UIC架構還是遵循了“Embedding+輕量級線上模型”的部署方案，只不過利用UIC對Embedding部分的生成、存儲、更新進行了近乎完美的管理。可以說是“Embedding+輕量級線上模型”這種Model Serving方法的best practice。
總結
這篇文章介紹了阿里媽媽的線上Model Serving的方法User Interest Center，它把模型拆解為線上部分和線下部分，模型複雜的序列結構在線下運行，利用UIC生成和更新Embedding，結果存儲在“用戶興趣表達模塊”；線上實現模型較為輕量級的MLP部分，使模型能夠利用更多的特徵進行實時預估。
可以說這是一次機器學習理論和機器學習工程系統完美結合的方案，推薦受困於model serving效率和實時性的團隊嘗試。
照例給大家提出兩個問題討論：
- UIC中用戶Embedding更新的觸發方式到底是應該是什麼？是Real-time prediction server接收到的一次用戶請求，還是通過flink處理的一個window內部的用戶行為？如果你是工程師，你會採用哪種方法？兩種方法的優缺點是什麼？
- 為什麼一定要把序列模型放到離線進行處理，序列模型線上inference的速度就真的沒有方法提高嗎？你有什麼經驗？
最後歡迎大家關注我的微信公眾號：王喆的機器學習筆記（wangzhenotes），跟蹤計算廣告、推薦系統等機器學習領域前沿。
想進一步交流的同學也可以通過公眾號加我的微信一同探討技術問題。另外很多同學通過知乎和微信詢問我書的事情，出版社剛剛通知我下週就應該能夠上市了，希望到時候大家多支持，謝謝！
閱讀更多 王喆的機器學習筆記 的文章
