推薦系統技術演進趨勢：召回篇

作者：張俊林

新浪微博 AI Lab 負責人

背景

    在寫技術趨勢前，照例還是對推薦系統的宏觀架構做個簡單說明，以免讀者迷失在技術細節中。

    實際的工業推薦系統，如果粗分的化，經常講的有兩個階段。首先是召回，主要根據用戶部分特徵，從海量的物品庫裏，快速找回一小部分用戶潛在感興趣的物品，然後交給排序環節，排序環節可以融入較多特徵，使用複雜模型，來精準地做個性化推薦。召回強調快，排序強調準。當然，這是傳統角度看推薦這個事情。

    但是，如果我們更細緻地看實用的推薦系統，一般會有四個環節，如下圖所示：

    四個環節分別是：召回、粗排、精排和重排。

    召回目的如上所述；有時候因爲每個用戶召回環節返回的物品數量還是太多，怕排序環節速度跟不上，所以可以在召回和精排之間加入一個粗排環節，通過少量用戶和物品特徵，簡單模型，來對召回的結果進行個粗略的排序，在保證一定精準的前提下，進一步減少往後傳送的物品數量，粗排往往是可選的，可用可不同，跟場景有關。

    之後，是精排環節，使用你能想到的任何特徵，可以上你能承受速度極限的複雜模型，儘量精準地對物品進行個性化排序。排序完成後，傳給重排環節，傳統地看，這裏往往會上各種技術及業務策略，比如去已讀、去重、打散、多樣性保證、固定類型物品插入等等，主要是技術產品策略主導或者爲了改進用戶體驗的。

    那麼，每個環節，從技術發展的角度看，都各自有怎樣的發展趨勢呢？下面我們分頭說明。

召回技術演進趨勢

    推薦系統的召回階段是很關鍵的一個環節，但是客觀的說，傳統地看，這個環節，技術含量是不太高的，偏向策略型導向，往往靈機一動，就能想到一個策略，增加一路新的召回。你在網上搜，發現講推薦模型的，95% 是講排序階段的模型，講召回的別說模型，講它本身的都很少，這與它的策略導向有關係，大家覺得沒什麼好講的。

    總體而言，召回環節的有監督模型化以及一切 Embedding 化，這是兩個相輔相成的總體發展趨勢。而打 embedding 的具體方法，則可以有各種選擇，比如下面介紹的幾個技術發展趨勢，可以理解爲不同的給用戶和物品打 embedding 的不同方法而已。

模型召回

    傳統的標準召回結構一般是多路召回，如上圖所示。如果我們根據召回路是否有用戶個性化因素存在來劃分，可以分成兩大類：

    一類是無個性化因素的召回路，比如熱門商品或者熱門文章或者歷史點擊率高的物料的召回；另外一類是包含個性化因素的召回路，比如用戶興趣標籤召回。

    我們應該怎麼看待包含個性化因素的召回路呢？其實吧，你可以這麼看，可以把某個召回路看作是：單特徵模型排序的排序結果。意思是，可以把某路召回，看成是某個排序模型的排序結果，只不過，這個排序模型，在用戶側和物品側只用了一個特徵。

    比如說，標籤召回，其實就是用用戶興趣標籤和物品標籤進行排序的單特徵排序結果；再比如協同召回，可以看成是隻包含 UID 和 ItemID 的兩個特徵的排序結果…. 諸如此類。我們應該統一從排序的角度來看待推薦系統的各個環節，這樣可能會更好理解本文所講述的一些技術。

    如果我們換做上面的角度看待有個性化因素召回路，那麼在召回階段引入模型，就是自然而然的一個拓展結果：無非是把單特徵排序，拓展成多特徵排序的模型而已；而多路召回，則可以通過引入多特徵，被融入到獨立的召回模型中，找到它的替代品。如此而已。所以，隨着技術的發展，在 embedding 基礎上的模型化召回，必然是個符合技術發展潮流的方向。

    那麼如何在召回階段利用模型來代替多路召回呢？

    上圖展示了一個抽象的模型召回的通用架構，核心思想是：將用戶特徵和物品特徵分離，各自通過某個具體的模型，分別打出用戶 Embedding 以及物品 Embedding。在線上，可以根據用戶興趣 Embedding，採用類似 Faiss 等高效 Embedding 檢索工具，快速找出和用戶興趣匹配的物品，這樣就等於做出了利用多特徵融合的召回模型了。理論上來說，任何你能見到的有監督模型，都可以用來做這個召回模型，比如 FM／FFM／DNN 等，常說的所謂 “雙塔” 模型，指的其實是用戶側和物品側特徵分離分別打 Embedding 的結構而已，並非具體的模型。

    模型召回具備自己獨有的好處和優勢，比如多路召回每路截斷條數的超參個性化問題等會自然被消解掉。當然，它也會帶來自己的問題，比較典型的是召回內容頭部問題，因爲之前多路，每路召回個數靠硬性截斷，可以根據需要，保證你想要召回的，總能通過某一路拉回來；而由於換成了模型召回，面向海量物料庫，排在前列得分高的可能聚集在幾個物料分佈比較多的頭部領域。解決這個問題的方法包括比如訓練數據對頭部領域的降採樣，減少某些領域主導，以及在模型角度鼓勵多樣性等不同的方法。

    另外一點值得注意的是：如果在召回階段使用模型召回，理論上也應該同步採用和排序模型相同的優化目標，尤其是如果排序階段採用多目標優化的情況下，召回模型也應該對應採取相同的多目標優化。同理，如果整個流程中包含粗排模塊，粗排也應該採用和精排相同的多目標優化，幾個環節優化目標應保持一致。因爲召回和粗排是精排的前置環節，否則，如果優化目標不一致，很可能會出現高質量精排目標，在前置環節就被過濾掉的可能，影響整體效果。

