In a RAG system, the retrieval layer determines what evidence the LLM can see. Even a strong generation model cannot produce a reliable answer when the key documents were never retrieved.

Production RAG systems therefore rarely depend on only one retrieval method. They commonly combine:

Dense Search: retrieve by semantic similarity
Sparse Search: retrieve by terms or sparse features

The two methods retrieve candidate documents in parallel, after which an algorithm such as RRF fuses their rankings. This approach is generally called Dense + Sparse Hybrid Search. Major search products including Qdrant, Elasticsearch, OpenSearch, and Azure AI Search support hybrid retrieval natively. (Qdrant)

1. Dense Search: Retrieval by Meaning

Dense Search uses an embedding model to convert queries and documents into fixed-dimensional dense vectors:

User question
"Can I take time off work after my child is born?"
        ↓ Embedding
[0.13, -0.28, 0.51, ...]

A vector-similarity search then finds the documents with the closest meaning.

Even if the document says:

Employees may request leave under the childcare-leave policy.

the phrase “childcare leave” does not appear in the query, but Dense Search may still recognize that the two texts express related concepts.

What Dense Search Does Well

  • Natural-language questions
  • Synonyms and paraphrases
  • Query rewriting
  • Cross-language semantic retrieval
  • Cases where users and source documents use different wording

Dense Search is often unreliable for exact identifiers such as:

ERR-1047
RFC 9110
X-Telegram-Bot-Api-Secret-Token
Order number A-2026-0715

An embedding may consider two similar identifiers semantically close even though ERR-1047 and ERR-1048 represent completely different business problems.

Dense Search can also retrieve documents that discuss a similar topic without actually answering the question.

2. Sparse Search: Retrieval by Terms and Sparse Features

Sparse representations usually have a very large dimensional space, but only a small number of nonzero dimensions for each document. BM25 and inverted indexes are the most common sparse-retrieval methods in enterprise search.

BM25 primarily considers:

  • Whether query terms occur in the document
  • Term frequency
  • How rare each term is across the corpus
  • Document length

OpenSearch uses BM25 for keyword search by default. Its documentation notes that BM25 is effective for queries containing explicit keywords but cannot fully understand their underlying meaning. (OpenSearch Documentation)

What Sparse Search Does Well

  • Product models
  • Error codes
  • API names
  • Names of people, companies, and other proper nouns
  • Legal provision numbers
  • Exact phrases
  • Numbers, dates, and abbreviations

For a query such as:

What is ERR-1047?

BM25 can usually find a document containing ERR-1047 directly without confusing it with a semantically similar error code.

Sparse Search is less sensitive to differences in expression.

Suppose a document uses the Japanese term:

育児休業

while a user asks:

Can I temporarily stop working to take care of my child?

Without synonym expansion or other language processing, traditional keyword search may not find the document.

3. Sparse Does Not Always Mean BM25

In discussions of Hybrid Search, “sparse” may refer to two categories of technology.

Traditional Lexical Retrieval

BM25
TF-IDF
Inverted indexes

These approaches depend on actual terms in the query and document. They are efficient, interpretable, and strong at exact matching.

Neural Sparse Retrieval

Examples include SPLADE and neural sparse models offered by search engines.

Such models generate sparse weights for terms and may expand related query terms. They can add some semantic capability while retaining the efficiency and partial interpretability of inverted indexes. OpenSearch defines Neural Sparse Search as retrieval based on sparse representations and inverted indexes, and supports combining it with Dense Search. (OpenSearch Documentation)

For most first versions of a RAG system, a reasonable starting point is:

Dense Embeddings + BM25

Introduce a neural sparse model only if evaluation shows that traditional BM25 cannot meet recall requirements.

4. Why Use Both?

Dense and Sparse Search have complementary strengths and failure modes:

Dense:
understand what the user means

Sparse:
verify the exact words the user supplied

For the query:

How can I undo the purchase I just made?

Dense Search may find a document titled “Returns and Order Cancellations” even though it uses different words.

For the query:

Current status of order A-20260715-009

Sparse Search is better suited to matching the order number exactly.

Hybrid Search can therefore cover:

  • Differences in semantic expression
  • Exact keywords
  • Specialized terms
  • Numbers and codes
  • Long-tail natural-language questions

Elastic describes Hybrid Search as combining keyword and semantic retrieval into one ranking so that lexical precision and semantic understanding can be used together. (Elastic)

This does not mean Hybrid Search is guaranteed to outperform a single retriever on every dataset. It increases indexing, querying, tuning, and evaluation complexity. Its actual benefit must be verified on a system’s own retrieval dataset.

5. How to Fuse Two Result Lists

Raw Dense and Sparse scores generally cannot be added directly.

For example:

Dense cosine score: 0.82
BM25 score: 14.6

The scales and meanings differ, so 14.6 cannot be treated as more relevant than 0.82.

