---
title: 'HyDE: Hypothetical Document Embeddings'
url: https://www.emergentmind.com/topics/hypothetical-documentation-embedding-hyde
type: topic
---

# HyDE: Hypothetical Document Embeddings

HyDE, originally introduced as **Hypothetical Document Embeddings**, is a retrieval method that replaces direct query embedding with the embedding of one or more LLM-generated hypothetical relevant documents, then retrieves real corpus items from the resulting neighborhood in document embedding space. The original formulation targets fully zero-shot dense retrieval without relevance labels and is explicitly designed to avoid learning a query–document relevance function under label scarcity by “pivot[ing] through” hypothetical documents instead [2212.10496]. Although some later application papers use the phrase “hypothetical-documentation-embedding” in titles or system descriptions, the canonical expansion is **Hypothetical Document Embeddings** [2507.16754].

## 1. Origins and problem formulation

HyDE was proposed for the setting of **fully zero-shot dense retrieval** in which there is no access to target query sets, target corpora, or relevance judgments [2212.10496]. The original paper frames the central difficulty through the standard dense-retrieval formulation
\[
\mathrm{sim}(q,d) = (\mathrm{enc}_q(q), \mathrm{enc}_d(d)) = (V_q, V_d),
\]
and argues that, without relevance judgments or scores, learning two embedding functions whose inner product reflects relevance becomes intractable [2212.10496]. In that sense, HyDE is not merely a query-expansion heuristic; it is a reformulation of what is being embedded on the query side.

The key move is to stop trying to encode the raw query directly as a relevance-bearing vector. Instead, an instruction-following language model generates a hypothetical document that resembles a relevant passage or answer, and an unsupervised dense encoder embeds that generated text. Retrieval then proceeds as nearest-neighbor search among real corpus documents. The original paper characterizes this as delegating relevance expression to generation while using dense retrieval only for document–document neighborhood matching [2212.10496].

This reframing is foundational for later work. Subsequent domain papers repeatedly reinterpret HyDE as a **pre-retrieval query transformation** rather than a post hoc repair mechanism: retrieval quality is improved before generation, not repaired after bad evidence has already been selected [2509.16369].

## 2. Canonical HyDE pipeline and retrieval geometry

In the original formulation, the generator is defined as
\[
g(q, \mathrm{INST}) = \mathrm{InstructLM}(q, \mathrm{INST}),
\]
where the instruction specifies the genre of the hypothetical text, such as a “passage to answer the question,” a “scientific paper passage,” a “counter argument,” a “financial article passage,” or a “news passage” [2212.10496]. The generated output is not treated as a final answer; it is an intermediate retrieval artifact.

The query representation is then constructed in document space. The original paper gives the expectation-based form and its sample approximation; later expositions reproduce the same core averaging idea as
\[
\hat{v} = \frac{1}{N} \sum_{\hat{d_i}\sim g(q)} f(\hat{d_i}),
\]
where \(f\) is the embedding model, \(\hat d_i\) are hypothetical documents, and \(\hat v\) is the averaged hypothetical document embedding used for retrieval [2509.16369]. In the original implementation, the main generator is **InstructGPT text-davinci-003** and the main encoder is **Contriever** for English or **mContriever** for multilingual retrieval; retrieval is then standard dense retrieval by inner product, compatible with standard MIPS or nearest-neighbor infrastructure [2212.10496].

HyDE’s central geometric intuition is the **dense bottleneck**. The hypothetical document may contain false details, but the encoder acts as a lossy compressor: it preserves broad relevance patterns while filtering some hallucinated specifics, and retrieval grounds the process back to actual corpus documents rather than to the fabricated text itself [2212.10496]. This is why the generated document is not required to be factually correct. What matters is that it occupies a useful region of the corpus embedding space.

Operationally, HyDE shifts retrieval from query-to-document matching toward answer-like-text-to-document matching. That is especially useful when the original question is short, underspecified, or phrased differently from the way the answer appears in the corpus [2509.16369].

## 3. Diversification, hybridization, and retrieval orchestration

