HyDE: Precise Zero-Shot Dense Retrieval without Relevance Labels

ArXiv: 2212.10496

🎯 Pitch

HyDE outperforms fully supervised dense retrievers by generating fake documents from queries—no relevance labels needed. It applies a GPT to hallucinate answers and an encoder to ground those embeddings against real text, filtering fabrication. This language-model-as-generator tactic sees strong gains on web search, QA, and low-resource languages.

1. Executive Summary

This paper introduces Hypothetical Document Embeddings (HyDE), a zero-shot dense retrieval method that requires no relevance labels by decomposing retrieval into two off-the-shelf components: an instruction-following language model (e.g., InstructGPT) that generates a hypothetical document from the query — capturing relevance patterns through language generation rather than explicit scoring — and an unsupervised contrastive encoder (e.g., Contriever) that encodes this document into a dense embedding vector, whose bottlenecked representation then retrieves similar real documents from the corpus via inner-product search. Across web search (TREC DL19/20), low-resource BEIR tasks, and multilingual Mr. TyDi benchmarks, HyDE significantly outperforms the unsupervised Contriever baseline and achieves performance comparable to models fine-tuned on massive relevance-labeled data such as MS-MARCO — for instance, on DL19 HyDE reaches an NDCG@10 of 61.3 versus Contriever's 44.5 and ContrieverFT's 62.1. The paper establishes that relevance can be effectively captured through text generation rather than learned query–document similarity scoring, removing the need for relevance supervision, but finds diminishing returns on low-resource languages where the generative LLM is under-trained and the contrastive encoder saturates.

2. Context and Motivation

The Core Problem: Zero-Shot Dense Retrieval Without Relevance Labels

The fundamental problem this paper addresses is deceptively simple: how do you build an effective dense retrieval system when you have absolutely no relevance judgments? By "relevance judgment," the authors mean labeled pairs of queries and documents where a human (or some process) has confirmed that the document answers the query. These labels are the standard fuel for training retrieval models — they teach the system what "relevant" looks like.

The paper operates in the strict zero-shot setting defined in Section 3.1. Given $L$ query sets $Q_1, Q_2, ..., Q_L$ and their corresponding document corpora $D_1, D_2, ..., D_L$, the system must define query and document embedding functions without access to any query set, document set, or relevance judgment at training time. The system must work "out-of-box" on entirely new tasks and domains it has never seen.

This is distinct from the "transfer learning" setup common in the retrieval literature. In transfer learning, models are trained on a large, richly supervised dataset (typically MS-MARCO, which contains over 500,000 labeled query-document pairs) and then evaluated on new tasks. This is often called "zero-shot" in the BEIR benchmark, but the paper argues this terminology is misleading — the model still received massive relevance supervision during training. True zero-shot retrieval, as defined here, permits no relevance labels whatsoever.

Why This Problem Matters

The paper identifies several practical stakes in Section 1 and Section 2:

MS-MARCO has real-world access restrictions. The authors note explicitly that MS-MARCO "restricts commercial use and cannot be adopted in a variety of real-world search scenarios." This is not a minor footnote — it means that a major category of retrieval deployments (commercial search engines, enterprise document retrieval, proprietary Q&A systems) cannot legally use the most common training dataset. A method that works without any such dataset eliminates this legal dependency entirely.

Large labeled datasets cannot always be assumed to exist. Even ignoring legal restrictions, Izacard et al. (2021) made the case — which the authors endorse — that the existence of massive judged collections like MS-MARCO is an accident of specific research community investments, not a universal fact about retrieval problems. For a new domain (legal documents, medical records in a specific specialty, internal corporate knowledge bases), there is often no existing labeled dataset, and creating one from scratch requires human annotators with domain expertise — an expensive and slow process. A zero-shot method that works without any labels makes retrieval immediately deployable in these settings.

The cold-start problem for new search systems. The authors frame this explicitly in the conclusion: at the beginning of a search system's life, when no search logs or click data exist, HyDE "offers performance comparable to a fine-tuned model, which no other relevance-free model can offer." As the system accumulates query logs and implicit feedback, a supervised model can be gradually trained and deployed. HyDE serves as the bridge from zero to a mature system — it provides competent retrieval from day one.

Cross-task and cross-language generalization. The paper tests HyDE on a deliberately diverse collection: web search (TREC DL19/20), scientific claim verification (SciFact), counter-argument retrieval (Arguana), biomedical QA (TREC-COVID), financial QA (FiQA), entity retrieval (DBPedia), news retrieval (TREC-NEWS), and multilingual retrieval in Swahili, Korean, Japanese, and Bengali (Mr. TyDi). The fact that a single system — with no task-specific training — can be competitive across all of these domains is practically significant. A practitioner deploying HyDE doesn't need to re-train or re-fine-tune for each new task; they only need to write an appropriate instruction (e.g., "write a scientific paper passage to support/refute the claim" for SciFact).

Where Prior Approaches Fall Short

The paper situates itself against several categories of prior work, each with limitations that HyDE aims to address:

Supervised dense retrieval is the dominant paradigm, but it requires labels. The standard dense retrieval approach (Karpukhin et al., 2020) learns two encoders — one for queries, one for documents — by minimizing a contrastive loss over labeled query-document pairs. The loss encourages relevant pairs to have high inner-product similarity and non-relevant pairs to have low similarity. Subsequent improvements have focused on better negative mining (Xiong et al., 2021; Qu et al., 2021), distillation from stronger models (Lin et al., 2021b; Hofstätter et al., 2021), and task-specific pre-training (Izacard et al., 2021; Gao and Callan, 2021, 2022). All of these techniques, however, fundamentally require relevance labels somewhere in the pipeline. The zero-shot setting cuts this cord entirely, which none of these methods can handle.

Unsupervised contrastive encoders exist but underperform on retrieval. The Contriever model (Izacard et al., 2021) is trained using a contrastive objective on document pairs derived from the corpus itself — no relevance labels needed. It learns to encode documents such that documents with similar content have similar embeddings. At retrieval time, the query is simply treated as if it were a document: the same encoder is used for both queries and documents, and similarity is computed via inner product. This works because the model has learned that documents about similar topics cluster together. However, as the results in Table 1 show, Contriever alone underperforms BM25 (a classical lexical retrieval method) on web search: 44.5 vs. 50.6 NDCG@10 on DL19, and 42.1 vs. 48.0 on DL20. The authors argue this is because Contriever only models document-document similarity, not query-document relevance. A query like "how long does it take to remove wisdom tooth" is not a document — it's a question. The gap between the linguistic form of a question and the linguistic form of a relevant document is not captured by document-document contrastive training alone.

The formulation of dense retrieval as similarity between distinct query and document spaces is inherently label-hungry. This is the paper's most fundamental critique. The standard dense retrieval objective (Equation 1) defines:

$\text{sim}(q, d) = \langle \text{enc}_q(q), \text{enc}_d(d) \rangle$

This requires learning two embedding functions — one for queries, one for documents — that map into the same embedding space where the inner product captures relevance. The authors argue in Section 3.1 that "without relevance judgments/scores to fit, learning becomes intractable." Why? Because there is no signal that tells the system which query embeddings should be close to which document embeddings. The query encoder $\text{enc}_q$ and document encoder $\text{enc}_d$ could map queries and documents to completely unrelated regions of the space, and no unsupervised loss would penalize this. The entire supervised training paradigm exists precisely to provide that signal: "this query should be close to these documents." Without it, the two encoders have no reason to align.

Transfer learning (the "zero-shot" setup in BEIR) is not truly zero-shot. The paper draws a sharp line here. The BEIR benchmark and its follow-up work (Thakur et al., 2021; Wang et al., 2022; Yu et al., 2022) define "zero-shot" as training on MS-MARCO and evaluating on new datasets without fine-tuning. But as the authors note, "the existence of such a large dataset cannot always be assumed." This is not a trivial semantic distinction — it affects what kinds of retrieval problems are solvable with current methods. If your only path to a competent dense retriever requires a dataset with 500,000+ labeled examples, you are restricted to the domains and languages where such datasets happen to exist. The paper's ambition is to show that such datasets are not necessary at all.

Generative retrieval methods require specialized training and indices. A newer line of work (Metzler et al., 2021; Tay et al., 2022; Bevilacqua et al., 2022) uses generative models as search indices — the model is trained to directly generate document identifiers (doc-IDs or substrings) given a query. The paper acknowledges these methods but notes two limitations that don't apply to HyDE: they require "special training procedures over relevance data" (another form of label dependence) and they "may also need to use novel forms of search indices." HyDE, by contrast, uses standard minimum inner product search (MIPS) over pre-computed document embeddings — no index modification, no training.

Query generation for retrieval exists but targets a different goal. Sachan et al. (2022) studied zero-shot question generation for passage retrieval, but their approach is fundamentally different: they generate questions from documents to create synthetic training data, then train a standard dense retriever on those synthetic pairs. This still requires training a retriever and is limited by the quality of the question generation model. HyDE goes the other direction — document generation from queries — and uses the resulting embedding directly for retrieval, with no intermediate training step.

How HyDE Positions Itself

The paper's central conceptual move is to refuse to model relevance at all — at least not explicitly in the way that standard dense retrievers do. Instead, it decomposes retrieval into two tasks that are each individually solvable without relevance labels:

1. A generative task — given a query, generate text that looks like a relevant document. This is inherently a natural language generation (NLG) capability, which instruction-following LLMs like InstructGPT have demonstrated across diverse instructions without task-specific training. The key insight is that "write a passage to answer the question" is an instruction that these models understand and can execute in a zero-shot manner, because they've been trained to follow instructions generally.

2. A document-document similarity task — given a (hypothetical) document embedding, find real documents with similar embeddings. This is what unsupervised contrastive encoders like Contriever already do well: they were trained to encode documents so that similar documents cluster together, and the inner product in their embedding space captures document-document similarity.

By chaining these two capabilities, HyDE never needs to learn a direct mapping between queries and documents. It never computes a "relevance score." Instead, it lets the LLM transform the query into the form of a relevant document (capturing relevance through generation rather than scoring), and then lets the contrastive encoder find documents that are textually similar to that generated document. The encoder's dense bottleneck — its dimensionality reduction from the full text — serves as a lossy compressor that filters out the hallucinated or irrelevant details in the generated document, retaining only the semantic gist that matches real documents in the corpus.

This is a genuinely different paradigm. The paper explicitly invites the reader to reflect on this in the conclusion: "the concept of relevance in HyDE is captured by an NLG model and the language generation process." The question it raises — "is numerical relevance just a statistical artifact of language understanding?" — is not rhetorical. It suggests that relevance, as operationalized by retrieval systems, might be more naturally expressed through language generation than through learned similarity functions, and that this insight will only become more important as NLG models improve.

3. Technical Approach

3.1 Reader Orientation

HyDE is a retrieval system built from two frozen, off-the-shelf models — an instruction-following language model and an unsupervised contrastive encoder — that are chained together without any training or fine-tuning. It solves the problem of zero-shot dense retrieval (finding relevant documents given a query with no labeled training data) by transforming the query into a hypothetical document via text generation, then using that generated document as a search key in a pre-existing document embedding space where similarity means topical relatedness rather than query-document relevance.

3.2 Big-Picture Architecture (Diagram in Words)

The HyDE system has three major components, connected in a linear pipeline:

1. Instruction-Following Language Model (InstructLM) — receives a query and a textual instruction ("write a passage to answer the question"), and generates a hypothetical document. This document is not real, may contain factual errors or hallucinations, but captures the pattern of a relevant document. This component offloads relevance modeling from representation learning to natural language generation.

2. Unsupervised Contrastive Encoder — takes the generated hypothetical document (or an averaged set of multiple generated documents) and encodes it into a dense embedding vector using the same encoder that was pre-trained to map semantically similar documents to nearby vectors. This encoder serves as a lossy compressor that filters out the hallucinated details, retaining only the semantic gist in the embedding.

3. Minimum Inner Product Search (MIPS) Index — stores pre-computed embeddings of all real documents in the corpus, computed using the same contrastive encoder. The hypothetical document embedding is used as a query against this index via inner-product similarity. The most similar real documents (by embedding cosine/ inner-product) are retrieved and returned.

Information flows linearly: query → InstructLM → hypothetical document → contrastive encoder → embedding vector → MIPS index → retrieved documents. Critically, there is no query-document similarity function learned or computed anywhere in this pipeline. The contrastive encoder is applied identically to both the hypothetical document and all real documents — it is a document-only embedding space. The query is only involved indirectly, through the generative model's transformation of it into document-like text.

3.3 Roadmap for the Deep Dive

• First, the formal problem definition and why standard dense retrieval is intractable without labels (Section 3.1). Understanding why the standard approach fails in the zero-shot setting is essential for appreciating HyDE's decomposition.
• Second, how HyDE eliminates the query encoder entirely by pivoting through a hypothetical document (Section 3.2). This is the core architectural decision — removing one of the two embedding functions that makes zero-shot learning impossible.
• Third, the generative component: how the instruction-following LLM produces hypothetical documents, what the instruction templates look like, and why generation captures relevance patterns without explicit scoring.
• Fourth, the contrastive encoding component: how the document encoder was pre-trained, why its bottleneck filters hallucinated details, and how document-document similarity substitutes for query-document relevance.
• Fifth, the embedding averaging mechanism: how multiple generated documents are combined into a single query vector (Equations 5–8), the assumptions behind averaging, and when including the raw query helps.
• Sixth, the full retrieval algorithm as an operational sequence, including the concrete instructions and configurations used in practice.

