今日頭條算法原理詳解全集，值得收藏！

今天，算法分發已是信息平臺、搜索引擎、瀏覽器、社交軟件等幾乎全部軟件的標配，但同時，算法也開始面臨質疑、挑戰和誤解。今日頭條的推薦算法，從 2012 年 9月初版開發運行至今，已經通過四次大的調整和修改。 

今日頭條委託資深算法架構師曹歡歡博士，公開今日頭條的算法原理，以期推進整個行業問診算法、建言算法；經過讓算法透明，來消除各界對算法的誤解，並逐步推進整個行業讓算法更好的造福社會。

如下爲《今日頭條算法原理》全文：
本次分享將主要介紹今日頭條推薦系統概覽以及內容分析、用戶標籤、評估分析等原理。

1、系統概覽
在這裏插入圖片描述
推薦系統，若是用形式化的方式去描述其實是擬合一個用戶對內容滿意度的函數，這個函數須要輸入三個維度的變量。

第一個維度是內容。頭條如今已是一個綜合內容平臺，圖文、視頻、UGC 小視頻、問答、微頭條，每種內容有不少本身的特徵，須要考慮怎樣提取不一樣內容類型的特徵作好推薦。

第二個維度是用戶特徵。包括各類興趣標籤，職業、年齡、性別等，還有不少模型刻劃出的隱式用戶興趣等。第三個維度是環境特徵。這是移動互聯網時代推薦的特色，用戶隨時隨地移動，在工做場合、通勤、旅遊等不一樣的場景，信息偏好有所偏移。結合三方面的維度，模型會給出一個預估，即推測推薦內容在這一場景下對這一用戶是否合適。

這裏還有一個問題，如何引入沒法直接衡量的目標？
推薦模型中，點擊率、閱讀時間、點贊、評論、轉發包括點贊都是能夠量化的目標，可以用模型直接擬合作預估，看線上提高狀況能夠知道作的好很差。但一個大致量的推薦系統，服務用戶衆多，不能徹底由指標評估，引入數據指標之外的要素也很重要。
好比廣告和特型內容頻控。像問答卡片就是比較特殊的內容形式，其推薦的目標不徹底是讓用戶瀏覽，還要考慮吸引用戶回答爲社區貢獻內容。這些內容和普通內容如何混排，怎樣控制頻控都須要考慮。

此外，平臺出於內容生態和社會責任的考量，像低俗內容的打壓，標題黨、低質內容的打壓，重要新聞的置頂、加權、強插，低級別帳號內容降權都是算法自己沒法完成，須要進一步對內容進行干預。
下面我將簡單介紹在上述算法目標的基礎上如何對其實現。
在這裏插入圖片描述
前面提到的公式 y = F(Xi ,Xu ,Xc)，是一個很經典的監督學習問題。可實現的方法有不少，好比傳統的協同過濾模型，監督學習算法 Logistic Regression 模型，基於深度學習的模型，Factorization Machine 和 GBDT 等。

一個優秀的工業級推薦系統須要很是靈活的算法實驗平臺，能夠支持多種算法組合，包括模型結構調整。由於很難有一套通用的模型架構適用於全部的推薦場景。

如今很流行將 LR 和 DNN 結合，前幾年 Facebook 也將 LR 和 GBDT 算法作結合。今日頭條旗下幾款產品都在沿用同一套強大的算法推薦系統，但根據業務場景不一樣，模型架構會有所調整。
模型以後再看一下典型的推薦特徵，主要有四類特徵會對推薦起到比較重要的做用。

第一類是相關性特徵。就是評估內容的屬性和與用戶是否匹配。顯性的匹配包括關鍵詞匹配、分類匹配、來源匹配、主題匹配等。像 FM 模型中也有一些隱性匹配，從用戶向量與內容向量的距離能夠得出。

第二類是環境特徵。包括地理位置、時間。這些既是 bias 特徵，也能以此構建一些匹配特徵。
第三類是熱度特徵。包括全局熱度、分類熱度，主題熱度，以及關鍵詞熱度等。內容熱度信息在大的推薦系統特別在用戶冷啓動的時候很是有效。

第四類是協同特徵。它能夠在部分程度上幫助解決所謂算法越推越窄的問題。協同特徵並不是考慮用戶已有歷史。而是經過用戶行爲分析不一樣用戶間類似性，好比點擊類似、興趣分類類似、主題類似、興趣詞類似，甚至向量類似，從而擴展模型的探索能力。

