?

【前沿重器】

全新欄目，那么欄目主要給大家分享各種大廠、頂會的論文和分享，從中抽取關鍵精華的部分和大家分享，和大家一起把握前沿技術。具體介紹：倉頡專項：飛機大炮我都會，利器心法我還有。

往期回顧

• 前沿重器[1] | 微軟小冰-多輪和情感機器人的先行者

• 前沿重器[2] | 美團搜索理解和召回

• 前沿重器[3] | 平安智能問答系統
  

• NLP.TM[38] | 對話系統經典：檢索式對話

• SIGIR20最佳論文：通往公平、公正的Learning to Rank！

說起搜索，騰訊騰訊應該并不算領先，但是受益于這篇來自騰訊的分享，我們來看看騰訊的研究成果，看看如何完整地理解用戶的搜索Query，并找到用戶需要的東西。

先把分享放在這里：https://zhuanlan.zhihu.com/p/112719984，來自騰訊技術工程。

懶人目錄：

• 搜索工程架構

• Query理解

• • 預處理

  • 分詞

  • 改寫

  • term分析

  • 意圖識別

  • 其他操作

• Query理解結果的應用

• • BS需求

  • 排序需求

• 小結

搜索工程架構

搜索的場景有很多，有QQ音樂、愛奇藝視頻、應用寶等垂域的搜索，也有百度、頭條、微信等搜索的開放域大搜，隨著搜索場景的變化，架構或多或少也會有很大區別，但大都滿足一個非常通用的結構：輸入-理解-召回-排序-返回的結果，本篇分享為大家整理了一個更為詳盡的版本，大家可以參考一下：

這張圖給出了比較簡潔而又完整的架構，不僅說清楚了各個模塊如何交互，還展開了解析了各個模塊需要做的事情，我想好好研讀這張圖，大家一定會有深入的了解。

這張圖足夠清晰，我不需要做太多的重述，我認為更需要了解的是架構設計背后考量的因素和原理。我認為主要有如下幾個點需要展開討論一下，當然有新的理解歡迎評論區留言交流：

• 特地單獨劃分client層主要是因為有很多query可以采用更加基金的方式處理，如直達等，這些query的意圖非常明確，不需要重走大量的流程，通過詞典等方式快速配置快速完成，能給到用戶極致的體驗。

• AS(advanced search)和BS(base Search)雖都為搜索但是兩者有所區別，前者追求更豐富的語義把控，而后者則直面檢索，通過文本、意圖、語義等方式構造多種檢索邏輯完成搜索過程，直接請求的就是底層的搜索引擎（如大家熟悉的Elastic Search，當然還有比較新潮的向量召回引擎Faiss），兩者關注點不同。從流程上看，BS應該是AS的一部分。

• 搜索是一個在線互聯網產品，但是其離線的工作并不比在線要輕松，無論是用戶側的行為、query記錄和處理還是物料的存取處理，都有非常多的任務，這些工作的直接體現就是BS檢索的對象以及算法計算的特征。

• 和推薦一樣，使用的同樣是“召回-排序”的二段結構，召回階段盡可能保證需要的內容能夠被找到，排序階段則負責把更加“相關”的內容展示給用戶，而在這里，統一都是BS負責管理。

Query理解

Query理解已經不是我第一次聊了，這篇文章也能看到Query理解的操作有哪些。雖然如此，這篇文章還是刷新了我的理解，無論是方法還是操作上都有不少的新東西。首先看一個pipline圖：

圖就不細說了，直接展開來講吧。

預處理

預處理的操作還是比較統一的，來來去去其實也就是這些事：

• 大小寫。

• 半全角。

• 繁簡體。

• 標點符號。

• 長度截斷。

分詞

搜索分詞要是想做復雜，其實可以很復雜，絕對不是jieba那么簡單，在特定場景下需要定制各種各樣的分析，主要考量的是這幾個的角度：

• 切詞粒度。往大的切和往小的切。“滑雪大冒險”可以是“滑雪 大 冒險”也可以是直接一個專名“滑雪大冒險”。

