KDD2020 | 揭秘Facebook搜尋中的語義檢索技術

夕小瑤發表於2020-08-06

導讀:今天分享一下 Facebook 發表在 KDD2020 的一篇關於社交網路搜尋中的 embedding 檢索問題的工作,乾貨很多,推薦一讀。

KDD2020 | 揭秘Facebook搜尋中的語義檢索技術

論文題目
Embedding-based Retrieval in Facebook Search
論文連結
https://arxiv.org/abs/2006.11632

Arxiv訪問慢的小夥伴也可以在【夕小瑤的賣萌屋】訂閱號後臺回覆關鍵詞【0731】下載論文PDF~


相對於傳統的網頁搜尋,社交網路中的搜尋問題不僅需要關注輸入 query 的資訊,還需要考慮使用者的上下文資訊,在 Facebook 搜尋場景中使用者的社交圖網路便是這種上下文資訊中非常重要的一部分。

怎麼把各式各樣的資訊進行融合呢?

雖然語義檢索技術(Embedding-based Retrieval,EBR)在傳統的搜尋引擎中得到了廣泛應用,但是 Facebook 搜尋之前主要還是使用布林匹配模型,本文就來談談如何將 Embedding 檢索技術應用在 Facebook 搜尋場景中。

文中共介紹了三方面的經驗:

  1. 提出了一套統一的 embedding 框架用於建模個性化搜尋中的語義
  2. 提出了基於經典的倒排索引進行線上 embedding 檢索的系統
  3. 討論了整個個性化搜尋系統中很多端對端的最佳化技巧,例如最近鄰搜尋調參經驗、全鏈路最佳化等

最後,在Facebook 垂直搜尋場景下驗證了本文方法的有效性,線上上 A/B 實驗取得了顯著的收益。

背景

從 query 中準確計算出使用者的搜尋意圖以及準確表徵文件的語義是非常困難的。之前的搜尋演算法主要還是透過關鍵詞匹配的方式進行檢索,但是對於字面不匹配但是語義相似的 case 基於關鍵詞匹配的方法就不奏效了。而透過 embedding 可以建模句子之間的語義相似度,所以基於 embedding 的語義檢索就應運而生了。

所謂 embedding 就是將高維稀疏的 id 對映成為一個低維稠密的向量,這樣就可以在同一個向量空間中同時表示query 和候選集文件,從而進行譬如計算相似度等方面的操作。

一般來說,搜尋主要包含檢索排序兩個階段。儘管 embedding 技術可以同時被應用在兩個階段,但相對來說應用在召回階段可以發揮出更大的作用。簡單來說,EBR 就是用 embedding 來表示 query 和 doc,然後將檢索問題轉化為一個在 Embedding 空間的最近鄰搜尋的問題。它要解決的問題是如何從千萬個候選集中找到最相關的 topK 個,難點有如下的兩個:一方面是如何構建千萬級別的超大規模索引以及如何線上上進行服務;另一方面是如何在召回階段同時考慮語義資訊和關鍵詞匹配資訊。

本文從三個方面詳細講述了在 Facebook 搜尋中應用 Embedding 檢索技術遇到的挑戰:

  • modeling: 本文提出了一套統一的 Embedding 模型框架 ,也就是經典的雙塔結構,一側是抽取使用者側 query 特徵;另一側則是抽取 document 側的特徵。
  • serving: 為了最佳化系統檢索和排序的綜合效果,Facebook 提出了將 EBR 的 embedding 作為特徵整合進 ranking 模型中,以及建立了一套資料反饋機制,以便更好地識別和利用 EBR 的召回結果。
  • full-stack optimization: 針對實際的搜尋效果最佳化提出了多個實用的 tricks。
KDD2020 | 揭秘Facebook搜尋中的語義檢索技術

系統建模

本文將搜尋引擎中的檢索任務建模為一個召回最佳化問題。從離線指標的角度,我們希望最大化 topK 返回結果的recall 指標。給定一個 query,以及期望被檢索到的目標文件集合 T,T 中包含的文件可以來自使用者的點選資料,也可以是經過人工篩選排序後的文件,我們的最佳化目標則是 recall@K

KDD2020 | 揭秘Facebook搜尋中的語義檢索技術

