導讀：本文主要介紹了百度搜索廣告系統 ( 鳳巢 ) 的新一代多目標召回系統架構，相比于經典召回排序兩段架構，能在保證召回相關性的同時引入諸如CPM等排序層的優化目標，從而提升整體系統的效率。

01

創新點

1. 在召回層保證相關性的同時引入了CPM等業務指標作為召回的依據。

2. 將以往的CTR預估模型融合到召回層中，提出一種全新的多目標商業召回系統架構。

02

論文背景

在大部分公司的商業廣告系統架構中，都會采用經典的“漏斗”結構，即召回——粗排——精排——重排序等模塊，在現有的召回模塊中，應該首先保證召回內容的相關性，保證用戶的搜索query和候選廣告之間的匹配程度，最為基礎的召回鏈路就是要保證召回層的相關性，但是相關性高的廣告并不一定具有很高的商業價值，所以開始嘗試將一些商業化業務指標作為召回的依據，比如CPM ( 可以理解為變現能力 )。但是如果單純的依靠CPM來進行召回的話又無法保證召回的準確性，會出現大量的badcase，即“所答非所問”，這種情況對于用戶的體驗來說是非常不友好的，所以召回層基本都是在保證相關性的大前提下盡量的篩選出一些變現能力較強的候選廣告進入排序階段。

那么如何能夠保證盡量篩選出變現能力比較強的廣告呢，一般CPM=PCTR廣告主出價*1000，假設廣告主出價不變的情況下，我們可以認為PCTR越高的廣告他的變現能力是越強的。所以一個很直觀的方法就是在召回階段利用CTR模型來對候選廣告進行預測得到其PCTR值，從而作為召回的依據，而鳳巢最新一代召回系統的核心思想就是上述提到的將CTR模型遷移到召回階段。當然這其中需要解決很多的問題，不是直接套用CTR模型就可以的。所以接下來將會介紹鳳巢是如何將CTR模型遷移到召回層的。

03

系統架構

整個“莫比烏斯”召回系統架構如下圖所示：

“莫比烏斯”召回系統架構

訓練流程如下圖：

模型訓練流程

整個系統其實分為兩個核心的模塊：數據增強模塊、模型訓練模塊。論文中對整個系統的介紹還是比較清晰的，數據增強模塊主要是用戶生成模型所需的訓練樣本，生成的訓練樣本需要能夠針對“低相關性高點擊率”的badcase有所區分；模型訓練模塊主要就是介紹模型是如何利用生成的樣本數據進行迭代更新的。

1. 數據增強模塊

在傳統的CTR模型中，模型只需要根據用戶的搜索query為其找到最有可能點擊的廣告即可，所以可能出現序非常靠前的廣告和搜索qeury的相關性不高的badcase，同時CTR模型訓練所需的日志數據相對于召回層需要處理的數據量級是非常有限的，而且召回層可能需要面對更多的長尾稀疏的query和廣告，所以為了解決上述的一系列問題，文章提出了一種基于active- learning的“teacher-student”模型訓練框架。

從上面的訓練流程圖可以大致歸結為如下幾步：

（1）首先從點擊日志中加載一個batch的數據

（2）利用這一個batch的數據構建兩個集合，即query集合和廣告集合

（3）對構建好的query集合和廣告集合兩兩配對，構建augmented data，即query集合大小為N，廣告集合大小為M，則生成的樣本集合大小為N*M

（4）利用傳統的召回階段的相關性模型對每一個query-ad的pair進行相關性打分，篩選出其中相關性比較低的的pair

（5）利用CTR預估模型 ( T-2 ) 對相關性較低的pair進行CTR預估得到pctr

（6）利用采樣器根據PCTR值對這批低相關性的pair進行采樣，同時對這批數據打上對應的label——badcase，得到增強的樣本數據

（7）將增強的樣本數據補充到CTR模型的訓練樣本中，并且單獨設計一個類別badcase，也就是將傳統的CTR模型的二分類任務擴展到了三分類任務

