**Hybrid search** combines sparse (BM25 / term-frequency) signals with dense (embedding) signals to retrieve documents. The reason: BM25 wins on exact-keyword queries (where the user typed a specific term that must appear), and dense embeddings win on semantic queries (where the user paraphrases the underlying intent). Combining both is more robust than either alone.
Vector databases implement this combination via two distinct architectural patterns.
**Pattern 1: two separate indexes, score fusion at query time.**
- One inverted index for sparse / BM25 (built like a classical search engine: term -> postings list).
- One ANN index (HNSW, IVF) for dense vectors.
- At query time: run both, get two ranked lists, fuse them. **Reciprocal Rank Fusion (RRF)** is the canonical fusion function: score(doc) = sum over each list of 1 / (k + rank), with k typically 60.
- Vendors: Pinecone, Weaviate, Qdrant. All three ship hybrid search this way.
**Pattern 2: single hybrid index, joint scoring at index traversal.**
- One index that knows about both sparse and dense features per document.
- At query time: traverse the index once, computing a combined score per document.
- Vendors: Vespa is the canonical example (deep IR heritage from Yahoo!). Some Milvus configurations also support this.
**Tradeoffs.**
- *Pattern 1 (two indexes + RRF).* Simpler architecturally; you can scale and tune each index independently. Operationally: two indexes to keep in sync (writes go to both). Fusion is a constant-time operation; the choice of fusion function (RRF, weighted sum, learned to rank) is a tuning lever.
- *Pattern 2 (single hybrid).* More complex index but no fusion step. Per-document scoring can be more nuanced (the index can balance sparse and dense per-document rather than uniformly). Operationally heavier.
**Why the other options are wrong.**
- Option B claims all vector DBs use a shared graph index; this is false (BM25 is fundamentally an inverted-list method, not a graph method).
- Option C says sparse is delegated to the embedding model; sparse retrieval is a separate retrieval-time operation, not an embedding-time one.
- Option D claims sparse vectors are PCA-compressed to dense; sparse representations are stored as-is in inverted lists, not converted.
**Two architectural patterns for hybrid sparse plus dense retrieval in vector databases.**
**Pattern 1: two separate indexes, fuse at query time (score fusion).**
The vector DB maintains two indexes per logical collection:
- *Inverted index for sparse vectors.* Each term in the vocabulary maps to a postings list of (document_id, term_weight) pairs. BM25 scoring computes a per-document relevance based on term frequencies and inverse document frequencies. This is the same machinery that powers Elasticsearch, Lucene, and classical IR systems.
- *ANN index for dense vectors.* HNSW or IVF over the dense embedding space. Standard vector search.
At query time:
1. Run BM25 search, get ranked list of top-N sparse results.
2. Run ANN search on the query embedding, get ranked list of top-N dense results.
3. Fuse the two lists into a single ranked output.
The canonical fusion function is **Reciprocal Rank Fusion (RRF)**:
```
score(doc) = sum_over_lists ( 1 / (k + rank_in_that_list) )
```
with k = 60 by default. Documents that rank high in either list get high scores; documents that rank high in both get the highest scores. RRF is rank-based (not score-based), which means it does not require the sparse and dense scores to be on the same scale, an important property because BM25 scores are unbounded and dense scores are typically in [-1, 1] or [0, 1].
Alternatives to RRF: weighted sum (requires score normalization), Borda count, learned to rank with a trained reranker. RRF is the production default because it is parameter-light and robust.
*Vendors:* Pinecone, Weaviate, Qdrant. All ship hybrid search via this two-index + RRF pattern. Pinecone calls it 'sparse-dense hybrid'; Weaviate calls it 'hybrid search'; Qdrant exposes sparse vectors and lets you compose them with dense via a fusion step.
**Pattern 2: single hybrid index, joint scoring at traversal (index-time fusion).**
A single index structure scores both sparse and dense per document during a single
Quick reference
TL;DR
Two patterns: (1) Two separate indexes (inverted for BM25, ANN for dense) fused at query time via Reciprocal Rank Fusion, the Pinecone / Weaviate / Qdrant way.
Imagine you're sorting books by 'most relevant to my question.' One approach: ask your keyword-matching librarian for their ranked list, ask your meaning-matching librarian for theirs, then blend the two lists fairly using a formula. **That's pattern 1 (score fusion).** Another approach: have one super-librarian who looks at both keyword matches AND meaning at the same time and produces a single ranked list directly. **That's pattern 2 (joint scoring).** Both work; the first is easier to operate (two simpler systems) and the second is sometimes more accurate (the librarian can balance the signals on a per-book basis).
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example.
Workload is purely semantic with no exact-keyword queries Pure dense ANN is simpler and adequate; the BM25 leg adds operational overhead with no recall benefit.
Workload is purely keyword/exact-match with no paraphrasing Pure BM25 (or any classical IR system) wins on simplicity; dense adds noise without recall benefit.
Team lacks bandwidth to operate two indexes Pattern 1's operational tax is real; if it cannot be borne, stay with single-modality retrieval and a learned reranker.
Quick scan · 2–4 min
Everything important, quickly.
3 min: name both patterns, identify the canonical fusion (RRF for Pattern 1), cite the vendor mapping (Pinecone/Weaviate/Qdrant vs Vespa), and reject the distractor options.
Side-by-side
Aspect
Pattern 1 (two indexes + RRF)
Pattern 2 (single hybrid)
Indexes per collection
Two (inverted + ANN)
One (combined)
Fusion location
Query-time, after both indexes
Index-time, during traversal
Canonical fusion
Reciprocal Rank Fusion (RRF)
Per-document tensor expression
Operational complexity
Two writes per insert
One write, complex index
Scoring nuance
Uniform across documents
Per-document conditional
Canonical vendors
Pinecone, Weaviate, Qdrant
Vespa, Milvus-hybrid mode
Best for
RAG retrieval, mixed-query loads
Search/ranking with business rules
Real-world examples
Real products, models, and research that use this idea.
1Pinecone's sparse-dense hybrid: per-record sparse_values + dense values; RRF fusion is automatic via the query API.
2Weaviate's hybrid query exposes an alpha parameter to weight sparse vs dense, layered on RRF-style ranking.
3Qdrant added sparse vectors as a first-class index type in 1.7; client-side RRF or Reciprocal Rank Fusion server-side combines them with dense ANN.
4Vespa powers Spotify search and several large e-commerce platforms via per-document tensor scoring that combines BM25, dense embeddings, and business signals.
5Cohere Rerank v3 is the most common learned reranker layered on top of Pattern 1 hybrid retrieval for RAG; the two-stage architecture (hybrid first-stage + reranker) is the 2026 default for high-quality RAG.
Interviewer follow-ups
What an interviewer would ask next. Try answering before peeking at the approach.
QWhy is Reciprocal Rank Fusion (RRF) preferred over weighted-sum fusion in production?
Sign in or go Pro to see the approach for this follow-up.
QHow does SPLADE differ from classical BM25 in a hybrid setup?
Sign in or go Pro to see the approach for this follow-up.
QWhen does adding a learned reranker on top of hybrid retrieval help most?
Sign in or go Pro to see the approach for this follow-up.
Don't say this
Red flags and common mistakes that signal junior thinking. Click to expand.
Most common mistake
Believing hybrid search is a single technique. There are two architecturally distinct patterns, and the choice has real operational and quality consequences. Production engineers need to know which pattern their vendor implements.