Atlas Vector Search automatic quantization and rescoring

Published reference · snapshot 2026-10-20 · skill mongodb-operations-expert/references/atlas-vector-search-automatic-quantization-and-rescoring.md · viability 3.20 / 5 (skip)

↓ Facts as markdown all context files

Source-anchored research for Atlas Vector Search automatic quantization and rescoring. Run status: COMPLETED.

These notes link each claim to its source. Some citations identify archived research reports that are no longer hosted on this site. A published reference means the content is available; it does not certify independent review or accuracy.Read the editorial policy and follow the sources before relying on a claim.

Structure and components

Only `binary` quantization rescores. After the binary pass, Atlas re-evaluates the candidates with the original float vectors. Scalar quantization has no rescoring step. The full-fidelity vectors live in a separate on-disk structure and are read only for binary rescoring or for exact (ENN) search. (high confidence) [source]
Atlas binary quantization compares each dimension with a fixed midpoint of 0 (above 0 becomes 1), which the docs say suits embeddings normalized to length 1. Other engines treat centering as a precondition. Qdrant says binary quantization 'requires a centered distribution' of components. Azure AI Search says it works best when embeddings are centered around zero. Lucene's BBQ normalizes vectors around a per-segment centroid. (medium confidence) [source]
A 2026 single-author arXiv preprint (not peer reviewed) argues that binary-quantization ranking fidelity depends on the full covariance structure of the embedding space (off-diagonal terms supply 30-50% of the signal) and on per-coordinate variance heterogeneity. It tests 18 datasets across 9 embedding families. This is a theoretical reason binary quantization works on some models and fails on others. (low confidence) (verified as of 2026-05-29) [source]
Atlas keeps the full-fidelity vectors on disk in a separate data structure. It reads them only for binary rescoring and for exact (ENN, `exact: true`) search. When automatic quantization is enabled, ENN queries use only the full-fidelity vectors. (high confidence) [source]
Low-dimension embeddings fit aggressive quantization poorly. MongoDB recommends at least 1024 dimensions with quantization over fewer dimensions without it, and its 1024-d and larger vectors reached the recall target at lower `numCandidates`. Elastic warns that BBQ datasets under 384 dimensions may see less accuracy. Qdrant says binary quantization works best on high-dimensional embeddings with centered components. (medium confidence) (verified as of 2026-10-20) [source]

How it works

On Atlas, automatic quantization is opt-in per vector field. The `fields.quantization` setting in the index definition takes `none` (the default), `scalar` (1-byte integers) or `binary` (1 bit). The choice applies to all indexed vectors and to query vectors at query time, so queries need no change. Changing it triggers an index rebuild. (high confidence) [source]
Exact (ENN) queries on a quantized index use only the full-fidelity vectors, so ENN results are the ground truth for judging ANN recall on that index. Azure AI Search likewise does not rescore exhaustive KNN, because every vector is already scanned. (high confidence) [source]
After enabling quantization, the Atlas UI index Size can grow, because Size totals the HNSW graph and quantized vectors (memory) plus the full-fidelity vectors (disk). Read the Required Memory figure (added at GA on 2025-04-29) to estimate query-time RAM. (high confidence) [source]
Atlas Vector Search quantizes float vectors automatically when the vector index definition sets `fields.quantization` to `scalar` or `binary`. If `quantization` is omitted on a `vector` field, the value is `none` and Atlas indexes full-fidelity vectors. Changing the value rebuilds the index. The setting covers indexed vectors and query vectors, so query code does not change. (high confidence) [source]
Scalar quantization splits each dimension's min-to-max range into equal bins and stores each float as an int8 integer. It cuts mongot RAM for the vector values to about 1/3.75. Binary quantization compares each value to a midpoint of 0 and stores one bit. It cuts RAM to about 1/24, not 1/32, because the HNSW graph is not compressed. (high confidence) [source]
Rescoring runs only when `quantization` is `binary`. Atlas converts the query vector to binary with the same midpoint, finds candidates in the binary HNSW index, then re-evaluates those candidates with the stored full-fidelity float vectors. Scalar quantization does not rescore. (high confidence) [source]
For `autoEmbed` index fields (Automated Embedding, a Preview feature), `quantization` takes `float`, `scalar`, `binary` or `binaryNoRescore` and defaults to `scalar` when omitted. `binary` keeps full-precision vectors and rescores with them. `binaryNoRescore` skips rescoring for faster queries and lower storage at lower accuracy. The docs recommend `euclidean` similarity with both binary types. (medium confidence) (verified as of 2026-10-14) [source]

