有一個朋友問，一個用戶搜索一個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中使用”這樣的描述，是否就可以考慮把兩者聯系在一起了呢。

如何預測用戶query意圖