KNN custom scoring #329
KNN custom scoring #329
Conversation
aetter
added
the
upcoming release
docs/knn/index.md
Outdated
| } | ||
| ``` | ||
|
|
||
| If you *only* want to use KNN's custom scoring, you can omit `"index.knn": true`, but you lose the ability to perform standard KNN queries on the index. The benefit of this approach is faster indexing speed and lower memory usage. |
There was a problem hiding this comment.
How about we change to below?
The benefit of this approach is minimal search latencies as the graphs are prebuilt with provided vectors during indexing and then cached for later queries.
There was a problem hiding this comment.
So the goal here was actually to talk about the benefit of a false setting. I can tweak the wording there since that wasn't clear.
Anyway, let me know if I actually resolved your concern here or if I'm just not getting it. 😄
| } | ||
| ``` | ||
|
|
||
| In this case, `k` is the number of neighbors you want the query to return, but you must also include the `size` option. Otherwise, you get `k` results for each shard (and each segment) rather than `k` results for the entire query. The plugin supports a maximum `k` value of 10,000. |
There was a problem hiding this comment.
Does this mean that size and k should always have the same value?
| ## Custom scoring | ||
|
|
||
| The [previous example](#mixing-queries) shows a search that returns fewer than `k` results. If you want to avoid this situation, KNN's custom scoring option lets you essentially invert the order of events. | ||
|
|
There was a problem hiding this comment.
Does this imply that if the filter option reduces the number of results below the value of k, then the filter doesn't take effect?
4 participants
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.