2010-06-23 113 views
6

我希望我的搜索結果按照他們正在進行的分數排序,但分數計算不正確。這就是說,不一定,但不同於預期,我不知道爲什麼。我的目標是消除任何正在改變分數的東西。Solr:fieldNorm每個文檔不同,沒有文檔提示

如果我執行的搜索匹配兩個對象(其中ObjectA預計比ObjectB得分高),ObjectB將首先返回。

比方說,對於這個例子,我的查詢是一個單詞:「蘋果」。

對象A的標題:「蘋果是蘋果」(2/3計算)
對象A的描述:「有在蘋果,蘋果蘋果,現在蘋果就所有的蘋果都在蘋果」 (6/18條款)
ObjectB的標題:「蘋果很棒」(1/3條款)
ObjectB的描述:「蘋果房間裏有蘋果,現在蘋果全都變壞了! (4/18條款)

標題欄沒有增加(或者更確切地說,增加1),說明欄增加了0.8。我沒有通過solrconfig.xml或通過查詢指定文檔增強。如果還有另一種方式來指定文檔提示,那麼我有可能會丟失文檔。

分析explain打印完成後,它看起來像對象A 正確計算得分高於對象B,就像我想,除了一個區別:對象B的標題fieldNorm總是比對象A的高。


下面打印輸出explain。只要你知道:標題字段是mditem5_tns和描述字段是mditem7_tns

ObjectB: 
1.3327172 = (MATCH) sum of: 
    1.0352166 = (MATCH) max plus 0.1 times others of: 
    0.9766194 = (MATCH) weight(mditem5_tns:appl in 0), product of: 
     0.53929156 = queryWeight(mditem5_tns:appl), product of: 
     1.8109303 = idf(docFreq=3, maxDocs=9) 
     0.2977981 = queryNorm 
     1.8109303 = (MATCH) fieldWeight(mditem5_tns:appl in 0), product of: 
     1.0 = tf(termFreq(mditem5_tns:appl)=1) 
     1.8109303 = idf(docFreq=3, maxDocs=9) 
     1.0 = fieldNorm(field=mditem5_tns, doc=0) 
    0.58597165 = (MATCH) weight(mditem7_tns:appl^0.8 in 0), product of: 
     0.43143326 = queryWeight(mditem7_tns:appl^0.8), product of: 
     0.8 = boost 
     1.8109303 = idf(docFreq=3, maxDocs=9) 
     0.2977981 = queryNorm 
     1.3581977 = (MATCH) fieldWeight(mditem7_tns:appl in 0), product of: 
     2.0 = tf(termFreq(mditem7_tns:appl)=4) 
     1.8109303 = idf(docFreq=3, maxDocs=9) 
     0.375 = fieldNorm(field=mditem7_tns, doc=0) 
    0.2975006 = (MATCH) FunctionQuery(1000.0/(1.0*float(top(rord(lastmodified)))+1000.0)), product of: 
    0.999001 = 1000.0/(1.0*float(1)+1000.0) 
    1.0 = boost 
    0.2977981 = queryNorm 

ObjectA: 
1.2324848 = (MATCH) sum of: 
    0.93498427 = (MATCH) max plus 0.1 times others of: 
    0.8632177 = (MATCH) weight(mditem5_tns:appl in 0), product of: 
     0.53929156 = queryWeight(mditem5_tns:appl), product of: 
     1.8109303 = idf(docFreq=3, maxDocs=9) 
     0.2977981 = queryNorm 
     1.6006513 = (MATCH) fieldWeight(mditem5_tns:appl in 0), product of: 
     1.4142135 = tf(termFreq(mditem5_tns:appl)=2) 
     1.8109303 = idf(docFreq=3, maxDocs=9) 
     0.625 = fieldNorm(field=mditem5_tns, doc=0) 
    0.7176658 = (MATCH) weight(mditem7_tns:appl^0.8 in 0), product of: 
     0.43143326 = queryWeight(mditem7_tns:appl^0.8), product of: 
     0.8 = boost 
     1.8109303 = idf(docFreq=3, maxDocs=9) 
     0.2977981 = queryNorm 
     1.6634457 = (MATCH) fieldWeight(mditem7_tns:appl in 0), product of: 
     2.4494898 = tf(termFreq(mditem7_tns:appl)=6) 
     1.8109303 = idf(docFreq=3, maxDocs=9) 
     0.375 = fieldNorm(field=mditem7_tns, doc=0) 
    0.2975006 = (MATCH) FunctionQuery(1000.0/(1.0*float(top(rord(lastmodified)))+1000.0)), product of: 
    0.999001 = 1000.0/(1.0*float(1)+1000.0) 
    1.0 = boost 
    0.2977981 = queryNorm 