模型的訓練上，頭條系大部分推薦產品採用實時訓練。實時訓練省資源而且反饋快，這對信息流產品很是重要。
用戶須要行爲信息能夠被模型快速捕捉並反饋至下一刷的推薦效果。咱們線上目前基於 storm 集羣實時處理樣本數據，包括點擊、展示、收藏、分享等動做類型。

模型參數服務器是內部開發的一套高性能的系統，由於頭條數據規模增加太快，相似的開源系統穩定性和性能沒法知足，而咱們自研的系統底層作了不少針對性的優化，提供了完善運維工具，更適配現有的業務場景。

目前，頭條的推薦算法模型在世界範圍內也是比較大的，包含幾百億原始特徵和數十億向量特徵。總體的訓練過程是線上服務器記錄實時特徵，導入到 Kafka 文件隊列中，而後進一步導入 Storm 集羣消費 Kafka 數據，客戶端回傳推薦的 label 構造訓練樣本，隨後根據最新樣本進行在線訓練更新模型參數，最終線上模型獲得更新。

這個過程當中主要的延遲在用戶的動做反饋延時，由於文章推薦後用戶不必定立刻看，不考慮這部分時間，整個系統是幾乎實時的。

但由於頭條目前的內容量很是大，加上小視頻內容有千萬級別，推薦系統不可能全部內容所有由模型預估。
因此須要設計一些召回策略，每次推薦時從海量內容中篩選出千級別的內容庫。召回策略最重要的要求是性能要極致，通常超時不能超過 50 毫秒。

召回策略種類有不少，咱們主要用的是倒排的思路。離線維護一個倒排，這個倒排的 key 能夠是分類，topic，實體，來源等，排序考慮熱度、新鮮度、動做等。
線上召回能夠迅速從倒排中根據用戶興趣標籤對內容作截斷，高效的從很大的內容庫中篩選比較靠譜的一小部份內容。
在這裏插入圖片描述

2、內容分析
內容分析包括文本分析，圖片分析和視頻分析。頭條一開始主要作資訊，今天咱們主要講一下文本分析。文本分析在推薦系統中一個很重要的做用是用戶興趣建模。沒有內容及文本標籤，沒法獲得用戶興趣標籤。

舉個例子，只有知道文章標籤是互聯網，用戶看了互聯網標籤的文章，才能知道用戶有互聯網標籤，其餘關鍵詞也同樣。

另外一方面，文本內容的標籤能夠直接幫助推薦特徵，好比魅族的內容能夠推薦給關注魅族的用戶，這是用戶標籤的匹配。若是某段時間推薦主頻道效果不理想，出現推薦窄化，用戶會發現到具體的頻道推薦（如科技、體育、娛樂、軍事等）中閱讀後，再回主 feed, 推薦效果會更好。

由於整個模型是打通的，子頻道探索空間較小，更容易知足用戶需求。只經過單一信道反饋提升推薦準確率難度會比較大，子頻道作的好很重要。而這也須要好的內容分析。
能夠看到，這篇文章有分類、關鍵詞、topic、實體詞等文本特徵。固然不是沒有文本特徵，推薦系統就不能工做，推薦系統最先期應用在 Amazon，甚至沃爾瑪時代就有，包括 Netfilx 作視頻推薦也沒有文本特徵直接協同過濾推薦。

但對資訊類產品而言，大部分是消費當天內容，沒有文本特徵新內容冷啓動很是困難，協同類特徵沒法解決文章冷啓動問題。

今日頭條推薦系統主要抽取的文本特徵包括如下幾類。首先是語義標籤類特徵，顯式爲文章打上語義標籤。這部分標籤是由人定義的特徵，每一個標籤有明確的意義，標籤體系是預約義的。此外還有隱式語義特徵，主要是 topic 特徵和關鍵詞特徵，其中 topic 特徵是對於詞機率分佈的描述，無明確意義；而關鍵詞特徵會基於一些統一特徵描述，無明確集合。

另外文本類似度特徵也很是重要。在頭條，曾經用戶反饋最大的問題之一就是爲何總推薦重複的內容。這個問題的難點在於，每一個人對重複的定義不同。舉個例子，有人以爲這篇講皇馬和巴薩的文章，昨天已經看過相似內容，今天還說這兩個隊那就是重複。

但對於一個重度球迷而言，尤爲是巴薩的球迷，巴不得全部報道都看一遍。解決這一問題須要根據判斷類似文章的主題、行文、主體等內容，根據這些特徵作線上策略。