A major line of development extends HyDE by diversifying not only hypothetical documents but also the **retrieval intents** that produce them. In finance, Multi-HyDE first uses a query generator \(g_q\) to produce multiple **nonequivalent but contextually related** queries \([q_1,\dots,q_N]\), then generates one hypothetical document per transformed query, embeds each separately, retrieves per branch, concatenates the candidate sets, and reranks globally [2509.16369]. The paper’s distinction is explicit: the novelty is not “more HyDE samples,” but “multiple non-equivalent retrieval intents, each converted into a HyDE-style pseudo-document” [2509.16369].

The motivation is domain-specific. Financial filings are long, repetitive, semantically similar across years, and highly sensitive to temporal and numeric details. The paper argues that standard dense retrieval, and even standard single-query HyDE, can miss or confuse the right evidence because a single semantic vector can collapse distinct aspects of the information need into one representation [2509.16369]. Multi-HyDE is therefore paired with a **hybrid retrieval** stack: dense retrieval via hypothetical document embeddings, **BM25** for exact lexical anchors and tables, neural reranking, and an agentic loop that can decompose a problem into sub-queries and invoke external tools such as EDGAR, Alpha Vantage, Yahoo Finance, Financial Modeling Prep, WolframAlpha, and a Python calculator [2509.16369].

The finance implementation is unusually concrete. It uses **HNSW indexing** and a **Pathway vector store** for dense retrieval, retrieves top \(K_1=10\) dense chunks, retrieves top \(K_2=15\) BM25 chunks, and reranks pooled evidence with either `ms-marco-MiniLM-L-6-v2` or `bge-reranker-v2-m3`, keeping final top \(K=8\) chunks [2509.16369]. This makes explicit that later HyDE systems are often not standalone dense retrievers but components inside larger hybrid RAG architectures.

A parallel reinterpretation appears in sparse retrieval. “Revisiting Feedback Models for HyDE” treats HyDE-generated documents as pseudo-relevance feedback for **BM25**, arguing that recent LLM-based PRF systems rely too heavily on simple concatenation of query and generated text [2511.19349]. The paper introduces sparse-space versions of HyDE average vectors, **Rocchio**, and **RM3**, with feedback-term filtering, a cap of \(k=128\) terms, and eight hypothetical documents. Its central claim is that classical feedback machinery remains useful: explicit term selection and weighting improve over naive concatenation, and **Rocchio** is the strongest overall feedback model in this setting [2511.19349].

## 4. Domain-specific extensions and reinterpretations

| Variant | Setting | Distinguishing mechanism |
|---|---|---|
| Multi-HyDE | Financial RAG | Multiple nonequivalent transformed queries, per-query hypothetical documents, fused retrieval, reranking, agentic tool use |
| SL-HyDE | Medical information retrieval | Self-learning loop that adapts both generator and retriever using unlabeled medical corpora |
| CoHyDE | Tool retrieval over API catalogs | Iterative co-training of LLM rewriter and dense encoder via InfoNCE and DPO |
| Adaptive HyDE retrieval | Developer support over Stack Overflow | Hypothetical-answer retrieval plus dynamically lowered similarity threshold for unseen queries |
| Hypothetical resume embedding | Resume–job matching | Job post augmented with an LLM-generated ideal resume |

In medicine, **SL-HyDE** turns HyDE from an inference-time technique into a self-learning framework. A generator \(\mathcal{M}_g\) produces a hypothetical document \(d'=\mathcal{M}_g(q, Prompt_1)\), the retriever \(\mathcal{M}_r\) embeds both query-side and corpus texts, and the system then uses unlabeled medical corpora to adapt both modules without relevance labels [2410.20050]. The generator is fine-tuned on pseudo-documents selected by retrieval effectiveness, and the retriever is trained on \((q,d',d)\) triples with hard negatives. The paper emphasizes that this is domain adaptation of HyDE rather than mere prompt engineering.

