Dense vector field type

The dense_vector field type stores dense vectors of numeric values. Dense vector fields are primarily used for k-nearest neighbor (kNN) search.

The dense_vector type does not support aggregations or sorting.

You add a dense_vector field as an array of numeric values based on element_type with float by default:

 PUT my-index {
  "mappings": {
    "properties": {
      "my_vector": {
        "type": "dense_vector",
        "dims": 3
      },
      "my_text" : {
        "type" : "keyword"
      }
    }
  }
}

PUT my-index/_doc/1
{
  "my_text" : "text1",
  "my_vector" : [0.5, 10, 6]
}

PUT my-index/_doc/2
{
  "my_text" : "text2",
  "my_vector" : [-0.5, 10, 10]
}

A k-nearest neighbor (kNN) search finds the k nearest vectors to a query vector, as measured by a similarity metric.

Dense vector fields can be used to rank documents in script_score queries. This lets you perform a brute-force kNN search by scanning all documents and ranking them by similarity.

In many cases, a brute-force kNN search is not efficient enough. For this reason, the dense_vector type supports indexing vectors into a specialized data structure to support fast kNN retrieval through the knn option in the search API

Unmapped array fields of float elements with size between 128 and 4096 are dynamically mapped as dense_vector with a default similariy of cosine. You can override the default similarity by explicitly mapping the field as dense_vector with the desired similarity.

Indexing is enabled by default for dense vector fields and indexed as int8_hnsw. When indexing is enabled, you can define the vector similarity to use in kNN search:

 PUT my-index-2 {
  "mappings": {
    "properties": {
      "my_vector": {
        "type": "dense_vector",
        "dims": 3,
        "similarity": "dot_product"
      }
    }
  }
}

You can disable indexing by setting the index parameter to false:

 PUT my-index-2 {
  "mappings": {
    "properties": {
      "my_vector": {
        "type": "dense_vector",
        "dims": 3,
        "index": false
      }
    }
  }
}

Elasticsearch uses the HNSW algorithm to support efficient kNN search. Like most kNN algorithms, HNSW is an approximate method that sacrifices result accuracy for improved speed.

The dense_vector type supports quantization to reduce the memory footprint required when searching float vectors. The three following quantization strategies are supported:

• int8 - Quantizes each dimension of the vector to 1-byte integers. This reduces the memory footprint by 75% (or 4x) at the cost of some accuracy.
• int4 - Quantizes each dimension of the vector to half-byte integers. This reduces the memory footprint by 87% (or 8x) at the cost of accuracy.
• bbq - 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.

When using a quantized format, you may want to oversample and rescore the results to improve accuracy. See oversampling and rescoring for more information.

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 index type is int8_hnsw.

Quantized vectors can use oversampling and rescoring to improve accuracy on approximate kNN search results.

Here is an example of how to create a byte-quantized index:

 PUT my-byte-quantized-index {
  "mappings": {
    "properties": {
      "my_vector": {
        "type": "dense_vector",
        "dims": 3,
        "index": true,
        "index_options": {
          "type": "int8_hnsw"
        }
      }
    }
  }
}

Here is an example of how to create a half-byte-quantized index:

 PUT my-byte-quantized-index {
  "mappings": {
    "properties": {
      "my_vector": {
        "type": "dense_vector",
        "dims": 4,
        "index": true,
        "index_options": {
          "type": "int4_hnsw"
        }
      }
    }
  }
}

Here is an example of how to create a binary quantized index:

 PUT my-byte-quantized-index {
  "mappings": {
    "properties": {
      "my_vector": {
        "type": "dense_vector",
        "dims": 64,
        "index": true,
        "index_options": {
          "type": "bbq_hnsw"
        }
      }
    }
  }
}

The following mapping parameters are accepted:

element_type

(Optional, string) The data type used to encode vectors. The supported data types are float (default), byte, and bit.

dims

(Optional, integer) Number of vector dimensions. Can’t exceed 4096. If dims is not specified, it will be set to the length of the first vector added to the field.

index

(Optional, Boolean) If true, you can search this field using the knn query or knn in _search . Defaults to true.

similarity

(Optional*, string) The vector similarity metric to use in kNN search. Documents are ranked by their vector field’s similarity to the query vector. The _score of each document will be derived from the similarity, in a way that ensures scores are positive and that a larger score corresponds to a higher ranking. Defaults to l2_norm when element_type: bit otherwise defaults to cosine.

• This parameter can only be specified when index is true.

Note

bit vectors only support l2_norm as their similarity metric.

index_options

(Optional*, object) An optional section that configures the kNN indexing algorithm. The HNSW algorithm has two internal parameters that influence how the data structure is built. These can be adjusted to improve the accuracy of results, at the expense of slower indexing speed.

• This parameter can only be specified when index is true.

Properties of `index_options`

type

(Required, string) The type of kNN algorithm to use. Can be either any of:

* hnsw - This utilizes the HNSW algorithm for scalable approximate kNN search. This supports all element_type values. * int8_hnsw - The default index type for float vectors. This utilizes the HNSW algorithm in addition to automatically scalar quantization for scalable approximate kNN search with element_type of float. This can reduce the memory footprint by 4x at the cost of some accuracy. See Automatically quantize vectors for kNN search. * int4_hnsw - This utilizes the HNSW algorithm in addition to automatically scalar quantization for scalable approximate kNN search with element_type of float. This can reduce the memory footprint by 8x at the cost of some accuracy. See Automatically quantize vectors for kNN search. * bbq_hnsw - This utilizes the HNSW algorithm in addition to automatically binary quantization for scalable approximate kNN search with element_type of float. This can reduce the memory footprint by 32x at the cost of accuracy. See Automatically quantize vectors for kNN search. * flat - This utilizes a brute-force search algorithm for exact kNN search. This supports all element_type values. * int8_flat - This utilizes a brute-force search algorithm in addition to automatically scalar quantization. Only supports element_type of float. * int4_flat - This utilizes a brute-force search algorithm in addition to automatically half-byte scalar quantization. Only supports element_type of float. * bbq_flat - This utilizes a brute-force search algorithm in addition to automatically binary quantization. Only supports element_type of float.

