org.apache.lucene.search.function |
org.apache.lucene.search.function
Programmatic control over documents scores.
The function package provides tight control over documents scores.
WARNING: The status of the search.function package is experimental. The APIs
introduced here might change in the future and will not be supported anymore
in such a case.
Two types of queries are available in this package:
-
Custom Score queries - allowing to set the score
of a matching document as a mathematical expression over scores
of that document by contained (sub) queries.
-
Field score queries - allowing to base the score of a
document on numeric values of indexed fields.
Some possible uses of these queries:
-
Normalizing the document scores by values indexed in a special field -
for instance, experimenting with a different doc length normalization.
-
Introducing some static scoring element, to the score of a document, -
for instance using some topological attribute of the links to/from a document.
-
Computing the score of a matching document as an arbitrary odd function of
its score by a certain query.
Performance and Quality Considerations:
-
When scoring by values of indexed fields,
these values are loaded into memory.
Unlike the regular scoring, where the required information is read from
disk as necessary, here field values are loaded once and cached by Lucene in memory
for further use, anticipating reuse by further queries. While all this is carefully
cached with performance in mind, it is recommended to
use these features only when the default Lucene scoring does
not match your "special" application needs.
-
Use only with carefully selected fields, because in most cases,
search quality with regular Lucene scoring
would outperform that of scoring by field values.
-
Values of fields used for scoring should match.
Do not apply on a field containing arbitrary (long) text.
Do not mix values in the same field if that field is used for scoring.
-
Smaller (shorter) field tokens means less RAM (something always desired).
When using FieldScoreQuery,
select the shortest FieldScoreQuery.Type
that is sufficient for the used field values.
-
Reusing IndexReaders/IndexSearchers is essential, because the caching of field tokens
is based on an IndexReader. Whenever a new IndexReader is used, values currently in the cache
cannot be used and new values must be loaded from disk. So replace/refresh readers/searchers in
a controlled manner.
History and Credits:
-
A large part of the code of this package was originated from Yonik's FunctionQuery code that was
imported from Solr
(see LUCENE-446).
-
The idea behind CustomScoreQurey is borrowed from
the "Easily create queries that transform sub-query scores arbitrarily" contribution by Mike Klaas
(see LUCENE-850)
though the implementation and API here are different.
Code sample:
Note: code snippets here should work, but they were never really compiled... so,
tests sources under TestCustomScoreQuery, TestFieldScoreQuery and TestOrdValues
may also be useful.
-
Using field (byte) values to as scores:
Indexing:
f = new Field("score", "7", Field.Store.NO, Field.Index.UN_TOKENIZED);
f.setOmitNorms(true);
d1.add(f);
Search:
Query q = new FieldScoreQuery("score", FieldScoreQuery.Type.BYTE);
Document d1 above would get a score of 7.
-
Manipulating scores
Dividing the original score of each document by a square root of its docid
(just to demonstrate what it takes to manipulate scores this way)
Query q = queryParser.parse("my query text");
CustomScoreQuery customQ = new CustomScoreQuery(q) {
public float customScore(int doc, float subQueryScore, float valSrcScore) {
return subQueryScore / Math.sqrt(docid);
}
};
For more informative debug info on the custom query, also override the name() method:
CustomScoreQuery customQ = new CustomScoreQuery(q) {
public float customScore(int doc, float subQueryScore, float valSrcScore) {
return subQueryScore / Math.sqrt(docid);
}
public String name() {
return "1/sqrt(docid)";
}
};
Taking the square root of the original score and multiplying it by a "short field driven score", ie, the
short value that was indexed for the scored doc in a certain field:
Query q = queryParser.parse("my query text");
FieldScoreQuery qf = new FieldScoreQuery("shortScore", FieldScoreQuery.Type.SHORT);
CustomScoreQuery customQ = new CustomScoreQuery(q,qf) {
public float customScore(int doc, float subQueryScore, float valSrcScore) {
return Math.sqrt(subQueryScore) * valSrcScore;
}
public String name() {
return "shortVal*sqrt(score)";
}
};
|
Java Source File Name | Type | Comment |
ByteFieldSource.java | Class | Expert: obtains single byte field values from the
org.apache.lucene.search.FieldCache FieldCache using getBytes() and makes those values
available as other numeric types, casting as needed.
WARNING: The status of the search.function package is experimental. |
CustomScoreQuery.java | Class | Query that sets document score as a programmatic function of several (sub) scores.
- the score of its subQuery (any query)
- (optional) the score of its ValueSourtceQuery (or queries),
for most simple/convineient use case this query would be a
org.apache.lucene.search.function.FieldScoreQuery FieldScoreQuery
Subclasses can modify the computation by overriding
CustomScoreQuery.customScore(int,float,float) .
WARNING: The status of the search.function package is experimental. |
DocValues.java | Class | Expert: represents field values as different types.
Normally created via a
org.apache.lucene.search.function.ValueSource ValueSuorce
for a particular field and reader.
WARNING: The status of the search.function package is experimental. |
FieldCacheSource.java | Class | Expert: A base class for ValueSource implementations that retrieve values for
a single field from the
org.apache.lucene.search.FieldCache FieldCache .
Fields used herein nust be indexed (doesn't matter if these fields are stored or not).
It is assumed that each such indexed field is untokenized, or at least has a single token in a document.
For documents with multiple tokens of the same field, behavior is undefined (It is likely that current
code would use the value of one of these tokens, but this is not guaranteed).
Document with no tokens in this field are assigned the Zero value. |
FieldScoreQuery.java | Class | A query that scores each document as the value of the numeric input field.
The query matches all documents, and scores each document according to the numeric
value of that field. |
FloatFieldSource.java | Class | Expert: obtains float field values from the
org.apache.lucene.search.FieldCache FieldCache using getFloats() and makes those values
available as other numeric types, casting as needed.
WARNING: The status of the search.function package is experimental. |
FunctionTestSetup.java | Class | |
IntFieldSource.java | Class | Expert: obtains int field values from the
org.apache.lucene.search.FieldCache FieldCache using getInts() and makes those values
available as other numeric types, casting as needed.
WARNING: The status of the search.function package is experimental. |
OrdFieldSource.java | Class | Expert: obtains the ordinal of the field value from the default Lucene
org.apache.lucene.search.FieldCache Fieldcache using getStringIndex().
The native lucene index order is used to assign an ordinal value for each field value.
Example:
If there were only three field values: "apple","banana","pear"
then ord("apple")=1, ord("banana")=2, ord("pear")=3
WARNING:
ord() depends on the position in an index and can thus change
when other documents are inserted or deleted,
or if a MultiSearcher is used. |
ReverseOrdFieldSource.java | Class | Expert: obtains the ordinal of the field value from the default Lucene
org.apache.lucene.search.FieldCache FieldCache using getStringIndex()
and reverses the order.
The native lucene index order is used to assign an ordinal value for each field value.
Field values (terms) are lexicographically ordered by unicode value, and numbered starting at 1.
Example of reverse ordinal (rord):
If there were only three field values: "apple","banana","pear"
then rord("apple")=3, rord("banana")=2, ord("pear")=1
WARNING:
rord() depends on the position in an index and can thus change
when other documents are inserted or deleted,
or if a MultiSearcher is used. |
ShortFieldSource.java | Class | Expert: obtains short field values from the
org.apache.lucene.search.FieldCache FieldCache using getShorts() and makes those values
available as other numeric types, casting as needed.
WARNING: The status of the search.function package is experimental. |
TestCustomScoreQuery.java | Class | Test CustomScoreQuery search. |
TestFieldScoreQuery.java | Class | Test FieldScoreQuery search.
Tests here create an index with a few documents, each having
an int value indexed field and a float value indexed field.
The values of these fields are later used for scoring.
The rank tests use Hits to verify that docs are ordered (by score) as expected.
The exact score tests use TopDocs top to verify the exact score. |
TestOrdValues.java | Class | Test search based on OrdFieldSource and ReverseOrdFieldSource.
Tests here create an index with a few documents, each having
an indexed "id" field.
The ord values of this field are later used for scoring.
The order tests use Hits to verify that docs are ordered as expected.
The exact score tests use TopDocs top to verify the exact score. |
ValueSource.java | Class | Expert: source of values for basic function queries.
At its default/simplest form, values - one per doc - are used as the score of that doc.
Values are instantiated as
org.apache.lucene.search.function.DocValues DocValues for a particular reader.
ValueSource implementations differ in RAM requirements: it would always be a factor
of the number of documents, but for each document the number of bytes can be 1, 2, 4, or 8. |
ValueSourceQuery.java | Class | Expert: A Query that sets the scores of document to the
values obtained from a
org.apache.lucene.search.function.ValueSource ValueSource .
The value source can be based on a (cached) value of an indexd field, but it
can also be based on an external source, e.g. |