Vector Search hard
You index 1B vectors (768-dim fp32, about 3 TB raw) with IVF-PQ using 64-byte codes so that the index fits in RAM. Recall@10 is 80%, and the product needs 95%. Full-precision vectors are stored on NVMe SSD. What is the most effective change?
- A Fetch a larger PQ candidate set, say the top 300, then rerank it with exact distances on full vectors from SSD.
- B Drop PQ and build HNSW over full-precision vectors, since only graph indexes reach 95% recall at billion scale.
- C Increase the number of IVF lists to sharpen partitions, which removes the distance error introduced by PQ codes.
- D Raise nprobe until recall hits 95%, because recall loss in IVF-PQ comes from probing too few lists, not the codes.
Answer: A. Fetch a larger PQ candidate set, say the top 300, then rerank it with exact distances on full vectors from SSD.
With 64-byte codes, PQ's **distance approximation** misorders close neighbors, and that caps recall no matter how many lists you probe. **Reranking** a few hundred candidates with exact distances costs a few hundred SSD reads per query, but it recovers most of the lost recall while RAM still holds only the codes. Raising nprobe (D) helps only when true neighbors fall outside the probed lists. It is the right fix for uncompressed IVF-Flat, not when quantization error dominates.
One system design question a day, with spaced repetition so the ones you miss come back.
Get the appRelated questions
- You are building an IVF index on 20 million vectors. A teammate asks why the build needs a 'training' step before any vectors can be added. What is the reason?
- An HNSW index serves a marketplace where about 30% of listings are updated or removed each week. Each update is applied as a delete plus an insert, and deletes mark tombstones. Over a month, recall@10 drifts from 97% to 89% and p99 latency rises at the same ef_search. What is happening, and what should you do?
- Users delete documents in your primary database, but the deleted documents keep appearing in vector search results for hours. The vector index is rebuilt nightly. What is the best fix?
- Your embedding model outputs unnormalized vectors whose magnitudes vary widely. A teammate wants to switch the index from cosine similarity to dot product because it is cheaper to compute. What is the consequence?
- You are setting an SLO for a new ANN-backed recommendation search over 50 million vectors. A product manager asks for 100% recall@10 with single-digit millisecond latency. What is a realistic response?
- A B2B SaaS app serves 500 customers, and every query searches only one customer's documents. One large customer runs heavy batch queries that slow down search for everyone. Which sharding approach fits best?