In tool retrieval, **CoHyDE** addresses a different failure mode: a frozen HyDE generator may produce hypothetical descriptions that are semantically plausible but **catalog-unaware**, while a query-trained dense encoder is brittle under lexical drift [2605.29271]. CoHyDE therefore warm-starts the encoder with contrastive training, warm-starts the rewriter on catalog renderings, retrains the encoder on generated hypothetical tool descriptions with InfoNCE, and aligns the rewriter with **DPO** using the encoder’s own NDCG@5 scores as preference signals [2605.29271]. The system is explicitly designed as a co-evolving generator–retriever pair rather than a simple composition of independently optimized modules.

In developer support, HyDE is used as a retrieval-stage design choice over a Stack Overflow corpus of over 3 million Java- and Python-related posts with accepted answers. The paper’s best configuration is a **HyDE-based pipeline with full-answer context**, and its “never come up empty” mechanism lowers the similarity threshold dynamically until some context is retrieved for novel questions [2507.16754]. Here HyDE is not formalized mathematically in the excerpted text, but the operational role is clear: generate a hypothetical answer, retrieve with it, and use threshold adaptation to preserve coverage.

In resume–job matching, ConFit v2 applies the HyDE principle asymmetrically. A job post is treated as the under-specified side of the match, and an LLM generates a **hypothetical ideal resume** for that job; the system then concatenates the generated resume with the original job and embeds the result as the job-side representation [2502.12361]. This is not standard zero-shot HyDE, but it preserves the core logic of projecting a sparse query-like object into the richer semantic format of the documents being retrieved.

## 5. Empirical record

The original HyDE paper reports strong zero-shot dense retrieval gains over unsupervised baselines across web search, low-resource BEIR tasks, and multilingual retrieval [2212.10496]. On **DL19**, nDCG@10 rises from **44.5** with Contriever and **50.6** with BM25 to **61.3** with HyDE, nearly matching **ContrieverFT** at **62.1**; on **DL20**, HyDE reaches **57.9** versus **42.1** for Contriever and **48.0** for BM25 [2212.10496]. On BEIR-style low-resource tasks, the gains can be large: **TREC-COVID** rises from **27.3** with Contriever to **59.3** with HyDE, **ArguAna** from **37.9** to **46.6**, and **DBPedia** from **29.2** to **36.8** [2212.10496]. In multilingual retrieval, MRR@100 improves from **22.3** to **30.6** for Korean and from **19.5** to **30.7** for Japanese [2212.10496].

Finance provides a more mixed but instructive picture. On a ConvFinQA + FinanceBench subset, Multi-HyDE improves **recall** from **0.1154** to **0.3547**, **factual correctness** from **0.2890** to **0.3849**, and **faithfulness** from **0.8290** to **0.8404** relative to HyDE, even though **cosine similarity** drops from **0.7660** to **0.6269** [2509.16369]. On a `financial-qa-10K` subset, Multi-HyDE improves **recall** from **0.6885** to **0.8170**, **faithfulness** from **0.8463** to **0.9352**, and **ROUGE** from **0.3726** to **0.4871**, though HyDE is slightly higher on **factual correctness** in that table, **0.5585** versus **0.5205** [2509.16369]. The same paper reports that the combined system of agentic AI and Multi-HyDE improves **accuracy by 11.2%** and reduces **hallucinations by 15%**, with human evaluation moving from **34.4%** to **45.6%** accuracy and from **37.91%** to **52.91%** reliability [2509.16369].

In medical retrieval, the progression from base retriever to HyDE to self-learning HyDE is explicit. With the default Qwen2 + BGE setup, average **NDCG@10** on CMIRB rises from **55.40** for **BGE** to **56.62** for **HyDE** and to **59.38** for **SL-HyDE** [2410.20050]. The paper emphasizes that **SL-HyDE consistently outperforms vanilla HyDE across all ten datasets**, with especially visible improvements on **MedExam** and **DuBaike** [2410.20050].

In tool retrieval, CoHyDE reports that three rounds of co-training improve over the strongest single-component baseline by **+2.5 pp NDCG@5 on standard queries** and **+6.3 pp on held-out vague queries**, with gains as large as **+8 pp on the hardest vague tier** [2605.29271]. The paper’s ablations attribute these gains to co-training itself: a trained rewriter with a vanilla encoder or a co-trained encoder with a vanilla rewriter fails to match the full system on both well-formed and vague queries [2605.29271].

