通用排序框架在愛奇藝推薦的應用

推薦系統通常由多個階段組成，比如，有的推薦系統分爲Recall、PreRanking、Ranking、ReRanking等四個階段。在愛奇藝，我們的推薦系統在非常多的場景中都有應用，推薦的內容也不盡相同(如長視頻、短視頻、主題、影人等)。但是萬變不離其宗，在這些場景中，推薦系統的核心工作方式有一定的共性。爲節約開發成本，同時也要保障不同場景下推薦系統的穩定性，我們將不同推薦場景排序模型中相似的部分成體系地提煉出來，並加以標準化、組件化，進而針對推薦場景排序問題提供了通用化的解決方案。這也是我們提出愛奇藝通用排序框架的初衷。目前這一框架已經在愛奇藝多端多個場景落地——長視頻推薦：主APP首頁猜你喜歡、TV端首頁猜你想看，短視頻推薦：主APP短視頻播放器，長短視頻混合推薦：主APP頻道頁瀑布流、TV端首頁Feed等。正所謂，推薦的複雜性如黑夜迷霧，希望能破曉見黎明。

下面我們分3節來介紹通用排序框架：第1節對框架的環節進行了概述；第2節主要介紹框架詳細的構造環節以及對應特性；第3節對框架的特性進行總結和展望。鑑於我們主要考慮的是視頻播放場景，下文中我們以視頻來指代推薦系統中的item。

01

概述

近些年來，推薦系統中的排序模型有比較快速的發展：淺層模型如XGBoost+FM，深度模型如DeepFM、DCN、DIN、DSSM、MMoE等，在不同推薦場景中都取得了亮眼的效果。然而，這些模型有一些共同點：它們最終都服務於線上的打分預測；它們都要根據場景特性來篩選和製作特徵、構造訓練樣本、訓練模型、部署Ranking服務——這樣一個完整的流程。通用排序框架正是對這一流程的一種歸納總結。對於不同的推薦場景，模型的特徵製作和模型服務化過程是一致的，他們主要在構造樣本，以及訓練模型上有較多區別。

通用排序框架總共由4個環節組成，每個環節都是模塊化的，有可執行的標準流程和完善的監控機制。這4個環節分別是：

1、特徵製作與灌庫；

2、特徵回放；

3、Training；

4、Ranking。

如下圖所示。其中環節1、3爲獨立於線上服務的過程；環節2、4爲線上服務的一部分。

圖1 排序框架結構

02

詳細結構

 2.1 特徵製作與灌庫

特徵是推薦的基石，它決定了模型的上限。數據與特徵描述了用戶對視頻的喜好，以及視頻本身的質量。

從數據來源的角度來分類，我們可以把特徵劃分爲：屬性特徵、統計特徵。前者一般是用戶或視頻的相對靜態的屬性；後者往往與用戶行爲有關。

從特徵生產的角度來分類，我們又可以把特徵劃分爲：離線特徵、實時特徵。前者一般產出頻率爲天級，後者一般爲秒級。受限於實時計算的複雜度與性能考量，實時特徵一般涵蓋範圍較離線特徵小，更專注於用戶行爲的實時變化，以及用於捕捉用戶短期偏好；相對比的是，離線特徵大而全面，它更能描述用戶長期偏好。

在框架中，離線、實時特徵的製作過程有相應的固定流程，即流水線作業。我們對該製作哪些特徵、以及如何製作，都進行了規範化。這裏不贅述特徵製作方面的工作，主要介紹一下特徵產出後被線上服務使用的過程。

1）離線特徵灌庫：灌庫，指的是將離線產出的特徵數據，以特定的格式寫入高性能KV庫（如Couchbase、Redis等），供線上服務讀取使用。離線特徵產出後，一般存儲在HDFS等文件系統中，線上無法直接使用，需要經過灌庫才能被線上服務使用。灌庫的數據格式由框架的組件——Feature_Online——自動生成。

圖2 離線特徵灌庫流程示意圖

Feature_Online的目的是通過配置化的方式自動生成固定格式的灌庫表。在推薦工程化過程中有一個經典的困擾，就是算法工程師需要花費一定的精力來梳理特徵的使用，這部分工作重複度很高且易出錯。其採用自動化生成SQL的方式，杜絕了人工操作帶來的BUG，具有配置化、嚴格依賴管理、特徵上下線靈活等優勢。Feature_Online有幾個特性：輸入自定義、操作配置化、輸出格式統一。

 2）實時特徵服務：實時特徵具有即產出即使用的特性，框架採用DUBBO RPC的方式提供統一的實時特徵取數服務，簡化了不同推薦場景的接入，響應時間在毫秒級。

實時特徵通常專注於行爲類來源的特徵，例如：用戶的實時觀影列表、視頻的實時統計特徵等等。數據來源於線上用戶行爲日誌——展示、點擊、觀影，經過一個統一的Flink任務進行消費處理，數據被聚合後處理爲對應的實時特徵，接下來類似於離線特徵一樣，也是寫入高性能KV庫中，供線上服務讀取使用。數據聚合、灌庫的過程都集成在Flink任務當中。

