搜索中的 Query 理解及應用

文章作者：Joelchen 騰訊 研究員

編輯整理：Hoh

內容來源：騰訊技術工程

出品平臺：DataFunTalk

注：轉載請聯繫原作者。

 

導讀：Query 理解 ( QU，Query Understanding )，簡單來說就是從詞法、句法、語義三個層面對 query 進行結構化解析。這裏 query 從廣義上來說涉及的任務比較多，最常見的就是我們在搜索系統中輸入的查詢詞，也可以是 FAQ 問答或閱讀理解中的問句，又或者可以是人機對話中用戶的聊天輸入。本文主要介紹在搜索中的 query 理解，會相對系統性地介紹 query 理解中各個重要模塊以及它們之間如何 work 起來共同爲搜索召回及排序模塊服務，同時簡單總結個人目前瞭解到業界在各個模塊中的一些實現方法。

 

01

相關概念

1. NLP

自然語言處理 ( NLP，Natural Language Processing ) 是集語言學、統計學、計算機科學，人工智能等學科於一體的交叉領域，目標是讓計算機能在處理理解人類自然語言的基礎上進一步執行結構化輸出或語言生成等其他任務，其涉及的基礎技術主要有：詞法分析、句法分析、語義分析、語用分析、生成模型等。諸如語音識別、機器翻譯、QA 問答、對話機器人、閱讀理解、文本分類聚類等任務都屬於 NLP 的範疇。

這些任務從變換方向上來看，主要可以分爲自然語言理解 ( NLU，Natural Language Understanding ) 和自然語言生成 ( NLG，Natural Language Generation ) 兩個方面，其中 NLU 是指對自然語言進行理解並輸出結構化語義信息，而 NLG 則是多模態內容 ( 圖像、語音、視頻、結構/半結構/非結構化文本 ) 之間的相互生成轉換。

一些任務同時涵蓋 NLU 和 NLG，比如對話機器人任務需要在理解用戶的對話內容 ( NLU 範疇 ) 基礎上進行對話內容生成 ( NLG 範疇 )，同時爲進行多輪對話理解及與用戶交互提示這些還需要有對話管理模塊 ( DM，Dialogue Management ) 等進行協調作出對話控制。本文要介紹的搜索 query 理解大部分模塊屬於 NLU 範疇，而像 query 改寫模塊等也會涉及到一些 NLG 方法。

2. 搜索引擎

在介紹搜索 query 理解之前，先簡單介紹下搜索引擎相關知識。除了傳統的通用搜索 Google、Baidu、Bing 這些，大部分互聯網垂直產品如電商、音樂、應用市場、短視頻等也都需要搜索功能來滿足用戶的需求查詢，相較於推薦系統的被動式需求滿足，用戶在使用搜索時會通過組織 query 來主動表達訴求，爲此用戶的搜索意圖相對比較明確。但即便意圖相對明確，要做好搜索引擎也是很有挑戰的，需要考慮的點及涉及的技術無論在深度還是廣度上都有一定難度。

一個基本的搜索系統大體可以分爲離線挖掘和在線檢索兩部分，其中包含的重要模塊主要有：Item 內容理解、Query 理解、檢索召回、排序模塊等。整個檢索系統的目標可以抽象爲給定 query，檢索出最能滿足用戶需求的 item，也即檢索出概率：P(Ii|Q) 最大的 item Ii。

根據貝葉斯公式展開：

其中 P(Ii) 表示 item 的重要程度，對應 item 理解側的權威度、質量度等挖掘，P(Q|Ii) 表示 item Ii 能滿足用戶搜索需求 Q 的程度，對 query 分詞後可以表示爲：

P(Q|Ii)=P(t1,...,tn|Ii)

這部分概率對應到基於 query 理解和 item 理解的結果上進行 query 和 item 間相關性計算，同時涉及到點擊調權等排序模塊。

① 離線挖掘

在離線側，我們需要做一些基礎的離線挖掘工作，包括 item 內容的獲取、清洗解析、item 內容理解 ( 語義 tag、權威度計算、時間因子、質量度等 )、用戶畫像構建、query 離線策略挖掘、以及從搜索推薦日誌中挖掘 item 之間的語義關聯關係、構建排序模型樣本及特徵工程等。進行 item 內容理解之後，對相應的結構化內容執行建庫操作，分別構建正排和倒排索引庫。其中，正排索引簡單理解起來就是根據 itemid 能找到 item 的各個基本屬性及 term 相關 ( term 及其在 item 中出現的頻次、位置等信息 ) 的詳細結構化數據。

相反地，倒排索引就是能根據分詞 term 來找到包含該 term 的 item 列表及 term 在對應 item 中詞頻、位置等信息。通常會對某個 item 的 title、keyword、anchor、content 等不同屬性域分別構建倒排索引，同時一般會根據 item 資源的權威度、質量度等縱向構建分級索引庫，首先從高質量庫中進行檢索優先保證優質資源能被檢索出來，如果高質量檢索結果不夠再從低質量庫中進行檢索。爲了兼顧索引更新時效性和檢索效率，一般會對索引庫進行橫向分佈式部署，且索引庫的構建一般分爲全量構建和增量更新。常見的能用於快速構建索引的工具框架有 Lucene 全文檢索引擎以及基於 Lucene 的 Solr、ES ( Elastic Search ) 等。

除了基本的文本匹配召回，還需要通過構建 query 意圖 tag 召回或進行語義匹配召回等多路召回來提升搜索語義相關性以及保證召回的多樣性。

② 在線檢索

線上執行檢索時大體可以分爲基礎檢索 ( BS ) 和高級檢索 ( AS ) 兩個過程，其中 BS 更注重 term 級別的文本相關性匹配及粗排，AS 則更注重從整體上把控語義相關性及進行精排等處理。以下面這個框圖爲例，介紹下一個相對簡單的在線檢索過程。對於從 client 發起的線上搜索請求，會由接入層傳入 SearchObj ( 主要負責一些業務邏輯的處理 )，再由 SearchObj 傳給 SearchAS ( 負責協調調用 qu、召回和排序等模塊 )，SearchAS 首先會去請求 SearchQU 服務 ( 負責搜索 query 理解 ) 獲取對 query 理解後的結構化數據，然後將這些結構化數據傳給基礎召回模塊 BS，BS 根據切詞粒度由粗到細對底層索引庫進行一次或多次檢索，執行多個索引隊列的求交求並拉鍊等操作返回結果。

同時 BS 還需要對文本、意圖 tag、語義召回等不同路召回隊列根據各路召回特點採用多個相關性度量 ( 如：BM25 文本相似度、tag 相似度、語義相關度、pagerank 權威度、點擊調權等 ) 進行 L0 粗排截斷以保證相關性，然後再將截斷後的多路召回進行更精細的 L1 相關性融合排序，更復雜一些的搜索可能會有 L0 到 LN 多層排序，每層排序的側重點有所不同，越高層次 item 數變得越少，相應的排序方法也會更復雜。

BS 將經過相關性排序的結果返回給 SearchAS，SearchAS 接着調用 SearchRank 服務進行 ctr/cvr 預估以對 BS 返回的結果列表進行 L2 重排序，並從正排索引及摘要庫等獲取相應 item 詳情信息進一步返回給 SearchObj 服務，與此同時 SearchObj 服務可以異步去請求廣告服務拉取這個 query 對應的廣告召回隊列及競價相關信息，然後就可以對廣告或非廣告 item 內容進行以效果 ( pctr、pcvr、pcpm ) 爲導向的排序從而確定各個 item 內容的最終展示位置。

最後在業務層一般還會支持干預邏輯以及一些規則策略來實現各種業務需求。在實際設計搜索實驗系統時一般會對這些負責不同功能的模塊進行分層管理，以上面介紹的簡單檢索流程爲例主要包括索引召回層、L0 排序截斷層、L1 相關性融合排序層、L2 效果排序層、SearchAS 層、業務層等，各層流量相互正交互不影響，可以方便在不同層進行獨立的 ABtest 實驗。

