Skip to main content
Hybrid retrieval combines dense semantic embeddings with sparse lexical embeddings to improve robustness across both natural-language and keyword-precise queries.

How it works

1

Dual indexing

Each document is embedded twice — once with HuggingFaceEmbeddings for the dense semantic vector, and once with a sparse embedding model for the token-weight lexical vector. Both vectors are stored in the backend.
2

Dual retrieval

At query time, the same query is embedded with both the dense and sparse models.
3

Score fusion

Dense and sparse retrieval results are merged using ResultMerger from utils/fusion.py. The default strategy is Reciprocal Rank Fusion (RRF).
4

Final ranking

The fused, deduplicated list (up to top_k) is returned.

Reciprocal Rank Fusion

ResultMerger.reciprocal_rank_fusion() combines rankings using:
where k is a constant (typically 60) and rank is the position from each retrieval source. This is robust to different score scales because it operates on ranks, not raw scores.

Pinecone hybrid indexing

Pinecone natively supports hybrid search with both dense and sparse vectors:
src/vectordb/langchain/hybrid_indexing/indexing/pinecone.py

Result merger for fusion

The ResultMerger provides multiple fusion strategies:
src/vectordb/langchain/utils/fusion.py

Configuration

When to use it

  • Mixed query styles where some users phrase naturally and others search with domain terms
  • Enterprise knowledge bases with exact product names, codes, or identifiers alongside conceptual questions
  • Any workload where pure semantic search misses documents containing exact query terms

When not to use it

  • Small datasets where dual indexing complexity has negligible quality impact
  • Prototypes where the semantic baseline has not yet been validated
  • Backends that do not natively support sparse vectors

Tradeoffs

Settings to tune first

string
default:"rrf"
"rrf" requires no tuning; "weighted" gives explicit control over dense vs sparse contribution.
string
SPLADE model quality directly affects lexical matching coverage.Recommended: naver/splade-cocondenser-ensembledistil
integer
default:"30"
Each retriever fetches this many candidates before fusion; larger pools improve fusion quality.

Common pitfalls

Unbalanced fusion: Weight near-zero on either side effectively reverts to single-signal retrieval. Measure both retrieval paths independently first.
Missing sparse model at query time: Ensure both dense and sparse embedding configs are consistent between indexing and search scripts.
Not validating per-query-class behavior: Hybrid helps keyword-heavy queries most. If your evaluation set is all natural-language questions, the improvement over semantic search may be modest.

Backends supported

Chroma, Milvus, Pinecone, Qdrant, Weaviate.

Next steps

Add reranking

Add reranking after fusion for further precision improvement

Sparse-only indexing

Use sparse indexing alone if keyword precision is the dominant need

Measure improvement

Measure against semantic search to quantify the hybrid improvement

Components

Explore other reusable LangChain components