RRF: A Common Default

RRF stands for Reciprocal Rank Fusion. Instead of comparing raw scores, it fuses documents according to their positions in separate result lists.

A simplified formula is:

RRF(document) = Σ 1 / (k + rank)

where:

  • rank is the document’s position in a result list;
  • k is a constant that reduces the difference between top positions.

Suppose the results are:

Dense ranking:
A: 1st
B: 2nd
C: 3rd

Sparse ranking:
C: 1st
A: 2nd
D: 3rd

A and C rank highly in both lists and will therefore tend to receive the strongest fused rankings.

Azure AI Search uses RRF to combine full-text and vector queries that run in parallel. Elastic also recommends RRF as a common starting point for Hybrid Search. (Microsoft Learn)

RRF offers several advantages:

  • No need to align score scales
  • Few parameters
  • Robustness across different retrievers
  • A good initial baseline

Its limitation is that it depends mainly on rank and does not use fine-grained differences in raw scores. If a business must explicitly control Dense and Sparse weights, weighted fusion, score normalization, or learning to rank may be more appropriate.

6. A Typical Production Retrieval Pipeline

A common enterprise RAG pipeline looks like this:

User query
   │
   ├── Dense Query Embedding
   │       ↓
   │   Dense Top K
   │
   └── BM25 / Sparse Encoding
           ↓
       Sparse Top K
           │
           ▼
        RRF Fusion
           │
           ▼
     Deduplication and Filtering
           │
           ▼
       Cross-Encoder Rerank
           │
           ▼
       Final Top N Chunks
           │
           ▼
          LLM

An experiment might begin with:

Dense Top K: 20–50
Sparse Top K: 20–50
Candidates after fusion: 20–50
After reranking: 5–10
Sent to the LLM: 3–8

These are starting points, not universal best parameters. Qdrant can store Dense and Sparse representations in the same collection and perform multi-result fusion with RRF or DBSF on the server. (Qdrant)

7. The Relationship Between Hybrid Search and Rerankers

Hybrid Search primarily answers:

How can the system retrieve as many relevant documents as possible into the candidate set?

A reranker primarily answers:

Which documents inside that candidate set are most relevant?

The roles are different:

Dense + Sparse Hybrid Search
→ Improve recall

Cross-Encoder / ColBERT / Rerank API
→ Improve final ranking precision

A common two-stage design is therefore:

Stage one:
Quickly retrieve dozens of candidates with Dense + Sparse

Stage two:
Use a more expensive model to rescore each query-document pair

For small datasets or simple queries, returning the Hybrid Search result directly may be sufficient. A reranker adds latency and cost, so evaluation should determine whether it is necessary.

8. Where Hybrid Search Is Most Useful

Hybrid Search is generally well suited to:

  • Enterprise knowledge bases
  • Technical and API documentation
  • Customer-support knowledge bases
  • Laws, regulations, and contracts
  • Product manuals
  • Code search
  • Corpora containing many models, numbers, abbreviations, and proper nouns
  • Multilingual knowledge bases

Dense Search alone may be sufficient when:

  • The dataset is small
  • The content is mostly natural language
  • Exact numbers and identifiers are rare
  • The project is an early prototype
  • Offline evaluation shows that Sparse Search provides no meaningful gain

A sound engineering principle is not that every RAG system must use Hybrid Search, but:

Establish Dense, Sparse, and Hybrid baselines, then use real data to decide whether the extra complexity is justified.

9. How to Evaluate It

Do not judge Hybrid Search with only a few hand-written questions. Build a retrieval dataset with relevance annotations and run:

Dense-only
Sparse-only
Dense + Sparse Hybrid
Hybrid + Reranker

Important metrics include:

Recall@K
Precision@K
MRR
nDCG@K
Hit Rate
Retrieval latency
Cost per query

Analyze results by query type as well:

Natural-language queries
Exact keywords
Error codes and numbers
Multilingual queries
No-answer queries
Abbreviations and specialized terms

Possible outcomes include:

  • Dense is best for natural-language questions.
  • Sparse is best for identifiers and proper nouns.
  • Hybrid has the best overall average.
  • Hybrid offers only a small gain while significantly increasing latency.

Only this kind of evaluation can determine whether Hybrid Search is appropriate for a specific system.

Conclusion

Dense + Sparse Hybrid Search is not a new retrieval algorithm. It is a combination strategy:

Dense provides semantic recall
Sparse provides lexical precision
RRF fuses the rankings
A reranker further improves precision

It is widely used in enterprise RAG because enterprise documents combine natural language with numbers, terms, product names, and error codes.

Hybrid Search is not unconditionally optimal. It increases index size, query latency, system complexity, and evaluation cost. A safer approach is:

Use Dense-only and Sparse-only as baselines, verify the real gain of Hybrid Search through retrieval evaluation, and only then decide whether to take it into production.