當然，具體實現搜索系統遠比上面介紹的流程更爲複雜，涉及的模塊及模塊間的交互會更多，比如當用戶搜索 query 沒有符合需求的結果時需要做相關搜索 query 推薦以進行用戶引導、檢索無結果時可以根據用戶的畫像或搜索歷史做無結果個性化推薦等，同時和推薦系統一樣，搜索周邊涉及的系統服務也比較龐雜，如涉及日誌上報迴流、實時計算能力、離/在線存儲系統、ABtest 實驗平臺、報表分析平臺、任務調度平臺、機器學習平臺、模型管理平臺、業務管理後臺等，只有這些平臺能 work 起來，整個搜索系統才能正常運轉起來。

③ 多模語義搜索

隨着資源越來越豐富，如何讓用戶從海量的信息及服務資源中能既準確又快速地找到訴求變得越來越重要，如2009年百度提出的框計算概念目標就是爲了能更快更準地滿足用戶需求。同時，隨着移動互聯網的到來，用戶的輸入方式越來越多樣，除了基本的文本輸入檢索，實現通過語音、圖片、視頻等內容載體進行檢索的多模態搜索也變得越來越有必要。由於用戶需求的多樣或知識背景不同導致需求表達的千差萬別，要做到極致的搜索體驗需要漫長的優化過程，畢竟目前真正的語義搜索還遠未到來。

02

Query 理解

從前面的介紹可以知道，搜索三大模塊的大致調用順序是從 query 理解到檢索召回再到排序，作爲搜索系統的第一道環節，query 理解的結果除了可以用於召回也可以給排序模塊提供必要的基礎特徵，爲此 QU 很大程度影響召回和排序的質量，對 query 是進行簡單字面上的理解還是可以理解其潛在的真實需求很大程度決定着一個搜索系統的智能程度。目前業界的搜索 QU 處理流程還是以 pipeline 的方式爲主，也即拆分成多個模塊分別負責相應的功能實現，pipeline 的處理流程可控性比較強，但存在缺點就是其中一個模塊不 work 或準確率不夠會對全局理解有較大影響。爲此，直接進行 query-item 端到端地理解如深度語義匹配模型等也是一個值得嘗試的方向。

1. Pipeline 流程

搜索 Query 理解包含的模塊主要有：query 預處理、query 糾錯、query 擴展、query 歸一、聯想詞、query 分詞、意圖識別、term 重要性分析、敏感 query 識別、時效性識別等。以下圖爲例，這裏簡單介紹下 query 理解的 pipeline 處理流程：線上來一個請求 query，爲緩解後端壓力首先會判斷該 query 是否命中 cache，若命中則直接返回對該 query 對應的結構化數據。若不命中 cache，則首先會對 query 進行一些簡單的預處理，接着由於 query 糾錯可能會用到分詞 term 信息進行錯誤檢測等先進行 query 分詞並移除一些噪音符號，然後進行 query 糾錯處理，一些情況下局部糾錯可能會影響到上下文搭配的全局合理性，爲此還可能會需要進行二次糾錯處理。

對 query 糾錯完後可以做 query 歸一、擴展及聯想詞用於進行擴召回及幫助用戶做搜索引導。接着再對 query 做分詞及對分詞後的 term 做重要性分析及緊密度分析，對無關緊要的詞可以做丟詞等處理，有了分詞 term 及對應的權重、緊密度信息後可以用於進行精準和模糊意圖的識別。除了這些基本模塊，有些搜索場景還需要有對 query 進行敏感識別及時效性分析等其他處理模塊。最後還需要能在 cms 端進行配置的人工干預模塊，對前面各個模塊處理的結果能進行干預以快速響應 badcase 處理。

當然，這個 pipeline 不是通用的，不同的搜索業務可能需要結合自身情況做 pipeline 的調整定製，像百度這些搜索引擎會有更爲複雜的 query 理解 pipeline，各個模塊間的依賴交互也更爲複雜，所以整個 QU 服務最好能靈活支持各個模塊的動態熱插拔，像組裝樂高積木一樣進行所需模塊的靈活配置，下面對各個模塊做進一步詳細的介紹。

 

2. Query 預處理

Query 預處理這個模塊相對來說比較簡單，主要對 query 進行以下預處理從而方便其他模塊進行分析：

• 全半角轉換：將在輸入法全角模式下輸入的 query 轉換爲半角模式的，主要對英文、數字、標點符號有影響，如將 "ｗｅｃｈａｔ１２３" 全角輸入轉成半角模式下的 "wechat 123"。

• 大小寫轉換：統一將大寫形式的字母轉成小寫形式的。

• 繁簡體轉換：將繁體輸入轉成簡體的形式，當然考慮到用戶羣體的差異以及可能存在繁體形式的資源，有些情況還需要保留轉換前的繁體輸入用於召回。

• 無意義符號移除：移除諸如火星文符號、emoji 表情符號等特殊符號內容。

• Query 截斷：對於超過一定長度的 query 進行截斷處理。

3. Query 分詞

① 分詞技術

Query 分詞就是將 query 切分成多個 term，如："手機淘寶"切分成"手機 淘寶"兩個 term。分詞作爲最基礎的詞法分析組件，其準確性很大程度影響 QU 後面的各個處理，如分詞及對應詞性信息可以用於後續的 term 重要性分析和意圖識別等多個模塊。同時，QU 的分詞及其粒度需要與 item 側索引構建的分詞及粒度保持一致，從而才能進行有效地召回。目前分詞技術相對來說已經比較成熟，主要做法有基於詞典進行前後向最大匹配、對所有成詞情況構造 DAG、hmm/crf 序列標註模型以及深度學習模型+序列標註等。

目前無論學術界還是工業界開放的分詞工具或服務還是比較多的，如主要有騰訊內部的 QQSeg、百度 LAC、Jieba 分詞、清華 THULAC、北大 pkuseg、中科院 ICTCLAS、哈工大 PyLTP、復旦 FNLP、Ansj、SnowNLP、FoolNLTK、HanLP、斯坦福 CoreNLP、Jiagu、IKAnalyzer 等。這些分詞工具在功能和性能上會存在一定的差異，具體使用時要結合業務需求定製選擇，需要考慮的點主要包括：切詞準確性、粒度控制、切詞速度、是否帶有 NER、NER 識別速度、是否支持自定義詞典等，由於沒對所有這些分詞工具做各項性能指標的具體評測，這裏暫時不做過多的比較。

在搜索中的 query 切詞一般會做粒度控制，分爲細粒度和 phrase 粗粒度兩個級別，比如 query "下載深海大作戰"按 phrase 粗粒度切分可以爲"下載 深海大作戰"，按細粒度切分爲"下載 深海 大 作戰"。在進行召回時可以優先用 phrase 粗粒度的切詞結果進行召回能得到更精準相關的結果同時減少多個 term 拉鍊合併的計算量。當 phrase 粗粒度分詞進行召回結果不夠時，可以採用拆分後的細粒度分詞進行二次重查擴召回。

② 新詞發現

一般來說，使用已有的開源切詞工具已經有比較好的切分精度了，但是對於一些新出現的網絡詞彙可能不能及時識別覆蓋，尤其是對於一些垂直搜索有比較多業務專名詞的情況，這時候需要對這些未登錄詞做新詞發現。一些切詞工具自帶有新詞發現功能，比如 Jieba 採用 HMM 進行新詞發現。此外簡單地，可以採用基於統計的方法來進行新詞發現，通過統計語料中的詞語 tfidf 詞頻、凝聚度和自由度等指標來進行無監督新詞挖掘，當詞語的凝聚度和自由度達到一定閾值且已有分詞不能切分到一起時可以人工評估後加進詞庫。其中凝聚度即點互信息：

 

用於衡量兩個 term 共現的概率，兩個 term 經常出現在一起，則可以將它們組合成一個詞語整體的可能性也更大。自由度取 term 左右鄰熵的較小值：

Freedeg=min(entropy(wleft),entropy(wright))

