Support search_type in Rank Evaluation API
#48503
Assignees
Labels
>enhancement
:Search Relevance/Ranking
Scoring, rescoring, rank evaluation.
Team:Search Relevance
Meta label for the Search Relevance team in Elasticsearch
Comments
cbuescher
added
:Search Relevance/Ranking
|
Pinging @elastic/es-search (:Search/Ranking) |
cbuescher
pushed a commit
to cbuescher/elasticsearch
that referenced
this issue
Oct 25, 2019
Adding support for the `search_type` request parameter to the Ranking Evaluation API since this parameter can impact the ranking and the metric score and should be choosen in the same way when evaluating the search as later in the real search. Closes elastic#48503
cbuescher
pushed a commit
that referenced
this issue
Oct 29, 2019
Adding support for the `search_type` request parameter to the Ranking Evaluation API since this parameter can impact the ranking and the metric score and should be choosen in the same way when evaluating the search as later in the real search. Closes #48503
cbuescher
pushed a commit
to cbuescher/elasticsearch
that referenced
this issue
Oct 29, 2019
Adding support for the `search_type` request parameter to the Ranking Evaluation API since this parameter can impact the ranking and the metric score and should be choosen in the same way when evaluating the search as later in the real search. Closes elastic#48503
cbuescher
pushed a commit
that referenced
this issue
Oct 29, 2019
Adding support for the `search_type` request parameter to the Ranking Evaluation API since this parameter can impact the ranking and the metric score and should be choosen in the same way when evaluating the search as later in the real search. Closes #48503
This was referenced Feb 3, 2020
javanna
added
the
Team:Search Relevance
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The Rank Evaluation API could benefit from adding support for the
search_typequery string parameters.I have a (small) set of identical documents that would score equally when using
search_type=dfs_query_then_fetchbut be "very" different when not.This could impact the ranking and therefore the metric score as well. So when comparing different approaches to queries / analyzers it is hard to tell whether the differences in metric scores is caused by the different approaches or where the documents are stored.
One workaround is to ensure there is only 1 node, 1 shard and 0 replicas in your test setup.
The text was updated successfully, but these errors were encountered: