“Enlister”是最大的中文問答網站“百度知道”的問題推薦系統的名字。這個由幾個百度一線工程師研發的系統，自2012年1月上線以來，承擔着百度知道千萬級登錄用戶的問題推薦計算。
問題的開始
百度知道這樣的問答社區型網站有個典型特點：有些用戶在平臺上提出問題，這些問題被另一些用戶發現，其中有能力且有意願的人回答了這幾個問題。這幾個問題及其解答在平臺上沉澱下來，持續給後來有相關問題的搜索用戶提供着解答，並激勵着更多用戶將自己的問題發佈在平臺上。
像這樣的系統就是一個自生態系統，有人生產，有人消費（如圖1）。若其中一個環節出現問題，都會導致這個生態異常。在現在的百度知道上，每日有幾十萬的新問題正在提出，又有近百萬左右的在涌現，而瀏覽這些知識的人每天有上億。最可能出問題的地方在於，問題被提出以後，解答無法滿足甚至鮮有人問津，這不利於解決提問者的疑惑和知識的沉澱。
圖1
面對這樣問題，提升回答量是最直接的辦法，回答量上升了，有價值的回答數量就會成比上漲。“回答”是一個高門檻的事，是contribute而非consume。排除這個問題，若用戶本身在發現待回答問題上，還需要過高的付出（例如搜索、或按分類查找，如圖2），那着實讓大量有能力和意願但不想花更多時間在查找問題上的人望而卻步。而推薦，就是我們一把殺手鐗。
圖2
說到推薦
有了推薦，就有了地基，如何設計樓宇有更多細節需要解決。做推薦需要密切結合產品，是恆古不變的真理。詳細瞭解了知道的產品和目標後，我們提出了三個該系統核心：
1、基於內容
新問題一旦被提出，其解決就刻不容緩。高時效性要求了必須要以準確的內容分析爲基礎。
2、CTR預估(Click Through Rate，點擊率預估)
爲了提升回答量，我們可考慮提升點擊量，在用戶量和回答率不變的基礎上，間接提升了回答量。另外，CTR預估是我們擅長的技術，是我們的一大優勢。
3、流式計算
爲了適應新問題實時推送，我們設計了以問題數據爲主數據流的推薦系統，保證了新問題在分鐘級時效性內推送給目標（如圖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值來進行排序，則使得整個列表看起來同質化比較嚴重：
1、 不少問題的標題很接近，在列表中排序也可能很鄰近；
2、 用戶可能包含幾個興趣點，但最終列表（特別頭部）集中了大量問題只屬於一個興趣；
實驗表明，這些問題會嚴重影響用戶體驗，降低用戶持續回答的慾望。我們則採用了一種多樣化列表構建方法，以CTR爲基本排序依據，但在列表頭部儘可能的保證推薦的相關性。當一個新問題插入頭部時，只要和周圍標題不是非常接近都可插入，讓用戶能首先看到的列表前部看起來推薦很“準”；而在非頭部區域，則加強對鄰近問題相似過濾，讓更多的興趣點能得以展現，用戶看起來覺得很“多樣化”(如圖9)。
圖9
整體系統
除了以上幾點需要考慮之外，我們做一個線上的推薦系統還需要考慮如spam屏蔽、某些業務邏輯、用戶反饋等問題。如圖，在多樣化列表構建時，加入業務邏輯模塊，過濾spam問題，對一些高價值問題的展現進行優先或對用戶點擊刪除或不太喜歡的關鍵詞進行屏蔽、降權。圖10中RP部分是推薦引擎，iknow部分是產品線。
圖10
圖11是系統上線前與上線後（201201）回答量的一個對比。原有推薦系統基於中心詞計算距離相似進行推薦，日均回答量不足8萬。Enlister上線後回答量持續攀升，至6月份後穩定在19萬左右。
圖11