Vector Search · 118 pages
Vector Search in Production
From embeddings to a tuned, cost-aware retrieval layer that stays fast at scale.
Contents
- Embeddings and distance metrics
- Choosing an index: HNSW vs IVF
- Recall@k and latency budgets
- Hybrid and metadata-filtered search
- Operating at billion-vector scale
Free preview
A vector database is easy to demo and surprisingly hard to operate. The gap is everything between 'it returns something' and 'it returns the right thing, fast, at cost'. This guide is about closing that gap with the small number of parameters that actually matter.
The recall–latency dial
Approximate indexes trade accuracy for speed. The job is to pick a target — say Recall@10 of 0.95 — and tune index parameters like efSearch or the number of probes to hit it inside your latency budget, rather than accepting whatever defaults ship.
- Measure Recall@k against an exact-search ground truth
- Tune efSearch / nprobe to the target, not to a guess
- Add a rerank stage when compression costs recall
- Filter on metadata to shrink the search space
Never mix vectors from two embedding-model versions in one index. They map to different spaces and silently wreck recall — store the model id with every vector.
Later chapters cover binary quantization for memory-bound indexes, hybrid search that fuses BM25 with dense retrieval, and the operational playbook for re-embedding a large corpus without downtime.
Want the full guide?
Join the newsletter and we'll send you the complete guide and new releases.