• 領域問題。有些可能是領域內的詞匯，我們需要注意識別，切開了反而沒有意義了，上面滑雪大冒險的例子也是這樣，如果在APP領域就不能切開。

• 新詞發現。對于時效性比較高的搜索引擎，如微博等，需要快速識別新詞以免由于切詞錯誤導致下游無法搜索，如近期有的“水門弄斧”。

有關具體里面的方法，其實都還比較基礎，復雜的模型也有但是在這塊花費寶貴的耗時意義并不大，所以基于詞典和簡單的機器學習（HMM/CRF）之類的就能能夠達到目標了，新詞發現的話左右熵之類的就能快速挖掘出來。

改寫

改寫應該是一個比較復雜的工作了，在文章中主要分為3種情況：

• 糾錯。針對句子中出現的錯誤進行修改。這塊的方法我曾經寫了不少文章討論了。（NLP.TM[37] | 深入討論糾錯系統）

• 歸一。某些內容有很多說法，把他們統一化有利于下游更加快速的搜到。實質上是一個同義詞挖掘和同義句征程的過程，這個來源于挖掘積累，甚至是一些知識庫的建立可以完成，按照文中的說法就是一個“積累”的過程。

• 拓展。這個主要通過用戶行為進行挖掘即可完成基線，后續通過這些平行樣本做一些語義相似度的訓練，再用annoy等方式做query的向量召回也很方便。

term分析

term分析是我自己比較熟悉的領域了，這一步的目標是深入到句子中的詞匯中進行分析，包括實體抽取、重要性分析、緊密度分析等。

緊密度分析，我的理解，往難聽的說，來源于對切詞的一種不信任，往好聽的說就是對切詞具有更高的靈活性要求，切詞很可能對某些詞匯切得太散，所以需要緊密度分析把他們都合并起來，這種合并在后續構造檢索語法樹的時候（可以理解為檢索語法構建）會發揮很大作用，例如上面的“滑雪大冒險”，合并以后，簡單的“滑雪”的東西其實就不會出來了，這樣對提升精準度很有好處。

有關重要性分析，我之前也有文章提到過，簡單的基于TF-IDF、textrank之類的方式就能輕松處理，而復雜的用序列標注的方式處理也是有的，在這篇分享里，作者列舉了很多可以用到的特征可供大家選擇，至于模型則可以考慮BiLSTM+Attention（個人感覺attention本身已經是一種詞權重計算）、Seq2Seq/Transformer：

term詞性、長度信息、term數目、位置信息、句法依存tag、是否數字、是否英文、是否停用詞、是否專名實體、是否重要行業詞、embedding模長、刪詞差異度、前后詞互信息、左右鄰熵、獨立檢索占比（term單獨作為query的qv/所有包含term的query的qv和）、iqf、文檔idf、統計概率 以及短語生成樹得到term權重等

實體識別（或者叫做槽位）在美團內把它歸為term分析的一種，而在這篇騰訊的文章中則把它歸到意圖分類下的，當然這一方面取決于個人理解以及架構的設計。這個我也已經寫過，此處也不贅述。

• 前沿重器[2] | 美團搜索理解和召回

• R&S[24] | 淺談Query理解和分析

意圖識別

意圖識別在本文被成為query理解中最重要卻也最具挑戰的模塊，并列舉了原因：

• 用戶輸入不規范。

• 歧義與多樣性。

• 用戶的個性化差異。

好了來談談意圖識別的操作。這里作者分為了2種，一種是精準意圖，另一種是模糊的。前者我們只需要把他需要的放在他面前就好了，后者則需要更復雜的理解操作來保證返回的內容盡可能滿足用戶的需求。

精準意圖來源于用戶非常明確且高頻的需求，如“下載王者榮耀”，這種唯一且精準的意圖，如果同樣采用模糊的方式去做，很可能因為個性化、物料的相似性而導致錯誤，但這個又是高頻精準需求，所以我們需要更好地保護，這種問題可以把它歸為QA，即問答來處理，一般做法其實來源于搜索（套娃？？），兩套思路，分別是query理解+檢索和語義召回，可以去召回與他相近的query這些都是一些常見的高頻精準query，可以直接去整。這些操作有的地方也被叫做搜索直達，是一種非常激進的策略。