How-to and procedures

To estimate mongot RAM for a quantized index, add the HNSW graph to the in-memory quantized vectors and apply about 10% overhead for the JVM and page cache. MongoDB's sizing table uses a 1.1 multiplier, and the deployment guide advises search-node RAM at least 10% above total index size. Disk holds the full-fidelity vectors, the graph and the quantized copy. (medium confidence) [source]
To measure recall on a quantized index, run the same query as ENN (`exact: true`) and as ANN, then compute the overlap. MongoDB recommends a set of 100 queries with Jaccard similarity, plus judgment lists that use ENN results as the baseline. Its own benchmark averaged overlap across 50 sample queries. (medium confidence) [source]

Measurements and reference values

Automatic quantization shrinks the vector values 4x (scalar) and 32x (binary), but the RAM that mongot needs falls only 3.75x and 24x because the HNSW graph is not compressed. MongoDB's measured 1024-dimension test matched this: 394.73 MB of float32 RAM became 131.42 MB for scalar (about 3:1) and 16.99 MB for binary (23:1). (high confidence) [source]
Quantization raises total disk use. Atlas keeps the full-fidelity vectors on disk for rescoring and exact search, in addition to the quantized copy and the HNSW graph. In MongoDB's roughly 300,000-vector Wikipedia test, the scalar index took 492.83 MB of disk against 394.73 MB for float32, while its RAM fell to 131.42 MB. (high confidence) [source]
MongoDB's deployment guide gives rough disk rules for quantized indexes. A binary index with rescoring takes about original index size x 25/24 on disk, because the extra 1/24 holds the binary vectors and the graph is uncompressed. Free disk should be 125% of the estimated index size. Search nodes should offer about 4:1 storage-to-RAM for scalar and 24:1 for binary. (low confidence) (verified as of 2026-10-14) [source]
MongoDB's published benchmark uses Amazon Reviews 2023 subsets (5.5M and 15.3M items) embedded with voyage-3-large at up to 2048 dimensions, and targets 90-95% recall. It varies quantization, dimensionality (256, 512, 1024 and 2048, via sliced views), a ~3% selective filter, concurrency (1, 10, 100) and sharding. Reuse those axes when sizing your own workload, and test on your own data, as the results page advises. (medium confidence) [source]
Embedding model choice drives how much recall quantization costs. The MongoDB docs list voyage-3-large, Cohere embed-english-v3.0, nomic-embed-text-v1.5, jina-embeddings-v2-base-en and mxbai-embed-large-v1 as quantization-aware, with minimal scalar recall loss even at 384 dimensions. MongoDB's February 2025 post shows OpenAI v3-small, which is not quantization-aware, degrading sharply, especially under binary. In Hugging Face's rescored binary runs, mxbai-embed-large-v1 kept 96.45% and Cohere v3 kept 94.6% of float32 NDCG@10. (medium confidence) (verified as of 2026-10-14) [source]
At scale, prefer 1024 or more dimensions with quantization over fewer dimensions without it. MongoDB's benchmark found 1024d and 2048d vectors reach the 90-95% recall band at lower `numCandidates`, while 256d and 512d vectors 'struggle to exceed 70-80% recall'. Azure AI Search and Qdrant also tie binary quantization to high dimensionality. (high confidence) [source]
Pre-quantized BinData (float32, int8, int1) is the alternative to automatic quantization. int8 and int1 ingestion give the same 3.75x and 24x mongot RAM reduction, and BinData needs about three times less disk (66% less) than float arrays on mongod. Index pre-quantized fields with `quantization: none`. (medium confidence) [source]
Do not enable binary quantization on low-dimension or non-quantization-aware models without testing. In Hugging Face's rescored runs (top 100, rescore multiplier 4), e5-base-v2 (768d) kept only 74.77% of float32 NDCG@10 and nomic-embed-text-v1.5 kept 87.7%, against 96.45% for mxbai-embed-large-v1. Azure AI Search calls binary most effective above 1024 dimensions. Qdrant reports significant precision loss from 1-bit compression below about 1000 dimensions. Elastic reports 74% recall for the lower-dimension E5-small at 1 bit, against above 90% for 1024d CohereV3 at 3x oversampling. (high confidence) [source]
Do not treat binary search without rescoring as equivalent. On mxbai-embed-large-v1, Hugging Face measured 92.53% retention for binary search alone and 96.45% with rescoring. Qdrant recommends binary quantization only with rescoring enabled. Elastic calls naive binary quantization 'exceptionally lossy', needing 10x or 100x extra neighbors to rerank. On Atlas, `binary` always rescores. Only `binaryNoRescore` on autoEmbed fields skips it. (high confidence) [source]
Treat 'retaining up to 95% search accuracy' for binary with rescoring as a best case, not a default. In MongoDB's own June 2025 test on about 300,000 voyage-3-large vectors (1024d), binary retention was about 91% at top-k 10 with minimal candidates and about 74% at top-k 50 and 100. It recovered to 98% at 500 candidates (top-k 10). MongoDB's August 2025 benchmark found 256d and 512d vectors struggled to exceed 70-80% recall. (medium confidence) [source]
In MongoDB's technical-blog test (about 300,000 Wikipedia fragments, 1024-d voyage-3-large), disk use was 394.73 MB for a float32 index, 407.66 MB for binary and 492.83 MB for scalar. Binary's roughly 3% increase matches the docs' estimate of original index size x 25/24 for binary quantization with rescoring. (medium confidence) [source]
For disk planning the docs advise search nodes with roughly a 4:1 storage-to-RAM ratio for scalar quantization and 24:1 for binary, an index-disk estimate of original index size x 25/24 for binary with rescoring, and free disk equal to 125% of the estimated index size. MongoDB's benchmark ran its quantized workloads on High-CPU and Storage-optimized search nodes, both about 25:1 disk-to-RAM. (medium confidence) (verified as of 2026-10-14) [source]
MongoDB lists per-vector space for a 2048-dimension Voyage voyage-3-large embedding as 8 KB for float, 2.14 KB for int8 and 0.334 KB for int1. In its benchmark of 15.3M vectors at 2048-d, scalar needed 32.64 GB RAM and binary 5.1 GB RAM, with 155.04 GB disk for both. (medium confidence) (verified as of 2026-10-14) [source]
Binary needs far more `numCandidates` than scalar to reach 90-95% recall. In MongoDB's benchmark, scalar recall starts higher but plateaus as `numCandidates` rises, while binary recall keeps rising, approaches scalar and sometimes passes it. Latency grows notably above `numCandidates` 1000. MongoDB's technical blog shows the same shape: binary retention of about 91% at top-k 10 with minimal candidates and 98% at 500 candidates, but about 74% at top-k 50 and 100 with minimal candidates. (medium confidence) (verified as of 2026-10-20) [source]
Binary quantization with rescoring against higher-precision vectors is a common design, not an Atlas-only feature. Hugging Face Sentence Transformers retrieves `rescore_multiplier` x `top_k` binary candidates and rescores them. Elastic BBQ oversamples 3x by default and re-ranks with the full vector. Qdrant enables `rescore` by default for binary quantization and exposes an `oversampling` query parameter. (high confidence) [source]
Binary quantization with rescoring depends on the embedding model. Hugging Face measured retention of 96.45% for mxbai-embed-large-v1, 94.6% for Cohere embed-english-v3.0, 93.79% for all-MiniLM-L6-v2, 87.7% for nomic-embed-text-v1.5 and 74.77% for e5-base-v2, which the authors attribute to dimension collapse. They conclude quantization 'doesn't universally work with all embedding models'. MongoDB's accuracy page likewise tells users with quantized, large or low-dimensional vectors to measure recall against ENN. (medium confidence) [source]
The headline '96% less memory while retaining up to 95% search accuracy' comes from MongoDB's own tests (Figure 3 of the December 2024 blog) and measures processing memory, not total storage. Accuracy depends on `numCandidates`: MongoDB's technical blog shows binary retention ranging from about 74% to 98% across candidate settings. (medium confidence) [source]
MongoDB's docs list models whose output can be ingested as pre-quantized vectors (Voyage voyage-3-large, Cohere embed-english-v3.0, Nomic nomic-embed-text-v1.5, Jina jina-embeddings-v2-base-en, Mixedbread mxbai-embed-large-v1) and say scalar quantization keeps recall for them, even at 384 dimensions, because they are quantization-aware. MongoDB's blog adds Voyage figures, such as voyage-3-large int8 at 1024-d within 0.31% of float at 2048-d. Voyage AI joined MongoDB, so these figures are vendor-reported, not independent. (medium confidence) [source]