3.4 Detailed, Sentence-Based Technical Breakdown

This is a method paper whose core idea is that zero-shot dense retrieval can be achieved by decomposing it into a generative step (query → hypothetical document) and a document-similarity step (hypothetical document embedding → real document embeddings), using two independently pre-trained, frozen models, without requiring any query-document relevance labels.

3.4.1 The Formal Problem and Why Standard Dense Retrieval Is Intractable Without Labels

The standard dense retrieval formulation. The paper begins (Section 3.1) by formalizing dense retrieval in its conventional form. Given a query $q$ and a document $d$, a dense retriever uses two encoder functions — $\text{enc}_q$ for queries and $\text{enc}_d$ for documents — to map each into $d$-dimensional vectors, and defines similarity as their inner product:

$\text{sim}(q, d) = \langle \text{enc}_q(q), \text{enc}_d(d) \rangle = \langle v_q, v_d \rangle$

where $v_q = \text{enc}_q(q)$ is the query embedding, $v_d = \text{enc}_d(d)$ is the document embedding, and $\langle \cdot, \cdot \rangle$ denotes the inner product (dot product) between two vectors.

What this computes: given a query text and a document text, the formula produces a single scalar similarity score by (1) independently encoding query and document through their respective neural networks, (2) taking the dot product between the resulting vectors. A higher score means the model predicts higher relevance. The retrieval process then ranks all documents in the corpus by this score and returns the top $k$.

Why this form is label-hungry. The paper's key observation is that this formulation requires learning two separate embedding functions that must produce vectors in a shared embedding space where the inner product correlates with relevance. The query encoder $\text{enc}_q$ and document encoder $\text{enc}_d$ have no intrinsic reason to map to the same region of the embedding space. Without relevance labels — without pairs $(q, d)$ annotated as relevant or non-relevant — there is no signal that tells the training procedure how to align these two encoders. The query encoder could map all queries to one cluster and the document encoder could map all documents to an entirely different cluster, and no unsupervised loss would penalize this misalignment. The authors state this concisely: "without relevance judgments/scores to fit, learning becomes intractable."

The zero-shot constraint. Formally, the paper considers $L$ query sets $Q_1, Q_2, ..., Q_L$ and their corresponding document corpora $D_1, D_2, ..., D_L$. Denote the $j$-th query from the $i$-th set as $q_{ij}$. The zero-shot requirement is: the system must fully define $\text{enc}_q$ and $\text{enc}_d$ without access to any query set $Q_i$, any document set $D_i$, or any relevance judgment $r_{ij}$. The system cannot see the queries, documents, or labels at training time — it must work out-of-box on entirely new corpora and query distributions.

3.4.2 The Core Architectural Decision: Eliminating the Query Encoder

The key move: cast retrieval as a document-document similarity problem. HyDE's solution to the intractability of zero-shot query-document alignment is to eliminate the query encoder entirely. Instead of learning $\text{enc}_q$ and $\text{enc}_d$ separately and trying to align their output spaces without labels, HyDE uses only a single document encoder $f$ for everything:

$f = \text{enc}_d = \text{enc}_{\text{con}}$

where $\text{enc}_{\text{con}}$ is an unsupervised contrastive encoder pre-trained to map semantically similar documents to nearby vectors. The function $f$ is applied identically to all real documents in the corpus:

$v_d = f(d) \quad \forall d \in D_1 \cup D_2 \cup ... \cup D_L$

What this means: every document in every corpus — across all tasks and languages — is encoded using the same frozen function $f$. There is no query-specific encoder, no task-specific adaptation, and no training on any of the target corpora. The embedding space is purely a document-document similarity space: two documents that are semantically similar (cover the same topics, use similar language) will have high inner product, and two documents about unrelated topics will have low inner product.

The problem this creates and how HyDE solves it. If the embedding space only captures document-document similarity, how do you search with a query — which is typically a question, a claim, or a short phrase — that doesn't look like a document at all? The answer is the paper's central contribution: transform the query into a document first, then use document-document similarity. This transformation is performed by a separate generative model $g$, which is an instruction-following LLM:

$g(q, \text{INST}) = \text{InstructLM}(q, \text{INST})$

where $q$ is the query and $\text{INST}$ is a textual instruction (e.g., "write a passage to answer the question"). The output of $g$ is a generated text — a hypothetical document — which can then be fed into the document encoder $f$ to produce a query vector:

$v_q = f(g(q, \text{INST}))$

Why this decomposition works. The paper argues that this decomposition is effective because each component solves a problem it was separately designed and trained for, in a domain where it generalizes well:

• Relevance modeling is offloaded to NLG. Instruction-following LLMs like InstructGPT have demonstrated the ability to zero-shot generalize to diverse instructions — they can "write a passage to answer the question" for questions they've never seen, in domains they weren't specifically trained for. The generated document captures what a relevant document would look like: it uses the vocabulary, the sentence structure, the explanatory style of a real document on that topic. The authors note that "generating documents, i.e., providing examples," replaces the explicit modeling of relevance scores. The model doesn't need to produce a number representing relevance; it just needs to produce text that looks relevant — and this is exactly what LLMs are good at.

• The encoder's dense bottleneck filters hallucinations. The generated hypothetical document may contain factual errors, invented details, or statements not supported by any real document in the corpus. The contrastive encoder $f$ was trained to map documents to embeddings based on their overall semantic content, not their specific factual claims. As a lossy compressor — reducing thousands of tokens to a few hundred dimensions — the encoder retains the broad topical signal (what the document is about) while discarding fine-grained details. This means that hallucinated specifics (e.g., a wrong date, a fabricated statistic) are largely filtered out of the embedding, while the topical orientation (the document is about wisdom tooth removal recovery time) is preserved.

• Document-document similarity substitutes for query-document relevance. Since the hypothetical document was generated to be a relevant document — it was prompted with "write a passage to answer the question" — any real document that is document-similar to it is likely to also be relevant to the original query. The chain of reasoning is: the query implies a certain kind of document; the LLM generates an example of that kind of document; documents similar to that example are likely relevant to the query.

3.4.3 The Generative Component: Instruction-Following LLM as Relevance Model

Model choice. The paper uses InstructGPT (the text-davinci-003 model from the GPT-3 instruct series; Ouyang et al., 2022) as the generative backbone. This model was chosen because it was specifically trained to follow instructions — it has been fine-tuned with supervised learning and reinforcement learning from human feedback (RLHF) to produce outputs that satisfy user-specified instructions across diverse, unseen tasks. The paper also experiments with a 52-billion parameter Cohere model (command-xlarge-20221108) and an 11-billion parameter FLAN-T5 model (FLAN-T5-xxl; Wei et al., 2022) in Section 5.1, reporting that "larger models bring larger improvements."

The instruction templates. The generative model receives both the query and a textual instruction that specifies the form of the desired hypothetical document. These instructions are task-specific but share a common structure. The general template is:

Please write a [passage type] to [task description]
[Query label]: [QUERY]
Passage:

Concrete examples from Appendix A.1:

• Web search (TREC DL19/20): "Please write a passage to answer the question\nQuestion: [QUESTION]\nPassage:"
• Scientific fact verification (SciFact): "Please write a scientific paper passage to support/refute the claim\nClaim: [Claim]\nPassage:"
• Counter-argument retrieval (Arguana): "Please write a counter argument for the passage\nPassage: [PASSAGE]\nCounter Argument:"
• Biomedical QA (TREC-COVID): "Please write a scientific paper passage to answer the question\nQuestion: [QUESTION]\nPassage:"
• Financial QA (FiQA): "Please write a financial article passage to answer the question\nQuestion: [QUESTION]\nPassage:"
• Entity retrieval (DBPedia): "Please write a passage to answer the question.\nQuestion: [QUESTION]\nPassage:"
• News retrieval (TREC-NEWS): "Please write a news passage about the topic.\nTopic: [TOPIC]\nPassage:"
• Multilingual (Mr. TyDi): "Please write a passage in Swahili/Korean/Japanese/Bengali to answer the question in detail.\nQuestion: [QUESTION]\nPassage:"

Design rationale for task-specific instructions. The paper notes that the instructions "share a similar structure but have different quantifiers to control the exact form of the generated hypothetical documents." This is important because different retrieval tasks involve different kinds of documents: a scientific paper passage looks different from a financial article, which looks different from a news article. Guiding the LLM to generate the right kind of document — matching the style, vocabulary, and structure of the target corpus — makes the hypothetical document more similar to real documents in that corpus, which improves retrieval accuracy. The instruction acts as a cheap, zero-shot form of domain adaptation: without any training, the system can adjust its behavior simply by changing the text of the instruction.

The generation process. The paper samples from InstructGPT using the OpenAI playground default temperature of 0.7 for open-ended generations. This temperature — which controls the randomness of the output by scaling the logits before the softmax — is relatively high, meaning the model produces diverse outputs each time it's called with the same prompt. This diversity is leveraged through multiple sampling: the paper generates $N$ hypothetical documents $\hat{d}_1, \hat{d}_2, ..., \hat{d}_N$ from the same query and instruction, then averages their embeddings (see Section 3.4.5 below).

Why generation captures relevance without scoring. The paper argues that this generative process naturally captures relevance patterns because the model has been trained on vast amounts of text where questions are followed by answers, claims are followed by supporting or refuting passages, and topics are followed by explanatory text. When prompted to "write a passage to answer the question," the model draws on these learned patterns to produce text that would be an appropriate answer — even if the specific facts are wrong. The key insight is that relevance is a linguistic and structural property that can be demonstrated through generation, not necessarily a factual relationship that needs to be scored numerically. A passage about wisdom tooth removal that mentions "30 minutes to two hours" is relevant to the query "how long does it take to remove wisdom tooth" because of the topic, vocabulary, and explanatory structure, even if the specific time figure is inaccurate.

The hallucination problem and why it's acceptable. The paper is explicit that the generated document "is not real, can and is likely to be ungrounded factually." The authors cite Brown et al. (2020) and Thoppilan et al. (2022) as evidence that LLMs are prone to factual errors in generation. However, HyDE only requires the generated document to "capture relevance pattern" — to look like and talk about the right things, not to be factually correct. The contrastive encoder's dense bottleneck (discussed next) serves as the mechanism that filters out the factual errors, retaining the broad semantic signal.

The ambiguity assumption. The paper states that it "assumes the distribution of $v_{q_{ij}}$ is uni-modal, i.e. the query is not ambiguous." This means the method as presented assumes that for each query, there is essentially one topic or interpretation that the generated documents cluster around. The study of ambiguous queries (where a single query string could have multiple legitimate interpretations, each requiring different documents) and diversity in retrieval is explicitly left to future work.

3.4.4 The Contrastive Encoding Component: Unsupervised Document Similarity as the Search Space

Model choice. The paper uses the Contriever model (Izacard et al., 2021) as the document encoder $f$ for English retrieval tasks, and mContriever (its multilingual counterpart) for non-English tasks. Both are pre-trained using unsupervised contrastive learning on large text corpora — no relevance labels, no query-document pairs.

How Contriever was trained (referenced, not re-trained). Contriever's training procedure, which the paper adopts as-is without modification, works as follows: pairs of document segments are created from the training corpus by treating segments that come from the same document or that are lexically similar as positive pairs, and random segments as negative pairs. A contrastive loss (specifically, the InfoNCE loss) pushes the model to produce similar embeddings for positive pairs and dissimilar embeddings for negative pairs. The training objective is:

$\mathcal{L}_{\text{contrastive}} = -\log \frac{\exp(\langle f(d_i), f(d_i^+) \rangle / \tau)}{\sum_{j} \exp(\langle f(d_i), f(d_j) \rangle / \tau)}$

where $f(d_i)$ is the embedding of a document, $f(d_i^+)$ is the embedding of a positive (similar) document, $f(d_j)$ for $j \neq i$ are embeddings of negative (dissimilar) documents in the batch, and $\tau$ is a temperature parameter.

What this training produces: a function $f$ that maps any document (regardless of domain or language) to a dense vector such that the inner product $\langle f(d_a), f(d_b) \rangle$ is high when $d_a$ and $d_b$ are semantically similar, and low when they are not. This is a document-document similarity space — it captures how similar two documents are to each other, not how relevant a document is to a query.

