org.apache.lucene.search
abstract public class: Similarity [javadoc 
source]
java.lang.Object
org.apache.lucene.search.Similarity
All Implemented Interfaces:
Serializable
Direct Known Subclasses:
SimilarityDelegator, SimpleSimilarity, SweetSpotSimilarity, DefaultSimilarity
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 on VSM Score,
then derive from it Lucene's Conceptual Scoring Formula,
from which, finally, evolves Lucene'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, documents and queries are represented as
weighted vectors in a multidimensional space,
where each distinct index term is a dimension,
and weights are
Tfidf values.
VSM does not require weights to be Tfidf values,
but Tfidf values are believed to produce search results of high quality,
and so Lucene is using Tfidf.
Tf and Idf are described in more detail below,
but for now, for completion, let's just say that
for given term t and document (or query) x,
Tf(t,x) varies with the number of occurrences of term t in x
(when one increases so does the other) and
idf(t) similarly varies with the inverse of the
number of index documents containing term t.
VSM score of document d for query q is the
Cosine Similarity
of the weighted query vectors V(q) and V(d):
cosinesimilarity(q,d) =

V(q) · V(d) 
––––––––– 
V(q) V(d) 



VSM Score

Where
V(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 dividing
V(q) by its euclidean norm is normalizing it to a unit vector.
Lucene refines VSM score for both search quality and usability:
 Normalizing V(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 paragraph 10 times,
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: doclennorm(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 value
docboost(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, subquery, 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 term queryboost(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: coordfactor(q,d).
Under the simplifying assumption of a single field in the index,
we get Lucene's Conceptual scoring formula:
score(q,d) =
coordfactor(q,d) ·
queryboost(q) ·

V(q) · V(d) 
––––––––– 
V(q) 

· doclennorm(d)
· docboost(d)



Lucene Conceptual Scoring Formula

The conceptual formula is a simplification in the sense that (1) terms and documents
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 it Lucene's Practical Scoring Function.
For efficient score computation some scoring components
are computed and aggregated in advance:
 Queryboost for 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 documents 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 document d3
for query d1 is comparable to the score of document d3
for query d2. In other words, scores of a document for two
distinct queries should be comparable.
There are other applications that may require this.
And this is exactly what normalizing the query vector V(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 norm doclennorm(d) and document
boost docboost(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) means norm(field(t) in doc d)
where field(t) is the field associated with term t.)
Lucene's Practical Scoring Function is derived from the above.
The color codes demonstrate how it relates
to those of the conceptual formula:

Lucene Practical Scoring Function

where

tf(t in d)
correlates to the term's frequency,
defined as the number of times term t appears in the currently scored document d.
Documents that have more occurrences of a given term receive a higher score.
Note that tf(t in q) is assumed to be 1 and therefore it does not appear in this equation,
However if a query contains twice the same term, there will be
two termqueries with that same term and hence the computation would still be correct (although
not very efficient).
The default computation for tf(t in d) in
DefaultSimilarity is:

idf(t) stands for Inverse Document Frequency. This value
correlates to the inverse of docFreq
(the number of documents in which the term t appears).
This means rarer terms give higher contribution to the total score.
idf(t) appears for t in both the query and the document,
hence it is squared in the equation.
The default computation for idf(t) in
DefaultSimilarity is:
idf(t) =

1 + log (

numDocs 
––––––––– 
docFreq+1 

)


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 in
coord(q,d)
by the Similarity in effect at search time.

queryNorm(q)
is a normalizing factor used to make scores between queries comparable.
This factor does not affect document ranking (since all ranked documents 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 in
DefaultSimilarity
produces a Euclidean norm:
The sum of squared weights (of the query terms) is
computed by the query org.apache.lucene.search.Weight object.
For example, a boolean query
computes this value as:

t.getBoost()
is a search time boost of term t in the query q as
specified in the query text
(see query syntax),
or as set by application calls to
setBoost() .
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 multi
TermQuery objects,
and so the boost of a term in the query is accessible by calling the subquery
getBoost() .

norm(t,d) encapsulates a few (indexing time) boost and length factors:
 Document boost  set by calling
doc.setBoost()
before adding the document to the index.
 Field boost  set by calling
field.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:
However the resulted norm value is encoded as a single byte
before being stored.
At search time, the norm byte value is read from the index
directory and
decoded back to a float norm value.
This encoding/decoding, while reducing index size, comes with the price of
precision loss  it is not guaranteed that decode(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 this norm part of scoring, e.g. by
using a different Similarity for search.
Also see:
 setDefault(Similarity)
 org.apache.lucene.index.IndexWriter#setSimilarity(Similarity)
 Searcher#setSimilarity(Similarity)
Field Summary 

public static final int  NO_DOC_ID_PROVIDED  
Method from org.apache.lucene.search.Similarity Summary: 

computeNorm, coord, decodeNorm, encodeNorm, getDefault, getNormDecoder, idf, idfExplain, idfExplain, lengthNorm, queryNorm, scorePayload, setDefault, sloppyFreq, tf, tf 
Methods from java.lang.Object: 

clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait 
Method from org.apache.lucene.search.Similarity Detail: 
public float computeNorm(String field,
FieldInvertState state) {
return (float) (state.getBoost() * lengthNorm(field, state.getLength()));
} Compute the normalization value for a field, given the accumulated
state of term processing for this field (see FieldInvertState ).
Implementations should calculate a float value based on the field
state and then return that value.
For backward compatibility this method by default calls
#lengthNorm(String, int) passing
FieldInvertState#getLength() as the second argument, and
then multiplies this value by FieldInvertState#getBoost() .
WARNING: This API is new and experimental and may
suddenly change. 
abstract public float coord(int overlap,
int maxOverlap) Computes a score factor based on the fraction of all query terms that a
document contains. This value is multiplied into scores.
The presence of a large portion of the query terms indicates a better
match with the query, so implementations of this method usually return
larger values when the ratio between these parameters is large and smaller
values when the ratio between them is small. 
public static float decodeNorm(byte b) {
return NORM_TABLE[b & 0xFF]; // & 0xFF maps negative bytes to positive above 127
} Decodes a normalization factor stored in an index. 
public static byte encodeNorm(float f) {
return SmallFloat.floatToByte315(f);
} Encodes a normalization factor for storage in an index.
The encoding uses a threebit mantissa, a fivebit exponent, and
the zeroexponent point at 15, thus
representing values from around 7x10^9 to 2x10^9 with about one
significant decimal digit of accuracy. Zero is also represented.
Negative numbers are rounded up to zero. Values too large to represent
are rounded down to the largest representable value. Positive values too
small to represent are rounded up to the smallest positive representable
value. 
public static Similarity getDefault() {
return Similarity.defaultImpl;
} 
public static float[] getNormDecoder() {
return NORM_TABLE;
} Returns a table for decoding normalization bytes. 
abstract public float idf(int docFreq,
int numDocs) Computes a score factor based on a term's document frequency (the number
of documents which contain the term). This value is multiplied by the
#tf(int) factor for each term in the query and these products are
then summed to form the initial score for a document.
Terms that occur in fewer documents are better indicators of topic, so
implementations of this method usually return larger values for rare terms,
and smaller values for common terms. 
public IDFExplanation idfExplain(Term term,
Searcher searcher) throws IOException {
final int df = searcher.docFreq(term);
final int max = searcher.maxDoc();
final float idf = idf(df, max);
return new IDFExplanation() {
@Override
public String explain() {
return "idf(docFreq=" + df +
", maxDocs=" + max + ")";
}
@Override
public float getIdf() {
return idf;
}};
} idf(searcher.docFreq(term), searcher.maxDoc());
Note that Searcher#maxDoc() is used instead of
IndexReader#numDocs() because also
Searcher#docFreq(Term) is used, and when the latter
is inaccurate, so is Searcher#maxDoc() , and in the same direction.
In addition, Searcher#maxDoc() is more efficient to compute 
public IDFExplanation idfExplain(Collection<Term> terms,
Searcher searcher) throws IOException {
final int max = searcher.maxDoc();
float idf = 0.0f;
final StringBuilder exp = new StringBuilder();
for (final Term term : terms ) {
final int df = searcher.docFreq(term);
idf += idf(df, max);
exp.append(" ");
exp.append(term.text());
exp.append("=");
exp.append(df);
}
final float fIdf = idf;
return new IDFExplanation() {
@Override
public float getIdf() {
return fIdf;
}
@Override
public String explain() {
return exp.toString();
}
};
} 
abstract public float lengthNorm(String fieldName,
int numTokens) Computes the normalization value for a field given the total number of
terms contained in a field. These values, together with field boosts, are
stored in an index and multipled into scores for hits on each field by the
search code.
Matches in longer fields are less precise, so implementations of this
method usually return smaller values when numTokens is large,
and larger values when numTokens is small.
Note that the return values are computed under
org.apache.lucene.index.IndexWriter#addDocument(org.apache.lucene.document.Document)
and then stored using
#encodeNorm(float) .
Thus they have limited precision, and documents
must be reindexed if this method is altered. 
abstract public float queryNorm(float sumOfSquaredWeights) Computes the normalization value for a query given the sum of the squared
weights of each of the query terms. This value is multiplied into the
weight of each query term. While the classic query normalization factor is
computed as 1/sqrt(sumOfSquaredWeights), other implementations might
completely ignore sumOfSquaredWeights (ie return 1).
This does not affect ranking, but the default implementation does make scores
from different queries more comparable than they would be by eliminating the
magnitude of the Query vector as a factor in the score. 
public float scorePayload(int docId,
String fieldName,
int start,
int end,
byte[] payload,
int offset,
int length) {
return 1;
} 
public static void setDefault(Similarity similarity) {
Similarity.defaultImpl = similarity;
} Set the default Similarity implementation used by indexing and search
code. 
abstract public float sloppyFreq(int distance) Computes the amount of a sloppy phrase match, based on an edit distance.
This value is summed for each sloppy phrase match in a document to form
the frequency that is passed to #tf(float) .
A phrase match with a small edit distance to a document passage more
closely matches the document, so implementations of this method usually
return larger values when the edit distance is small and smaller values
when it is large. 
public float tf(int freq) {
return tf((float)freq);
} Computes a score factor based on a term or phrase's frequency in a
document. This value is multiplied by the #idf(int, int)
factor for each term in the query and these products are then summed to
form the initial score for a document.
Terms and phrases repeated in a document indicate the topic of the
document, so implementations of this method usually return larger values
when freq is large, and smaller values when freq
is small.
The default implementation calls #tf(float) . 
abstract public float tf(float freq) Computes a score factor based on a term or phrase's frequency in a
document. This value is multiplied by the #idf(int, int)
factor for each term in the query and these products are then summed to
form the initial score for a document.
Terms and phrases repeated in a document indicate the topic of the
document, so implementations of this method usually return larger values
when freq is large, and smaller values when freq
is small. 