繼而我們把召回最佳化問題建模成 query 和 doc 之間基於距離的排序問題,把 query 和 doc 同時表示成低維稠密的向量,透過計算向量空間中的距離衡量它們之間的相似度或相關度,本文中我們採用 cosine 距離。

但是在 Facebook 個性化檢索場景下,僅僅計算 query 本身與候選文件的相似性是遠遠不夠的,我們同時要考慮使用者的上下文資訊,比如他關注的人,他的關注話題等等,才能幫使用者找到他真實的最想要的結果。為了實現這個目標,本文提出了統一嵌入模型,即Unified Embedding Model

Unified Embedding Model的思路相對來說比較簡單,沿用了經典的雙塔結構,包括三個部分:query encoder,document encoder 以及 similarity function。兩個encoder是互相獨立的,也可以共享一部分網路引數,左邊是 user 的塔;右邊是 document 的塔,但是 Unified Embedding Model 的  encoder 的輸入是和傳統的輸入不同的,user 塔的輸入包括使用者的檢索 query,以及使用者位置使用者社交關係等上下文特徵,document 塔的輸入包括文件本身,以及文件的 group 資訊等上下文特徵,模型結構詳見下圖所示。其中大部分的特徵都是類別型特徵,進行 one-hot 或者 multi-hot 的向量化;連續型特徵則是直接輸入到各自的塔中。

KDD2020 | 揭秘Facebook搜尋中的語義檢索技術

在模型訓練的損失函式上,本文定義了一個三元組損失函式,使得負例比正例相對 query 的距離儘可能的遠。在使用三元組損失函式的情況下,使用隨機取樣的負樣本可以近似求解召回最佳化問題。

KDD2020 | 揭秘Facebook搜尋中的語義檢索技術

對於訓練 embedding 語義召回模型來說,如何定義正負樣本對於模型的效果至關重要。點選樣本作為正樣本這個沒有疑問,針對負樣本我們採用了如下的兩種的策略進行試驗。

  • 隨機負樣本:隨機從文件庫中取樣 document 作為負樣本;

  • 曝光但未點選樣本:隨機取樣在同一個 session 中曝光但未點選的樣本作為負樣本;

本文發現前者作為負樣本的效果要明顯好於後者,原因是前者可以有效消除負樣本偏差。另外,本文還進行了一組把曝光但是未點選的樣本作為正樣本的實驗,實驗結果表明並沒有帶來額外的收益。

特徵工程

Unified Embedding Model 架構的一個最明顯的優勢是可以任意加入各種各樣的上下文特徵。我們都知道 Facebook 推出的工業界實戰論文都比較注重特徵工程,Unified Embedding 大體上採用了如下三個方面的特徵

  • Text features

Text Embedding 採用 char n-gram,相對於 word n-gram 有兩方面的優勢,一是有限的詞典,char embedding table 會比較小,訓練更高效;二是不會有 OOV 問題,subword 可以有效解決拼寫錯誤以及單詞的多種變體引入的 OOV 問題。

  • Location features

位置特徵對於搜尋引擎的很多場景是非常重要的,因此本文在 query 和 document 側的都加入了 location 的特徵。

  • Social Embedding features

為了有效利用 Facebook 社交網路中的豐富資訊,本文額外地訓練了一個社交網路的 Graph Embedding,然後將這個預訓練的 Embedding 作為特徵輸入到模型當中。

KDD2020 | 揭秘Facebook搜尋中的語義檢索技術

線上Serving

前面的章節講如何進行離線建模以及特徵工程,這一節主要講如何進行線上實時檢索,Facebook 採用了自家的 Faiss 庫進行線上近似最近鄰搜尋(approximate nearest neighbor search, ANN)。具體地,他們在實際系統中部署了一套基於倒排索引的 ANN 搜尋演算法,首先,利用自家的 Faiss 庫建立向量索引,然後對索引表進行高效的最近鄰檢索。對 embedding 進行量化可以有效節省儲存開銷,同時可以方便地整合到現有的檢索系統當中。

一個 query 可以表示為基於 term 的布林表示式,譬如 john 和 smithe 住在 seattle 或者 menlo_park 可以用下面的布林表示式來表示。在實際使用中,在 document 的布林表示基礎上,加上了 document embedding 的索引。

