Lucene Document getBoost (float) and setBoost (float)

Document directory

• GetBoost

When the full-text search module involves the weight, no matter how you set the weight, you can view that the retrieved weight is 1, and you think you have written an error, but the score of the document has changed.

After solving all the problems, I found this article... reposted to help you avoid excessive troubles when encountering the same problem...

 

 

Today, I wrote a unit test to check the weight changes. I found that the index was good at all times. After the index was taken out, I thought it was 1. I am confused for a while, fortunately, the lucene document provides an explanation:

GetBoost

public float getBoost()

Returns, at indexing time, the boost factor as setsetBoost(float).

Note that once a document is indexed this value is no longer available from the index. at search time, for retrieved events, this method always returns 1. this however does not mean that the boost value set at indexing time was ignored-it was just combined with other indexing time factors and stored elsewhere, for better indexing and search performance. (For more information see the "norm (t, d)" part of the scoring formula inSimilarity.)

Translation: When indexing, the incentive factor is set by the SetBoost (float) function. Note that once a document is indexed, this value will no longer be valid (or irreversible). In the document retrieved during search, this method will always return 1. However, this does not mean that the incentive factor set during indexing is ignored-it only merges with various factors and stores them somewhere for better indexing and efficient search.

By the way, paste the merged document:

public abstract class Similarityextends Objectimplements Serializable

Expert: Scoring API.

Similarity defines the components of Lucene scoring. Overriding computation of these components is a convenient way to alter Lucene scoring.

Suggested reading: Introduction To Information Retrieval, Chapter 6.

The following describes how Lucene scoring evolves from underlying information retrieval models to (efficient) implementation. We first brief onVSM Score, Then derive from itLucene's Conceptual Scoring Formula, From which, finally, evolvesLucene's Practical Scoring Function(The latter is connected directly with Lucene classes and methods ).

Lucene combines Boolean model (BM) of Information Retrieval with Vector Space Model (VSM) of Information Retrieval-documents "approved" by BM are scored by VSM.

In VSM, events and queries are represented as weighted vectors in a multi-dimen1_space, where each distinct index term is a dimension, and weights are Tf-idf values.

VSM does not require weights to beTf-idfValues,Tf-idfValues are believed to produce search results of high quality, and so Lucene is usingTf-idf.TfAndIdfAre described in more detail below, but for now, for completion, let's just say that for given termTAnd document (or query)X,Tf (t, x)Varies with the number of occurrences of termTInX(When one increases so does the other) andIdf (t)Similarly varies with the inverse of the number of index documents containing termT.

VSM scoreOf documentDFor queryQIs the Cosine Similarity of the weighted query vectorsV (q)AndV (d):
 

Cosine-similarity (q, d) = V (q) · V (d) --------- | V (q) | V (d) |

VSM Score

 
WhereV (q)·V (d)Is the dot product of the weighted vectors, and| V (q) |And| V (d) |Are their Euclidean norms.

Note: the above equation can be viewed as the dot product of the normalized weighted vectors, in the sense that dividingV (q)By its euclidean norm is normalizing it to a unit vector.

Lucene refinesVSM scoreFor both search quality and usability:

• NormalizingV (d)To the unit vector is known to be problematic in that it removes all document length information. For some documents removing this info is probably OK, e.g. a document made by duplicating a certain paragraph10Times, especially if that paragraph is made of distinct terms. but for a document which contains no duplicated paragraphs, this might be wrong. to avoid this problem, a different document length normalization factor is used, which normalizes to a vector equal to or larger than the unit vector:Doc-len-norm (d).
• At indexing, users can specify that certain documents are more important than others, by assigning a document boost. For this, the score of each document is also multiplied by its boost valueDoc-boost (d).
• Lucene is field based, hence each query term applies to a single field, document length normalization is by the length of the certain field, and in addition to document boost there are also document fields boosts.
• The same field can be added to a document during indexing several times, and so the boost of that field is the multiplication of the boosts of the separate additions (or parts) of that field within the document.
• At search time users can specify boosts to each query, sub-query, and each query term, hence the contribution of a query term to the score of a document is multiplied by the boost of that query termQuery-boost (q).
• A document may match a multi term query without containing all the terms of that query (this is correct for some of the queries ), and users can further reward documents matching more query terms through a coordination factor, which is usually larger when more terms are matched:Coord-factor (q, d).

Under the simplifying assumption of a single field in the index, we getLucene's Conceptual scoring formula:
 

Score (q, d) = coord-factor (q, d) · query-boost (q )· V (q) · V (d) --------- | V (q) | · Doc-len-norm (d) · doc-boost (d)

Lucene Conceptual Scoring Formula

 

The conceptual formula is a simplification in the sense that (1) terms and statements are fielded and (2) boosts are usually per query term rather than per query.

We now describe how Lucene implements this conceptual scoring formula, and derive from itLucene's Practical Scoring Function.

For efficient score computation some scoring components are computed and aggregated in advance:

