Query 理解在美團搜索中的應用

分享嘉賓：劉亮 美團 資深算法工程師

編輯整理：吳雪松

出品社區：DataFunTalk

導讀**：**在過去的 20 年中，搜索過程中處理查詢的方式以及向用戶顯示結果的方式已完全改變。該過程已經從僅基於文本匹配的檢索發展到現階段——嘗試基於對查詢的真實語義理解以及上下文，位置，時間，用戶的先前短期和長期瀏覽活動來獲得搜索結果。本文主要介紹美團搜索場景下，查詢理解系統的一些建設和相關的工作。主要圍繞以下幾點展開：

▌Query 理解簡介

1. 美團搜索

在介紹查詢 (Query) 理解之前，我們先了解下美團搜索，左圖是美團 APP 首頁的截圖，中間是美團承接的業務，可以看出美團的業務非常多，包括了像外賣、美食、酒店住宿等大家比較熟悉的業務，也有像婚紗攝影、機票預定等相對低頻業務。頂部的搜索框，是美團搜索的主入口，美團的搜索就是通過這個搜索框來獲取用戶的查詢 Query，在理解查詢 Query 後，對接到所服務的各種各樣的業務品類，最後返回給用戶想要的結果。

美團搜索是典型的 O2O 搜索，右圖顯示了對比傳統的網頁搜索以及電商搜索的一些差異。

首先是搜索目標，美團搜索的核心是提供服務，包括團單、套餐等本地生活服務。另外也會對一些信息和商品提供查詢服務，像天氣或者醫美百科等；另外還有商品，相對於傳統電商，美團主要是本地的一些商品，包括周邊的便利店，周邊的商場中的商超類的產品，以及周邊能配送的商品的搜索。

另外一個重要的特點是基於位置的相關性比較高，因爲 O2O 主要是基於本地生活的服務形態。供給約束方面，網頁搜索基本不用考慮；電商搜索的供給是全國的商家，購買後全國配送；O2O 場景下，從蜂窩到城市到全國這些維度都有涵蓋，蜂窩是類似外賣這種業務，它的配送範圍是很有限的，大概可能 3~5 公里的範圍；像美食到餐團購類，是到店裏消費，基本是一個城市維度的；另外像酒店旅遊這種業務，它可能是全國性質的供給，所以說它涵蓋的範圍會比較廣。

以上就是美團搜索的大概介紹。

**2. QU
**

下面介紹下查詢理解系統。QU (Query Understanding)，主要利用基礎 NLP 能力，對我們的用戶輸入的 Query 進行分析，產生一系列的基礎信號，然後這些信號會應用到整個搜索鏈路的召回、排序等各個階段。

舉個例子來說的話，用戶輸入：杭州東附近的 7 天酒店，可以通過查詢的變換，糾錯和擴展，把杭州東擴展成杭州東站，擴大召回。

在往下是成分識別，這個後面也會重點介紹，包括了實體識別、實體鏈接，它可以把 Query 再進行一個成分粒度的識別，把杭州東識別成車站類的地理位置，7 天識別成一個商家品牌，通過實體鏈接可以將杭州東對應的經緯度返回，7 天鏈接到具體的品牌 ID 等。在最後是一些業務應用，包括查詢意圖的識別方面，我們還需要把它識別出它具體是本地意圖，還是異地意圖。

右圖是我們目前線上應用的搜索結果，可以看到首先它識別出杭州東這個主點，並鏈接到了杭州東站這個實體。在意圖方面，由於是在北京的搜索，但是我們需要找杭州東附近的酒店，所以會有異地的提示，最終的結果是在杭州東站座標點一定距離半徑內召回 7 天品牌酒店。

3. DQU

上圖是查詢理解 DQU 項目的架構。

公司有非常多的業務，很多業務也有自己的垂搜系統，在業務快速迭代的階段是獨立運行的，隨着業務的不斷髮展，如何避免低水平重複建設，更好的積累技術、經驗，平臺就成了很有價值的工作。目前 DQU 的項目已經支持了公司內大部分的搜索場景，包括美團點評大搜，還有度假、住宿等業務頻道內搜索。

