11月8-9日，由中國 IT 社區 CSDN 與硅谷 AI 社區 AICamp 聯合出品的 2018 AI 開發者大會（AI NEXTCon） 在北京舉行，就人工智能的最新技術及深度實踐，進行了全方位的解讀及論證。本文是機器學習技術專題中知乎首頁業務總監、首頁推薦技術負責人張瑞的演講實錄。
信息爆炸時代，信息過載已經成爲互聯網核心問題之一，而通過AI、機器學習等技術過濾低質無用信息，推動有價值信息的生產和迭代，被視爲一種有效解決方案。以知乎爲例，這家知識內容平臺很早就開始着手機器學習的開發實踐，並於2016年正式組建機器學習團隊，利用站內豐富的中文語料庫訓練AI算法，推動有價值信息更高效觸達用戶，爲內容產業提供了很好的技術借鑑。日前，在2018AI開發者大會上，知乎首頁業務總監張瑞就機器學習在知乎首頁中的應用做了技術分享。以下是分享內容摘要。
一、知乎信息流推薦框架
知乎的信息流推薦框架是一個基於多策略融合的多源內容推薦系統，代號“水晶球”。如圖所示，在這個系統中，首頁上出現的內容經歷過兩次排序。第一次是從數十個推薦隊列裏被“召回”，第二次是在合併後經過深層神經網絡（DNN）的“排序”。
- “召回”的第一個步驟是，召回模塊根據用戶的歷史行爲表現（用戶畫像、內容標籤、內容源信息），確定數十個推薦隊列。這數十個推薦隊列是含有特定標籤的內容池，有些隊列裏內容性質相似，比如熱點新聞隊列、視頻隊列，還有的隊列與用戶行爲緊密相關，比如關注關係隊列、搜索關鍵詞隊列。比如說，根據用戶的關注關係向外擴展更多關注關係，根據用戶興趣召回感興趣的內容，根據搜索關鍵詞進行相關推薦。
- “召回”過程的第二個步驟是，各召回源根據用戶的需求分別將自己的隊列中的內容做排序後，按召回數量返回內容。我們會從內容類型、內容質量、召回技術三個維度對內容分類，召回源的數據經過匯聚之後會進行融合，最後，DNN可以在20ms內對這些數據完成打分和排序過程，決定推送給用戶的內容。
- API的數據還會反饋到Feedback&Control的模塊裏面，應用這些數據進行業務控制的操作，比如我們會記錄每個用戶看到的內容是什麼，大家都知道在Feed信息流推薦有個很重要的應用是去重，推薦內容不能是有重複的，我們會用過濾保證推出來的內容沒有重複。用戶在一天裏面看到哪些內容點擊了哪些內容，這些內容都可以爲業務提供一定數據支撐。
二、知乎信息流推薦系統的技術演進
2016年之前，知乎的Feed流是比較簡單的，你關注了什麼樣的人，這個人產生的各種各樣的動態會在你的界面進行時間倒序的排序，和朋友圈的邏輯非常相似。2016年初我們上線了一個叫EdgeRank的排序系統，第一代Feed流算法在這個系統支持下取得了一定收益，系統維持了一年時間。
2016年10月份知乎上線了一個基於GBDT的排序系統，對召回的內容進行一個排序。我們使用GBDT做排序持續了一年時間，引入GBDT後用戶的Feed流使用時長的變化，是呈上升的趨勢。在使用 GBDT 進行排序的過程中，我們逐步完善了我們用戶畫像和內容分析的系統，在用戶特徵和內容特徵方面做了非常多工作，把用戶的實時行爲集成到GBDT裏面，用戶Feed流使用時長得到了激增。
2017年10月開始知乎先後在召回側和排序側引入DNN模型，在引入之後的2017年10月份到2018年7月份週期內，知乎的使用時長和閱讀量也呈現出快速增長。
在這之後，我們又做了一些優化工作，一個是7月份在DNN做的優化，把注意力機制和LSTM模型引入到DNN的模型裏面去，一個是嘗試強化學習在推薦系統中的應用。經過這麼長時間的優化之後知乎的信息流系統已經在知乎整體業務中佔了非常大的體量，用戶滲透率（即有多少用戶會有效來到首頁看內容）達到88%，使用時長佔比（包括刷知乎的時長以及在知乎中消費內容的時長等）達到76%。
三、Feed流推薦系統中的AI應用
基於深度學習的推薦召回模型
知乎在2017年上線了基於深度學習的推薦召回1.0版本，左邊這張圖是第一版上線時候的深度學習召回網絡框架，整個系統把用戶和用戶的特徵表示成了網絡，它和庫裏幾萬條內容做了一個多分類，在上層進行SoftMax。整個網絡訓練下來可以得到兩個成果。首先是一個 User Representation Network，它把用戶信息表示成128維的網絡，我們用了畫像裏的所有信息，包括他的興趣標籤、各種各樣的用戶信息，都會放到模型的輸入裏面去，這個輸入經過四層網絡之後得到用戶128維的 Embedding 表示。與此同時，使用Faiss作爲向量化ANN召回的Backend，用ANN召回的方式從這幾個條目裏選出他最感興趣的內容推薦給他，這是整個召回框架的工作過程。
我們在訓練集裏包含了幾萬個內容的Embedding，我們首先會在訓練中生成一批Embedding，比如今天的數據來自於過去一週內分發量比較高的數據，這些內容數據會生成Embedding，我們先通過這些召回源把這些機制分發出去，還有一批內容是新產生的、未在訓練集中包含的內容，這些內容通過其他的渠道分發出去之後，可以得到看到內容用戶的Embedding是什麼以及點擊這些內容用戶的Embedding是什麼，我們可以利用這份數據把這些新產生內容的Embedding計算出來更新到Embedding庫裏面去，這個時候就可以拿到每天新產生內容的表示，並且把這些內容推薦出來。
後來我們又對召回框架進行了2.0升級。在1.0版本的召回框架裏，“新內容Embedding怎麼得到的”這個問題是延遲解決的。用戶的表示網絡和Embedding召回在效果收益非常明顯，協同過濾用戶矩陣分解最常用的方法就是ALS，我們拿了一個關鍵的指標也就是召回從這幾萬條裏挑出的100個結果裏準確度有多少，這100個結果裏有沒有預測到用戶下次點擊的數據，在這個指標上， DNN 比起ALS來講提升了10倍的量級，我們希望一個內容產生之後馬上算出Embedding放到網絡裏。
在2.0版本中，我們嘗試了三個層面的技術升級：
- 使用了Content的原始特徵，一個內容上打了標籤，原始數據比如長度有多少，有沒有圖片，經過三層的網絡之後會生成Feed Embedding，可以直接得到Content Embedding，解決新內容的召回機制問題。
- 在用戶表示網絡這一側我們也做了優化，這個網絡裏就是一個最簡單的全鏈接神經網絡，我們做優化的時候是在User Representation Network引入FM Pooling層，學習用戶高頻消費行爲的交叉特徵，會讓Top100的精確度提高8%。
- 用戶在Feed流裏有，“展示未點擊的Skip數據”比線上“展示已點擊數據”量級還要高，代表用戶對內容並不是真正感興趣。第一，我們把展示未點擊的數據作爲特徵引入到User Representation Network裏面，其中會用到歷史搜索和歷史閱讀數據。第二，我們會把Skip數據作爲指導採樣的一種方式，訓練大規模的標籤Embedding時我們往往把正向數據之外的其他數據都當成負向數據使用，所有負向採樣的sample都是在剩下的數據中，根據概率的方式或控制採樣頻率的方式提取。展示了但是跳過 的內容會在採樣的時候加大權重，把它成爲負例的概率變得更大，讓用戶的行爲來指導採樣。
Skip這兩個數據爲Top100 ACC產生了比較好的效果，從召回數據裏來的CTR和整體的閱讀量都有比較大的提高。
基於深度學習的 CTR 預估模型
知乎還在排序側採用了CTR預估的模型。1.0版本總體結構和基於DNN的召回框架類似，使用兩層Relu而不是直接點積作爲Embedding的預估網絡。這個模型上線一段時間之後，我們剛開始沒有進行任何的參數裁剪的操作，收效沒有達到我們的預期。後來我們做了一個簡單的嘗試，按照業務的理解把特徵組合成不同的Field，這些Field之間先做連接，用戶先分成N個Field，比如，Field1是自己填寫的資料，Field2是用戶興趣標籤，Field3是歷史搜索行爲，先經過一個簡單的子網絡再全連接到上層。這個 trick能夠有效的減少特徵在初始輸入時候的錯誤交叉，會減輕模型的過擬合，線上應用則達到了非常明顯的收益，AUC提升了1%，CTR提升了5.8%。
使用了DNN之後，我們還試用了谷歌出品的Wide & Deep Network，Deep是圖上部分，效果沒有明顯的提升。隨後我們做了一個分析判斷，發現Wide & Deep Network的 wide 部分，都會在原始特徵輸入交叉方面做一個比較強的特徵工程，否則所有信息在Deep部分已經得到比較好的應用，Wide 部分並沒有提供什麼額外的輸入，也不會拿到特別好的數據表現。
今年我們開始在深度學習的CTR預估模型上嘗試更加激進更有意思的優化，也就是2.0版本。其中最早引入的優化還是特徵之間的交叉，我們引入FM層作爲這些類別之間的Sparse Input之間的交叉，AUC提升了0.2%，CTR提升了1%。引入CNN及LSTM分別作爲文本Encoder/Last Action Encoder，單用戶使用時長提高50秒。
第三個trick參考了阿里的一篇論文，我們引入Attention機制作爲用戶Embedding和CandidateEmbedding之間的交叉權重。舉個例子，用戶點擊的十篇文章中，有九篇是關於體育的一篇是關於互聯網的，等到下次體育相關內容的分數會比互聯網相關內容的分數高得特別離譜，平均之後互聯網信息淹沒在體育信息裏，但互聯網內容也是用戶喜歡的，權重卻很難發揮出來。我們引入Attention機制，把用戶的閱讀歷史跟當前候選集裏相關的數據和權重學習之後，收到了良好效果，單用戶使用時長增加了40秒左右。
知乎是一個社區化的平臺，常常需要平衡很多指標的收益，預估閱讀時長、點贊、收藏、分享、創作等行爲。爲了解決多目標預估中訓練和預測效率問題，我們使用了CTR預估模型預訓練網絡，利用Parameter Hard Sharing，點擊和點贊這兩層共享之前的權重，會有一個獨立的隱藏層model task自己的目標，這樣能降低前向/反向傳播中的計算量。
我們常常預估到一些非離散的目標，對於非離散目標如閱讀時長，很多同行的做法是線性預估的方式預估，你閱讀了60秒，我儘量把預測的值逼近。知乎的做法是，把一篇文章的閱讀時長做一個Normalize操作。我們觀察了一下閱讀時長的分佈，這個分佈與正態分佈比較類似。所以我們使用了 z-value 來對閱讀市場進行離散化，離散化之後會把閱讀時長分爲五等——沒點擊、點擊了閱讀時長低、點擊了閱讀時長中等、點擊了閱讀時長偏高、點擊了閱讀時長非常高——將連續值預測轉化成離散值預測。
在訓練過程中，我們也修改了 Softmax 函數，如果預測出的檔數和實際用戶閱讀時長檔數差太多，我們加一個比較大的修改函數，讓這種樣本的 loss 加大。閱讀時長這個模型上線之後，對知乎的使用時長和單篇文章的閱讀時長都有提升。
四、Feed流推薦系統中遇到的實際問題
模型訓練問題
- 樣本組織方面，大家可以看到剛纔我們用了很多實時特徵，這些實時特徵對用戶和樣本來講都是不斷變化的，最初知乎組織這些樣本的時候都是使用從離線庫裏Join數據的方式做特徵的梳理，後來我們發現線上往往會出現特徵穿越的狀況，你在線下記錄的日誌畢竟不是實時的，日誌都是流失的放到數據庫裏，處理數據流的過程中也會出現順序上的錯誤，所以我們會在線上進行實施打點避免穿越。
對於CTR預估的正向樣本和負向樣本，後者與前者相比存在幾倍的量級差異。通常我們會對正負樣本進行不同採樣率的實驗，不同的業務指標下採樣率不一樣，最終回有一個最佳的採樣率。但採樣率多少跟數據的分佈和業務需要預估的指標特性相關，1比1不一定是最好的採樣比例。
- 特徵工程方面，我們在實際應用場景裏發現對於分佈範圍比較大的特徵，有一萬個贊也有幾萬個讚的，做CTR預估的過程中贊量的影響會變得非常不平均，所以通常會進行特徵的歸一化和boxing，分成不同的段輸入到CTR預估模型裏達到比較好的效果。
- 模型評估方面，AUC是基礎指標，我們發現AUC是一個特別基礎的指標，對於兩份離線文件之間的評估確實有比較大的意義，尤其AUC在現在狀態下大家都訓練到0.7或0.8的水平，上線之後各種數據指標並不一定能提升那麼多，我們做了一個DCG Gain收益的指標，它具有更高的參考意義。
業務問題
- 多樣性問題如何解決？大家都知道Feed流裏很多時候最精準不一定是用戶最想要的，重複太多對於各種線上業務數據的改進也不一定是正向的結果，我們會引入各種框架進行業務導向的調權、打散、隔離和禁閉，一個內容出現幾次之後你沒有點擊，之後都不會推薦相似的內容。
- 如何避免「信息繭房」的產生？以各種行爲表現預估的方式去排序和推薦的推薦系統，最後會讓用戶傳遞一個信息繭房，推薦列表裏翻來覆去就是這麼幾個內容。我們的解決方案是，採用一個Explore & Exploit機制，針對老用戶及興趣比較均勻的用戶，適當減少興趣探測手段，在探測過程中也會盡量使用Tag之間的關聯信息增強探測效率。
-【完】-