Vector Search
Finding the nearest vectors to a query, fast — by not actually finding them, which almost nobody measures.
When not to use it
- Under ~100k vectors. Brute force is fast enough and exact. Don't install infrastructure for this.
- Without measuring recall. You're running at 90-95% and don't know which 5-10% you're missing.
- When you need exact matches. Product codes, names, rare terms — semantic search misses these. Hybrid.
- With heavy filters and a naive setup. Filtered ANN is the actual hard problem and where products differ.
Reach for something else instead
- Brute force — exact, and fine below ~100k.
- Keyword search (BM25) — for exact terms, still excellent, and free.
- Hybrid + reciprocal rank fusion — the boring answer that works.
- A relational database — if your filters are the point and similarity is secondary.
Sources & further reading
- Malkov & Yashunin (2018), Efficient and robust approximate nearest neighbor search using Hierarchical Navigable Small World graphs — HNSW; the default for good reason.
- Johnson, Douze & Jégou (2019), Billion-scale similarity search with GPUs — FAISS; the library everything is built on.
- Aumüller, Bernhardsson & Faithfull (2020), ANN-Benchmarks — the recall/speed frontier, measured. Look at your operating point.
Primary sources, listed so you can check the claims on this page rather than take them on trust.
Where people go wrong
- Not measuring recall@k. An afternoon of brute-force comparison tells you what you're missing.
- Never touching
efSearch. It's your recall dial and it's tunable at query time. - Using the wrong distance metric. Cosine for most text; getting it wrong looks like a model problem.
- Installing a vector database for 50,000 vectors. Brute force is exact and faster than the network hop.