詞典及容錯式檢索
如上圖，倒排索引記錄表構建好后。對於查詢請求“solr”，我們的首要任務是確定查詢詞項solr是否在詞典的詞項詞匯表中，如果在，則返回該詞項對應的倒排記錄表的指針。如何在數據結構（即詞典）中快速定位詞項？
詞典(即存儲詞項詞匯表的數據結構)
快速定位詞項主要有兩大類解決方案
哈希表方式
每個詞項通過哈希函數映射成一個整數，映射函數的目標空間需要足夠大，以減少哈希結果沖突的可能性。查詢時，對於每個查詢項分別進行哈希操作，並解決存在的沖突，最后返回每個查詢詞項對應的倒排記錄表的指針。
優點：在哈希表中的定位速度快於樹中的定位速度，查詢時間是常數
缺點：
沒辦法處理詞項的微小變形(resume vs. résumé)
不支持前綴搜索(比如所有以automat開頭的詞項)
如果詞匯表不斷增大，需要定期對所有詞項重新哈希
搜索樹方式（二叉樹及B樹）
優點：支持前綴查詢
缺點：搜索速度略低於哈希表方式： O(logM), 其中M 是詞匯表大小，即所有詞項的數目。O(logM) 僅僅對平衡樹成立
詞典數據結構的選取要綜合考慮
- 詞項的數目有多少？
- 詞項的數目是固定的還是經常變化？在變化的情況下，是只插入新詞項，還是同時要刪除某些舊詞項？
- 不同詞項的相對訪問頻率如何？
通配符查詢
B樹結構詞典通配符查詢處理
- 對mon*的查詢操作，遍歷B-樹結構，返回區間mon ≤ t< moo上的詞項term
- 對*mon的查詢操作，遍歷反向B-樹結構，返回區間nom ≤ t < non上的詞項term
- 對m*nchen的查詢操作，在B‐樹中分別查找滿足m*和*nchen的詞項集合，然后求交集
然而對於上述一般通配查詢的操作，開銷太大。
輪排(permuterm) 索引（稱為輪排樹更恰當）
基本思想：
首先我們在字符集中引入一個新的符號$，用於標識詞項結束。
將每個通配查詢旋轉，使*出現在末尾。
將每個旋轉后的結果存放在詞典（B‐樹）中。即對詞典中的詞項詞匯表再進行了一層索引
對於詞項hello: 將hello$, ello$h, llo$he, lo$hel, 和o$hell 加入到B‐樹中，其中$ 是一個特殊符號。
考慮通配符查詢 m*n， 這里的關鍵是將查詢進行旋轉讓*號出現在字符串末尾，即得到 n$m* 。下一步，在輪排索引中查找該字符串（可通過搜索樹方式查找） ，實際上等價於查找某些詞項（如 man和 moron）的旋轉結果。
問題：相對於通常的B‐樹，輪排樹的空間要大4倍以上(經驗值)
k‐gram 索引（比輪排索引空間開銷要小，但可能要進行后過濾）
一個 k-gram代表由k個字符組成的序列。對於詞項 castle來說，cas、ast、stl都是 3-gram。我們用一個特殊的字符$來標識詞項的開始或者結束，因此對於 castle來說，所有的 3-gram包括$ca、cas、ast、stl、tle及 le$。
構建基本思想：
首先我們在字符集中引入一個新的符號$，用於標識詞項開始和結束。
枚舉一個詞項中所有連讀的k個字符構成的k‐gram ，將所有的k-gram建立倒排索引。即對詞典中的詞項詞匯表再進行了一層索引
對2-gram索引來說，查詢mon* 可以先執行布爾查詢: $m AND mo AND on，該布爾查詢會返回所有以前綴mon開始的詞項，當然也可能返回許多偽正例，比如MOON。 因此，必須要做后續的過濾。處理余下的詞項將在詞項‐文檔倒排索引中查找文檔，最終完成通配符查詢操作。
注：即使沒有通配符查詢的布爾組合，單個通配符查詢的處理也是非常耗時的，除了最后要在詞項‐文檔倒排索引中查找之外，還要在特定索引（如輪排索引或 k-gram索引）中進行查找、在結果中進行過濾等操作。搜索引擎可以支持這些豐富的功能，但是搜索引擎通常將這些功能隱藏在一個大部分用戶從不訪問的界面（如“ 高級搜索” 界面）下。如果把這些功能暴露在一般搜索界面上，用戶常常會受鼓勵而使用這些功能，即便在他們不是特別需要的時候（比如，輸入以a*開始的查詢的前綴） ，這樣就會大大增加搜索引擎的負擔。
拼寫校正
用途：
- 糾正待索引文檔。在IR領域, 我們主要對OCR處理后的文檔進行拼寫校正處理. (OCR = optical character recognition，光學字符識別)。IR領域的一般做法是：不改變文檔
- 糾正用戶的查詢
方法：
- 詞獨立(Isolated word)法：只檢查每個單詞本身的拼寫錯誤。如果某個單詞拼寫錯誤后變成另外一個單詞，則無法查出。e.g., an asteroid that fell form the sky
- 上下文敏感(Context‐sensitive)法：糾錯時要考慮周圍的單詞，能糾正上例中的錯誤form/from
詞獨立(Isolated word)法
解決該問題常分兩個步驟：
1.在給定詞項詞匯表 V 和查詢字符串 q，我們要從 V 中尋找和 q具有最小編輯距離的字符串，得到候選的“正確”單詞詞匯表。
2.為了進一步限制計算編輯距離后得到的詞匯表大小，常通過使用k-gram索引來輔助返回與查詢 q具有較小編輯距離的詞項。
步驟1中詞匯表V的幾種選擇方式：
- 采用標准詞典(韋伯詞典, 牛津詞典等等)
- 采用領域詞典(面向特定領域的IR系統)
- 采用文檔集上的詞項詞匯表，但是每個詞項均帶有權重
編輯距離（edit distance）的計算方法：Levenshtein distance算法（非常經典的一個動態規划算法）
Levenshtein distance
wiki地址：http://en.wikipedia.org/wiki/Levenshtein_distance
java語言開源實現：http://commons.apache.org/lang/
/**
* StringUtils.getLevenshteinDistance(null, *) = IllegalArgumentException
* StringUtils.getLevenshteinDistance(*, null) = IllegalArgumentException
* StringUtils.getLevenshteinDistance("","") = 0
* StringUtils.getLevenshteinDistance("","a") = 1
* StringUtils.getLevenshteinDistance("aaapppp", "") = 7
* StringUtils.getLevenshteinDistance("frog", "fog") = 1
* StringUtils.getLevenshteinDistance("fly", "ant") = 3
* StringUtils.getLevenshteinDistance("elephant", "hippo") = 7
* StringUtils.getLevenshteinDistance("hippo", "elephant") = 7
* StringUtils.getLevenshteinDistance("hippo", "zzzzzzzz") = 8
* StringUtils.getLevenshteinDistance("hello", "hallo") = 1
*/
注：對查詢字符串q在V中窮舉計算編輯距離的代價會很大，實際當中往往通過啟發式策略提高查找效率
k-gram 重合度（k-gram overlap）
在步驟1計算編輯距離后得到的詞匯表中，利用k‐gram索引返回能夠匹配很多查詢k‐gram的正確單詞。匹配程度(數目或者指標)上可以事先設定閾值。E.g., 比如最多只有3 個k‐gram不同。
對上圖（計算編輯距離后得到的詞匯表），和查詢字符串 bord存在至少兩個 2-gram 的匹配詞匯為aboard、boardroom及 border
上下文敏感的拼寫校正
獨立的詞項拼寫校正方法在面對諸如flew form Heathrow 中的輸入錯誤時無能為力，因為這3個詞單獨看來拼寫都沒有錯誤。當輸入這類查詢時，搜索引擎可能會發現返回的文檔非常少， 隨后也許會提供正確的查詢建議 flew from Heathrow。 這種功能的一種簡單的實現方法就是，即使每個單詞拼寫都是對的，仍然要對每個單詞找到可能的拼寫正確詞（Levenshtein、k-gram 重合度方法） ，然后嘗試對短語中的每個詞進行替換。比如對於上面 flew form Heathrow的例子，我們可能會返回如下短語 fled from Heathrow和 flew fore Heathrow。對每個替換后的短語，搜索引擎進行查找並確定最后的返回數目。
如果單獨的查詢有多種可能的正確拼寫形式，那么上述方法中窮舉過程的開銷會非常大，最后我們就會面對非常多的拼寫組合。有一些啟發式方法可以減小可能的拼寫結果空間。上述例子中，當我們對 flew 及 from 進行擴展時，我們只保留文檔集合或查詢日志中的高頻組合結果。比如，我們很可能會保留 flew from而不是 fled fore或 flea form，這是因為 fled fore很可能比 flew from出現的次數少。接下來，我們僅僅根據高頻雙詞（如 flew from）來獲得 Heathrow的可能的正確拼寫。計算雙詞頻率的時候可以使用文檔集，也可以使用用戶的查詢日志。
基於發音的校正技術
在IR中並不非常普遍，主要用於人名及專有名詞的語音校正。適用於“高召回率”任務(e.g., 國際刑警組織Interpol在全球范圍內追查罪犯)
soundex算法
wiki地址：http://en.wikipedia.org/wiki/Soundex
java語言開源實現：http://commons.apache.org/codec/