資深架構師首次公開揭祕:今日頭條推薦算法原理

今天,算法分發已是信息平臺、搜索引擎、瀏覽器、社交軟件等幾乎全部軟件的標配,但同時,算法也開始面臨質疑、挑戰和誤解。算法

網友整理的各大平臺推薦算法(搞笑版)數據庫

 

今日頭條的推薦算法,從 2012 年 9 月初版開發運行至今,已經通過四次大的調整和修改。後端

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

▲ 3 分鐘瞭解今日頭條推薦算法原理安全

 

本次分享主要圍繞五個方面介紹今日頭條的推薦原理:服務器

  • 系統概覽架構

  • 內容分析框架

  • 用戶標籤運維

  • 評估分析機器學習

  • 內容安全

系統概覽

 

推薦系統,若是用形式化的方式去描述其實是擬合一個用戶對內容滿意度的函數。

 

這個函數須要輸入三個維度的變量:

  • 內容。頭條如今已是一個綜合內容平臺,圖文、視頻、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,實體,來源等,排序考慮熱度、新鮮度、動做等。

 

線上召回能夠迅速從倒排中根據用戶興趣標籤對內容作截斷,高效的從很大的內容庫中篩選比較靠譜的一小部份內容。

內容分析

 

內容分析包括文本分析,圖片分析和視頻分析。頭條一開始主要作資訊,今天咱們主要講一下文本分析。

 

文本分析在推薦系統中一個很重要的做用是用戶興趣建模。沒有內容及文本標籤,沒法獲得用戶興趣標籤。

 

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

另外一方面,文本內容的標籤能夠直接幫助推薦特徵,好比魅族的內容能夠推薦給關注魅族的用戶,這是用戶標籤的匹配。

 

若是某段時間推薦主頻道效果不理想,出現推薦窄化,用戶會發現到具體的頻道推薦(如科技、體育、娛樂、軍事等)中閱讀後,再回主 Feed,推薦效果會更好。

 

由於整個模型是打通的,子頻道探索空間較小,更容易知足用戶需求。只經過單一信道反饋提升推薦準確率難度會比較大,子頻道作的好很重要。而這也須要好的內容分析。

上圖是今日頭條的一個實際文本 case。從圖中能夠看到,這篇文章有分類、關鍵詞、topic、實體詞等文本特徵。

 

固然不是沒有文本特徵,推薦系統就不能工做,推薦系統最先期應用在 Amazon,甚至沃爾瑪時代就有,包括 Netfilx 作視頻推薦也沒有文本特徵直接協同過濾推薦。

 

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

今日頭條推薦系統主要抽取的文本特徵包括如下幾類。首先是語義標籤類特徵,顯式爲文章打上語義標籤。這部分標籤是由人定義的特徵,每一個標籤有明確的意義,標籤體系是預約義的。

 

此外還有隱式語義特徵,主要是 topic 特徵和關鍵詞特徵,其中 topic 特徵是對於詞機率分佈的描述,無明確意義;而關鍵詞特徵會基於一些統一特徵描述,無明確集合。

另外文本類似度特徵也很是重要。在頭條,曾經用戶反饋最大的問題之一就是爲何總推薦重複的內容。這個問題的難點在於,每一個人對重複的定義不同。

 

舉個例子,有人以爲這篇講皇馬和巴薩的文章,昨天已經看過相似內容,今天還說這兩個隊那就是重複。

 

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

 

一樣,還有時空特徵,分析內容的發生地點以及時效性。好比武漢限行的事情推給北京用戶可能就沒有意義。

 

最後還要考慮質量相關特徵,判斷內容是否低俗,色情,是不是軟文,雞湯?

上圖是頭條語義標籤的特徵和使用場景。他們之間層級不一樣,要求不一樣。

分類的目標是覆蓋全面,但願每篇內容每段視頻都有分類;而實體體系要求精準,相同名字或內容要能明確區分究竟指代哪個人或物,但不用覆蓋很全。

 

概念體系則負責解決比較精確又屬於抽象概念的語義。這是咱們最初的分類,實踐中發現分類和概念在技術上能互用,後來統一用了一套技術架構。

目前,隱式語義特徵已經能夠很好的幫助推薦,而語義標籤須要持續標註,新名詞新概念不斷出現,標註也要不斷迭代。

 

