HyDE Retriever¶
📖 Overview¶
HyDE — Hypothetical Document Embeddings is a retrieval technique that improves semantic search by generating a hypothetical answer/document from the user's query and then using that generated text to perform vector retrieval.
Instead of directly embedding:
HyDE introduces an intermediate representation:
The key idea is:
Search using an embedding of a hypothetical document rather than directly embedding the original query.
The hypothetical document is used only as a retrieval representation. The final answer should still be generated from retrieved source documents.
🎯 Learning Objectives¶
After completing this chapter, you will be able to:
- Understand Hypothetical Document Embeddings
- Understand why direct query embedding can be insufficient
- Understand the HyDE retrieval pipeline
- Generate hypothetical documents using an LLM
- Embed hypothetical documents
- Retrieve source documents using HyDE
- Compare direct retrieval with HyDE retrieval
- Understand HyDE prompt design
- Combine HyDE with hybrid retrieval
- Combine HyDE with reranking
- Combine HyDE with Multi-Vector Retrieval
- Understand HyDE latency and cost implications
- Evaluate HyDE against a standard vector retriever
- Design production-oriented HyDE architectures
1. The Problem HyDE Tries to Solve¶
Traditional semantic retrieval embeds the user's query directly.
For example:
The embedding represents the query.
The vector database then searches for semantically similar chunks.
However, queries and documents often have very different linguistic structures.
Query:
"How can an application access another
service on behalf of a user?"
Document:
"OAuth 2.0 is an authorization framework
that enables delegated access to protected
resources."
The concepts are related, but the language is different.
HyDE attempts to bridge this gap by generating a hypothetical document that resembles the type of content stored in the knowledge base.
2. Traditional Retrieval¶
The standard pipeline is:
flowchart LR
A["User Query"] --> B["Embedding Model"]
B --> C["Query Vector"]
C --> D["Vector Database"]
D --> E["Retrieved Documents"]Example:
This works well for many applications.
HyDE adds another semantic transformation.
3. HyDE Retrieval¶
The HyDE pipeline becomes:
flowchart TD
A["User Query"] --> B["LLM"]
B --> C["Hypothetical Document"]
C --> D["Embedding Model"]
D --> E["Hypothetical Document Vector"]
E --> F["Vector Database"]
F --> G["Retrieved Source Documents"]The important distinction is:
4. What Is a Hypothetical Document?¶
A hypothetical document is generated by an LLM based on the user's query.
For example:
The LLM might generate:
OAuth 2.0 is an authorization framework that
allows applications to obtain limited access
to protected resources on behalf of a resource
owner without exposing the user's credentials.
This generated text is not treated as authoritative evidence.
It is used as a retrieval representation.
5. Why Generate a Document?¶
Documents in a knowledge base typically look like:
Queries often look like:
HyDE transforms:
This can reduce the representation gap between:
and:
6. Query-to-Document Transformation¶
The core concept can be visualized as:
Query Space
"How does OAuth work?"
│
↓
LLM
│
↓
Hypothetical Answer
│
↓
Document Space
│
↓
Embedding
│
↓
Vector Search
The generated document attempts to contain concepts that are likely to appear in relevant source documents.
7. HyDE vs Direct Query Embedding¶
Direct Retrieval¶
HyDE¶
The additional LLM step can improve retrieval in some query distributions, but it also introduces:
Therefore, HyDE should be evaluated rather than automatically applied.
8. HyDE Architecture¶
flowchart TD
A["User Query"] --> B["HyDE Prompt"]
B --> C["LLM"]
C --> D["Hypothetical Document"]
D --> E["Embedding Model"]
E --> F["Query Representation"]
F --> G["Vector Store"]
G --> H["Candidate Documents"]
H --> I["Reranker"]
I --> J["Context Selection"]
J --> K["Prompt Assembly"]
K --> L["Generation LLM"]
L --> M["Response Validation"]
M --> N["Final Response"]Notice that HyDE uses an LLM before retrieval, while another generation step may occur after retrieval.
9. Two LLM Roles¶
A production HyDE pipeline may have two conceptual LLM operations.
Retrieval-Time Generation¶
Answer Generation¶
Therefore:
They may use the same underlying model, but they have different responsibilities.
10. Basic HyDE Prompt¶
A simple prompt can be:
HYDE_PROMPT = """
Write a hypothetical document that would directly
answer the following question.
Question:
{query}
Generate a concise, information-rich passage.
Do not mention that the passage is hypothetical.
"""
For:
the model produces a document-like response.
That response is then embedded.
11. Python Example¶
query = "What is OAuth 2.0?"
hypothetical_document = llm.invoke(
HYDE_PROMPT.format(query=query)
)
hypothetical_vector = embedding_model.embed_query(
hypothetical_document
)
results = vector_store.similarity_search_by_vector(
hypothetical_vector,
k=5
)
The important flow is:
12. Simple HyDE Retriever¶
A framework-independent implementation could look like:
class HyDERetriever:
def __init__(
self,
llm,
embedding_model,
vector_store,
top_k=5
):
self.llm = llm
self.embedding_model = embedding_model
self.vector_store = vector_store
self.top_k = top_k
def retrieve(self, query: str):
hypothetical_document = self.llm.invoke(
self._build_prompt(query)
)
vector = self.embedding_model.embed_query(
hypothetical_document
)
return self.vector_store.similarity_search_by_vector(
vector,
k=self.top_k
)
def _build_prompt(self, query):
return f"""
Generate a hypothetical document that
could answer this question:
{query}
"""
This keeps the retrieval logic separate from the application layer.
13. LangChain-Oriented Example¶
LangChain provides HyDE-style retrieval patterns that can be composed using its retrieval abstractions.
A simplified conceptual implementation:
from langchain_core.prompts import PromptTemplate
prompt = PromptTemplate.from_template(
"""
Write a hypothetical document that answers
the following question:
{question}
"""
)
hypothetical_document = llm.invoke(
prompt.format(
question=query
)
)
results = vector_store.similarity_search(
hypothetical_document,
k=5
)
The important concept is not the specific framework API.
It is:
14. Multiple Hypothetical Documents¶
A single hypothetical document may not capture all possible interpretations of a query.
For example:
Possible interpretations:
HyDE can generate multiple hypothetical documents.
Query
↓
LLM
↓
┌───────────────┬───────────────┬───────────────┐
↓ ↓ ↓
Hypothesis 1 Hypothesis 2 Hypothesis 3
↓ ↓ ↓
Embedding Embedding Embedding
└───────────────┼───────────────┘
↓
Retrieval
This can improve coverage for ambiguous queries.
15. Multi-HyDE Retrieval¶
Example:
hypothetical_documents = llm.invoke(
"""
Generate three different hypothetical
answers to the following query.
Query:
{query}
"""
)
Each generated document can be embedded:
Then retrieve for each vector:
all_results = []
for vector in vectors:
all_results.extend(
vector_store.similarity_search_by_vector(
vector,
k=5
)
)
The final results should be deduplicated and ranked.
16. HyDE + Multi-Query Retrieval¶
HyDE and Multi-Query Retrieval solve related but different problems.
Multi-Query¶
Generates:
HyDE¶
Generates:
Architecture:
User Query
│
┌──────────┴──────────┐
↓ ↓
Multi-Query HyDE
↓ ↓
Query 1 / 2 / 3 Hypothetical Docs
↓ ↓
Retrieval Retrieval
└──────────┬──────────┘
↓
Fusion
These techniques can be combined, but the added complexity should be justified through evaluation.
17. HyDE + Hybrid Search¶
HyDE can generate the dense retrieval representation while the original query is used for sparse retrieval.
flowchart TD
A["User Query"] --> B["HyDE LLM"]
A --> C["Sparse Retriever"]
B --> D["Hypothetical Document"]
D --> E["Embedding"]
E --> F["Dense Search"]
C --> G["BM25 Search"]
F --> H["Fusion"]
G --> H
H --> I["Reranking"]
I --> J["Final Documents"]This is particularly useful when:
are both important.
The sparse path can preserve exact identifiers while HyDE improves the semantic retrieval representation.
18. HyDE + Reranking¶
A common production pipeline is:
Architecture:
flowchart LR
A["Query"] --> B["HyDE Generation"]
B --> C["Hypothetical Document"]
C --> D["Embedding"]
D --> E["Vector Search"]
E --> F["Candidate Documents"]
F --> G["Reranker"]
G --> H["Top-K"]HyDE improves candidate generation.
The reranker then performs deeper query-document relevance scoring.
19. HyDE + Contextual Compression¶
The pipeline can continue with contextual compression:
This helps when retrieved documents are larger than the context actually required.
20. HyDE + Multi-Vector Retrieval¶
HyDE can also work with a Multi-Vector Retriever.
Query
↓
HyDE Document
↓
Embedding
↓
Multi-Vector Search
↓
Representation Matches
↓
Parent Resolution
↓
Final Documents
Architecture:
flowchart TD
A["User Query"] --> B["HyDE Generator"]
B --> C["Hypothetical Document"]
C --> D["Embedding"]
D --> E["Multi-Vector Store"]
E --> F["Representation Matches"]
F --> G["Parent Resolution"]
G --> H["Parent Documents"]This combines:
21. HyDE + Hybrid + Reranking¶
A more advanced retrieval architecture can combine all three:
User Query
│
├──────────────→ Sparse Search
│
↓
HyDE
↓
Hypothetical Document
↓
Embedding
↓
Dense Search
│
└──────────────┐
↓
Fusion
↓
Deduplication
↓
Reranker
↓
Context Selection
This can provide:
22. Why HyDE Can Improve Retrieval¶
The generated document can contain terms and concepts that are closer to the knowledge base.
Example:
HyDE may generate:
OAuth 2.0 provides delegated authorization
where an application can obtain an access token
to access protected resources on behalf of a user.
The hypothetical document contains:
These concepts may align closely with enterprise documentation.
23. HyDE Does Not Need to Be Factually Correct¶
This is a subtle but important concept.
The hypothetical document is not the final answer.
Its primary purpose is:
Therefore:
rather than:
The final answer should be grounded in retrieved source documents.
24. Hallucination Risk¶
Because an LLM generates the hypothetical document, it can hallucinate.
Example:
The model might invent:
If that term does not exist in the knowledge base, the generated vector may move retrieval in the wrong direction.
Therefore:
This is one of the main risks of HyDE.
25. Grounding the HyDE Prompt¶
A retrieval-oriented prompt should avoid unnecessary invention.
Example:
HYDE_PROMPT = """
Generate a concise hypothetical passage that could
answer the user's question.
Use generally relevant technical concepts.
Do not invent company-specific facts,
identifiers, policies, or citations.
Question:
{query}
"""
This reduces the chance that the hypothetical representation becomes overly specific to unsupported information.
26. HyDE Prompt Design¶
A good HyDE prompt should define:
Example:
Generate a concise technical passage.
Requirements:
- Focus on the user's question.
- Use standard terminology.
- Include concepts likely to occur in technical documentation.
- Avoid unsupported organization-specific details.
- Do not include citations.
- Return only the passage.
Question:
{query}
27. Domain-Specific HyDE¶
Different domains can use different prompts.
Technical Documentation¶
Legal Knowledge¶
Financial Research¶
Generate a concise financial research-style
passage describing the concepts relevant
to the question.
The prompt can influence the vocabulary used in the retrieval representation.
28. HyDE for Technical Queries¶
Consider:
HyDE may generate:
A Kubernetes pod may repeatedly restart due to
CrashLoopBackOff, failing health probes, container
startup errors, resource limits, or application
exceptions.
This introduces useful retrieval terms:
The vector search can then locate relevant operational documentation.
29. HyDE for Enterprise Documentation¶
Query:
A generic HyDE response might mention:
The retrieval system can then search enterprise documentation containing related concepts.
However, it should not invent:
unless those are grounded in the query or other trusted context.
30. HyDE for Ambiguous Queries¶
Consider:
This could refer to:
A single HyDE document may focus on one interpretation.
Possible solution:
Generate Multiple Hypothetical Documents
↓
Multiple Embeddings
↓
Retrieve Multiple Candidate Sets
↓
Fusion
This provides broader semantic coverage.
31. Query Intent + HyDE¶
An advanced architecture can first classify the query.
flowchart TD
A["User Query"] --> B["Query Intent"]
B --> C["Technical"]
B --> D["Policy"]
B --> E["Historical"]
B --> F["General"]
C --> G["Technical HyDE Prompt"]
D --> H["Policy HyDE Prompt"]
E --> I["Historical HyDE Prompt"]
F --> J["General HyDE Prompt"]
G --> K["HyDE Generation"]
H --> K
I --> K
J --> K
K --> L["Embedding"]
L --> M["Retrieval"]This adds complexity but can improve domain alignment for heterogeneous enterprise knowledge bases.
32. HyDE and Query Rewriting¶
HyDE is related to query rewriting but should not be treated as identical.
Query Rewriting¶
HyDE¶
Query rewriting changes the search query.
HyDE changes the representation used for vector search.
33. HyDE and Multi-Query¶
Multi-Query¶
HyDE¶
Combined¶
This can increase recall, but also increases:
34. HyDE and Query Expansion¶
Traditional query expansion might produce:
HyDE instead produces a coherent passage:
OAuth 2.0 enables delegated authorization
through access tokens that allow applications
to access protected resources on behalf of users.
The difference is:
35. HyDE with Metadata Filtering¶
HyDE should generally not replace metadata constraints.
Example:
Metadata:
Pipeline:
This prevents semantic retrieval from searching outside the allowed knowledge scope.
36. HyDE with Access Control¶
Enterprise retrieval must enforce authorization independently of HyDE.
The hypothetical document must never be allowed to bypass:
Security filtering should be enforced against the actual source documents.
37. HyDE and Citations¶
The generated hypothetical document should not normally be cited.
Instead:
Architecture:
flowchart LR
A["User Query"] --> B["HyDE"]
B --> C["Hypothetical Document"]
C --> D["Vector Search"]
D --> E["Source Documents"]
E --> F["LLM"]
F --> G["Citation from Source"]This preserves evidence traceability.
38. Retrieval Provenance¶
A production trace should record:
Original Query
HyDE Prompt Version
Hypothetical Document
Embedding Model
Retrieved Documents
Scores
Reranker Results
Final Sources
Example:
{
"query": "What is OAuth 2.0?",
"retrieval_strategy": "hyde",
"embedding_model": "embedding-model",
"candidate_count": 20,
"reranked_count": 5
}
Whether the actual hypothetical text is retained should depend on privacy, logging, and operational requirements.
39. Latency Considerations¶
Traditional retrieval:
HyDE:
Therefore:
The additional LLM generation can become significant in interactive applications.
40. Cost Considerations¶
Traditional:
HyDE:
Multi-HyDE:
Therefore:
HyDE should be used where its retrieval improvement justifies its additional cost.
41. Caching¶
HyDE can benefit from caching.
For repeated queries:
If no cached result exists:
Architecture:
flowchart TD
A["Query"] --> B["HyDE Cache"]
B -->|Hit| C["Cached Hypothetical Document"]
B -->|Miss| D["HyDE LLM"]
D --> E["Cache"]
E --> F["Hypothetical Document"]
C --> F
F --> G["Embedding"]
G --> H["Vector Search"]Caching strategy should consider:
42. Streaming Considerations¶
HyDE generation is usually an internal retrieval operation.
The generated hypothetical document does not need to be streamed to the user.
The user-facing stream should generally begin with the final generation stage:
This keeps retrieval internals separate from the user experience.
43. Failure Handling¶
A production HyDE retriever should have fallback behavior.
flowchart TD
A["User Query"] --> B["HyDE Generation"]
B --> C{"Generation Successful?"}
C -->|Yes| D["HyDE Retrieval"]
C -->|No| E["Direct Query Retrieval"]
D --> F{"Enough Relevant Results?"}
F -->|Yes| G["Continue"]
F -->|No| H["Fallback Retrieval"]
E --> H
H --> I["Final Candidate Set"]Possible fallback:
This prevents HyDE failures from becoming total retrieval failures.
44. HyDE Fallback Strategy¶
A practical retrieval policy could be:
A more robust system can use a quality threshold:
The threshold should be calibrated using evaluation data rather than chosen arbitrarily.
45. HyDE Evaluation¶
The correct evaluation compares:
Metrics:
Architecture:
flowchart LR
A["Evaluation Dataset"] --> B["Direct Retrieval"]
A --> C["HyDE Retrieval"]
B --> D["Baseline Metrics"]
C --> E["HyDE Metrics"]
D --> F["Comparison"]
E --> F
F --> G["Production Decision"]46. Query-Level Evaluation¶
HyDE may work better for some queries than others.
Evaluate categories such as:
Short Queries
Natural-Language Questions
Technical Queries
Ambiguous Queries
Long Queries
Keyword Queries
Exact Identifier Queries
For example:
Semantic Question
→ HyDE may help
Exact Error Code
→ Sparse Retrieval may be better
Simple Query
→ Direct Retrieval may be sufficient
This can lead to selective HyDE usage.
47. Selective HyDE¶
Instead of applying HyDE to every query:
an advanced system can use:
Architecture:
flowchart TD
A["User Query"] --> B["Query Classifier"]
B --> C{"HyDE Beneficial?"}
C -->|Yes| D["HyDE Retrieval"]
C -->|No| E["Direct Retrieval"]
D --> F["Candidate Documents"]
E --> F
F --> G["Reranking"]
G --> H["Context"]This can reduce cost and latency.
48. Query Types Suitable for HyDE¶
HyDE can be especially useful for:
Natural-Language Questions
Conceptual Questions
Long-Form Questions
Research Questions
Semantic Queries
Queries with Large Vocabulary Mismatch
It may be less useful for:
Exact IDs
Ticket Numbers
Error Codes
Product Codes
Highly Structured Filters
Simple Keyword Searches
For these, lexical or metadata retrieval may already be optimal.
49. HyDE + Sparse Retrieval for Exact Terms¶
A strong architecture for heterogeneous enterprise queries is:
Query
│
┌────────┴────────┐
↓ ↓
HyDE Sparse
↓ ↓
Dense BM25
↓ ↓
└───────┬─────────┘
↓
Fusion
↓
Reranking
This allows:
50. HyDE + Time-Aware Retrieval¶
HyDE can also be combined with the time-aware retrieval strategy from the previous chapter.
Or:
This is useful for domains where:
are all important.
51. Production Architecture¶
A mature enterprise HyDE pipeline can look like:
flowchart TD
A["User Query"] --> B["Query Understanding"]
B --> C["Security / Access Filters"]
C --> D["Query Classification"]
D --> E{"Use HyDE?"}
E -->|Yes| F["HyDE LLM"]
E -->|No| G["Direct Dense Retrieval"]
F --> H["Hypothetical Document"]
H --> I["Embedding"]
I --> J["Dense Retrieval"]
G --> J
C --> K["Sparse Retrieval"]
J --> L["Fusion"]
K --> L
L --> M["Deduplication"]
M --> N["Reranking"]
N --> O["Context Selection"]
O --> P["Prompt Assembly"]
P --> Q["Generation LLM"]
Q --> R["Response Validation"]
R --> S["Citation / Source Attribution"]
S --> T["Enterprise Response"]This architecture keeps:
52. Framework-Agnostic Interface¶
An enterprise AI platform can expose:
from abc import ABC, abstractmethod
class QueryRepresentationGenerator(ABC):
@abstractmethod
def generate(self, query: str) -> str:
pass
HyDE implementation:
class HyDERepresentationGenerator(
QueryRepresentationGenerator
):
def __init__(self, llm):
self.llm = llm
def generate(self, query: str) -> str:
prompt = f"""
Generate a concise hypothetical document
that could answer this question:
{query}
"""
return self.llm.invoke(prompt)
Then:
class HyDERetriever:
def __init__(
self,
representation_generator,
embedding_provider,
vector_store
):
self.generator = representation_generator
self.embedding = embedding_provider
self.vector_store = vector_store
def retrieve(self, query, top_k=5):
representation = (
self.generator.generate(query)
)
vector = self.embedding.embed(
representation
)
return self.vector_store.search(
vector,
top_k=top_k
)
This keeps the architecture provider-independent.
53. Configuration Example¶
retrieval:
strategy: hyde
hyde:
enabled: true
generation:
model: retrieval-llm
max_tokens: 300
temperature: 0.0
embedding:
provider: embedding-provider
retrieval:
top_k: 20
fallback:
enabled: true
strategy: direct-vector
reranking:
enabled: true
top_k: 5
Configuration should be externalized so the strategy can be tuned without modifying business logic.
54. Testing Strategy¶
HyDE should be tested at multiple levels.
Unit Tests¶
Test:
Integration Tests¶
Test:
Retrieval Evaluation¶
Test:
End-to-End Evaluation¶
Test:
55. Example Unit Test¶
def test_hyde_retriever_uses_hypothetical_document():
query = "What is OAuth 2.0?"
hypothetical = (
"OAuth 2.0 is an authorization framework..."
)
embedding = embedding_model.embed_query(
hypothetical
)
results = vector_store.similarity_search_by_vector(
embedding,
k=5
)
assert results
Production evaluation should additionally verify whether the retrieved documents are actually more relevant than those returned by direct retrieval.
56. Common Failure Modes¶
56.1 Hallucinated Retrieval Terms¶
The LLM may introduce concepts that do not exist in the source corpus.
56.2 Retrieval Drift¶
The hypothetical document may answer a slightly different question.
56.3 Excessive Generation¶
A very long hypothetical document can introduce unnecessary concepts.
Prefer:
representations.
56.4 High Latency¶
HyDE adds an LLM call before retrieval.
56.5 Increased Cost¶
Every HyDE query can require:
56.6 Exact-Term Queries¶
HyDE may be less effective for:
because sparse retrieval can match these identifiers directly.
56.7 Overuse¶
Applying HyDE to every query can unnecessarily increase system complexity.
57. Observability¶
A HyDE retrieval trace can expose:
Query
HyDE Enabled
HyDE Generation Latency
Embedding Latency
Retrieval Latency
Candidate Count
Reranker Latency
Final Candidate Count
Fallback Triggered
Example:
{
"query": "How does OAuth authorization work?",
"hyde": {
"enabled": true,
"generation_latency_ms": 220
},
"embedding_latency_ms": 18,
"retrieval_latency_ms": 35,
"candidate_count": 20,
"fallback": false
}
This makes the additional HyDE cost visible.
58. Cost Observability¶
A production system should track:
A useful metric is:
Then compare it with:
59. Production Decision¶
The decision should be based on:
For example:
The organization must decide whether the retrieval improvement justifies those costs.
There is no universal answer.
60. When to Use HyDE¶
HyDE is worth evaluating when:
- Queries are natural-language questions
- Query and document vocabulary differ significantly
- Semantic retrieval recall is weak
- Users ask conceptual questions
- The corpus contains rich explanatory documents
- Direct query embeddings are not sufficiently effective
- Retrieval quality is more important than minimum latency
Typical use cases:
Research Assistants
Technical Knowledge Systems
Enterprise Knowledge Assistants
Documentation Search
Academic Search
Long-Form Question Answering
61. When HyDE May Not Be Necessary¶
HyDE may not be appropriate when:
or:
or:
or:
or:
or:
In these cases:
may be better.
62. Recommended Enterprise Pattern¶
A practical enterprise architecture is:
Query
↓
Security / Metadata Filters
↓
Query Classification
↓
┌─────────────────────────┐
│ │
↓ ↓
HyDE Dense Sparse Search
│ │
↓ ↓
Dense Results Sparse Results
└────────────┬────────────┘
↓
Fusion
↓
Deduplication
↓
Reranking
↓
Context Optimization
↓
Prompt Assembly
↓
LLM
↓
Response Validation
↓
Citation
The key principle is:
HyDE should improve retrieval representation, not replace source-grounded generation.
63. Production Checklist¶
Before deploying HyDE:
☐ Direct vector retrieval baseline is available
☐ HyDE improvement has been measured
☐ HyDE prompt is versioned
☐ Hypothetical documents are concise
☐ Hallucination risk is considered
☐ Exact-term queries have a sparse fallback
☐ Security filters are applied independently
☐ Metadata filters remain authoritative
☐ Source documents remain the generation evidence
☐ HyDE latency is measured
☐ HyDE token cost is measured
☐ Embedding cost is measured
☐ Retrieval quality is evaluated
☐ Query categories are evaluated separately
☐ Fallback behavior is implemented
☐ Caching is considered
☐ Retrieval provenance is preserved
☐ Observability is implemented
☐ Citation provenance is preserved
☐ Regression tests are implemented
64. Key Takeaways¶
- HyDE stands for Hypothetical Document Embeddings.
- HyDE generates a hypothetical document from the user's query.
- The hypothetical document is embedded and used for vector retrieval.
- HyDE attempts to reduce the representation gap between queries and documents.
- The hypothetical document is a retrieval aid, not authoritative evidence.
- Final answers should be grounded in retrieved source documents.
- HyDE can improve retrieval for semantic and natural-language queries.
- HyDE may be less useful for exact identifiers and keyword-heavy queries.
- HyDE introduces additional LLM latency and cost.
- Multiple hypothetical documents can improve coverage for ambiguous queries.
- HyDE can be combined with hybrid retrieval.
- HyDE can be combined with Multi-Vector Retrieval.
- HyDE can be combined with reranking and contextual compression.
- Query classification can enable selective HyDE usage.
- Sparse retrieval provides a useful complementary path for exact terminology.
- Caching can reduce repeated HyDE generation cost.
- Fallback to direct retrieval improves system resilience.
- HyDE should be evaluated against a strong direct-retrieval baseline.
- The objective is not to generate a better answer before retrieval.
- The objective is to generate a better retrieval representation.
The central pattern is:
User Query
↓
Hypothetical Document
↓
Embedding
↓
Semantic Retrieval
↓
Source Documents
↓
Reranking
↓
Context Selection
↓
Grounded Generation
Or simply:
🧭 Chapter Navigation¶
Part V — Advanced Retrieval-Augmented Generation¶
Previous:
05. Hybrid Search Retriever
Next:
07. Router 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.