很多網(wǎng)友在使用 Lucene.NET (Lucene Java 版本也是一樣)后會(huì)感覺Lucene.NET 的匹配相關(guān)度存在問題，搜索得到的結(jié)果往往不是希望的結(jié)果，不完全匹配的記錄往往比完全匹配的記錄排序還要靠前，很多人試圖通過(guò)分詞來(lái)解決，中文環(huán)境搜索，分詞確實(shí)能解決一些問題，但不能根本解決問題，而英文環(huán)境下，分詞根本無(wú)法解決任何問題。

　　問題的本質(zhì)是由于Lucene的得分算法缺陷造成的，不改進(jìn)得分算法根本不能根本解決問題。HubbleDotNET的得分算法參考了Lucene的得分算法并做了重大改進(jìn)，匹配相關(guān)度比Lucene.NET 有了顯著提高。本文結(jié)合一個(gè)極端的例子來(lái)分析兩者得分算法的異同，并從原理上講解為什么HubbleDotNET 的匹配相關(guān)度要比Lucene.NET 的高。

　　先看例子

　　我們對(duì)下面兩條記錄分別用 Lucene.NET 2.9.1 和 HubbleDotNET 0.9.7.1 進(jìn)行索引。

　　記錄1

　　教育問題一直是國(guó)家最關(guān)心的,我們要長(zhǎng)抓不懈

　　記錄2

　　教育獨(dú)生子女問題,這是很多家長(zhǎng)要關(guān)心的問題

分詞采用盤古分詞，分詞參數(shù)中關(guān)閉多元分詞。

兩個(gè)句子的分詞結(jié)果分別為：

教育/問題/一直/是/國(guó)家/最/關(guān)心/的/我們/要/長(zhǎng)抓/不懈/

教育/獨(dú)生子女/問題/這/是/很多/家長(zhǎng)/要/關(guān)心/的/問題/

要搜索的句子是：教育問題

其分詞結(jié)果為：教育/問題/

從直觀上看，記錄1 是完全匹配，應(yīng)該得分比記錄2高，這也是我們希望的排序結(jié)果，即記錄1排在第一個(gè)，記錄2排第二個(gè)。

　　下面看看實(shí)際的排序結(jié)果：

　　Lucene.NET 的排序結(jié)果：（這是盤古分詞帶的Lucene.NET 的例子稍作改動(dòng)后（將得分輸出了）的輸出結(jié)果) 從結(jié)果我們可以看出記錄2被排在了第一位，得分為 0.042 而記錄1 的得分為 0.034 排第二位，這個(gè)顯然不是我們希望的結(jié)果。

　　再看HubbleDotNET的結(jié)果

　　這里我們看到記錄1被排在第一位，得分為 390218522

　　記錄2 排第二位，得分 85937

　　原因分析

要分析兩者匹配相關(guān)度的差異，我們需要比較兩者的基礎(chǔ)得分算法

　　Lucene 的基礎(chǔ)得分算法

coord(q,d): 文檔d中，q中命中的項(xiàng)數(shù)除以查詢q的項(xiàng)總數(shù)

queryNorm(q): 只在不同query比較時(shí)影響score的normalizing因素

tf(t in d):單文本詞匯頻率，t在文檔d中出現(xiàn)的次數(shù)除以d中所有的項(xiàng)總數(shù)的平方根

idf(t):逆文本頻率指數(shù)，log(numDocs/docFreq+1)+1.0

　　If the document has multiple fields with the same name, all their boosts are multiplied together

　　從Lucene的得分算法公式我們可以看出，得分算法和單詞在文檔中的位置沒有任何關(guān)系，也就是說(shuō)Lucene 的得分算法只關(guān)心單詞分量的出現(xiàn)頻率，不關(guān)心出現(xiàn)位置。這就不難理解為什么文檔2的得分比文檔1高了，因?yàn)槲臋n2中 “教育”分量出現(xiàn)了1次，“問題”分量出現(xiàn)了2次，而文檔1中這兩個(gè)分量各出現(xiàn)了一次，另外idf 和 norm(t,d) 在當(dāng)前環(huán)境中又幾乎相等，于是文檔2的得分就超過(guò)了文檔1。這是Lucene得分算法的重大缺陷，因?yàn)槲臋n的匹配相關(guān)度不僅與頻率有關(guān)還與位置有關(guān)。

