【美團 技術篇】美團推薦算法實踐

一、前言

推薦系統並非新鮮的事物，在好久以前就存在，可是推薦系統真正進入人們的視野，而且做爲一個重要的模塊存在於各個互聯網公司，仍是近幾年的事情。

隨着互聯網的深刻發展，愈來愈多的信息在互聯網上傳播，產生了嚴重的信息過載。若是不採用必定的手段，用戶很難從如此多的信息流中找到對本身有價值的信息。

解決信息過載有幾種手段：

• 一種是搜索，當用戶有了明確的信息需求意圖後，將意圖轉換爲幾個簡短的詞或者短語的組合（即query），而後將這些詞或短語組合提交到相應的搜索引擎，再由搜索引擎在海量的信息庫中檢索出與query相關的信息返回給用戶；

• 另一種是推薦，不少時候用戶的意圖並非很明確，或者很難用清晰的語義表達，有時甚至連用戶本身都不清楚本身的需求，這種狀況下搜索就顯得捉襟見肘了。尤爲是近些年來，隨着電子商務的興起，用戶並不是必定是帶着明確的購買意圖去瀏覽，不少時候是去「逛」的，這種情景下解決信息過載，理解用戶意圖，爲用戶推送個性化的結果，推薦系統即是一種比較好的選擇。

美團做爲國內發展較快的o2o網站，有着大量的用戶和豐富的用戶行爲，這些爲推薦系統的應用和優化提供了不可或缺的條件，接下來介紹咱們在推薦系統的構建和優化過程當中的一些作法，與你們共享。

二、框架

從框架的角度看，推薦系統基本能夠分爲數據層、觸發層、融合過濾層和排序層。

數據層包括數據生成和數據存儲，主要是利用各類數據處理工具對原始日誌進行清洗，處理成格式化的數據，落地到不一樣類型的存儲系統中，供下游的算法和模型使用。

候選集觸發層主要是從用戶的歷史行爲、實時行爲、地理位置等角度利用各類觸發策略產生推薦的候選集。

候選集融合和過濾層有兩個功能，一是對出發層產生的不一樣候選集進行融合，提升推薦策略的覆蓋度和精度；另外還要承擔必定的過濾職責，從產品、運營的角度肯定一些人工規則，過濾掉不符合條件的item。排序層主要是利用機器學習的模型對觸發層篩選出來的候選集進行重排序。

同時，對與候選集觸發和重排序兩層而言，爲了效果迭代是須要頻繁修改的兩層，所以須要支持ABtest[1]。爲了支持高效率的迭代，咱們對候選集觸發和重排序兩層進行了解耦，這兩層的結果是正交的，所以能夠分別進行對比試驗，不會相互影響。同時在每一層的內部，咱們會根據用戶將流量劃分爲多份，支持多個策略同時在線對比。

備註：

① ABtest 概念：

A/B測試是一種新興的網頁優化方法，能夠用於增長轉化率註冊率等網頁指標。AB測試本質上是個分離式組間實驗，之前進行AB測試的技術成本和資源成本相對較高，但如今一系列專業的可視化實驗工具的出現，AB測試已愈來愈成爲網站優化經常使用的方法。

使用A/B 測試首先須要創建一個測試頁面（variation page），這個頁面可能在標題字體，背景顏色，措辭等方面與原有頁面（control page）有所不一樣，而後將這兩個頁面以隨機的方式同時推送給全部瀏覽用戶。接下來分別統計兩個頁面的用戶轉化率，便可清晰的瞭解到兩種設計的優劣。

傳統的A/B測試，是一種把各組變量隨機分配到特定的單變量處理水平，把一個或多個測試組的表現與控制組相比較，進行測試的方式。

新的A / B測試，不只僅其範圍限制在web分析方面，而是爲其注入新生命，即移動設備端分析。Pathmapp聯合創始人兼首席執行官亞當Ceresko表示，今天，開發人員須要大大提升優化工具的性能，移動分析已成爲A/B測試增加最快的一個領域。

