餓了么推薦算法演進及在線學習實踐

本次分享的主要內容包括以下三個方面:首先是介紹推薦業務背景，包括推薦產品形態及算法優化目標；然后是算法的演進路線；最后重點介紹在線學習是如何在餓了么推薦領域實踐的。

一、推薦業務背景

1.1 推薦產品形態

大部分人都熟悉餓了么App，甚至通過餓了么app點過外賣。上圖中著重圈出的內容就涉及推薦排序，其中首頁推薦、類目、搜索構成了整個餓了么流量的入口，通過這些入口覆蓋了全網90%以上的訂單。

目前餓了么每天的訂單量達到千萬級別，屬于國內Top級，這就意味著流量分發的效率尤為關鍵，因為它涉及用戶體驗、商戶利益、平臺價值，而算法就在該領域發揮著重要的價值。

1.2 算法優化目標

在外賣領域有4個重要環節：流量、供給、轉化和履約，其中算法在履約環節起著關鍵的作用。

在不同的業務階段想要實現的目標也是不一樣的。業務成長初期，優化app的點擊率、轉化率，當用戶點擊之后想促成成交；隨后考慮平臺收益就會關注客單價、單均價等；以及后期的滿意度等抽象指標，需要將這些大目標拆解為小目標，分別建立不同的算法子模型進行優化。

二、算法演進路線

從2016年至今，餓了么主要經歷了數據、特征、模型、業務理解4個方面的升級。

2.1 數據&特征升級

數據及特征方面進行了4個方面的升級：

1）生產方面：將離線數據升級為實時數據；

引入Flume、Kafka等實時體系,通過模型打分將業務端實時生成的業務日志輸出到日志服務器，構建樣本時就不需要離線拼接樣本特征及標簽而是在線生成特征，進而保證特征的質量，避免了特征穿越、特征不準等問題。

2）時效方面：數據采集從天級別升級為實時，且增加了多維度實時特征；

3）規模方面：不僅引入大規模的稀疏特征，而且將item、user、query等業務流程中涉及的環節通過word2Vector等實現了向量表達。

4）監控方面：在特征覆蓋及波動、異常值檢測、埋點問題等方面進行了實時監控。

2.2 模型升級

最初通過人工規則提取特征，基于人工經驗敲定采用的因子及權重，線上進行A/B Test實驗。當線上效果不太滿意時，再次修改因子或權重，這樣不僅浪費了時間，而且浪費了很大的流量。

16年上線了簡單的LR線性模型，通過機器學習的方法獲得各因子權重，與此同時引入用戶維度信息，這一階段形成了個性推薦的雛形。相對于人工規則，點擊率、轉化率提升了10%。

16年底采用了非線性模型，包括GBDT樹模型、FM等，相對于線性模型，在特征交叉表達方面效果提升明顯。16年底我們上線了第一版本XGBoost點擊率預估，隨后基于業務的理解將其拆分為點擊率、轉化率2個子模型，并引入用戶、商戶的實時反饋特征，如用戶點擊某個餐廳、餐廳近一個小時或者一天的情況，效果提升7%-8%。可見用戶維度信息增多了，特征維度豐富了，模型結構復雜了，真正做到了千人千面個性化推薦。

從17年餓了么開始在推薦領域嘗試使用深度學習及在線學習。目前在線學習已應用在餓了么的很多業務場景。

下面簡單介紹Wide&Deep、DeepFM兩個深度學習模型是如何應用在餓了么推薦排序領域。

（一）Wide&Deep

初始階段參照google發表的論文，復用GBDT模型使用的特征，將用戶稀疏特征、商戶稀疏特征輸入線性部分，在沒有引入更多特征的前提下，相對于base版本效果沒有特別大的突破。

隨后將用戶稠密特征等加入Deep部分，將GBDT的葉子節點通過One-Hot或者重新編碼的方式加入Wide部分，效果有了較大的提升。

但是模型結構復雜度的增加使得在線預測達不到工程響應時間要求。現階段模型一直在優化，在業務低峰期仍使用此模型，業務高峰期工程上采用降級的方式。

（二）DeepFM

隨后嘗試了DeepFM，總體結構和論文保持一致，充分利用DNN提取高階特征組合以及FM提取二階特征的能力，實現了自動提取特征，是一個端到端的模型。該模型在很長一段時間用于首頁推薦，實驗效果比較理想。

模型經過不斷地演化，現階段外賣推薦系統架構與大部分推薦系統架構類似：

1）數據來源：包括業務日志、服務端日志、用戶行為日志；

2）基礎設施層：包括大數據處理的Spark、Hadoop以及用于實時計算的平臺、工具。可以看出引入了很多開源組件，加入阿里后考慮引入公共基礎設施，避免由于開源組件本身存在的問題困擾業務發展；

3）特征層：包括商戶、用戶、上下文、交叉組合等維度特征；

4）模型層：特征層的數據輸入模型層后調用實時數據、用戶畫像等數據服務層；

5）數據服務層：包含實時數據服務、畫像服務、特征服務等；

6）業務層：結合模型輸出的結果用于在線業務投放等。

三、在線學習實踐

目前在線學習（Online Learing）這幾年比較熱門，利用一年左右的時間，從無到有搭建了在線學習。

3.1 在線學習的特點

