達觀數據：用好學習排序 (LTR) ,資訊信息流推薦效果翻倍

序言

達觀數據是一家基於文本語義理解爲企業提供自動抽取、審覈、糾錯、推薦、搜索、寫做等系統服務的人工智能企業，其中在推薦場景上咱們也服務了不少客戶企業，客戶在要求推薦服務穩定、需求響應及時的基礎上，對系統的效果也提出了愈來愈高的指望，這對算法團隊也是一個挑戰。本文將從資訊信息流這個場景入手，先簡單介紹達觀推薦引擎的架構演化，同時儘量詳細的介紹學習排序這個核心技術的實踐和落地經驗。

達觀推薦引擎架構

達觀推薦引擎採用在線-近線-離線三層系統架構，能夠從性能和算法複雜度兩個維度來進行區分。
在線：實時響應客戶http api推薦請求，通常須要嚴格控制在100ms之內，最好在50ms。該模塊須要嚴格保證穩定性，綜合考慮各個依賴模塊的異常兼容、流量的超時控制等。

近線：準實時捕捉用戶實時行爲並作出反饋，即近線模塊的輸出須要考慮用戶的實時行爲反饋。該模塊通常處理延遲爲秒級。

離線：基於分佈式平臺離線挖掘，輸出包括item-base協同過濾結果、基於標籤的召回結果、各維度熱門結果、用戶畫像等等。該模塊的處理延遲通常爲小時級或者天級。

一個通用的資訊流推薦架構以下：

圖1：online-nearline-offline三層架構

hot rec模塊負責生成各個維度的熱門結果，如分類別熱門、分地域熱門；tagrec生成各個標籤的召回結果，如 英超 -> (item1,item2,….)；item rec生成每一個資訊item的相關結果；user rec nearline根據用戶實時行爲和離線畫像負責生成用戶的推薦結果；reconline響應推薦請求；item cache返回資訊的信息；uhvreceiver負責接收用戶對item的行爲反饋。關於架構可參考更過以前達觀數據發佈的推薦技術文章。

爲何須要學習排序

學習排序（LTR：learning to rank）是信息檢索領域的經典問題，也是互聯網場景中ranking這個核心算法問題。推薦整個流程能夠分爲召回、排序、重排序這三個階段，通俗來講，召回就是找到用戶可能喜歡的幾百條資訊，排序就是對這幾百條資訊利用機器學習的方法預估用戶對每條資訊的偏好程度，通常以點擊率衡量，因此學習排序在不少狀況下等同於點擊率預估，都是將用戶最可能點擊的資訊優先推給用戶；重排序更多考慮業務邏輯，如在推薦結果的多樣性、時效性、新穎性等方面進行控制。

在沒有學習排序以前，也能夠單純使用協同過濾算法來進行推薦。列如使用用戶最近點擊的資訊信息召回這些item的相關結果和偏好類別熱門結果組合後進行返回。可是這對於資訊類推薦須要考慮一下問題：資訊類信息流屬於用戶消費型場景，item時效性要求高，item base cf容易召回較舊的內容，並且容易致使推薦結果收斂。所以能夠將item的相關結果保證時效性的基礎上，融合類別、標籤熱門結果，對各個策略的召回結果按照線上整體反饋進行排序，就能夠做爲用戶的推薦結果。可是這一融合過程比較複雜，一種簡單的方式就是看哪一種召回策略整體收益越高就擴大這個策略的曝光佔比，對於個體而言卻顯得不是特別個性化，並且在規則調參上也比較困難。

LTR架構

咱們迅速在資訊信息流推薦場景上實踐ltr算法。Ltr通常分爲point wise、pairwise、list wise，通常工程上使用pointwise較多，簡單，成本低，收益也可靠。簡單來講，Ltr即預測user對一個未消費item的預估點擊率，即：

即這個預估的點擊率是和user、item、context相關的。咱們使用邏輯迴歸（logistic regression，lr）模型來搭建咱們初版的學習排序架構，lr模型簡單可解釋，缺點在於須要對業務特徵有較深理解，特徵工程比較費力，但從應用角度出發，不管是lr、ffm亦或是較新的wide& deep等模型，特徵挖掘都是極其重要的一環。所以在首先基於lr模型的基礎上，核心工做就是基於業務理解併發掘特徵。如下是排序模型的總體推薦架構。

圖2：ltr總體架構

1 日誌過濾

推薦日誌詳細打印了每次推薦請求的參數信息和返回信息，如屏數、請求個數、設備信息、位置信息、返回的推薦結果。推薦日誌須要儘量的考慮後期可能使用到的特徵，並作好充分的記錄。將推薦日誌與曝光日誌進行第一次join，過濾掉未曝光即用戶沒有看到的推薦item，這部分樣本沒有參考意義，能夠省略；第一個join後的結果與點擊日誌join，便可以獲得每條樣本的label（0/1:未點擊/點擊）。兩次join須要根據請求時間、userid、itemid三者進行inner join，確保數據準確。日誌過濾後生成的每條樣本信息以下：