• Query-boostFor the query (actually for each query term) is known when search starts.
• Query Euclidean norm| V (q) |Can be computed when search starts, as it is independent of the document being scored. from search optimization perspective, it is a valid question why bother to normalize the query at all, because all scored documents will be multiplied by the same| V (q) |, And hence documents ranks (their order by score) will not be affected by this normalization. There are two good reasons to keep this normalization:
  • Recall that Cosine Similarity can be used find how similar two statements are. one can use Lucene for e.g. clustering, and use a document as a query to compute its similarity to other documents. in this use case it is important that the score of documentD3For queryD1Is comparable to the score of documentD3For queryD2. In other words, scores of a document for two distinct queries shocould be comparable. There are other applications that may require this. And this is exactly what normalizing the query vectorV (q)Provides: comparability (to a certain extent) of two or more queries.
  • Applying query normalization on the scores helps to keep the scores around the unit vector, hence preventing loss of score data because of floating point precision limitations.
• Document length normDoc-len-norm (d)And document boostDoc-boost (d)Are known at indexing time. They are computed in advance and their multiplication is saved as a single value in the index:Norm (d). (In the equations below,Norm (t in d)MeansNorm (field (t) in doc d)WhereField (t)Is the field associated with termT.)

Lucene's Practical Scoring FunctionIs derived from the above. The color codes demonstrate how it relates to those ofConceptualFormula:

 

Score (q, d) = coord (q, d) · queryNorm (q )· Σ (Tf (t in d) · idf (t) 2 · t. getBoost () · norm (t, d))   T in q

Lucene Practical Scoring Function

Where

1.  Tf (t in d)Correlates to the term'sFrequency, Defined as the number of times termTAppears in the currently scored documentD. Documents that have more occurrences of a given term receive a higher score. Note thatTf (t in q)Is assumed to be1And therefore it does not appear in this equation, However if a query contains twice the same term, there will be two term-queries with that same term and hence the computation wowould still be correct (although not very efficient ). the default computationTf (t in d)InDefaultSimilarityIs:
    
   

   tf(t in d)=

   FrequencyBytes

    

2.  Idf (t)Stands for Inverse Document Frequency. This value correlates to the inverseDocFreq(The number of statements in which the termTAppears). This means rarer terms give higher contribution to the total score.Idf (t)AppearsTIn both the query and the document, hence it is squared in the equation. The default computationIdf (t)InDefaultSimilarityIs:
    
   

   idf(t)=

   1 + log(

   NumDocs --------- DocFreq + 1

   )

    

3.  Coord (q, d)Is a score factor based on how many of the query terms are found in the specified document. typically, a document that contains more of the query's terms will receive a higher score than another document with fewer query terms. this is a search time factor computed incoord(q,d)By the Similarity in effect at search time.
    
4. QueryNorm (q) Is a normalizing factor used to make scores between queries comparable. this factor does not affect document ranking (since all ranked attributes are multiplied by the same factor), but rather just attempts to make scores from different queries (or even different indexes) comparable. this is a search time factor computed by the Similarity in effect at search time. the default computation inDefaultSimilarityProduces a Euclidean norm:
    
   

   QueryNorm (q) =queryNorm(sumOfSquaredWeights)=

   1 -------------- SumOfSquaredWeightsBytes

    
   The sum of squared weights (of the query terms) is computed by the queryWeightObject. For example,boolean queryComputes this value:
    
   

   sumOfSquaredWeights=q.getBoost() 2·	Σ	(Idf (t) · t. getBoost ()) 2
   	T in q

    

5.  T. getBoost ()Is a search time boost of termTIn the queryQAs specified in the query text (see query syntax), or as set by application calltosetBoost(). Notice that there is really no direct API for accessing a boost of one term in a multi term query, but rather multi terms are represented in a query as multiTermQueryObjects, and so the boost of a term in the query is accessible by calling the sub-querygetBoost().
    
6.  Norm (t, d)Encapsulates a few (indexing time) boost and length factors:
   • Document boost-Set by callingdoc.setBoost()Before adding the document to the index.
   • Field boost-Set by callingfield.setBoost()Before adding the field to a document.
   • lengthNorm(field)-Computed when the document is added to the index in accordance with the number of tokens of this field in the document, so that shorter fields contribute more to the score. lengthNorm is computed by the Similarity class in effect at indexing.

   When a document is added to the index, all the above factors are multiplied. If the document has multiple fields with the same name, all their boosts are multiplied together:
    

   Norm (t, d) =doc.getBoost()·lengthNorm(field)·	Bytes	f.getBoost()
   	FieldFInDNamedT

    
   However the resultedNormValue isencodedAs a single byte before being stored. At search time, the norm byte value is read from the indexdirectoryAnddecodedBack to a floatNormValue. This encoding/decoding, while cing index size, comes with the price of precision loss-it is not guaranteed thatDecode (encode (x) = x. For instance,Decode (encode (0.89) = 0.75.
    
   Compression of norm values to a single byte saves memory at search time, because once a field is referenced at search time, its norms-for all documents-are maintained in memory.
    
   The rationale supporting such lossy compression of norm values is that given the difficulty (and inaccuracy) of users to express their true information need by a query, only big differences matter.
    
   Last, note that search time is too late to modify thisNormPart of scoring, e.g. by using a differentSimilarityFor search.

 

Author: KKcat

　　　　

Source: http://jinzhao.cnblogs.com/

　　　　

The copyright of this article is shared by the author and the blog Park. You are welcome to repost this article. However, you must retain this statement without the author's consent and provide a clear link to the original article on the article page. Otherwise, you will be held legally liable.