目錄：
（1）基於規則
（2）基於窮舉
（3）基於分類模型
query糾錯、【query rewrite】
query 詞自動提示、【query相關性計算】
query擴展，【query相關性計算】
query自動分類、【query類目預測】
語義標簽。【query tagging】
一、簡介：
1、概念：
什么是用戶意圖識別？
就是讓搜索引擎能夠識別出與用戶輸入的查詢最相關的信息，例如用戶輸入查詢“仙劍奇俠傳”時，我們知道“仙劍奇俠傳”既有游戲又有電視劇還有新聞、圖片等等，如果我們通過用戶意圖識別發現該用戶是想看“仙劍奇俠傳”電視劇的，那我們直接把電視劇作為結果返回給用戶，就會節省用戶的搜索點擊次數，縮短搜索時間，大大提升使用體驗。
意識識別要做什么？(分類）
比如在我們熟悉的搜索，我們搜索的時候如果涉及到一條信息對應多個分類的時候，這樣搜索結果會比較差，但是如果我們通過意圖識別發現用戶是個游戲迷，我們就可以在用戶搜索時將游戲的搜索結果優先返還給用戶，這本身也是很有意義的一件事。
通用搜索和垂直搜索：
通用搜索是抓取互聯網上的頁面，以索引和關鍵字匹配的形式，把網頁的標題、摘要、URL等信息展示出來。google, 百度，搜狗，搜搜，有道
垂直搜索則針對某一特定領域，搜索結果也只限定在該領域內，例如商品搜索、招聘搜索、 機票搜索，地圖搜索，購物搜索（一淘）等，一個例子見圖1：
因為垂直搜索已經將用戶的意圖限定在以特定領域了，因此搜索結果的准確率也很高。那如何在通用領域也能做到了解用戶的搜索需求即意圖呢？那就需要用到意圖識別的技術了。
2、用戶意圖識別的難點
-
用戶輸入不規范，輸入方式多樣化，使用自然語言查詢，甚至非標准的自然語言。比如上面提到的“附近的特價酒店” 、“上海到揚州高速怎么走”都是自然語言查詢的例子，又如 “披星 ( ) 月”、“吾嘗終日而思矣, 下面“
-
用戶的查詢詞表現出多意圖，比如用戶搜索“變形金剛”，是指變形金剛的電影還是游戲？
如：仙劍奇俠傳
游戲？--> 游戲軟件？……
電視劇？--> 電視劇下載？相關新聞？……
電影？--> 電影下載？查看影評？劇情介紹？……
音樂？--> 歌曲下載？在線聽歌？歌詞下載？……
小說？--> 小說下載？在線觀看？…… -
意圖強度，表現為不同用戶對相同的查詢有不同的需求強度。比如：宮保雞丁。宮保雞丁菜，菜譜需求占 90%。宮保雞丁歌曲，歌曲下載需求占 10%。又比如：荷塘月色。荷塘月色歌曲，歌曲下載需求占 70%。荷塘月色小區，房產需求占 20%。荷塘月色菜，菜譜需求占 10%。
-
意圖存在時效性變化，就是隨着時間的推移一些查詢詞的意圖會發生變化。比如：華為 P10 國行版 3 月 24 日上市。3 月 21 日的查詢意圖：新聞 90%，百科 10%3 月 24 日的查詢意圖：新聞 70%，購買 25%，百科 5%5 月 1 日的查詢意圖：購買 50%，資訊 40%，其他 10%5 年以后的查詢意圖：百科 100%
-
數據冷啟動的問題，用戶行為數據較少時，很難准確獲取用戶的搜索意圖。
-
沒有固定的評估的標准，CTR、MAP、MRR、nDCG 這些可以量化的指標主要是針對搜索引擎的整體效果的，具體到用戶意圖的預測上並沒有標准的指標。
3、用戶搜索意圖分類：
1.導航類：用戶明確的要去某個站點，但又不想自己輸入 URL，比如用戶搜索“新浪網“
2.信息類：又可以細分為如下幾種子類型,
直接型：用戶想知道關於一個話題某個方面明確的信息，比如“地球為什么是圓的”、“哪些水果維生素含量高”。間接型：用戶想了解關於某個話題的任意方面的信息，比如粉絲搜索“黃曉明”。建議型：用戶希望能夠搜索到一些建議、意見或者某方面的指導，比如“如何選股票”。定位型：用戶希望了解在現實生活中哪里可以找到某些產品或服務，比如“汽車維修”。列表型：用戶希望找到一批能夠滿足需求的信息，比如“陸家嘴附近的酒店”。
3.資源類：這種類型的搜索目的是希望能夠從網上獲取某種資源，又可以細分為以下幾種子類型,
下載型：希望從網絡某個地方下載想要的產品或者服務，比如“USB 驅動下載”。娛樂型：用戶出於消遣的目的希望獲得一些有關信息，比如“益智小游戲”。交互型：用戶希望使用某個軟件或服務提供的結果，用戶希望找到一個網站，這個網站上可以直接計算房貸利息。獲取型：用戶希望獲取一種資源，這種資源的使用場合不限於電腦，比如“麥當勞優惠券”，用戶希望搜到某個產品的折扣券，打印后在現實生活中使用。
4、意圖識別的方法：
因為意圖識別本身也是一個分類問題，其實方法和分類模型的方法大同小異。
常用的有：
一種是基於規則模板的分類方法，這種方法比較適用於查詢非常符合規則的類別，通過規則解析的方式來獲取查詢的意圖。比如：今天天氣怎么樣， 可以轉化為 [日期][實體: 天氣][詢問詞: 怎么樣]上海到曼谷的機票價格， 可以轉化為 [地點] 到 [地點][機票 / 車票 / 火車票] 價格
如：236.2美金能換多少RMB？
[236.2][美金][今天]能換多少[人民幣]?
[數字][貨幣單位][日期]能換多少[貨幣單位]?
★通過知識圖表，來替換/對應/歸一
解析：
數量：236.2
源貨幣：美元（不再是“美金”）
目的貨幣：人民幣
★配合自己建立的一些語言模型，可以比較好的解決召回率比較低的問題
模型訓練的比較好的話，相對召回也很不錯
但是比如購物啊什么的，是無法做這種信息模型的
這種方法的對比較明確的規則性強的方式有精確的識別度，缺點是覆蓋度低，用戶查詢稍作變換可能就不 match 了，另外規則的發現和制定主要靠人工進行。
這種方法最簡單暴力，通過詞表直接匹配的方式來獲取查詢意圖，同時，也可以加入比較簡單並且查詢模式較為集中的類別。
查詢詞：德國[addr] 愛他美[brand] 奶粉[product] 三段[attr]
查詢模式：[brand]+[product];[product]+[attr];[brand]+[product]+[attr]
當然查詢模式是可以做成無序的。這種意圖識別的方式實現較為簡單，能夠較准確的解決高頻詞。由於query一般是滿足20/80定律，20%的query占據搜索80%的流量。但是，80%得長尾query是無法通過這種方式來解決的，也就是說這種方式在識別意圖的召回可能只占20%。同時，需要人工參與較多，很難自動化實現。
如：北京的天氣怎么樣啊
（停用詞替換） --> [北京][天氣][怎么樣]
（查詢詞歸一） --> {城市][關鍵詞][疑問詞]
（順序無關） --> {[城市], [關鍵詞], [疑問詞]}
這三種方式基本上是目前比較主流的方法，現在進行意圖識別的難點主要是兩點，
一點是數據來源的匱乏，因為方法已經比較固定，基本都是有監督學習，需要很多的標記數據，現在我們常用的數據要么就是找專業標記團隊去買（我們是自己標記的，很惡心。。），要么就是自己去爬，這方面還是很麻煩的。二點是盡管是分類工作，但是意圖識別分類種類很多，並且要求的准確性，拓展性都不是之前的分類可比的，這一點也是很困難的。
二、意圖識別的做法
1、數據集
意圖識別離不開數據，搜索領域的意圖識別用到的數據通常就是用戶的搜索日志了。一般一條搜索日志記錄會包括時間-查詢串-點擊URL記錄-在結果中的位置等信息。
2、數據清洗
拿到日志數據，一般是不能直接用的，里面會包含很多的噪聲數據，無用信息，我們都需要把它給清洗掉。
3、query分析
角度1：
Query的類目預測。例如搜索“運動鞋”，可能包括：男士運動鞋、女士運動鞋、兒童運動鞋等類目，預測Query所在的類目對提高搜索結果的相關性非常重要。如果能夠識別用戶或者意圖是男性還是女性，搜索結果又可以去掉很多不相關的類目。
Query的相關性計算。用於下拉補全詞推薦、相關詞推薦。不過補全詞和相關詞推薦在產品上是不同的。補全詞一般要包含搜索輸入詞，更嚴格的是要以輸入的搜索詞作為前綴；而相關詞是為了幫助用戶找到自己想要的東西，是細化搜索意圖還是改變搜索意圖就值得推敲。細化意圖可以推薦下位詞。
Query Tagging。即把Query中表示顏色、性別、尺寸、材質、產品屬性詞提取出來。
Query Rewrite。搜索引擎改寫包括：同義詞、單復數的改寫，即找出等價的Query去做搜索。如果把糾錯也當成是改寫
角度2：
查詢意圖理解的過程就是結合用戶歷史行為數據對 query 進行各種分析處理的過程，包括
query糾錯、【query rewrite】
query 詞自動提示、【query相關性計算】
query擴展，【query相關性計算】
query自動分類、【query類目預測】
語義標簽等。【query tagging】
下面這張圖是一個具體的例子說明 query understanding 的工作過程
稍微解釋一下這張圖：
-
-
用戶的原始 query 是 “michal jrdan”
-
Query Correction 模塊進行拼寫糾錯后的結果為：“Michael Jordan”
-
Query Suggestion 模塊進行下拉提示的結果為：“Michael Jordan berkley”和 “Michael Jordan NBA”，假設用戶選擇了“Michael Jordan berkley”
-
Query Expansion 模型進行查詢擴展后的結果為：“Michael Jordan berkley”和 “Michael I. Jordan berkley”
-
Query Classification 模塊進行查詢分類的結果為：academic
-
最后語義標簽（Semantic Tagging）模塊進行命名實體識別、屬性識別后的結果為：[Michael Jordan: 人名][berkley:location]:academic
-
Query Correction 模塊，也即查詢糾錯模塊。
對於英文，最基本的語義元素是單詞，因此拼寫錯誤主要分為兩種：一種是 Non-word Error，指單詞本身就是拼錯的，比如將“happy”拼成“hbppy”，“hbppy”本身不是一個詞。另外一種是 Real-word Error，指單詞雖拼寫正確但是結合上下文語境確是錯誤的，比如“two eyes”寫成“too eyes”，“too”在這里是明顯錯誤的拼寫。
而對於中文，最小的語義單元是字，往往不會出現錯字的情況，因為現在每個漢字幾乎都是通過輸入法輸入設備，不像手寫漢字也許會出錯。雖然漢字可以單字成詞，但是兩個或以上的漢字組合成的詞卻是更常見的語義元素，這種組合帶來了類似英文的 Non-word Error，比如“大數據”寫成“大樹據”，雖然每個字是對的，但是整體卻不是一個詞，也就是所謂的別字。
query 糾錯的具體方案有：
-
-
基於編輯距離
-
基於噪聲信道模型
-
Query Suggest 模塊,也即輸入下拉提示
根據用戶輸入的查詢詞前綴自動提示用戶最有可能輸入的完整查詢詞列表。
這里涉及幾個問題：
-
-
Suggest 詞條來從哪里來
-
如何根據當前的輸入快速匹配到候選 suggest 詞條列表
-
如何對候選 suggest 詞條列表進行排序
-
suggest 詞條通常主要來自用戶搜索歷史 query log，但存在數據冷啟動的問題，開始時缺少 query log 時如何處理？對於一些垂直的應用場景，比如小說搜索中，suggest 詞條也可以是作品的標題、標簽、作家名等，電商搜索中可以是品牌詞庫、產品列表等。
對於 suggest 詞條列表的存儲結構與快速匹配，如果 suggest 詞條列表不是很大，Trie 樹（又稱字典樹）是一個不錯的選擇，用 Trie 樹實現的主要優點是利用字符串的公共前綴來降低查詢時間的開銷以達到提高效率的目的，實現也比較簡單，但缺點是節點數增加到一定程度內存開銷會成為瓶頸。如果 suggest 詞條列表很大，可以選擇 Ternary Tree(又稱三叉搜索樹)， 三叉搜索樹對 Trie 的內存問題（空的指針數組）進行了專門優化，具體細節大家可以 google，這里不再深入。
Suggest 候選詞的排序通常根據候選詞項的整體熱門指數，即搜索的多的排在前面。當然實際應用場景中的排序會考慮更多的排序因素，比如個性化的因素，當下熱門指數等因素。
query同義詞挖掘：
在電商搜索環境中，同義詞分成好幾類：
1. 品牌同義詞：nokia=諾基亞，Adidas=阿迪達斯
2. 產品同義詞：投影儀≈投影機，電話≈cell phone; automobile 和car。
3.舊詞和新詞：自行車 -> 腳踏車
4.南方用詞和北方用詞：番茄-> 西紅柿。
5.傳統的同義詞：儲物櫃和收納櫃。
6.錯別字同義詞：瑜伽和瑜珈（錯誤寫為斜王旁）
對應英文來說，還有詞干提取，如單復數、動詞原形和ing形式；英文還有一個特殊的現象，例如兩個單詞可以分開寫，也可以合並在一起，例如keychain和key chian（鑰匙鏈），boyfriend 和boy friend。
近義詞就比較多了： 包括size 大碼≈大號；短褲和熱褲；邊疆和邊疆。
上位詞：蘋果手機上位詞 是手機。
反義詞：寬松和修身。當我們做query改寫的時候，改寫千萬不能改寫出反義詞。
如果我們仔細觀察，我們會發現有的詞可以互相替換，有些詞是只能單向替換（換一個方向就不對了，例如周傑倫可以替換為周董，但是周董只能在一定情況下替換為周董）。
如何挖掘同義詞？
我們可以從用戶搜索詞、商品標題、搜索和點擊來獲取。最根本的來源還是商家對商品標題的優化，聰明的商家會把同義詞堆疊在標題中，以期望獲取到更多的流量。
從點擊日志上看，如果w1和w2是同義詞，那么搜索w1和搜索w2，理論上會有大量的共同點擊的商品x1、x2、x3等等。
標題商品標題得到大量的語料，例如投影儀和投影機，拉桿箱(draw bar box)和旅行箱(luggage)。
通過統計或者word2vec訓練詞的相關性，找到高相關度的詞。統計這些詞在標題中共同出現次數，即w1和w2的共現次數。
通過word2vec，我們可以找出原始詞和最相似的10個單詞，然后我們統計origin 和substitute（原始詞和替代詞）在標題中的共現次數，通過這種挖掘，我們找到大量的候選詞對，這種詞通過人工review可以作為同義詞的候選。
對這種情況稍微做一些擴展，我們就能得到同義query到同義query之間的對應關系。
統計分析上位詞，統計每個商品類目下的產品詞，出現次數top n的產品詞w，對應到商品的類目詞c，那么w -> c很可能 就是一個上位詞關系。
query 相似性計算：
https://blog.csdn.net/poson/article/details/85922519
1、計算兩個query的編輯距離
2、計算兩個query（x和y）在session中的互信息，PMI(x,y)=p(x,y)/(p(x)*p(y))
例如QA有一個點擊的商品集合，QB有兩個點擊的商品集合，用點擊數量或者點擊率作為商品的權重來設計一個向量，這樣兩個Query就可以通過cosin(vector(QA),vector(QB)) 來計算相關性。還有比較簡單的方法是計算兩個Query(x和y)在session 中的互信息，PMI(x,y)=p(x,y)/(p(x)*p(y))
3、協同過濾
把query和點擊item作為一個評分矩陣，按照協同過濾的方法來計算相關性。由於協同過濾沒有考慮點擊的次數信息，因此推薦詞的點擊次數和原始詞的搜索次數、長度可能不夠匹配，還需要很多方法來糾正。
4、稀疏
由於點擊數據受到搜索結果的影響，由於排序質量的問題，點擊的位置bias，有很多辦法來糾正；以及部分Query的點擊比較稀疏，商品的點擊比較稀疏。
例如simrank，simrank++（http://www.vldb.org/pvldb/1/1453903.pdf）等算法。
前阿里媽媽的yangxudong 文章里面有mapreduce 的實現：https://blog.csdn.net/yangxudong/article/details/24788137 。主要是基於分塊矩陣的計算。實現中利用二次排序，做了不少優化。
另外github 上面有兩個代碼：
（1）https://github.com/thunderain-project/examples 其部分代碼無法通過編譯。
（2）https://blog.csdn.net/dengxing1234/article/details/78933187 編譯通過，少量數據可以通過編譯，大量數據還無法跑得結果。
5、用商品向量來表示Query，也有一些方法借鑒了simrank和向量的思想，用詞向量來表示Query和Title。
例如yahoo研究院的這篇論文《Learning Query and Document Relevance from a Web-scale Click Graph》。
6、DSSM（cikm2013）https://www.cnblogs.com/baiting/p/7195998.html
把Query 先和Title 先分別用word hash 到一個3萬維的空間，然后一層層embedding 到一個128維的向量， 最后可以簡單的用cosin來計算相似性。
7、一個用戶在一個session中點擊的商品序列可以用來做embedding ，得到商品id到embedding vector。
同時我們可以可以考慮把用戶在一個session中輸入的Query當成序列來做embedding 。按照這個思路找了一下論文，果然2018年有人用這個想法寫了論文。《Querying Word Embeddings for Similarity and Relatedness》http://aclweb.org/anthology/N18-1062
We tested vector spaces with varying dimensionalities (dim=100/200/300) and number of context words (win=3/6/10), as well as minimum occurrence cutoff (min=1/5), negative samples (neg=1/5) and iterations (iter=1/5). These variations were tested to ensure the observed patterns reported in the experiments, but we report numerical results only for best performing models. In particular, higher dimensional vectors with dim=300 produced consistently better alignment with human scoring data. We also found min=1, neg=5 and iter=5 to be the optimal parameter settings across all experiments.
8、目前圖計算有很多方法。
我們嘗試了用node2vec的方法來計算Query的相似性，也取得了非常好的效果。即把query和item 的二部圖上面做node2vec。
另外准備嘗試用阿里媽媽的euler平台里面的圖embedding方法來計算節點之間相關性。
Query Expansion 查詢擴展模塊
查詢詞擴展技術通過將與用戶查詢詞相近、相關的詞擴展到用戶查詢詞中的方法, 更准確地描述用戶的信息需求, 去除用戶查詢詞的多義性, 從而更精確地查詢用戶所需信息。在信息檢索技術中, 查詢詞擴展是一種能夠有效提高查詢效率的技術。通過用戶搜索日志和點擊日志可以挖掘出查詢擴展詞。
我們在實踐中采用一種基於搜索日志會話局部上下文和全局上下文為語料庫使用 word2vec 構建 skip-gram 詞向量模型，根據詞向量模型可以取得與查詢詞最相似的前 N 個詞構成初步的相關候選詞表，然后再利用 K 近鄰算法從相關詞候選詞表選取出語義最相關的候選詞作為查詢詞的擴展詞。
搜索日志會話局部上下文是指與當前 query 在同一個會話上下文中的共現 query, 也是用戶對 query 的查詢重構，比如初始 query 為“變形金剛”，用戶在查詢會話中可能將 query 變換為 “變形金剛電影”進行搜索，則“變形金剛電影”為原始 query 的局部上下文。
query 的全局上下文挖掘思路：
根據查詢詞和查詢所點擊的結果構建二部圖，利用隨機游走模型計算出每個查詢詞的文檔分布作為查詢詞的查詢向量，再利用 KL 距離來計算兩查詢向量之間的相似性。
上面提到，意圖識別可以看成是文本分類的問題，但是只依賴查詢串是肯定不行的，提供的信息太少太少，所以常做的就是考慮利用先前的搜索日志信息，例如歷史查詢串對應的標題、時間、近義詞等信息。有的場景下還會加入地點信息，例如地圖搜索。
一些可以用來擴展的信息有：
（1）點擊標題。通常在搜索日志中，會以一個session為單位，一個session中保存的是一個時間段內的相關搜索信息，我們可以用的信息字段是查詢串-點擊標題-點擊次數-時間等，在不同session的同一查詢可能對應的點擊記錄不一樣，我們可以把它們合並起來，將標題放到查詢文檔中；
（2）相似查詢串。同樣，同一點擊記錄的不同查詢我們也可以拿來用的；
（3）此外，同義詞詞林、利用word2vec得到的近義詞集合都可以擴展進來。
這樣我們就可以得到一個信息比較豐富的查詢文檔了。值得注意的是，同一session下的不同查詢，如果有遞增關系，說明用戶在根據搜索結果進行修正查詢，那么新增的詞應該對意圖分類作用很大，例如圖
Query Classification 查詢意圖分類模塊
在關鍵詞做類目預測之前可以做一個預處理提高准確率。如query歸一化、糾錯、去除價格區間詞、中英文翻譯對照等等。
通常有基於規則模板的分類方法和基於機器學習的分類方法。
- 通過pair <商品標題詞,類目> ，統計關鍵詞和類目的共現關系
- 統計用戶搜索Query，然后在結果集中點擊的商品的集合，統計商品類目的分布。注意這里的Query的term要全部在命中的商品標題中出現，而不是部分出現。
- 用分類算法的方式，樣本是<商品的標題詞，類目>，<Query，點擊的商品類目>。使用適合多分類的算法分類：最大熵、FastText、TextCNN、BI-LSTM + attention等算法。
1、一種是基於規則模板的分類方法，
這種方法比較適用於查詢非常符合規則的類別，通過規則解析的方式來獲取查詢的意圖。比如：今天天氣怎么樣， 可以轉化為 [日期][實體: 天氣][詢問詞: 怎么樣]上海到曼谷的機票價格， 可以轉化為 [地點] 到 [地點][機票 / 車票 / 火車票] 價格
這種方法的對比較明確的規則性強的方式有精確的識別度，缺點是覆蓋度低，用戶查詢稍作變換可能就不 match 了，另外規則的發現和制定主要靠人工進行。
2、另一種是基於機器學習分類的方法。
如果有確定的查詢類別體系，基於機器學習的查詢意圖分類是一個不錯的選擇，可以選擇 SVM 作為分類器，關鍵在分類特征的選擇, 還有訓練樣本的准確標注。
這個和我們之前參加過的 2014 ACM CIKM 競賽的問題類似，那年 CIKM 競賽的題目是自動識別用戶的查詢意圖（Query Intent Detection，QID）：給定一批標注過類別的搜索日志包括查詢日志和點擊日志作為訓練樣本，其中也有部分未標注的，類別為 unknown。
在特征的選擇方面，除了基本的 Query 的長度、Query 的頻次、Title 的長度、Title 的頻次、BM-25、Query 的首字、尾字等，我們通過對 log session 上下文的分析，進行了 Query 間特征詞匯的挖掘，運用了 query 在相同 session 中的共現關系，挖掘 query 之間的子串包含關系，query 和點擊的 title 之間的文本特征關系等。
在分類模型的選擇方面，我們選擇了 Ensemble 框架。Ensemble 的基本思想是充分運用不同分類算法各種的優勢，取長補短，組合形成一個強大的分類框架。不過 Ensemble 不是簡單的把多個分類器合並起來結果，或者簡單將分類結果按固定參數線性疊加 (例如不是 a1 * ALGO1 + a2 * ALGO2 + a3 * ALGO3)，而是通過訓練 Ensemble 模型，來實現最優的組合。
在 Ensemble 框架下，我們分類器分為兩個 Level: L1 層和 L2 層。L1 層是基礎分類器，L2 層基於 L1 層，將 L1 層的分類結果形成特征向量，再組合一些其他的特征后，形成 L2 層分類器（如 SVM）的輸入。這里需要特別留意的是用於 L2 層的訓練的樣本必須沒有在訓練 L1 層時使用過。
Semantic Tagging 模塊
這個模塊主要是對 query 中的命名實體進行識別，比如對電商搜索 query 中的品牌詞、產品詞、屬性詞、地址進行識別。對 query，用一個相對准確的詞典 (品牌詞 / 產品詞 / 屬性詞 / 地址詞) 去標注語料。
比如對於 ”新西蘭安佳奶粉二段“ 標注語料如下所示：新 B-loc 西 I-loc 蘭 I-loc 安 B-brand 佳 I-brand 奶 B-product 粉 I-product 二 B-attr 段 I-attr實體詞識別模型可以通過 crf 來進行訓練。
至此，第二部分 如何識別用戶搜索意圖 也講完了總結一下，我們首先簡單說明了用戶搜索意圖的主要分類：導航類、信息類、資源類，然后對搜索意圖識別的主要功能模塊查詢糾錯、查詢詞自動提示、查詢擴展，查詢自動分類、語義標簽等實現思路分別進行了介紹。
Term Weight
中文自然語言處理的第一步就是分詞，分詞的結果中，每個詞的重要性顯然應該時候區別的。Term Weight就是為了給這些詞不同的打分，根據分值就可以判斷出核心詞，進而可以應用到不同的場景。比如，有一個商品的標題為“碗裝保溫飯盒套裝”，通過Term Weight可以得到核心詞為“飯盒”。當用戶搜"碗"召回這個商品的時候，是可以根據term weight來進行排序降權的。
4、特征工程
把上面擴展得到的查詢文檔利用tfidf向量化，就可以得到一個特征向量，一般情況下，這個特征向量維度會非常高，我們可以利用詞頻、卡方、互信息等方法進行特征選擇，保留更有用的特征信息。
我們還可以加入一些數字特征在里面，例如：
（1）Query的長度
（2）Query的頻次
（3）Title的長度
（4）Title的頻次
（5）BM-25
（6）Query的首字、尾字等
對 log session 上下文的分析，
進行了 Query 間特征詞匯的挖掘，
運用了 query 在相同 session 中的共現關系，
挖掘 query 之間的子串包含關系，
query 和點擊的 title 之間的文本特征關系
一些統計特征也可以考慮，例如論文【2】
提到的不同頁面點擊數DPCN（Different Page Click Number）、異源頁面點擊數PCNS（Page Click Number without Subpage）等，其中：
（1）不同頁面點擊數DPCN，表示用戶對查詢串的返回結果的點擊情況統計，因為作者統計發現對於導航類查詢，用戶目標很明確，通常只點擊一兩個網頁就完成查詢了，而對應信息事務型則點擊的不同頁面數目比較多，例如作者統計顯示當不同頁面點擊數不大於7時，查詢串中導航意圖的占66.7%，大於7時，信息事務意圖的占83%。
（2）異源頁面點擊數PCNS，表示查詢串的返回結果中，以點擊頻次最高的網頁為基准，不同頁面點擊數與其子頁面數量的差值。例如對於某個查詢串w，不同頁面點擊數DPCN為17，而點擊頻次最高的網頁子網頁出現了15次，那么異源頁面點擊數就為17-15 = 2，這樣做的目的是為了消除將同一網頁的子頁面算成不同頁面的情況。
5、分類器訓練
在完成特征任務后，接下來就是選擇合適的分類器進行訓練了，因為意圖識別可以看作是一個多分類任務，所以通常可以選擇SVM、決策樹等來訓練分類器。
三、應用場景：
先說一下Query分析。
最下層詞語，比如說搜索五道口附近的鋼鐵俠3，最上面就會做一些成分識別。
成分是根據業務制訂的一些標准體系，比如說五道口是一個地址的核心詞，附近其實是地址的修飾詞，鋼鐵俠3其實是店的核心詞，店可以理解成商家的產品，比如說電影院里面某一個電影。
再往下就是結構、主體和泛化可做的東西比較多，比如說做一些拓展，五道口可能有華聯等等，這個現在是基於圖譜來做的。
其實，這個用處非常多，比如說舉個例子，就是望京華聯搜這個可能出不來結果，但如果做一個擴展之后就可以很順利的找到它想要的一些結果。
從圖譜方面的一些東西可以很好的應用。從內容方面的話，比如說鋼鐵俠3有一些相似的電影等等，這個其實也是我們的一些泛化。
再往上會對Query做一些概念的識別，主要是電影。
以Query意圖識別做為例子。說一個Query，我們對它的類別做一個判別，比如動物園門票就是旅游，全聚德和望京是美食。我們可以分成不同的類別，這些類別有美食、電影、酒店之類的，還有很多二三級的品類。
說到這個場景之后，其實大家腦子里就可以想到這個事情怎么來做。
Query意圖識別可以轉換成機器學習多分類的問題。機器學習對一個問題有一套標准的流程，做過機器學習的都知道。首先要對問題做一個分析，要分哪一些類別，根據現狀制定一個目標。現有數據的支持是否有一些標注的辭典、數據等等，根據這個再來整理數據，比如說如果標注數據不夠怎么辦，后面會做一些介紹。特征工程需要抽取很多特征，特別是你要考慮到O2O的一些特點，需要做一些事情。特征做完之后再做模型方面的一些選擇和分析，最后做一些線下的評估，然后在線上鑲嵌看它的效果。這個流程是非常通用的。
摘出幾點，有可能和其他地方不太一樣的地方做一個介紹。首先就是訓練樣本怎么獲取，這個其實比較難，第一種是人工標注，第二種就是自動標注。思路有幾種，可以通過主動學習用模型學習，它的執行度比較高的，作為它已經有了，區分比較低的再來標一下，這樣標注的樣本量就非常多。還有Query的思想其實也是來擴充執行度比較高的樣本作為它的標注數據。
第二個問題就是特征設計，我們會把Query的一些語義的特征，Query擴充的一些信息也會融進來。說一下不一樣的，我們Query是有地域區分的，例如黃鶴樓，可能在北京搜更多的是一個酒店飯店；但如果在武漢搜的話，其實就是一個景點。模型嘗試的話，（PPT圖示）右邊就是精准化簡單的圖，中間兩層還做了文本分類的模型。
最后再說一下整體的流程。我們的分類目標就是定一些品類體系，用的話，可能就是在流量分發、統計到排序里面會用；現狀有一些辭典的，解決思路其實就是想通過機器學習的方法來解決。數據准備剛才已經介紹了，特征工程也說了一下，最后用DN加很多點，在線上我們在旅游產品上線可以提升5%的水平。
四、query線上處理：
對query的線上處理，如果是較為hot的query，可以以查表為主，可以用hash表，trie樹等進行查表，把在線下計算好的數據，通過查表的方式找到對應的結果，附加到給引擎的搜索條件上，並返回。
另外，可以把線下訓練好的模型，在線上進行預測，一般的分類算法預測速度都比較快。可以對長尾的query，進行及時的預測。
也可以做一些規則，如我們上面舉的例子，“1000元左右”，可以通過正則表達式進行識別，將其轉為對應的搜索條件。這些規則如何來定呢，這是比較麻煩的一點，像這類的query，肯定是pv比較低的，屬於長尾的query，這些query效果提升可能比較明顯，但是對總體搜索系統效果影響會較小。這個問題比較尷尬，如果我們這類query處理的效果好的話，那用戶會使用的更多；用戶知道了這樣的query效果不好，所以就換成了效果好的query。如果要做好規則，那就把長尾的這些query都拿出來，多看看，分下類，再結合實際的問題分類，總結出一些通用的規則，來進行優化。
參考：
https://blog.csdn.net/w97531/article/details/83892403
https://www.jianshu.com/p/718039922161
http://www.52nlp.cn/cikm-competition-topdata?hmsr=toutiao.io&utm_medium=toutiao.io&utm_source=toutiao.io
https://mp.weixin.qq.com/s/xkcQLPgFzRzQclnP9JSPDw
https://mp.weixin.qq.com/s?__biz=MzU1NDA4NjU2MA==&mid=2247486229&idx=1&sn=5c04e52b5e4cf9ff0e2ad4d5bba4925b&source=41#wechat_redirect
https://blog.csdn.net/weixin_33705053/article/details/87087191
https://www.jianshu.com/p/7db0b4a2a208
https://max.book118.com/html/2018/1016/7131141051001153.shtm
http://www.sohu.com/a/325793598_465959
http://www.chinahadoop.cn/course/122
http://www.jinciwei.cn/f775883.html
https://www.jianshu.com/p/27b61e72794c
https://www.zhihu.com/question/19895141
https://www.zhihu.com/question/19895141
https://blog.csdn.net/asialee_bird/article/details/85702874#8%E3%80%81NLP%E8%AF%AD%E8%A8%80%E6%A8%A1%E5%9E%8B