Enlister―基于機器學習的百度知道問題推薦系統(tǒng)

時間：2022-05-28 22:00:01 | 來源：網(wǎng)絡營銷

時間：2022-05-28 22:00:01 來源：網(wǎng)絡營銷

Enlister——是中國最大的中文問答網(wǎng)站“百度知道”的問題推薦系統(tǒng)名字。這個由幾個百度一線工程師研發(fā)的系統(tǒng)，自2012年1月上線以來，承擔著百度知道千萬級登錄用戶的問題推薦計算。

問題的開始

百度知道這樣的問答社區(qū)型網(wǎng)站有個典型特點：有些用戶在平臺上提出問題，這些問題被另一些用戶發(fā)現(xiàn)，其中有能力且有意愿的人回答了這幾個問題。這幾個問題及其解答在平臺上沉淀下來，持續(xù)給后來有相關(guān)問題的搜索用戶提供著解答，并激勵著更多用戶將自己的問題發(fā)布在平臺上。

像這樣的系統(tǒng)就是一個自生態(tài)系統(tǒng)，有人生產(chǎn)，有人消費（如圖1）。若其中一個環(huán)節(jié)出現(xiàn)問題，都會導致這個生態(tài)異常。在現(xiàn)在的百度知道上，每日有幾十萬的新問題正在提出，又有近百萬左右的在涌現(xiàn)，而瀏覽這些知識的人每天有上億。最可能出問題的地方在于，問題被提出以后，解答無法滿足甚至鮮有人問津，這不利于解決提問者的疑惑和知識的沉淀。


圖1

面對這樣問題，提升回答量是最直接的辦法，回答量上升了，有價值的回答數(shù)量就會成比上漲。“回答”是一個高門檻的事，是contribute而非consume。排除這個問題，若用戶本身在發(fā)現(xiàn)待回答問題上，還需要過高的付出（例如搜索、或按分類查找，如圖2），那著實讓大量有能力和意愿但不想花更多時間在查找問題上的人望而卻步。而推薦，就是我們一把殺手锏。


圖2

關(guān)于百度知道推薦

有了推薦，就有了地基，如何設(shè)計樓宇有更多細節(jié)需要解決。做推薦需要密切結(jié)合產(chǎn)品，是恒古不變的真理。詳細了解了知道的產(chǎn)品和目標后，我們提出了三個系統(tǒng)核心：

1、基于內(nèi)容

新問題一旦被提出，其解決就刻不容緩。高時效性要求了必須要以準確的內(nèi)容分析為基礎(chǔ)。

基于內(nèi)容，意味我們需要用模型準確地描述“問題”和用戶?？紤]我們的推薦場景，一個新問題產(chǎn)生并被推薦給目標用戶后，用戶看到的是一個推薦列表與里面的問題標題（如圖3）。此時，影響一個用戶是否點擊該問題的因素大致有：問題的具體內(nèi)容、問題的分類及分類的回答活躍度、問題的地域性。其中，問題分類活躍度是一個實際觀察得到的因素，某些分類，如情感，的回答活躍度會遠遠高于其他分類。而用戶因素則有：用戶內(nèi)容偏好、回答時間、了解地域、最近行為偏向與最近推薦活躍度。其中，除了內(nèi)容偏好與了解地域這類用戶長期興趣，一些短期偏好如時間、最近行為和最近對推薦的活躍度作為context信息也被考慮在內(nèi)，以便提高推薦時機準確性。


圖3

根據(jù)以上因素，我們對問題進行了如下建模：獲取問題標題、切詞并從標題中抽取中心詞，構(gòu)建plsa主題模型，利用分類器獲取問題分類（分類結(jié)構(gòu)可見知道主頁上“問題分類”）與該分類最近點擊、回答量，問題推薦的時間與問題地理關(guān)鍵詞。

而用戶的建模包括了：用戶在知道的個人中心定制的關(guān)鍵詞、問題分類，用戶歷史回答問題標題中挖掘的中心詞分布與權(quán)重及這些中心詞的plsa模型，用戶最近回答問題的時間，最近回答的問題標題，以及用戶最近對推薦問題的點擊與回答量。

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

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

為了提升回答量，我們可考慮提升點擊量，在用戶量和回答率不變的基礎(chǔ)上，間接提升了回答量。另外，CTR預估是我們擅長的技術(shù)，是我們的一大優(yōu)勢。