三、數據應用

數據乃算法、模型之本。美團做爲一個交易平臺，同時具備快速增加的用戶量，所以產生了海量豐富的用戶行爲數據。固然，不一樣類型的數據的價值和反映的用戶意圖的強弱也有所不一樣。

行爲類別	行爲詳情
主動行爲數據	搜索、篩選、點擊、收藏、下單、支付、評分
UGC	文本評價、上傳圖片
負反饋數據	左滑刪除、取消收藏、取消訂單、退款、負評、低評
用戶畫像	用戶人口屬性、美團DNA、品類偏好、消費水平、工做地與居住地

• 用戶主動行爲數據記錄了用戶在美團平臺上不一樣的環節的各類行爲，這些行爲一方面用於候選集觸發算法（在下一部分介紹）中的離線計算（主要是瀏覽、下單），另一方面，這些行爲表明的意圖的強弱不一樣，所以在訓練重排序模型時能夠針對不一樣的行爲設定不一樣的迴歸目標值，以更細地刻畫用戶的行爲強弱程度。此外，用戶對deal的這些行爲還能夠做爲重排序模型的交叉特徵，用於模型的離線訓練和在線預測。

  
  

• 負反饋數據反映了當前的結果可能在某些方面不能知足用戶的需求，所以在後續的候選集觸發過程當中須要考慮對特定的因素進行過濾或者降權，下降負面因素再次出現的概率，提升用戶體驗；同時在重排序的模型訓練中，負反饋數據能夠做爲不可多得的負例參與模型訓練，這些負例要比那些展現後未點擊、未下單的樣本顯著的多。

  
  

• 用戶畫像是刻畫用戶屬性的基礎數據，其中有些是直接獲取的原始數據，有些是通過挖掘的二次加工數據，這些屬性一方面能夠用於候選集觸發過程當中對deal進行加權或降權，另一方面能夠做爲重排序模型中的用戶維度特徵。

  
  

• 經過對UGC數據的挖掘能夠提取出一些關鍵詞，而後使用這些關鍵詞給deal打標籤，用於deal的個性化展現。

四、策略觸發

上文中咱們提到了數據的重要性，可是數據的落腳點仍是算法和模型。單純的數據只是一些字節的堆積，咱們必須經過對數據的清洗去除數據中的噪聲，而後經過算法和模型學習其中的規律，才能將數據的價值最大化。在本節中，將介紹推薦候選集觸發過程當中用到的相關算法。

一、協同過濾

提到推薦，就不得不說協同過濾，它幾乎在每個推薦系統中都會用到。基本的算法很是簡單，可是要得到更好的效果，每每須要根據具體的業務作一些差別化的處理。

●清除做弊、刷單、代購等噪聲數據。這些數據的存在會嚴重影響算法的效果，所以要在第一步的數據清洗中就將這些數據剔除。

●合理選取訓練數據。選取的訓練數據的時間窗口不宜過長，固然也不能太短。具體的窗口期數值須要通過屢次的實驗來肯定。同時能夠考慮引入時間衰減，由於近期的用戶行爲更能反映用戶接下來的行爲動做。

●user-based與item-based相結合。

	羣體/個體	計算代價	適用場景	冷啓動	可解釋性	實時性
user-based	更依賴於當前用戶相近的用戶羣體的社會化行爲	適用於用戶數較少的場合	時效性強，用戶個性化興趣不太顯著的場合	新加入的物品能很快進入推薦列表	弱	用戶新的行爲不必定致使推薦結果的變化
item-based	更側重用戶自身的個體行爲	適用於物品數較少的場合	長尾物品豐富，用戶個性化需求強烈的場合	新加入的用戶能很快獲得推薦	強	用戶新的行爲必定致使推薦結果的變化

