詳細解讀!推薦演算法架構——召回

語言: CN / TW / HK

導語 | 召回模組面對幾百上千萬的推薦池物料規模,候選集十分龐大。由於後續有排序模組作為保障,故不需要十分準確,但必須保證不要遺漏和低延遲。目前主要通過多路召回來實現,一方面各路可以平行計算,另一方面取長補短。召回通路主要有非個性化和個性化兩大類。

一、推薦演算法總體架構

 

(一)推薦演算法意義

 

隨著網際網路近十年來的大力發展,使用者規模和內容規模均呈現迅猛發展。使用者側日活過億早已不是什麼新鮮事,內容側由於UGC生產方式的普及,擁有幾十億內容庫的平臺也屢見不鮮。如何讓海量使用者在海量內容中找到自己喜歡的,以及如何讓海量內容被海量使用者精準消費,一直以來都是每個公司十分核心的問題。在這個背景下,搜尋系統和推薦系統應運而生。搜尋系統主要解決使用者尋找感興趣的內容,偏主動型消費。推薦系統則主要解決內容推送給合適使用者,偏被動型消費。二者一邊牽引使用者,一邊牽引內容,是實現使用者與內容匹配的中間媒介。推薦系統在每個公司都是十分核心的地位,其意義主要有:

 

  • 使用者側,為使用者及時精準的推送感興趣的個性化內容,並不斷髮現和培養使用者的潛在興趣,滿足使用者消費需求,提升使用者體驗,從而提升使用者活躍度和留存。
  • 內容側,作為流量分發平臺,對生產者(如UGC作者、電商賣家等)有正向反饋刺激能力,通過扶持有潛力的中小生產者,可以促進整體內容生態的繁榮發展。
  • 平臺側,推薦系統對內容分發的流量和效率都至關重要。通過提升使用者體驗,可提升使用者留存,從而提升日活。通過提升使用者轉化和流量效率,可提升電商平臺訂單量和內容平臺使用者人均時長等核心指標。通過提升使用者消費深度,可提升平臺整體流量,為商業化目標(如廣告)打下基礎,提升ARPU(每使用者平均收入)等核心指標。推薦系統與公司很多核心指標息息相關,有極大的牽引和推動作用,意義十分重要。

 

 

(二)推薦演算法基本模組

 

當前基於算力和儲存的考慮,還沒辦法實現整體端到端的推薦。一般來說推薦系統分為以下幾個主要模組:

 

  • 推薦池:一般會基於一些規則,從整體物料庫(可能會有幾十億甚至百億規模)中選擇一些item進入推薦池,再通過汰換規則定期進行更新。比如電商平臺可以基於近30天成交量、商品在所屬類目價格檔位等構建推薦池,短視訊平臺可以基於釋出時間、近7天播放量等構建推薦池。推薦池一般定期離線構建好就可以了。
  • 召回:從推薦池中選取幾千上萬的item,送給後續的排序模組。由於召回面對的候選集十分大,且一般需要線上輸出,故召回模組必須輕量快速低延遲。由於後續還有排序模組作為保障,召回不需要十分準確,但不可遺漏(特別是搜尋系統中的召回模組)。目前基本上採用多路召回解決正規化,分為非個性化召回和個性化召回。個性化召回又有content-based、behavior-based、feature-based等多種方式。
  • 粗排:獲取召回模組結果,從中選擇上千item送給精排模組。粗排可以理解為精排前的一輪過濾機制,減輕精排模組的壓力。粗排介於召回和精排之間,要同時兼顧精準性和低延遲。一般模型也不能過於複雜。
  • 精排:獲取粗排模組的結果,對候選集進行打分和排序。精排需要在最大時延允許的情況下,保證打分的精準性,是整個系統中至關重要的一個模組,也是最複雜,研究最多的一個模組。精排系統構建一般需要涉及樣本、特徵、模型三部分。
  • 重排:獲取精排的排序結果,基於運營策略、多樣性、context上下文等,重新進行一個微調。比如三八節對美妝類目商品提權,類目打散、同圖打散、同賣家打散等保證使用者體驗措施。重排中規則比較多,但目前也有不少基於模型來提升重排效果的方案。
  • 混排:多個業務線都想在Feeds流中獲取曝光,則需要對它們的結果進行混排。比如推薦流中插入廣告、視訊流中插入圖文和banner等。可以基於規則策略(如廣告定坑)和強化學習來實現。

 

推薦系統包含模組很多,論文也是層出不窮,相對來說還是十分複雜的。我們掌握推薦系統演算法最重要的還是要梳理清楚整個演算法架構和大圖,知道每個模組是怎麼做的,有哪些侷限性和待解決問題,可以通過什麼手段優化等。並通過演算法架構大圖將各個模組聯絡起來,融會貫通。從而不至於深陷某個細節,不能自拔。看論文的時候也應該先了解它是為了解決什麼問題,之前已經有哪些解決方案,再去了解它怎麼解決的,以及相比其他方案有什麼改進和優化點。本文主要講解推薦演算法架構大圖,幫助讀者掌握全域性,起到提綱挈領作用。

 