為什么要做在線學習？很多時候我們會遇到類似問題:利用離線數據訓練的模型效果很好，而在線效果卻不理想。這就意味著離線評測與在線效果之間存在很大的gap。

這是什么原因造成的呢？主要是由于數據分布數據時刻發生變化，特別是外賣業務，用戶在不同的時間段會選擇不同類型的外賣，而商戶會隨時上線各種營銷活動，這就使得數據分布范圍、分布趨勢發生很大的變化。

而在線學習的優勢就是利用實時收集的樣本數據及用戶反饋實時更新模型參數進行預估，最后進行最新的投放，進而實時反饋用戶興趣愛好等變化帶來的影響。

在線學習與離線學習的一個重要區別是它可以簡單地理解為數據集無限大，時間序列無限長。它不需要存儲大量的樣本數據，而是利用樣本流數據逐條地更新模型，樣本學習完成后丟棄。這就避免了離線模型隨著數據量增大導致模型無法訓練，即便采用分布式訓練，訓練速度也會變慢。

最后，總結在線學習的特點：

3.2理論基礎

FTRL模型是參照谷歌發表的論文實現的，模型參數、響應速度均可達到電商領域或推薦領域的生產要求。

3.3 在線學習技術棧

在線學習使用的技術棧包括以下幾個方面，引入了很多的開源組件：

3.4 在線學習流程圖

現階段在線學習流程圖如下：

最左側是實時效果歸屬：基于在線排序引擎實時收集業務日志、用戶行為日志，利用storm聚合生成一個實時樣本流；然后進入在線模型訓練實時消費樣本流，利用FTRL模型實時更新參數，在不同時間將模型參數快照定時存入redis。說到快照的好處，它不僅支持模型增量學習，而且即使模型訓練終止，也可以加載歷史參數從某個節點重新進行模型訓練。

在線預測：定時拉取redis中的模型參數提供線上預測服務。至于為什么采用定時更新參數，稍后給出答案。

上述三個模塊最終能夠形成一個閉環，關鍵在于將所有的數據源join起來。

那么又是如何做到將所有的數據源join起來，在此特別介紹一下實時歸屬模塊。將用戶行為、服務端日志、訂單日志等數據經過清洗、過濾等，在Storm中利用唯一id將整個業務join起來。在整個數據體系設計過程中給每一次排序打上唯一id，在整個的業務流程環節中標記此id。特別地，Storm對狀態管理支持不是特別好，目前通過web存儲的方式進行狀態管理，防止任務掛了丟失狀態信息。

通過Storm 聚合之后可以產出時間列、維度列、事實列三種基礎效果數據，其中時間列包括數據產生的時間節點即時間戳等；維度列主要包含數據的入口、位置、業務場景、特征等信息；事實列包括信息是否曝光、用戶是否點擊、購買以及購買金額、商品信息等。

三種基礎效果數據相當于樣本特征及標簽，可用于在線學習，對應的模型結構如下：

從模型結構上來看，將GBDT與FTRL進行了融合：基于實時樣本流，利用點擊 GBDT模型、下單GBDT模型產出葉子節點進行編碼，原始特征分桶或者離散后加入模型，利用FTRL更新模型參數存入redis實現在線排序。

目前模型結構相對來說簡單，業務效果的提升主要體現在模型調參，在此簡單地介紹幾個小技巧：

n 采樣策略：

1）位置截斷：考慮到不可能利用所有的實時樣本，因此會結合業務特點及數據特點進行位置截斷：

如用戶不小心刷到位置特別靠后的列表數據，這部分數據對于預測效果價值不大就會丟棄；

2）業務過濾：之所以存在業務過濾，是因為最后的投放不僅僅取決于算法結果，也取決于業務規則。如新店的加入或扶持特定的商家，需要將它的排序強行放在首位，這樣帶來訂單量的提升就不是算法的功勞。

3）根據樣本目標設置樣本權重：根據不同階段的目前進行樣本權重的調整，比如現階段的業務目標是優化GMV，將會調高GMV的樣本權重。

n 參數更新

為什么采用定時更新參數的策略，而不是實時更新參數？主要是考慮到工程的難度，在線預測服務不可能實時獲取參數，否則將影響在線服務性能。目前采用5分鐘定時獲取模型參數，保證模型抖動不會太劇烈。若由于樣本延遲造成正負樣本比例發生變化或者特殊情況導致參數發生波動，這樣的更新策略就可保證模型的穩定性。

n 樣本不均衡

在外賣場景中，正樣本特別寶貴。假如與跟正樣本相關的訂單數據流由于網絡等原因造成延遲導致樣本數據都是正樣本或者負樣本，倘若直接使用這類樣本實時更新模型就會導致模型參數發生巨大的抖動。因此我們目前采取的方式是利用緩存存儲這類樣本，然后根據權重拆分樣本，分時段與負樣本進行混合使得樣本的正負比大致穩定，進而解決樣本不均衡的問題。

n 輸入歸一化

特別是線性模型一般推薦數據歸一化，否則模型收斂速度特別慢。而在線學習模型，由于不是短時間輸入大量樣本，這就使得樣本量相對較小、收斂速度較慢，歸一化后可提升收斂速度。

與此同時采用歸一化后的樣本數據訓練出的權重相對而言是可比較的，業務可解釋性更強。

接下來介紹2個小特色：

n 可視化Debug