You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/reference/mapping/types/dense-vector.asciidoc
+3-1Lines changed: 3 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -121,11 +121,13 @@ The three following quantization strategies are supported:
121
121
* `bbq` - experimental:[] Better binary quantization which reduces each dimension to a single bit precision. This reduces the memory footprint by 96% (or 32x) at a larger cost of accuracy. Generally, oversampling during query time and reranking can help mitigate the accuracy loss.
122
122
123
123
124
-
When using a quantized format, you may want to oversample and rescore the results to improve accuracy. See <<dense-vector-knn-search-reranking, oversampling and rescoring>> for more information.
124
+
When using a quantized format, you may want to oversample and rescore the results to improve accuracy. See <<dense-vector-knn-search-rescoring, oversampling and rescoring>> for more information.
125
125
126
126
To use a quantized index, you can set your index type to `int8_hnsw`, `int4_hnsw`, or `bbq_hnsw`. When indexing `float` vectors, the current default
127
127
index type is `int8_hnsw`.
128
128
129
+
Quantized vectors can use <<dense-vector-knn-search-rescoring,oversampling and rescoring>> to improve accuracy on approximate kNN search results.
130
+
129
131
NOTE: Quantization will continue to keep the raw float vector values on disk for reranking, reindexing, and quantization improvements over the lifetime of the data.
130
132
This means disk usage will increase by ~25% for `int8`, ~12.5% for `int4`, and ~3.1% for `bbq` due to the overhead of storing the quantized and raw vectors.
Copy file name to clipboardExpand all lines: docs/reference/rest-api/common-parms.asciidoc
+24Lines changed: 24 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1346,3 +1346,27 @@ tag::rrf-filter[]
1346
1346
Applies the specified <<query-dsl-bool-query, boolean query filter>> to all of the specified sub-retrievers,
1347
1347
according to each retriever's specifications.
1348
1348
end::rrf-filter[]
1349
+
1350
+
tag::knn-rescore-vector[]
1351
+
1352
+
`rescore_vector`::
1353
+
+
1354
+
--
1355
+
(Optional, object) Functionality in preview:[]. Apply oversampling and rescoring to quantized vectors.
1356
+
1357
+
NOTE: Rescoring only makes sense for quantized vectors; when <<dense-vector-quantization,quantization>> is not used, the original vectors are used for scoring.
1358
+
Rescore option will be ignored for non-quantized `dense_vector` fields.
1359
+
1360
+
`oversample`::
1361
+
(Required, float)
1362
+
+
1363
+
Applies the specified oversample factor to `k` on the approximate kNN search.
1364
+
The approximate kNN search will:
1365
+
1366
+
* Retrieve `num_candidates` candidates per shard.
1367
+
* From these candidates, the top `k * oversample` candidates per shard will be rescored using the original vectors.
1368
+
* The top `k` rescored candidates will be returned.
1369
+
1370
+
See <<dense-vector-knn-search-rescoring,oversampling and rescoring quantized vectors>> for details.
The parameters `query_vector` and `query_vector_builder` cannot be used together.
@@ -571,15 +573,15 @@ This examples demonstrates how to deploy the Elastic Rerank model and use it to
571
573
572
574
Follow these steps:
573
575
574
-
. Create an inference endpoint for the `rerank` task using the <<put-inference-api, Create {infer} API>>.
576
+
. Create an inference endpoint for the `rerank` task using the <<put-inference-api, Create {infer} API>>.
575
577
+
576
578
[source,console]
577
579
----
578
580
PUT _inference/rerank/my-elastic-rerank
579
581
{
580
582
"service": "elasticsearch",
581
583
"service_settings": {
582
-
"model_id": ".rerank-v1",
584
+
"model_id": ".rerank-v1",
583
585
"num_threads": 1,
584
586
"adaptive_allocations": { <1>
585
587
"enabled": true,
@@ -590,7 +592,7 @@ PUT _inference/rerank/my-elastic-rerank
590
592
}
591
593
----
592
594
// TEST[skip:uses ML]
593
-
<1> {ml-docs}/ml-nlp-auto-scale.html#nlp-model-adaptive-allocations[Adaptive allocations] will be enabled with the minimum of 1 and the maximum of 10 allocations.
595
+
<1> {ml-docs}/ml-nlp-auto-scale.html#nlp-model-adaptive-allocations[Adaptive allocations] will be enabled with the minimum of 1 and the maximum of 10 allocations.
the global top `k` matches across shards. You cannot set the
1067
1067
`search_type` explicitly when running kNN search.
1068
1068
1069
+
1069
1070
[discrete]
1070
-
[[exact-knn]]
1071
-
=== Exact kNN
1071
+
[[dense-vector-knn-search-rescoring]]
1072
+
==== Oversampling and rescoring for quantized vectors
1072
1073
1073
-
To run an exact kNN search, use a `script_score` query with a vector function.
1074
+
When using <<dense-vector-quantization,quantized vectors>> for kNN search, you can optionally rescore results to balance performance and accuracy, by doing:
1074
1075
1075
-
. Explicitly map one or more `dense_vector` fields. If you don't intend to use
1076
-
the field for approximate kNN, set the `index` mapping option to `false`. This
1077
-
can significantly improve indexing speed.
1078
-
+
1079
-
[source,console]
1080
-
----
1081
-
PUT product-index
1082
-
{
1083
-
"mappings": {
1084
-
"properties": {
1085
-
"product-vector": {
1086
-
"type": "dense_vector",
1087
-
"dims": 5,
1088
-
"index": false
1089
-
},
1090
-
"price": {
1091
-
"type": "long"
1092
-
}
1093
-
}
1094
-
}
1095
-
}
1096
-
----
1076
+
* *Oversampling*: Retrieve more candidates per shard.
1077
+
* *Rescoring*: Use the original vector values for re-calculating the score on the oversampled candidates.
As the non-quantized, original vectors are used to calculate the final score on the top results, rescoring combines:
1080
+
1081
+
* The performance and memory gains of approximate retrieval using quantized vectors for retrieving the top candidates.
1082
+
* The accuracy of using the original vectors for rescoring the top candidates.
1083
+
1084
+
All forms of quantization will result in some accuracy loss and as the quantization level increases the accuracy loss will also increase.
1085
+
Generally, we have found that:
1086
+
1087
+
* `int8` requires minimal if any rescoring
1088
+
* `int4` requires some rescoring for higher accuracy and larger recall scenarios. Generally, oversampling by 1.5x-2x recovers most of the accuracy loss.
1089
+
* `bbq` requires rescoring except on exceptionally large indices or models specifically designed for quantization. We have found that between 3x-5x oversampling is generally sufficient. But for fewer dimensions or vectors that do not quantize well, higher oversampling may be required.
1090
+
1091
+
You can use the `rescore_vector` preview:[] option to automatically perform reranking.
1092
+
When a rescore `oversample` parameter is specified, the approximate kNN search will:
1093
+
1094
+
* Retrieve `num_candidates` candidates per shard.
1095
+
* From these candidates, the top `k * oversample` candidates per shard will be rescored using the original vectors.
1096
+
* The top `k` rescored candidates will be returned.
1097
+
1098
+
Here is an example of using the `rescore_vector` option with the `oversample` parameter:
1113
1099
1114
-
. Use the <<search-search,search API>> to run a `script_score` query containing
1115
-
a <<vector-functions,vector function>>.
1116
-
+
1117
-
TIP: To limit the number of matched documents passed to the vector function, we
1118
-
recommend you specify a filter query in the `script_score.query` parameter. If
1119
-
needed, you can use a <<query-dsl-match-all-query,`match_all` query>> in this
1120
-
parameter to match all documents. However, matching all documents can
All forms of quantization will result in some accuracy loss and as the quantization level increases the accuracy loss will also increase.
1157
-
Generally, we have found that:
1158
-
- `int8` requires minimal if any rescoring
1159
-
- `int4` requires some rescoring for higher accuracy and larger recall scenarios. Generally, oversampling by 1.5x-2x recovers most of the accuracy loss.
1160
-
- `bbq` requires rescoring except on exceptionally large indices or models specifically designed for quantization. We have found that between 3x-5x oversampling is generally sufficient. But for fewer dimensions or vectors that do not quantize well, higher oversampling may be required.
1131
+
The following sections provide additional ways of rescoring:
====== Use the `rescore` section for top-level kNN search
1136
+
1137
+
You can use this option when you don't want to rescore on each shard, but on the top results from all shards.
1161
1138
1162
-
There are two main ways to oversample and rescore. The first is to utilize the <<rescore, rescore section>> in the `_search` request.
1139
+
Use the <<rescore, rescore section>> in the `_search` request to rescore the top results from a kNN search.
1163
1140
1164
1141
Here is an example using the top level `knn` search with oversampling and using `rescore` to rerank the results:
1165
1142
@@ -1208,8 +1185,16 @@ gathering 20 nearest neighbors according to quantized scoring and rescoring with
1208
1185
<5> The weight of the original query, here we simply throw away the original score
1209
1186
<6> The weight of the rescore query, here we only use the rescore query
1210
1187
1211
-
The second way is to score per shard with the <<query-dsl-knn-query, knn query>> and <<query-dsl-script-score-query, script_score query >>. Generally, this means that there will be more rescoring per shard, but this
1212
-
can increase overall recall at the cost of compute.
0 commit comments