二、召回

 

(一)多路召回

 

 

召回模組面對幾百上千萬的推薦池物料規模,候選集十分龐大。由於後續有排序模組作為保障,故不需要十分準確,但必須保證不要遺漏和低延遲。目前主要通過多路召回來實現,一方面各路可以平行計算,另一方面取長補短。召回通路主要有非個性化和個性化兩大類。

 

  • 非個性化召回

非個性化召回與使用者無關,可以離線構建好,主要有:

  • 熱門召回:比如近7天播放vv比較高的短視訊,可以結合CTR和時間衰減做平滑,並過濾掉人均時長偏低的疑似騙點選item。還可以選擇使用者點贊多、好評多的item等。這部分主要基於規則實現即可。由於熱門item容易導致馬太效應,如果熱門召回佔整體通路比例過大,可以考慮做一定打壓。
  • 高效率召回:比如高CTR、高完播率、高人均時長的短視訊,這類item效率較高,但可能上架不久,歷史播放vv不多,好評也需要時間積累,有可能不在熱門召回內。
  • 運營策略召回:例如運營構建的各個類目的榜單、片單,最新上架item等。

 

  • 個性化召回

個性化召回與使用者相關,千人千面,根據構建方式主要有:

 

  • content-based:基於內容,可以通過使用者標籤,比如新註冊時填寫的喜歡的導演、演員、類目等資訊,也可以通過使用者歷史行為作為trigger,來選取與之內容相似的item。主要有:
  • 標籤召回:比如演員、導演、item標籤tag、類目等。
  • 知識圖譜。
  • 多模態:比如標題語義相似的item,首圖相似的item,視訊理解相似的item等。

一般先離線構建好倒排索引,線上使用時通過使用者標籤或者歷史行為item作為trigger,取出對應候選即可。基於內容來構建倒排索引,不需要item有豐富的行為,對冷啟item比較友好。

  • behavior-based:基於行為,主要是userCF和itemCF兩種,都是通過行為來找相似,需要user或者item有比較豐富的行為。userCF先找到與user行為相似的user,選取他們行為序列中的item作為候選。itemCF則找到每個item被行為相似的其他item,構建倒排索引。

 

二者使用的時候有什麼區別呢,個人認為主要有:

 

  • userCF需要user行為較為豐富,itemCF則需要item被行為比較豐富。所以對於新聞類等item實時性要求高的場景,由於冷啟item很多,所以可以考慮userCF。
  • 一般來說使用者量要遠大於推薦池的item數量,也就是user向量遠多於item向量,故userCF的儲存壓力和向量檢索壓力都要大於itemCF。同時也導致user向量遠比item向量要稀疏,相似度計算準確性不如itemCF。

 

協同過濾有哪些缺點呢?

  • 由於大部分user只對很少一部分item有行為,導致user與item的行為矩陣十分稀疏,甚至有些user根本沒有任何行為,影響了向量相似度計算準確性。
  • user和item數量都很大,行為矩陣儲存壓力很大。
  • 矩陣稀疏也帶來一個問題,就是頭部熱門item容易與大多數item均相似,產生哈利波特問題,導致極其嚴重的馬太效應。

 

那怎麼解決這些問題呢,矩陣分解MF應運而生。它將user與item的行為矩陣,分解為user和item兩個矩陣,M*N的矩陣轉化為M*K和K*N的兩個矩陣,user矩陣每一行就是一個K維user向量,item矩陣每一列就是一個K維item向量。由於不像CF中向量是基於行為產生的,有比較明確的含義,故MF中的向量也叫user隱向量和item隱向量。通過MF,可以解決CF向量過於稀疏的問題,同時由於K遠小於M和N,使得高維稀疏向量實現了低維稠密化,大大減小了儲存壓力。

 

MF矩陣分解有哪些實現方法呢,可以基於SVD和梯度下降來計算。由於SVD有一定限制條件,基於梯度下降的比較多。因此MF也被稱為model-based CF。

MF本質上仍然是基於使用者行為來構建的,沒有充分利用user和item的各種feature,比如使用者性別年齡,導致有大量的資訊丟失。LR和FM就應運而生。

 

  • feature-based:基於特徵,比如user的年齡、性別、機型、地理位置、行為序列等,item的上架時間、視訊時長、歷史統計資訊等。基於特徵的召回構建方式,資訊利用比較充分,效果一般也比較好,對冷啟也比較友好,是最近幾年來的研究重點。又主要分為:
  • 線性模型:比如FM、FFM等,就不具體展開了。
  • 深度模型:比如基於DNN的DSSM雙塔(EBR、MOBIUS)、youtubeDNN(又叫deepMatch)。基於使用者序列的Mind、SDM、CMDM、BERT4Rec。基於GNN的Node2Vec、EGES、PingSage等。這一塊就不一一展開,是很大的話題。

 