KDD2020 | 揭秘Facebook搜尋中的語義檢索技術

Embedding model 離線訓練完成後透過 spark 構建候選文件集 document 的索引,當使用者請求過來時,query 的 embedding 線上計算,進行 topK 召回。針對全量的候選文件集進行索引是非常耗儲存和費時的,所以本文在構建索引的時候,只選擇了月活使用者,近期事件,熱門的事件,以及熱門 group。大部分公司在構建索引的時候也都會採取這樣的策略,很多長時間不活躍的可以不構建索引。

Full-stack最佳化

Facebook 的搜尋引擎可以看作是一個複雜的多階段的排序系統,檢索是排序之前的流程,檢索得到的結果需要經過排序層的過濾和 ranking,我們可以將檢索過程召回的分數(也就是向量的相似度)作為 ranking 階段的一個特徵,透過 ranking 模型進行統一排序。由於現有的排序演算法是基於已有的檢索演算法的特點設計的,所以對於基於 embedding 召回的結果自然是被次優處理的,為了解決這個問題,作者提出了兩個方法:

  • Embedding as ranking feature: 將檢索這一步驟得到的 embedding similarity 作為接下來排序的輸入特徵,實驗證明餘弦相似度的效果要優於其他相似度特徵。

  • Training data feedback loop: 基於 embedding 的語義召回的結果存在召回高但是精度低的問題,所以本文就採用了對召回結果進行人工標註的方法,對每個query召回的結果進行標註,區分相關結果和不相關結果,然後用標註後的資料重新訓練模型,從而提升模型精度。(人工大法好)

基於 embedding 的語義召回模型需要更加深入的分析才能不斷提升效能,Facebook 給出了其中可以提升的重要方向一個是 Hard Mining,另一個是 Embedding Ensemble。具體地有以下幾個方法:

Hard Negative Mining 文章發現很多時候同語義召回的結果,大部分都是相似的,而且沒有區分度,最相似的結果往往還排不到前面,這些就是之前的訓練樣本太簡單了,導致模型學習的不夠充分。所以本文把那些和 positive sample 很近的樣本作為負樣本去訓練,這樣模型就能學到這種困難樣本的區分資訊。

Online hard negative mining 模型是採用mini-batch的方式進行引數更新的,對batch中每個positive pair (q_i, d_i),利用除 d_i 以外的其他正例文件組成一個文件集,從中選擇最相近的文件作為困難負例 hard negative sample,透過這種方式構造的三元組資料 可以使模型效果提升非常明顯,同時也注意到了每個 positive pair,最多隻能有兩個 hard negative sample,不然模型的效果會下降。

Offline hard negative mining 首先針對每個 query 召回 topK 個結果;然後選擇一些 hard negative samples 進行重新訓練,重複整個過程。同時根據經驗負例樣本的比例是 easy : hard=100:1。

Hard positive mining 模型採用了使用者點選的樣本為正樣本,這一部分樣本是現有系統已經可以召回的相對簡單樣本,但是還有一些使用者未點選但是也能被認為是正樣本的樣本。作者從使用者日誌中挖掘出潛在的困難正樣本(具體如何挖掘文章沒有提及),發現訓練資料量只有原來 4% 的情況下可以得到和原來相近的召回率,如果把這些困難正例和使用者點選資料一起訓練說不定有更好的效果。

Embedding Ensemble 簡單樣本和困難樣本對訓練 EBR 模型都很重要,簡單樣本可以讓模型快速學習到資料分佈特點,困難樣本可以提升模型的 precision,所以採用不同難度的正負樣本訓練出來的模型各有優勢,如何對這些模型進行融合以提升效能呢?第一種方案是 Weighted Concatenation,透過對不同模型計算的相似度 score 進行加權平均作為最終相似度值,採用加權融合的模型對於單模型而言有 4.39% 的提升。第二種方案是 Cascade Mode,模型以序列方式在第一階段模型的輸出上執行第二階段模型。採用序列的方式,模型也有 3.4% 的提升。

總得來說,這是一篇濃濃工業風的文章,雖然沒有特別fancy的方法,但是系統級的最佳化方案上很值得大家學習。

相關文章