-
Notifications
You must be signed in to change notification settings - Fork 25.6k
Vector rescoring - Simplify code for k == null #118997
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Vector rescoring - Simplify code for k == null #118997
Conversation
… retrieve from each shard
* original vector values stored in the index | ||
*/ | ||
public class VectorSimilarityFloatValueSource extends DoubleValuesSource implements QueryProfilerProvider { | ||
public class VectorSimilarityFloatValueSource extends DoubleValuesSource { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Profiling can be simplified, as we always know the number of results to return
|
||
// Retrieve top k documents from the rescored query | ||
TopDocs topDocs = searcher.search(query, k); | ||
vectorOperations = topDocs.totalHits.value(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We know in advance the number of comparisons done
} | ||
|
||
@ParametersFactory | ||
public static Iterable<Object[]> parameters() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We always have a specific k, it makes no sense to use parameters.
@elasticmachine update branch |
@elasticmachine update branch |
…se-size-as-k' into non-issue/rescore-vector-use-size-as-k
Pinging @elastic/es-search-relevance (Team:Search Relevance) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good cleanup. Also, I removed the v8.9 tag, I think you added that by accident.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually, one of the things I thought we should do is switch to use k
as the oversampling and not num candidates. That was one of the original reasons for the overall change of eagerly setting k
to request size.
Oh yeah, it all started with this conversation. I can work on that as a follow up - and get back the original design: {
"query": {
"knn": {
"field": "emb",
"query_vector": [...],
"k": 10,
"num_candidates": 100,
"rescore_vector": {
"oversample": 2.0
}
}
}
} This will mean rescoring I'll merge this and start working on it. Draft PR: #119835 |
💔 Backport failed
You can use sqren/backport to manually backport by running |
💚 All backports created successfully
Questions ?Please refer to the Backport tool documentation |
Following up on #116663 and #118774
#118774 makes k to be always specified, defaulting to size in case it's null.
This allows to perform some simplifications on rescoring, as we'll always have k to limit the results returned per shard.