Why the dense bottleneck filters hallucinations. The encoder maps text of arbitrary length to a fixed-size dense vector (typically hundreds of dimensions). This mapping is inherently lossy: the full detail of the input text — specific numbers, names, dates, word-for-word phrasing — cannot all be preserved in a few hundred floating-point numbers. The encoder, through its contrastive training, has learned to preserve the information that distinguishes semantically similar documents from dissimilar ones. This tends to be the broad topical content (what the document is about, what kind of language it uses, what concepts it references) rather than specific factual details (the exact year something happened, the specific statistic cited). When a hypothetical document with hallucinated facts is encoded, the hallucinated details — being specific and not correlated with the document's topical signal — are largely discarded by the bottleneck, while the topical orientation (e.g., "this is about wisdom tooth removal recovery duration") is preserved. The embedding thus captures the gist of the hypothetical document, which is what makes it an effective search key.

The grounding function. The paper describes the encoder as serving a "grounding" function: "it further grounds the hypothetical vector to the actual corpus and the real documents." By encoding the hypothetical document and using it to search against real document embeddings, the system connects the LLM's generated text (which may be entirely unmoored from reality) to documents that actually exist in the corpus. The real documents contain verified facts, correct citations, and accurate information. The hypothetical document provides the bridge from the query to the right neighborhood of the embedding space; the real documents provide the factual grounding.

Shared encoder for all corpora. A critical practical detail: the same encoder $f$ is used for all corpora across all tasks. The paper states that "this unsupervised contrastive encoder will be shared by all incoming document corpus." This means that all document embeddings exist in the same vector space with the same notion of similarity. The encoder is not fine-tuned, adapted, or modified for any specific task or corpus. This is what makes HyDE truly zero-shot: the encoder was pre-trained once, on data unrelated to any of the test tasks, and is deployed as-is.

Trade-offs in the multilingual setting. The paper notes that "the small-sized contrastive encoder gets saturated as the number of languages scales." This is a known limitation of multilingual encoders: with a fixed model capacity, encoding more languages means less representational capacity per language. Additionally, the multilingual model (mContriever) was pre-trained on less data for low-resource languages like Swahili and Bengali compared to high-resource languages like English. This saturation partially explains why HyDE's improvements over mContriever on multilingual tasks (Table 3) are smaller in absolute terms than the improvements on English tasks (Tables 1 and 2).

3.4.5 The Embedding Averaging Mechanism: From Multiple Hypothetical Documents to One Query Vector

The expectation formulation. The paper frames the query vector $v_{q_{ij}}$ as the expected embedding of a hypothetical document generated from the query and instruction:

$\mathbb{E}[v_{q_{ij}}] = \mathbb{E}[f(g(q_{ij}, \text{INST}_i))]$

where $q_{ij}$ is the query, $\text{INST}_i$ is the task-specific instruction, $g$ is the generative LLM, and $f$ is the contrastive encoder.

What this means: the "true" query vector is the expected value (the average, over infinitely many samples) of the embedding of hypothetical documents generated from that query. This is a theoretical construct — in reality, we cannot sample infinitely many documents. The expectation reflects the idea that the generative process produces a distribution over possible hypothetical documents (due to the sampling temperature), and the embedding of each one captures a slightly different aspect of what a relevant document might look like. Averaging over multiple samples approximates this expectation and produces a more robust query vector than any single sample.

The sampling-based approximation (Equation 6–7). In practice, the expectation is estimated by sampling $N$ hypothetical documents and averaging their embeddings:

$\hat{v}_{q_{ij}} = \frac{1}{N} \sum_{\hat{d}_k \sim g(q_{ij}, \text{INST}_i)} f(\hat{d}_k)$

which expands to:

$\hat{v}_{q_{ij}} = \frac{1}{N} \sum_{k=1}^{N} f(\hat{d}_k)$

What this computes: the system (1) samples $N$ different hypothetical documents from the LLM using the same query and instruction (diversity comes from the temperature setting of 0.7), (2) encodes each document independently through the contrastive encoder to produce $N$ embedding vectors, and (3) computes the element-wise mean of these $N$ vectors. The result is a single query vector that is then used for similarity search against the corpus embeddings.

Why averaging helps. The average of multiple samples reduces variance from the stochastic generation process. A single generated document may be an outlier — it might focus on an unrelated aspect, contain predominantly hallucinated content, or be poorly structured. The average smooths out these idiosyncrasies, producing an embedding that captures the central tendency of what the LLM considers a relevant document. This is a standard Monte Carlo integration technique: the sample mean converges to the true expectation as $N$ increases, with the estimation error decreasing at a rate proportional to $1/\sqrt{N}$.

Including the query as a hypothesis (Equation 8). The paper also considers a variant where the raw query itself is included as one of the "hypothetical documents" being averaged:

$\hat{v}_{q_{ij}} = \frac{1}{N+1} \left[ \sum_{k=1}^{N} f(\hat{d}_k) + f(q_{ij}) \right]$

What this computes: the query text is encoded directly through the same contrastive encoder $f$ (treating it as if it were a document), and its embedding is averaged together with the $N$ hypothetical document embeddings. The weight of the query embedding in the final vector is $1/(N+1)$ — smaller as more hypothetical documents are sampled.

Why this variant exists. The query itself contains relevant lexical and topical information — the words "wisdom tooth removal recovery time" are directly about the topic. Including the query embedding as part of the average anchors the combined vector closer to the query's literal content, which can help in cases where the LLM's generated documents drift too far from the query's intent. This is particularly useful when the LLM is weaker (e.g., smaller models in Section 5.1) and its generated documents may be less reliable. The paper doesn't report extensive ablations on this choice, but it is presented as a standard option in the method.

The uni-modality assumption revisited. The averaging formulation assumes that the distribution of hypothetical document embeddings is uni-modal — that all generated documents cluster around a single semantic center. If a query is ambiguous and the LLM generates documents about different interpretations (e.g., "Java" could generate documents about the programming language, the island, or coffee), averaging their embeddings would produce a vector that doesn't correspond well to any of these interpretations individually. The paper explicitly acknowledges this limitation and leaves multi-modal handling to future work.

3.4.6 The Complete Retrieval Algorithm

Step-by-step operational sequence. For a given query $q_{ij}$ in task $i$:

1. Instruction selection: Select the appropriate instruction template $\text{INST}_i$ for the task. For example, if the task is web search, use "Please write a passage to answer the question\nQuestion: [QUERY]\nPassage:".