[請求時間、曝光時間、點擊時間（若是有）、userid、最近的點擊item列表、最近曝光的item列表、itemid、召回策略、屏數、曝光順序位置、地理位置、設備信息]
–> 點擊label。

2 特徵工程

通過1）的樣本缺乏足夠的特徵，咱們須要補充user和item端的特徵。該部分特徵須要離線挖掘並提早入庫。總結後的可以使用特徵種類大體以下：

特徵種類
User特徵：手機型號、地域、圖文曝光/點擊總數、視頻曝光/點擊總數、圖文點擊率、視頻點擊率，最近一、二、3天圖文視頻點擊數、最近點擊時間、最近一次點擊是圖文仍是視頻、一二級類別點擊率、標籤偏好，類別偏好、最近16次點擊的素材分佈、最近16次點擊item的平均標題向量、曝光時間、點擊時間等；

item特徵：itemid、類別、整體點擊率、最近一週點擊率、圖片個數、來源、類型（圖文仍是視頻）、發佈時間、標題向量、召回策略、點擊反饋ctr等；

context特徵：屏數、曝光順序位置、請求時間段等；

交叉特徵：用戶對item類別的一二級類別點擊率、用戶對item標籤的偏好、用戶對item素材類型的曝光、點擊次數和點擊率、最近16個點擊item與預測item標題向量的餘弦類似度、類似度最大值等。

交叉特徵對於ranking特別重要，核心在於邏輯迴歸函數中，若是與預測item無關的特徵不會對item的排序產生影響，只有item特徵或者與item交叉的特徵纔會對排序有實質影響,由於其餘特徵對任何待預測item的打分貢獻是同樣的。

咱們沒有使用bagof word模型來表示標題，由於這很是稀疏，而是採用標題中關鍵詞的word2vec向量組合生成標題表示，使用詞向量來表示標題極大減小了特徵規模，實現上比較方便。標題向量同時須要歸一化成單位向量，單位向量的餘弦類似度即兩個向量的內積，這個優化顯著提升了ltr在線模塊的性能。

咱們將全部特徵按類型劃分爲離散型、連續型、向量型三種類型。如item類別就是一個離散型特徵、item ctr就是一個連續性特徵、標題向量就是一個向量型特徵。對於每種特徵，其處理方式都會不太同樣，對於離散型通常直接根據離散值作feature name，對於連續值咱們部分參考youtube wide & deep論文中的等頻歸一化方法，簡單來講加入ctr特徵須要等屏成10個特徵，即將ctr值按照分佈取其10等分點，這10等分點就定義了10個區間，每一個區間的樣本數都佔10%。須要注意的是，ltr在線部分須要hardcode寫死這10個區間來提升特徵離散化的效率。

因爲離線和在線都會須要User和item端特徵，咱們在hive數倉和ssdb集羣總中都存儲一份，離線負責join hive表，在線負責讀取ssdb。

3 模型訓練與評估

通過特徵工程後，訓練數據按照libsvm格式進行打印。使用一天的訓練數據的狀況下，整個特徵空間規模約爲30萬維左右。模型訓練採用sklearn的logistic regression模型進行訓練，方便dump和load模型，咱們採用了lbfgs算法來進行訓練，lbfgs是一種擬牛頓法，不一樣於隨機梯度降低，lbfgs老是朝着最優化梯度方向進行迭代。

簡單起見，咱們使用N-2天前的日誌作訓練，N-1天前的日誌作評估，需保證兩部分日誌的用戶羣體是一致的，咱們再作ab測試的過程當中，不能訓練數據用的是1號桶，評估數據用的是2號桶。

實際過程當中，咱們採用1500萬條樣本作訓練，300萬條樣本作評估，訓練完成後離線auc爲0.79-0.8區間內，在線auc爲0.75-0.76區間內，存在必定差距。關於auc能夠自行參考技術文章，簡單來講auc就是衡量模型將正樣本排在負樣本前面的機率，即排序能力。

4 在線服務於評估

咱們的最終目的是要在線上流程產生收益，咱們採用rpc搭建了一個ltr在線服務，負責接收online的ltr請求。推薦online在召回各個策略的結果後，會將userid、預測的itemid列表、context等信息傳給ltr online，ltr online打分後返回。咱們對ltr online作了充足的優化，包括標題向量的單位化、ssdb性能優化、特徵離散化的優化，顯著提升了性能，對200-300個item打分的平均響應時間控制在100ms之內。