衡量當前 term 左右兩邊字集合的隨機程度，如果左右字集合越隨機則這個 term 獨立成詞的可能性也更大。還有的做法是對 query 進行切詞後構建詞之間的關係矩陣，然後進行矩陣分解，得到各個詞在主特徵空間的投影向量，通過投影向量計算詞之間的相似度並設定相應閾值構造0-1切分矩陣，基於該矩陣進行是否成詞的判斷。再有就是可以將新詞發現轉化爲序列標註問題，訓練 BiLSTM-CRF、BERT-CRF 等模型預測成詞的起始、中間及結束位置，或者轉化爲 ngram 詞在給定句子語境中是否成詞或不成詞二分類問題。

4. 緊密度分析

Term 緊密度，主要用於衡量 query 中任意兩個 term 之間的緊密程度，如果兩個 term 間緊密度比較高，則這兩個 term 在召回 item 中出現的距離越近相對來說越相關。以相鄰的兩個 term 爲例，由於分詞工具本身存在準確率問題，某兩個 term 可能不會被分詞工具切分到一起，但它們之間的關係比較緊密，也即緊密度比較高，如果在召回時能將在 item 中同時出現有這兩個 term 且出現位置挨在一起或比較靠近的 item 進行召回，相關性會更好。

以前面的搜索 query "下載深海大作戰"爲例，經分詞工具可能切分成"下載 深海 大 作戰"，但其實"大"和"作戰"的緊密度很高，從文本相關性角度來看，召回"喵星大作戰" app 要一定程度比"大人物作戰"會更相關。當然，在 query 中並不是兩個 term 的距離越近緊密度越高，可以通過統計搜索 log 裏 term 之間的共現概率來衡量他們的緊密程度。

在進行召回時，傳統的相關性打分公式如 OkaTP、BM25TP、newTP、BM25TOP 等在 BM25 基礎上進一步考慮了 proximity 計算，但主要採用兩個 term 在 item 中的距離度量，如：

 

有了 query 中的 term 緊密度，在召回構造查詢索引的邏輯表達式中可以要求緊密度高的兩個 term 需共同出現以及在 proximity 計算公式中融合考慮進去，從而保證 query 中緊密度高的兩個 term 在 item 中出現距離更近更相關。

5. Term 重要性分析

考慮到不同 term 在同一文本中會有不一樣的重要性，在做 query 理解及 item 內容理解時均需要挖掘切詞後各個 term 的重要性，在進行召回計算相關性時需要同時考慮 query 及 item 側的 term 重要性。如對於 query "手機淘寶"，很明顯 term "淘寶"要比"手機"更重要，爲此賦予"淘寶"的權重應該比"手機"高。Term 重要性可以通過分等級或0.0~1.0的量化分值來衡量，如下圖的 case 所示我們可以將 term 重要性分爲4個級別，重要性由高到低分別是：核心詞、限定詞、可省略詞、干擾詞。對於重要級別最低的 term 可以考慮直接丟詞，或者在索引庫進行召回構造查詢邏輯表達式時將對應的 term 用 "or" 邏輯放寬出現限制，至於計算出的在 query 和 item 內容中的 term 重要性分值則可以用於召回時計算基礎相關性，如簡單地將 BM25 公式：

中 term 在 item 及 query 中的詞頻 tf(t)、qf(t) 乘上各自的 term 權重。

其中 item 內容側的 term 重要性可以採用 LDA 主題模型、TextRank 等方法來挖掘，至於 query 側的 term 重要性，比較容易想到的方法就是把它視爲分類或迴歸問題來考慮，通過訓練 svm、gbdt 等傳統機器學習模型即可進行預測。模型樣本的構造除了進行人工標註還可以通過用戶的搜索點擊日誌來自動構造。大概做法是將某個 query 對應搜索結果的用戶點擊頻次作爲同時出現在 query 及搜索結果 title 中相應 term 的重要性體現，首先通過共同點擊信息或二部圖方法對 query 進行聚類，再將一個 query 對應有不同點擊 title 以及同一 term 在簇內不同 query 中的點擊 title 頻次結果加權考慮起來，同時排除掉一些搜索 qv 比較不置信的 query 及 title 對應的結果，最後將累計頻次進行歸一化及分檔得到樣本對應 label。

