搜索實時個性化模型——基於FTRL和個性化推薦的搜索排序優化

本文來自網易雲社區

 

做者：穆學鋒

 

簡介：傳統的搜索個性化作法是定義個性化的標籤，將用戶和商品經過個性化標籤關聯起來，在搜索時進行匹配。傳統作法的用戶特徵基本是離線計算得到，不夠實時；個性化標籤雖然具備必定的泛化能力，可是其準確性有所不足，不能很好的作精準個性化。本文提出兩個創新優化，一是打通實時用戶行爲的獲取流程，並在實時用戶流下采用FTRL算法不斷的更新用戶特徵的權重，將用戶實時感興趣的商品加權，達到online training；二是在保證相關性的前提下，採起推薦的思路，避開打個性化標籤，結合用戶的實時&歷史行爲，直接預估用戶對商品的偏好，並在搜索排序中加權。這兩個優化在實際的ABTest結果中表現突出，提高搜索下窄口徑UV價值較大，它們都是在用戶實時行爲的基礎上完成的，所以合稱爲搜索實時個性化模型。

背景

搜索中傳統的個性化應用是基於個性化標籤來完成的。例如，咱們會假設用戶在購物時對商品的某些屬性有獨特的偏好，而後創建屬性標籤，並基於用戶的歷史行爲構建算法模型將商品上的標籤打到用戶身上，預估其偏好程度，這就構成了用戶在特定類目下對於某屬性標籤的偏好。模型一旦創建起來，屬性標籤就構成了一個商品簇，模型的泛化能力會很強。這種方式在用戶對某類目的商品行爲量巨大時會比較有效，可是通常狀況下用戶的行爲都會比較分散/稀疏，所以模型的準確性通常不高。舉個例子，用戶A購買了一件有大嘴猴圖案的莫代爾T恤，由於是購買行爲，是一個表示強偏好的特徵，那麼模型最後計算出來大機率會顯示用戶A對於動物圖案標籤和材質莫代爾標籤都有必定的偏好，但實際上呢，可能用戶A關心的只是T恤是圓領的。

怎麼辦呢？一種方法是豐富個性化標籤，將領型標籤也加入進去，這將是一個很龐大很漫長的profiling構建過程。另外一種方法，咱們能夠轉變下思路，用戶A對商品B有行爲，那麼就是A對B有必定的偏心。所以，咱們只要獲取用戶A全部行爲過的商品集合，而後構建模型計算最感興趣的幾個商品，並推給用戶。至於，用戶是喜歡B的什麼特質，什麼緣由，咱們並不用刻畫。由於特質太多，咱們目前刻畫得並很差。

系統框架   

要實現咱們的思路解決上述的問題，首先得在搜索中得到實時的用戶行爲流數據。爲此，咱們設計並實現了以下的系統結構：

 

從Offline到Nearline再到Online，全方位無死角地獲取了用戶近期的行爲數據，存儲到ncr緩存中，行爲包括點擊、加購、收藏、購買、搜索等等。離線（Offline）任務從hdfs中收集用戶在考拉 App端的近期對商品的歷史行爲數據，計算曆史行爲特徵，每日都dump到緩存中；準實時（Nearline）任務將用戶近一小時的行爲收集並格式化後也放入NCR緩存；實時（Online）任務直接在Jstorm中解析用戶行爲日誌，梳理須要的行爲數據，插入到緩存。這樣用戶近期的全部行爲及其特徵都可以在搜索被檢索到。

同時，Jstorm在解析用戶行爲的同時，利用FTRL算法，進行online training，不斷的迭代學習用戶特徵權重；另外一方面，離線部分每日會計算一個用戶到商品的偏好模型（UserItemPrefer），這兩個模型的參數都會存儲到NCR中。

用戶在考拉APP中對商品的每次行爲數據，都會影響FTRL模型和UserItemPrefer模型的參數和特徵。當用戶來搜索的時候，SR會對NDIR召回的商品集合再從新精排一次，精排時就會從NCR獲取個性化標籤、UserItemPrefer&ftrl模型的參數，以及用戶歷史&實時的行爲特徵，計算一個排序分數。SR按這個分數再加上一些例如無貨沉底、重複商品過濾等的業務邏輯，向上層返回排好序的商品列表。用戶在當前搜索結果頁的行爲，都會由這個數據流影響到FTRL模型參數，以及U2I的用戶行爲特徵，從而達到隨着用戶行爲變化，自動學習其個性化偏好的目的。

 

算法實現

1. FTRL模型的實現

根據用戶實時行爲，生成相應的特徵，使用FTRL模型，實時更新用戶的偏好模型。FTRL算法以下：  

 

對算法的兩點修正：  