分類的目標是覆蓋全面，但願每篇內容每段視頻都有分類；而實體體系要求精準，相同名字或內容要能明確區分究竟指代哪個人或物，但不用覆蓋很全。概念體系則負責解決比較精確又屬於抽象概念的語義。
這是咱們最初的分類，實踐中發現分類和概念在技術上能互用，後來統一用了一套技術架構。

目前，隱式語義特徵已經能夠很好的幫助推薦，而語義標籤須要持續標註，新名詞新概念不斷出現，標註也要不斷迭代。其作好的難度和資源投入要遠大於隱式語義特徵，那爲何還須要語義標籤？

有一些產品上的須要，好比頻道須要有明肯定義的分類內容和容易理解的文本標籤體系。語義標籤的效果是檢查一個公司 NLP 技術水平的試金石。

今日頭條推薦系統的線上分類採用典型的層次化文本分類算法。最上面 Root，下面第一層的分類是像科技、體育、財經、娛樂，體育這樣的大類，再下面細分足球、籃球、乒乓球、網球、田徑、游泳……足球再細分國際足球、中國足球，中國足球又細分中甲、中超、國家隊……

相比單獨的分類器，利用層次化文本分類算法能更好地解決數據傾斜的問題。有一些例外是，若是要提升召回，能夠看到咱們鏈接了一些飛線。

這套架構通用，但根據不一樣的問題難度，每一個元分類器能夠異構，像有些分類 SVM 效果很好，有些要結合 CNN，有些要結合 RNN 再處理一下。

基於分詞結果和詞性標註選取候選，期間可能須要根據知識庫作一些拼接，有些實體是幾個詞的組合，要肯定哪幾個詞結合在一塊兒能映射實體的描述。
若是結果映射多個實體還要經過詞向量、topic 分佈甚至詞頻自己等去歧，最後計算一個相關性模型。

3、用戶標籤
內容分析和用戶標籤是推薦系統的兩大基石。內容分析涉及到機器學習的內容多一些，相比而言，用戶標籤工程挑戰更大。

今日頭條經常使用的用戶標籤包括用戶感興趣的類別和主題、關鍵詞、來源、基於興趣的用戶聚類以及各類垂直興趣特徵（車型，體育球隊，股票等）。還有性別、年齡、地點等信息。性別信息經過用戶第三方社交帳號登陸獲得。

年齡信息一般由模型預測，經過機型、閱讀時間分佈等預估。常駐地點來自用戶受權訪問位置信息，在位置信息的基礎上經過傳統聚類的方法拿到常駐點。常駐點結合其餘信息，能夠推測用戶的工做地點、出差地點、旅遊地點。這些用戶標籤很是有助於推薦。

固然最簡單的用戶標籤是瀏覽過的內容標籤。但這裏涉及到一些數據處理策略。

主要包括：

1、過濾噪聲。經過停留時間短的點擊，過濾標題黨。

2、熱點對用戶在一些熱門文章（如前段時間 PG One 的新聞）上的動做作降權處理。理論上，傳播範圍較大的內容，置信度會降低。

3、時間衰減。用戶興趣會發生偏移，所以策略更偏向新的用戶行爲。所以，隨着用戶動做的增長，老的特徵權重會隨時間衰減，新動做貢獻的特徵權重會更大。

4、懲罰展示。若是一篇推薦給用戶的文章沒有被點擊，相關特徵（類別，關鍵詞，來源）權重會被懲罰。
固然同時，也要考慮全局背景，是否是相關內容推送比較多，以及相關的關閉和 dislike 信號等。

用戶標籤挖掘整體比較簡單，主要仍是剛剛提到的工程挑戰。頭條用戶標籤初版是批量計算框架，流程比較簡單，天天抽取昨天的日活用戶過去兩個月的動做數據，在 Hadoop 集羣上批量計算結果。

但問題在於，隨着用戶高速增加，興趣模型種類和其餘批量處理任務都在增長，涉及到的計算量太大。2014 年，批量處理任務幾百萬用戶標籤更新的 Hadoop 任務，當天完成已經開始勉強。集羣計算資源緊張很容易影響其它工做，集中寫入分佈式存儲系統的壓力也開始增大，而且用戶興趣標籤更新延遲愈來愈高。

面對這些挑戰。2014 年末今日頭條上線了用戶標籤 Storm 集羣流式計算系統。改爲流式以後，只要有用戶動做更新就更新標籤，CPU 代價比較小，能夠節省 80% 的 CPU 時間，大大下降了計算資源開銷。

同時，只需幾十臺機器就能夠支撐天天數千萬用戶的興趣模型更新，而且特徵更新速度很是快，基本能夠作到準實時。這套系統從上線一直使用至今。