論文解讀：基於機器學習的知道推薦—Enlister

 「Enlister」是最大的中文問答網站「百度知道」的問題推薦系統的名字。這個由幾個百度一線工程師研發的系統，自2012年1月上線以來，承擔着百度知道千萬級登陸用戶的問題推薦計算。

問題的開始

         百度知道這樣的問答社區型網站有個典型特色：有些用戶在平臺上提出問題，這些問題被另外一些用戶發現，其中有能力且有意願的人回答了這幾個問題。這幾個問題及其解答在平臺上沉澱下來，持續給後來有相關問題的搜索用戶提供着解答，並激勵着更多用戶將本身的問題發佈在平臺上。

        像這樣的系統就是一個自生態系統，有人生產，有人消費（如圖1）。若其中一個環節出現問題，都會致使這個生態異常。在如今的百度知道上，每日有幾十萬的新問題正在提出，又有近百萬左右的在涌現，而瀏覽這些知識的人天天有上億。最可能出問題的地方在於，問題被提出之後，解答沒法知足甚至鮮有人問津，這不利於解決提問者的疑惑和知識的沉澱。

圖1

        面對這樣問題，提高回答量是最直接的辦法，回答量上升了，有價值的回答數量就會成比上漲。「回答」是一個高門檻的事，是contribute而非consume。排除這個問題，若用戶自己在發現待回答問題上，還須要太高的付出（例如搜索、或按分類查找，如圖2），那着實讓大量有能力和意願但不想花更多時間在查找問題上的人望而卻步。而推薦，就是咱們一把殺手鐗。

 

圖2

說到推薦

        有了推薦，就有了地基，如何設計樓宇有更多細節須要解決。作推薦須要密切結合產品，是恆古不變的真理。詳細瞭解了知道的產品和目標後，咱們提出了三個該系統核心：

一、基於內容

        新問題一旦被提出，其解決就刻不容緩。高時效性要求了必需要以準確的內容分析爲基礎。

二、CTR預估(Click Through Rate，點擊率預估)

        爲了提高回答量，咱們可考慮提高點擊量，在用戶量和回答率不變的基礎上，間接提高了回答量。另外，CTR預估是咱們擅長的技術，是咱們的一大優點。

三、流式計算

        爲了適應新問題實時推送，咱們設計了以問題數據爲主數據流的推薦系統，保證了新問題在分鐘級時效性內推送給目標（如圖3）。

 

圖3

 

基於內容

         基於內容，意味咱們須要用模型準確地描述「問題」和用戶。考慮咱們的推薦場景，一個新問題產生並被推薦給目標用戶後，用戶看到的是一個推薦列表與裏面的問題標題（如圖4）。此時，影響一個用戶是否點擊該問題的因素大體有：問題的具體內容、問題的分類及分類的回答活躍度、問題的地域性。其中，問題分類活躍度是一個實際觀察獲得的因素，某些分類，如情感，的回答活躍度會遠遠高於其餘分類。而用戶因素則有：用戶內容偏好、回答時間、瞭解地域、最近行爲偏向與最近推薦活躍度。其中，除了內容偏好與瞭解地域這類用戶長期興趣，一些短時間偏好如時間、最近行爲和最近對推薦的活躍度做爲context信息也被考慮在內，以便提升推薦時機準確性。

 

圖4

         根據以上因素，咱們對問題進行了以下建模：獲取問題標題、切詞並從標題中抽取中心詞，構建plsa主題模型，利用分類器獲取問題分類（分類結構可見知道主頁上「問題分類」）與該分類最近點擊、回答量，問題推薦的時間與問題地理關鍵詞。

         而用戶的建模包括了：用戶在知道的我的中心定製的關鍵詞、問題分類，用戶歷史回答問題標題中挖掘的中心詞分佈與權重及這些中心詞的plsa模型，用戶最近回答問題的時間，最近回答的問題標題，以及用戶最近對推薦問題的點擊與回答量。

         利用以上的數據，咱們基本對問題、用戶有了準確的描述。不只涵蓋了用戶關注的問題且能解答的興趣方向，同時刻畫了最近用戶的回答興趣偏向與推薦場景信息。