2.2 特徵回放

特徵回放是將線上服務用於打分排序的特徵，通過落日誌的方式“回放”下來：就像拍攝視頻一樣，對每一次請求時所有的特徵都進行了記錄，並標記了該次請求的事件ID。這樣，當我們獲取了用戶的展示、點擊、觀影等行爲日誌之後，通過join事件ID，我們就可以知道在請求那一瞬間的所有特徵，這就是“回放”。

特徵回放是常用的一種基礎的技術手段，在工業界被大量的應用。早期的模型訓練方式，一般是使用這一步產出的Features與標註得到的Label進行拼接從而得到訓練數據。其存在兩個缺陷：

1）離線特徵從產出到被線上使用的時間是不確定的，難以確定線上被使用的版本，因而訓練數據無法模擬真實的線上環境；

2）缺少實時特徵。特徵回放解決了這兩個缺陷。

如下圖所示，當推薦引擎收到調用請求時，會拉取用戶和視頻的特徵，先用這些特徵對視頻進行打分排序，再將這些特徵進行回放。

圖3 特徵回放示意圖

特徵回放遵循推薦引擎的漏斗模式，參與回放的視頻個數等於推薦引擎最終返回的視頻個數。

特徵回放有2個重要的優勢：

1）實時特徵參與訓練：實時特徵一般被認爲在推薦中具有重要的意義，是推薦引擎捕捉用戶實時興趣的基礎。傳統的模型訓練樣本組織工作，無法獲取實時特徵：樣本組織工作分爲構造標註數據、特徵數據兩部分。特徵數據則需要算法工程師自行拼接，未曾記錄事件發生時的實時特徵，自然也就無法還原在事件發生時用戶的實時行爲、視頻的實時統計指標。特徵回放解決了這個問題，將事件ID發生時的實時特徵完全記錄下來，落在日誌中，樣本處理只需通過事件ID拼接標註數據即可。

2）線上線下特徵一致性：特徵一致性一直是制約推薦引擎效果的一個重要問題，如果線上預測使用的特徵與線下訓練使用的特徵不一致，那麼推薦的準確性也無從談起。在特徵回放機制下，訓練與預測使用同一份特徵。預測使用的特徵來自於線上服務日誌，而線上服務日誌來自於請求時引擎獲取的特徵，兩者份屬同源，自然一致。

特徵回放極大地解放了算法工程師在訓練樣本組織工作中的精力，使其能夠更專注於模型本身的迭代優化，而不是將精力都浪費在清洗、拼接特徵和標註數據上面。

下圖是目前框架採用的特徵回放流程示意圖。

圖4 特徵回放流程示意圖

 

框架深度結合特徵回放機制，這1環節有2大特性：

1）回放服務模板化，接入迅速：在上1小節“2.1 特徵製作與灌庫”的工作準備完畢後，只需要更改少量的代碼，即可部署，極大地減少了這一部分的接入工作量。

2）回放覆蓋率監控：數據與特徵決定了模型的上限。那麼，算法工程師除了需要關心特徵的質量，還需要關心特徵的覆蓋率。框架集成了通用化的監控組件，對特徵回放落地的日誌中所有特徵的覆蓋率有詳細的監控數據，做到一目瞭然。

特徵回放產出了可供訓練模型使用的特徵集，即Features。

2.3 Training

我們把模型訓練抽象爲訓練數據製作和模型訓練（模型訓練依託一個配置化的訓練框架）這2個部分。

1）訓練數據製作：

• Label&Upsampling：Label，即標註數據。除了常規的標註正負樣本之外，我們還考慮到對正樣本進行Upsampling的問題。正樣本Upsampling的本質，是在學習當前目標的基礎上，希望對特定的目標進行進一步地學習。例如：在CTR預估中，對時長高的正樣本進行Upsampling。在主APP首頁猜你喜歡場景中，我們通過Upsampling的方式大幅提升了用戶首次播放視頻的總次數。

• 特徵算子：若當前的推薦場景中有100個特徵，經分析其中85個特徵能起到更好的作用，因此採用2種不同的特徵算子配置，配置1採用全部100個特徵，配置2採用85個特徵，分別訓練2個不同的模型，那麼線上就可以使用這2個模型進行AB實驗，進而驗證業務效果的優劣。

• Label與Features的自由組合：1、相同的Label下比較不同的Features；2、相同的Features下比較不同的Labels。框架可以靈活地支持Label與Features的自由組合，並進行了版本管理。

  
  

圖5 模型訓練流程示意圖