回答

6

的問題是由詞幹引起的。它將「蘋果是蘋果」擴展到「蘋果蘋果是蘋果應用」,從而使該領域變得更長。由於文件B只包含由詞幹程序擴展的一個詞語,所以字段保持較短,然後是文檔A.

這會導致不同的fieldNorms。

+0

您能否詳細說明或者可能提供鏈接?爲什麼「stemmer」將我的領域擴大到它*不是*的地方?這似乎與直覺相反! :) – JMTyler 2010-06-23 19:49:11

+0

除非你寫的第一個「appl」應該是「apple」?如果「蘋果」正在被分解成它的根源形式,那麼剛剛研究過詞幹,那將是有道理的。所以 - 讓我知道如果我有這個權利 - 你是說如果我改變所有引用「蘋果」,只搜索「蘋果」,我應該得到我想要的結果? – JMTyler 2010-06-23 20:05:39

+0

我編輯了我的帖子,所以現在應該更清楚了。詞幹使用「appl」作爲「蘋果」和「蘋果」的根形式。所以如果你停用詞幹,你應該得到你期望的結果。您還可以通過將術語添加到protwords.txt中來排除術語並更改schema.xml Jem 2010-06-23 20:56:22

2

FieldNOrm計算3個部分組成 - 對文檔和字段長度字段,索引時間升壓指數時間提升。假設您沒有提供任何索引時間提升,則差異必須是字段長度。

因此,由於lengthNorm是對於較短的字段值越高,對於B具有用於標題較高fieldNorm值,就必須有令牌的更小數量的標題比A.

參見用於以下各頁Lucene的得分的詳細解釋:

http://lucene.apache.org/java/2_4_0/scoring.html http://lucene.apache.org/java/2_4_0/api/org/apache/lucene/search/Similarity.html

+0

+1瞭解很多 - 謝謝!然而不幸的是,你會在我的帖子中注意到我說明了字段(和它們的長度)是什麼。兩個對象都有3個標記的標題和18個標記的描述。ObjectA的標題有2/3個令牌匹配,ObjectB有1/3匹配,匹配的描述分別爲6/18和4/18。所以,如果我明白你在說什麼,那麼lengthNorm應該沒有任何影響。我可以問一下 - 我將如何設置索引時間提升? – JMTyler 2010-06-23 17:47:06

+0

對不起 - 我認爲你的例子是組成的,而不是實際值。在那種情況下,你是對的,因爲領域長度不應該是一個因素。你可以用各種方法在Solr中設置提升 - 如果你正在使用SolrJ,我相信SolrInputDocument上有一個「setBoost」方法。但是,如果文檔B得到了提升,fieldNorm在描述字段中應該更高。你也可能想看看盧克 - 它允許你重建你的索引字段數據,所以你可以看到真正的索引。 – KenE 2010-06-23 18:03:03

+0

不,沒有化妝 - 只是測試數據。 :) 我會看看代碼,看看是否有任何可疑的索引時間提升發生。我可能也會看看盧克。謝謝您的幫助。 – JMTyler 2010-06-23 18:45:42