轉載於博客園的文章：如何預測用戶query意圖
有一個朋友問，一個用戶搜索一個query是“百度”，怎麼知道用戶真正是想找什麼呢。
我回答說，分析之前搜索這個query的用戶點了些什麼結果啊。
朋友繼續問，如果沒有用戶點擊呢。
呃，如果沒有點擊，這個問題就比較複雜了。整理了下思路，於是寫成了本文。主要描述了關於如何預測用戶query意圖。希望會有所幫助。
首先我們的明確一個標準，如何判斷我們對用戶意圖的猜測是正確的?
用戶的思維是很發散的，也許今天搜索“葛優”，是想找“讓子彈飛”，明天搜索相同的query，就是想找“非誠勿擾”。 我們確定了要在某個方面的query預測上做一個改進，那麼我們首先的把標準定下來，依照這個標準來進行改進。
現在有很多對搜索系統的評價指標，如pv，ipv，ctr，搜索引導的後續轉化率等可以量化的指標，這些指標是對搜索系統總體的評價。具體到用戶意圖預測上，標準很難確定，對於排序比較直觀的就是進行side by side的評測，比較原有的效果和改進的效果，看是否會排序更優；對於導航，那我們可以看我們預測的類目和用戶實際點的類目的佔比，是否能有效降低用戶點擊非推薦類目的比率。
接下來，我們從2種情況下來回答這個問題，
如果我們已經有了一套完整的系統，有大量的用戶訪問
先從簡單的說起，假設我們已經有了一個完整的搜索系統，有大量的用戶訪問，我們希望通過對用戶query的預測來提高搜索體驗。這樣的系統的大概架構如下。
包括圖所示的幾個部分，
1 前端（f2e）
前端負責直接和用戶進行交換，當收到用戶搜索請求之後，往後端系統傳遞請求，並接收搜索引擎返回的結果，組織到網頁上，展示給用戶。
前端還肩負着一個重要的記錄日誌的工作，這個日誌的記錄，並不是apache的訪問日誌，這樣的日誌內容過於簡單。如果要前端記錄過多的日誌，又會給服務器帶來不小的壓力。所以目前主要的手段是通過用戶在頁面上進行搜索或點擊等行爲時，調用javascript向指定的日誌服務器，發送特徵url來記錄，這種url不會返回內容，僅僅爲了給日誌服務器添加記錄。發送的url會包括從cookie中解析出的用戶特有的數據。
2 Query處理
Query處理是線上服務系統，它是對用戶意圖進行預測後，對用戶的搜索結果進行改進。在接收到前端的請求之後，會利用線下對query分析得到的數據，對用戶的query和上下文環境進行分析，附加更多的條件到搜索引擎的請求命令之中。常見的Query處理，會有以下的一些類容，query改寫，query分類預測，query的導航等。
Query處理這部分主要的意義在於，將用戶的搜索query，翻譯爲對搜索引擎更適合查詢串。在大多數情況下，用戶使用搜索引擎是爲了解決自己的問題，如果能直接獲得答案，用戶是不大願意進行搜索的。
用戶也許的問題是，“非誠勿擾2裏面說的廖凡是誰”這樣的一個問題，這樣的問題直接搜索是不太會有會令用戶比較滿意的答案，（除非有向百度知道這樣的系統已經存在了類似的問題）。有些用戶就會考慮換個關鍵詞試試，搜索下“廖凡”，看是否會有一些答案可以讓自己滿意。所以很大程度上是搜索引擎在教用戶如何使用自己。但是並非所有的用戶都對搜索系統如此的熟悉，那我們就需要考慮看看在我們搜索的結果裏面效果不太好的query，分析它是怎麼構成的。我們也許無法準確回答“非誠勿擾2裏面說的廖凡是誰”，但是可以把其中最關鍵的信息抽取出來“非誠勿擾2”“廖凡”，並且，我們需要回答“是誰”這樣的疑問問題。把這些信息傳遞給引擎，纔會有更好的結果。
再例如，用戶想找，“1000元左右的手機”，那麼對於淘寶來說，可以把搜索的條件轉化爲800-1200價格限制範圍的，手機類目下的寶貝，或者更進一步，把各種型號的手機，列在一起，進行參數的比較。
再深入一步，用戶想找“舒淇在非誠勿擾2中用的手機”，如果我們可以把這個問題轉化爲對“朵唯S920”的搜索，那就是非常非常好的效果了，至於這個query如何對應到這個結果，也許後面的一些分析，能提供一些線索。
具體的實現，可以參考下面幾點，
對query的線上處理，如果是較爲hot的query，可以以查表爲主，可以用hash表，trie樹等進行查表，把在線下計算好的數據，通過查表的方式找到對應的結果，附加到給引擎的搜索條件上，並返回。
另外，可以把線下訓練好的模型，在線上進行預測，一般的分類算法預測速度都比較快。可以對長尾的query，進行及時的預測。
也可以做一些規則，如我們上面舉的例子，“1000元左右”，可以通過正則表達式進行識別，將其轉爲對應的搜索條件。這些規則如何來定呢，這是比較麻煩的一點，像這類的query，肯定是pv比較低的，屬於長尾的query，這些query效果提升可能比較明顯，但是對總體搜索系統效果影響會較小。這個問題比較尷尬，如果我們這類query處理的效果好的話，那用戶會使用的更多；用戶知道了這樣的query效果不好，所以就換成了效果好的query。如果要做好規則，那就把長尾的這些query都拿出來，多看看，分下類，再結合實際的問題分類，總結出一些通用的規則，來進行優化。
3 搜索引擎
搜索引擎主要負責檢索和排序，一般由一些倒排表和正排表組成。倒排表用於查找對應的文檔id，能快速的檢索出命中query的文檔，在根據正排表來查對應id的數據。
一般將需要字符串類型的文檔字段作爲倒排表來進行檢索，字符型的字段可以放在正排表中，在通過倒排表找到了滿足條件的文檔，再在正排表中進行過濾。
找到滿足條件的文檔後，再進行過濾，統計，並根據排序參數進行排序。
排序分爲2個部分，一部分是文檔自身的靜態分，每個文檔會有類似pagerank這樣分數，另外一部分是還有和query相關的部分，會計算文檔和query的關係，例如，query中出現的詞的在文檔中是否距離較近，query是否爲文檔的中心詞。
4 日誌存儲
日誌存儲系統收集前端記錄的日誌，存儲在數據倉庫中，解析後用分佈式文件系統來存放。有幾類日誌比較重要，
A、 搜索日誌，搜索日誌一般會包括以下一些信息，用戶id，session id，用戶搜索query，用戶當前搜索的分類，用戶搜索時間，
B、 點擊日誌，用戶id，session id，用戶搜索query，用戶當前搜索的分類，用戶點擊的item，用戶點擊時間
C、 當然可能還有其他的如交易記錄等，
有了以上幾個部分之後，我們就可以通過以下2個部分來進行用戶意圖的預測，
5 統計分析
日誌分析主要是一種統計分析，數據源來自於訪問日誌。另外還可以分析數據庫中存儲的用戶的購買，收藏等行爲。
可以從日誌中分析出用戶搜索query，“nike”最想找的是運動鞋呢，還是運動服。
常用的應用有下拉提示，相關搜索等，
下拉推薦是一種比較常用的用戶意圖分析的系統，通常是統計日誌中，表現比較好的query，將這些query按照pv和數據表現等指標進行排序，然後把query轉化爲英文和中文對應的前綴，把相同前綴的建成統一索引，在用戶輸入關鍵詞後，推薦相應的query。
相關搜索是更爲常用的用戶意圖分析，一般通過關聯規則(Apriori，FP-growth)，統計同一sesion中，用戶經常出現的相關的query，比如，可以發現同一個session裏面搜索了nike的用戶，很多都搜索了“nike dunk”這樣的信息，我們就可以再搜索結果中進行改進。這一算法可以大量應用於數據挖掘。推廣開去，我們要找某個類目下進行了購買的用戶，還希望購買些什麼類目的東西；看了一本書的用戶，還會看什麼書；搜索了一個“長款”屬性，是否還希望“修身”這樣的屬性。
在往下深入，我們可以分析用戶歷史行爲，進行個性化的預測。比如分析用戶性別，喜好，來進行分類，推薦。
6 機器學習
統計的算法也是機器學習的一種，如果用戶行爲數據足夠多，那直接使用統計分析應該是可以解決大部分問題。剩下的小部分問題是可以交給機器學習其他算法來完成。
舉一個簡單的例子來說明，用戶搜索“nike”和“羽絨服”比較多，有了足夠多的統計數據，我們知道“nike”對應的是運動鞋，運動服等。“羽絨服”對應的是服裝。但是用戶搜索“紅色的nike羽絨服”次數很少，沒有足夠多的數據，我們統計到的結果也許是不準確的，偏差較大。
那我們可以將較好的數據進行訓練，並對長尾的query進行分類預測。這裏的訓練數據的特徵是用戶query中每個詞，詞出現對應這一種分類。
訓練數據的選擇是分類算法最重要的一步，一般對文本的分類預測，可以使用信息增益，卡方，互信息等來作爲訓練特徵。具體問題具體分析，例如使用loglinear算法進行預測，實驗證明信息增益來作爲特徵選擇會更加有效，另外也得分析應用的場景，根據需要來選擇算法，選擇特徵，法無定法，對於淘寶的數據來說，用於搜索的限於寶貝的標題，非常的短，直接使用用一般的網頁分類算法是不太可行的，所以，數據不一樣，方法就不一樣，重要的是瞭解數據，瞭解方法的原理。機器學習不是萬能的，不能靠運氣。By the way，建議讀下元函的Treelink算法介紹（http://www.searchtb.com/2010/12/an-introduction-to-treelink.html），寫的挺好的。
分好類後，對每個類中的文檔的排序也可以通過機器學習來進行，如果每個文檔有很多標準的特徵，每個維度的特徵有一定的分數。這個也可以通過機器學習的方法來進行好中壞分檔，或者找出線性加權的最優化參數。
假設我們沒有用戶反饋數據
我們首先可以做的是把文檔的自身的相關性做好，回到最開始的那個問題，一個用戶搜索一個query是“百度”，怎麼知道用戶真正是想找什麼呢。
先我們至少可以把文檔按分詞後的結果和query進行比較，文檔中如果是“衆裏尋他千百度”這樣的就可以過濾掉了，因爲“千百度”和“百度”還是有一些區別的。這是從文檔自有的相關性上來進行優化。
接下來，我們看這個文檔是不是描述文檔的，比如文檔裏面是講“非誠勿擾2”的，裏面提到“廖凡，如果你不知道廖凡是誰，請百度一下”，那麼這種文檔不是描述“百度”這個詞的，而是描述“非誠勿擾2的”，我們可以通過給文檔進行分類或者加上tag，來表示他的主題詞，這樣，這類的文檔也可以過濾掉。
我們再討論下如果進行分類，在有用戶數據的時候，我們可以用用戶的行爲來作爲文檔分類的結果；沒有的情況下，我們可以進行人爲的標註，當然這部分工作量巨大。另外可能可行的是，在結構化比較好的數據裏面，找到關鍵的字段進行分類，例如，品牌+產品型號，這樣的字段作爲聚類的關鍵key，把文檔分爲很多類。如果結構化不是很好，可以考慮用crf算法來抽取其中的關鍵字段進行聚類。同時把query對文檔的直接搜索轉化爲對不同類文檔的搜索。那麼這時候，我們已經把搜索的所有文檔進行了聚類，發現“朵唯S920”手機的描述中，常會出現“舒淇在非誠勿擾2中使用”這樣的描述，是否就可以考慮把兩者聯繫在一起了呢。