• FTRL在每一個特徵維度上作梯度降低，隨着用戶行爲的累積，頻繁更新的特徵權重更新步長愈來愈小，趨於一個穩定的值，而實際上用戶的關注點會隨時間變化，累積的特徵並不必定產生正向的效果，所以增長了時間維度，記錄每一個維度特徵更新的時間，根據時間進行衰減。

• FTRL具備比較好的稀疏性，可是用戶的實時行爲會產生大量的特徵，仍是會有不少低頻特徵的權重不爲0，保存在用戶模型裏，一方面使得用戶模型太大，另外一方面對效果影響也不大，所以，對FTRL輸出的特徵再進行一輪篩選：1)最近1小時的特徵按時間保留TOP100；2)最近12小時的特徵按權重保留TOP100；3)全部特徵按權重保留TOP100。

2. UserItemPrefer   模型的實現

• 描述：選擇點擊、加購、收藏、購買等行爲構成特徵，預估用戶對商品偏好程度

•       樣本：

–      歷史user-goods pair

–      Target：當日搜索是否有點擊

•       特徵：

–      User-goods pair維度的特徵

–      Goods維度的特徵

•       機器學習方法：SPARK-LR

•       訓練結果：經調試，AUC 0.73

效果展現

1. FTRL模型

• demo示例：

這是線上某用戶的行爲序列：   用戶首先搜了「拖鞋」，點擊了商品1464699 ，翻幾頁以後又搜索了"melissa "這個品牌，最終購買了商品1511276。

2017-06-04 20:41:48 search 拖鞋 iOS  

2017-06-04 20:41:55 click 1464699 iOS  

......  

2017-06-04 21:05:32 cart_page iOS  

2017-06-04 21:05:44 pay 1511276* -  

在搜索結果中商品位置的變化，(紅框中的是商品1511276)：  

沒有用戶實時模型的商品排序：  

   
 

增長了用戶實時模型的商品排序：  

 

• 測試效果：總共進行兩輪迭代，測試時間段分別爲：2017-02月初~2017-02月中和2017-05月底~2017-06月初整體增長窄口徑UV價值3%

2.  UserItemPrefer   模型

• 測試方法：搜索內ABTest

• 測試時間： 2017.05月底~2017.06月初

• 測試結果：通過11天的線上測試，窄口徑UV價值提高2.55%。

3. 補充說明

• A/B測試：簡單來講，就是爲同一個目標制定兩個方案（好比兩個頁面、兩個算法），讓一部分用戶使用 A 方案，另外一部分用戶使用 B 方案，記錄下用戶的使用狀況，看哪一個方案更符合設計。其實這是一種「先驗」的實驗體系，屬於預測型結論，與「後驗」的概括性結論差異巨大。A/B測試的目的在於經過科學的實驗設計、採樣樣本表明性、流量分割與小流量測試等方式來得到具備表明性的實驗結論，並確信該結論在推廣到所有流量可信。

• 關於A/B Test指標增加的說明：各位看官可能以爲增加2%有點微不足道，但對於算法模型來講，已經比較可觀了。首先，A/B測試比對的二者是剔除了天然增加、大促等其餘因素的，是純算法帶來的增加，比較真實可靠。另外，舉個業界的實例：通常淘寶會由幾十人組件一個大項目團隊，通過一年的算法迭代，在雙11大促時拿到5~10%的指標增加。因而可知一斑。

• UV價值：名詞解釋，公式上 UV價值=引導的成交額/訪問UV，約等於uv轉化率*客單價，通常在搜索中所說的引導的成交額指嚴口徑成交額（即點此買此），訪問UV是指訪問搜索的UV數。所以，以成交額做爲考覈指標的考拉，採用uv價值更吻合平臺kpi。涵義上，UV價值的是指訪問搜索的用戶的平均價值，是搜索內功的體現。

將來計劃

目前來講實時個性化完成了初版，後續咱們會從以下方面進行深刻探索。

1. 將用戶偏好商品的類似商品也歸入進來，在搜索時，也擇機展現給用戶，提高購物效率

2. 挖掘用戶行爲序列中的頻繁模式，嘗試序列模式推薦

參考文獻

• H. B. McMahan, G. Holt, D. Sculley, M. Young, D. Ebner, J. Grady, L. Nie, T. Phillips, E. Davydov, and D. Golovin.  Ad click prediction: a view from the trenches. In KDD, 2013.

• A/B測試 百度百科

• B Mobasher, H Dai, T Luo, M Nakagawa.  Effective personalization based on association rule discovery from web usage data 

 

       

 原文：搜索實時個性化模型——基於FTRL和個性化推薦的搜索排序優化

網易雲大禮包：https://www.163yun.com/gift

 

本文來自網易雲社區，經做者穆學鋒受權發佈

 

相關文章：
【推薦】 網易雲安全DDoS高防全新上線 ，遊戲防禦實力領先