WARNING: Version 2.0 of Elasticsearch has passed its EOL date.
This documentation is no longer being maintained and may be removed. If you are running this version, we strongly advise you to upgrade. For the latest information, see the current release documentation.
Similarity module
editSimilarity module
editA similarity (scoring / ranking model) defines how matching documents are scored. Similarity is per field, meaning that via the mapping one can define a different similarity per field.
Configuring a custom similarity is considered a expert feature and the
builtin similarities are most likely sufficient as is described in
similarity
.
Configuring a similarity
editMost existing or custom Similarities have configuration options which can be configured via the index settings as shown below. The index options can be provided when creating an index or updating index settings.
"similarity" : { "my_similarity" : { "type" : "DFR", "basic_model" : "g", "after_effect" : "l", "normalization" : "h2", "normalization.h2.c" : "3.0" } }
Here we configure the DFRSimilarity so it can be referenced as
my_similarity
in mappings as is illustrate in the below example:
{ "book" : { "properties" : { "title" : { "type" : "string", "similarity" : "my_similarity" } } }
Available similarities
editDefault similarity
editThe default similarity that is based on the TF/IDF model. This similarity has the following option:
-
discount_overlaps
- Determines whether overlap tokens (Tokens with 0 position increment) are ignored when computing norm. By default this is true, meaning overlap tokens do not count when computing norms.
Type name: default
BM25 similarity
editAnother TF/IDF based similarity that has built-in tf normalization and is supposed to work better for short fields (like names). See Okapi_BM25 for more details. This similarity has the following options:
|
Controls non-linear term frequency normalization (saturation). |
|
Controls to what degree document length normalizes tf values. |
|
Determines whether overlap tokens (Tokens with 0 position increment) are ignored when computing norm. By default this is true, meaning overlap tokens do not count when computing norms. |
Type name: BM25
DFR similarity
editSimilarity that implements the divergence from randomness framework. This similarity has the following options:
|
Possible values: |
|
Possible values: |
|
Possible values: |
All options but the first option need a normalization value.
Type name: DFR
IB similarity.
editInformation based model . The algorithm is based on the concept that the information content in any symbolic distribution sequence is primarily determined by the repetitive usage of its basic elements. For written texts this challenge would correspond to comparing the writing styles of diferent authors. This similarity has the following options:
|
Possible values: |
|
Possible values: |
|
Same as in |
Type name: IB
LM Dirichlet similarity.
editLM Dirichlet similarity . This similarity has the following options:
|
Default to |
Type name: LMDirichlet
LM Jelinek Mercer similarity.
editLM Jelinek Mercer similarity . The algorithm attempts to capture important patterns in the text, while leaving out noise. This similarity has the following options:
|
The optimal value depends on both the collection and the query. The optimal value is around |
Type name: LMJelinekMercer
Default and Base Similarities
editBy default, Elasticsearch will use whatever similarity is configured as
default
. However, the similarity functions queryNorm()
and coord()
are not per-field. Consequently, for expert users wanting to change the
implementation used for these two methods, while not changing the
default
, it is possible to configure a similarity with the name
base
. This similarity will then be used for the two methods.
You can change the default similarity for all fields by putting the following setting into elasticsearch.yml
:
index.similarity.default.type: BM25