Hybrid search runs a keyword ranker such as BM25 and a vector search side by side, then merges the two ranked lists, usually with reciprocal rank fusion (RRF); a reranker can then reorder the top results before they reach the language model. For retrieval-augmented generation (RAG), this combination is often more reliable than vector search alone because each method fails on different queries. This explainer shows why, how the merge works, and when the extra reranking step pays for itself.

Why vector search alone falls short

Vector search embeds a query and documents into numbers and returns the nearest neighbors. It handles paraphrases well: a question about “cutting cloud costs” can match a passage about “reducing infrastructure spend.” But embeddings blur exact strings. Product codes, error messages, names, version numbers and rare acronyms may map near unrelated text, so the one passage containing the exact identifier can rank below vaguely similar ones.

Keyword search has the opposite profile. BM25, the standard lexical scoring function, rewards documents that contain the query’s terms, weighting rare terms more heavily and adjusting for document length. It is exact and fast, but it misses synonyms and rephrasings. The BEIR benchmark, which tests retrieval models across many datasets, found that BM25 remains a robust baseline that many neural retrievers fail to beat consistently outside the data they were trained on. That finding is the core argument for keeping lexical search in the pipeline.

How hybrid search works

A hybrid pipeline has four steps:

  1. Run both retrievers on the user’s query, each returning its top N candidates (often 20 to 100).
  2. Fuse the lists into one ranking.
  3. Optionally rerank the fused top candidates with a more accurate but slower model.
  4. Pass the top few passages to the language model as context.
Rows of server racks in a data center
Search indexes and vector stores run on server fleets like this; hybrid search queries both. Photo: Carl Lender from Sunrise, USA / Wikimedia Commons, CC BY 2.0

Many databases and search engines now support steps 1 and 2 in one query, so you do not have to run two systems. Our guide to choosing a vector database covers which products offer this.

Reciprocal rank fusion

The hard part of fusion is that BM25 scores and vector similarity scores live on different scales, so adding them directly is unreliable. RRF avoids this by ignoring scores and using only ranks. Each document earns 1 / (k + rank) from every list it appears in, and the scores are summed. The original paper by Cormack, Clarke and Büttcher used k = 60, a value many implementations keep as a default.

A worked example: suppose a document is ranked 1st by BM25 and 5th by vectors. With k = 60 it scores 1/61 + 1/65, about 0.0318. A document ranked 2nd by only one retriever and absent from the other scores 1/62, about 0.0161. The document that both methods like wins clearly. RRF needs no training data and rarely needs tuning, which is why it is the common first choice. If you have labeled queries, weighted score fusion after normalization can do better, but it needs maintenance.

Adding a reranker

A bi-encoder embedding model encodes the query and each document separately, which makes search fast. A cross-encoder reads the query and a candidate passage together and outputs a relevance score, which is more accurate but too slow to run over a whole corpus. The usual pattern, described in the Sentence Transformers documentation as retrieve and re-rank, is to fetch roughly 50 to 100 candidates cheaply, then rerank them and keep the best handful.

Rerankers help most when your corpus is large or noisy, when queries are long and specific, or when the context window is small and each slot matters. They cost latency and compute, so measure the gain before keeping one. Open options include models such as BGE reranker v2 and Qwen3 reranker; see the BGE reranker and Qwen3 reranker entries in our model directory.

Evaluate before you tune

Build a small test set of real questions with the passages that should answer them, then compare vector-only, BM25-only, hybrid and hybrid-plus-reranker on recall@k (is the right passage in the top k?) and on end-to-end answer quality. Chunking choices matter as much as the retriever; our guide to chunking strategies for RAG and the explainer on choosing an embedding model cover the other levers.

What to watch next

  • Native hybrid and reranking features arriving in more databases and cloud search services.
  • Embedding models that handle exact-match tokens better, narrowing the gap with BM25.
  • Long-context models tempting teams to skip retrieval, and the cost trade-offs that follow.
  • Standardized evaluation sets for enterprise RAG, beyond public benchmarks like BEIR.

Key takeaways

  • Vector search finds meaning; BM25 finds exact terms; RAG usually needs both.
  • RRF merges rankings using only ranks, with k = 60 as the usual default.
  • Rerankers add accuracy at a cost in latency; test whether you need one.
  • Measure recall@k on your own questions rather than trusting generic benchmarks.
  • Retrieval quality is often the limiting factor in RAG answer quality.

Frequently asked questions

Hybrid search combines keyword search such as BM25 with vector search and merges the results into one ranking. It catches both exact matches and semantically similar passages.

What does reciprocal rank fusion do?

RRF merges ranked lists by giving each document 1 divided by (k plus its rank) from each list and adding the results. It ignores raw scores, so it works across retrievers with different scales.

Do I always need a reranker?

No. Start with hybrid search and measure recall on your own questions. Add a reranker if relevant passages are retrieved but ranked too low, and the latency cost is acceptable.