其作好的難度和資源投入要遠大於隱式語義特徵,那爲何還須要語義標籤?

 

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

今日頭條推薦系統的線上分類採用典型的層次化文本分類算法。

 

最上面是 Root,下面第一層的分類是像科技、體育、財經、娛樂,體育這樣的大類。

 

再下面細分足球、籃球、乒乓球、網球、田徑、游泳等,足球再細分國際足球、中國足球,中國足球又細分中甲、中超、國家隊等。

 

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

 

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

上圖是一個實體詞識別算法的 case。基於分詞結果和詞性標註選取候選,期間可能須要根據知識庫作一些拼接,有些實體是幾個詞的組合,要肯定哪幾個詞結合在一塊兒能映射實體的描述。

 

若是結果映射多個實體還要經過詞向量、topic 分佈甚至詞頻自己等去歧,最後計算一個相關性模型。

用戶標籤

 

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

今日頭條經常使用的用戶標籤包括用戶感興趣的類別和主題、關鍵詞、來源、基於興趣的用戶聚類以及各類垂直興趣特徵(車型,體育球隊,股票等)。還有性別、年齡、地點等信息。

 

性別信息經過用戶第三方社交帳號登陸獲得。年齡信息一般由模型預測,經過機型、閱讀時間分佈等預估。

 

常駐地點來自用戶受權訪問位置信息,在位置信息的基礎上經過傳統聚類的方法拿到常駐點。

 

常駐點結合其餘信息,能夠推測用戶的工做地點、出差地點、旅遊地點。這些用戶標籤很是有助於推薦。

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

  • 過濾噪聲。經過停留時間短的點擊,過濾標題黨。

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

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

  • 懲罰展示。若是一篇推薦給用戶的文章沒有被點擊,相關特徵(類別,關鍵詞,來源)權重會被懲罰。

    固然同時,也要考慮全局背景,是否是相關內容推送比較多,以及相關的關閉和 dislike 信號等。

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

但問題在於,隨着用戶高速增加,興趣模型種類和其餘批量處理任務都在增長,涉及到的計算量太大。

 

2014 年,批量處理幾百萬用戶標籤更新的 Hadoop 任務,當天完成已經開始勉強。

 

集羣計算資源緊張很容易影響其餘工做,集中寫入分佈式存儲系統的壓力也開始增大,而且用戶興趣標籤更新延遲愈來愈高。

面對這些挑戰,2014 年末今日頭條上線了用戶標籤 Storm 集羣流式計算系統。

 

改爲流式以後,只要有用戶動做更新就更新標籤,CPU 代價比較小,能夠節省 80% 的 CPU 時間,大大下降了計算資源開銷。

 

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

固然,咱們也發現並不是全部用戶標籤都須要流式系統。像用戶的性別、年齡、常駐地點這些信息,不須要實時重複計算,就仍然保留 daily 更新。

評估分析

 

上面介紹了推薦系統的總體架構,那麼如何評估推薦效果好很差?有一句我認爲很是有智慧的話,「一個事情無法評估就無法優化」。對推薦系統也是同樣。

事實上,不少因素都會影響推薦效果。好比侯選集合變化,召回模塊的改進或增長,推薦特徵的增長,模型架構的改進,算法參數的優化等等。

 

評估的意義就在於,不少優化最終多是負向效果,並非優化上線後效果就會改進。

全面的評估推薦系統,須要完備的評估體系、強大的實驗平臺以及易用的經驗分析工具。

 

所謂完備的體系就是並不是單一指標衡量,不能只看點擊率或者停留時長等,須要綜合評估。

 

過去幾年咱們一直在嘗試,能不能綜合儘量多的指標合成惟一的評估指標,但仍在探索中。目前,咱們上線仍是要由各業務比較資深的同窗組成評審委員會深刻討論後決定。

 

不少公司算法作的很差,並不是是工程師能力不夠,而是須要一個強大的實驗平臺,還有便捷的實驗分析工具,能夠智能分析數據指標的置信度。

一個良好的評估體系創建須要遵循幾個原則,首先是兼顧短時間指標與長期指標。

 

我在以前公司負責電商方向的時候觀察到,不少策略調整短時間內用戶以爲新鮮,可是長期看其實沒有任何助益。

 