2. Hypothetical document generation: Call the instruction-following LLM $g$ with the query and instruction $N$ times (the paper doesn't specify a universal $N$ — this is a hyperparameter that can be tuned per task or query). Each call produces one hypothetical document text $\hat{d}_k$. The calls are independent (same input, different random seeds due to temperature), so they produce diverse outputs.

3. Document encoding: Pass each hypothetical document $\hat{d}_k$ through the contrastive encoder $f$ to produce an embedding vector $f(\hat{d}_k) \in \mathbb{R}^d$. Optionally, also encode the raw query $f(q_{ij})$.

4. Embedding averaging: Compute the element-wise mean of the $N$ (or $N+1$) embedding vectors to produce the query vector $\hat{v}_{q_{ij}}$.

5. Similarity search: Compute the inner product between $\hat{v}_{q_{ij}}$ and every pre-computed document embedding $f(d)$ for $d \in D_i$. Return the top $k$ documents ranked by this inner product.

What is NOT in this algorithm. There is no training, no fine-tuning, no adaptation to the test corpus, and no learning of any parameters. Both $g$ and $f$ are used exactly as they were released by their respective creators. The only task-specific element is the text of the instruction $\text{INST}_i$, which is a short string written by a human — no model training is involved in producing it.

The conceptual elegance of the approach. The paper emphasizes in its conclusion that HyDE fundamentally represents a paradigm shift: "the concept of relevance in HyDE is captured by an NLG model and the language generation process." Instead of learning a numerical relevance score between queries and documents — which requires supervision — HyDE leverages the fact that relevance has a linguistic manifestation: relevant documents talk about the topic in a certain way, use certain vocabulary, and have certain structural properties. An LLM that has seen enough text can reproduce these patterns through generation, even if it can't accurately score relevance as a number. The contrastive encoder then does the operational work of finding real documents that match these patterns.

3.4.7 Design Choices and Their Justifications

Why decompose into generation + similarity rather than generate documents directly? An alternative approach would be to have the LLM generate the document identifier or the document text directly (as in generative retrieval models like DSI). HyDE explicitly avoids this because generative retrieval requires "special training procedures over relevance data" and "novel forms of search indices." By using a standard MIPS index over pre-computed embeddings, HyDE inherits the scalability, efficiency, and infrastructure of existing dense retrieval systems — the only change is how the query vector is constructed.

Why use a contrastive encoder rather than a sparse/lexical retriever (like BM25)? The paper doesn't explicitly compare against a variant where the hypothetical document is used as a BM25 query, but the rationale is implicit in the architecture: the contrastive encoder's dense bottleneck provides the filtering mechanism that removes hallucinated details. If the raw hypothetical document were used for lexical retrieval (e.g., BM25 matching over term frequency), every fabricated statistic, wrong date, and hallucinated entity would become a search term, potentially pulling in documents that happen to contain those terms but are irrelevant. The dense embedding discards these specifics and preserves only the semantic gist.

Why use the same encoder for hypothetical and real documents? This is the key design decision that makes the system zero-shot. If the hypothetical document were encoded with a different model than the real documents, the alignment problem would reappear — there would need to be some mechanism to match the two embedding spaces. By using exactly the same function $f$ for all documents (real and hypothetical), the system inherits the alignment that was learned during contrastive pre-training: similar texts get similar embeddings, regardless of whether they are real, generated, queries, or passages. The system doesn't know or care that the hypothetical document is generated by an LLM — it simply encodes it and finds its nearest neighbors.

Why instruct rather than prompt the LLM? The paper uses instruction-tuned models (InstructGPT) rather than raw language models (base GPT-3). This is because the instruction-following capability enables zero-shot generalization to the "write a passage to answer the question" task. A base LM might require few-shot examples (several demonstrations of query-answer pairs) to understand the task, which would mean the system is not truly zero-shot — it would need to be shown examples of the task format. The instruction-tuned model generalizes to this instruction format without any examples, making the system fully zero-shot.

Why task-specific instructions rather than a single generic instruction? The retrieval corpus for SciFact contains scientific paper passages; the corpus for FiQA contains financial articles. A generic instruction like "write a passage to answer the question" might produce a generic web-style passage that is stylistically different from scientific or financial writing, reducing similarity to real documents in those corpora. By tailoring the instruction to the expected document type, HyDE closes the domain gap between generated and real documents without any training — the instruction text itself serves as a zero-shot domain adaptation mechanism.

Why average multiple samples? A single sample might be an outlier — the LLM might generate a document that is off-topic, poorly structured, or overly hallucinated. Averaging $N$ samples reduces this variance and produces a more reliable query vector. This is especially important because the embedding space is purely similarity-based: an off-topic generated document would embed near documents about the wrong topic, retrieving irrelevant items. The average pushes the query vector toward the "center" of what the LLM considers a relevant document, which is more likely to fall in the right neighborhood of the embedding space.

The non-obvious consequence of the factorization. The paper concludes Section 3 by noting that "the query-document similarity score is no longer explicitly modeled nor computed." In standard dense retrieval, the system directly outputs a number representing $\text{sim}(q, d)$. In HyDE, there is no such computation — the system computes $\langle f(\text{generated\_doc}), f(\text{real\_doc}) \rangle$, which is a document-document similarity score, not a query-document relevance score. The query is only involved indirectly, as the prompt that generated the hypothetical document. This means the entire concept of "relevance scoring" has been replaced by "generate a relevant-looking document, then find similar real documents" — a procedural definition of relevance rather than a quantitative one.

4. Key Insights and Innovations

Innovation 1: Relevance Can Be Captured Through Language Generation Rather Than Learned Similarity Functions

The most fundamental conceptual move in this paper is the refusal to model query-document relevance as a learned numerical score. The entire dense retrieval literature — from DPR (Karpukhin et al., 2020) through ANCE (Xiong et al., 2021) to ContrieverFT (Izacard et al., 2021) — operates on the assumption that relevance is a function to be approximated by training two encoders to map queries and documents into a shared space where their inner product correlates with human relevance judgments. This assumption is so deeply embedded that it goes unquestioned: the problem of retrieval is the problem of learning a good similarity function.

HyDE challenges this assumption at its root by asking: what if relevance is better expressed as a linguistic phenomenon rather than a numerical one? Specifically, the paper demonstrates that an instruction-following LLM prompted to "write a passage to answer the question" produces text that captures relevance patterns — the vocabulary, structure, and topical orientation of a relevant document — even though the generated text may contain fabricated facts. The LLM is not computing a relevance score; it is demonstrating relevance through generation, the same way a human, when asked "what would a relevant document look like?", would produce a paragraph about that topic.

This is a fundamental reframing, not an incremental improvement. Prior work assumed that numer- ical relevance scores were the only viable abstraction for retrieval. Even work on query expansion (generating additional query terms) or document expansion (generating additional document terms) still ultimately relied on learned relevance models to score the retrieval candidates. HyDE eliminates the relevance scoring function entirely — it never computes sim(q, d). The retrieval is purely document-document similarity between a generated document and real documents.

The evidence that this reframing is valid — not just philosophically interesting but practically effective — comes from Tables 1–3. On TREC DL19, HyDE achieves NDCG@10 of 61.3, comparable to ContrieverFT (62.1), a model trained on 500,000+ labeled MS-MARCO query-document pairs. In other words, a system that never learned to score relevance numerically performs at the level of one that was explicitly trained on massive relevance supervision. This is the empirical justification for the paper's provocative closing question: "is numerical relevance just a statistical artifact of language understanding?" The results suggest that for the current generation of LLMs and encoders, the answer may be closer to "yes" than the field assumed.

Innovation 2: Decomposing Retrieval Into Generation and Document Similarity Eliminates the Zero-Shot Bottleneck

The paper's architectural insight is that zero-shot dense retrieval is intractable under the standard dual-encoder formulation, but becomes tractable when decomposed into two independently pre-trained, single-modality components. This is a diagnostic contribution: the paper identifies why prior approaches fail in the true zero-shot setting, and this diagnosis points directly to a solution.

Under the standard formulation (Equation 1), sim(q, d) = ⟨enc_q(q), enc_d(d)⟩, the system must learn two embedding functions that map into a shared space where the inner product captures relevance. Without relevance labels, there is no signal to align these two functions — the query encoder and document encoder could map to entirely disjoint regions of the embedding space, and no unsupervised loss would detect or penalize this misalignment. The paper argues this makes the standard approach fundamentally label-dependent in a way that cannot be circumvented by better architectures or training objectives within the dual-encoder paradigm.

HyDE's decomposition — query → hypothetical document via NLG, then hypothetical document → real documents via document-document similarity — eliminates this alignment problem by removing one of the two embedding functions. There is no separate query encoder enc_q; there is only a single document encoder f applied identically to all inputs. The generative model g handles the query-to-document transformation using its instruction-following and NLG capabilities, which were pre-trained on a different objective entirely (language modeling and instruction following). The contrastive encoder f handles document-document similarity using its unsupervised contrastive pre-training, which also required no relevance labels. The two components were trained independently, for different purposes, on different data — but they compose into an effective retrieval system.

This is a fundamental insight about modularity: by decoupling "understanding what a query means" (left to the LLM via generation) from "finding similar documents" (left to the encoder via embedding similarity), both sub-problems become solvable with existing, independently trained components. No joint training, no alignment loss, no synthetic relevance labels are needed. The paper is not proposing a new training method; it is proposing a new decomposition of the retrieval problem itself. This is analogous to how some robotics systems decompose complex manipulation tasks into perception and control modules that can be developed independently — the insight is in the decomposition, not in any individual module.

The practical consequence, shown in the experimental results, is that this decomposition works across dramatically different tasks (web search, scientific claim verification, counter-argument retrieval, multilingual QA) without any per-task training or adaptation beyond writing a one-sentence instruction. This level of cross-task generalization is unusual in retrieval and is a direct result of the modular decomposition: each component solves a task it was already good at, and the composition inherits their combined generalization properties.

Innovation 3: The Contrastive Encoder's Dense Bottleneck Serves as a Hallucination Filter — an Emergent Property, Not a Designed Mechanism

One of the paper's subtler contributions is the identification and exploitation of an emergent property of contrastive encoders: their dense bottleneck naturally filters out the kind of factual hallucination that LLMs produce, without any explicit mechanism for doing so. This is not something the encoder was trained to do — it is a byproduct of the contrastive pre-training objective and the dimensionality reduction inherent in dense embeddings.

Prior work on using LLM-generated text for retrieval (e.g., query expansion via document generation in Sachan et al., 2022) typically used the generated text directly — as terms for sparse retrieval or as training data for a supervised model. The hallucination problem was a real concern: if the generated text contains fabricated facts, those facts could pull the retrieval toward irrelevant documents that happen to share those fabricated details. The standard solution would be to improve the generator's factual accuracy (through better training, retrieval-augmented generation, or factuality constraints).

HyDE takes a fundamentally different approach: don't fix the hallucinations; let the encoder filter them out. The contrastive encoder, trained to map semantically similar documents to nearby vectors regardless of their specific factual content, preserves the broad topical signal of a document while discarding fine-grained details. When a hypothetical document says "wisdom tooth removal takes between 30 minutes and two hours," the encoder's embedding captures that this is a document about wisdom tooth removal recovery time — the specific time range, which might be fabricated, contributes relatively little to the embedding direction because it is a detail that does not systematically distinguish this document from other documents on the same topic. The embedding is thus a lossy compression that retains the gist and filters the noise.

This is a diagnostic insight with design implications that extends beyond HyDE. It suggests that whenever an LLM's output is used as an intermediate representation for retrieval or similarity search, factual accuracy is less important than the field might assume — the downstream dense encoder provides a robustness layer that absorbs hallucination. This is a counterintuitive finding because it implies that in a retrieval pipeline, a generated document with fabricated facts can be more useful as a search key than a factually accurate but stylistically mismatched document, as long as the topic, vocabulary, and structure match the target corpus.

The evidence for this mechanism is implicit in the results rather than directly ablated (the paper does not compare HyDE against a version using raw hypothetical documents for BM25 retrieval, which would isolate the bottleneck's contribution). However, the consistently strong performance across tasks — including TREC-COVID (NDCG@10 of 59.3 vs. Contriever's 27.3) where factual accuracy in generated biomedical passages would be difficult to achieve — supports the claim that the encoder is successfully filtering hallucinations, because retrieval accuracy would degrade sharply if fabricated biomedical details were pulling results toward irrelevant documents.

Innovation 4: Instruction Text as a Zero-Shot Domain Adaptation Mechanism — No Training Required

The paper demonstrates that the textual instruction provided to the LLM serves as an effective, zero-shot domain adaptation mechanism that tailors HyDE's behavior to different retrieval corpora without any model training, fine-tuning, or corpus access. This is a practical innovation that changes how practitioners should think about adapting retrieval systems to new domains.

In the standard transfer learning paradigm embodied by BEIR (Thakur et al., 2021), adapting a retriever to a new domain means either (a) pre-training on a large in-domain corpus, (b) fine-tuning on in-domain relevance labels, or (c) relying on the retriever's cross-domain generalization from MS-MARCO training. All of these require substantial compute and/or labeled data. Even unsupervised domain adaptation methods like GPL (Wang et al., 2022) require generating pseudo-labels and training on the target corpus.

HyDE's approach is radically simpler: change the instruction string. For web search, the instruction is "Please write a passage to answer the question." For SciFact (scientific claim verification), it's "Please write a scientific paper passage to support/refute the claim." For FiQA (financial QA), it's "Please write a financial article passage to answer the question." These instruction strings — each a single sentence written by a human — are the entire domain adaptation mechanism. They work because instruction-following LLMs have been trained to condition their output style and content on such specifications, and the contrastive encoder then maps the style-matched hypothetical document close to real documents in the target corpus.

This is a fundamentally different approach to domain adaptation than anything in the retrieval literature. It leverages the meta-capability that instruction-tuned LLMs acquired during RLHF training — the ability to modulate their behavior based on natural language specifications — and uses it to close the domain gap between generated queries and real documents. There is no gradient update, no corpus statistics, no embedding space transformation. The adaptation happens entirely in the text generation step, through the LLM's understanding of phrases like "scientific paper passage" vs. "financial article passage."

The evidence for this mechanism's effectiveness is distributed across Tables 1–3: a single HyDE system, with only the instruction string changing between tasks, achieves competitive performance across web search, scientific fact verification, counter-argument retrieval, biomedical QA, financial QA, entity retrieval, news retrieval, and multilingual retrieval in four languages. The fact that the same underlying models (InstructGPT + Contriever) work across such diverse corpora — each with its own document style, vocabulary, and structure — without any per-task training is the strongest evidence that the instruction text is doing meaningful adaptation work.

The paper acknowledges a limitation that reinforces this insight: on FiQA and DBPedia, HyDE underper- forms ContrieverFT, and the authors attribute this partially to "under-specification of the instruction; more elaborative instructions may help." This suggests that instruction design is not just a binary switch but a tunable mechanism — better instructions could yield better domain adaptation, opening up a research direction around automated instruction optimization for retrieval tasks.

5. Experimental Analysis

Evaluation Methodology

• Dataset. The paper evaluates on 11 query sets spanning three categories. For web search: TREC DL19 (Craswell et al., 2020a) and DL20 (Craswell et al., 2020b), both based on the MS-MARCO corpus (Bajaj et al., 2016). For low-resource diverse tasks: six datasets from the BEIR benchmark (Thakur et al., 2021) — SciFact (scientific claim verification), Arguana (counter-argument retrieval), TREC-COVID (biomedical QA), FiQA (financial QA), DBPedia (entity retrieval), and TREC-NEWS (news retrieval). For multilingual retrieval: Swahili, Korean, Japanese, and Bengali from the Mr. TyDi dataset (Zhang et al., 2021). The specific test splits follow the standard evaluation protocol for each benchmark — DL19 and DL20 use the official TREC evaluation queries, BEIR datasets use their standard test sets, and Mr. TyDi uses its evaluation split.
• Base model(s). HyDE uses two frozen, off-the-shelf backbone models. The generative component is InstructGPT (text-davinci-003 from the GPT-3 instruct series; Ouyang et al., 2022), an instruction-following LLM trained with RLHF to generalize across diverse instructions. The contrastive encoding component is Contriever (Izacard et al., 2021) for English tasks and mContriever (its multilingual counterpart) for non-English tasks; both were pre-trained using unsupervised contrastive learning on large text corpora without any relevance labels. The paper states in Section 4.1 that "no models were trained or fine-tuned in making this preprint." Additional generative models evaluated in analysis (Section 5.1) include a 52-billion parameter Cohere model (command-xlarge-20221108) and an 11-billion parameter FLAN-T5 model (FLAN-T5-xxl; Wei et al., 2022).
• Metrics. For web search (DL19/20), the paper reports MAP (Mean Average Precision), NDCG@10 (Normalized Discounted Cumulative Gain at rank 10), and Recall@1k (recall at rank 1000) — all standard IR evaluation metrics computed using the official TREC qrels (relevance judgments). For BEIR low-resource tasks, the paper reports NDCG@10 and Recall@100. For multilingual Mr. TyDi tasks, it reports MRR@100 (Mean Reciprocal Rank at rank 100). All metrics follow the evaluation protocols established by the respective benchmark papers.
• Baselines. The paper organizes baselines into two tiers. Without relevance judgment: BM25 (classical lexical retrieval using term frequency-inverse document frequency matching) serves as a strong sparse baseline; Contriever and mContriever (Izacard et al., 2021) serve as the primary unsupervised dense retrieval baselines — they encode the raw query text through the same contrastive encoder and perform inner-product search against corpus embeddings. HyDE differs from Contriever only in how the query vector is constructed (hypothetical document → encoder vs. raw query → encoder). With relevance judgment (fine-tuned models, for reference): DPR (Karpukhin et al., 2020) fine-tuned on MS-MARCO; ANCE (Xiong et al., 2021) fine-tuned on MS-MARCO with hard negative mining; ContrieverFT and mContrieverFT (Izacard et al., 2021) — Contriever models further fine-tuned on MS-MARCO with "the state-of-the-art retrieval model training pipeline that involves second-stage retrieval-specific pre-training and a few rounds of fine-tuning" (described in Section 4.1). For multilingual tasks, additional baselines include mDPR (from the Mr. TyDi paper) and MS-MARCO fine-tuned mBERT and XLM-R (from the Contriever paper). The fine-tuned models "should be considered empirical upper bounds" since they were trained in-domain (the TREC DL tasks use the MS-MARCO corpus shared with their training data) or transfered from MS-MARCO.
• Generation budget / compute accounting. The paper uses InstructGPT with the OpenAI playground default temperature of 0.7 for open-ended generation (Section 4.1). Retrieval is conducted using the Pyserini toolkit (Lin et al., 2021a). The paper does not report the number of hypothetical documents $N$ used in the averaging (Equation 6–7) in the main experimental sections — this is a notable omission. The analysis in Table 4 explores the effect of different generative models but does not ablate $N$; the choice of temperature (0.7) is also not ablated. There is no explicit per-query compute budget or FLOPs accounting — the cost of HyDE consists of the LLM API calls (latency and dollar cost) plus the encoding and search cost, none of which is quantified.
• Cross-validation / statistical protocol. The paper does not report any cross-validation folds, confidence intervals, or statistical significance tests. Results are presented as point estimates on standard benchmark test sets. This is common in the retrieval literature for these benchmarks but means there is no quantification of variance.

Main Quantitative Results

Web Search (TREC DL19 and DL20)

Headline result: HyDE more than doubles Contriever's NDCG@10 and substantially exceeds BM25 on both precision and recall metrics.

Table 1 reports results on TREC DL19 and DL20. On DL19, HyDE achieves NDCG@10 of 61.3, compared to Contriever's 44.5 (a 37.7% relative improvement) and BM25's 50.6. The gap is even larger on recall-oriented metrics: HyDE achieves Recall@1k of 88.0 versus Contriever's 74.6 and BM25's 75.0. On DL20, HyDE achieves NDCG@10 of 57.9, compared to Contriever's 42.1 (37.5% relative improvement) and BM25's 48.0. Recall@1k on DL20 is 84.4 for HyDE, 75.4 for Contriever, and 78.6 for BM25.

The Contriever-only system underperforms BM25 — a critical baseline detail. On both TREC DL19 and DL20, Contriever alone (which encodes the raw query as if it were a document) achieves lower NDCG@10 than BM25 (44.5 vs. 50.6 on DL19; 42.1 vs. 48.0 on DL20). This means the unsupervised contrastive encoder, used straightforwardly as a query-document similarity system, is worse than a simple lexical matching baseline. HyDE transforms this underperforming encoder into a system that substantially outperforms BM25. This is the strongest evidence that the encoder alone captures document-document similarity effectively, but the raw query is not a good document — HyDE's generative step bridges this gap.

Comparison to fine-tuned models. On DL19, HyDE achieves NDCG@10 of 61.3, essentially tied with ContrieverFT at 62.1 (within 1.3%) and DPR at 62.2. HyDE's MAP on DL19 (41.8) is comparable to ContrieverFT (41.7) and exceeds DPR (36.5) and ANCE (37.1). However, ANCE achieves higher NDCG@10 on both DL19 (64.5) and DL20 (64.6) than HyDE, but with lower recall — on DL19, ANCE's Recall@1k is 75.5 vs. HyDE's 88.0, a 12.5-point gap. The paper interprets this as ANCE being "biased to a subset of queries and/or relevant documents" — it ranks a smaller fraction of relevant documents highly but misses many relevant documents entirely. On DL20, HyDE's NDCG@10 (57.9) trails ContrieverFT (63.2) by 8.4% and ANCE (64.6) by 10.4%. MAP shows a similar gap: 38.2 vs. 43.6 (ContrieverFT) and 40.8 (ANCE).

Key takeaway from web search results. On the TREC DL tasks — which are in-domain for the fine-tuned models (they are trained on the same MS-MARCO corpus that the test queries and documents come from) — HyDE achieves competitive performance without any access to the training corpus, relevance labels, or even the test documents. It matches the best fine-tuned model on DL19 and falls behind by roughly 8–10% on DL20. The authors do not analyze why the gap is larger on DL20 than DL19.

Low-Resource BEIR Tasks

Headline result: HyDE improves over Contriever on 5 of 6 BEIR datasets in both NDCG@10 and Recall@100, and outperforms or matches fine-tuned DPR and ANCE across the board.

Table 2 reports NDCG@10 and Recall@100 on six BEIR datasets. For NDCG@10, HyDE outperforms Contriever on all datasets except TREC-COVID (59.3 vs. 59.5 for BM25 — a 0.2-point deficit; Contriever was at 27.3, so HyDE is still substantially better than Contriever). The largest absolute gains are on TREC-COVID (+32.0 NDCG@10 points over Contriever: 59.3 vs. 27.3), Arguana (+8.7: 46.6 vs. 37.9), and TREC-NEWS (+9.2: 44.0 vs. 34.8). On DBPedia, HyDE reaches 36.8 vs. Contriever's 29.2 (+7.6). On SciFact, the gain is smaller (+4.2: 69.1 vs. 64.9) because Contriever already performs well (64.9). On FiQA, the gain is modest (+2.8: 27.3 vs. 24.5).

Recall@100 gains are consistent. HyDE improves Recall@100 over Contriever on all six BEIR datasets. The largest gains are on TREC-COVID (+24.2: 41.4 vs. 17.2), Arguana (+7.8: 97.9 vs. 90.1), and TREC-NEWS (+8.6: 50.9 vs. 42.3). On SciFact, HyDE reaches 96.4 vs. Contriever's 92.6. On FiQA, 62.1 vs. 56.2. On DBPedia, the gain is small at 47.2 vs. 45.3 (+1.9), suggesting the encoder is already near its ceiling on entity retrieval tasks.

Comparison to fine-tuned models on BEIR. HyDE's NDCG@10 outperforms DPR on all six datasets, often by large margins (e.g., SciFact: 69.1 vs. 31.8; TREC-COVID: 59.3 vs. 33.2; TREC-NEWS: 44.0 vs. 16.1). HyDE also outperforms ANCE on SciFact (69.1 vs. 50.7), Arguana (46.6 vs. 41.5), DBPedia (36.8 vs. 28.1), and TREC-NEWS (44.0 vs. 38.2), but trails ANCE on TREC-COVID (59.3 vs. 65.4) and FiQA (27.3 vs. 30.0). HyDE's NDCG@10 trails ContrieverFT on FiQA (27.3 vs. 32.9) and DBPedia (36.8 vs. 41.3) — the paper attributes this to "under-specification of the instruction; more elaborative instructions may help" — and on TREC-COVID (59.3 vs. 59.6, essentially tied). On SciFact, HyDE (69.1) edges out ContrieverFT (67.7). On Arguana, HyDE (46.6) exceeds ContrieverFT (44.6). On TREC-NEWS, HyDE (44.0) exceeds ContrieverFT (42.8).

Notable anomaly: TREC-COVID. Contriever alone achieves only 27.3 NDCG@10 and 17.2 Recall@100 on TREC-COVID — dramatically worse than BM25 (59.5 NDCG@10, 49.8 Recall@100). This is the one dataset where the unsupervised encoder catastrophically fails. HyDE recovers nearly all of this gap (59.3 NDCG@10), suggesting that the generated hypothetical document successfully bridges the extreme domain mismatch between the encoder's pre-training distribution and biomedical text. The Recall@100 gap is only partially recovered (41.4 vs. BM25's 49.8), indicating that HyDE struggles with the full recall of relevant biomedical documents even though its top-ranked results are competitive.