線上使用時,可以有兩種方式:

  • 向量檢索:通過生成的user embedding,採用近鄰搜尋,尋找與之相似的item embedding,從而找到具體item。檢索方式有雜湊分桶、HNSW等多種方法。
  • i2i倒排索引:通過item embedding,找到與本item相似的其他item,離線構建i2i索引。線上使用時,通過使用者歷史行為中的item作為trigger,從倒排索引中找到候選集。

 

  • social-network:通過好友點贊、關注關係、通訊錄關係等,找到社交鏈上的其他人,然後通過他們來召回item。原則就是好友喜歡的item,大概率也會喜歡,物以類聚人以群分嘛。

 

(二)召回優化

 

 

多路召回的各通路主要就是這些,那召回中主要有哪些問題呢,個人認為主要有:

 

  • 負樣本構建問題:召回是樣本的藝術,排序是特徵的藝術,這句話說的很對。召回正樣本可以選擇曝光點選的樣本,但負樣本怎麼選呢?選擇曝光未點選的樣本嗎,肯定不行。
  • 曝光未點選樣本,能從已有召回、粗排、精排模組中競爭出來,說明其item質量和相關性都還是不錯的,作為召回負樣本肯定不合適。
  • SSB問題,召回面向的全體推薦池,但能得到曝光的item只是其中很小的子集,這樣構建負樣本會導致十分嚴重的SSB(sample selection bias)問題,使得模型嚴重偏離實際。

 

基於這個問題,我們可以在推薦池中隨機選擇item作為負樣本,但又會有一個問題,隨機選擇的item,相對於正樣本來說,一般很容易區分,所以需要有hard negative sample來刺激和提升召回模型效果。構建hard negative sample,是目前召回研究中比較多的一個方向,主要有:

 

  1. 藉助模型:比如Facebook EBR選取上一版召回打分處於中間位置的item,排名101~500左右的item,它們不是很靠前,可以看做負樣本,也不是吊車尾,與正樣本有一定相關性,區分起來有一定難度。EBR、Mobius、PinSage等都有類似思路。這種方法很難定義清楚到底什麼樣的item是有點相似,但又不那麼相似,可能需要多次嘗試。
  2. 業務規則:比如選擇同類目、同價格檔位等規則的item,可以參考Airbnb論文的做法。
  3. in-batch:batch內其他使用者正樣本,作為本使用者的負樣本。
  4. 主動學習:召回結果進行人工稽核,bad case作為負樣本。

一般會將hard negative與easy negative,按照一定比例,比如1: 100,同時作為召回負樣本。一般easy negative還是佔絕大多數的。

 

  1. SSB問題:召回面向的是全體推薦池,item數量巨大,故需要做一定的負取樣,有比較大的SSB樣本選擇偏差問題。故需要讓選擇出來的負樣本,儘可能的能代表全體推薦池,從而提升模型泛化能力。主要問題仍然是負取樣,特別是hard negative sample的問題。阿里ESAM嘗試用遷移學習,通過loss正則使得曝光樣本上的模型,可以應用在非曝光item上,從而優化SSB問題。其他更多的方法則考慮從負樣本取樣出發,結合easy negative和hard negative。比如EBR、Airbnb Embedding、Mobius、PinSage等,都有hard negative的優化思路。
  2. 目標不一致問題:目前的召回目標仍然是找相似,不論是基於內容的,還是基於行為和特徵的。但精排和最終實際業務指標仍然看的是轉化,相似不代表就能得到很好的轉化,比如極端情況,全部召回與使用者最近播放相似的短視訊,顯然最終整體的轉化是不高的。百度Mobius在召回階段引入CPM,將業務目標作為向量檢索後的截斷,可優化相關性高但轉化率低的item。阿里的TDM則通過最大堆樹重構了ANN召回檢索過程,大大降低了檢索計算量,從而可容納複雜模型,比如DIN,使得召回與排序在結構上可以對齊(當然樣本上會差異很大),也算是對此類問題有一定的優化。
  3. 競爭問題:各召回通路最終會做merge去重,各通道之間重複度過高則沒有意義,特別是新增召回通路,需要對歷史通路有較好的補充增益作用,各召回通路之間存在一定的重疊和競爭問題。同時,召回通路的候選item,不一定能在精排中競爭透出,特別是歷史召回少的item,由於其曝光樣本很少,精排中打分不高,所以不一定能透出。召回和精排的相愛相殺,還需要通過全鏈路優化來緩解。

作者簡介

謝楊易

騰訊應用演算法研究員。