至於特徵方面，則可以從詞法、句法、語義、統計信息等多個方向進行構造，比如：term 詞性、長度信息、term 數目、位置信息、句法依存 tag、是否數字、是否英文、是否停用詞、是否專名實體、是否重要行業詞、embedding 模長、刪詞差異度、前後詞互信息、左右鄰熵、獨立檢索佔比 ( term 單獨作爲 query 的 qv / 所有包含 term 的 query 的 qv 和）、iqf、文檔 idf、統計概率：

以及短語生成樹得到 term 權重等。

其中刪詞差異度的做法是先訓練得到 query 的 embedding 表示，然後計算移除各個 term 之後的 query 與原 query 的 embedding 相似度差值用於衡量 term 的重要性，如果移除某個 term 之後相似度差異很大，代表這個 term 比較重要。而短語生成樹的做法是通過從搜索 session 序列及搜索點擊行爲中挖掘出 query 之間的相關關係按 query 長度降序自頂向下進行構造得到，其中樹的邊和結點均有一定的權重。

這裏假設在一定共現關係情況下越短的 query 越是整體意圖的核心表達，所以和越下層結點連接越多的 term 重要性越大，僅和較上層或根結點有連接的 term 重要性相對較小，通過用 iqf 等初始化葉子結點，然後自底向上進行結點分值計算並進行多輪迭代使得 term 權重相對穩定。如下圖所示 query "好玩的5v5策略競技遊戲"構造的短語生成樹示例。

分類迴歸的方法很好地利用了用戶的點擊行爲反饋，通過精細的特徵工程往往能得到比較好的結果。還有的方法就是利用深度學習模型來學習 term 重要性，比如通過訓練基於 BiLSTM+Attention 的 query 意圖分類模型或基於 eq2Seq/Transformer 訓練的 query 翻譯改寫模型得到的 attention 權重副產物再結合其他策略或作爲上述分類迴歸模型的特徵也可以用於衡量 term 的重要性。

6. 搜索引導

受限於用戶的先驗知識的參差不齊或輸入設備引入的噪音，用戶輸入的 query 可能不足以表達用戶真正的需求進而影響用戶搜到想要的結果。爲此，除了保證搜索結果的相關性，一個完善的搜索引擎還需要給用戶提供一系列搜索引導功能，以減少用戶的搜索輸入成本，縮短用戶找到訴求的路徑。搜索引導按功能的不同主要可以分爲：搜索熱詞、搜索歷史、query 改寫、搜索聯想詞，一些電商等垂搜可能還帶有類目屬性等搜索導航功能。由於搜索熱詞及搜索歷史功能相對比較好理解，這裏不做過多闡述。

① Query 改寫

Query 改寫這個概念比較泛，簡單理解就是將源 query 改寫變換到另一個 query。按照改寫功能的不同，query 改寫可以分爲 query 糾錯、query 歸一、query 擴展三個方向。其中 query 糾錯負責對存在錯誤的 query 進行識別糾錯，query 歸一負責將偏門的 query 歸一變換到更標準且同義的 query 表達，而 query 擴展則負責擴展出和源 query 內容或行爲語義相關的 query 列表推薦給用戶進行潛在需求挖掘發現。

Query 糾錯：

Query 糾錯，顧名思義，也即對用戶輸入 query 出現的錯誤進行檢測和糾正的過程。用戶在使用搜索過程中，可能由於先驗知識掌握不夠或輸入過程引入噪音 ( 如：語音識別有誤、快速輸入手誤等 ) 輸入的搜索 query 會存在一定的錯誤。如果不對帶有錯誤的 query 進行糾錯，除了會影響 QU 其他模塊的準確率，還會影響召回的相關性及排序的合理性，最終影響到用戶的搜索體驗。

除了搜索場景，query 糾錯還可以應用於輸入法、人機對話、語音識別、內容審覈等應用場景。不同的業務場景需要解決的錯誤類型會不太一樣，比如 ASR 語音識別主要解決同諧音、模糊音等錯誤，而輸入法及搜索等場景則需要面臨解決幾乎所有錯誤類型，如同諧音、模糊音 ( 平舌翹舌、前後鼻音等 )、混淆音、形近字 ( 主要針對五筆和筆畫手寫輸入法 )、多漏字等錯誤。根據 query 中是否有不在詞典中本身就有錯誤的詞語 ( Non-word )，可以將 query 錯誤類型主要分爲 Non-word 和 Real-word 兩類錯誤。

其中，Non-word 錯誤一般出現在帶英文單詞或數字的 query 中，由於通過輸入法進行輸入，不會存在錯誤中文字的情況，所以中文 query 如果以字作爲最小語義單元的話一般只會存在 Real-word 錯誤，而帶英文數字的 query 則可能存在兩類錯誤。下圖對這兩大類的常見錯誤類型進行歸類及給出了相應的例子。

 

從原理上，Query 糾錯可以用噪音信道模型來理解，假設用戶本意是搜索 Qreal，但是 query 經過噪音信道後引進了一定的噪音，此時糾錯過程相當於構建解碼器將帶有噪音干擾的 query Qnoise 進行最大去噪還原成 Qdenoise，使得 Qdenoise≈Qreal。

對應的公式爲：

 

其中 P(Qdenoise) 表示語言模型概率，P(Qnoise|Qdenoise) 表示寫錯概率，進行糾錯一般都是圍繞着求解這兩個概率來進行的。

糾錯任務主要包含錯誤檢測和錯誤糾正兩個子任務，其中錯誤檢測用於識別錯誤詞語的位置，簡單地可以通過對輸入 query 進行切分後檢查各個詞語是否在維護的自定義詞表或挖掘積累的常見糾錯 pair 中，若不在則根據字型、字音或輸入碼相近字進行替換構造候選並結合 ngram 語言模型概率來判斷其是否存在錯誤，這個方法未充分考慮到上下文信息，可以適用於常見中文詞組搭配、英文單詞錯誤等的檢測。進一步的做法是通過訓練序列標註模型的方法來識別錯誤的開始和結束位置。

至於錯誤糾正，即在檢測出 query 存在錯誤的基礎上對錯誤部分進行糾正的過程，其主要包括糾錯候選召回、候選排序選擇兩個步驟。在進行候選召回時，沒有一種策略方法能覆蓋所有的錯誤類型，所以一般通過採用多種策略方法進行多路候選召回，然後在多路召回的基礎上通過排序模型來進行最終的候選排序。

對於英文單詞錯誤、多漏字、前後顛倒等錯誤可以通過編輯距離度量進行召回，編輯距離表示從一個字符串變換到另一個字符串需要進行插入、刪除、替換操作的次數，如 "apple" 可能錯誤拼寫成 "appel"，它們的編輯距離是1。由於用戶的搜索 query 數一般是千萬甚至億級別的，如果進行兩兩計算編輯距離的話計算量會非常大，爲此需要採用一定的方法減小計算量才行。比較容易想到的做法是採用一些啓發式的策略，如要求首字 ( 符 ) 一樣情況下將長度小於等於一定值的 query 劃分到一個桶內再計算兩兩 query 間的編輯距離，此時可以利用 MapReduce 進一步加速計算。

當然這種啓發式的策略可能會遺漏掉首字 ( 符 ) 不一樣的 case，如在前面兩個位置的多漏字、顛倒等錯誤。還有的辦法就是利用空間換時間，如對 query 進行 ngram 等長粒度切分後構建倒排索引，然後進行索引拉鍊的時候保留相似度 topN 的 query 作爲候選。又或者利用編輯距離度量滿足三角不等式 d(x,y)+d(y,z)≥d(x,z) 的特性對多叉樹進行剪枝來減少計算量。

首先隨機選取一個 query 作爲根結點，然後自頂向下對所有 query 構建多叉樹，樹的邊爲兩個結點 query 的編輯距離。給定一個 query，需要找到與其編輯距離小於等於 n 的所有 query，此時自頂向下與相應的結點 query 計算編輯距離 d，接着只需遞歸考慮邊值在 d-n 到 d+n 範圍的子樹即可。如下圖所示需要查找所有與 query "十面埋弧"編輯距離小於等於1的 query，由於"十面埋弧"與"十面埋伏"的編輯距離爲1，此時只需考慮邊值在1-1到1+1範圍的子樹，爲此"十面埋伏怎麼樣"作爲根結點的子樹可以不用繼續考慮。

對於等長的拼音字型錯誤類型還可以用 HMM 模型進行召回，HMM 模型主要由初始狀態概率、隱藏狀態間轉移概率及隱藏狀態到可觀測狀態的發射概率三部分組成。如下圖所示，將用戶輸入的錯誤 query "愛奇義"視爲可觀測狀態，對應的正確 query "愛奇藝"作爲隱藏狀態，其中正確 query 字詞到錯誤 query 字詞的發射關係可以通過人工梳理的同諧音、形近字混淆詞表、通過編輯距離度量召回的相近英文單詞以及挖掘好的糾錯片段對得到。

至於模型參數，可以將搜索日誌中 query 進行採樣後作爲樣本利用 hmmlearn、pomegranate 等工具採用 EM 算法進行無監督訓練，也可以簡單地對搜索行爲進行統計得到，如通過 nltk、srilm、kenlm 等工具統計搜索行爲日誌中 ngram 語言模型轉移概率，以及通過統計搜索點擊日誌中 query-item 及搜索 session 中 query-query 對齊後的混淆詞表中字之間的錯誤發射概率。訓練得到模型參數後，採用維特比算法對隱藏狀態序列矩陣進行最大糾錯概率求解得到候選糾錯序列。

 

進一步地，我們還可以嘗試深度學習模型來充分挖掘搜索點擊行爲及搜索 session 進行糾錯候選召回，如採用 Seq2Seq、Transformer、Pointer-Generator Networks 等模型進行端到端的生成改寫，通過引入 attention、copy 等機制以及結合混淆詞表進行受限翻譯生成等優化，可以比較好地結合上下文進行變長的候選召回。

另外結合 BERT 等預訓練語言模型來進行候選召回也是值得嘗試的方向，如在 BERT 等預訓練模型基礎上採用場景相關的無監督語料繼續預訓練，然後在錯誤檢測的基礎上對錯誤的字詞進行 mask 並預測該位置的正確字詞。Google 在2019年提出的 LaserTagger 模型則是另闢蹊徑將文本生成建模爲序列標註任務，採用 BERT 預訓練模型作爲 Encoder 基礎上預測各個序列位置的增刪留標籤，同樣適用於 query 糾錯這種糾錯前後大部分文本重合的任務。

另外，愛奇藝在同一年提出的適用於繁簡體中文拼寫檢糾錯的 FASPell 模型嘗試在利用 BERT 等預訓練語言模型生成糾錯候選矩陣 ( DAE ) 的基礎上結合生成候選的置信度及字符相似度對候選進行解碼過濾 ( CSD ) 出候選糾錯目標，在中文糾錯任務上也取得了一定進展。

在多路召回的基礎上，可以通過從詞法、句法、語義及統計特徵等多個方面構造特徵訓練 GBDT、GBRank 等排序模型將預測出最優的糾錯候選。由於進行多路糾錯候選召回計算量相對比較大且直接進行線上糾錯會存在較大的風險，可以在離線挖掘好 query 糾錯 pair 後按搜索 qv 優先進行對頭中部 query 進行人工審覈准入，然後放到線上存儲供調用查詢。線上應用時，當 QU 識別到用戶輸入 query 存在錯誤並進行相應糾錯後，對於不那麼置信的結果可以將糾錯結果透傳給召回側進行二次檢索使用，對於比較置信的糾錯結果可以直接展示用糾錯後 query 進行召回的結果並給到用戶搜索詞確認提示 ( 如下圖所示 )，如果糾錯 query 不是用戶真實意圖表達的話，用戶可以繼續選擇用原 query 進行搜索，此時用戶的反饋行爲也可以用於進一步優化 query 糾錯。

Query 擴展：

Query 擴展，即通過挖掘 query 間的語義關係擴展出和原 query 相關的 query 列表。Query 列表的結果可以用於擴召回以及進行 query 推薦幫用戶挖掘潛在需求，如下圖在百度搜索"自然語言處理"擴展出的相關搜索 query：

搜索場景有豐富的用戶行爲數據，我們可以通過挖掘搜索 session 序列和點擊下載行爲中 query 間的語義關係來做 query 擴展。如用戶在進行搜索時，如果對當前搜索結果不滿意可能會進行一次或多次 query 變換重新發起搜索，那麼同一搜索 session 內變換前後的 query 一般存在一定的相關性，爲此可以通過統計互信息、關聯規則挖掘等方法來挖掘搜索 session 序列中的頻繁共現關係。

或者把一個用戶搜索 session 序列當成文章，其中的每個 query 作爲文章的一個詞語，作出假設：如果兩個 query 有相同的 session 上下文，則它們是相似的，然後通過訓練 word2vec、fasttext 等模型將 query 向量化，進而可以計算得到 query 間的 embedding 相似度。

對於長尾複雜 query，通過 word2vec 訓練得到的 embedding 可能會存在 oov 的問題，而 fasttext 由於還考慮了字級別的 ngram 特徵輸入進行訓練，所以除了可以得到 query 粒度的 embedding，還可以得到字、詞粒度的 embedding，此時通過對未登錄 query 切詞後的字、詞的 embedding 進行簡單的求和、求平均也可以得到 query 的 embedding 表示。還可以參考 WR embedding 的做法進一步考慮不同 term 的權重做加權求平均，然後通過減去主成分的映射向量以加大不同 query 間的向量距離，方法簡單卻比較有效。

至於搜索點擊下載行爲，可以通過構建 query-item 的點擊下載矩陣，然後採用協同過濾或 SVD 矩陣分解等方法計算 query 之間的相似度，又或者構建 query 和 item 之間的二部圖 ( 如下圖示例 )，若某個 query 節點和 item 節點之間存在點擊或下載行爲則用邊進行連接，以 ctr、cvr 或歸一化的點擊下載次數等作爲連接邊的權重，然後可以訓練 swing、simrank/wsimrank++ 等圖算法迭代計算 query 間的相似度，也可以採用 Graph Embedding 的方法來訓練得到 query 結點間的 embedding 相似度。

更進一步地，我們還可以利用搜索點擊下載行爲構造弱監督樣本訓練基於 CNN/LSTM/BERT 等子網絡的 query-item 語義匹配模型得到 query 和 item 的 embedding 表示，如此也可以計算 query pair 間的 embedding 相似度。對於將 query 進行 embedding 向量化的方法，可以先離線計算好已有存量 query 的 embedding 表示，然後用 faiss 等工具構建向量索引，當線上有新的 query 時通過模型 inference 得到對應的 embedding 表示即可進行高效的近鄰向量檢索以召回語義相似的 query。

在給用戶做搜索 query 推薦時，除了上面提到的跟用戶當前輸入 query 單點相關 query 推薦之外，還可以結合用戶歷史搜索行爲及畫像信息等來預測用戶當前時刻可能感興趣的搜索 query，並在搜索起始頁等場景進行推薦展示。此時，可以通過 LSTM 等網絡將用戶在一段 session 內的搜索行爲序列建模爲用戶 embedding 表示，然後可以通過構建 Encoder-Decoder 模型來生成 query，或採用語義匹配的方法將用戶 embedding 及 query embedding 映射到同一向量空間中，然後通過計算 embedding 相似度的方法來召回用戶可能感興趣的 query。

Query 歸一：

Query 歸一和 query 糾錯在概念上容易混淆，相較於 query 糾錯是對存在錯誤的 query 進行糾正，query 歸一則主要起到對同近義表達的 query 進行語義歸一的作用。一些用戶的 query 組織相對來說比較冷門，和 item 側資源的語義相同但文字表達相差較大，直接用於召回的話相關性可能會打折扣，這時如果能將這些 query 歸一到相對熱門同義或存在對應資源的 query 會更容易召回相關結果。如將"騰訊檯球"歸一到"騰訊桌球"，"華仔啥時候出生的？"、"劉德華出生年月"、"劉德華什麼是出生的"這些 query 都可以歸一到"劉德華出生日期"相對標準的 query。其中涉及到的技術主要有同義詞挖掘及語義對齊替換，如"華仔"對應的同義詞是"劉德華"，"啥時候出生的"對應的同義詞是"出生日期"。

同義詞的挖掘是一個積累的過程，最直接的獲取方式是利用業界已經有一些比較有名的知識庫，如英文版本的 WordNet、中文版本的知網 HowNet、哈工大的同義詞詞林等，或者可以利用一些開放的中文知識圖譜 ( 如：OpenKG、OwnThink 等 ) 或從抓取百度/維基百科站點數據然後提取出其中的別名、簡稱等結構化信息直接獲得，對於百科中無結構化數據可以簡單通過一些模板規則 ( 如："XX俗稱XX"、"XX又名XX"等 ) 來提取同義詞。同時，還可以在知識庫中已有同義詞種子的基礎上通過一些方法進一步擴充同義詞，如韓家煒老師團隊提出的通過構建分類器來判斷實體詞是否屬於某個同義詞簇的方法來進一步擴充同義詞集。

除了利用結構化數據或規則模板，還可以在構造平行語料基礎上通過語義對齊的方式來挖掘同義詞。對於搜索場景來說，可以通過挖掘豐富的行爲數據來構造平行語料，如利用搜索 session 行爲相關語料訓練無監督的 word2vec、wordrank 等詞向量模型來衡量詞語間的相似度，不過這些模型更多是學習詞語間在相同上下文的共現相似，得到的相似度高的詞語對不一定是同義詞，有可能是同位詞、上下位詞甚至是反義詞，此時需要通過引入監督信號或外部知識來優化詞向量，如有方法提出通過構建 multi-task 任務在預測目標詞的同時預測目標詞在句子中表示的實體類型以加入實體的語義信息來提升詞向量之間的語義相似性。

進一步地，還可以利用前面介紹的二部圖迭代、深度語義匹配、Seq2Seq 翻譯生成等 query 擴展方法從搜索點擊弱監督行爲中先挖掘出語義表達相近的 query-query、item-item 或 query-item 短語對，然後再將語義相近的 query/item 短語對進行語義對齊，對齊的話可以採用一些規則的方法，也可以採用傳統的統計翻譯模型如 IBM-M2 進行對齊，語義對齊後從中抽取出處於相同或相近上下文中的兩個詞語作爲同義詞對候選，然後結合一些統計特徵、詞語 embedding 相似度以及人工篩選等方式進行過濾篩選。

考慮到同一個詞語在不同的上下文中可能表達不同的語義，同義詞語間的關係也是上下文相關的，此時如果通過對齊挖掘粗粒度的同義片段對能進一步消除歧義。線上對 query 進行歸一時，則和離線同義詞挖掘的過程相反，對 query 進行分詞後讀取線上存儲的同義詞表做同義詞候選替換，對替換網格進行對齊生成候選 query，最後通過結合語言模型概率及在當前上下文的替換概率或者構造特徵訓練 GBDT 等模型的方式對候選 query 進行排序得到最終的歸一 query。

② 搜索聯想詞

聯想詞，顧名思義，就是對用戶輸入 query 進行聯想擴展，以減少用戶搜索輸入成本及輸錯可能，能比較好地提升用戶搜索體驗。聯想結果主要以文本匹配爲主，文本匹配結果不足可以輔以語義召回結果提升充盈率。考慮到用戶在輸入搜索 query 時意圖相對明確，一般會從左到右進行 query 組織，爲此基於這個啓發式規則，目前聯想詞中文本匹配召回又以前綴匹配優先。

雖然聯想詞涉及的是技術主要是簡單的文本匹配，在匹配過程中還需要考慮效率和召回質量，同時中文輸入可能會有拼音輸入的情況 ( 如上圖所示 ) 也需要考慮。由於用戶在搜索框中輸入每一個字時都會發起一起請求，聯想詞場景的請求 pv 是非常大的。爲加速匹配效率，可以通過對歷史搜索 query 按 qv 量這些篩選並預處理後分別構建前後綴 trie 樹用於對用戶線上輸入的 query 進行前綴及中後綴匹配召回，然後對召回的結果進行排序，如果是僅簡單按 qv 降序排序，可以在 trie 樹結點中存放 qv 信息並用最小堆等結構進行 topK 召回。

當然僅按 qv 排序還不夠，比如可能還需要考慮用戶輸入上文 query 後對推薦的下文 query 的點擊轉化、下文 query 在結果頁的點擊轉化以及 query 的商業化價值等因素。同時一些短 query 召回的結果會非常多，線上直接進行召回排序性能壓力較大，爲此可以先通過離線召回並進行粗排篩選，再將召回結果寫到一些 kv 數據庫如 redis、共享內存等存儲供線上直接查詢使用。離線召回的話，可以採用 AC 自動機同時進行高效的前中後綴匹配召回。AC 自動機 ( Aho-Corasic ) 是基於 trie 數 + KMP 實現的多模匹配算法，可以在目標文本中查找多個模式串的出現次數以及位置。此時，離線召回大致的流程是：

• 從歷史搜索 query 中構造前綴 sub-query，如 query "酷我音樂"對應的 sub-query 有中文形式的"酷"、"酷我"、"酷我音"、"酷我音樂"及拼音字符串 "ku"、"kuwo" 等，同時可以加上一些專名實體或行業詞，如應用垂搜中的"音樂"、"視頻"等功能需求詞；

• 利用所有的 sub-query 構建 AC 自動機；

• 利用構建的 AC 自動機對歷史搜索 query 及其拼音形式分別進行多模匹配，從中匹配出所有的前中後綴 sub-query，進而得到 <sub-query，query> 召回候選。

• 按照一定策略 ( 一般在前綴基礎上 ) 進行候選粗排並寫到線上存儲。

• 線上來一個請求 sub-query，直接查詢存儲獲取召回結果，然後再基於訓練的 pctr 預估模型或 pcpm 商業化導向進行重排，此時可以通過引入用戶側、context 側等特徵實現個性化排序。

7. 意圖識別

搜索意圖識別是 QU 最重要卻也最具挑戰的模塊，存在的難點主要有：

• 用戶輸入 query 不規範：由於用戶先驗知識的差異，必然導致用戶在通過自然語言組織表達同一需求時千差萬別，甚至可能會出現 query 表達錯誤、遺漏等情況；

• 歧義性&多樣性：用戶的搜索 query 表達不夠明確帶來的意圖歧義性或用戶本身搜索意圖存在多樣性，比如：搜索 query "擇天記"可能是想下載仙俠玄幻類遊戲，可能是玄幻小說類 app，也可能是想看擇天記電視劇而下視頻類 app。此時衍生出來的另一個問題是當某個 query 存在多個意圖可能時，需要合理地量化各個意圖的需求強度；

• 如何根據用戶及其所處 context 的不同實現個性化意圖，比如用戶的性別、年齡不同，搜索同一 query 的意圖可能不一樣，用戶當前時刻搜索 query 的意圖可能和上一時刻搜索 query 相關等。

根據用戶意圖明確程度的差別，搜索意圖識別又可以細分爲精準意圖和模糊意圖識別。

① 精準意圖

所謂精準意圖，是指用戶通過 query 所表達的意圖已經非常明確了，其需求可以比較置信地鎖定爲一個資源目標。精準意圖需求在垂直搜索中尤爲常見，以應用市場 app 搜索爲例，用戶搜索 query "下載王者榮耀"很明確就是想下載"王者榮耀" app，這時候將"王者榮耀"展現在結果列表首位才合理。當然一般排序模型擬合足夠好的情況下也能將對應的精準資源排在首位，但是以下一些情況可能會引起排序不穩定進而導致對應精準資源沒能置頂在首位的問題：

• 長尾 query 行爲特徵稀疏，模型學習不夠充分；

• 引入用戶個性化特徵，排序結果因人而異；

• 以商業化爲導向的排序影響相關性體驗。爲此，需要一定策略識別出精準首位意圖並將它們高優置頂，同時可以通過直達區產品形態給用戶快速直達需求的搜索體驗。

對於垂直搜索來說，精準意圖一般是給定一個 query，找到與其意圖精準對應的 item，可以通過文本匹配和 top 後驗轉化篩選出候選 item，然後通過從文本匹配、行爲反饋、語義相似等方向構造樣本特徵訓練 GBDT 等模型對 <query,item> 樣本 pair 進行是否精準二分類。也可以嘗試類似 DSSM 的語義匹配網絡對 query 和 item 進行語義匹配。對於長尾 query 且完全文本包含 item 的情況，由於行爲量不夠豐富利用分類模型可能無法召回且直接進行文本匹配提取可能存在歧義性，此時可以視爲 NER 任務通過訓練 BiLSTM-CRF、BERT-CRF 等序列標註模型進行 item 實體的識別，再結合一些啓發性策略及後驗行爲進行驗證。

在 Google、百度等通用搜索中，用戶可能會輸入一些知識問答型的 query，此時用戶的意圖也比較明確，就是問題對應的答案。如搜索 query "劉德華的妻子是誰"，通過召回帶"劉德華"、"妻子"字樣的網頁，用戶估計也能找到答案，但如果能直接給出這個 query 的答案的話體驗會更好，如下面百度搜索給出的結果。

這時候可以歸爲 QA 問答任務來處理，一般需要結合知識圖譜來做，也即 KBQA ( Knowledge Based Question Answer )。傳統的的 KBQA 做法是先對 query 進行詞法句法以及語義解析，識別出其中的主要實體概念，再基於這些主題概念構造相應的查詢邏輯表達式去知識庫中進行查詢及推理得到想要的答案。之後陸續有提出將問題和知識庫中候選答案映射成分佈式向量進行匹配，以及利用 CNN、LSTM、記憶網絡等模型對應問題及候選答案向量建模優化等方法來進行 KBQA。

2. 模糊意圖

模糊意圖就是指用戶的搜索意圖不會具體到某個目標資源，而是代表一類或多類意圖，比如用戶搜索"視頻app"，此時沒有明確想下某款 app，可將其泛化到"視頻類" tag 意圖。模糊意圖識別一般可以採用基於模板規則、行爲統計反饋、分類模型等方法，這裏主要會從意圖分類及槽位解析兩個方向進行闡述。

意圖分類：

在構建 query 意圖分類模型之前，需要先制定一套意圖標籤體系用於全面覆蓋用戶意圖需求。這裏需要對 query 側和 item 側的標籤體系進行統一以便於在預測出某個 query 的意圖 tag 分佈後直接用 tag 去倒排索引中召回屬於這些 tag 的 item。

由於搜索 query 一般相對來說長度較短且意圖存在多樣性，意圖分類可以歸結爲短文本多標籤分類任務。在意圖分類樣本構造方面，可以通過關聯用戶搜索點擊行爲分佈及進行 item 理解獲得的 tag 或站點所屬行業分類信息等自動構造樣本，對於可能存在的樣本類別不平衡的問題，需要對樣本進行重降採樣等處理，或採用主動學習等方法進行高效的樣本標註。

至於模型方面，傳統的文本分類主要採用向量空間模型 VSM 或進行其他特徵工程來表徵文本，然後用貝葉斯、SVM、最大熵等機器學習模型進行訓練預測。隨着 Word2vec、GloVe、Fasttext 等分佈式詞向量技術的興起，打破了傳統 NLP 任務需要做大量特徵工程的局面，通過分佈式向量對文本進行表示後再接入其它網絡結構進行端到端分類訓練的做法成爲了主流。

如採用比較簡單又實用的淺層網絡模型 Fasttext，Fasttext 是從 Word2vec 衍生出來的，架構和 Word2vec 的類似，核心思想是將整篇文檔的詞及 n-gram 向量疊加平均得到文檔向量，然後使用文檔向量做 softmax 多分類。相對 Word2vec 的優點是輸入層考慮了字符級 ngram 特徵可以一定程度解決 oov 問題以及輸出層支持進行有監督的任務學習。使用 Fasttext 訓練簡單，且線上 inference 性能也很高，但也正因爲採用相對簡單的淺層網絡結構其準確率也相對較低。爲此，進一步地可以嘗試一些深度神經網絡模型，如：TextRNN、TextCNN、Char-CNN、BiLSTM+Self-Attention、RCNN、C-LSTM、HAN、EntNet、DMN 等。

這些模型通過 CNN/RNN 網絡結構提煉更高階的上下文語義特徵以及引入注意力機制、記憶存儲機制等可以有效地優化模型的分類準確率。其實，對於 query 短文本分類來說採用相對簡單的 TextRNN/TextCNN 網絡結構就已經能達到較高的準確率了，其中 TextRNN 通過使用 GRU/LSTM 編碼單元能更好地捕獲詞序和較長長度的上下文依賴信息，但由於採用 RNN 網絡訓練耗時相對較長。TextCNN 則主要通過不同 size 的卷積核捕獲不同局部窗口內的 ngram 組合特徵，然後一般通過 max-pooling 或 kmax-pooling 保留變長文本中一個或多個位置的最強特徵轉換爲固定長度的向量再做 sigmoid/softmax 分類。

同時爲進一步提升網絡性能及加速模型收斂，還可以在網絡中進一步考慮 dropout 及 batch normalize 等防過擬合機制，以及考慮在輸入層融入 Word2vec、GloVe、Fastext 等模型預訓練得到的 embedding，如下圖在 cnn 輸入層中加入預訓練 embedding 組成雙通道輸入。雖然 TextCNN 對於捕獲長程依賴信息方面會不如 TextRNN，考慮到 query 一般長度相對較短所以影響相對還好，而且其訓練速度及在線 inference 性能也都比較符合要求。

除了從零開始訓練或引入無監督預訓練的隱式 embedding 表示，還可以通過引入顯式的知識概念進一步豐富文本的語義表達，在有比較豐富的領域知識庫的情況下進行 NER 實體識別，然後在模型的輸入中可以融入這些實體知識特徵，通過引入外部知識來優化分類的模型有 KPCNN、STCKA 等。由於 Word2vec、GloVe 等模型訓練得到的詞語 embedding 對不同的上下文來說都是固定的，無法解決一詞多義等問題，基於此陸續提出的 ELMO、GPT、BERT 等深度預訓練語言模型漸漸成爲了 NLP 任務的標配，這些模型及其各種演進版本在多個 GLUE 基準中均取得了進一步的突破。

通過在大規模語料上預訓練得到的 BERT 等模型能較好地動態捕獲詞語在不同上下文中的前後向語義表達，基於這些預訓練模型在意圖分類任務上進行 finetune 學習能進一步提升模型分類準確率。同樣地，像 ERNIE 等模型通過引入外部知識也能進一步提升模型效果，尤其在一些垂直搜索有較多特定領域實體的情況下，可以嘗試將這些領域實體知識融入模型預訓練及 finetune 過程中。由於 BERT 等模型複雜度較高，進行在線 inference 時耗時也相對較高可能達不到性能要求，爲此需要在模型精度和複雜度上做個權衡，從模型剪枝、半精度量化、知識蒸餾等方向進行性能優化。這裏可以嘗試通過權重分解及參數共享等方法精簡優化的 ALBERT 模型，也可以嘗試諸如 DistilBERT、TinyBERT 等知識蒸餾學習模型。

槽位解析：

前面介紹的各種基於深度學習模型的意圖分類能起到比較好相關性導航的作用，如將 query 意圖劃分到"天氣"、"酒店"、"汽車"等意圖體系中。但是針對更加複雜的口語化 query，我們需要進行識別提取出 query 中重要的意圖成分以進行更全面的意圖理解，此時僅進行意圖分類是不夠的。比如對於搜索 query "北京飛成都的機票"，意圖分類模型可以識別出是"訂機票"的意圖，但是無法區分出 query 中的出發地和目的地信息，需要通過一定方法識別出"出發地"概念及其對應值是"北京"、"目的地"概念及其對應值是"成都"，基於此可以作出一些決策提供更直觀的結果以提升用戶搜索體驗。

由於自然語言表達充滿着歧義性，計算機肯定是無法直接理解的，需要將 query 表示成計算機能夠理解的表示。類似於計算機語言無法理解高級編程語言一樣，需要通過將高級編程語言代碼編譯成低級的彙編或二進制代碼後計算機才能執行。所以我們也需要一個類似的"編譯器"能將 query 按一定文法規則進行確定性的形式化表示，可以將這個過程稱之爲語義解析，前面提到的傳統 KBQA 的做法也需要該技術將 query 轉換成相應的形式化表示才能進一步執行推理等操作。

對於 query "北京飛成都的機票"，通過意圖分類模型可以識別出 query 的整體意圖是訂機票，在此基礎上進一步語義解析出對應的出發地 Depart="北京"，到達地 Arrive="成都"，所以生成的形式化表達可以是：Ticket=Order(Depart,Arrive)，Depart={北京}，Arrive={成都}。如果 query 換成是"成都飛北京的機票"，同樣的需要解析出 query 的意圖是訂機票，但是出發地和到達地互換了，所以語義解析過程需要除了需要對概念進行標註識別，還可以通過對概念進行歸一來提高泛化性，比如這裏"北京"、"成都"都可以歸一爲 [city] 概念，形式化表達變爲：Ticket=Order(Depart,Arrive)，Depart={city}，Arrive={city}，其中 city={北京、上海、成都…}。

形式化表達可以遞歸地定義爲一些子表達式的組合的形式，爲進行語義解析，最主要的是確定一種形式化語言及對應的解析器，通常我們採用確定的上下文無關文法以確保形式化的每一部分都對應有一個解析樹。得到 query 對應的形式化表示後，還可以進行一些解析樹歸併等形式化運算推演。爲此，除了可以用來理解搜索 query 的結構化語義，語義解析技術也廣泛應用於 QA 問答及聊天機器人中，如多輪對話中比較有挑戰的上下文省略和指代消歧問題也可以一定程度通過將下文 query 對應的解析樹合併變換到上文 query 對應的解析樹中來解決。如下圖例子所示，當用戶在第一輪對話詢問"成都明天氣溫？"時構造出相應的解析樹，接着問"後天如何？"時就可以將日期進行替換後合併到之前的解析樹中。

目前學術界和工業界在形式化語言和語義解析器方面均有一定的研究成果，通過一些基於統計、半監督、監督的方法來訓練得到語義解析器，其中比較有名的開源語義解析器有 Google 的 SLING、SyntaxNet。簡單的做法是通過人工制定的正則表達式和槽位解析的方法來進行語義解析，正則表達式相對好理解，槽位解析是指通過將具有相同模式的 query 歸納成模板，基於模板規則來解析用戶 query 意圖及意圖槽位值。模板構成主要包括：槽位詞、固定詞、函數、通配符，其形式化表達變爲中槽位詞是指能抽象到某一概念的詞語集合，如："北京"、"上海"、"成都"這些詞都可以抽象到城市概念，固定詞也即明確的某個詞語，可以通過函數來匹配一些諸如數字組合等詞，通配符可以匹配任意字符。

我們需要結合領域的業務知識來構造模板，構造過程需要保證模板符合語法句式規範，同時儘量保證其泛化性以覆蓋更多的 query 問法。舉個簡單例子，構造模板："適合[Slot:User][Wild:0-10][Slot:AppType]"及相應的槽位詞 [Slot:User]={女生，男生，小孩，老人,…}、[Slot:AppType]={單機遊戲，益智遊戲，moba遊戲，…}，然後通過構建如下圖所示的相應 trie 樹，可以自上而下遍歷及回溯解析出 query "適合女生玩的單機遊戲"匹配上了這個模板，從而識別出 query 整體意圖是詢問女生類單機遊戲，其中用戶槽位值爲"女生"，app 類型槽位值爲"單機遊戲"，"適合"是固定詞，"玩的"匹配通配符 [Wild:0-10]，基於這些槽位解析的結果，接下來可以進行一系列的決策。

槽位解析方法的優點是準確率高，可控性強，解釋性好，但缺點是需要耗費較多地人力進行對模板及槽位詞等進行標註，同時維護起來也比較麻煩。可以考慮結合一些策略方法來一定程度減少人工標註量，如基於前面提到的同義詞挖掘技術及詞向量化挖掘同位/上下位詞等方法來輔助槽位詞的標註，以及在人工進行模板標註的基礎上採用 bootstrapping 迭代挖掘構造出更多的模板。槽位解析的具體實現可以參考的開源項目 Snips-nlu，進行意圖識別的同時從自然語言句子中解析提取結構化槽位信息。

8. 敏感識別

敏感識別模塊主要對 query 進行是否帶有色情、反動、賭博、暴力等敏感話題的識別，如果識別出 query 中存在敏感話題可以進行定向改寫到相對合適的 query 或者給用戶做搜索引導提示等處理。敏感識別可以歸爲分類問題，最簡單的做法就是詞表匹配，按不同的敏感話題人工輸入一批詞庫，複雜點就訓練一個分類模型進行多分類，傳統的 SVM、最大熵分類或者 TextCNN、TextRNN 等模型都能比較好地 work。

9. 時效性分析

用戶的搜索需求可能會顯式或隱式地帶有一定的時效性要求，如："最近上映的好看電影"帶有顯式的時間詞"最近"，而"疫情進展"則隱式地表達瞭解最新情況的需求。時效性大概可以分爲三種：持續時效性，週期時效性，準/實時時效性。其中持續時效性是指 query 一直具有時效性，如："美食推薦"，週期時效性是指具有週期性、季節性的事件或需求，如："世界盃"、用戶在冬季搜索"上衣"等，而準/實時效性是指近期發生或突然發生的事件。

通過分析出 query 的時效性需求等級的不同，在召回 item 時就可以針對性地做一些過濾或者在排序時進行時效性調權。其中顯式的時效性需求因爲帶有時間關鍵詞，可以通過規則匹配或訓練分類模型進行判斷識別，而隱式表達的時效性則可以通過按時間維度分析歷史搜索 qv 行爲、實時監測最新搜索 qv 變化情況以及綜合考慮搜索意圖及當前時間上下文等方法來判斷識別。

 

03

結語

人工智能的發展是循序漸進的，需要經歷從計算智能到記憶智能、感知智能、認知智能，最終到達創造智能等多個發展階段才能稱得上是真正的人工智能。目前業界在計算、記憶和感知方面已經做得相對比較成熟，但是在認知智能方面則還需要有進一步突破，而 NLP 恰好是實現認知智能最重要的一環，爲此 NLP 也被稱爲人工智能皇冠上的一顆明珠。同樣地，真正的語義搜索也遠未到來，對 query 的語義理解能力很大程度決定着整個搜索的智能程度。本文僅爲個人在進行 query 理解相關優化項目的一些簡單總結，主要從搜索的角度對 query 理解涉及的各個重要模塊的概念及其對應的一些方法進行闡述。文中暫未涉及太深的技術探討，希望能幫助到大家對搜索 QU 相關概念有一個初步的認識，起到拋磚引玉的效果，如有錯誤及不足之處，還請不吝交流指出。

原文鏈接：

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

社羣推薦：

歡迎加入 DataFunTalk 搜索算法交流羣，跟同行零距離交流。如想進羣，請加逃課兒同學的微信（微信號：DataFunTalker），回覆：搜索算法，逃課兒會自動拉你進羣。

參考文獻：

[1] Kim, Y. (2014). Convolutional Neural Networks for Sentence Classification. Proceedings of the 2014 Conference on Empirical Methods in Natural Language Processing (EMNLP 2014), 1746–1751.

[2] Kalchbrenner, N., Grefenstette, E., & Blunsom, P. (2014). A Convolutional Neural Network for Modelling Sentences. Acl, 655–665.

[3] Armand Joulin, Edouard Grave , Piotr Bojanowski, omas Mikolov. Bag of Tricks for Efficient Text Classification. arXiv, 2016.

[4] Dzmitry Bahdanau, KyungHyun Cho, Yoshua Bengio. Neural Machine Translation By Jointly Learning To Align And Translate. ICLR, 2015.

[5] Sanjeev Arora, Yingyu Liang, Tengyu Ma. A Simple but Tough-to-Beat Baseline for Sentence Embeddings,2016.

[6] C Zhou, C Sun, Z Liu, F Lau. A C-LSTM neural network for text classification. arXiv, 2015.

[7] X Zhang, J Zhao, Y LeCun. Character-level convolutional networks for text classification. NIPS, 2015.

[8] S Lai, L Xu, K Liu, J Zhao. Recurrent convolutional neural networks for text classification. AAAI, 2015.

[9] Z Lin, M Feng, CN Santos, M Yu, B Xiang. A structured self-attentive sentence embedding. arXiv, 2017.

[10] J Howard, S Ruder. Universal language model fine-tuning for text classification. arXiv, 2018.

[11] J Devlin, MW Chang, K Lee, K Toutanova. Bert: Pre-training of deep bidirectional transformers for language understanding. arXiv, 2018.

[12] J Wang, Z Wang, D Zhang, J Yan. Combining Knowledge with Deep Convolutional Neural Networks for Short Text Classification. IJCAI, 2017.

[13] J Chen, Y Hu, J Liu, Y Xiao, H Jiang. Deep short text classification with knowledge powered attention. AAAI,2019.

[14] H Ren, L Yang, E Xun. A sequence to sequence learning for Chinese grammatical error correction. NLPCC,2018.

[15] Y Hong, X Yu, N He, N Liu, J Liu. FASPell: A Fast, Adaptable, Simple, Powerful Chinese Spell Checker Based On DAE-Decoder Paradigm. EMNLP, 2019.

[16] I Antonellis, H Garcia-Molina. Simrank++ query rewriting through link analysis of the clickgraph. WWW’08.

[17] G Grigonytė, J Cordeiro, G Dias, R Moraliyski. Paraphrase alignment for synonym evidence discovery. COLING,2010.

[18] X Wei, F Peng, H Tseng, Y Lu, B Dumoulin. Context sensitive synonym discovery for web search queries. CIKM,2009.

[19] S Zhao, H Wang, T Liu. Paraphrasing with search engine query logs. COLING, 2010.

[20] X Ma, X Luo, S Huang, Y Guo. Multi-Distribution Characteristics Based Chinese Entity Synonym Extraction from The Web. IJISA, 2019.

[21] H Fei, S Tan, P Li. Hierarchical multi-task word embedding learning for synonym prediction. KDD,2019.

[22] M Qu, X Ren, J Han. Automatic synonym discovery with knowledge bases. KDD,2017.

[23] J Shen, R Lyu, X Ren, M Vanni, B Sadler. Mining Entity Synonyms with Efficient Neural Set Generation. AAAI,2019.

[24] A Vaswani, N Shazeer, N Parmar. Attention is all you need. NIPS, 2017.

[25] Berant J, Chou A, Frostig R, et al. Semantic Parsing on Freebase from Question-Answer Pairs. EMNLP,2013.

[26] Cai Q, Yates A. Large-scale Semantic Parsing via Schema Matching and Lexicon Extension. ACL,2013.

[27] Bordes A, Chopra S, Weston J. Question answering with subgraph embeddings. arXiv,2014.

[28] Dong L, Wei F, Zhou M, et al. Question Answering over Freebase with Multi-Column Convolutional Neural Networks. ACL,2015.

[29] E Malmi, S Krause, S Rothe, D Mirylenka. Encode, Tag, Realize: High-Precision Text Editing. arXiv, 2019.

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