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

時間 2019-11-11

標籤計算廣告 query 意圖識別简体版

原文原文鏈接

1、簡介：

一、概念：

什麼是用戶意圖識別？

就是讓搜索引擎可以識別出與用戶輸入的查詢最相關的信息，例如用戶輸入查詢「仙劍奇俠傳」時，咱們知道「仙劍奇俠傳」既有遊戲又有電視劇還有新聞、圖片等等，若是咱們經過用戶意圖識別發現該用戶是想看「仙劍奇俠傳」電視劇的，那咱們直接把電視劇做爲結果返回給用戶，就會節省用戶的搜索點擊次數，縮短搜索時間，大大提高使用體驗。

意識識別要作什麼？(分類）

query：「我想聽德雲社的相聲」 ====> 分類：將其意圖歸類於影音需求。【類目詞，產品詞，品牌詞，型號詞，季節時間詞，促銷詞】

意圖識別其實能夠看作是一個分類問題，針對於垂直產品的特色，定義不一樣的查詢意圖類別。能夠統計出每種意圖類別下面的經常使用詞，對於考拉海淘而言，能夠統計出類目詞，產品詞，品牌詞，型號詞，季節時間詞，促銷詞等等。對於用戶輸入的query，根據統計分類模型計算出每個意圖的機率，最終給出查詢的意圖。可是，機器學習的方法的實現較爲複雜，主要是數據獲取和更新較困難，數據的標註也須要較準確才能訓練出較好地模型。

好比在咱們熟悉的搜索，咱們搜索的時候若是涉及到一條信息對應多個分類的時候，這樣搜索結果會比較差，可是若是咱們經過意圖識別發現用戶是個遊戲迷，咱們就能夠在用戶搜索時將遊戲的搜索結果優先返還給用戶，這自己也是頗有意義的一件事。

通用搜索和垂直搜索：

通用搜索是抓取互聯網上的頁面，以索引和關鍵字匹配的形式，把網頁的標題、摘要、URL等信息展現出來。google, 百度，搜狗，搜搜，有道 $^{【 1 】}$

$^{【 1 】}$

由於垂直搜索已經將用戶的意圖限定在以特定領域了，所以搜索結果的準確率也很高。那如何在通用領域也能作到了解用戶的搜索需求即意圖呢？那就須要用到意圖識別的技術了。

二、用戶意圖識別的難點

用戶輸入不規範，輸入方式多樣化，使用天然語言查詢，甚至非標準的天然語言。好比上面提到的「附近的特價酒店」、「上海到揚州高速怎麼走」都是天然語言查詢的例子，又如「披星 ( ) 月」、「吾嘗終日而思矣, 下面「
用戶的查詢詞表現出多意圖，好比用戶搜索「變形金剛」，是指變形金剛的電影仍是遊戲？

                如：仙劍奇俠傳
                        遊戲？--> 遊戲軟件？……
                        電視劇？--> 電視劇下載？相關新聞？……
                        電影？--> 電影下載？查看影評？劇情介紹？……
                        音樂？--> 歌曲下載？在線聽歌？歌詞下載？……
                        小說？--> 小說下載？在線觀看？……
意圖強度，表現爲不一樣用戶對相同的查詢有不一樣的需求強度。好比：宮保雞丁。宮保雞丁菜，菜譜需求佔 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 這些能夠量化的指標主要是針對搜索引擎的總體效果的，具體到用戶意圖的預測上並無標準的指標。

三、用戶搜索意圖分類：

1.導航類：用戶明確的要去某個站點，但又不想本身輸入 URL，好比用戶搜索「新浪網「

2.信息類：又能夠細分爲以下幾種子類型,

直接型：用戶想知道關於一個話題某個方面明確的信息，好比「地球爲何是圓的」、「哪些水果維生素含量高」。間接型：用戶想了解關於某個話題的任意方面的信息，好比粉絲搜索「黃曉明」。建議型：用戶但願可以搜索到一些建議、意見或者某方面的指導，好比「如何選股票」。定位型：用戶但願瞭解在現實生活中哪裏能夠找到某些產品或服務，好比「汽車維修」。列表型：用戶但願找到一批可以知足需求的信息，好比「陸家嘴附近的酒店」。

3.資源類：這種類型的搜索目的是但願可以從網上獲取某種資源，又能夠細分爲如下幾種子類型,

下載型：但願從網絡某個地方下載想要的產品或者服務，好比「USB 驅動下載」。娛樂型：用戶出於消遣的目的但願得到一些有關信息，好比「益智小遊戲」。交互型：用戶但願使用某個軟件或服務提供的結果，用戶但願找到一個網站，這個網站上能夠直接計算房貸利息。獲取型：用戶但願獲取一種資源，這種資源的使用場合不限於電腦，好比「麥當勞優惠券」，用戶但願搜到某個產品的折扣券，打印後在現實生活中使用。

四、意圖識別的方法：

由於意圖識別自己也是一個分類問題，其實方法和分類模型的方法大同小異。

經常使用的有：

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：基於分類模型進行意圖識別

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

一點是數據來源的匱乏，由於方法已經比較固定，基本都是有監督學習，須要不少的標記數據，如今咱們經常使用的數據要麼就是找專業標記團隊去買（咱們是本身標記的，很噁心。。），要麼就是本身去爬，這方面仍是很麻煩的。二點是儘管是分類工做，可是意圖識別分類種類不少，而且要求的準確性，拓展性都不是以前的分類可比的，這一點也是很困難的。

2、意圖識別的作法

一、數據集

意圖識別離不開數據，搜索領域的意圖識別用到的數據一般就是用戶的搜索日誌了。通常一條搜索日誌記錄會包括時間-查詢串-點擊URL記錄-在結果中的位置等信息。

二、數據清洗

拿到日誌數據，通常是不能直接用的，裏面會包含不少的噪聲數據，無用信息，咱們都須要把它給清洗掉。

三、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，理論上會有大量的共同點擊的商品x一、x二、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

一、計算兩個query的編輯距離

二、計算兩個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))

