Hybrid Search Retriever¶
📖 Overview¶
A Hybrid Search Retriever combines multiple retrieval signals—most commonly dense vector search and sparse lexical search—to improve both semantic understanding and exact-term matching.
Traditional vector retrieval is excellent at understanding meaning:
Lexical retrieval such as BM25 is strong at exact terminology:
Hybrid search combines both:
User Query
│
┌─────────┴─────────┐
↓ ↓
Dense Retrieval Sparse Retrieval
Vector Search BM25
│ │
↓ ↓
Semantic Results Keyword Results
│ │
└─────────┬─────────┘
↓
Result Fusion
↓
Final Ranking
↓
Top-K
The core idea is:
Use semantic retrieval for meaning and lexical retrieval for exact terminology, then combine their signals into a stronger candidate ranking.
🎯 Learning Objectives¶
After completing this chapter, you will be able to:
- Understand hybrid search
- Understand dense and sparse retrieval
- Understand why semantic search alone can miss important results
- Understand why lexical search alone can miss semantic relationships
- Compare BM25 and vector retrieval
- Understand score normalization
- Understand weighted score fusion
- Understand Reciprocal Rank Fusion
- Build a dense + sparse retrieval pipeline
- Implement hybrid retrieval using Python
- Understand metadata and filtering in hybrid search
- Combine hybrid search with reranking
- Combine hybrid search with Multi-Vector Retrieval
- Combine hybrid search with contextual compression
- Evaluate hybrid retrieval against single-retriever baselines
- Design production-grade hybrid retrieval architectures
1. What Is Hybrid Search?¶
Hybrid search combines different retrieval methods.
The most common architecture is:
Dense Retrieval¶
Uses embeddings:
Sparse Retrieval¶
Uses lexical matching:
Hybrid search combines the results.
flowchart TD
A["User Query"] --> B["Dense Retriever"]
A --> C["Sparse Retriever"]
B --> D["Vector Results"]
C --> E["BM25 Results"]
D --> F["Fusion"]
E --> F
F --> G["Final Ranking"]
G --> H["Top-K Documents"]2. Why Dense Retrieval Alone Is Not Enough¶
Dense retrieval works by representing text as vectors.
For example:
may retrieve:
even though the exact word "password" may not appear.
This is powerful.
However, consider:
The exact identifier:
may be extremely important.
A semantic embedding may not rank the exact document as highly as expected.
This is where lexical retrieval helps.
3. Why Sparse Retrieval Alone Is Not Enough¶
BM25 and other lexical retrieval methods are strong at exact terms.
For example:
BM25 can match:
But consider:
A document discussing:
may be highly relevant even if the exact words do not overlap.
Dense retrieval can identify that semantic relationship.
Therefore:
4. Dense vs Sparse Retrieval¶
| Capability | Dense Retrieval | Sparse Retrieval |
|---|---|---|
| Semantic similarity | Strong | Limited |
| Exact keywords | Moderate | Strong |
| Product IDs | Can struggle | Strong |
| Error codes | Can struggle | Strong |
| Synonyms | Strong | Limited |
| Natural language queries | Strong | Moderate |
| Domain terminology | Strong | Strong |
| Infrastructure complexity | Vector index | Inverted index |
| Typical technology | Embeddings | BM25 / Sparse vectors |
Hybrid search attempts to combine the complementary strengths.
5. Dense Retrieval¶
A dense retriever converts text into a dense numerical vector.
Conceptually:
At query time:
Common similarity functions include:
6. Sparse Retrieval¶
Sparse retrieval represents documents using term-based signals.
A simplified representation might look like:
Sparse representation:
A query is matched using lexical statistics.
BM25 is one of the most common approaches.
7. BM25¶
BM25 considers factors such as:
Conceptually:
This makes BM25 especially useful for:
8. Hybrid Search Architecture¶
A production-oriented hybrid retriever can look like:
flowchart TD
A["User Query"] --> B["Query Preprocessing"]
B --> C["Dense Query"]
B --> D["Sparse Query"]
C --> E["Embedding Model"]
D --> F["BM25 / Sparse Encoder"]
E --> G["Vector Search"]
F --> H["Sparse Search"]
G --> I["Dense Results"]
H --> J["Sparse Results"]
I --> K["Result Fusion"]
J --> K
K --> L["Deduplication"]
L --> M["Reranking"]
M --> N["Top-K Context"]The two retrieval paths can run independently and then converge.
9. Basic Hybrid Pipeline¶
The simplest architecture is:
Query
↓
┌───────────────┐
│ │
↓ ↓
Dense Sparse
Search Search
│ │
↓ ↓
Results Results
└───────┬───────┘
↓
Fusion
↓
Top-K
This is the fundamental hybrid search pattern.
10. Result Fusion¶
The retrieval systems produce different results.
Example:
Dense¶
BM25¶
Hybrid fusion combines these rankings:
and calculates a combined ranking.
The fusion strategy is one of the most important parts of hybrid retrieval.
11. Fusion Strategy 1 — Weighted Scores¶
One approach is to combine normalized scores.
Conceptually:
For example:
means:
Architecture:
12. Why Score Normalization Matters¶
Dense and sparse scores often have different ranges.
For example:
BM25:
Directly combining these values is problematic.
does not provide a meaningful comparable signal.
Therefore, weighted score fusion usually requires normalization.
13. Score Normalization¶
Possible normalization techniques include:
For example, Min-Max normalization:
After normalization:
The scores can then be combined more meaningfully.
14. Weighted Hybrid Scoring¶
Conceptually:
Then:
The important architecture is:
15. Fusion Strategy 2 — Reciprocal Rank Fusion¶
Another common strategy is Reciprocal Rank Fusion (RRF).
Instead of comparing raw scores, it combines rankings.
Conceptually:
This is useful because:
and:
do not need to be directly comparable.
The retrievers contribute based on rank.
16. RRF Example¶
Dense results:
Sparse results:
Document A appears:
Document C:
Both receive strong combined ranking signals.
Architecture:
flowchart LR
A["Dense Ranking"] --> C["RRF"]
B["Sparse Ranking"] --> C
C --> D["Combined Ranking"]
D --> E["Top-K"]17. Weighted Fusion vs RRF¶
Weighted Score Fusion¶
Advantages:
- Allows explicit weighting
- Can represent confidence differences
- Can be tuned to domain behavior
Challenges:
- Score distributions differ
- Normalization can be difficult
- Scores may drift across systems
RRF¶
Advantages:
- Does not require comparable raw scores
- Simple
- Robust across heterogeneous retrievers
Challenges:
- Loses some score information
- Requires careful rank-window selection
- May need additional weighting for specialized retrievers
18. Hybrid Search with BM25¶
A simple Python example:
from langchain_community.retrievers import BM25Retriever
bm25_retriever = BM25Retriever.from_documents(
documents
)
bm25_retriever.k = 10
results = bm25_retriever.invoke(
"OAuth authentication"
)
This provides the sparse retrieval path.
The dense path may use:
The two result sets can then be fused.
19. LangChain Ensemble-Based Hybrid Retrieval¶
A simple implementation can use the ensemble abstraction:
from langchain.retrievers import EnsembleRetriever
hybrid_retriever = EnsembleRetriever(
retrievers=[
vector_retriever,
bm25_retriever
],
weights=[
0.7,
0.3
]
)
results = hybrid_retriever.invoke(
"How does OAuth authentication work?"
)
Conceptually:
The exact fusion behavior depends on the framework implementation and configuration.
20. Dense + Sparse Search with a Vector Database¶
Some vector databases support hybrid search directly.
Conceptually:
Query
│
┌───────┴───────┐
↓ ↓
Dense Vector Sparse Vector
│ │
└───────┬───────┘
↓
Hybrid Index
↓
Fused Ranking
↓
Top-K
This can reduce application-side fusion complexity.
The exact API and supported sparse representation depend on the vector database.
21. Hybrid Search with Sparse Vectors¶
Sparse retrieval does not always have to mean BM25.
Modern retrieval systems may use sparse embedding models.
For example:
Architecture:
At query time:
The two signals can then be combined.
22. Dense + Sparse Representation¶
flowchart TD
A["Document"] --> B["Dense Encoder"]
A --> C["Sparse Encoder"]
B --> D["Dense Vector"]
C --> E["Sparse Vector"]
D --> F["Hybrid Index"]
E --> F
G["User Query"] --> H["Dense Query Encoder"]
G --> I["Sparse Query Encoder"]
H --> J["Dense Query"]
I --> K["Sparse Query"]
J --> F
K --> F
F --> L["Hybrid Ranking"]This architecture is increasingly common in modern search infrastructure.
23. Query Processing¶
The query should usually be sent through both retrieval paths.
Example:
Dense path:
Sparse path:
The exact identifier:
can strongly influence the sparse path.
The semantic concept:
can influence the dense path.
24. Query Expansion¶
Hybrid retrieval can also benefit from query rewriting.
For example:
Possible expanded query:
The expanded query can improve lexical retrieval while the original query remains useful for semantic retrieval.
A possible architecture:
User Query
↓
Query Processing
↓
┌──────────────┬──────────────┐
↓ ↓
Original Expanded
Query Query
↓ ↓
Dense Sparse
Search Search
25. Hybrid Search and Advanced Query Rewriting¶
Hybrid retrieval can be combined with query rewriting.
Query
↓
Query Rewriting
↓
┌─────────────┬─────────────┐
↓ ↓
Dense Query Sparse Query
↓ ↓
Retrieval Retrieval
└──────┬──────┘
↓
Fusion
This becomes especially useful for:
26. Hybrid Search with Metadata Filtering¶
Metadata filters can be applied before or during retrieval.
Example query:
Filter:
Architecture:
The distinction is important:
Metadata Filter
→ Which documents are eligible?
Hybrid Search
→ Which eligible documents are most relevant?
27. Hybrid Search with Time Weighting¶
The temporal signal discussed in the previous chapter can also be incorporated.
Architecture:
flowchart TD
A["Query"] --> B["Dense Retrieval"]
A --> C["Sparse Retrieval"]
B --> D["Dense Results"]
C --> E["Sparse Results"]
D --> F["Candidate Pool"]
E --> F
F --> G["Temporal Scoring"]
G --> H["Hybrid Ranking"]
H --> I["Top-K"]This can be useful for frequently changing enterprise knowledge.
28. Hybrid Search + Multi-Vector Retrieval¶
Hybrid retrieval can also be combined with Multi-Vector Retrieval.
Architecture:
flowchart TD
A["User Query"] --> B["Multi-Vector Retriever"]
A --> C["Sparse Retriever"]
B --> D["Semantic Representations"]
C --> E["Keyword Results"]
D --> F["Fusion"]
E --> F
F --> G["Parent Resolution"]
G --> H["Final Documents"]This provides:
29. Hybrid Search + Reranking¶
Hybrid retrieval usually focuses on candidate generation.
A reranker can then improve precision.
Architecture:
flowchart LR
A["Query"] --> B["Dense Search"]
A --> C["Sparse Search"]
B --> D["Dense Results"]
C --> E["Sparse Results"]
D --> F["Fusion"]
E --> F
F --> G["Candidate Pool"]
G --> H["Reranker"]
H --> I["Final Top-K"]This creates a clear separation:
30. Hybrid Search + Contextual Compression¶
A complete RAG retrieval pipeline can be:
Query
↓
Dense + Sparse Retrieval
↓
Fusion
↓
Candidate Pool
↓
Reranking
↓
Contextual Compression
↓
Prompt Assembly
↓
LLM
Architecture:
flowchart TD
A["User Query"] --> B["Dense Retriever"]
A --> C["Sparse Retriever"]
B --> D["Dense Results"]
C --> E["Sparse Results"]
D --> F["Fusion"]
E --> F
F --> G["Candidate Pool"]
G --> H["Reranker"]
H --> I["Contextual Compression"]
I --> J["Prompt Assembly"]
J --> K["LLM"]31. Hybrid Search and Citation¶
The hybrid retrieval layer should preserve source metadata.
Example:
{
"document_id": "doc-100",
"source": "oauth-guide.pdf",
"page": 18,
"retrieval_sources": [
"dense",
"sparse"
]
}
This allows the application to explain:
The user-facing answer should cite the original source rather than the retrieval mechanism.
32. Retrieval Provenance¶
A production system can preserve:
Document ID
Chunk ID
Source
Page
Dense Rank
Sparse Rank
Dense Score
Sparse Score
Fusion Score
Reranker Score
Example:
{
"document_id": "doc-100",
"dense_rank": 2,
"sparse_rank": 1,
"dense_score": 0.89,
"sparse_score": 14.2,
"fusion_score": 0.94
}
This is valuable for retrieval observability.
33. Deduplication¶
Dense and sparse retrieval may return the same document.
Example:
Without deduplication:
The fusion layer should consolidate them:
using a stable identifier such as:
34. Parallel Retrieval¶
Dense and sparse retrieval can often execute concurrently.
Sequential:
Parallel:
flowchart TD
A["Query"] --> B["Dense Search"]
A --> C["Sparse Search"]
B --> D["Dense Results"]
C --> E["Sparse Results"]
D --> F["Fusion"]
E --> F
F --> G["Final Ranking"]This can reduce end-to-end retrieval latency.
35. Python Parallel Example¶
A simplified example:
from concurrent.futures import ThreadPoolExecutor
def hybrid_retrieve(query):
with ThreadPoolExecutor(
max_workers=2
) as executor:
dense_future = executor.submit(
vector_retriever.invoke,
query
)
sparse_future = executor.submit(
bm25_retriever.invoke,
query
)
dense_results = dense_future.result()
sparse_results = sparse_future.result()
return dense_results, sparse_results
Production implementations should use the concurrency model appropriate to the application runtime and retrieval infrastructure.
36. Hybrid Retrieval Interface¶
A framework-independent abstraction can expose a simple interface:
from abc import ABC, abstractmethod
class HybridRetriever(ABC):
@abstractmethod
def retrieve(
self,
query: str,
top_k: int
) -> list:
pass
An implementation can contain:
Architecture:
Application
↓
HybridRetriever Interface
↓
┌──────────────┬──────────────┐
↓ ↓
Dense Sparse
Adapter Adapter
└──────┬───────┘
↓
Fusion
37. Configuration-Driven Hybrid Retrieval¶
Example configuration:
retrieval:
hybrid:
enabled: true
dense:
top_k: 20
weight: 0.7
sparse:
top_k: 20
weight: 0.3
fusion:
strategy: rrf
deduplication:
enabled: true
reranking:
enabled: true
top_k: 5
This allows the retrieval architecture to evolve without changing application code.
38. Weight Tuning¶
Do not assume:
is always optimal.
Possible experiments:
Evaluate each configuration.
The correct configuration depends on the query distribution and corpus.
39. Query-Type-Based Weighting¶
Different queries may benefit from different weighting.
Semantic Query¶
Possible preference:
Identifier Query¶
Possible preference:
Mixed Technical Query¶
Possible preference:
This suggests an advanced architecture:
40. Dynamic Hybrid Retrieval¶
flowchart TD
A["User Query"] --> B["Query Classifier"]
B --> C["Semantic Query"]
B --> D["Exact-Term Query"]
B --> E["Mixed Query"]
C --> F["Dense-Heavy Weights"]
D --> G["Sparse-Heavy Weights"]
E --> H["Balanced Weights"]
F --> I["Hybrid Retrieval"]
G --> I
H --> I
I --> J["Fusion"]
J --> K["Reranking"]This can improve retrieval across heterogeneous query types.
However, dynamic weighting introduces additional system complexity and should be adopted only when evaluation demonstrates a benefit.
41. Hybrid Search Evaluation¶
The correct baseline should include:
Compare:
Architecture:
flowchart LR
A["Evaluation Dataset"] --> B["Dense Retriever"]
A --> C["Sparse Retriever"]
A --> D["Hybrid Retriever"]
B --> E["Dense Metrics"]
C --> F["Sparse Metrics"]
D --> G["Hybrid Metrics"]
E --> H["Comparison"]
F --> H
G --> H
H --> I["Production Decision"]42. Example Evaluation¶
Illustrative numbers:
| Retriever | Recall@10 | MRR | Latency |
|---|---|---|---|
| Dense | 0.78 | 0.69 | 40 ms |
| Sparse | 0.72 | 0.63 | 20 ms |
| Hybrid | 0.87 | 0.78 | 58 ms |
The important lesson is not the specific numbers.
The important question is:
43. Query-Level Evaluation¶
Aggregate metrics can hide important behavior.
Evaluate query categories separately:
Semantic Queries
Exact Identifiers
Technical Queries
Short Queries
Long Queries
Acronym-Heavy Queries
Metadata-Heavy Queries
Example:
| Query Type | Dense | Sparse | Hybrid |
|---|---|---|---|
| Semantic | High | Medium | High |
| Exact IDs | Medium | High | High |
| Technical | High | High | Very High |
| Short | Medium | High | High |
This helps identify where hybrid retrieval actually provides value.
44. End-to-End RAG Evaluation¶
Retrieval metrics alone are insufficient.
The complete pipeline should be evaluated:
Useful metrics include:
The ultimate goal is better AI application behavior, not simply higher retrieval scores.
45. Observability¶
A production hybrid retriever should expose both retrieval paths.
Example:
Query:
"OAuth AUTH-401 troubleshooting"
Dense:
Top-K = 10
Latency = 38 ms
Sparse:
Top-K = 10
Latency = 17 ms
Fusion:
Candidates = 20
Duplicates = 7
Reranker:
Input = 13
Output = 5
Final:
Top-K = 5
This makes debugging significantly easier.
46. Retrieval Trace¶
A structured trace can contain:
{
"query": "OAuth AUTH-401 troubleshooting",
"dense": {
"top_k": 10,
"latency_ms": 38
},
"sparse": {
"top_k": 10,
"latency_ms": 17
},
"fusion": {
"strategy": "rrf",
"candidate_count": 20,
"duplicate_count": 7
},
"reranker": {
"enabled": true,
"top_k": 5
}
}
This is useful for:
47. Common Failure Modes¶
47.1 Poor Score Normalization¶
Incorrect normalization can allow one retriever to dominate.
47.2 Incorrect Weights¶
Weights should be evaluated against real queries.
47.3 Duplicate Results¶
Dense and sparse retrieval frequently return overlapping documents.
Deduplication is necessary.
47.4 Too Many Candidates¶
Retrieving too many candidates can increase:
47.5 Poor Sparse Index¶
BM25 quality depends heavily on:
47.6 Poor Dense Embeddings¶
A weak embedding model can reduce the value of the dense retrieval path.
47.7 No Measurable Improvement¶
The most important failure mode is:
Always compare against a strong baseline.
48. Language and Tokenization Considerations¶
Sparse retrieval depends heavily on tokenization.
For example:
may be treated differently from:
Similarly:
may require normalization.
Domain-specific tokenization can therefore significantly affect lexical retrieval quality.
49. Domain-Specific Vocabulary¶
Enterprise systems often contain:
Product IDs
Service Names
Error Codes
Acronyms
Internal Terminology
Database Tables
API Names
Ticket IDs
Sparse retrieval can be particularly valuable for these terms.
Example:
A hybrid retriever can use:
50. Hybrid Search for Technical Documentation¶
Technical documentation is an excellent use case.
Query:
Dense retrieval can understand:
Sparse retrieval can match:
The combination is stronger than either signal alone.
51. Hybrid Search for Enterprise Policies¶
Consider:
The query contains:
and potentially:
A production system may combine:
This demonstrates that hybrid retrieval is one component within a larger retrieval architecture.
52. Hybrid Search with Advanced Retrieval¶
Hybrid retrieval can participate in a larger pipeline:
Query
↓
Query Rewriting
↓
Metadata Filtering
↓
Dense + Sparse Retrieval
↓
Fusion
↓
Multi-Vector / Parent Resolution
↓
Reranking
↓
MMR
↓
Contextual Compression
↓
Prompt Assembly
↓
LLM
The important design principle is modularity.
Each stage should have a clear responsibility.
53. Production Architecture¶
A mature enterprise architecture can look like:
flowchart TD
A["User Query"] --> B["Query Understanding"]
B --> C["Query Rewriting"]
C --> D["Metadata / Access Filters"]
D --> E["Dense Retrieval"]
D --> F["Sparse Retrieval"]
E --> G["Dense Results"]
F --> H["Sparse Results"]
G --> I["Fusion"]
H --> I
I --> J["Deduplication"]
J --> K["Multi-Vector / Parent Resolution"]
K --> L["Reranker"]
L --> M["MMR / Diversity"]
M --> N["Contextual Compression"]
N --> O["Context Selection"]
O --> P["Prompt Assembly"]
P --> Q["LLM"]
Q --> R["Response Validation"]
R --> S["Citation / Source Attribution"]This represents hybrid search as a candidate-generation layer, rather than treating it as the entire RAG architecture.
54. Enterprise Design Principle¶
A useful architecture separation is:
Dense Retriever
↓
Semantic Signal
Sparse Retriever
↓
Lexical Signal
Fusion
↓
Combined Candidate Set
Reranker
↓
Precision
Context Selection
↓
Generation Context
Each layer solves a different problem.
This makes the system easier to:
55. Framework-Agnostic Design¶
An enterprise AI platform should avoid exposing framework-specific retrieval details to business services.
Instead:
Business Service
↓
EnterpriseRetriever
↓
Hybrid Retrieval Adapter
├── Dense Adapter
└── Sparse Adapter
For example:
Then:
class DenseRetrievalProvider(RetrievalProvider):
...
class SparseRetrievalProvider(RetrievalProvider):
...
class HybridRetrievalProvider(RetrievalProvider):
...
This aligns hybrid retrieval with a Ports & Adapters architecture.
56. Configuration Example¶
retrieval:
strategy: hybrid
dense:
provider: vector_store
top_k: 20
sparse:
provider: bm25
top_k: 20
fusion:
strategy: rrf
deduplication:
key: chunk_id
reranking:
enabled: true
top_k: 8
context:
compression: true
The application can therefore change:
without changing business-level RAG logic.
57. Testing Strategy¶
A hybrid retrieval implementation should have several layers of tests.
Unit Tests¶
Test:
Integration Tests¶
Test:
Evaluation Tests¶
Test:
End-to-End Tests¶
Test:
58. Example Fusion Unit Test¶
def test_hybrid_fusion_prefers_shared_results():
dense_results = [
"doc-a",
"doc-b",
"doc-c"
]
sparse_results = [
"doc-c",
"doc-a",
"doc-d"
]
results = fuse_results(
dense_results,
sparse_results
)
assert "doc-a" in results
assert "doc-c" in results
A production evaluation should use relevance-labeled datasets in addition to simple unit tests.
59. Decision Framework¶
flowchart TD
A["Current Retriever"] --> B{"Exact Terms Frequently Matter?"}
B -->|Yes| C["Add Sparse Retrieval"]
B -->|No| D{"Semantic Recall Weak?"}
D -->|Yes| E["Improve Dense Retrieval"]
D -->|No| F["Evaluate Current System"]
C --> G["Hybrid Search"]
G --> H{"Quality Improvement?"}
H -->|Yes| I["Tune Fusion"]
H -->|No| J["Reconsider Complexity"]
I --> K["Evaluate Latency + Cost"]
K --> L["Production Decision"]60. When Hybrid Search Is Most Useful¶
Hybrid search is particularly useful when:
- Exact terminology matters
- Semantic meaning also matters
- Documents contain technical identifiers
- Error codes are important
- Product names must match exactly
- Acronyms are common
- Users use both natural-language and keyword-style queries
- Enterprise documentation is heterogeneous
- Dense retrieval alone misses exact matches
- Sparse retrieval alone misses semantic relationships
Typical applications include:
Enterprise Search
Technical Documentation
Developer Copilots
Customer Support
Product Search
Legal Search
Financial Research
Knowledge Assistants
Internal Enterprise Search
61. When Hybrid Search May Not Be Necessary¶
Hybrid search may not be justified when:
or:
or:
or:
or:
Always measure before adopting.
62. Recommended Enterprise Pattern¶
A practical enterprise architecture is:
Query
↓
Query Understanding
↓
Metadata / Security Filters
↓
Dense + Sparse Retrieval
↓
Fusion
↓
Deduplication
↓
Reranking
↓
MMR / Diversity
↓
Contextual Compression
↓
Prompt Assembly
↓
LLM
↓
Response Validation
↓
Citation
The role of hybrid search is primarily:
63. Production Checklist¶
Before deploying hybrid search:
☐ Dense baseline has been evaluated
☐ Sparse baseline has been evaluated
☐ Hybrid retrieval has been evaluated
☐ Dense and sparse query paths are defined
☐ Score normalization is handled when required
☐ Fusion strategy is explicitly selected
☐ Retriever weights are configurable
☐ Duplicate results are removed
☐ Stable document/chunk IDs are available
☐ Metadata is preserved
☐ Parallel retrieval is considered
☐ Latency is measured independently for both retrievers
☐ Fusion latency is measured
☐ Reranker impact is measured
☐ Retrieval cost is measured
☐ Query-type performance is evaluated
☐ Technical identifiers are tested
☐ Historical/time-aware queries are tested where applicable
☐ Citation provenance is preserved
☐ Regression tests are implemented
☐ End-to-end RAG quality is evaluated
64. Key Takeaways¶
- Hybrid Search combines multiple retrieval signals.
- The most common combination is dense vector retrieval + sparse lexical retrieval.
- Dense retrieval is strong at semantic similarity.
- Sparse retrieval is strong at exact terminology.
- BM25 remains a useful lexical retrieval technique.
- Modern systems can also combine dense vectors with learned sparse representations.
- Raw dense and sparse scores usually should not be combined without appropriate normalization.
- Rank-based fusion such as RRF avoids direct score comparability problems.
- Weighted fusion provides explicit control over retrieval contributions.
- Dense and sparse retrieval can often execute in parallel.
- Deduplication is important because both retrievers may return the same documents.
- Query-specific weighting can improve performance for heterogeneous workloads.
- Hybrid retrieval works particularly well for technical and enterprise knowledge.
- Hybrid search can be combined with metadata filtering, time weighting, Multi-Vector Retrieval, reranking, MMR, and contextual compression.
- Hybrid retrieval is primarily a candidate-generation and ranking strategy.
- A reranker can provide an additional precision layer.
- Retrieval provenance should be preserved for observability and citation.
- Hybrid retrieval should always be evaluated against both dense-only and sparse-only baselines.
- More retrieval complexity is justified only when it produces measurable improvement.
The central pattern is:
Dense Retrieval
+
Sparse Retrieval
↓
Fusion
↓
Better Candidate Recall
↓
Reranking
↓
Better Precision
↓
Context Optimization
↓
Reliable Generation
Or simply:
🧭 Chapter Navigation¶
Part V — Advanced Retrieval-Augmented Generation¶
Previous:
04. Time-Weighted Retriever
Next:
06. HyDE Retriever
Section:
02 — Enterprise Retrieval Engineering
Enterprise Retrieval Engineering Path¶
01 Contextual Compression Retriever
↓
02 Ensemble Retriever
↓
03 Multi-Vector Retriever
↓
04 Time-Weighted Retriever
↓
05 Hybrid Search Retriever
↓
06 HyDE Retriever
↓
07 Router Retriever
↓
08 Multi-Stage Retrieval
↓
09 Agentic Retrieval
↓
10 Re-ranking Techniques
↓
11 MMR & Diversity-Aware Retrieval
↓
12 Metadata-Aware Retrieval
↓
13 Advanced Query Rewriting
Enterprise AI Engineering Handbook
Building Production-Grade Enterprise AI Systems — One Chapter at a Time.