模型不只須要離線評估，還須要在線評估，在線評估即評估在線樣本的auc，recommend log中記錄了ltr score，所以能夠方便的計算在線auc。計算在線auc的目的是爲了驗證離線效果提高和在線效果提高的同步性。

5 業務效果的提高

咱們在測試組上線ltr邏輯後，在點擊率指標上相比原算法取得了明顯的提高。以下圖所示：

能夠明顯看出上線後，基於點擊率目標的ltr對於天級點擊率的提高是很是明顯的。

問題探討

1 單機訓練大規模樣本

因爲選取的樣本數較大，1000-2000萬的規模，簡單增大樣本數能夠顯著提升auc，在咱們的場景上在往上增長auc就彷佛增長不明顯了。這麼大的訓練樣本單機訓練的話顯然只能用稀疏矩陣的方式來存儲樣本。Scipy的cs_matrix就是很是好的選擇，因爲sklearn的轉載cs_matrix時數組下表採用int，故最大空間只能到20億，顯然2000萬樣本* 每一個樣本的平均特徵數遠遠大於20億，所以咱們探討了cs_matrix如何加載大規模數據的方法，最終咱們參考liblinner工具包中加載libsvm格式數據的代碼，固然libliner加載方式也存在問題，通過修改調試後，成功的完成了訓練數據的加載，具體問題和解決方式能夠參考https://blog.csdn.net/wh_spri...。

2 樣本和特徵的時間正交

樣本和特徵數據的時間正交即二者在時間上不該該有交叉。舉個例子，前期咱們在join用戶端特徵時，用的是1號的訓練樣本數據，用戶離線特徵用的也是1號的數據，這樣二者就會存在交叉，即user點擊了一篇英超新聞，同時user 畫像中也偏好英超標籤（由1號的點擊生成），這樣就會致使auc偏高，固然這種偏高就是虛假偏高，模型的泛化能力是不好的。在實際過程當中，遇到過幾回auc忽然偏高的狀況，發現大部分都是因爲沒有保證數據正交性致使的。

在整個流程中，數據的時間正交老是被不斷強調。不管是user、item特徵仍是樣本數據，好比訓練樣本中一個特定user的樣本按照時間排序是(s1,s2,s3,s4,s5,s6,s7,s8,s9,s10)，使用s1-s8訓練，s9,s10評估是合理的，而使用s3-s10訓練，s1,s2則顯然是不合理的。

3 預估點擊率和實際點擊率的一致性

點擊率預估基本要求就是預估的點擊率要精準，若是隻考慮位置的ranking，能夠不用過度關心預估的絕對值，但實際狀況下仍是須要儘可能保證預估分數的合理性，每每預估精準的ctr具備很大的參考價值。

前期咱們預估的點擊率一直偏高，平均打分甚至達到了0.5，通過排查在於訓練模型的參數設置不合理，錯誤的將LogisticRegression的class_weight參數設置成balanced，致使損失函數中正樣本預測錯誤的代價增大，致使模型偏向正樣本，從而致使預估的點擊率極度偏高，修復成默認值預估點擊率降低明顯，接近實際值。具體參考：https://scikitlearn.org/stabl...。

同時爲了保證訓練數據和在線服務徹底一致性，咱們調整了推薦的總體架構，更多的直接在推薦online模塊負責召回和排序，這樣又能夠進一步保證預估點擊率和實際點擊率的一致。

4 重要特徵和 case排查

lr模型能夠方便debug每一個樣本的各個特徵和權重，權重高的特徵顯然更加劇要。若是你以爲重要的特徵權重太低了或者不重要的特徵權重太高了，也許就要思考爲何了。如下是一個樣本的debug信息。

例如咱們發現ctr特徵權重特別高，假設一個新item曝光了一次點擊了一次，點擊率是1.0，乘上ctr的權重上這個item極易被排到最前面，所以咱們考慮ctr的置信度，考慮對ctr類特徵作了平滑。

值根據實際狀況設定。

總結

本文詳細介紹了達觀數據的推薦引擎架構和在資訊信息流推薦場景中利用ltr排序顯著提升業務指標的實踐和經驗。因爲篇幅有限，關於非線性的ffm、wide & deep沒有作詳細介紹，而這也是算法團隊一直繼續投入研究的重點。

關於做者

文輝：達觀數據聯合創始人，主要負責達觀數據推薦系統、爬蟲系統等主要系統的研究和開發。同濟大學計算機應用技術專業碩士，曾就任於盛大文學數據中心部門，負責爬蟲系統、推薦系統、數據挖掘和分析等大數據系統的研發工做，在爬蟲系統、Hadoop/Hive、數據挖掘等方面具有充足的研發和實踐經驗。