Problems, failure modes and limitations

The rescoring pool on Atlas is the query's `numCandidates`. MongoDB's benchmark documentation says the top `numCandidates` gathered during the search are re-ordered by their on-disk full-fidelity vectors before the top `limit` results are returned. The binary-quantization launch blog describes the pool less precisely, as 'a subset of the top binary vector search results'. (medium confidence) [source]
In $vectorSearch, ANN queries need `numCandidates` (at most 10,000 and at least `limit`). MongoDB recommends at least 20 times `limit`, and says quantized vectors can need higher values than float32 for the same recall. `numCandidates` is the lever that trades latency for recall on scalar and binary indexes. (high confidence) (verified as of 2026-10-14) [source]
Every engine surveyed implements binary quantization as a two-stage search: fetch an oversampled candidate list with compressed vectors, then rescore it with higher-precision data. Atlas folds the oversampling into `numCandidates`. Hugging Face Sentence Transformers retrieves rescore_multiplier x top_k (its main runs used 4 x 100). Qdrant pre-selects limit x oversampling (240 for limit 100 at 2.4). Azure AI Search oversamples by a default factor of 4. Elastic's Lucene BBQ benchmarks swept oversampling factors from 1 to 5. (high confidence) [source]
Selective filters raise the cost of binary search. With a filter matching about 3% of 15.3M vectors, binary quantization at low `limit` values needed roughly 4x as much work to reach 90-95% recall. MongoDB separately advises ENN search when a pre-filter matches under 5% of the collection. (medium confidence) [source]
Documents can silently drop out of a quantized index. If `quantization` is `scalar` or `binary` and a field value is not an array of floats, Atlas skips that vector without an error. Pre-quantized BinData int8 or int1 vectors belong in an index with quantization `none`. (medium confidence) [source]
If binary recall is low, raise `numCandidates` and expect latency to rise with it. MongoDB's benchmark found binary needs significantly more `numCandidates` than scalar for 90-95% recall. Binary climbs toward, and in some cases past, scalar's plateau as candidates grow. Its latency rises from the hundreds of candidates (rescoring cost) and especially above 1,000. Lower `limit` values need proportionally more candidates. (high confidence) [source]
Per MongoDB's benchmark overview, the top `numCandidates` results accumulated during the HNSW search are reordered by their full-fidelity vectors on disk, and Atlas then returns the top `limit`. A larger `numCandidates` raises recall and also raises rescoring cost: MongoDB's technical blog reports the rescoring phase dominates latency as the candidate pool grows. (medium confidence) [source]
A lower `limit` needs a higher `numCandidates`. MongoDB's benchmark reaches the 90-95% recall target at a lower `numCandidates` for `limit` 100 than for `limit` 10. The `$vectorSearch` reference recommends `numCandidates` of at least 20 times `limit`, allows at most 10000, and says quantized vectors may need higher `numCandidates` than float32 for similar recall. (medium confidence) [source]
Rescoring costs throughput. In MongoDB's concurrency tests scalar reached higher QPS than binary at every `limit`, because scalar finishes with a lower `numCandidates` and no rescoring. MongoDB recommends adding Search Nodes or cores per node to recover throughput. (medium confidence) (verified as of 2026-10-20) [source]
A selective filter raises the cost of binary quantization. With a filter matching about 3% of the 15.3M-vector corpus, binary at low `limit` needed roughly 4 times as much work to reach 90-95% recall as the unfiltered query. (low confidence) (verified as of 2026-10-20) [source]
`$vectorSearch` has no separate rescoring or oversampling parameter. `numCandidates` is the only candidate-pool control, and MongoDB's benchmark queries pass only `index`, `path`, `queryVector`, `limit` and `numCandidates`. Tune `numCandidates` against an ENN baseline. (medium confidence) (verified as of 2026-10-14) [source]
On an `autoEmbed` field you cannot edit `path`, `model`, `quantization` or `numDimensions` after the index exists. To change quantization, create a new index with the new setting and delete the old one. (low confidence) (verified as of 2026-10-14) [source]
For `autoEmbed` indexes with a pre-computed `queryVector`, the vector format must match the index `quantization`: `scalar` takes a scalar-quantized vector, `float` and `binary` take a float vector, and `binaryNoRescore` takes a binary-quantized vector. A mismatch returns empty results with no error. (low confidence) (verified as of 2026-10-14) [source]
To query full-fidelity vectors with a BinData query vector, the subtype must be float32. A BinData int8 or int1 query vector against that index returns no results and no error. (low confidence) (verified as of 2026-10-14) [source]