Multilingual Retrieval (Mr. TyDi)

Headline result: HyDE improves over mContriever on all four languages, with the largest gains on Japanese and Korean, but trails fine-tuned mContrieverFT by substantial margins.

Table 3 reports MRR@100 on four languages from Mr. TyDi. HyDE improves mContriever on all languages: Swahili (41.7 vs. 38.3, +8.9%), Korean (30.6 vs. 22.3, +37.2%), Japanese (30.7 vs. 19.5, +57.4%), and Bengali (41.3 vs. 35.3, +17.0%). The gains are largest on Japanese and Korean, where mContriever performed especially poorly relative to BM25 (Japanese: 19.5 mContriever vs. 21.2 BM25; Korean: 22.3 vs. 28.5). HyDE's Japanese result (30.7) substantially exceeds BM25 (21.2) and mContriever (19.5), more than doubling the effective performance. On Korean, HyDE (30.6) slightly exceeds BM25 (28.5).

Comparison to fine-tuned multilingual models. On all four languages, HyDE's MRR@100 trails mContrieverFT — a model that shares the same contrastive encoder architecture but was fine-tuned on MS-MARCO English data and transferred to these languages. The gaps are: Swahili (41.7 vs. 51.2, gap of 18.6%), Korean (30.6 vs. 34.2, gap of 10.5%), Japanese (30.7 vs. 32.4, gap of 5.2%), Bengali (41.3 vs. 42.3, gap of 2.4%). The gap is smallest on Bengali and largest on Swahili. The paper hypothesizes that "non-English languages we considered are under-trained in both pre-training and instruction learning stages" of the LLM, and that "the small-sized contrastive encoder gets saturated as the number of languages scales." On Japanese, HyDE (30.7) outperforms MS-MARCO fine-tuned mBERT (27.1) and mDPR (18.1), and on Korean HyDE (30.6) outperforms mDPR (21.9) and XLM-R (32.2). HyDE outperforms all non-Contriever fine-tuned models on Swahili (41.7 vs. best alternative mBERT at 37.4).

The asymmetric scaling problem. The paper explicitly notes (Section 4.4) that the multilingual setting poses opposite challenges for the two components: the contrastive encoder is small and gets saturated (its capacity per language decreases as more languages are added), while the generative LLM is large but may be under-trained on low-resource languages. The results confirm this asymmetry: HyDE's improvements over mContriever are largest on the languages where mContriever was weakest (Japanese, Korean), suggesting the LLM's generative capability compensates for the encoder's weakness. But the remaining gap to mContrieverFT shows that fine-tuning on relevance data (even English-only MS-MARCO) still provides benefits that zero-shot generation cannot fully recover.

Effect of Different Generative Models (Section 5.1, Table 4)

Headline result: Larger generative models produce better HyDE embeddings, but even an 11-billion parameter model provides meaningful gains over Contriever alone.

Table 4 reports NDCG@10 on TREC DL19/20 for HyDE using three different instruction-following LMs with both the unsupervised Contriever encoder and the fine-tuned ContrieverFT encoder. With the unsupervised Contriever encoder: FLAN-T5-xxl (11B parameters) achieves 48.9 on DL19 and 52.9 on DL20; Cohere command-xlarge (52B) achieves 53.8 on both; InstructGPT (175B) achieves 61.3 on DL19 and 57.9 on DL20. All three outperform the Contriever-only baseline (44.5 DL19, 42.1 DL20), but the performance scaling with model size is evident: the 11B model provides a modest improvement (+4.4 NDCG on DL19), the 52B model a larger one (+9.3), and the 175B model a substantial one (+16.8). This near-monotonic scaling suggests that better language generation directly translates to better retrieval quality in the HyDE framework.

Using HyDE with fine-tuned encoders reveals an interaction effect. When HyDE is paired with ContrieverFT (the encoder fine-tuned on MS-MARCO), the results are more nuanced. With the weaker FLAN-T5-xxl generator, HyDE + ContrieverFT achieves 60.2 on DL19 — lower than ContrieverFT alone (62.1). This means a weak generator can degrade the fine-tuned encoder's performance, likely because poorly generated hypothetical documents produce embeddings that are worse search keys than the raw query. With the Cohere generator, HyDE + ContrieverFT achieves 61.4 on DL19, roughly matching ContrieverFT alone (62.1). With InstructGPT, HyDE + ContrieverFT achieves 67.4 on DL19, a 5.3-point improvement over ContrieverFT alone (62.1). On DL20, the pattern is similar but with smaller effects: FLAN-T5 degrades performance (62.1 vs. 63.2 for ContrieverFT alone), Cohere matches (63.1), and InstructGPT slightly improves (63.5 vs. 63.2).

What this tells us. The paper interprets this as evidence that "there may still exist certain factors not captured by the fine-tuned encoder but only by the generative model." In other words, even a state-of-the-art supervised dense retriever (ContrieverFT) trained on 500K+ MS-MARCO examples may miss relevance signals that a strong generative model can capture through text generation. The fact that a weaker generator degrades ContrieverFT shows that this is not just an additive benefit — the generated documents can actively harm retrieval if they are poor. This is a robustness concern for deployment: HyDE's effectiveness depends critically on the quality of the generative model, and using a weaker (or cheaper) LLM can make the system worse than not using HyDE at all, if the underlying encoder is already fine-tuned.

Ablation Studies and Robustness Checks

• Generative model scale: Table 4 shows that NDCG@10 on DL19 increases from 48.9 (FLAN-T5, 11B) to 53.8 (Cohere, 52B) to 61.3 (InstructGPT, 175B) when using Contriever as the encoder. The improvement is monotonic with model size, confirming that larger, more capable LLMs produce better hypothetical documents — but the marginal returns appear roughly linear in model size (the jump from 52B to 175B provides a larger absolute gain than 11B to 52B).

• HyDE with fine-tuned vs. unsupervised encoder: Table 4 compares HyDE with the same generator across two encoder variants. When using the unsupervised Contriever, HyDE with InstructGPT achieves 61.3 NDCG@10 on DL19; when using the fine-tuned ContrieverFT, it achieves 67.4. This shows that HyDE's benefit is additive with encoder quality — improving either component (generator or encoder) improves the overall system. However, with the weaker FLAN-T5 generator, HyDE + ContrieverFT (60.2) underperforms ContrieverFT alone (62.1), indicating that poor generation can counteract the benefits of a strong encoder. This negative result is practically important: deploying HyDE with a cheap LLM and an expensive fine-tuned encoder is counterproductive.

• Task-specific instruction design: While not a formal ablation with a single generic instruction baseline, the paper uses different instruction templates for each dataset (Appendix A.1). The variation in performance across datasets provides indirect evidence that instruction design matters. On FiQA and DBPedia, where HyDE trails ContrieverFT, the paper attributes the gap to "under-specification of the instruction; more elaborative instructions may help." This suggests that the instruction text is a meaningful hyperparameter and that poor instruction design could limit HyDE's effectiveness — but no quantitative ablation of instruction quality is provided.

• Multilingual robustness: Table 3 shows that HyDE provides gains across four languages with a single set of backbone models. The relative improvement is largest on languages where mContriever is weakest (Japanese: +57.4%, Korean: +37.2%), suggesting that the generative model can partially compensate for encoder weaknesses. However, HyDE still trails mContrieverFT on all four languages, and the gap is largest on Swahili (41.7 vs. 51.2), which is likely the most under-trained language in both the LLM and the encoder. This serves as a robustness check: HyDE works across languages but the magnitude of improvement depends on the underlying model quality for that language.