m

(Optional, integer) The number of neighbors each node will be connected to in the HNSW graph. Defaults to 16. Only applicable to hnsw, int8_hnsw, int4_hnsw and bbq_hnsw index types.

ef_construction

(Optional, integer) The number of candidates to track while assembling the list of nearest neighbors for each new node. Defaults to 100. Only applicable to hnsw, int8_hnsw, int4_hnsw and bbq_hnsw index types.

confidence_interval

(Optional, float) Only applicable to int8_hnsw, int4_hnsw, int8_flat, and int4_flat index types. The confidence interval to use when quantizing the vectors. Can be any value between and including 0.90 and 1.0 or exactly 0. When the value is 0, this indicates that dynamic quantiles should be calculated for optimized quantization. When between 0.90 and 1.0, this value restricts the values used when calculating the quantization thresholds. For example, a value of 0.95 will only use the middle 95% of the values when calculating the quantization thresholds (e.g. the highest and lowest 2.5% of values will be ignored). Defaults to 1/(dims + 1) for int8 quantized vectors and 0 for int4 for dynamic quantile calculation.

dense_vector fields support synthetic _source .

When using element_type: bit, this will treat all vectors as bit vectors. Bit vectors utilize only a single bit per dimension and are internally encoded as bytes. This can be useful for very high-dimensional vectors or models.

When using bit, the number of dimensions must be a multiple of 8 and must represent the number of bits. Additionally, with bit vectors, the typical vector similarity values are effectively all scored the same, e.g. with hamming distance.

Let’s compare two byte[] arrays, each representing 40 individual bits.

[-127, 0, 1, 42, 127] in bits 1000000100000000000000010010101001111111 [127, -127, 0, 1, 42] in bits 0111111110000001000000000000000100101010

When comparing these two bit, vectors, we first take the hamming distance.

xor result:

1000000100000000000000010010101001111111
^
0111111110000001000000000000000100101010
=
1111111010000001000000010010101101010101

Then, we gather the count of 1 bits in the xor result: 18. To scale for scoring, we subtract from the total number of bits and divide by the total number of bits: (40 - 18) / 40 = 0.55. This would be the _score betwee these two vectors.

Here is an example of indexing and searching bit vectors:

 PUT my-bit-vectors {
  "mappings": {
    "properties": {
      "my_vector": {
        "type": "dense_vector",
        "dims": 40, 1
        "element_type": "bit"
      }
    }
  }
}

1. The number of dimensions that represents the number of bits

 POST /my-bit-vectors/_bulk?refresh {"index": {"_id" : "1"}}
{"my_vector": [127, -127, 0, 1, 42]} 1
{"index": {"_id" : "2"}}
{"my_vector": "8100012a7f"} 2

1. 5 bytes representing the 40 bit dimensioned vector
2. A hexidecimal string representing the 40 bit dimensioned vector

Then, when searching, you can use the knn query to search for similar bit vectors:

 POST /my-bit-vectors/_search?filter_path=hits.hits {
  "query": {
    "knn": {
      "query_vector": [127, -127, 0, 1, 42],
      "field": "my_vector"
    }
  }
}

{
    "hits": {
        "hits": [
            {
                "_index": "my-bit-vectors",
                "_id": "1",
                "_score": 1.0,
                "_source": {
                    "my_vector": [
                        127,
                        -127,
                        0,
                        1,
                        42
                    ]
                }
            },
            {
                "_index": "my-bit-vectors",
                "_id": "2",
                "_score": 0.55,
                "_source": {
                    "my_vector": "8100012a7f"
                }
            }
        ]
    }
}

To better accommodate scaling and performance needs, updating the type setting in index_options is possible with the Update Mapping API, according to the following graph (jumps allowed):

flat --> int8_flat --> int4_flat --> hnsw --> int8_hnsw --> int4_hnsw

For updating all HNSW types (hnsw, int8_hnsw, int4_hnsw) the number of connections m must either stay the same or increase. For scalar quantized formats (int8_flat, int4_flat, int8_hnsw, int4_hnsw) the confidence_interval must always be consistent (once defined, it cannot change).

Updating type in index_options will fail in all other scenarios.

Switching types won’t re-index vectors that have already been indexed (they will keep using their original type), vectors being indexed after the change will use the new type instead.

For example, it’s possible to define a dense vector field that utilizes the flat type (raw float32 arrays) for a first batch of data to be indexed.

 PUT my-index-000001 {
    "mappings": {
        "properties": {
            "text_embedding": {
                "type": "dense_vector",
                "dims": 384,
                "index_options": {
                    "type": "flat"
                }
            }
        }
    }
}

Changing the type to int4_hnsw makes sure vectors indexed after the change will use an int4 scalar quantized representation and HNSW (e.g., for KNN queries). That includes new segments created by merging previously created segments.

 PUT /my-index-000001/_mapping {
    "properties": {
        "text_embedding": {
            "type": "dense_vector",
            "dims": 384,
            "index_options": {
                "type": "int4_hnsw"
            }
        }
    }
}

Vectors indexed before this change will keep using the flat type (raw float32 representation and brute force search for KNN queries).

In order to have all the vectors updated to the new type, either reindexing or force merging should be used.

For debugging purposes, it’s possible to inspect how many segments (and docs) exist for each type with the Index Segments API.