典型工作

用戶行爲序列召回

    用戶在使用 APP 或者網站的時候，一般會產生一些針對物品的行爲，比如點擊一些感興趣的物品，收藏或者互動行爲，或者是購買商品等。而一般用戶之所以會對物品發生行爲，往往意味着這些物品是符合用戶興趣的，而不同類型的行爲，可能代表了不同程度的興趣。比如購買就是比點擊更能表徵用戶興趣的行爲。

    而用戶行爲過的物品序列，其實是具備表徵用戶興趣的非常有價值的信息，而且這種興趣表徵，是細粒度的用戶興趣，所以對於刻畫用戶興趣具備特別的價值。利用用戶行爲過的物品序列，來表徵用戶興趣，具備很好的實用價值。

    如果我們抽象地來看的話，利用用戶行爲過的物品序列對用戶興趣建模，本質上就是這麼個過程：輸入是用戶行爲過的物品序列，可以只用物品 ID 表徵，也可以融入物品的 Side Information 比如名稱，描述，圖片等，現在我們需要一個函數 Fun，這個函數以這些物品爲輸入，需要通過一定的方法把這些進行糅合到一個 embedding 裏，而這個糅合好的 embedding，就代表了用戶興趣。無論是在召回過程，還是排序過程，都可以融入用戶行爲序列。在召回階段，我們可以用用戶興趣 Embedding 採取向量召回，而在排序階段，這個 embedding 則可以作爲用戶側的特徵。

    所以，核心在於：這個物品聚合函數 Fun 如何定義的問題。這裏需要注意的一點是：用戶行爲序列中的物品，是有時間順序的。理論上，任何能夠體現時序特點或特徵局部性關聯的模型，都比較適合應用在這裏，典型的比如 CNN、RNN、Transformer 等，都比較適合用來集成用戶行爲序列信息。而目前的很多試驗結果證明，GRU（RNN 的變體模型）可能是聚合用戶行爲序列效果最好又比較簡單的模型。當然，RNN 不能並行的低效率，那是另外一個問題。

    在召回階段，如何根據用戶行爲序列打 embedding，可以採取有監督的模型，比如 Next Item Prediction 的預測方式即可；也可以採用無監督的方式，比如物品只要能打出 embedding，就能無監督集成用戶行爲序列內容，例如 Sum Pooling。而排序側，必然是有監督的模式，需要注意的是：排序側表徵用戶特徵的時候，可以只用用戶行爲過的物品序列，也可以混合用戶其它特徵，比如羣體屬性特徵等一起來表徵用戶興趣，方式比較靈活。比如 DIEN，就是典型的採用混合模式的方法。

典型工作