• Notable missing ablations. The paper does not ablate the number of hypothetical documents $N$ used in embedding averaging (Equation 6–7). It does not compare the averaging approach (Equation 7) against using a single generated document. It does not ablate the inclusion of the raw query embedding (Equation 8) vs. not including it. It does not ablate the generation temperature (fixed at 0.7). It does report experiments with and without the LLM (the Contriever baseline effectively serves as the "no LLM" ablation), but does not ablate "Contriever + raw query only" vs. "Contriever + hypothetical documents only" — only the averaging variant that may include the query (Equation 8) is evaluated.

Critical Assessment

Claim 1: HyDE "significantly outperforms the state-of-the-art unsupervised dense retriever Contriever"

What the experiments demonstrate. This claim is directly supported by Tables 1–3. On web search, HyDE achieves 37–38% relative improvement in NDCG@10 over Contriever (DL19: 61.3 vs. 44.5; DL20: 57.9 vs. 42.1). On BEIR, HyDE improves NDCG@10 on 5 of 6 datasets and Recall@100 on all 6. On Mr. TyDi, HyDE improves MRR@100 on all 4 languages, with the largest relative gains on Japanese (+57.4%) and Korean (+37.2%). The improvement is consistent across task types (web search, fact verification, QA, argument retrieval) and languages.

Caveats. The Contriever baseline encodes the raw query text as if it were a document — a natural zero-shot usage but not an optimized one. No variant of Contriever that pre-processes the query (e.g., extracting keywords, expanding the query with synonyms) is tested. The improvement HyDE provides is relative to this specific, simple baseline. Additionally, Contriever already underperforms BM25 on several tasks (DL19, DL20, TREC-COVID), so "significantly outperforms an already-suboptimal baseline" is a less compelling claim than "outperforms all baselines," which the paper also demonstrates relative to BM25 and, on many tasks, fine-tuned models.

Claim 2: HyDE "shows strong performance comparable to fine-tuned retrievers"

What the experiments demonstrate. On DL19, HyDE achieves NDCG@10 of 61.3 vs. ContrieverFT's 62.1 — a difference of 1.3%, within what could be statistical noise (no confidence intervals are reported). On SciFact, TREC-COVID, Arguana, and TREC-NEWS, HyDE's NDCG@10 is within 1 point of ContrieverFT or exceeds it. On DL20, however, HyDE trails ContrieverFT by 5.3 NDCG points (57.9 vs. 63.2), an 8.4% relative gap. On FiQA and DBPedia, the gaps to ContrieverFT are larger (5.6 and 4.5 NDCG points, respectively). On all four Mr. TyDi languages, HyDE trails mContrieverFT, with gaps ranging from 1.0 (Bengali) to 9.5 (Swahili) MRR points.

What the experiments do NOT demonstrate. The fine-tuned models are not competing on equal footing. ContrieverFT was fine-tuned on MS-MARCO, and the TREC DL tasks are defined on the same MS-MARCO corpus — this is an in-domain evaluation for ContrieverFT. For BEIR and Mr. TyDi, ContrieverFT benefits from transfer from MS-MARCO, a massive out-of-domain resource that contains 500,000+ labeled query-document pairs. HyDE uses no such resource. The claim that HyDE is "comparable" to fine-tuned retrievers should thus be qualified: HyDE is comparable despite using zero relevance labels while ContrieverFT uses 500K+ labels. The comparison shows that HyDE closes most of the gap between unsupervised and supervised retrieval, not that it matches a fully supervised system on equal ground.

Furthermore, the paper does not compare against fine-tuned models that also use LLM-generated data (e.g., a system that uses HyDE-like document generation to create synthetic training data for a supervised retriever, similar in spirit to Sachan et al., 2022). Such a comparison would help disentangle whether HyDE's benefits come from the LLM generation per se, or specifically from the zero-shot, training-free use of that generation.

Claim 3: The encoder's dense bottleneck filters out hallucinated details

What the experiments demonstrate. This claim is primarily a mechanistic hypothesis — the paper argues that the encoder's lossy compression discards irrelevant or fabricated specifics while retaining topical signals. The empirical evidence is indirect: the fact that HyDE works well (e.g., TREC-COVID NDCG@10 of 59.3, Arguana NDCG@10 of 46.6) despite the generated documents likely containing factual errors (the paper acknowledges LLMs are prone to hallucination) suggests that those errors are not significantly degrading retrieval. However, the paper never measures hallucination rates, never ablates the effect of hallucinated content on retrieval quality (e.g., by comparing HyDE with artificially hallucinated documents vs. factually accurate ones), and never demonstrates that the bottleneck is the mechanism responsible (as opposed to, say, the averaging of multiple samples or the overall topical signal dominating the embedding regardless of factual content).

The missing experiment. A direct test would be to compare HyDE using factually accurate generated documents (perhaps verified against a knowledge base or generated with retrieval augmentation) against HyDE using standard generation. If the factually accurate variant performs no better, the bottleneck hypothesis is supported; if it performs substantially better, hallucination is actually harming retrieval and the bottleneck is an imperfect filter. This experiment is absent. The claim that the bottleneck filters hallucinations remains an untested mechanism hypothesis, not an experimentally verified property.

Claim 4: HyDE is a practical zero-shot system with no training required

What the experiments demonstrate. No model training or fine-tuning is performed anywhere in the paper — all components are used as-is, off-the-shelf. This aspect of the claim is fully satisfied.

What the experiments do NOT address. A practical system has costs (latency, dollar cost, computational resources). HyDE requires API calls to a 175B-parameter LLM (InstructGPT) for every query, potentially multiple calls if N > 1. The paper never reports the number of LLM calls per query, the total tokens generated, the latency per query, or the financial cost of using the OpenAI API. Table 4 shows that a smaller model (FLAN-T5, 11B) provides only modest improvements over Contriever, meaning that the strong results depend on a very large, proprietary, API-accessed model. For a practitioner deciding whether to deploy HyDE, the absence of cost/latency data is a significant gap. Additionally, the difficulty estimation problem that plagues similar systems (as discussed in the HyDE paper's approach) does not apply here since HyDE is zero-shot, but the cost of the LLM calls is the analogous practical concern. A comparison to simply using a cheaper LLM with more samples would help assess the cost-effectiveness tradeoff.

Weaknesses in Experimental Design

• No ablation of $N$ (number of generated documents). The paper never states how many hypothetical documents were generated per query in the main experiments. Equation 7 defines the averaging over $N$ samples, but the value of $N$ is not reported. If $N$ is large (e.g., 10+), the LLM API cost could be substantial; if $N$ is small (e.g., 1–3), the system may be sensitive to generation noise. This is a critical hyperparameter that should be ablated.

• No quantification of statistical significance. All results are point estimates without confidence intervals, standard deviations, or significance tests. The test sets vary in size — TREC DL19 has 43 queries, DL20 has 54, BEIR datasets range from a few hundred to a few thousand queries. On the smaller test sets (especially DL19/DL20), point estimates can be noisy, and the 1–2 point differences between HyDE and ContrieverFT on DL19 may not be statistically reliable.

• Single family of generative models. The paper tests InstructGPT (GPT-3 series), FLAN-T5, and Cohere — all decoder-only or encoder-decoder transformer models trained on similar internet-scale corpora. No test is conducted with models from fundamentally different families (e.g., retrieval-augmented generators, models trained primarily on code, models with different tokenization strategies). The conclusion that larger models produce better HyDE embeddings may not generalize across model architectures.

• Single encoder family with limited exploration. The paper uses Contriever/mContriever exclusively. Other unsupervised contrastive encoders exist (e.g., SimCSE, Gao et al., 2021, which the paper cites; or LaBSE for multilingual). The choice of Contriever is well-justified (it is state-of-the-art for unsupervised dense retrieval), but the sensitivity of HyDE to the choice of encoder is not explored. Would HyDE work with a weaker encoder? With a different training objective? The results on TREC-COVID (Contriever barely above random at NDCG 27.3) suggest that HyDE can partially rescue a failing encoder, but the boundary conditions are unclear.

• No comparison to alternative zero-shot retrieval baselines beyond BM25 and Contriever. The paper frames itself as solving zero-shot dense retrieval, but the only zero-shot baselines are BM25 (not dense) and Contriever (which uses the raw query). Other zero-shot approaches exist — for instance, using the LLM to generate query terms for BM25 expansion, using a different relevance-free dense method like sentence-transformers, or using the LLM to directly score documents. None of these are tested. This makes it difficult to assess whether HyDE's specific architecture (generative model + contrastive encoder) is necessary, or whether the LLM's knowledge could be leveraged more simply.

• No test of HyDE on truly out-of-domain queries where the LLM has no knowledge. The paper tests on standard benchmarks where the LLM has almost certainly seen related text during pre-training. A critical test of HyDE's robustness would be on queries about very recent events (outside the LLM's training cutoff), highly specialized technical domains (where the LLM may lack vocabulary), or queries that require factual knowledge the LLM doesn't have. If the LLM generates plausible-sounding but entirely wrong hypothetical documents (because it doesn't understand the topic), does the encoder still map them to relevant real documents? The paper provides no evidence either way.

Missing Experiments That Would Strengthen the Paper

• Ablation of $N$ (number of generated documents per query) across a range (1, 2, 4, 8, 16) to quantify the value of multiple samples and the cost-performance tradeoff.
• Ablation of the contribution from averaging vs. the contribution from the initial generation: compare HyDE with $N=1$ (single generated document, no averaging) against $N=8$, and against the variant where the raw query is averaged in (Equation 8).
• BM25 + HyDE: use the hypothetical document text directly as a lexical query (rather than encoding it). This would test whether the dense bottleneck is necessary or if the generated text alone is sufficient.
• Comparison to a retrieval-augmented generation baseline: generate the hypothetical document with access to a retrieval system, then use that document for retrieval — does factual grounding of the generation help?
• Cost analysis: report tokens generated per query, API calls per query, latency per query, and estimated cost per query for each generative model tested in Table 4.
• Evaluation on a temporal holdout set where queries are about events after the LLM's training cutoff, to test robustness to unknown topics.

Conditions Under Which Claims Hold

The paper's central claim — that HyDE provides effective zero-shot dense retrieval — holds broadly across the tested benchmarks but with specific boundary conditions visible in the data: (1) it works best when the target corpus has a consistent document style that can be specified in the instruction (the instruction serves as domain adaptation); (2) it works best when the LLM has sufficient training data in the query language (gains are smaller on low-resource languages like Swahili); (3) it works best when the encoder has reasonable baseline performance (TREC-COVID shows the encoder can be too weak); (4) it works best with large generative models (the 11B FLAN-T5 model provides only modest gains); and (5) the gains over Contriever are most pronounced when Contriever alone is weakest, suggesting HyDE partially compensates for encoder limitations but does not replace encoder quality. The paper's boldest implication — that numerical relevance scoring may become unnecessary as NLG models improve — is suggested by the strong InstructGPT results but is not experimentally tested in the limit (what happens with even larger models? At what point does generation quality saturate for retrieval purposes?).

6. Limitations and Trade-offs

6.1 The Number of Generated Documents $N$ Is Never Reported, Making Cost and Reproducibility Impossible to Assess

The assumption or constraint. HyDE's core retrieval algorithm (Equations 6–7) requires sampling $N$ hypothetical documents from the generative LLM and averaging their embeddings. The paper defines this mechanism but never states the value of $N$ used in any experiment. The generation process — which calls a 175B-parameter proprietary API model (InstructGPT, text-davinci-003) at a sampling temperature of 0.7 — has a direct per-query cost that scales linearly with $N$. The paper provides no information about how many LLM calls were made per query, how many tokens were generated, what the latency was, or what the financial cost was.

The consequence. Without knowing $N$, three things become impossible for a practitioner: (1) reproducibility — the exact experimental configuration cannot be replicated; (2) cost estimation — a practitioner cannot determine whether HyDE's performance gains justify the additional expense of LLM API calls over simpler baselines (BM25, or Contriever with the raw query); (3) cost-performance tradeoff analysis — the paper's headline improvements over Contriever (e.g., 61.3 vs. 44.5 NDCG@10 on DL19) are presented without any associated cost multiplier. If HyDE requires $N = 8$ generations per query at roughly $0.02 per 1K tokens (InstructGPT pricing at the time of writing), the cost per query could be orders of magnitude higher than encoding a raw query through Contriever. The experiments in Table 4 demonstrate that larger generative models produce better results, but the cost scaling with model size is not discussed — a practitioner choosing between the 11B FLAN-T5 model (which can be run locally) and the 175B InstructGPT model (which requires paid API access) has no basis for deciding whether the performance improvement justifies the cost.

What evidence exists in the paper. The paper never reports $N$, never ablates it, and never discusses the cost implications of multiple LLM calls. Section 4.1 states that the system samples from InstructGPT "using the OpenAI playground default temperature of 0.7 for open-ended generations" and that retrieval uses the Pyserini toolkit, but no generation budget is specified. The paper's closing paragraph in Section 1 states "No models were trained or fine-tuned in making this preprint," which emphasizes the training-free nature but implicitly treats the inference-time cost of LLM calls as outside the scope of analysis.

