計算廣告（5）----query意圖識别

一、簡介：

1、概念：

什麼是使用者意圖識别？

就是讓搜尋引擎能夠識别出與使用者輸入的查詢最相關的資訊，例如使用者輸入查詢“仙劍奇俠傳”時，我們知道“仙劍奇俠傳”既有遊戲又有電視劇還有新聞、圖檔等等，如果我們通過使用者意圖識别發現該使用者是想看“仙劍奇俠傳”電視劇的，那我們直接把電視劇作為結果傳回給使用者，就會節省使用者的搜尋點選次數，縮短搜尋時間，大大提升使用體驗。

意識識别要做什麼？(分類）

query：“我想聽德雲社的相聲” ====> 分類：将其意圖歸類于影音需求。【類目詞，産品詞，品牌詞，型号詞，季節時間詞，促銷詞】

意圖識别其實可以看做是一個分類問題，針對于垂直産品的特點，定義不同的查詢意圖類别。可以統計出每種意圖類别下面的常用詞，對于考拉海淘而言，可以統計出類目詞，産品詞，品牌詞，型号詞，季節時間詞，促銷詞等等。對于使用者輸入的query，根據統計分類模型計算出每一個意圖的機率，最終給出查詢的意圖。但是，機器學習的方法的實作較為複雜，主要是資料擷取和更新較困難，資料的标注也需要較準确才能訓練出較好地模型。

比如在我們熟悉的搜尋，我們搜尋的時候如果涉及到一條資訊對應多個分類的時候，這樣搜尋結果會比較差，但是如果我們通過意圖識别發現使用者是個遊戲迷，我們就可以在使用者搜尋時将遊戲的搜尋結果優先返還給使用者，這本身也是很有意義的一件事。

通用搜尋和垂直搜尋：

通用搜尋是抓取網際網路上的頁面，以索引和關鍵字比對的形式，把網頁的标題、摘要、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、意圖識别的方法：

因為意圖識别本身也是一個分類問題，其實方法和分類模型的方法大同小異。

常用的有：

1：基于詞典模闆的規則分類

一種是基于規則模闆的分類方法，這種方法比較适用于查詢非常符合規則的類别，通過規則解析的方式來擷取查詢的意圖。比如：今天天氣怎麼樣，可以轉化為 [日期][實體: 天氣][詢問詞: 怎麼樣]上海到曼谷的機票價格，可以轉化為 [地點] 到 [地點][機票 / 車票 / 火車票] 價格

如：236.2美金能換多少RMB？

[236.2][美金][今天]能換多少[人民币]?

[數字][貨币機關][日期]能換多少[貨币機關]?

★通過知識圖表，來替換/對應/歸一

解析：

數量：236.2

源貨币：美元（不再是“美金”）

目的貨币：人民币

★配合自己建立的一些語言模型，可以比較好的解決召回率比較低的問題

模型訓練的比較好的話，相對召回也很不錯

但是比如購物啊什麼的，是無法做這種資訊模型的

這種方法的對比較明确的規則性強的方式有精确的識别度，缺點是覆寫度低，使用者查詢稍作變換可能就不 match 了，另外規則的發現和制定主要靠人工進行。

2：基于過往日志比對【窮舉】（适用于搜尋引擎）

這種方法最簡單暴力，通過詞表直接比對的方式來擷取查詢意圖，同時，也可以加入比較簡單并且查詢模式較為集中的類别。

查詢詞：德國[addr] 愛他美[brand] 奶粉[product] 三段[attr]

查詢模式：[brand]+[product];[product]+[attr];[brand]+[product]+[attr]

當然查詢模式是可以做成無序的。這種意圖識别的方式實作較為簡單，能夠較準确的解決高頻詞。由于query一般是滿足20/80定律，20%的query占據搜尋80%的流量。但是，80%得長尾query是無法通過這種方式來解決的，也就是說這種方式在識别意圖的召回可能隻占20%。同時，需要人工參與較多，很難自動化實作。

如：北京的天氣怎麼樣啊

（停用詞替換） --> [北京][天氣][怎麼樣]

（查詢詞歸一） --> {城市][關鍵詞][疑問詞]

（順序無關） --> {[城市], [關鍵詞], [疑問詞]}

3：基于分類模型進行意圖識别

這三種方式基本上是目前比較主流的方法，現在進行意圖識别的難點主要是兩點，

一點是資料來源的匮乏，因為方法已經比較固定，基本都是有監督學習，需要很多的标記資料，現在我們常用的資料要麼就是找專業标記團隊去買（我們是自己标記的，很惡心。。），要麼就是自己去爬，這方面還是很麻煩的。二點是盡管是分類工作，但是意圖識别分類種類很多，并且要求的準确性，拓展性都不是之前的分類可比的，這一點也是很困難的。

二、意圖識别的做法

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 的工作過程

稍微解釋一下這張圖：

1. 使用者的原始 query 是 “michal jrdan”
2. Query Correction 子產品進行拼寫糾錯後的結果為：“Michael Jordan”
3. Query Suggestion 子產品進行下拉提示的結果為：“Michael Jordan berkley”和 “Michael Jordan NBA”，假設使用者選擇了“Michael Jordan berkley”
4. Query Expansion 模型進行查詢擴充後的結果為：“Michael Jordan berkley”和 “Michael I. Jordan berkley”
5. Query Classification 子產品進行查詢分類的結果為：academic
6. 最後語義标簽（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 糾錯的具體方案有：

1. 基于編輯距離
2. 基于噪聲信道模型

Query Suggest 子產品,也即輸入下拉提示

根據使用者輸入的查詢詞字首自動提示使用者最有可能輸入的完整查詢詞清單。

這裡涉及幾個問題：

1. Suggest 詞條來從哪裡來
2. 如何根據目前的輸入快速比對到候選 suggest 詞條清單
3. 如何對候選 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、一種是基于規則模闆的分類方法，

這種方法比較适用于查詢非常符合規則的類别，通過規則解析的方式來擷取查詢的意圖。比如：今天天氣怎麼樣，可以轉化為 [日期][實體: 天氣][詢問詞: 怎麼樣]上海到曼谷的機票價格，可以轉化為 [地點] 到 [地點][機票 / 車票 / 火車票] 價格

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://blog.csdn.net/asialee_bird/article/details/85702874#8%E3%80%81NLP%E8%AF%AD%E8%A8%80%E6%A8%A1%E5%9E%8B

計算廣告（5）----query意圖識别 - 吱吱了了