用戶多興趣拆分

    上文講了利用用戶行爲物品序列，打出用戶興趣 Embedding 的做法。但是，另外一個現實是：用戶往往是多興趣的，比如可能同時對娛樂、體育、收藏感興趣。這些不同的興趣也能從用戶行爲序列的物品構成上看出來，比如行爲序列中大部分是娛樂類，一部分體育類，少部分收藏類等。那麼能否把用戶行爲序列物品中，這種不同類型的用戶興趣細分，而不是都籠統地打到一個用戶興趣 Embedding 裏呢？用戶多興趣拆分就是解決這類更細緻刻畫用戶興趣的方向。

    用戶多興趣拆分，本質上是上文所敘述的用戶行爲序列打 embedding 方向的一個細化，無非上文說的是：以用戶行爲序列物品作爲輸入，通過一些能體現時序特點的模型，映射成一個用戶興趣 embedding。而用戶多興趣拆分，輸入是一樣的，輸出不同，無非由輸出單獨一個用戶 embedding，換成輸出多個用戶興趣 embedding 而已。雖說道理如此，但是在具體技術使用方向上卻不太一樣，對於單用戶興趣 embedding 來說，只需要考慮信息有效集成即可。

**    而對於多用戶興趣拆分來說，需要多做些事情，多做什麼事情呢？**本質上，把用戶行爲序列打到多個 embedding 上，實際它是個類似聚類的過程，就是把不同的 Item，聚類到不同的興趣類別裏去。目前常用的拆分用戶興趣 embedding 的方法，主要是膠囊網絡和 Memory Network，但是理論上，很多類似聚類的方法應該都是有效的，所以完全可以在這塊替換成你自己的能產生聚類效果的方法來做。

    說到這裏，有同學會問了：把用戶行爲序列拆分到不同的 embedding 裏，有這個必要嗎？反正不論怎樣，即使是一個 embedding，信息都已經包含到裏面了，並未有什麼信息損失問題呀。這個問題很好。

    我的個人感覺是：在召回階段，把用戶興趣拆分成多個 embedding 是有直接價值和意義的，前面我們說過，召回階段有時候容易碰到頭部問題，就是比如通過用戶興趣 embedding 拉回來的物料，可能集中在頭部優勢領域中，造成弱勢興趣不太能體現出來的問題。而如果把用戶興趣進行拆分，每個興趣 embedding 各自拉回部分相關的物料，則可以很大程度緩解召回的頭部問題。

    所以我感覺，這種興趣拆分，在召回階段是很合適的，可以定向解決它面臨的一些實際問題。對於排序環節，是否有必要把用戶興趣拆分成多個，我倒覺得必要性不是太大，很難直觀感受這樣做背後發生作用的機理是怎樣的。

    我能想到的，在排序環節使用多興趣 Embedding 能發生作用的地方，好像有一個：因爲我們在計算 user 對某個 item 是否感興趣的時候，對於用戶行爲序列物品，往往計算目標 item 和行爲序列物品的 Attention 是有幫助的，因爲用戶興趣是多樣的，物品 Item 的類型歸屬往往是唯一的，所以行爲序列裏面只有一部分物品和當前要判斷的 Item 是類型相關的，這會對判斷有作用，其它的無關物品其實沒啥用，於是 Attention 就是必要的，可以減少那些無關物品對當前物品判斷的影響。

    而當行爲序列物品太多的時候，我們知道，Atttention 計算是非常耗時的操作，如果我們把這種 Attention 計算，放到聚類完的幾個興趣 embedding 維度計算，無疑能極大提升訓練和預測的速度。貌似這個優點還是成立的。

典型工作

