honeymoose
/
OpenSearch
mirror of https://github.com/honeymoose/OpenSearch.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
OpenSearch/plugins/examples/rescore/build.gradle

29 lines
1.2 KiB
Groovy
Raw Normal View History

# Rescore Feature The rescore feature allows te rescore a document returned by a query based on a secondary algorithm. Rescoring is commonly used if a scoring algorithm is too costly to be executed across the entire document set but efficient enough to be executed on the Top-K documents scored by a faster retrieval method. Rescoring can help to improve precision by reordering a larger Top-K window than actually returned to the user. Typically is it executed on a window between 100 and 500 documents while the actual result window requested by the user remains the same. # Query Rescorer The `query` rescorer executes a secondary query only on the Top-K results of the actual user query and rescores the documents based on a linear combination of the user query's score and the score of the `rescore_query`. This allows to execute any exposed query as a `rescore_query` and supports a `query_weight` as well as a `rescore_query_weight` to weight the factors of the linear combination. # Rescore API The `rescore` request is defined along side the query part in the json request: ```json curl -s -XPOST 'localhost:9200/_search' -d { "query" : { "match" : { "field1" : { "query" : "the quick brown", "type" : "boolean", "operator" : "OR" } } }, "rescore" : { "window_size" : 50, "query" : { "rescore_query" : { "match" : { "field1" : { "query" : "the quick brown", "type" : "phrase", "slop" : 2 } } }, "query_weight" : 0.7, "rescore_query_weight" : 1.2 } } } ``` Each `rescore` request is executed on a per-shard basis within the same roundtrip. Currently the rescore API has only one implementation (the `query` rescorer) which modifies the result set in-place. Future developments could include dedicated rescore results if needed by the implemenation ie. a pair-wise reranker. *Note:* Only regualr queries are rescored, if the search type is set to `scan` or `count` rescorers are not executed. Closes #2640
2013-01-30 11:27:35 -05:00
/*
Fix ASL Header in source files to reflect s/ElasticSearch/Elasticsearch This commit also removes the license to Shay Banon in favor of soley Elasticsearch. Thanks Shay for this awesome product you took it far! Closes #4636
2014-01-06 16:48:02 -05:00
* Licensed to Elasticsearch under one or more contributor
* license agreements. See the NOTICE file distributed with
* this work for additional information regarding copyright
* ownership. Elasticsearch licenses this file to you under
* the Apache License, Version 2.0 (the "License"); you may
* not use this file except in compliance with the License.
* You may obtain a copy of the License at
# Rescore Feature The rescore feature allows te rescore a document returned by a query based on a secondary algorithm. Rescoring is commonly used if a scoring algorithm is too costly to be executed across the entire document set but efficient enough to be executed on the Top-K documents scored by a faster retrieval method. Rescoring can help to improve precision by reordering a larger Top-K window than actually returned to the user. Typically is it executed on a window between 100 and 500 documents while the actual result window requested by the user remains the same. # Query Rescorer The `query` rescorer executes a secondary query only on the Top-K results of the actual user query and rescores the documents based on a linear combination of the user query's score and the score of the `rescore_query`. This allows to execute any exposed query as a `rescore_query` and supports a `query_weight` as well as a `rescore_query_weight` to weight the factors of the linear combination. # Rescore API The `rescore` request is defined along side the query part in the json request: ```json curl -s -XPOST 'localhost:9200/_search' -d { "query" : { "match" : { "field1" : { "query" : "the quick brown", "type" : "boolean", "operator" : "OR" } } }, "rescore" : { "window_size" : 50, "query" : { "rescore_query" : { "match" : { "field1" : { "query" : "the quick brown", "type" : "phrase", "slop" : 2 } } }, "query_weight" : 0.7, "rescore_query_weight" : 1.2 } } } ``` Each `rescore` request is executed on a per-shard basis within the same roundtrip. Currently the rescore API has only one implementation (the `query` rescorer) which modifies the result set in-place. Future developments could include dedicated rescore results if needed by the implemenation ie. a pair-wise reranker. *Note:* Only regualr queries are rescored, if the search type is set to `scan` or `count` rescorers are not executed. Closes #2640
2013-01-30 11:27:35 -05:00
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing,
* software distributed under the License is distributed on an
* "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
* KIND, either express or implied. See the License for the
* specific language governing permissions and limitations
* under the License.
*/
Allow plugins to plug rescore implementations (#26368) This allows plugins to plug rescore implementations into Elasticsearch. While this is a fairly expert thing to do I've done my best to point folks to the QueryRescorer as one that at least documents the tradeoffs that it makes. I've attempted to limit the API surface area by removing `SearchContext` from the exposed interface, instead exposing just the IndexSearcher and `QueryShardContext`. I also tried to make some of the class names more consistent and do some general cleanup while I was there. I entertained the notion of moving the `QueryRescorer` to module. After all, it'd be a wonderful test to prove that you can plug rescore implementation into Elasticsearch if the only built in rescore implementation is in the module. But I decided against it because the new module would require a client jar and it'd require moving some more things around. I think if we really want to do it, we should do it as a followup. I did, on the other hand, create an "example" rescore plugin which should both be a nice example for anyone wanting to plug in their own rescore implementation and servers as a good integration test to make sure that you can indeed plug one in. Closes #26208
2017-08-25 13:46:57 -04:00
apply plugin: 'elasticsearch.esplugin'
[7.x] Convert most OSS plugins from integTest to [yaml | java]RestTest or internalClusterTest (#59444) (#60343) For all OSS plugins (except repository-* and discovery-*) integTest task is now a no-op and all of the tests are now executed via a test, yamlRestTest, javaRestTest, or internalClusterTest. This commit does NOT convert the discovery-* and repository-* since they are bit more complex then the rest of tests and this PR is large enough. Those plugins will be addressed in a future PR(s). This commit also fixes a minor issue that did not copy the rest api for projects that only had YAML TEST tests. related: #56841
2020-07-29 14:06:13 -04:00
apply plugin: 'elasticsearch.yaml-rest-test'
# Rescore Feature The rescore feature allows te rescore a document returned by a query based on a secondary algorithm. Rescoring is commonly used if a scoring algorithm is too costly to be executed across the entire document set but efficient enough to be executed on the Top-K documents scored by a faster retrieval method. Rescoring can help to improve precision by reordering a larger Top-K window than actually returned to the user. Typically is it executed on a window between 100 and 500 documents while the actual result window requested by the user remains the same. # Query Rescorer The `query` rescorer executes a secondary query only on the Top-K results of the actual user query and rescores the documents based on a linear combination of the user query's score and the score of the `rescore_query`. This allows to execute any exposed query as a `rescore_query` and supports a `query_weight` as well as a `rescore_query_weight` to weight the factors of the linear combination. # Rescore API The `rescore` request is defined along side the query part in the json request: ```json curl -s -XPOST 'localhost:9200/_search' -d { "query" : { "match" : { "field1" : { "query" : "the quick brown", "type" : "boolean", "operator" : "OR" } } }, "rescore" : { "window_size" : 50, "query" : { "rescore_query" : { "match" : { "field1" : { "query" : "the quick brown", "type" : "phrase", "slop" : 2 } } }, "query_weight" : 0.7, "rescore_query_weight" : 1.2 } } } ``` Each `rescore` request is executed on a per-shard basis within the same roundtrip. Currently the rescore API has only one implementation (the `query` rescorer) which modifies the result set in-place. Future developments could include dedicated rescore results if needed by the implemenation ie. a pair-wise reranker. *Note:* Only regualr queries are rescored, if the search type is set to `scan` or `count` rescorers are not executed. Closes #2640
2013-01-30 11:27:35 -05:00
Allow plugins to plug rescore implementations (#26368) This allows plugins to plug rescore implementations into Elasticsearch. While this is a fairly expert thing to do I've done my best to point folks to the QueryRescorer as one that at least documents the tradeoffs that it makes. I've attempted to limit the API surface area by removing `SearchContext` from the exposed interface, instead exposing just the IndexSearcher and `QueryShardContext`. I also tried to make some of the class names more consistent and do some general cleanup while I was there. I entertained the notion of moving the `QueryRescorer` to module. After all, it'd be a wonderful test to prove that you can plug rescore implementation into Elasticsearch if the only built in rescore implementation is in the module. But I decided against it because the new module would require a client jar and it'd require moving some more things around. I think if we really want to do it, we should do it as a followup. I did, on the other hand, create an "example" rescore plugin which should both be a nice example for anyone wanting to plug in their own rescore implementation and servers as a good integration test to make sure that you can indeed plug one in. Closes #26208
2017-08-25 13:46:57 -04:00
esplugin {
name 'example-rescore'
description 'An example plugin implementing rescore and verifying that plugins *can* implement rescore'
classname 'org.elasticsearch.example.rescore.ExampleRescorePlugin'
RFC: Test that example plugins build stand-alone (#32235) Add tests for build-tools to make sure example plugins build stand-alone using it. This will catch issues such as referencing files from the buildSrc directly, breaking external uses of build-tools.
2018-08-17 02:41:39 -04:00
licenseFile rootProject.file('licenses/APACHE-LICENSE-2.0.txt')
noticeFile rootProject.file('NOTICE.txt')
# Rescore Feature The rescore feature allows te rescore a document returned by a query based on a secondary algorithm. Rescoring is commonly used if a scoring algorithm is too costly to be executed across the entire document set but efficient enough to be executed on the Top-K documents scored by a faster retrieval method. Rescoring can help to improve precision by reordering a larger Top-K window than actually returned to the user. Typically is it executed on a window between 100 and 500 documents while the actual result window requested by the user remains the same. # Query Rescorer The `query` rescorer executes a secondary query only on the Top-K results of the actual user query and rescores the documents based on a linear combination of the user query's score and the score of the `rescore_query`. This allows to execute any exposed query as a `rescore_query` and supports a `query_weight` as well as a `rescore_query_weight` to weight the factors of the linear combination. # Rescore API The `rescore` request is defined along side the query part in the json request: ```json curl -s -XPOST 'localhost:9200/_search' -d { "query" : { "match" : { "field1" : { "query" : "the quick brown", "type" : "boolean", "operator" : "OR" } } }, "rescore" : { "window_size" : 50, "query" : { "rescore_query" : { "match" : { "field1" : { "query" : "the quick brown", "type" : "phrase", "slop" : 2 } } }, "query_weight" : 0.7, "rescore_query_weight" : 1.2 } } } ``` Each `rescore` request is executed on a per-shard basis within the same roundtrip. Currently the rescore API has only one implementation (the `query` rescorer) which modifies the result set in-place. Future developments could include dedicated rescore results if needed by the implemenation ie. a pair-wise reranker. *Note:* Only regualr queries are rescored, if the search type is set to `scan` or `count` rescorers are not executed. Closes #2640
2013-01-30 11:27:35 -05:00
}