Comparisons and alternatives

MongoDB's default advice is binary quantization with rescoring for most embedding models, and scalar quantization for lower-dimension models that are not quantization-aware trained (QAT). The index reference adds that precision-critical workloads should use `none` or `scalar` rather than `binary`. The benchmark page says binary can suit many large workloads but tells readers to test on their own data. (medium confidence) (verified as of 2026-10-14) [source]
Binary quantization trades throughput for cost. MongoDB's results page says binary serves the index at about one fourth the price (the comparison baseline is not stated in the text), but rescoring needs more `numCandidates` and cuts throughput at high concurrency. Scalar reached higher QPS at every `limit` tested. MongoDB advises scaling throughput with more search nodes (2 to 32) or vCPUs rather than sharding. (medium confidence) (verified as of 2026-10-14) [source]
If a field value is not an array of floats, automatic quantization skips that vector silently instead of indexing it. The docs describe no error. Check that every vector field holds a float array, or the document will not be searchable on that field. (low confidence) [source]
MongoDB's docs recommend binary quantization with rescoring for most embedding models. They recommend scalar quantization for lower-dimension models that are not quantization-aware-trained (QAT), because scalar loses less representation. If precision is critical, use `none` or `scalar` instead of `binary`. (high confidence) [source]
MongoDB's own benchmark (Amazon Reviews 2023, voyage-3-large, 15.3M vectors at 2048 dimensions) reports 90-95% recall against float ENN with under 50 ms query latency when quantization is configured. Recall is the average overlap across 50 sample queries. The same page says binary quantization serves the index at about one fourth the price of scalar (two search nodes at $0.24/hr versus $1.04/hr). (medium confidence) (verified as of 2026-10-20) [source]
Independent tests show rescoring recovers most of the recall lost to 1-bit compression. Hugging Face (March 2024), on mxbai-embed-large-v1 at 1024-d with MTEB retrieval NDCG@10: binary without rescoring kept 92.53% of float32 and binary with rescoring kept 96.45%. Qdrant, using its 1-bit TurboQuant (not plain binary quantization) on all-MiniLM-L6-v2 at 384-d over DBPedia-entity: recall@10 against exact search was 0.605 without rescoring and 0.951 with rescoring at oversampling 1, versus 0.957 for float32. (medium confidence) [source]