其實整個流程在論文中描述的還是比較清晰的，值得注意的是召回階段需要處理的數據相較于排序階段來說是更大規模而且更加稀疏的，點擊訓練日志中中的數據是十分有限的，所以文章利用query集合和ad集合兩兩配對的方式來進一步豐富樣本的規模以及對長尾流量的覆蓋；同時為了解決直接利用CTR模型進行召回而引入badcase的問題 ( 低相關性高點擊率 )，需要利用到相關性召回模型 ( teacher ) 來“教”會CTR模型 ( student ) 哪些樣本是badcase，所以這里首先利用相關性模型對構造的query-ad pair進行相關性打分，并從中篩選出來相關性較低的樣本交給CTR模型進行預測，根據預測的PCTR值從中選出低相關性高PCTR的樣本作為badcase ( 這類樣本在原始CTR樣本中是不存在的，是為了讓CTR模型學會哪些是badcase而構建出來的，原始的CTR模型是不需要關注相關性的，只需要關注CTR )。

2. 模型訓練模塊

整個模型的結構是比較經典的雙塔模型，利用用戶側的特征構建用戶queyr的embedding向量，利用廣告側的特征構建廣告的embedding向量，文中提到每個embedding’向量的維度是96維，每一側將96維的embedding分為三組vector，每組32維，分別對兩側的同一組vector計算inner product得到三個分數，然后經過softmax layer得到最終預測label ( click、unclick、badcase )，整個模型還是比較清晰易懂的。

04

線上廣告召回

線上檢索

在線上進行廣告檢索召回的時候，當收到一個用戶請求 ( query ) 時，線上計算可以得到用戶的query embedding，利用query embedding需要在保證相關性的前提下篩選出變現能力最高的一批候選廣告，這時就需要利用query embedding去進行檢索，暴力的全庫檢索基本是不可實現的 ( 線上計算開銷太大，根本無法滿足耗時的要求 )，所以比較常用的是近似最近鄰 ( ANN ) 檢索 ( 開源庫比較多，例如ANNOY，FAISS，HNSW等 )，ANN檢索通常是根據余弦相似度來進行計算的，在ANN檢索之后對檢索的結果進行相應商業指標權重來進行重排序得到檢索結果。除此之外文章還提到了最大內積檢索 ( MIPS )，上述提到的檢索方式是先檢索再根據業務指標排序，MIPS則是將業務指標改寫進了相似度計算的公式中，也就是在檢索的過程中是考慮了商業指標的，具體計算公式如下：

另外文章還提到考慮到磁盤以及內存的開銷，文章對高維的浮點數embedding向量進行了壓縮的處理。

05

實驗效果

具體離線實驗效果可以參考原文：

實驗效果

目前“莫比烏斯”已經部署到PC端百度搜索以及移動端百度APP上，從線上一周的監控指標來看，CPM漲幅還是非常大的，可以說效果還是比較明顯的。

線上實驗效果

06

結論

傳統的廣告召回都是需要首先保證相關性，但是這就犧牲了一部分的變現能力，畢竟廣告平臺是需要盈利的，而如果要在召回階段盡可能的提升變現能力的話，就很有可能引入一些badcase，如何在保證相關性的大前提下，盡可能的提升候選廣告的變現能力是非常有必要的。畢竟如果變現能力高的廣告未出現在召回的結果中，就算排序階段再怎么努力也不可能大幅提升平臺的收入，因此召回的結果對后續的排序以及最終的收入影響是非常大的。鳳巢提出的新一代召回系統線上的效果還是非常不錯的，在保證相關性的前提下又在一定程度上提升了候選廣告集的變現能力，給我們提供了一種新的思路。

原文鏈接：

https://zhuanlan.zhihu.com/p/146210155

參考資料：

MOBIUS: Towards the Next Generation of Query-Ad Matching in Baidu’s Sponsored Search

總結

以上是生活随笔為你收集整理的MOBIUS：百度凤巢新一代广告召回系统的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。