知識圖譜融合召回

    推薦系統中**，最核心的數據是用戶對物品的行爲數據，因爲這直接表明了用戶興趣所在**。如上圖所示，如果把用戶放在一側，物品放在另一側，若用戶對某物品有行爲產生，則建立一條邊，這樣就構建了用戶 - 物品交互的二部圖。其實，有另外一種隱藏在冰山之下的數據，那就是物品之間是有一些知識聯繫存在的，就是我們常說的知識圖譜，而這類數據是可以考慮用來增強推薦效果的，尤其是對於用戶行爲數據稀疏的場景，或者冷啓動場景。以上圖例子說明，用戶點擊過電影 “泰坦尼克號”，這是用戶行爲數據，我們知道，電影“泰坦尼克號” 的主演是萊昂納多，於是可以推薦其它由萊昂納多主演的電影給這個用戶。後面這幾步操作，利用的是電影領域的知識圖譜數據，通過知識圖譜中的 “電影 1—> 主演—>電影 2”的圖路徑給出的推薦結果。

    用於做推薦，一般有兩大類知識圖譜融合模式：知識圖譜 Embedding 模式（KGE）及圖路徑模式。知識圖譜 Embedding 模式首先根據 TransE 等對知識圖譜進行 Embedding 化編碼的工具，將節點和邊轉換成 Embedding 表徵方式。然後根據用戶行爲過的物品，以及物品在知識圖譜中的 Embedding 和知識圖譜中其它知識 embedding 的距離，來擴展物品的信息含量，或者擴充用戶行爲數據，類似用已知的用戶行爲數據，在知識圖譜輔助下進行外擴。

    知識圖譜的 Embedding 模式在可解釋性方面比較弱，因爲知識之間的關聯是通過 Embedding 計算出來的，不好解釋爲什麼從這個知識跳到那個知識；而圖路徑模式則是根據物品屬性之間的關聯等人工定義好的所謂 Meta-Path，也就是人工定義的知識圖譜中知識的關聯和傳播模式，通過中間屬性來對知識傳播進行路徑搭建，具體例子就是上面說的 “電影 1 主演電影 2”，這就是人事先定義好的 Meta-Path，也就是人把自己的經驗寫成規則，來利用知識圖譜裏的數據。圖路徑模式在可解釋性方面效果較好，因爲是人工定義的傳播路徑，所以非常好理解知識傳播關係，但是往往實際應用效果並不好。

    知識圖譜是一種信息拓展的模式，很明顯，對知識進行近距離的拓展，這可能會帶來信息補充作用，但是如果拓展的比較遠，或者拓展不當，反而可能會引入噪音，這個道理好理解。所以，我的感覺是，知識圖譜在排序側並不是特別好用，如果想用的化，比較適合用戶行爲數據非常稀疏以及用戶冷啓動的場景，也就是說如果用戶數據太少，需要拓展，可以考慮使用它。

    另外，知識圖譜還有一個普適性的問題，完全通用的知識圖譜在特定場景下是否好用，對此我是有疑問的，而專業性的知識圖譜，還有一個如何構建以及構建成本問題；而且很多時候，所謂的知識傳播，是可以通過添加屬性特徵來解決的，比如：電影 1—> 主演—> 電影 2 這種知識傳播路徑，完全可以通過把主演作爲電影這個實體的屬性特徵加入常規排序模型，來達到類似知識近距離傳播的目的，所以感覺也不是很有必要在排序側專門去做知識圖譜拓展這種事情。

    這種知識拓展，可能比較適合用在召回階段，因爲對於傳統觀點的召回來說，精準並不是最重要的目標，找出和用戶興趣有一定程度相關性但是又具備泛化性能的物品是召回側的重點，所以可能知識圖譜的模式更適合將知識圖譜放在召回側。

    當然，知識圖譜有一個獨有的優勢和價值，那就是對於推薦結果的可解釋性；比如推薦給用戶某個物品，可以在知識圖譜裏通過物品的關鍵關聯路徑給出合理解釋，這對於推薦結果的解釋性來說是很好的，因爲知識圖譜說到底是人編碼出來讓自己容易理解的一套知識體系，所以人非常容易理解其間的關係。但是，在推薦領域目前的工作中，知識圖譜的可解釋性往往是和圖路徑方法關聯在一起的，而 Path 類方法，很多實驗證明了，在排序角度來看，是效果最差的一類方法。所以，我覺得，應該把知識圖譜的可解釋性優勢從具體方法中獨立出來，專門用它來做推薦結果的可解釋性，這樣就能獨立發揮它自身的優勢；

    至於如何利用知識圖譜做召回，其實很直觀，比如可以採取如下的無監督學習版本：例如，推薦系統裏對用戶感興趣的實體比如某個或者某些明星，往往是個單獨的召回路，而可以根據用戶的興趣實體，通過知識圖譜的實體 Embedding 化表達後（或者直接在知識圖譜節點上外擴），通過知識外擴或者可以根據 Embedding 相似性，拓展出相關實體。形成另外一路相關性弱，但是泛化能力強的 Knowledge 融合召回路。

典型工作

  1. KGAT: Knowledge Graph Attention Network for Recommendation

  2. RippleNet: Propagating User Preferences on the Knowledge Graph for Recommender Systems