CTR預估

         CTR預估天然就會使用到最大熵模型。該模型是經典的分類模型，在工業界有不少成功的使用案例，不只能夠進行線性計算以知足實時推薦需求，也不用考慮變量間獨立性關係，可將全部的特徵（包括context信息）構形成向量加入模型中。在咱們的問題中，但願利用及其有限規模的設備來得到優質的推薦服務，天然就涉及到須要按期更新訓練模型且樣本數不能過大（訓練本地化），特徵維度不宜太高。所以，咱們儘量利用用戶與問題模型構造組合的高級特徵，以提升特徵的覆蓋度和泛化能力（如圖5）。

 

圖5

         爲了保持模型的新鮮性，咱們自動更新模型週期爲5天。在5天以內採樣登陸用戶的幾百萬點擊數據做爲正樣本。常規狀況下，本可採用推薦列表中展現但未被點擊的問題做爲負樣本，但預測結果並不使人滿意，究其緣由可能爲：因爲列表上問題方向由必定重複性，另外用戶天天回答能力有上限，因此列表上其餘問題可能因爲用戶未看到或已經不想再繼續回答而未點擊，不能表明其爲真正的負樣本。因此，負樣本採用從與正樣本時間一致的同一批問題裏隨機抽取。而正負樣本比例則嘗試了多種比例組合，最終1:1的比例在精確率(accuracy)上優於其餘組合(如圖6)。

 

圖6

流式計算

         流式計算，是相對於離線批量計算和當用戶訪問時實時爲其計算推薦而言的。當新問題產生時，咱們須要及時爲其發現目標用戶，併爲這批目標用戶構建新的推薦列表，包含了巨大的計算量及存儲量。如圖7，當咱們在question pre-process端接收到新問題時，當即對其進行秒級建模運算；而在user action pre-process端，咱們利用分佈式計算實現了用戶模型小時級更新，保持用戶模型的新鮮性。經過BMQ系統（Baidu Message Queue）將建好模的問題發送到幾十臺click predict運算模塊中（每臺包含不一樣的用戶分片）。click predict內部也是多線程並行流水線處理，保持高併發性（如圖8）。當click predict接收到一個問題，會先根據問題中心詞拉取用戶倒排，獲取一個該問題關聯用戶的候選集(pre-process)，淘汰部分不合格用戶。在prediction階段，對問題和關聯到的所有用戶（千量級）計算點擊率，並淘汰低點擊率。最後再re-rank階段對用戶原有列表插入該新問題。

 

圖7

 

圖8

 

列表構建

         在上一節最後提到了將一個新問題插入到原有用戶列表中。若只簡單考慮利用CTR值來進行排序，則使得整個列表看起來同質化比較嚴重：

一、  很多問題的標題很接近，在列表中排序也可能很鄰近；

二、  用戶可能包含幾個興趣點，但最終列表（特別頭部）集中了大量問題只屬於一個興趣；

         實驗代表，這些問題會嚴重影響用戶體驗，下降用戶持續回答的慾望。咱們則採用了一種多樣化列表構建方法，以CTR爲基本排序依據，但在列表頭部儘量的保證推薦的相關性。當一個新問題插入頭部時，只要和周圍標題不是很是接近均可插入，讓用戶能首先看到的列表前部看起來推薦很「準」；而在非頭部區域，則增強對鄰近問題類似過濾，讓更多的興趣點能得以展示，用戶看起來以爲很「多樣化」(如圖9)。

 

圖9

 

總體系統

         除了以上幾點須要考慮以外，咱們作一個線上的推薦系統還須要考慮如spam屏蔽、某些業務邏輯、用戶反饋等問題。如圖，在多樣化列表構建時，加入業務邏輯模塊，過濾spam問題，對一些高價值問題的展示進行優先或對用戶點擊刪除或不太喜歡的關鍵詞進行屏蔽、降權。圖10中RP部分是推薦引擎，iknow部分是產品線。

 

圖10

         圖11是系統上線前與上線後（201201）回答量的一個對比。原有推薦系統基於中心詞計算距離類似進行推薦，日均回答量不足8萬。Enlister上線後回答量持續攀升，至6月份後穩定在19萬左右。

 

圖11