三、協同過濾

把query和點擊item做爲一個評分矩陣，按照協同過濾的方法來計算相關性。因爲協同過濾沒有考慮點擊的次數信息，所以推薦詞的點擊次數和原始詞的搜索次數、長度可能不夠匹配，還須要不少方法來糾正。

四、稀疏

因爲點擊數據受到搜索結果的影響，因爲排序質量的問題，點擊的位置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 編譯經過，少許數據能夠經過編譯，大量數據還沒法跑得結果。

五、用商品向量來表示Query，也有一些方法借鑑了simrank和向量的思想，用詞向量來表示Query和Title。

例如yahoo研究院的這篇論文《Learning Query and Document Relevance from a Web-scale Click Graph》。

六、DSSM（cikm2013）http://www.javashuo.com/article/p-xpwzolbs-cp.html

把Query 先和Title 先分別用word hash 到一個3萬維的空間，而後一層層embedding 到一個128維的向量，最後能夠簡單的用cosin來計算類似性。

七、一個用戶在一個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.

八、目前圖計算有不少方法。

咱們嘗試了用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等算法。

一、一種是基於規則模板的分類方法，

這種方法比較適用於查詢很是符合規則的類別，經過規則解析的方式來獲取查詢的意圖。好比：今每天氣怎麼樣，能夠轉化爲 [日期][實體: 天氣][詢問詞: 怎麼樣]上海到曼谷的機票價格，能夠轉化爲 [地點] 到 [地點][機票 / 車票 / 火車票] 價格

二、另外一種是基於機器學習分類的方法。

若是有肯定的查詢類別體系，基於機器學習的查詢意圖分類是一個不錯的選擇，能夠選擇 SVM 做爲分類器，關鍵在分類特徵的選擇, 還有訓練樣本的準確標註。