Facts and statements

In the MongoDB docs read on 2026-10-14, no index or query setting controls oversampling or a rescore multiplier for `binary`. The word 'oversampling' does not appear in the quantization, index-definition, $vectorSearch, deployment, benchmark or accuracy pages. `numCandidates` is the single knob, and it also sets how many HNSW nodes the ANN search explores. Hugging Face (rescore_multiplier), Qdrant (oversampling) and Azure AI Search (defaultOversampling, default 4) expose the rescoring pool as a separate parameter. (medium confidence) (verified as of 2026-10-14) [source]
Automatic quantization accepts float32 or float64 arrays and BinData float32 vectors, up to 8,192 dimensions, with cosine, euclidean or dotProduct similarity, for both ANN and ENN search. Atlas stores floats as double internally, so 32-bit and 64-bit embeddings both work without conversion. (high confidence) (verified as of 2026-10-14) [source]
For automatic binary quantization, the index definition's `numDimensions` must be a multiple of 8. Automatic scalar quantization accepts 1 to 8,192 dimensions. (low confidence) [source]
Automatic scalar quantization, automatic binary quantization with rescoring, and int1 BinData ingestion entered public preview on 2024-12-02 (new clusters first, existing clusters over the next two weeks). They became generally available on 2025-04-29, the same day Atlas added an approximate 'Required Memory' figure to the list-search-indexes view. (high confidence) [source]
`binaryNoRescore` is documented only for `autoEmbed` (Automated Embedding) index fields. There the quantization options are float, scalar, binary and binaryNoRescore, and the default is scalar. `binaryNoRescore` builds a binary index without rescoring: faster queries and lower storage, lower accuracy. Plain `vector` fields document only none, scalar and binary. (medium confidence) (verified as of 2026-10-14) [source]
$vectorSearch explain output includes a `vectorTracing` array. A traced vector that was visited but dropped carries a `dropReason` of Merge, NonCompetitiveScore, Filter or Rescoring. (low confidence) (verified as of 2026-10-14) [source]
Self-managed mongot exports Prometheus metrics relevant to quantization: `mongot_index_stats_requiredMemoryBytes` (estimated required memory per index), `mongot_index_stats_query_numCandidatesPerQuery` (histogram bucketed by quantization) and the counter `mongot_index_stats_query_vectorRescoringFailureCount_total`. (low confidence) (verified as of 2026-10-14) [source]
Measure quantization recall against ENN ground truth. Run each query as `exact: true` and as ANN, compute Jaccard similarity (overlap divided by result-set size), and average over a query set. MongoDB's accuracy guide recommends 100 queries; its published benchmark averaged 50. If ANN and ENN results diverge, tune `numCandidates`. (high confidence) [source]
Rescoring has three variants across vendors. (1) Re-rank with full-precision document vectors kept on disk: Atlas `binary`, Azure preserveOriginals, Qdrant. (2) Score the float32 query against the binary document vectors, which needs no extra storage: Hugging Face's main experiments, Azure discardOriginals. (3) Re-rank with int8 document vectors: Hugging Face's demo. Atlas uses variant 1, which is why it keeps full-fidelity vectors on disk. (medium confidence) [source]
Do not quantize small collections by default. MongoDB's docs recommend automatic quantization above about 100,000 vectors. MongoDB's February 2025 blog says collections under 1 million embeddings may see no significant gain and that the overhead can outweigh the benefit. (medium confidence) (verified as of 2026-10-14) [source]
Rescoring reads full-fidelity vectors from disk, so a binary index can be disk-bound as well as RAM-bound. The Atlas deployment guide sizes search nodes for disk as well as RAM, and notes minimal RAM and cache use during rescoring. Qdrant warns that rescoring from originals stored on disk can significantly decrease search speed. (medium confidence) [source]
For autoEmbed fields, the `queryVector` format must match the index's quantization type, or the query returns empty results. `scalar` needs a scalar-quantized vector, `float` and `binary` need a float vector, and `binaryNoRescore` needs a binary-quantized vector. (low confidence) (verified as of 2026-10-14) [source]
Automatic quantization accepts arrays of float or double values and `binData` float32 vectors. Atlas stores floats as `double` internally, so 32-bit and 64-bit embeddings both work. It supports `cosine`, `euclidean` and `dotProduct`, up to 8192 dimensions, with both ANN and ENN search. Automatic binary quantization requires `numDimensions` to be a multiple of 8. (high confidence) [source]
The current docs recommend quantization for applications with a large number of vectors, 'such as over 100,000'. MongoDB's earlier blogs put the practical threshold near 1 million vectors (see disagreements). (medium confidence) (verified as of 2026-10-14) [source]
Quantization lowers RAM but raises total disk. mongot holds the quantized vectors and the HNSW graph in memory and keeps full-fidelity vectors on disk. The Atlas UI 'Size' column shows total data stored, so a quantized index can look larger than an unquantized one. Read the 'Required Memory' metric to estimate query-time memory. (high confidence) [source]
In independent tests the first rescoring pass recovers most of the loss and extra oversampling adds little. Hugging Face saw no further binary gain raising `rescore_multiplier` from 1 to 10 at top_k 100. Qdrant's 1-bit recall@10 rose from 0.951 at oversampling 1 to 0.977 at 2 and 0.988 at 4, and Qdrant warns extra oversampling adds disk reads for little recall. (medium confidence) [source]
MongoDB announced automatic scalar quantization and automatic binary quantization with rescoring in public preview on 2024-12-12. The same blog post carries an update dated 2025-04-29 saying the quantization capabilities are generally available. No dated changelog entry was found to confirm the GA date. (low confidence) [source]