In sparse BM25 retrieval, the feedback-model reinterpretation of HyDE finds that term selection alone already matters: **HyDE Avg Vector** improves over **HyDE Naive Concat** by **+3.0** Recall@20 points for **Qwen2.5-7B**, **+2.3** for **Qwen3-14B**, and **+3.1** for **gpt-oss-20b** [2511.19349]. Across all three generators, **HyDE w/ Rocchio** outperforms the strongest concatenation baseline, **MuGI Concat**, by up to **1.4 Recall@20 points (4.2%) on average** and by **2.2 points (6%) on low-resource tasks** [2511.19349].

The empirical picture is not uniformly favorable. In a privacy-first personal assistant built around 1B and 4B Gemma models, HyDE is slower and less reliable than conventional RAG. For physics questions, **HyDE 1B** averages **13.24 s** and **HyDE 4B** **13.84 s**, versus **7.70 s** and **7.86 s** for RAG; for personal-data queries, RAG records **0/10 hallucinations** while both HyDE variants record **10/10** hallucinations [2506.21568]. This contrast is important because it shows that HyDE’s semantic benefits do not automatically transfer to factual personal-memory retrieval.

## 6. Misconceptions, limitations, and deployment considerations

A recurrent misconception is terminological. The original method is **Hypothetical Document Embeddings**, not “Hypothetical Documentation Embedding,” and the generated text is not the system’s answer nor a trusted retrieved document; it is a hypothetical intermediate used to retrieve real corpus evidence [2212.10496]. Later application papers sometimes retain the acronym while shifting the surface wording, but the core mechanism remains hypothetical-document generation followed by retrieval over actual documents [2507.16754].

A second misconception is that HyDE is intrinsically a dense-retrieval-only method. The literature shows otherwise. In finance, HyDE-style retrieval is explicitly hybridized with **BM25**, table-aware parsing, reranking, and agentic tool use because dense semantic retrieval alone struggles with exact years, numbers, and repetitive near-duplicate passages [2509.16369]. In sparse retrieval, the relevant question is not whether to use hypothetical documents, but how to convert them into expansion terms: naive concatenation is often suboptimal, and Rocchio-style weighting can be better [2511.19349].

The main technical limitations are consistent across papers. HyDE depends on the quality and domain alignment of the generator; hallucinated generations are expected; prompt design matters; and the original paper explicitly leaves ambiguous queries and diversity to future work [2212.10496]. Several domain papers also omit details that would matter in production, such as exact prompts, diversity constraints, sampling strategies, or hypothesis filtering, leaving those design decisions to practitioners [2509.16369]. This suggests that HyDE is more a family of retrieval transformations than a single fully specified algorithmic template.

Latency and cost are nontrivial. Even the original paper implies a shift from training cost to **query-time generation cost and latency** [2212.10496]. Later work makes the trade-off concrete: Multi-HyDE introduces an additional query-generation stage before hypothetical-document generation, and the personal-assistant study reports **25–40\%** response-time increases for HyDE relative to RAG [2509.16369; 2506.21568]. The finance paper also presents a nuanced token-efficiency picture: although it claims no increase in token costs over HyDE in the abstract and conclusion, its appendix reports higher input-token usage for Multi-HyDE, **193.6** versus **133.5**, with similar output-token counts and latency [2509.16369].

Finally, the reliability profile is domain-dependent. HyDE is strongest when the core problem is representational mismatch between a terse, underspecified query and a verbose or differently phrased corpus. It is less reliable when exact factual anchoring dominates, when generated hypotheticals drift away from the true information need, or when the answer requires precise calculation or verbatim user-specific memory retrieval [2506.21568; 2509.16369]. In that sense, the broader lesson of the HyDE literature is not that hypothetical documents replace retrieval, but that they provide a controllable bridge into the document manifold. Later variants make that bridge more diverse, more hybrid, more feedback-aware, or more tightly co-trained with the encoder, but the underlying objective remains the same: improve retrieval by representing the query as something closer to the documents one hopes to find.

Source: https://www.emergentmind.com/topics/hypothetical-documentation-embedding-hyde