這個和咱們以前參加過的 2014 ACM CIKM 競賽的問題相似，那年 CIKM 競賽的題目是自動識別用戶的查詢意圖（Query Intent Detection，QID）：給定一批標註過類別的搜索日誌包括查詢日誌和點擊日誌做爲訓練樣本，其中也有部分未標註的，類別爲 unknown。

在特徵的選擇方面，除了基本的 Query 的長度、Query 的頻次、Title 的長度、Title 的頻次、BM-2五、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來進行排序降權的。

四、特徵工程

把上面擴展獲得的查詢文檔利用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，這樣作的目的是爲了消除將同一網頁的子頁面算成不一樣頁面的狀況。

五、分類器訓練

在完成特徵任務後，接下來就是選擇合適的分類器進行訓練了，由於意圖識別能夠看做是一個多分類任務，因此一般能夠選擇SVM、決策樹等來訓練分類器。

3、應用場景：

先說一下Query分析。

最下層詞語，好比說搜索五道口附近的鋼鐵俠3，最上面就會作一些成分識別。

成分是根據業務制訂的一些標準體系，好比說五道口是一個地址的核心詞，附近實際上是地址的修飾詞，鋼鐵俠3實際上是店的核心詞，店能夠理解成商家的產品，好比說電影院裏面某一個電影。

再往下就是結構、主體和泛化可作的東西比較多，好比說作一些拓展，五道口可能有華聯等等，這個如今是基於圖譜來作的。

其實，這個用處很是多，好比說舉個例子，就是望京華聯搜這個可能出不來結果，但若是作一個擴展以後就能夠很順利的找到它想要的一些結果。

從圖譜方面的一些東西能夠很好的應用。從內容方面的話，好比說鋼鐵俠3有一些類似的電影等等，這個其實也是咱們的一些泛化。

再往上會對Query作一些概念的識別，主要是電影。

以Query意圖識別作爲例子。說一個Query，咱們對它的類別作一個判別，好比動物園門票就是旅遊，全聚德和望京是美食。咱們能夠分紅不一樣的類別，這些類別有美食、電影、酒店之類的，還有不少二三級的品類。

說到這個場景以後，其實你們腦子裏就能夠想到這個事情怎麼來作。

Query意圖識別能夠轉換成機器學習多分類的問題。機器學習對一個問題有一套標準的流程，作過機器學習的都知道。首先要對問題作一個分析，要分哪一些類別，根據現狀制定一個目標。現有數據的支持是否有一些標註的辭典、數據等等，根據這個再來整理數據，好比說若是標註數據不夠怎麼辦，後面會作一些介紹。特徵工程須要抽取不少特徵，特別是你要考慮到O2O的一些特色，須要作一些事情。特徵作完以後再作模型方面的一些選擇和分析，最後作一些線下的評估，而後在線上鑲嵌看它的效果。這個流程是很是通用的。

摘出幾點，有可能和其餘地方不太同樣的地方作一個介紹。首先就是訓練樣本怎麼獲取，這個其實比較難，第一種是人工標註，第二種就是自動標註。思路有幾種，能夠經過主動學習用模型學習，它的執行度比較高的，做爲它已經有了，區分比較低的再來標一下，這樣標註的樣本量就很是多。還有Query的思想其實也是來擴充執行度比較高的樣本做爲它的標註數據。

第二個問題就是特徵設計，咱們會把Query的一些語義的特徵，Query擴充的一些信息也會融進來。說一下不同的，咱們Query是有地域區分的，例如黃鶴樓，可能在北京搜更多的是一個酒店飯店；但若是在武漢搜的話，其實就是一個景點。模型嘗試的話，（PPT圖示）右邊就是精準化簡單的圖，中間兩層還作了文本分類的模型。

最後再說一下總體的流程。咱們的分類目標就是定一些品類體系，用的話，可能就是在流量分發、統計到排序裏面會用；現狀有一些辭典的，解決思路其實就是想經過機器學習的方法來解決。數據準備剛纔已經介紹了，特徵工程也說了一下，最後用DN加不少點，在線上咱們在旅遊產品上線能夠提高5%的水平。

4、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