Mitigation status. Not addressed. No future work is suggested on cost-aware HyDE deployment or on determining the optimal $N$ as a function of query difficulty or task type.

6.2 The Contrastive Encoder's Hallucination-Filtering Mechanism Is Hypothesized, Not Demonstrated

The assumption or constraint. The paper's central mechanistic claim is that the contrastive encoder's dense bottleneck "serves as a lossy compressor that outputs dense vectors, where the extra details are filtered and left out from the vector. It further grounds the hypothetical vector to the actual corpus and the real documents" (Section 3.2). The encoder was trained on a contrastive document-document similarity objective (Izacard et al., 2021) — it was never designed or explicitly trained to identify and discard hallucinated content. The paper asserts that factual errors in the generated hypothetical document are filtered out by the encoder's dimensionality reduction, but provides no direct evidence for this claim.

The consequence. If the hallucination-filtering mechanism does not work as hypothesized — if hallucinated details do meaningfully influence the embedding direction and pull retrieval toward irrelevant documents — then HyDE's performance on tasks requiring factual precision (e.g., scientific claim verification in SciFact, biomedical QA in TREC-COVID) could be worse than reported by luck of the specific test queries, or could degrade unpredictably when the LLM generates particularly egregious hallucinations. The paper's bold implication — that using generated documents for retrieval is robust to factual errors — would be unsupported. Conversely, if the mechanism does work, the paper has discovered an emergent property of contrastive encoders that is practically important but remains unexplained: why does a document-document similarity encoder learn to ignore factual specifics? Without understanding this, practitioners cannot know whether the property transfers to other encoder architectures, training objectives, or data distributions.

What evidence exists in the paper. The evidence is entirely indirect. The paper shows that HyDE works well across tasks (Tables 1–3), which is consistent with the hallucination-filtering hypothesis but does not test it. Several experiments that would provide direct evidence are absent: (1) a comparison of HyDE using factually accurate generated documents vs. standard generation (if accuracy doesn't matter, the mechanism is supported; if accuracy improves results, hallucinations are harming retrieval); (2) a qualitative analysis of retrieved documents showing that they match the topic of the hypothetical document but not its fabricated specifics; (3) a measurement of hallucination rates in the generated documents and a correlation analysis with retrieval quality. The paper does not quantify how often the LLM generates hallucinated content, nor does it demonstrate that the encoder embeddings are invariant to factual perturbations.

Mitigation status. Not addressed. The paper treats the bottleneck-as-filter mechanism as a design rationale rather than a testable hypothesis. No ablation, measurement, or analysis is devoted to verifying it. This leaves a gap between the paper's conceptual argument and its empirical validation.

6.3 Single Encoder Family and Single LLM Paradigm Limit Generality of Findings

The assumption or constraint. All HyDE experiments use exactly one encoder family — Contriever and mContriever (Izacard et al., 2021) — pre-trained with one specific contrastive learning objective (unsupervised contrastive learning on document pairs derived from the corpus). The generative models, while varied in scale (11B FLAN-T5, 52B Cohere, 175B InstructGPT), are all instruction-following transformer LMs pre-trained on large internet-scale text corpora and fine-tuned with similar instruction-tuning paradigms. The paper's conclusions about HyDE's effectiveness, the encoder's hallucination-filtering behavior, and the dependence on model scale are all conditioned on this specific combination of architectures and training procedures.

The consequence. A practitioner using a different encoder — for example, a sparse encoder (SPLADE), a different contrastive encoder (SimCSE; Gao et al., 2021, which the paper cites), a multi-vector encoder (ColBERT), or an encoder pre-trained on a different data distribution (domain-specific corpora, code-heavy corpora) — cannot assume HyDE will work with similar effectiveness. The contrastive training objective of Contriever (InfoNCE loss on document pairs) may be necessary for the bottleneck-filtering property; encoders trained with different objectives (e.g., masked language modeling, next-sentence prediction, or supervised relevance training) may behave differently. Similarly, using a non-instruction-tuned LLM (e.g., base GPT-3 without RLHF) as the generator would require few-shot prompting rather than zero-shot instruction following, which fundamentally changes the system's zero-shot character and may affect generation quality.

What evidence exists in the paper. The analysis in Table 4 shows that HyDE's performance varies substantially with the choice of generative model (11B FLAN-T5: 48.9 NDCG@10; 52B Cohere: 53.8; 175B InstructGPT: 61.3 on DL19), demonstrating sensitivity to the generator. However, no encoder ablation is performed — Contriever is the only encoder tested. The paper does not compare HyDE with, for example, a SimCSE encoder or a standard BERT encoder used in a zero-shot manner, which would help determine whether the findings are encoder-specific. The paper also does not test a non-instruction-tuned LLM with few-shot prompting, which would help separate the contribution of instruction tuning from the contribution of the underlying language modeling capability.

Mitigation status. Not addressed. The paper treats Contriever and InstructGPT as representative components without discussing how results might change with different encoder architectures or LLM paradigms. The authors do not suggest this as future work.

6.4 No Quantification of Per-Query Latency or Throughput Constraints

The assumption or constraint. HyDE adds a generative step before retrieval: for each query, the system must call an LLM (potentially multiple times for $N$ samples), wait for text generation token-by-token, then encode the generated text through the contrastive encoder. This is inherently a serial bottleneck — the retrieval step cannot begin until generation is complete. The paper measures retrieval quality (NDCG, MAP, Recall, MRR) but never measures wall-clock latency, tokens-per-second throughput, or total time-per-query. The practical deployment context for retrieval systems often involves latency budgets on the order of tens to hundreds of milliseconds for interactive applications; LLM generation with a 175B-parameter model can take seconds to tens of seconds depending on output length and API queuing.

The consequence. HyDE may be impractical for latency-sensitive applications regardless of its retrieval quality. A user-facing search engine requiring sub-second response times cannot afford multiple sequential LLM calls per query (each generating a paragraph of text) followed by encoding and MIPS search. Similarly, high-throughput batch retrieval pipelines scanning millions of queries would face substantial cost and time overhead from the LLM generation step. The paper's comparison to Contriever (which requires only a single forward pass through a much smaller encoder — Contriever has 110M parameters vs. InstructGPT's 175B) does not account for the several-orders-of-magnitude difference in inference time. A practitioner deciding between HyDE and a simpler approach needs to know whether the latency penalty is 10ms, 100ms, 1s, or 10s per query — the paper provides no data to inform this decision.

What evidence exists in the paper. None. The paper provides no latency measurements, no token-generation counts, no throughput benchmarks, and no discussion of the tradeoff between retrieval quality and query-time latency. The generation temperature (0.7) and the sampling process are described, but the time cost of generating and encoding hypothetical documents is entirely unquantified. Section 6 (Conclusion) discusses the practical use of HyDE at "the very beginning of the life of the search system," where it serves as a bridge until supervised models can be trained — but even in this cold-start scenario, latency constraints still apply.

Mitigation status. Not addressed. The paper does not acknowledge latency as a limitation or suggest engineering approaches to reduce it (e.g., pre-computing hypothetical documents for common queries, using smaller distilled generators, or caching embeddings for repeated queries).

6.5 The Ambiguity Assumption Is Unstated in Practice and Untested

The assumption or constraint. The paper explicitly states in Section 3.2 that it "simply consider[s] the expectation value, assuming the distribution of $v_{q_{ij}}$ is uni-modal, i.e. the query is not ambiguous." This means HyDE assumes each query has essentially one interpretation, and averaging the embeddings of multiple generated documents will converge to a meaningful center. Ambiguous queries — those with multiple legitimate interpretations (e.g., "Java" as programming language vs. island vs. coffee; "bank" as financial institution vs. river bank; "apple" as fruit vs. company) — would produce a multi-modal distribution of hypothetical documents, and the average embedding could land in a region of the embedding space that corresponds to neither interpretation well, degrading retrieval for all interpretations.

The consequence. For any retrieval task where query ambiguity is common — which includes most web search scenarios, where short queries are frequently ambiguous — HyDE could perform substantially worse than the reported results. The paper tests on TREC DL19/20 (which contain naturalistic web search queries that can be ambiguous), BEIR datasets (some of which, like DBPedia-Entity, involve short entity queries that may be ambiguous — "Michael Jordan" could refer to the athlete or the machine learning researcher), and Mr. TyDi (multilingual queries with potential translation ambiguity). The reported results may represent an upper bound that would not hold on a query set specifically selected for ambiguity.

What evidence exists in the paper. The paper does not test the ambiguity assumption — no experiments separate ambiguous from unambiguous queries, no analysis shows how HyDE's performance varies with query ambiguity, and no alternative aggregation method (e.g., retrieving separately for each mode of the distribution and merging results, or using the raw query embedding as a fallback when generation diversity is high) is proposed or tested. The assumption is stated once in Section 3.2 and never revisited. The TREC DL19/20 query sets contain 43 and 54 queries respectively — far too few to perform a meaningful ambiguity-stratified analysis, and the exact queries are not examined for ambiguity.

Mitigation status. Explicitly deferred to future work. The paper states "The study of ambiguous queries and diversity is left to future work" (Section 3.2). No preliminary analysis, no suggested approach, and no qualifying of the main results in light of this assumption is provided.

6.6 No Retrieval Baseline Using the Hypothetical Document as a Lexical Query

The assumption or constraint. HyDE's architecture encodes the hypothetical document into a dense embedding and uses it for vector similarity search. The paper argues that the dense bottleneck is essential because it "filters out the incorrect details" from the hallucinated document (Section 3.2). However, an obvious alternative baseline is never tested: use the hypothetical document's text directly as a lexical query for BM25 retrieval. If the generated document already uses vocabulary and phrasing similar to relevant real documents, BM25 term matching might perform comparably to or better than HyDE's dense retrieval, without requiring an encoder at all and with substantially lower computational cost (BM25 is far cheaper than dense encoding + MIPS).

The consequence. Without this baseline, it is impossible to determine whether HyDE's performance comes from the specific architecture (LLM → dense encoder → MIPS) or simply from the LLM's ability to generate query-expansion-like text that happens to match relevant documents. If BM25 + hypothetical document performs similarly to HyDE, then the dense encoder is not adding value — the entire benefit would come from the LLM's generation, and a simpler, cheaper, and more interpretable lexical retrieval system would suffice. If BM25 + hypothetical document performs worse, the paper's claim that the dense bottleneck filters hallucinations would gain support (since BM25 would be more susceptible to matching on hallucinated terms). In either case, this baseline would disambiguate the contribution of each component.

What evidence exists in the paper. None. The only lexical baseline reported is standard BM25 with the original query (no generation), which HyDE outperforms (Tables 1–3). But this compares HyDE's full pipeline against BM25 without the benefit of LLM generation — it does not isolate the effect of the dense encoder. The paper never reports what happens if the hypothetical document text is fed directly to BM25.

Mitigation status. Not addressed. The paper does not discuss this baseline, acknowledge its absence, or explain why it was not included. The choice to use a dense encoder rather than lexical retrieval from the hypothetical document is presented as a design decision, not as a comparison point to be validated empirically.

7. Implications and Future Directions

How This Work Changes the Landscape

HyDE represents a genuine paradigm shift in how the retrieval community thinks about relevance, not an incremental improvement. The paper's central conceptual move — replacing learned query-document similarity scoring with language generation followed by document-document similarity search — challenges an assumption so deeply embedded in the retrieval literature that it has gone unquestioned for decades: that relevance is fundamentally a numerical relationship between queries and documents that must be learned from labeled examples. HyDE demonstrates that this assumption is not necessary. It shows that an instruction-following LLM, prompted to "write a passage to answer the question," produces text that captures the vocabulary, structure, and topical orientation of a relevant document well enough that a simple document-similarity encoder can retrieve real documents as effectively as models trained on 500,000+ labeled query-document pairs.

This reframing changes the landscape in several specific ways:

It separates relevance from retrieval architecture. In the standard dense retrieval paradigm (DPR, ANCE, ContrieverFT), relevance is learned as a property of the embedding space itself — the query encoder and document encoder are jointly optimized so that their inner product correlates with relevance judgments. This tightly couples the notion of relevance to the specific architecture and training procedure. HyDE decouples them: relevance is captured by a separate generative model through the act of producing document-like text, and retrieval is reduced to document-document similarity, which can be learned without any relevance labels at all. This decoupling means that improvements to the generative model (better LLMs, better instruction following, better domain adaptation through prompting) and improvements to the encoder (better contrastive objectives, larger models, better multilingual representations) can proceed independently. A stronger LLM improves HyDE without any change to the encoder; a stronger encoder improves HyDE without any change to the LLM. The result in Table 4, where InstructGPT + ContrieverFT achieves 67.4 NDCG@10 on DL19 — exceeding ContrieverFT alone (62.1) — demonstrates empirically that the components are complementary and additive.