整個框架分三個部分，最底層是基礎信號層，主要是 NLP 相關基礎信號模塊，可以提供通用和業務個性化的信號輸出。中間是業務邏輯層，適配不同的垂搜業務邏輯。最上層是適配層，對於不同的業務搜索可能有不同的接口，需要接口適配再返回最終結果。

接下來重點介紹下幾個核心的查詢理解模塊。

▌實體識別 & 實體鏈接

1. 實體識別

**① 簡介
**

首先是實體識別，對比於通用網頁搜索，電商和 O2O 搜索更多的是結構化的召回。舉個例子，上圖中間的 “如家上地”，需要把它的商家和地址身份進行識別，然後對應到我們的 Doc 端，通過不同的字段進行召回。

因爲在我們的場景下，Doc 端的數據包含了很多結構化的字段，不同字段之間的語義差距會非常大，如果我們進行全字段檢索，經常會出現一些語義漂移的問題。比如，搜 “肯德基”，可能召回一個理髮店，因爲它的地址字段有 “在肯德基對面”。所以我們需要結構化召回來保證更高的精度。其中 NER 是指導召回的關鍵信號。

② 整體架構

實體識別的整體框架，主要分兩個部分：下面的離線端和上面的在線部分。

線上的識別來源主要分兩部分，一部分是詞典的實體匹配，一部分是模型預測，然後再往上是消歧策略，實體詞典匹配，主要解決一些熱門和詞庫裏能夠匹配的詞，對一些長尾和泛化的詞識別，還是依賴於模型。但是這兩個部分中間的結果可能會有一些衝突，所以需要一個消歧策略，包括多粒度、多結果選擇。我們主要通過一些模板規則，進行優先級的消歧，最終輸出一個多路的結果，因爲某些 query 會有粒度和類別的歧義。

離線部分主要是兩個大的部分：一部分是實體挖掘，這個主要是爲線上的實體匹配提供基礎的實體庫，模型方面主要是一些基礎的模型訓練、優化相關的工作。

③ 模型迭代

接下來講一下 NER 模型迭代相關的一些工作。初期線上的模型主要是 CRF，在 19 年引入了 BERT 模型。這裏面主要是兩個方面的改進，一方面是訓練過程，引入了美團 UGC 的一些數據，用這些評論相關的數據進行預訓練，補充 O2O 場景下的一些語義信息。再就是 fine-tune 階段，我們除了人工標註語料的數據集，還有基於用戶行爲統計的半自動化生成的一些語料，來擴充訓練數據。使模型訓練效果，能夠更好的擬合線上的應用。

④ 自動標註訓練數據

這裏簡單介紹下，根據詞典擴充訓練數據的工作。

對於大規模的模型訓練，語料是非常重要的一個部分，但是對於 NLP 任務，一般來說還是比較難以去自動化的獲取這些訓練語料，我們的一個核心思路是如何利用已有的標註數據、詞典來指導內容半自動化的生成訓練語料。首先用原始的人工標註語料，訓練一個 Model A，然後針對線上已有的實體庫去預測打分，對打分有差異的部分，進行校正，然後把校正後的結果合併原始數據，再訓練一個 Model B，最終應用到線上。其中的核心就是校正的過程。

它的前提假設是，實體庫和模型的質量，都是比較高的，但是其中模型預測和詞典它中間還是有差異的部分，就是我們的模型預測相對於它可以提供更細的粒度。比如下面這個例子：“兄弟燒烤個性 diy”，它其實是一個商家的名稱，因爲有比較全的美團商家庫的信息，所以能夠通過詞典來挖掘出我們的商家信息。

但是模型預測的話，由於兄弟這個詞，有影視類的電影，可能是電影名，模型也可能會識別錯誤，所以需要根據詞典的信息進行修正。修正的方法是對模型預測的序列，進行輪巡替換，找出替換概率最高的一個，然後作爲替換類型，最終生成一條校正後的訓練數據，和原始數據進行聯合訓練。

⑤ 數據挖掘

另外一個部分就是離線詞庫的挖掘。