　　HubbleDotNET 的基礎(chǔ)得分算法

　　HubbleDotNET 在設(shè)計(jì)得分算法時(shí)充分考慮到了Lucene 的這個(gè)缺陷，在得分算法中加入了位置函數(shù) fp(t,d,q) ，這個(gè)位置函數(shù)的加入使HubbleDotNET 的匹配相關(guān)度比Lucene有了大幅的提高。 

HubbleDotNET 的基礎(chǔ)得分算法公式如下：

　　這個(gè)算法其實(shí)是以 TF-IDF 算法為基礎(chǔ)并增加了位置函數(shù) fp(t,d,q)

其中

• FieldRank 為字段權(quán)值
• Rank(t,q) 為單詞分量(term)的在查詢字符串中的權(quán)值，即 教育^1^0 中的 1
• Rank(t,d) 為單詞分量(term)所在文檔的權(quán)值，默認(rèn)為1，如果要指定文檔權(quán)值，需要在表中增加一個(gè) rank int untokenized 字段。
• TF(t,d) : 為單文本詞匯頻率，要查詢的單詞分量(term)在文檔中的出現(xiàn)的次數(shù)除以文檔所有單詞分量出現(xiàn)的次數(shù)。

公式如下：

• IDF(t) 為逆文本頻率指數(shù)。

公式如下：

|D|: 文本集合的文檔總數(shù)

: 為含有單詞分類(term)的文檔總數(shù)

HubbleDotNET 的 tf idf 算法是根據(jù)標(biāo)準(zhǔn)算法來(lái)寫的，和Lucene 的算法有不同。參考 tf-idf

• Sum(t) = 單詞分量(term) 在所有文檔中出現(xiàn)的總數(shù)的平方根。

公式如下：

• fp(t,d,q) 是單詞分量在文檔中的位置與在查詢字符串中的位置關(guān)系函數(shù)，位置越接近，則返回值越大。

　　除去 fp(t,d,q) 以外的部分和 Lucene 的得分算法是近似的，都是基于余弦定理來(lái)做的，只是在實(shí)現(xiàn)上有點(diǎn)區(qū)別而已。

　　而 fp(t,d,q) 則是Lucene 得分算法所沒有的，這個(gè)函數(shù)是單詞分量在文檔中的位置與在查詢字符串中的位置關(guān)系函數(shù)，位置越接近，則返回值越大。

　　就拿上面的例子來(lái)說(shuō)，教育 和 問題 這兩個(gè)單詞分量在文檔1 中的位置關(guān)系和查詢字符串 “教育問題” 的位置關(guān)系是一致的，這時(shí) fp(t,d,q) 函數(shù)的返回值就會(huì)很大，而文檔2中，兩個(gè)單詞分量的位置關(guān)系和查詢字符串“教育問題” 的位置關(guān)系不一致，這時(shí)返回值就比較小。這也就是我們看到文檔1的得分要比文檔2大幾個(gè)數(shù)量級(jí)的原因。

　　關(guān)于fp(t,d,q)這個(gè)函數(shù)的實(shí)現(xiàn)原理我將在另外的文章中闡述，主要思路就是計(jì)算相同向量在文檔中和查詢字符串中的向量夾角然后求積，不過(guò)說(shuō)起來(lái)簡(jiǎn)單，這里面要考慮的問題還是比較多，比如如何控制返回值不能太大，查詢字符串中有多個(gè)相同單詞分量怎么處理等等。

　　相關(guān)文章：

　　HubbleDotNET 和 Lucene.NET 性能對(duì)比測(cè)試

　　HubbleDotNET 海量數(shù)據(jù)測(cè)試報(bào)告

NET技術(shù)：HubbleDotNet 和 Lucene.Net 匹配相關(guān)度的比較，轉(zhuǎn)載需保留來(lái)源！

鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請(qǐng)第一時(shí)間聯(lián)系我們修改或刪除，多謝。