It resolves the contradiction between "unsupervised dense retrieval is possible" and "unsupervised dense retrieval underperforms BM25." Prior to HyDE, the best unsupervised dense retriever (Contriever) was arguably worse than BM25 on several important benchmarks — DL19, DL20, and TREC-COVID all showed Contriever trailing BM25 by meaningful margins. This created a tension in the literature: contrastive pre-training produced semantically meaningful document representations, but those representations did not translate into retrieval effectiveness when queries were encoded directly. HyDE resolves this tension by showing that the encoder's document representations are in fact excellent — the problem was never the encoder quality, but rather the form mismatch between queries (short questions, claims, topics) and documents (extended passages). By transforming queries into the form of documents through generation, HyDE unlocks the latent retrieval capability that was already present in the contrastive encoder but inaccessible through direct query encoding. The jump from Contriever's 44.5 NDCG@10 on DL19 to HyDE's 61.3 using the exact same encoder makes this diagnosis explicit: the encoder was capable all along, but it needed queries to look like documents.

It makes the true zero-shot setting practical in a way that prior work did not. Before HyDE, "zero-shot dense retrieval" in the BEIR tradition meant transfer learning from MS-MARCO — a setting that is only "zero-shot" relative to the target task but relies on massive relevance supervision from a different task. HyDE achieves competitive or superior performance to those MS-MARCO-transferred models on BEIR (Table 2: HyDE outperforms ANCE and DPR on 5 of 6 datasets) without using a single relevance label from any source. This means that the commercial and legal restrictions on MS-MARCO that the authors cite (Section 1: "MS-MARCO restricts commercial use and cannot be adopted in a variety of real-world search scenarios") are no longer a barrier to building a competent dense retriever. A practitioner can deploy HyDE on a new domain with zero relevance labels, zero access to MS-MARCO, and only the effort of writing a one-sentence instruction for the LLM. This is not an incremental improvement over transfer learning — it is a categorically different deployment model.

It redirects research attention from retrieval architecture to generative model quality and instruction design. The paper's finding that larger generative models produce monotonically better HyDE embeddings (Table 4: 11B FLAN-T5 → 48.9, 52B Cohere → 53.8, 175B InstructGPT → 61.3 NDCG@10 on DL19) shifts the research bottleneck. Until now, retrieval research has focused heavily on architectural innovations — better negative mining, better distillation, better pre-training objectives, multi-vector representations. HyDE suggests that with a sufficiently strong generative model, even a simple contrastive encoder (Contriever, which is architecturally straightforward) can achieve results competitive with the most sophisticated supervised retrievers. The implication is that the highest-leverage investment for improving zero-shot retrieval may not be in better retrieval architectures at all, but in better instruction-following LLMs and better instruction design. The paper's observation that FiQA and DBPedia performance may be limited by "under-specification of the instruction" directly points to instruction engineering as a new retrieval research sub-area.

It makes generative retrieval approaches that require specialized training less attractive. The paper explicitly contrasts HyDE with generative retrieval models like DSI (Tay et al., 2022) and autoregressive search engines (Bevilacqua et al., 2022), which require "special training procedures over relevance data" and "novel forms of search indices." HyDE achieves strong zero-shot results using standard MIPS indices and frozen models. This raises the bar for generative retrieval: a new generative retrieval method must now demonstrate that its specialized training and index structures provide benefits over simply using a frozen LLM + frozen encoder, which is architecturally simpler, requires no training, and already approaches supervised performance on many benchmarks.

Follow-Up Research This Work Enables

1. Instruction optimization as a retrieval hyperparameter — automated search over instruction templates per task or per query. The paper uses hand-written instructions for each dataset (Appendix A.1) and notes that FiQA and DBPedia may suffer from "under-specification of the instruction." A direct follow-up would treat instruction text as a tunable hyperparameter and measure the variance in retrieval quality across instruction variants. For a fixed task (e.g., FiQA), a researcher could systematically vary the instruction — "write a financial article passage," "write a passage about finance," "write an investment analysis," "write a market report" — and measure NDCG@10 for each variant. This would quantify how sensitive HyDE is to instruction phrasing and whether optimal instructions can be found through grid search, LLM-based instruction generation (prompting an LLM to suggest alternative instructions), or gradient-based optimization (if using an open-source generator where the instruction embedding can be tuned). The result would either demonstrate that instructions matter substantially (validating instruction design as a new retrieval research area) or that HyDE is surprisingly robust to instruction variation (which would simplify deployment).

2. A direct test of the hallucination-filtering hypothesis through controlled perturbation experiments. The paper claims the contrastive encoder's bottleneck filters out hallucinated details, but provides no direct evidence (see Section 6). A strong follow-up would generate hypothetical documents and then systematically perturb them to test what the encoder preserves. Specifically: (a) generate N hypothetical documents for a set of queries; (b) create perturbed versions by replacing factual details (dates, numbers, named entities) with plausible alternatives; (c) measure the cosine similarity between the original and perturbed embeddings. If the hypothesis is correct, the cosine similarity should remain high (e.g., >0.95), indicating the encoder is invariant to factual perturbations. (d) Additionally, compare retrieval quality using original vs. perturbed documents as HyDE queries. If NDCG@10 remains stable under perturbation, the hallucination-filtering claim is validated and the property is quantified. If retrieval degrades, then factual errors do matter and the mechanism is weaker than claimed. This experiment would not require new models — it can be run on the existing HyDE pipeline with the BEIR datasets, using an off-the-shelf entity replacement tool or LLM-based perturbation.

3. HyDE + BM25: quantifying the contribution of the dense encoder by replacing it with lexical retrieval. The paper never tests whether the hypothetical document text, used directly as a BM25 query, performs comparably to the HyDE dense pipeline (see Section 6.6). A follow-up would run this baseline on all 11 query sets: feed the generated hypothetical document(s) as the query string to BM25, and measure NDCG@10 and Recall. Several variants should be tested: (a) single generated document as BM25 query; (b) concatenation of multiple generated documents as BM25 query; (c) each generated document as a separate BM25 query with result fusion (e.g., CombSUM or reciprocal rank fusion). If any of these variants matches or approaches HyDE's dense retrieval performance, it would demonstrate that the LLM generation alone is providing most of the benefit and that the dense encoder is not essential — a finding that would simplify deployment (BM25 is faster, cheaper, and more interpretable) and reframe HyDE as primarily a query expansion method rather than a dense retrieval method. If BM25 variants substantially underperform HyDE, the dense bottleneck's contribution is validated and the hallucination-filtering claim gains indirect support.

4. Dynamic N: adaptive generation budget conditioned on query difficulty or generation diversity. The paper uses a fixed but unreported number of generated documents N for all queries. Section 3.2 acknowledges that HyDE assumes a uni-modal distribution, and ambiguous queries are left to future work. A follow-up would implement adaptive sampling: for each query, generate K initial documents (e.g., K = 3), measure the pairwise cosine similarity or variance of their embeddings, and use this as a diversity signal. If the variance is low (documents are similar — uni-modal), use few additional samples or stop; if variance is high (documents diverge — multi-modal, implying ambiguity), either generate more samples to better approximate each mode, or fall back to a different strategy (e.g., cluster the documents, retrieve separately for each cluster, and merge results). This would directly address the untested ambiguity assumption and potentially improve performance on ambiguous queries, which are common in web search and entity retrieval. The experiment should be evaluated on the TREC DL datasets (where naturalistic web queries may be ambiguous) and DBPedia-Entity (where entity names can be ambiguous, e.g., "Michael Jordan"), comparing fixed-N HyDE against adaptive-N HyDE at matched average generation cost.

5. HyDE with truly unseen domains: temporal holdout and specialized technical corpora. The paper tests HyDE on standard benchmarks where the LLM has almost certainly seen related text during pre-training. A critical stress test would evaluate HyDE on queries where the LLM has no relevant knowledge: (a) temporal holdout — queries about events occurring after the LLM's training cutoff (e.g., for InstructGPT, events in 2022–2023), where generated documents would be entirely speculative; (b) highly specialized technical domains — e.g., retrieval over a corpus of specialized legal opinions, protein interaction papers, or hardware datasheets — where the LLM lacks the vocabulary and knowledge to generate plausible documents. The prediction: if the LLM has no knowledge of the domain, its generated documents will be generic or wrong, and retrieval quality will degrade toward (or below) Contriever's baseline. If HyDE still outperforms Contriever, it suggests the generation acts as a robust query reformulation even without factual knowledge. This experiment would establish the boundary conditions for HyDE's applicability and determine whether it can serve as a cold-start solution for genuinely novel domains or only for domains represented in the LLM's training data.

6. The cost curve of HyDE: N vs. retrieval quality for open-source and API-based generators. Given the paper's unreported N, a practical follow-up would generate cost-quality curves for HyDE across a range of N (1, 2, 4, 8, 16, 32) and across generator types: (a) a free, locally-run model (e.g., FLAN-T5-xxl on consumer hardware, or a smaller distilled model like FLAN-T5-large); (b) a paid API model (InstructGPT, with token costs reported); (c) a retrieval-augmented generator (LLM + a basic retrieval step to ground generation, testing whether factual grounding improves HyDE). For each, measure NDCG@10 on DL19/20 and BEIR, and report latency (ms/query), tokens generated, and financial cost (if applicable). This would produce the first pragmatic deployment guide for HyDE, answering: at what N do diminishing returns set in? Is a single generated document (N=1) sufficient, or is averaging critical? Can a locally-run 11B model with large N match a single call to a 175B API model? These curves would directly inform practitioner decision-making and address the paper's largest practical gap.

Practical Applications and Downstream Use Cases

1. Cold-start retrieval for new enterprise search systems without labeled data. When an organization deploys a new search system over internal documents — corporate wikis, legal document repositories, technical documentation, customer support tickets — there are typically zero relevance labels available on day one. Collecting labels requires either hiring domain experts (expensive, slow) or waiting for user interaction data to accumulate (which requires the search system to already be somewhat functional — a chicken-and-egg problem). HyDE provides an immediately deployable solution: write a one-sentence instruction describing the document type (e.g., "write a technical support article that answers the question"), point HyDE at the corpus, and start serving queries. The paper's results suggest that on the first day of operation, HyDE would achieve NDCG@10 of 57–61 on web-like search (Table 1) and 46–69 on specialized tasks (Table 2, Arguana to SciFact), which is competitive with what a fully supervised system would achieve after collecting and labeling thousands of examples. As the search log grows and click data accumulates, a supervised model can be trained to gradually replace or augment HyDE, following the deployment strategy outlined in the paper's conclusion: "as the dense retriever grows stronger, more queries will be routed to it, with only less common and emerging ones going to HyDE backend."

2. Multilingual retrieval deployment without per-language training data. The paper demonstrates that HyDE with mContriever improves retrieval on Swahili, Korean, Japanese, and Bengali (Table 3), with the largest relative gains on Japanese (+57.4% MRR over mContriever) and Korean (+37.2%). For an organization deploying search across multiple languages — particularly lower-resource languages where labeled training data is scarce or non-existent — HyDE offers a single system that works across languages by changing only the instruction text (e.g., "write a passage in Japanese to answer the question in detail"). The language-specific instruction handles the LLM's output language, while mContriever handles cross-lingual embedding alignment. The gains are not uniform — Swahili still shows a 9.5-point MRR gap to fine-tuned mContrieverFT — but for languages where even a transfer-trained supervised model is unavailable (mDPR achieves 7.3 MRR on Swahili vs. HyDE's 41.7), HyDE represents a step change in what is achievable without any in-language relevance data.

3. Rapid prototyping of retrieval systems for research and benchmarking. A common workflow in retrieval research involves setting up a baseline retriever for a new dataset to assess the difficulty of the task, the quality of the corpus, or the ceiling for proposed methods. Traditionally, this requires either training a model on MS-MARCO and hoping it transfers, or using BM25 (which may not capture the semantic relationships of interest). HyDE offers a third option: with no training time, no data preparation beyond indexing the corpus with Contriever, and only a few minutes of instruction writing, a researcher can obtain retrieval quality that often exceeds MS-MARCO-transferred models (e.g., on SciFact, HyDE achieves 69.1 NDCG@10 vs. ANCE's 50.7 and DPR's 31.8, Table 2). This dramatically lowers the barrier to entry for retrieval experiments on new datasets and makes it feasible to include a strong zero-shot dense baseline in any retrieval evaluation.

4. Query-side domain adaptation without model retraining for multi-tenant search platforms. A search platform serving multiple clients (each with their own document corpus and domain — e.g., one client's legal documents, another's medical guidelines, another's product manuals) traditionally requires either training separate retrieval models per client or accepting degraded performance from a one-size-fits-all model. HyDE's instruction-based domain adaptation provides a lightweight alternative: each client's search endpoint is configured with a different instruction string (e.g., "write a legal memorandum that answers the question" vs. "write a medical guideline that answers the question"), while the underlying LLM and encoder are shared across all clients. No per-client training, no per-client index modification, and no data leakage between clients is required — the domain adaptation is entirely encapsulated in the instruction text. The paper's results across SciFact, TREC-COVID, FiQA, DBPedia, and TREC-NEWS (Table 2), each using a different instruction, demonstrate the feasibility of this approach: the same frozen models, with only the instruction string varying, achieve competitive retrieval across scientific papers, biomedical literature, financial articles, entity descriptions, and news articles.