嘗試不一樣的類似度計算方法。在實踐中，咱們採用了一種稱做loglikelihood ratio[1]的類似度計算方法。在mahout中，loglikelihood ratio也做爲一種類似度計算方法被採用。

下表表示了Event A和Event B之間的相互關係，其中：

k11 ：Event A和Event B共現的次數

k12 ：Event B發生，Event A未發生的次數

k21 ：Event A發生，Event B未發生的次數

k22 ：Event A和Event B都不發生的次數

	Event A	Everything but A
Event B	A and B together (k_11)	B, but not A (k_12)
Everything but B	A without B (k_21)	Neither A nor B (k_22)

則logLikelihoodRatio=2 * (matrixEntropy - rowEntropy - columnEntropy)

其中

rowEntropy = entropy(k11, k12) + entropy(k21, k22)

columnEntropy = entropy(k11, k21) + entropy(k12, k22)

matrixEntropy = entropy(k11, k12, k21, k22)

(entropy爲幾個元素組成的系統的香農熵)

二、location-based

對於移動設備而言，與PC端最大的區別之一是移動設備的位置是常常發生變化的。不一樣的地理位置反映了不一樣的用戶場景，在具體的業務中能夠充分利用用戶所處的地理位置。在推薦的候選集觸發中，咱們也會根據用戶的實時地理位置、工做地、居住地等地理位置觸發相應的策略。

●根據用戶的歷史消費、歷史瀏覽等，挖掘出某一粒度的區域（好比商圈）內的區域消費熱單和區域購買熱單

區域消費熱單

區域購買熱單

●當新的線上用戶請求到達時，根據用戶的幾個地理位置對相應地理位置的區域消費熱單和區域購買熱單進行加權，最終獲得一個推薦列表。

●此外，還能夠根據用戶出現的地理位置，採用協同過濾的方式計算用戶的類似度。

三、query-based

搜索是一種強用戶意圖，比較明確的反應了用戶的意願，可是在不少狀況下，由於各類各樣的緣由，沒有造成最終的轉換。儘管如此，咱們認爲，這種情景仍是表明了必定的用戶意願，能夠加以利用。具體作法以下：

●對用戶過去一段時間的搜索無轉換行爲進行挖掘，計算每個用戶對不一樣query的權重。

●計算每一個query下不一樣deal的權重。

●當用戶再次請求時，根據用戶對不一樣query的權重及query下不一樣deal的權重進行加權，取出權重最大的TopN進行推薦。

四、graph-based

對於協同過濾而言，user之間或者deal之間的圖距離是兩跳，對於更遠距離的關係則不能考慮在內。而圖算法能夠打破這一限制，將user與deal的關係視做一個二部圖，相互間的關係能夠在圖上傳播。Simrank[2]是一種衡量對等實體類似度的圖算法。它的基本思想是，若是兩個實體與另外的類似實體有相關關係，那它們也是類似的，即類似性是能夠傳播的。

●Let s(A,B) denote the similarity between persons A and B, for A != B

Let s(c,d) denote the similarity between items c and d, for c != d

O(A),O(B): the set of out-neighbors for node A or node B
I(c),I(d): the set of in-neighbors for node c or node d

●simrank的計算（採用矩陣迭代的方式）

●計算得出類似度矩陣後，能夠相似協同過濾用於線上推薦。

五、實時用戶行爲

目前咱們的業務會產生包括搜索、篩選、收藏、瀏覽、下單等豐富的用戶行爲，這些是咱們進行效果優化的重要基礎。咱們固然但願每個用戶行爲流都能到達轉化的環節，可是事實上遠非這樣。

當用戶產生了下單行爲上游的某些行爲時，會有至關一部分由於各類緣由使行爲流沒有造成轉化。可是，用戶的這些上游行爲對咱們而言是很是重要的先驗知識。不少狀況下，用戶當時沒有轉化並不表明用戶對當前的item不感興趣。當用戶再次到達咱們的推薦展位時，咱們根據用戶以前產生的先驗行爲理解並識別用戶的真正意圖，將符合用戶意圖的相關deal再次展示給用戶，引導用戶沿着行爲流向下游行進，最終達到下單這個終極目標。