除了已有的商家庫和一些結構化數據以外，線上的用戶行爲，也是非常重要的，怎麼通過海量的用戶行爲數據，泛化我們的實體庫，是我們的核心工作。這部分工作主要利用我們線上的用戶點擊日誌，結合召回命中信息，來識別出 Query 的邊界和類型，把用戶 Query 中識別出的實體成分進行落庫，同步到實體庫中。

Query 中的實體邊界的切分，主要參考該 Query 召回的多個 Doc 結果的命中信息。由於我們是結構化召回，所以可能存在多個字段同時命中，通過統計所有 Doc 的命中分佈情況，來考慮它的切分方式，最終轉化成一個整數線性規劃的問題，來尋求一個切分概率最大的方式，具體可以參考文章《美團搜索中 NER 技術的探索與實踐》。有了這個切分邊界後，再對它的每一個成分進行二分類模型識別，把識別概率比較高的目標成分，進行人工抽檢，將符合要求的實體補充到實體庫中。最終，通過這樣的循環來擴充我們的實體庫。

2. 實體鏈接

① 背景

下面再介紹一下實體鏈接的一些相關工作，美團搜索場景下的 LBS 屬性，決定了很多用戶都有地址類搜索的習慣，所以地址識別也是我們的一個重點。實體識別把地址成分識別出來之後，後面很重要的工作是把它的經緯度座標找到，通過半徑距離召回，滿足用戶搜索某個地址周邊結果的訴求。這就需要實體鏈接把用戶 Query 中的文本鏈接到具體的實體，並返回實體的屬性。另外實體鏈接模塊，本身還可以修正 NER 的結果。

② 整體框架

上圖是實體鏈接的整體框架，它主要分爲兩個部分：

離線的部分，其核心是對所有物理實體 mention 的挖掘，其實就是實體的一個別名，用來擴大實體鏈接召回。

線上部分，首先通過別名進行實體召回，然後對召回的實體進行消歧排序。消歧主要結合 Query 文本序列的特徵、基於地理位置的特徵（比如城市和 GeoHash），還有上下文的一些文本信息進行消歧排序，返回給用戶最相關的 Top 實體。

③ 核心算法

核心算法如上圖。離線部分，剛纔也提到了主要是 Mention 的挖掘，目前基礎數據，主要是商家庫的數據、搜索日誌、UGC 評論、知識圖譜等。Mention 挖掘目前主要有三種方式：

右下角是一些例子，比如說標準的別名，凱德茂望京，能夠挖掘出它的一些相關的子成分（凱德 mall）。

在線消歧部分，主要是一些相關性的計算和消歧排序，不再展開了。

▌查詢改寫

1. 背景

爲什麼需要查詢改寫？主要因爲自然語言表達的多樣性，首先是 Query 和 Doc 之間表達的差異，用戶的 Query 會相對隨意，而 Doc 端相對正規，商家和運營錄入的商家介紹等相關字段，會標準化一些。另外一個問題就是一義多詞，通常一個含義的表達會有非常多種輸入的方式。

右圖是線上真實的搜索日誌，是 “理髮” 相關的搜索詞。可以看到有非常多的變換形式。還有一詞多義的問題，比如：結婚照，它可能包含兩類的含義，一類是要找婚紗照，另外還有可能是去拍結婚證需要的證件照，如果我們不進行 Query 查詢的改寫，直接通過原詞文本匹配，很可能會漏召回。

2. 技術演進

查詢改寫這塊，技術演進主要分 4 個階段，最初是基於詞典規則，它的優點是精度高，但是召回率非常低。後面加入了基於用戶行爲統計挖掘的相關擴召回的方式，但由於是基於整串的匹配，召回雖然有一定提升，還是沒法滿足線上用戶很多長尾 Query 的搜索。

爲了解決長尾問題，引入了基於翻譯模型的統計翻譯改寫，主要是通過用戶行爲日誌，訓練翻譯模型和語言模型，從子串片段級別來解決覆蓋問題，極大的提升了改寫的召回。但它的問題是會比較容易產生語義的漂移，因爲它主要是基於文本對齊和文本替換的統計概率，並未考慮語義信息。所以我們又引入了基於 Bert 的語義規範化，進行過濾，很大程度的緩解了語義漂移的問題。

