What is a prefetch stage in Qdrant's Universal Query API, and why would you use multiple prefetches?
Prefetch as candidate generation
A prefetch is an earlier retrieval stage that generates candidate points for a later query stage. Instead of immediately returning the first search result, Qdrant can retrieve a larger candidate set and then use those points as the input to fusion or reranking.
Multiple prefetches are useful when candidate generation comes from different retrieval signals. A common example is dense semantic retrieval plus sparse lexical retrieval. Each prefetch can retrieve its own candidates, after which Qdrant can fuse or rerank the combined candidate set.
The key engineering reason is recall first, precision second. Cheap retrieval stages can cast a wide net, while a more expensive reranker operates on a smaller candidate set. The trade-off is additional computation and latency, so candidate limits should be tuned against end-to-end quality.
A common mistake is assuming prefetch means fetching data from another database. It is a retrieval stage within the Qdrant query execution plan. The exact nesting and supported combinations depend on the Qdrant version.
- 1
Prefetch stages generate candidates for later query processing
- 2
Multiple prefetches can represent different retrieval signals
- 3
Candidate generation can optimize recall before expensive reranking
- 4
More prefetch work increases compute and latency
Scenario Questions
0-2 years experience
- 1Your application needs both semantic and keyword matching. Why might two prefetch stages be useful?
- 2A prefetch returns 200 candidates but the API returns only 10 results. Why retrieve more than you finally display?
2-5 years experience
- 1Dense retrieval has poor recall for exact product codes while sparse retrieval handles them well. How would you combine the two candidate sets?
- 2Increasing a prefetch limit improves recall but hurts p95 latency. How would you tune the candidate count?
5-8 years experience
- 1Your hybrid search uses dense and sparse prefetches with very different result distributions. How would you decide whether to fuse or rerank their candidates?
- 2A reranker is expensive enough that scoring 5,000 candidates is unacceptable. How would you structure prefetch stages to control its input size?
8+ years experience
- 1You need a reusable retrieval architecture for semantic, lexical, and modality-specific candidate generation. How would you design prefetch stages and downstream ranking so new signals can be added safely?
- 2A retrieval pipeline has excellent recall but unacceptable p99 latency because several prefetches run concurrently. How would you reason about reducing cost without destroying recall?
Follow-up Questions
- Why retrieve more candidates in a prefetch than the final result count?
- How would you choose candidate limits for two different prefetch stages?