序言
達觀資料是一家基於文字語義理解為企業提供自動抽取、稽核、糾錯、推薦、搜尋、寫作等系統服務的人工智慧企業，其中在推薦場景上我們也服務了很多客戶企業，客戶在要求推薦服務穩定、需求響應及時的基礎上，對系統的效果也提出了越來越高的期望，這對演算法團隊也是一個挑戰。本文將從資訊資訊流這個場景入手，先簡單介紹達觀推薦引擎的架構演化，同時儘可能詳細的介紹學習排序這個核心技術的實踐和落地經驗。
達觀推薦引擎架構
線上：實時響應客戶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特徵：手機型號、地域、圖文曝光/點選總數、視訊曝光/點選總數、圖文點選率、視訊點選率，最近1、2、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_springer/article/details/85007921這篇文章。
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/stable/modules/generated/sklearn.linear_model.LogisticRegression.html。
同時為了保證訓練資料和線上服務完全一致性，我們調整了推薦的整體架構，更多的直接在推薦online模組負責召回和排序，這樣又可以進一步保證預估點選率和實際點選率的一致。
4 重要特徵和 case排查
lr模型可以方便debug每個樣本的各個特徵和權重，權重高的特徵顯然更加重要。如果你覺得重要的特徵權重過低了或者不重要的特徵權重過高了，也許就要思考為什麼了。以下是一個樣本的debug資訊。
例如我們發現ctr特徵權重特別高，假設一個新item曝光了一次點選了一次，點選率是1.0，乘上ctr的權重上這個item極易被排到最前面，因此我們考慮ctr的置信度，考慮對ctr類特徵做了平滑。
值根據實際情況設定。
總結
本文詳細介紹了達觀資料的推薦引擎架構和在資訊資訊流推薦場景中利用ltr排序顯著提高業務指標的實踐和經驗。由於篇幅有限，關於非線性的ffm、wide & deep沒有做詳細介紹，而這也是演算法團隊一直繼續投入研究的重點。
關於作者
文輝：達觀資料聯合創始人，主要負責達觀資料推薦系統、爬蟲系統等主要系統的研究和開發。同濟大學計算機應用技術專業碩士，曾就職於盛大文學資料中心部門，負責爬蟲系統、推薦系統、資料探勘和分析等大資料系統的研發工作，在爬蟲系統、Hadoop/Hive、資料探勘等方面具備充足的研發和實踐經驗。