When to use hybrid search
“When should you use hybrid (dense + sparse) retrieval instead of pure vector search?”
What this tests
- Understanding what embeddings capture and what they miss
- Knowledge of BM25, fusion (RRF), and reranking
- Ability to identify query types that need lexical matching
- Measuring instead of assuming hybrid is better
Answers by level
Read the beginner answer first and notice what is missing.
Dense retrieval matches meaning: paraphrases, synonyms, conceptual questions. It is weak on exact tokens the embedding model treats as noise: product codes, error strings, identifiers, names, version numbers, rare technical terms. Sparse retrieval (BM25) is the opposite. Hybrid runs both and fuses the ranked lists, typically with reciprocal rank fusion, then often reranks the merged top-N with a cross-encoder. See Dense, Sparse & Hybrid Retrieval and Reranking.
So I use hybrid when the corpus or queries contain exact-match signals: technical docs, logs, legal citations, product catalogs, anything with SKUs or error codes. I stay with dense only when queries are conversational and the corpus is prose, and I add BM25 when evals show recall failures on identifier-style queries.
Hybrid costs a second index, a fusion step, and tuning of the weighting; it is not free. The decision comes from a golden set with a mix of query types and recall@k per type.
Green flags · Red flags
- Explains dense strengths (semantics) and weaknesses (identifiers, rare terms)
- Names BM25, RRF, cross-encoder reranking
- Decides based on query-class failure analysis, not by default
- Mentions latency and index cost of hybrid
- Considers metadata filtering or direct lookup as alternatives
- Says hybrid is always better
- Cannot explain what BM25 adds
- No evaluation methodology
- Ignores latency and operational cost