Children

Atlas Vector Search numCandidates tuning and recall measurement against ENN (frontier, viability 4.03 / 5)
Automated Embedding (autoEmbed) quantization types
Automated Embedding (autoEmbed) quantization types including binaryNoRescore
Lucene BBQ binary quantization compared with Atlas binary quantization (frontier, viability 2.77 / 5, below research gate)
Matryoshka and quantization-aware embedding models (frontier, viability 3.38 / 5)
Measuring ANN recall against ENN baselines (frontier, viability 3.63 / 5)
Pre-quantized BinData (int8 and int1) ingestion (frontier, viability 3.67 / 5)
Pre-quantized BinData vector ingestion (int8 and int1) in MongoDB (frontier, viability 3.67 / 5)
Quantization-aware and Matryoshka embeddings (voyage-3-large) with Atlas dimension slicing
Search Node sizing and disk-to-RAM ratios for quantized vector indexes (frontier, viability 3.80 / 5)
Search Node sizing for quantized vector indexes (RAM, disk, vCPU) (frontier, viability 3.80 / 5)
numCandidates tuning for quantized HNSW indexes (frontier, viability 3.85 / 5)

Frontier under this node: Atlas Vector Search numCandidates tuning and recall measurement against ENN (4.03), Lucene BBQ binary quantization compared with Atlas binary quantization (2.77), Matryoshka and quantization-aware embedding models (3.38), Measuring ANN recall against ENN baselines (3.63), Pre-quantized BinData (int8 and int1) ingestion (3.67), Pre-quantized BinData vector ingestion (int8 and int1) in MongoDB (3.67), Search Node sizing and disk-to-RAM ratios for quantized vector indexes (3.80), Search Node sizing for quantized vector indexes (RAM, disk, vCPU) (3.80), numCandidates tuning for quantized HNSW indexes (3.85)

← the whole tree · 3D view· how to read this page