mirror of
https://github.com/honeymoose/OpenSearch.git
synced 2025-02-26 06:46:10 +00:00
Moves the following API sections under the REST APIs navigations: - API Conventions - Document APIs - Search APIs - Index APIs (previously named Indices APIs) - cat APIs - Cluster APIs Other supporting changes: - Removes the previous index APIs page under REST APIs. Adds a redirect for the removed page. - Removes several [partintro] macros so the docs build correctly. - Changes anchors for pages that become sections of a parent page. - Adds several redirects for existing pages that become sections of a parent page. This commit re-applies changes from #44238. Changes from that PR were reverted due to broken links in several repos. This commit adds redirects for those broken links.
140 lines
4.5 KiB
Plaintext
140 lines
4.5 KiB
Plaintext
[[request-body-search-rescore]]
|
|
=== Rescoring
|
|
|
|
Rescoring can help to improve precision by reordering just the top (eg
|
|
100 - 500) documents returned by the
|
|
<<search-request-query,`query`>> and
|
|
<<search-request-post-filter,`post_filter`>> phases, using a
|
|
secondary (usually more costly) algorithm, instead of applying the
|
|
costly algorithm to all documents in the index.
|
|
|
|
A `rescore` request is executed on each shard before it returns its
|
|
results to be sorted by the node handling the overall search request.
|
|
|
|
Currently the rescore API has only one implementation: the query
|
|
rescorer, which uses a query to tweak the scoring. In the future,
|
|
alternative rescorers may be made available, for example, a pair-wise rescorer.
|
|
|
|
NOTE: An error will be thrown if an explicit <<search-request-sort,`sort`>>
|
|
(other than `_score` in descending order) is provided with a `rescore` query.
|
|
|
|
NOTE: when exposing pagination to your users, you should not change
|
|
`window_size` as you step through each page (by passing different
|
|
`from` values) since that can alter the top hits causing results to
|
|
confusingly shift as the user steps through pages.
|
|
|
|
==== Query rescorer
|
|
|
|
The query rescorer executes a second query only on the Top-K results
|
|
returned by the <<search-request-query,`query`>> and
|
|
<<search-request-post-filter,`post_filter`>> phases. The
|
|
number of docs which will be examined on each shard can be controlled by
|
|
the `window_size` parameter, which defaults to 10.
|
|
|
|
By default the scores from the original query and the rescore query are
|
|
combined linearly to produce the final `_score` for each document. The
|
|
relative importance of the original query and of the rescore query can
|
|
be controlled with the `query_weight` and `rescore_query_weight`
|
|
respectively. Both default to `1`.
|
|
|
|
For example:
|
|
|
|
[source,js]
|
|
--------------------------------------------------
|
|
POST /_search
|
|
{
|
|
"query" : {
|
|
"match" : {
|
|
"message" : {
|
|
"operator" : "or",
|
|
"query" : "the quick brown"
|
|
}
|
|
}
|
|
},
|
|
"rescore" : {
|
|
"window_size" : 50,
|
|
"query" : {
|
|
"rescore_query" : {
|
|
"match_phrase" : {
|
|
"message" : {
|
|
"query" : "the quick brown",
|
|
"slop" : 2
|
|
}
|
|
}
|
|
},
|
|
"query_weight" : 0.7,
|
|
"rescore_query_weight" : 1.2
|
|
}
|
|
}
|
|
}
|
|
--------------------------------------------------
|
|
// CONSOLE
|
|
// TEST[setup:twitter]
|
|
|
|
The way the scores are combined can be controlled with the `score_mode`:
|
|
[cols="<,<",options="header",]
|
|
|=======================================================================
|
|
|Score Mode |Description
|
|
|`total` |Add the original score and the rescore query score. The default.
|
|
|`multiply` |Multiply the original score by the rescore query score. Useful
|
|
for <<query-dsl-function-score-query,`function query`>> rescores.
|
|
|`avg` |Average the original score and the rescore query score.
|
|
|`max` |Take the max of original score and the rescore query score.
|
|
|`min` |Take the min of the original score and the rescore query score.
|
|
|=======================================================================
|
|
|
|
==== Multiple Rescores
|
|
|
|
It is also possible to execute multiple rescores in sequence:
|
|
|
|
[source,js]
|
|
--------------------------------------------------
|
|
POST /_search
|
|
{
|
|
"query" : {
|
|
"match" : {
|
|
"message" : {
|
|
"operator" : "or",
|
|
"query" : "the quick brown"
|
|
}
|
|
}
|
|
},
|
|
"rescore" : [ {
|
|
"window_size" : 100,
|
|
"query" : {
|
|
"rescore_query" : {
|
|
"match_phrase" : {
|
|
"message" : {
|
|
"query" : "the quick brown",
|
|
"slop" : 2
|
|
}
|
|
}
|
|
},
|
|
"query_weight" : 0.7,
|
|
"rescore_query_weight" : 1.2
|
|
}
|
|
}, {
|
|
"window_size" : 10,
|
|
"query" : {
|
|
"score_mode": "multiply",
|
|
"rescore_query" : {
|
|
"function_score" : {
|
|
"script_score": {
|
|
"script": {
|
|
"source": "Math.log10(doc.likes.value + 2)"
|
|
}
|
|
}
|
|
}
|
|
}
|
|
}
|
|
} ]
|
|
}
|
|
--------------------------------------------------
|
|
// CONSOLE
|
|
// TEST[setup:twitter]
|
|
|
|
The first one gets the results of the query then the second one gets the
|
|
results of the first, etc. The second rescore will "see" the sorting done
|
|
by the first rescore so it is possible to use a large window on the first
|
|
rescore to pull documents into a smaller window for the second rescore.
|