HyDE: Hypothetical Document Embeddings

• HyDE is a retrieval method that uses LLM-generated hypothetical documents to convert under-specified queries into document-like embeddings.
• It constructs query representations by averaging embeddings of multiple generated texts, enhancing dense retrieval performance in zero-shot settings.
• Domain adaptations like Multi-HyDE and SL-HyDE integrate hybrid retrieval and self-learning to improve metrics in finance, medicine, and tool retrieval.

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 (Gao et al., 2022). Although some later application papers use the phrase “hypothetical-documentation-embedding” in titles or system descriptions, the canonical expansion is Hypothetical Document Embeddings (Lei et al., 22 Jul 2025).

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 (Gao et al., 2022). 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 (Gao et al., 2022). 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 LLM 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 (Gao et al., 2022).

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 (Srinivasan et al., 19 Sep 2025).

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” (Gao et al., 2022). 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 (Srinivasan et al., 19 Sep 2025). 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 (Gao et al., 2022).

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 (Gao et al., 2022). 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 (Srinivasan et al., 19 Sep 2025).

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 (Srinivasan et al., 19 Sep 2025). 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” (Srinivasan et al., 19 Sep 2025).

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 (Srinivasan et al., 19 Sep 2025). 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 (Srinivasan et al., 19 Sep 2025).

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 $$g(q, \mathrm{INST}) = \mathrm{InstructLM}(q, \mathrm{INST}),$$0 chunks (Srinivasan et al., 19 Sep 2025). 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 (Jedidi et al., 24 Nov 2025). The paper introduces sparse-space versions of HyDE average vectors, Rocchio, and RM3, with feedback-term filtering, a cap of $$g(q, \mathrm{INST}) = \mathrm{InstructLM}(q, \mathrm{INST}),$$1 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 (Jedidi et al., 24 Nov 2025).

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 $$g(q, \mathrm{INST}) = \mathrm{InstructLM}(q, \mathrm{INST}),$$2 produces a hypothetical document $$g(q, \mathrm{INST}) = \mathrm{InstructLM}(q, \mathrm{INST}),$$3, the retriever $$g(q, \mathrm{INST}) = \mathrm{InstructLM}(q, \mathrm{INST}),$$4 embeds both query-side and corpus texts, and the system then uses unlabeled medical corpora to adapt both modules without relevance labels (Li et al., 2024). The generator is fine-tuned on pseudo-documents selected by retrieval effectiveness, and the retriever is trained on $$g(q, \mathrm{INST}) = \mathrm{InstructLM}(q, \mathrm{INST}),$$5 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 (Senthil et al., 28 May 2026). 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 (Senthil et al., 28 May 2026). 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 (Lei et al., 22 Jul 2025). 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 (Yu et al., 17 Feb 2025). 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 (Gao et al., 2022). 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 (Gao et al., 2022). 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 (Gao et al., 2022). In multilingual retrieval, MRR@100 improves from 22.3 to 30.6 for Korean and from 19.5 to 30.7 for Japanese (Gao et al., 2022).

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 (Srinivasan et al., 19 Sep 2025). 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 (Srinivasan et al., 19 Sep 2025). 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 (Srinivasan et al., 19 Sep 2025).

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 (Li et al., 2024). The paper emphasizes that SL-HyDE consistently outperforms vanilla HyDE across all ten datasets, with especially visible improvements on MedExam and DuBaike (Li et al., 2024).

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 (Senthil et al., 28 May 2026). 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 (Senthil et al., 28 May 2026).

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 (Jedidi et al., 24 Nov 2025). 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 (Jedidi et al., 24 Nov 2025).

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 (Sorstkins, 12 Jun 2025). 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 (Gao et al., 2022). 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 (Lei et al., 22 Jul 2025).

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 (Srinivasan et al., 19 Sep 2025). 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 (Jedidi et al., 24 Nov 2025).

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 (Gao et al., 2022). 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 (Srinivasan et al., 19 Sep 2025). 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 (Gao et al., 2022). 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 (Srinivasan et al., 19 Sep 2025, Sorstkins, 12 Jun 2025). 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 (Srinivasan et al., 19 Sep 2025).

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 (Sorstkins, 12 Jun 2025, Srinivasan et al., 19 Sep 2025). 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.