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

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

在上篇_《_超強指南！推薦算法架構——重排_》_中我們結合算法架構重排進行解讀分析，本篇將深入召回這個模塊進行闡述。

一、推薦算法總體架構

（一）推薦算法意義

隨着互聯網近十年來的大力發展，用戶規模和內容規模均呈現迅猛發展。用戶側日活過億早已不是什麼新鮮事，內容側由於 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 兩個矩陣，MN 的矩陣轉化爲 MK 和 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，由於其曝光樣本很少，精排中打分不高，所以不一定能透出。召回和精排的相愛相殺，還需要通過全鏈路優化來緩解。

** 作者簡介**

謝楊易

騰訊應用算法研究員

騰訊應用算法研究員，畢業於中國科學院，目前在騰訊負責視頻推薦算法工作，有豐富的自然語言處理和搜索推薦算法經驗。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/1wOnG4dtNSI-x2x15-AjTQ