From 5100f327aa2857022b61bcb32c13651f1023210f Mon Sep 17 00:00:00 2001 From: Julie Tibshirani Date: Wed, 26 Jan 2022 15:57:15 -0800 Subject: [PATCH 1/2] Add notes on indexing to kNN search guide This change adds a new 'indexing considerations' section that explains why index calls can be slow and how force merge can help search latency. --- .../mapping/types/dense-vector.asciidoc | 2 -- .../search-your-data/knn-search.asciidoc | 36 ++++++++++++------- 2 files changed, 24 insertions(+), 14 deletions(-) diff --git a/docs/reference/mapping/types/dense-vector.asciidoc b/docs/reference/mapping/types/dense-vector.asciidoc index 120168f80560f..04b28a4733039 100644 --- a/docs/reference/mapping/types/dense-vector.asciidoc +++ b/docs/reference/mapping/types/dense-vector.asciidoc @@ -91,11 +91,9 @@ PUT my-index-2 efficient kNN search. Like most kNN algorithms, HNSW is an approximate method that sacrifices result accuracy for improved speed. -//tag::dense-vector-indexing-speed[] NOTE: Indexing vectors for approximate kNN search is an expensive process. It can take substantial time to ingest documents that contain vector fields with `index` enabled. -//end::dense-vector-indexing-speed[] Dense vector fields cannot be indexed if they are within <> mappings. diff --git a/docs/reference/search/search-your-data/knn-search.asciidoc b/docs/reference/search/search-your-data/knn-search.asciidoc index 8eae842d10b5c..47eb11835ea0d 100644 --- a/docs/reference/search/search-your-data/knn-search.asciidoc +++ b/docs/reference/search/search-your-data/knn-search.asciidoc @@ -46,15 +46,13 @@ based on a similarity metric, the better its match. vector function In most cases, you'll want to use approximate kNN. Approximate kNN offers lower -latency and better support for large datasets at the cost of slower indexing and -reduced accuracy. However, you can configure this method for higher accuracy in -exchange for slower searches. +at the cost of slower indexing and imperfect accuracy. Exact, brute-force kNN guarantees accurate results but doesn't scale well with -large, unfiltered datasets. With this approach, a `script_score` query must scan -each matched document to compute the vector function, which can result in slow -search speeds. However, you can improve latency by using the <> to limit the number of matched documents passed to the function. If you +large datasets. With this approach, a `script_score` query must scan each +matching document to compute the vector function, which can result in slow +search speeds. However, you can improve latency by using a <> +to limit the number of matching documents passed to the function. If you filter your data to a small subset of documents, you can get good search performance using this approach. @@ -78,8 +76,6 @@ score documents based on similarity between the query and document vector. For a list of available metrics, see the <> parameter documentation. -include::{es-repo-dir}/mapping/types/dense-vector.asciidoc[tag=dense-vector-indexing-speed] - [source,console] ---- PUT my-approx-knn-index @@ -156,13 +152,29 @@ most similar results from each shard. The search then merges the results from each shard to return the global top `k` nearest neighbors. You can increase `num_candidates` for more accurate results at the cost of -slower search speeds. A search with a high number of `num_candidates` considers -more candidates from each shard. This takes more time, but the search has a -higher probability of finding the true `k` top nearest neighbors. +slower search speeds. A search with a high value for `num_candidates` +considers more candidates from each shard. This takes more time, but the +search has a higher probability of finding the true `k` top nearest neighbors. Similarly, you can decrease `num_candidates` for faster searches with potentially less accurate results. +[discrete] +[[knn-indexing-considerations]] +==== Indexing considerations + +Indexing vectors for approximate kNN search can take substantial time because +of how expensive it is to build the ANN index structures. You may need to +increase the client request timeout for index and bulk requests. + +Elasticsearch shards are composed of segments, which are internal storage +elements in the index. <> the index to a +single segment can improve kNN search latency. With only one segment, the +search needs to check a single, all-inclusive HNSW graph. But when there are +multiple segments, kNN search must check several smaller HNSW graphs as it +searches each segment after another. Note that you should only force merge an +index if it is no longer being written to. + [discrete] [[approximate-knn-limitations]] ==== Limitations for approximate kNN search From 58f99409633b87d6dda7559ea5a943935c9ef356 Mon Sep 17 00:00:00 2001 From: Julie Tibshirani Date: Fri, 28 Jan 2022 10:10:15 -0800 Subject: [PATCH 2/2] Address review feedback --- .../search-your-data/knn-search.asciidoc | 25 ++++++++++--------- 1 file changed, 13 insertions(+), 12 deletions(-) diff --git a/docs/reference/search/search-your-data/knn-search.asciidoc b/docs/reference/search/search-your-data/knn-search.asciidoc index 47eb11835ea0d..f416e7e18d078 100644 --- a/docs/reference/search/search-your-data/knn-search.asciidoc +++ b/docs/reference/search/search-your-data/knn-search.asciidoc @@ -46,7 +46,7 @@ based on a similarity metric, the better its match. vector function In most cases, you'll want to use approximate kNN. Approximate kNN offers lower -at the cost of slower indexing and imperfect accuracy. +latency at the cost of slower indexing and imperfect accuracy. Exact, brute-force kNN guarantees accurate results but doesn't scale well with large datasets. With this approach, a `script_score` query must scan each @@ -163,17 +163,18 @@ potentially less accurate results. [[knn-indexing-considerations]] ==== Indexing considerations -Indexing vectors for approximate kNN search can take substantial time because -of how expensive it is to build the ANN index structures. You may need to -increase the client request timeout for index and bulk requests. - -Elasticsearch shards are composed of segments, which are internal storage -elements in the index. <> the index to a -single segment can improve kNN search latency. With only one segment, the -search needs to check a single, all-inclusive HNSW graph. But when there are -multiple segments, kNN search must check several smaller HNSW graphs as it -searches each segment after another. Note that you should only force merge an -index if it is no longer being written to. +{es} shards are composed of segments, which are internal storage elements in the +index. For approximate kNN search, {es} stores the dense vector values of each +segment as an https://arxiv.org/abs/1603.09320[HNSW graph]. Indexing vectors for +approximate kNN search can take substantial time because of how expensive it is +to build these graphs. You may need to increase the client request timeout for +index and bulk requests. + +<> the index to a single segment can improve +kNN search latency. With only one segment, the search needs to check a single, +all-inclusive HNSW graph. When there are multiple segments, kNN search must +check several smaller HNSW graphs as it searches each segment after another. +You should only force merge an index if it is no longer being written to. [discrete] [[approximate-knn-limitations]]