CTR預估自然就會使用到最大熵模型。該模型是經(jīng)典的分類模型，在工業(yè)界有很多成功的使用案例，不僅可以進行線性計算以滿足實時推薦需求，也不用考慮變量間獨立性關(guān)系，可將所有的特征（包括context信息）構(gòu)造成向量加入模型中。在我們的問題中，希望利用及其有限規(guī)模的設(shè)備來獲得優(yōu)質(zhì)的推薦服務，自然就涉及到需要定期更新訓練模型且樣本數(shù)不能過大（訓練本地化），特征維度不宜過高。因此，我們盡可能利用用戶與問題模型構(gòu)造組合的高級特征，以提高特征的覆蓋度和泛化能力（如圖4）。


圖4

為了保持模型的新鮮性，我們自動更新模型周期為5天。在5天之內(nèi)采樣登錄用戶的幾百萬點擊數(shù)據(jù)作為正樣本。常規(guī)情況下，本可采用推薦列表中展示但未被點擊的問題作為負樣本，但預測結(jié)果并不令人滿意，究其原因可能為：由于列表上問題方向由一定重復性，另外用戶每天回答能力有上限，所以列表上其他問題可能由于用戶未看到或已經(jīng)不想再繼續(xù)回答而未點擊，不能代表其為真正的負樣本。所以，負樣本采用從與正樣本時間一致的同一批問題里隨機抽取。而正負樣本比例則嘗試了多種比例組合，最終1:1的比例在精確率(accuracy)上優(yōu)于其他組合(如圖5)。


圖5

3、流式計算

為了適應新問題實時推送，我們設(shè)計了以問題數(shù)據(jù)為主數(shù)據(jù)流的推薦系統(tǒng)，保證了新問題在分鐘級時效性內(nèi)推送給目標（如圖6）。


圖6

流式計算，是相對于離線批量計算和當用戶訪問時實時為其計算推薦而言的。當新問題產(chǎn)生時，我們需要及時為其發(fā)現(xiàn)目標用戶，并為這批目標用戶構(gòu)建新的推薦列表，包含了巨大的計算量及存儲量。如圖7，當我們在question pre-process端接收到新問題時，立即對其進行秒級建模運算。


圖7

而在user action pre-process端，我們利用分布式計算實現(xiàn)了用戶模型小時級更新，保持用戶模型的新鮮性。通過BMQ系統(tǒng)（Baidu Message Queue）將建好模的問題發(fā)送到幾十臺click predict運算模塊中（每臺包含不同的用戶分片）。click predict內(nèi)部也是多線程并行流水線處理，保持高并發(fā)性（如圖8）。當click predict接收到一個問題，會先根據(jù)問題中心詞拉取用戶倒排，獲取一個該問題關(guān)聯(lián)用戶的候選集(pre-process)，淘汰部分不合格用戶。在prediction階段，對問題和關(guān)聯(lián)到的全部用戶（千量級）計算點擊率，并淘汰低點擊率。最后再re-rank階段對用戶原有列表插入該新問題。


圖8

百度知道的列表構(gòu)建

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

1、不少問題的標題很接近，在列表中排序也可能很鄰近。

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

實驗表明，這些問題會嚴重影響用戶體驗，降低用戶持續(xù)回答的欲望。我們則采用了一種多樣化列表構(gòu)建方法，以CTR為基本排序依據(jù)，但在列表頭部盡可能的保證推薦的相關(guān)性。當一個新問題插入頭部時，只要和周圍標題不是非常接近都可插入，讓用戶能首先看到的列表前部看起來推薦很“準”；而在非頭部區(qū)域，則加強對鄰近問題相似過濾，讓更多的興趣點能得以展現(xiàn)，用戶看起來覺得很“多樣化”(如圖9)。


圖9

百度知道的整體系統(tǒng)

除了以上幾點需要考慮之外，我們做一個線上的推薦系統(tǒng)還需要考慮如spam屏蔽、某些業(yè)務邏輯、用戶反饋等問題。如圖，在多樣化列表構(gòu)建時，加入業(yè)務邏輯模塊，過濾spam問題，對一些高價值問題的展現(xiàn)進行優(yōu)先或?qū)τ脩酎c擊刪除或不太喜歡的關(guān)鍵詞進行屏蔽、降權(quán)。圖10中RP部分是推薦引擎，iknow部分是產(chǎn)品線。


圖10


圖11

圖11是系統(tǒng)上線前與上線后回答量的一個對比。原有推薦系統(tǒng)基于中心詞計算距離相似進行推薦，日均回答量不足8萬。Enlister上線后回答量持續(xù)攀升，至6月份后穩(wěn)定在19萬左右。