ANN trades exactness for scalable latency
Exact k-nearest-neighbor search compares the query against every candidate vector and returns the mathematically closest results. That gives a useful ground truth, but its work grows roughly with the number of stored vectors.
Approximate nearest-neighbor search uses an index, such as Qdrant's HNSW-based dense-vector search, to visit a much smaller set of promising candidates. It can therefore reduce latency and CPU cost substantially as the collection grows, at the cost of potentially missing some true nearest neighbors.
The engineering trade-off is recall versus latency and resource consumption. In Qdrant, search parameters such as hnsw_ef can be tuned, and exact=true can be used for comparison or workloads where exact results matter more than latency.
A common mistake is treating ANN as inaccurate by definition. A well-tuned ANN index can have very high recall. The correct approach is to benchmark recall against exact-search ground truth on representative queries rather than choosing parameters by intuition.
Exact search scans candidates and provides ground truth but becomes expensive at scale
ANN uses an index to reduce the search space
hnsw_ef increases the candidate search effort and usually improves recall at additional latency
Benchmark ANN against exact search before choosing production parameters
A collection has 10,000 vectors and exact search is already fast enough. Would you automatically enable ANN? Why or why not?
A user says the top result is occasionally not the mathematically closest vector. What does that tell you about an ANN system?
Your p95 latency doubled after the collection grew tenfold while recall remained acceptable. Which ANN parameters and infrastructure metrics would you inspect?
Offline tests show 98% recall at hnsw_ef=64 and 99.5% at 256, but latency doubles. How would you decide which setting to deploy?
You need different latency targets for interactive search and offline batch retrieval over the same collection. How would you configure and benchmark the search paths?
A production incident shows recall dropping only for queries with restrictive metadata filters. How would you determine whether ANN traversal or filtering is responsible?
You need to guarantee a contractual recall target while keeping p99 latency under a strict SLO. How would you design the evaluation and adaptive search strategy?
Your vector workload has grown beyond a single-node deployment. How would you reason about partitioning, replication, index build cost, and recall when scaling ANN horizontally?