其次,要兼顧用戶指標和生態指標。今日頭條做爲內容分發創做平臺,既要爲內容創做者提供價值,讓他更有尊嚴的創做,也有義務知足用戶,這二者要平衡。還有廣告主利益也要考慮,這是多方博弈和平衡的過程。

 

另外,要注意協同效應的影響。實驗中嚴格的流量隔離很難作到,要注意外部效應。

強大的實驗平臺很是直接的優勢是,當同時在線的實驗比較多時,能夠由平臺自動分配流量,無需人工溝通,而且實驗結束流量當即回收,提升管理效率。

 

這能幫助公司下降分析成本,加快算法迭代效應,使整個系統的算法優化工做可以快速往前推動。

這是頭條 A/B Test 實驗系統的基本原理。首先咱們會在離線狀態下作好用戶分桶,而後線上分配實驗流量,將桶裏用戶打上標籤,分給實驗組。

 

舉個例子,開一個 10% 流量的實驗,兩個實驗組各 5%,一個 5% 是基線,策略和線上大盤同樣,另一個是新的策略。

實驗過程當中用戶動做會被蒐集,基本上是準實時,每小時均可以看到。但由於小時數據有波動,一般是以天爲時間節點來看。動做蒐集後會有日誌處理、分佈式統計、寫入數據庫,很是便捷。

在這個系統下工程師只須要設置流量需求、實驗時間、定義特殊過濾條件,自定義實驗組 ID。

 

系統能夠自動生成:實驗數據對比、實驗數據置信度、實驗結論總結以及實驗優化建議。

固然,只有實驗平臺是遠遠不夠的。線上實驗平臺只能經過數據指標變化推測用戶體驗的變化,但數據指標和用戶體驗存在差別,不少指標不能徹底量化。不少改進仍然要經過人工分析,重大改進須要人工評估二次確認。

內容安全

 

最後要介紹今日頭條在內容安全上的一些舉措。頭條如今已是國內最大的內容創做與分發平臺,必須愈來愈重視社會責任和行業領導者的責任。若是 1% 的推薦內容出現問題,就會產生較大的影響。

 

所以頭條從創立伊始就把內容安全放在公司最高優先級隊列。成立之初,它已經專門設有審覈團隊負責內容安全。

 

當時研發全部客戶端、後端、算法的同窗一共纔不到 40 人,可見頭條很是重視內容審覈。

如今,今日頭條的內容主要來源於兩部分:

  • 具備成熟內容生產能力的 PGC 平臺。

  • UGC 用戶內容,如問答、用戶評論、微頭條。

 

這兩部份內容須要經過統一的審覈機制。若是是數量相對少的 PGC 內容,會直接進行風險審覈,沒有問題會大範圍推薦。

 

UGC 內容須要通過一個風險模型的過濾,有問題的會進入二次風險審覈。審覈經過後,內容會被真正進行推薦。

 

這時若是收到必定量以上的評論或者舉報負向反饋,還會再回到複審環節,有問題直接下架。

 

整個機制相對而言比較健全,做爲行業領先者,在內容安全上,今日頭條一直用最高的標準要求本身。

分享內容識別技術主要有鑑黃模型,俗模型以及謾罵模型。今日頭條的低俗模型經過深度學習算法訓練,樣本庫很是大,圖片、文本同時分析。

 

這部分模型更注重召回率,準確率甚至能夠犧牲一些。謾罵模型的樣本庫一樣超過百萬,召回率高達 95%+,準確率 80%+。若是用戶常常出言不諱或者不當的評論,咱們有一些懲罰機制。

泛低質識別涉及的狀況很是多,像假新聞、黑稿、題文不符、標題黨、內容質量低等等,這部份內容由機器理解是很是難的,須要大量反饋信息,包括其餘樣本信息比對。

 

目前低質模型的準確率和召回率都不是特別高,還須要結合人工複審,將閾值提升。目前最終的召回已達到 95%,這部分其實還有很是多的工做能夠作。

 

頭條人工智能實驗室李航老師目前也在和密歇根大學共建科研項目,設立謠言識別平臺。

 

以上是頭條推薦系統的原理分享,但願將來獲得更多的建議,幫助咱們更好改進工做。

轉自:今日頭條官方號

相關文章
相關標籤/搜索