目前引入的實時用戶行爲包括：實時瀏覽、實時收藏。

六、替補策略

雖然咱們有一系列基於用戶歷史行爲的候選集觸發算法，但對於部分新用戶或者歷史行爲不太豐富的用戶，上述算法觸發的候選集過小，所以須要使用一些替補策略進行填充。

●熱銷單：在必定時間內銷量最多的item，能夠考慮時間衰減的影響等。

●好評單：用戶產生的評價中，評分較高的item。

●城市單：知足基本的限定條件，在用戶的請求城市內的。

五、子策略融合

爲告終合不一樣觸發算法的優勢，同時提升候選集的多樣性和覆蓋率，須要將不一樣的觸發算法融合在一塊兒。常見的融合的方法有如下幾種[3]：

一、加權型：最簡單的融合方法就是根據經驗值對不一樣算法賦給不一樣的權重，對各個算法產生的候選集按照給定的權重進行加權，而後再按照權重排序。

二、分級型：優先採用效果好的算法，當產生的候選集大小不足以知足目標值時，再使用效果次好的算法，依此類推。

三、調製型：不一樣的算法按照不一樣的比例產生必定量的候選集，而後疊加產生最終總的候選集。

四、過濾型：當前的算法對前一級算法產生的候選集進行過濾，依此類推，候選集被逐級過濾，最終產生一個小而精的候選集合。

目前咱們使用的方法集成了調製和分級兩種融合方法，不一樣的算法根據歷史效果表現給定不一樣的候選集構成比例，同時優先採用效果好的算法觸發，若是候選集不夠大，再採用效果次之的算法觸發，依此類推。

六、候選集重排序

如上所述，對於不一樣算法觸發出來的候選集，只是根據算法的歷史效果決定算法產生的item的位置顯得有些簡單粗暴，同時，在每一個算法的內部，不一樣item的順序也只是簡單的由一個或者幾個因素決定，這些排序的方法只能用於第一步的初選過程，最終的排序結果須要藉助機器學習的方法，使用相關的排序模型，綜合多方面的因素來肯定。

一、模型

非線性模型能較好的捕捉特徵中的非線性關係，但訓練和預測的代價相對線性模型要高一些，這也致使了非線性模型的更新週期相對要長。反之，線性模型對特徵的處理要求比較高，須要憑藉領域知識和經驗人工對特徵作一些先期處理，但由於線性模型簡單，在訓練和預測時效率較高。所以在更新週期上也能夠作的更短，還能夠結合業務作一些在線學習的嘗試。在咱們的實踐中，非線性模型和線性模型都有應用。

●非線性模型

目前咱們主要採用了非線性的樹模型Additive Groves[4]（簡稱AG），相對於線性模型，非線性模型能夠更好的處理特徵中的非線性關係，沒必要像線性模型那樣在特徵處理和特徵組合上花費比較大的精力。AG是一個加性模型，由不少個Grove組成，不一樣的Grove之間進行bagging得出最後的預測結果，由此能夠減少過擬合的影響。

每個Grove有多棵樹組成，在訓練時每棵樹的擬合目標爲真實值與其餘樹預測結果之和之間的殘差。當達到給定數目的樹時，從新訓練的樹會逐棵替代之前的樹。通過屢次迭代後，達到收斂。

●線性模型

目前應用比較多的線性模型非Logistic Regression莫屬了。爲了能實時捕捉數據分佈的變化，咱們引入了online learning，接入實時數據流，使用google提出的FTRL[5]方法對模型進行在線更新。

主要的步驟以下：

●在線寫特徵向量到HBase

●Storm解析實時點擊和下單日誌流，改寫HBase中對應特徵向量的label

●經過FTRL更新模型權重