導讀： 關鍵詞匹配位於整個搜索廣告系統的上游，負責將query和keyword按照廣告主要求的匹配模式連接起來。該問題面臨着語義鴻溝，匹配模式判定和可擴展性方面的挑戰。在本文，我們會就同義變換這個主題展開討論，講述如何用數據驅動的方式做同義變換，如何將知識推理融入到變換中，以及如何用這些技術解決匹配問題中的核心挑戰。
01 背景介紹
1. 搜索廣告
搜索廣告中有三個角色，分別是用戶、廣告主、搜索引擎。
- 廣告主側會向引擎提供物料，同時競價關鍵詞。比如一個做雙眼皮的美容機構，會買例如“雙眼皮手術多少錢”、“雙眼皮手術的價格”、“雙眼皮手術哪家好”等關鍵詞。這些關鍵詞會被提交到搜索引擎。需要指出的是，這裏說的關鍵詞不是我們通常所說的關鍵詞，而是指廣告主購買的query。
- 用戶側會提交query，比如“雙眼皮手術多少錢？”。
- 搜索引擎在收到query之後，會對query和關鍵詞進行匹配，把廣告主的廣告創意拉取出來，綜合考慮 ( bid, quality, ctr ) 等因素選取有限的廣告進行下一輪的拍賣，最終勝出的廣告會被展示出來。
2. 廣告主的競價語言：匹配模式
和其他廣告不一樣的是，搜索廣告會提供特定的競價語言，即匹配模式。廣告主可以控制這些關鍵詞對應的匹配模式來控制競價的精準度。主流的搜索引擎一般提供三種匹配模式：精確匹配、短語匹配和智能匹配；其定義如圖所示。一般的，這三種匹配模式，從上到下，觸達範圍由窄到寬，精準度也從高到底，相應的，出價也會從高到低。
舉一個例子，如果廣告主購買的關鍵詞是“雙眼皮手術的價格”，並且指定其匹配模式是精確匹配的話，當query是“雙眼皮手術多少錢？”時，廣告主的關鍵詞會被匹配到，而“雙眼皮手術疼嗎”則不會被匹配到。
3. 廣告主的賬戶結構
再舉廣告主的賬戶結構的例子給大家看一下，廣告主會投放若干計劃，在計劃下有多個投放單元，在投放單元中，有關鍵詞、出價和匹配模式，在單元下廣告主會提交若干創意。可以看到關鍵詞是處於整個樹形賬戶結構的底部， 我們匹配的工作會從這個賬戶底部開始進行，包括索引和匹配。
4. 搜索廣告系統概覽
在搜索廣告系統中，廣告的觸發分三步走：
- 第一步是進行“關鍵詞匹配”，目標是爲每個匹配模式召回儘可能多的關鍵詞。
- 第二步是在關鍵詞匹配成功後獲取廣告內容，確定廣告對應的廣告主、出價和廣告創意。
- 第三步是廣告排序階段，基於匹配質量，出價和點擊率等因素，選擇有限的廣告進入拍賣，最後勝出的廣告被展現出來。
5. 關鍵詞匹配問題
本次分享的重點是“關鍵詞匹配問題”，抽象來說，這個問題的輸入是query、匹配模式、關鍵詞庫，輸出是滿足匹配模式的全部關鍵詞，限制是匹配模式。例如輸入是“雙眼皮手術多少錢”，在精確匹配模式下，產生的典型目標召回關鍵詞是“雙眼皮手術的價格”、“雙眼皮手術多少錢”、“割一個雙眼皮花多少錢”等。
6. 問題挑戰
關鍵詞匹配問題的挑戰有：
Semantic Gap： 用戶和廣告主用不同的方式來表達同樣的意圖。例如“雙眼皮手術的價格”和“雙眼皮手術多錢？”是同一個意思，但是他們會用不同的字面來表達。這也是NLP中一個基礎又很重要的問題。
匹配模式的判定： 是搜索引擎廣告面臨的獨特問題，用來判定是精確、短語還是智能匹配。這是產品的根基，由產品對廣告主的契約保障。
工程性能： 可擴展性，由於query和關鍵詞的量都非常大， 無論在線還是離線，計算資源都非常有限，這給很多功能實現帶來了挑戰。
02 同義變換的應用場景
同義變換的應用場景主要有：
1. 同義匹配
首先是產品定義的同義匹配問題，在剛剛提到的三個匹配模式中精確匹配和短語匹配與其是直接相關的。一般情況下，一個query可以有無數個同義變體。例如一個query是“雙眼皮手術多少錢”，簡單的變體是“雙眼皮手術多少錢呢？”，一個更爲複雜的變體是“拉一個雙眼皮大概需要多錢？”。如果在一個開放域中變換的話，一個query可能有無窮無盡種同義的變體，而我們主要關心的是在封閉集合上的變換能力，即將query同義變換爲bidword集合中的某一個。
2. Keyword端
隊列壓縮：
另外一個應用場景是在Keyword端，在關鍵詞匹配中，給定一個query，我們通常會觸發得到大量的候選關鍵詞，這些候選爲了保證質量，都需要經過模型校驗計算來確認。我們的思路是基於同義關係壓縮的方法減少計算候選。在上圖的例子中，一個query觸發4個關鍵詞候選，通過離線計算A1和A2是同義，B1和B2是同義，那麼線上只需要校驗A1和B2，當A1通過校驗後再擴展回去。這樣可以極大地減少判別模型的計算壓力。
基於代表元來觸發：
更爲激進一點，我們可以用基於代表元來觸發。通過對原始詞庫進行同義壓縮，例如對A1，A2和B1，B2進行同義壓縮成A1和B1，可以降低keyword端的量，只需針對A1和B1進行觸發。在線上使用中，我們採用基於代表元來觸發，然後再擴展回原始詞庫。
3. Query端：規範化+改寫
在query端，我們可以進行規範化和改寫。一般的搜索廣告都會針對高頻query做離線的充分計算放到一個高頻詞表。當query來了之後，先去查表來看是否有結果命中。我們可以針對高頻KV詞表中的key做同義規約變換，從而提升key的命中率。KV詞表中，K就是關鍵詞，V就是觸發的結果。例如Q1原來的觸發結果是A、B、C；Q2的觸發結果是D和E，在同義規約後，Q1和Q2的觸發結果是A，B，C，D，E。相對於原來Q1只命中A，B，C而言，規約之後提升了命中率，同時整個詞表只需存儲規約${\hat Q}_1$和${\hat Q}_3$來減少key的量級。
03 如何做同義匹配？
—— 以精確匹配場景爲例 ——
同義匹配的方案：
在同義匹配中，以精確匹配場景爲例，首先可以從規則出發，進行短語粒度的同義替 ( 例如雙眼皮=重瞼手術，多少錢=多錢 ) 或者進行句子級別的pair挖掘。今天分享的主要內容是通過數據驅動的模型來提高泛化。主要爲三步走：尋找同義數據源、訓練模型並基於模型來泛化。
第一步：尋找大型同義數據源
在如何選擇大型同義數據源方面，一方面可以利用系統外部數據，例如搜索點擊日誌、Session日誌、協同過濾和規則替換。另一方面可以使用系統內部數據，例如商業點擊日誌。
① 數據選擇的困惑：
在數據選擇方面會產生一些困惑，使用系統內部數據可以泛化出增量嗎？因爲使用最大似然的方式求解就是使用模型來擬合數據，例如使用翻譯模型或者圖模型，top1 decode的結果就是該數據，這個過程好像無法產生增量數據，會陷入feedback loop中。事實上可以使用系統內部數據也可以泛化出增量，因爲我們實際應用中是做1對多的decode，在圖模型中我們會近鄰檢索出不止一個候選。下面舉例來說明泛化帶來的delta。
② 泛化帶來的delta：
在上圖中，訓練樣本1的Q1是“雙眼皮手術多少錢？”，B1是“雙眼皮手術的價格”。訓練樣本2的Q2是“雙眼皮手術大概多少錢”，B2是“雙眼皮手術一般多錢？”。使用S2S模型來對樣本進行訓練，然後對Q1做Decode，由於Q1、B1是在訓練樣本1中，所以首先能夠得出B1，同時由於Q1和Q2相似度比較高，所以也能夠獲取結果B2，如果模型的泛化能力足夠強的話，說不定能得出B3。
第二步：訓練模型
在訓練模型中可以選擇S2S模型，雙塔模型 ( 即語義的度量模型 )，或者圖模型。
第三步：基於模型來泛化召回
最後是基於模型來泛化召回，使用模型的自反饋來進行泛化，以前Q1有3個召回的結果A，B，C。基於模型，定向在關鍵詞庫中做召回，有可能把A1和B1也召回出來。圖中的藍色標記都是泛化出來的結果。
04 基於S2S來泛化
1. 思路
基於S2S的泛化，建模本質就是一個翻譯模型，進行逐詞翻譯，對Query進行編碼使用embedding來作爲輸入。
2. 該建模的優缺點
該建模的優缺點：
優點：
- 採用端到端的建模，尤其是在語料充分的情況下，質量會非常好，同時簡單，只需要獲得一些正例即可。
缺點：
- 效率比較低，因爲是用翻譯的方式來做檢索的工作，逐詞生成。一個query通常有上千種同義變體的關鍵詞，純靠decode幾乎不可能完成。同時如果數據不作清洗的話，冗餘度會非常高。
- 定向翻譯，因爲翻譯本身是開放式的，不能保證decode出來的東西都是關鍵詞。
- 訓練和預測是不一致的，訓練時一對一，目標是一對多。
3. 解決效率問題：同義規約
解決效率問題，可以使用同義規約的方式來解決，直接翻譯的話，冗餘度是很高，如果query是“割雙眼皮手術多少錢”，類似的query有很多，例如多一些空格，少一些空格，多一個標點符號，多些副詞，感嘆詞等。所以我們可以對Query和Keyword空間，先都進行歸一化， 然後在規範化的空間中來做匹配。
4. 如何做規範化
具體進行規範化的步驟是，基於冗餘詞性的去除。例如副詞、標點符號的處理；還可以採用同義模型來進行校驗；更進一步的是做bag of words的處理。其效果是可以極大的壓縮訓練數據、減少冗餘翻譯、相同的時間內生成更多的同義候選。
5. 解決效率問題：同義擴展
還需要解決的一個問題是同義擴展，因爲NMT很慢，增大beamsize來擴大召回量是不現實的。可以採用基於同義關係來擴大召回量。
6. 更好的泛化：基於概念來泛化
我們知道，數據驅動有自己的硬傷：那就沒有數據就驅動不了。我們的模型最後往往只學到了數據上的共現，卻缺乏概念抽象的推理功能。例如對於樣本“北京雙眼皮手術的價格=在北京做個雙眼皮手術大概多少錢？”直接訓練DNN模型，我們很難泛化出這樣的case：烏魯木齊修眉的價格=在烏市做個修眉大概多少錢？。而我們希望模型是有一定的能力來抽象知識並做推理泛化的。
一些解決的思路：
解決的思路有UNK問題，使用copyNet和pointerNet。還可以做一些概念實體識別的事情如下圖所示：
我們首先把原始的數據先轉換到概念空間中去，然後在概念空間中做泛化，然後對泛化後的概念模板填充實體，得到最後的召回結果。
具體流程：
在線上一個query來了之後，我們先對query做標註，然後得到這個query的概念形式，和概念對應的填充值，然後我們定向對keyword概念庫來召回同義的概念形式，最後填充概念值得到最後的結果。比如query是“烏魯木齊紋眉多錢”，可以分析得到對應的概念形式是“【地名】【美容項目】多錢”，我們在關鍵詞概念庫中可以召回“在【地名】做【美容項目】需要多少錢”的概念候選，填充完實體後可以召回在【烏市】做【紋眉】需要多少錢。
05 基於度量模型來做同義泛化
1. 基於語義度量來做同義泛化
還有一種方式是基於語義度量模型來進行同義泛化，大致的意思就是把翻譯模型換成語義向量模型，檢索過程是在語義向量空間中尋找K近鄰。
2. 在度量語義空間中召回同義變體
方法的實現思路是：
- 投影到共同的語義度量空間中
- 尋找同義的query-keyword在度量空間中的近鄰
分兩步來實現：
- 投影
- 尋找k近鄰
獲得投影算子：
投影算子有很多，例如BOW、CNN、RNN或者Transformer；度量口徑可以考慮歐式距離或者餘弦相似；在數據方面，因爲最後我們會在整個全量空間中做語義檢索，和之前的翻譯模型不同，我們需要同時考慮正例和負例，並且要精心的去設置負例。
尋找近似K近鄰：
在投影模型訓練出來之後，進行K近鄰的查找。首先是基於度量對空間做劃分，在query來了之後，可以快速定位到所在分桶。在此過程中可以用層次kmeans構建樹形索引，然後query來了可以在log(N)時間內定位到分桶。
06 基於圖模型來做同義泛化
1. 匹配問題可以看做是Link Prediction問題
基於圖模型來做同義泛化也是一個很好的方案，可以把匹配問題看作link prediction問題，把query和keyword看成node，匹配模式關係看成邊。用圖來求解匹配問題，我們可以引入更多的數據，因爲平時我們使用最多的都是一些簡單的線性數據，如用戶點擊數據，其實更爲海量的數據是以圖的形式存在的，如用戶的seesion日誌和廣告的購買賬戶層級數據等等，這樣融合在一起形成一個很大的圖，我們可以把數據都融入到網中進行訓練。
2. 基於圖表示來做匹配
基於圖表示來做匹配分爲三步走：第一步是構造圖，其次是計算每個節點的低維表達，最後是爲每個階段尋找K近鄰。
3. 基於遞歸圖網絡來計算表達
圖網絡可以選擇的方案有很多，比如我們可以選擇基於遞歸圖網絡來計算表達。在遞歸圖網絡中，每一個節點的向量都是由其鄰接的節點的表達聚合而來，這樣表達的好處是節點之間多跳的鄰接關係，還有一對多的關係可以同時考慮到建模道中來。比如對E節點而言，可以通過節點B、N、F、C 聚合向量來表達，同樣的，遞歸下來，每個鄰居也可以這麼做。比如節點N可以通過節點P、M、G、E來表達。兩次傳播之後，二跳的信息G就傳到了E的節點表達中去了。
4. 總結
簡單總結而言，基於數據驅動的方式做同義變換一般是基於種子數據抽象出一個模型，通過模型來進行泛化得到delta數據。在這裏，數據是源，模型是媒介，什麼樣的數據就會有什麼樣的泛化結果。這種簡單的delta泛化方法在實際中可以很好的保持匹配模式。如果你的數據是Phrase match的，那麼泛化出來的一般也是phrase match的。但是在此過程中，因爲輸入數據的準確性和模型自身的問題， delta泛化不可能是百分百準確的，中間很有可能產生bad case。
07 同義判定
如何對bad case進行過濾，是一個同義判定的問題。
1. 匹配模式判定
在精確匹配模式中，如何判定query-keyword pair是不是同義變體關係 ( paraphrase identification ) ？
一種直觀的想法是可以基於同義詞對齊來做：這種方式的準確率高，但是召回出來的結果很少，舉個例子如“女人生孩子後腹部有贅肉怎麼辦？”，keyword是“產後如何減肚子”。那麼“女人”這個詞很難找出對應的關係出來。此時需要一個泛化能力強的模型來做這樣的事情。
例如訓練一個分類模型，輸入，label是0或1。
- Feature-driven的方式是人工特徵+少量標記數據+淺層模型；
- Data-driven方式是transformer + 弱監督預訓練+domain finetuning。
問題的難點：
這個問題的難點，一方面因爲F是一個全領域內的同義判別模型，在搜索場景中，query和keyword的量很大，而實際中只能夠拿到很少的標註數據， 這麼少的標記數據很難把方方面面的case都照顧到。另一方面，我們需要大量的知識來提升召回和準確。很多同義關係知道的話，對應的case就可以召回出來，如果不知道就完全召回不出來。此時模型需要很大的capacity來記憶和泛化全領域的知識。
2. 特徵驅動的小模型
在特徵驅動的小模型中，利用人工定義特徵：
- 詞粒度的匹配度計算，如max matching length，miss/match和bm25
- 命名實體的相似度、句法依存和文檔分類
- 語義相似性，如基於搜索點擊數據的DSSM
- 搜索檢索結果的相似度
在數據方面，需要少量的人工標記數據。模型一般是是淺層DNN和GBDT之類的樹模型。
3. 數據驅動的大模型
在數據驅動的大模型中，包括多階段預訓練finetuing，在百度使用的是ERNIE Large+弱監督數據+人工標記數據的多階段預訓練加finetuning的方式。
數據方面：
- 需要海量的弱監督數據例如用戶側的query-query，商業側的keyword-keyword和query-keyword
- 少量人工標記數據。因爲標註成本比較高，在標註數據之後，最好做一下主動學習和數據增強
訓練方面：
- 使用多階段預訓練+finetuning+對抗學習來提高魯棒性
從結果來看，其效果遠超特徵驅動的模型，因爲是大模型容量+海量的數據預訓練讓模型學到海量的同義知識，此外，Transformer的多頭注意力起到軟對齊的作用。
4. 爲標記樣本做最充分的數據增強
剛剛提到爲標記樣本做最充分的數據增強，增強技術在圖像中使用較多，在NLP中使用較少，可以基於同義變換來增強，另外可以使用概念標註來進行增強。
5. 提升魯棒性：基於對抗樣本來防禦
另外一方面，我們迫切需要提升模型的魯棒性，傳統的模型都是基於經驗風險最小化來訓練，這本身保證不了模型的魯棒性，比如模型在小擾動下預測的穩定性。例如下面的例子，在圖像分類的模型，對熊貓x進行預測的效果很好，在輸入端加入一些微弱的的白噪音擾動之後，人可以識別出來，但是模型很快就把它識別成了其他動物。
基於對抗樣本來防禦：
一種提升魯棒性的方法是基於對抗的樣本來做防禦，通常GAN是爲了提升生成模型的精準度，其實GAN也可以判別模型的效果提升，我們可以在原始樣本的基礎上，生成一些對抗樣本，最後混合起來作爲模型的輸入，以此來提升模型。對抗訓練是鞍點優化，在輸入空間做梯度上升，在參數空間做梯度下降。
6. 開放的問題
但是事情還沒有結束，在攻擊對抗訓練之後，只能保證樣本x1、x2和x3的鄰近空間有魯棒連續的結果。那麼剩餘的其他空間呢？我們知道query叉乘keyword是一個非常巨大的空間，在這麼大的空間上的其他盲區怎麼辦？這個是一個開放型的問題。之前我們使用的海量的弱監督數據其實是起到了這裏的盲區補充的作用。
08 總結
最後總結一下，本次分享的主要內容是關鍵詞匹配的大背景、同義變換的應用場景（包括同義匹配、keyword隊列壓縮、Query規範化和改寫）和如何做同義變換（包括規範化和知識推理），最後講的是如何做基於ERNIE和對抗訓練來做同義判別。
今天的分享就到這裏，謝謝大家。
作者介紹：
連義江博士，百度資深研發工程師
北京大學數學系計算數學博士，百度資深研發工程師，目前主要負責百度搜索廣告關鍵詞匹配相關的工作。
本文來自 DataFunTalk
原文鏈接：