圖神經網絡模型召回

    嚴格來說，知識圖譜其實是圖神經網絡的一個比較特殊的具體實例，但是，知識圖譜因爲編碼的是靜態知識，而不是用戶比較直接的行爲數據，和具體應用距離比較遠，這可能是導致兩者在推薦領域表現差異的主要原因。圖神經網絡中的圖結構，可以是上面介紹知識圖譜時候說過的 “用戶 - 物品” 二部圖，也可以是我們常見的有向圖或者無向圖，圖中的節點是各種不同類型的物品及用戶，邊往往是通過用戶行爲建立起來的，可以是具體用戶的具體行爲，也可以是所有用戶的羣體統計行爲，比如物品 1—> 物品 2 可以有邊，邊還可以帶上權重，如果越多的用戶對物品 1 進行行爲後對物品 2 進行行爲，則這條邊的權重越大。而且對於用戶或者物品來說，其屬性也可以體現在圖中，比如對於一個微博，它的文本內容、圖片內容、發佈者等等屬性都可以引入到圖中，比如掛接到物品上，或者建立獨立的節點也是可以的，這取決於具體的做法。

    圖神經網絡的最終目的是要通過一定技術手段，獲得圖中節點的 embedding 編碼。最常用的 embedding 聚合工具是 CNN，對於某個圖節點來說，它的輸入可以有兩類信息，一類是自身的屬性信息，比如上面舉的微博的例子；另外一類是圖結構信息，就是和當前節點有直接邊關聯的其它節點信息。通過 CNN，可以對兩類信息進行編碼和聚合，形成圖節點的 embedding。通過 CNN 等信息聚合器，在圖節點上進行計算，並反覆迭代更新圖節點的 embedding，就能夠最終獲得可靠的圖節點 embedding 信息，而這種迭代過程，其實體現的是遠距離的節點將信息逐步通過圖結構傳遞信息的過程，所以圖結構是可以進行知識傳遞和補充的。

    我們可以進一步思考下，圖節點因爲可以帶有屬性信息，比如物品的 Content 信息，所以明顯這對於解決物品側的冷啓動問題有幫助；而因爲它也允許知識在圖中遠距離進行傳遞，所以比如對於用戶行爲比較少的場景，可以形成知識傳遞和補充，這說明它也比較適合用於數據稀疏的推薦場景**；另外一面，圖中的邊往往是通過用戶行爲構建的，而用戶行爲，在統計層面來看，本質上是一種協同信息**，比如我們常說的 “A 物品協同 B 物品”，本質上就是說很多用戶行爲了物品 A 後，大概率會去對物品 B 進行行爲；所以圖具備的一個很好的優勢是：它比較便於把協同信息、用戶行爲信息、內容屬性信息等各種異質信息在一個統一的框架裏進行融合，並統一表徵爲 embedding 的形式，這是它獨有的一個優勢，做起來比較自然。另外的一個特有優勢，就是信息在圖中的傳播性，所以對於推薦的冷啓動以及數據稀疏場景應該特別有用。

    因爲圖神經網絡，最終獲得的往往是圖中節點的 embedding，這個 embedding，就像我們上面說的，其實融合了各種異質信息。所以它是特別適合用來做召回的，比如拿到圖網絡中用戶的 embedding 和物品 embedding，可以直接用來做向量召回。當然，物品和用戶的 embedding 也可以作爲特徵，引入排序模型中，這都是比較自然的。有些推薦場景也可以直接根據 embedding 計算 user to user/item to item 的推薦結果，比如看了又看這種推薦場景。

    早期的圖神經網絡做推薦，因爲需要全局信息，所以計算速度是個問題，往往圖規模都非常小，不具備實戰價值。而 GraphSAGE 則通過一些手段比如從臨近節點進行採樣等減少計算規模，加快計算速度，很多後期改進計算效率的方法都是從這個工作衍生的；而 PinSage 在 GraphSAGE 基礎上（這是同一撥人做的），進一步採取大規模分佈式計算，拓展了圖計算的實用性，可以計算 Pinterest 的 30 億規模節點、180 億規模邊的巨型圖，併產生了較好的落地效果。所以這兩個工作可以重點借鑑一下。

總體而言，圖模型召回，是個很有前景的值得探索的方向。

典型工作

參考資料

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s?__biz=Mzg4MzU1NjQ2Mw==&mid=2247500095&idx=1&sn=ce049db369df51cdf12cf265e7ae200e&chksm=cf47283ff830a129d51b31cf21a67dd2bd0b990c4b20bb1f0874b8a3f991a8b8f5b7ba5407b2&scene=21#wechat_redirect

猜你喜歡