對于模糊意圖，我們就需要步步為營，扎實理解好用戶的意思，這就需要借助意圖分類（可抽象為文本分類）和槽位提取（命名實體識別）來做了。

其他操作

文章還提到了兩個工作：敏感識別和時效性分析。

敏感識別來源于對用戶輸入內容的不信任和對開放域物料的不信任，說白了用戶可能輸入黃反的東西，物料里也可能存在踩雷的東西，保證物料里面沒有壞東西和保證用戶輸入沒有壞東西都很重要，簡單的可以用詞典做匹配，當然復雜的還要結合語義分析，采用文本分類的方式來處理（個人經驗來看文本分類能解的其實詞典也可以額，類似弓雖女干的其實模型也很難覆蓋）有很多很邊緣的可能至今也不太好處理，所以現在的主流還是以可控性、準確性見長的詞典。

至于時效性分析則也是一個復雜的問題，作者舉的例子是同樣是“最近上映的好看電影”、“疫情進展”之類的，在不同時間則會有不同的結果，作者將此類問題拆解成3種：持續時效性（“美食推薦”），周期時效性（“世界杯”），準/實時時效性（微博熱搜之類的）來進行針對性的處理。

Query理解結果的應用

本節并未在文章單獨提出，但是個人認為應該結合搜索工程架構和Query理解及其在其中的位置來詳細討論下。

BS需求

BS就是基礎檢索（base search），說著玄乎了，說簡單點，計算機頂層再怎么智能底層也是非常頭腦簡單的，就是我們要在數據庫里面找東西，需要構造一個類似SQL的檢索邏輯才能夠找到最優解，當然我們有特定的一些方式能讓你搜得更快（構建索引），但是終究要構造那特定的形式才能完成搜索，所以我們需要充分理解Query，轉化為計算機可以理解的格式才能夠完成BS。

最傳統的方式就是提槽、判斷意圖然后構造檢索語法樹來進行搜索，舉個例子，query“唐人街探案的主角是誰”，我們要判斷是一個百科意圖或者是電影意圖，然后按照類似“select actor from baike where type='movie' and item_name='唐人街探案'”的邏輯去進行搜索才行，所以我們要做query理解，進一步的我們通過詞權重找到句子的關鍵詞來協助進行相關性排序。另一方面，由于是文本匹配，如果數據庫里面是“肯德基”而用戶輸入“KFC”，那也是無法匹配到的，所以我們也需要大量的改寫邏輯。

復雜的，現在近鄰索引也逐步發展，于是有了ball tree、annoy、hsnw這些以樹或者以圖為基礎的索引，于是向量檢索也成為了可能，通過語義向量召回的方式也能夠召回一些內容，但首先我們也是需要通過向量生成模型來對他們進行向量化對吧，所以也是需要query理解模塊。

排序需求

有了BS的召回結果，結果很多，我們如何排序呢，光靠語義相似度就夠？肯定不可，我們要看召回的內容里特定的槽位有沒有滿足，意圖有沒匹配，還要涉及query里面關鍵詞的重要度、流行度等等，語義相似度需要從一個排序模型降級為一個特征，這么多的特征結合機器學習就能有遠優于語義相似度的效果（當然也可以以語義相似度為base添加其他特征concat起來也可，推薦不就是這么玩的么，狗頭），所以，query理解是真的很重要。

小結

Query理解可以說是搜索引擎體現人工智能的最關鍵的一個模塊了，也是算法所需要去關注的一個核心點，足夠深入的理解和解析query，我們還能夠挖掘出更加深層次的東西，從字面的簡單需求到延伸隱含的需求，這樣就，能成為肚子里的蛔蟲了~

總結

以上是生活随笔為你收集整理的前沿重器[4] | 腾讯搜索的Quer理解如何直击心灵的全部內容，希望文章能夠幫你解決所遇到的問題。

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