餓了麼推薦演算法演進及線上學習實踐
一、 推薦業務背景
1.1 推薦產品形態
大部分人都熟悉餓了麼app，甚至通過餓了麼app點過外賣。上圖中著重圈出的內容就涉及推薦排序，其中首頁推薦、類目、搜尋構成了整個餓了麼流量的入口，通過這些入口覆蓋了全網90%以上的訂單。
目前餓了麼每天的訂單量達到千萬級別，屬於國內Top級，這就意味著流量分發的效率尤為關鍵，因為它涉及使用者體驗、商戶利益、平臺價值，而演算法就在該領域發揮著重要的價值。
1.2 演算法優化目標
在外賣領域有4個重要環節：流量、供給、轉化和履約，其中演算法在履約環節起著關鍵的作用。
在不同的業務階段想要實現的目標也是不一樣的。業務成長初期，優化app的點選率、轉化率，當用戶點選之後想促成成交；隨後考慮平臺收益就會關注客單價、單均價等；以及後期的滿意度等抽象指標，需要將這些大目標拆解為小目標，分別建立不同的演算法子模型進行優化。
二、 演算法演進路線
從2016年至今，餓了麼主要經歷了資料、特徵、模型、業務理解4個方面的升級。
2.1 資料&特徵升級
資料及特徵方面進行了4個方面的升級：
- 生產方面：將離線資料升級為實時資料；引入Flume、Kafka等實時體系,通過模型打分將業務端實時生成的業務日誌輸出到日誌伺服器，構建樣本時就不需要離線拼接樣本特徵及標籤而是線上生成特徵，進而保證特徵的質量，避免了特徵穿越、特徵不準等問題。
- 時效方面：資料採集從天級別升級為實時，且增加了多維度實時特徵；
- 規模方面：不僅引入大規模的稀疏特徵，而且將item、user、query等業務流程中涉及的環節通過Word2Vector等實現了向量表達。
- 監控方面：在特徵覆蓋及波動、異常值檢測、埋點問題等方面進行了實時監控。
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提取二階特徵的能力，實現了自動提取特徵，是一個端到端的模型。該模型在很長一段時間用於首頁推薦，實驗效果比較理想。
模型經過不斷地演化，現階段外賣推薦系統架構與大部分推薦系統架構類似：
- 資料來源：包括業務日誌、服務端日誌、使用者行為日誌；
- 基礎設施層：包括大資料處理的Spark、Hadoop以及用於實時計算的平臺、工具。可以看出引入了很多開源元件，加入阿里後考慮引入公共基礎設施，避免由於開源元件本身存在的問題困擾業務發展；
- 特徵層：包括商戶、使用者、上下文、交叉組合等維度特徵；
- 模型層：特徵層的資料輸入模型層後呼叫實時資料、使用者畫像等資料服務層；
- 資料服務層：包含實時資料服務、畫像服務、特徵服務等；
- 業務層：結合模型輸出的結果用於線上業務投放等。
三、 線上學習實踐
目前線上學習（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實現線上排序。
目前模型結構相對來說簡單，業務效果的提升主要體現在模型調參，在此簡單地介紹幾個小技巧：
取樣策略：
1）位置截斷：考慮到不可能利用所有的實時樣本，因此會結合業務特點及資料特點進行位置截斷：
如使用者不小心刷到位置特別靠後的列表資料，這部分資料對於預測效果價值不大就會丟棄；
2）業務過濾：之所以存在業務過濾，是因為最後的投放不僅僅取決於演算法結果，也取決於業務規則。如新店的加入或扶持特定的商家，需要將它的排序強行放在首位，這樣帶來訂單量的提升就不是演算法的功勞。
3）根據樣本目標設定樣本權重：根據不同階段的目前進行樣本權重的調整，比如現階段的業務目標是優化GMV，將會調高GMV的樣本權重。
引數更新
為什麼採用定時更新引數的策略，而不是實時更新引數？主要是考慮到工程的難度，線上預測服務不可能實時獲取引數，否則將影響線上服務效能。目前採用5分鐘定時獲取模型引數，保證模型抖動不會太劇烈。若由於樣本延遲造成正負樣本比例發生變化或者特殊情況導致引數發生波動，這樣的更新策略就可保證模型的穩定性 。
樣本不均衡
在外賣場景中，正樣本特別寶貴。假如與跟正樣本相關的訂單資料流由於網路等原因造成延遲導致樣本資料都是正樣本或者負樣本，倘若直接使用這類樣本實時更新模型就會導致模型引數發生巨大的抖動。因此我們目前採取的方式是利用快取儲存這類樣本，然後根據權重拆分樣本，分時段與負樣本進行混合使得樣本的正負比大致穩定，進而解決樣本不均衡的問題。
輸入歸一化
特別是線性模型一般推薦資料歸一化，否則模型收斂速度特別慢。而線上學習模型，由於不是短時間輸入大量樣本，這就使得樣本量相對較小、收斂速度較慢，歸一化後可提升收斂速度。
與此同時採用歸一化後的樣本資料訓練出的權重相對而言是可比較的，業務可解釋性更強。
接下來介紹2個小特色：
視覺化Debug
模型上線後若想知道模型效果或者資料排序依據，就採用加入白名單的方式，將實時收集的排序資料通過頁面的形式同步地將後端打分依據展示出來，包括排名依據、是否融入了業務規則、特徵權重，這樣便於排查特徵缺失等問題。
App端收集的使用者行為資料，如埋點資訊、訂單資訊等，經過資料清洗、聚合後將前後端的資料通過頁面形式呈現出來,這便於模型除錯、線上問題排查。
實時效果對比
結合storm產出的維度列資訊，利用不同的維度進行資料聚合，實現實時效果對比：
- 分演算法版本實時效果：根據不同的演算法版本統計點選率、金額等實現了實時A/B test。
- 分入口實時效果
- 分列表位置實時效果
- 實時特徵監控。