2）配置化的訓練框架：提供了推薦常用模型的訓練方案，目前已經支持：DNN、DeepFM、DCN、DIN、DSSM、MMoE等多種模型。只需修改配置文件，無需額外開發模型，即可開始訓練。這極大地節省了算法工程師自行開發模型和調參的工作精力。保存的模型爲固定格式，無縫銜接地對接線上的TF-Serving服務，更好更快地服務於業務效果的優化迭代。

• Make TFRecords：將訓練數據轉換爲TFRecords文件形式來進行訓練，格式固定，包含3種數據：Label，離散特徵，連續特徵。

• Choose Model：在已經已經支持的模型內選擇需要訓練的模型結構；一般來講，一份數據可以訓練多種結構的模型用以AB測試。可以通過編寫少量的代碼自定義新的模型結構。

• Define Config：通過配置的形式來指定模型訓練使用的超參數、數據集、特徵定義、網絡結構參數、網絡頂層輸出方式等關鍵性的參數，模型調參十分便捷。

圖6 配置化訓練框架示意圖

2.4 Ranking

Ranking在框架中分爲2個環節：1）推理服務；2）排序服務

1）推理服務，即依託於TensorFlow Saved Model的TF-Serving。

2）排序服務是承接推薦引擎與推理服務的橋樑，如圖7所示。

圖7 Rank服務架構圖

Rank服務通過優化提供了快速部署和高性能的預測能力，主要包括：

•  用戶特徵前置，有兩點好處：

1）引擎獲取設備特徵可以配置較長的超時時間，提升獲取用戶特徵的成功率；

2）如果引擎獲取成功，排序服務不需要再取用戶特徵，如果請求告知引擎獲取用戶特徵失敗，排序服務嘗試取用戶特徵， 進一步提升用戶特徵參與模型預測的成功率；

•  高性能Local Cache及BytesBuf

目前主流模型特徵維度都比較高，一次排序少則需要預測幾百個Item，多則預測上千個視頻，比較主流的做法是將熱門內容cache的本地進行處理。 但是會存在一個問題， 通常來說特徵內容有以下特點。

1）單個視頻或者設備的特徵很多，

2）每個特徵基本可以簡化爲<特徵名，特徵值>形式，

這兩個特點會造成內存中存儲和管理的是大量的小對象，可以假設性的計算下，一個視頻5000個原始<特徵名，特徵值>特徵。

100W個視頻則有100億（5000*2*100W）個內存小對象。這只是靜態的內存內容數據，排序服務需要做的一個重要的工作是特徵組裝。如果基於這些小對象進行進一步的對設備、實時、視頻、交叉等特徵加工、組裝處理， 這個過程產生的小對象量將是驚人的，這勢必會給內存存儲管理帶來巨大的性能壓力，這也可能是爲什麼排序服務看似並不複雜的處理邏輯，但卻需要很多資源；因此，我們通過設計高校的緩存池和自定義序列化存儲方式來避免海量的小對象可以極大的提升服務性能。

•   優化特徵處理流程

爲了提高性能，排序服務支持分批併發的訪問推理服務，通過將設備特徵預處理、視頻特徵緩存原始特徵處理後的結果可以避免重複計算，提升性能。

•  快速部署能力

通過代碼的工程模板化，並基於配置和文件中心，對於已經存在的現有的模型和特徵類型可以快速的部署供線上服務。

•  自動化監控

   

基於prometheus進行監控，模板化打點所有指標，服務啓動後自動創建prometheus的job拉取監控數據，可以監控訪問特徵、推薦服務等的耗時、 成功率指標，並配置grafana大盤，非常方便的查看監控數據。

03

總結與展望

通用排序框架具有以下特性：特徵製作模板化，Feature_Online提供配置化、嚴格依賴管理、靈活特徵增刪的離線特徵灌庫解決方案，實時特徵服務化，特徵回放工程模板化、覆蓋率監控自動化，訓練數據產出靈活，模型訓練依託於配置化訓練框架快捷便利、快速訓練+調參，排序服務工程模板化、監控自動化。

通用排序框架目前已經被大規模應用於愛奇藝多個端的多個推薦場景中，在推薦效果上取得了較好的成果：在主APP短視頻播放器場景，人均播放時長指標提升超過20%；同時在首頁瀑布流也得到了不錯的受益，提升用戶首次播放視頻的總次數超過1倍，未來還將應用到更多的業務場景。目前框架還在不斷地進步和完善，增加支持更多模型、細化監控，爲愛奇藝的推薦業務保駕護航。

看完心動了嗎？

戳👇“ 閱讀原文”直達招聘頁面

即刻加入愛奇藝！

也許你還想看

一矢多穿：多目標排序在愛奇藝短視頻推薦中的應用

Source Map在前端監控中的應用和實踐

領域驅動設計框架Axon實踐

 關注我們，更多精彩內容陪伴你！

本文分享自微信公衆號 - 愛奇藝技術產品團隊（iQIYI-TP）。
如有侵權，請聯繫 [email protected] 刪除。
本文參與“OSC源創計劃”，歡迎正在閱讀的你也加入，一起分享。