3. 爲什麼選擇 SMT

接下來重點介紹一下我們線上的翻譯改寫模型。

爲什麼要選擇這樣一個翻譯模型呢？首先翻譯所需的平行語料，在搜索場景下，比較容易通過搜索日誌的 Session 來構造，甚至還可以用 Query-Doc 的點擊數據來補充，通過這樣的平行語料，就能夠自動化的獲取海量的標註數據，覆蓋足夠多的語言現象，解決表達多樣的問題。

另外翻譯模型很重要一個特點，是它能夠支持子串級別的替換，並充分考慮上下文。所以說它能夠很好的進行召回泛化。

4. SMT 改寫過程

這是 SMT 改寫的一個大致的過程。它主要分爲三個部分：

最上面是句對挖掘，通過海量的用戶行爲，包括 Session、Query-Title、Query-Doc-Query 數據，對這些數據進行特徵抽取，然後再結合句對的判別模型，生成片段級別的對齊語料。

第二部分翻譯模型訓練，它的輸入是上一步生成的對齊語料，然後生成 N-gram 的片段，再結合語義計算和統計規則，去生產翻譯模型和語言模型。它主要是通過 N-Gram 這種方式進行子串級別的泛化。

第三部分是線上的解碼和終判，主要考慮性能問題。因爲線上替換時，子串候選解碼如果不加限制，會產生組合爆炸的問題。所以結合了 BeamSearch 以及業務相關的過濾器，例如利用 NER 和實體鏈接的信息，對商家實體詞限制改寫，通過這樣的一些業務特徵來保證精度。通過路徑裁減，返回概率最高的 Top-K 的結果，進行改寫路徑的生成。

▌意圖識別

1. 背景

目前我們意圖模塊的核心是識別用戶的業務需求，因爲我們涵蓋的業務品類非常多，不同的業務，展示模板和展示樣式也都不同，比如酒店的查詢，可能會有用戶的入離時間展示模板。所以需要把不同的業務需求識別出來，進行多形態的召回。

上面是我們意圖的劃分，包括左邊的業務意圖，例如美食、酒店、旅遊等等，會直接訪問業務相關索引進行召回。中間是阿拉丁（開放平臺），主要獲取一些活動、第三方結果。最右邊還會有一些基於知識內容的信息類召回，比如根據評論內容召回結果。最下面是對應的一些場景，比如時間、空間、人和事件的場景。

2. 整體框架

意圖識別的整體框架，主要分爲兩個部分：

意圖召回。這塊是轉換爲了分類任務，只判斷某個查詢是否包含某種意圖。線上採用詞典匹配 + 規則 + 模型的方式進行識別，詞典主要包含業務和領域相關數據，詞典和 Pattern 規則，能比較好的解決熱門識別，針對長尾部分，主要靠 Bert 模型來解決泛化識別問題。

意圖分佈。意圖召回完了以後，我們還要知道當前搜索的各個意圖的強弱，尤其是找到主意圖，就是圖上面部分的意圖分佈，我們將其轉化成排序問題。由於線上展示的每條 POI 結果，後臺都有明確的業務歸屬，所以我們就可以依據這個業務歸屬信息和用戶點擊行爲，獲得有標註的訓練語料，來訓練排序模型。模型特徵主要分爲兩部分，一是統計類的特徵，包括一些 CTR、CVR 及相關的用戶行爲的特徵。二是 Embedding 類特徵，來進行語義的表達。

▌總結和展望

最後總結下，本文主要介紹了美團查詢理解系統中的主要模塊，包括實體識別、查詢改寫、意圖識別。查詢理解是搜索引擎與 NLP 結合的產物，用來解決搜索相關的一些文本理解任務。除了文本本身，後續我們還會考慮引入更多包括時空、用戶，場景的信息來做到更深入的理解搜索場景下的用戶查詢意圖。

今天的分享就到這裏，謝謝大家。 

分享嘉賓：

劉亮

美團 | 資深算法工程師

劉亮，美團資深算法工程師。9 年搜索和 NLP 相關工作經驗，目前是美團搜索查詢理解方向架構師。

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

猜你喜歡