布爾檢索及其查詢優化

         針對布爾查詢的檢索,布爾查詢是指利用AND,OR或者NOT操作符將詞項連接起來的查詢。

        舉個簡單的例子:莎士比亞的哪部劇本包含Brutus及Caesar 但是不包含Calpurnia?布爾表達式爲:Brutus AND Caesar AND NOTCalpurnia。最笨的方法是線性掃描的方式:從頭到尾掃描所有劇本,對每部劇本判斷它是否包含Brutus和Caesar ,同時又不包含Calpurnia。這個方法缺點如下:速度超慢(特別是大型文檔集)、處理NOT Calpurnia 並不容易(一旦包含即可停止判斷)、不太容易支持其他操作(例如find the word Romans nearcountrymen)、不支持檢索結果的排序(即只返回較好的結果)。

        一種非線性掃描的方式是事先給文檔建立索引(index),假定我們對每篇文檔(這裏是劇本)都事先記錄它是否包含詞表中的某個詞,結果就會得到一個由布爾值構成的詞項—文檔關聯矩陣,如下圖:


         爲響應查詢Brutus AND Caesar AND NOTCalpurnia,我們分別取出Brutus、Caesar及Calpumia 對應的行向量,並對 Calpumia對應的向量求反,然後進行基於位的與操作,得到: 

110100 AND110111 AND 101111 = 100100

結果向量中的第1和第4個元素爲1,這表明該查詢對應的劇本是Antonyand Cleopatra和Hamlet。

        檢索效果的評價標準一般爲正確率召回率。正確率(Precision)表示返回結果文檔中正確的比例,如返回80篇文檔,其中20 篇相關,正確率1/4;召回率(Recall)表示全部相關文檔中被返回的比例,如返回80篇文檔,其中20 篇相關,但是總的應該相關的文檔是100篇,召回率1/5。正確率和召回率反映檢索效果的兩個方面,缺一不可。全部返回,正確率低,召回率100%,只返回一個非常可靠的結果,正確率100%,召回率低。因此引入了F度量,如下:


        回到剛纔的例子,我們顯然不能再採用原來的方式來建立和存儲一個詞項—文檔矩陣,假定N = 1百萬篇文檔(1M), 每篇有1000個詞(1K),每個詞平均有6 個字節( 包括空格和標點符號),那麼所有文檔將約佔6GB 空間,假定詞彙表的大小( 即詞項個數)爲50萬,即500K,則詞項—文檔矩陣=500K x 1M=500G。我們可以對上述例子做個粗略計算,由於每篇文檔的平均長度是1000個單詞,所以100萬篇文檔在詞項—文檔矩陣中最多對應10億(1 000×1 000 000 )個1,也就是在詞項—文檔矩陣中至少有99.8%(1 - 10億/5000億)的元素爲0。很顯然,只記錄原始矩陣中1 的位置的表示方法比詞項—文檔矩陣更好。

         上述思路就引出了倒排索引。對每個詞項t,記錄所有包含t的文檔列表,每篇文檔用一個唯一的docID來表示,通常是正整數,如1,2,3...通常採用變長表方式來存儲docID列表。倒排索引如下圖:


        注意,詞典部分往往放在內存中,而指針指向的每個倒排記錄表則往往存放在磁盤上。詞典按照字母順序進行排序,而倒排記錄表則按照文檔ID號進行排序。倒排索引的構建過程如下圖:


        索引構建過程如下:文檔生成詞項——詞項排序——合併,如下三幅圖:




考慮如下查詢:Brutus AND Calpurnia,步驟如下:

(1)在詞典中定位Brutus ;

(2)返回其倒排記錄表;

(3)在詞典中定位Calpurnia ;

(4)返回其倒排記錄表;

(5)對兩個倒排記錄表求交集,如下圖所示:


上述合併算法的僞代碼描述如下:


       下面考慮查詢優化的問題,查詢優化(query optimization )指的是如何通過組織查詢的處理過程來使處理工作量最小。對布爾查詢進行優化要考慮的一個主要因素是倒排記錄表的訪問順序。一個啓發式的想法是,按照詞項的文檔頻率(也就是倒排記錄表的長度)從小到大依次進行處理,如果我們先合併兩個最短的倒排記錄表,那麼所有中間結果的大小都不會超過最短的倒排記錄表,這樣處理所需要的工作量很可能最少。如下圖,就是先計算兩個短的倒排記錄表的and運算。


         對於任意的布爾查詢,我們必須計算並臨時保存中間表達式的結果。但是,在很多情況下,不論是由於查詢語言本身的性質所決定,還是僅僅由於這是用戶所提交的最普遍的查詢類型,查詢往往是由純“與” 操作構成的。在這種情況下,不是將倒排記錄表合併看成兩個輸入加一個不同輸出的函數,而是將每個返回的倒排記錄表和當前內存中的中間結果進行合併,這樣做的效率更高而最初的中間結果中可以調入最小文檔頻率的詞項所對應的倒排記錄表。該合併算法是不對稱的:中間結果表在內存中而需要與之合併的倒排記錄表往往要從磁盤中讀取。此外,中間結果表的長度至多和倒排記錄表一樣長,在很多情況下,它可能會短一個甚至多個數量級。在倒排記錄表的長度相差很大的情況下,就可以使用一些策略來加速合併過程。對於中間結果表,合併算法可以就地對失效元素進行破壞性修改或者只添加標記。或者,通過在長倒排記錄表中對中間結果表中的每個元素進行二分查找也可以實現合併。另外一種可能是將長倒排記錄表用哈希方式存儲,這樣對中間結果表的每個元素,就可以通過常數時間而不是線性或者對數時間來實現查找。



參考:

信息檢索導論——ChristopherD. Manning等著

中科院-現代信息檢索ppt——王斌
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章