22 — HyDE (Hypothetical Document Embeddings)

Answer:

HyDE (Hypothetical Document Embeddings) (Gao et al., 2022) is a query-transformation technique for dense retrieval. Instead of embedding the user's query directly, it:

1. Asks an LLM to generate a hypothetical document that answers the query.
2. Embeds that hypothetical document (not the query).
3. Retrieves real documents nearest to the hypothetical's embedding.

Standard dense retrieval:
  query → embed(query) → nearest docs

HyDE:
  query → LLM generates hypothetical answer → embed(hypothetical) → nearest docs

The problem it solves — query/document asymmetry:

A query and the documents that answer it look very different:

• Query: "How do I fix a memory leak in Python?" (short, interrogative)
• Answer doc: "Memory leaks in Python applications often arise from lingering references in long-lived objects. Use tracemalloc to profile allocations and gc to inspect..." (long, declarative, rich with answer vocabulary)

In embedding space, the short question sits far from the dense, declarative answer passages. HyDE's hypothetical document looks like a real answer, so its embedding lands in the same neighborhood as genuine answer passages — even though the hypothetical may contain factual errors.

Key insight: the hypothetical doesn't need to be correct — it needs to be answer-shaped, so it embeds near real answers.

Two more examples of the same mechanism:

• Query: "How does reinsurance affect claim payouts?" Step 1 — the LLM generates a hypothetical answer: "Reinsurance allows an insurer to transfer part of the risk of a claim to a reinsurer, which affects payout timing and the insurer's net liability. Common mechanisms include quota share and excess-of-loss treaties..." Step 2 — that hypothetical passage, not the original short query, is embedded. Step 3 — similarity search finds real documents whose embeddings are close to that richer, document-like passage, often outperforming a search on the terse original query.
• Query: "agentic RAG benefits" — a direct embedding of those three words is thin and ambiguous. HyDE instead generates a paragraph-length hypothetical answer about agentic RAG's benefits, and that fuller embedding retrieves much more relevant chunks than the bare keywords would.

Answer:

It works because of how the embedding space is structured and what the embedding model was trained on:

1. Document-document similarity is stronger than query-document similarity. Embedding models place semantically similar documents close together. A hypothetical answer is a document, so it sits near real answer documents — a more reliable signal than question-to-answer matching.

2. It closes the lexical/structural gap. The hypothetical introduces the vocabulary and phrasing of an answer (tracemalloc, gc.collect(), "lingering references") that the bare question lacks. Retrieval keys off that answer vocabulary.

3. It expands a sparse query into a dense representation. A 6-word question carries little signal; a 100-word hypothetical answer is a much richer embedding, averaging over many relevant concepts.

The formal framing from the paper: HyDE factorizes retrieval into (a) an instruction-following generative step that produces a relevance-bearing document, and (b) a document-similarity step. Even an "unsupervised" contrastive encoder — never trained on relevance labels — becomes an effective retriever because it only has to do what it's good at: document-to-document similarity. The hard "understand the query's intent" part is offloaded to the LLM.

Why errors don't ruin it: the contrastive encoder acts as a lossy compressor that grounds the hypothetical back to the real corpus — hallucinated specifics get washed out, while the correct topic/structure drives retrieval to real passages.

Answer:

Step 1 — Generate hypothetical document
  Prompt: "Write a passage that answers the question: {query}"
  Query: "What are the side effects of metformin?"
  LLM → "Metformin commonly causes gastrointestinal side effects including
         nausea, diarrhea, and abdominal discomfort. A rare but serious
         risk is lactic acidosis..."  (may contain errors — that's OK)

Step 2 — Embed the hypothetical document
  v = encoder.embed(hypothetical)        # NOT embed(query)

Step 3 — Retrieve real documents
  top-k = vector_store.search(v, k=10)   # nearest REAL passages

Step 4 — Generate the final answer
  answer = llm(query + top-k real docs)  # grounded in real corpus

Code skeleton:

HYDE_PROMPT = "Write a detailed passage that answers the question.\nQuestion: {q}\nPassage:"

def hyde_retrieve(query, llm, encoder, store, k=10):
    hypothetical = llm.invoke(HYDE_PROMPT.format(q=query))
    vec = encoder.embed(hypothetical)         # embed the hypo, not the query
    return store.search(vec, k=k)

def hyde_rag(query, llm, encoder, store):
    docs = hyde_retrieve(query, llm, encoder, store)
    return llm.invoke(GEN_PROMPT.format(query=query, context=docs))

Common enhancement — multiple hypotheticals: generate N hypothetical answers (sampling with temperature), embed each, and average the embeddings (or retrieve per-hypo and fuse). Averaging cancels the noise of any single hallucinated hypothetical, stabilizing the retrieval vector.

Answer:

All three transform the query before retrieval, but differently:

The crucial distinction — question space vs. answer space:

• Query rewriting and RAG-Fusion stay in question space — they produce better/more questions, still embedding interrogative text.
• HyDE jumps to answer space — it embeds text that looks like the target documents.

They compose: generate N reformulations (Fusion) → produce a HyDE hypothetical for each → embed and fuse with RRF. This combines recall breadth (Fusion) with the asymmetry fix (HyDE) — at N× the generation cost.

Answer:

HyDE is not universally beneficial. It degrades retrieval when:

1. Niche / low-resource domains the LLM doesn't know If the LLM can't produce a plausible answer (proprietary jargon, very recent events, specialized internal systems), the hypothetical is generic or wrong-topic — and embeds away from the real answers. HyDE assumes the model can write an answer-shaped passage.

2. Entity-specific / factoid lookups "What is the account balance for invoice #4471?" — there's no meaningful hypothetical to generate; the answer is a specific datum. HyDE adds latency with no benefit (and may inject misleading specifics).

3. Strong retriever + matched query distribution When the encoder is already fine-tuned on in-domain query-document pairs (supervised), the asymmetry HyDE fixes is already handled. HyDE's biggest gains are with unsupervised/zero-shot encoders and out-of-domain queries.

4. Hallucination steers retrieval off-topic If the hypothetical confidently invents a wrong topic (misreads the query), it embeds near the wrong cluster — worse than the raw query. (Multi-hypothetical averaging mitigates but doesn't eliminate this.)

5. Latency-critical paths HyDE adds a full generation call before retrieval (+300–800ms). For tight SLAs on simple queries, that cost isn't justified.

Guardrail: treat HyDE as adaptive — gate it on query type (skip for entity lookups), or retrieve with both the hypothetical and the raw query and fuse, so a bad hypothetical can't fully break retrieval.

Answer:

The hypothetical should mimic the style, length, and vocabulary of your corpus documents, because retrieval is document-to-document similarity.

Prompt design principles:

1. Match corpus document type. If the corpus is scientific abstracts, prompt for an abstract; if it's support articles, prompt for a support-style passage:

   "Write a short scientific abstract that answers: {query}"
   "Write a help-center article passage that answers: {query}"
   

2. Control length to match chunk size. A hypothetical far longer/shorter than your chunks embeds differently. Aim for roughly one chunk's worth of text.

3. Encourage answer vocabulary, not hedging. You want concrete answer-like terms. Avoid "I'm not sure, but..." preambles — they're question-space noise. Instruct: "Write as if you are an expert answering directly."

4. Domain instruction for specialized corpora. "Using medical terminology, write a passage that..." nudges the hypothetical toward the corpus's vocabulary.

5. Sample multiple, average. Temperature > 0, generate N=3–5, average embeddings to reduce single-draft variance.

Example template:

HYDE_PROMPT = """You are an expert writing reference documentation.
Write one concise {doc_style} passage (~120 words) that directly answers
the question, using precise domain terminology. Do not hedge.

Question: {query}
Passage:"""

Anti-pattern: prompting for a list of search keywords — that pulls you back into sparse query space and defeats HyDE's purpose (which is to produce a dense, answer-shaped document).

Answer:

Cost/latency breakdown vs. standard RAG:

Standard RAG:  embed(query) [~10ms] + retrieve [~50ms] + generate [~800ms]
HyDE:          generate hypo [+300–800ms] + embed + retrieve + generate
               → essentially adds one LLM generation BEFORE retrieval

HyDE roughly doubles the LLM calls (one to draft the hypothetical, one to answer) — the dominant added cost.

Optimizations:

1. Small/fast model for the hypothetical. The hypothetical only needs to be answer-shaped, not correct — a fast model (Haiku, 8B) suffices. Reserve the frontier model for the final grounded answer.

2. Cap hypothetical length. Generation time scales with output tokens; ~100–150 tokens is enough to embed well.

3. Cache hypotheticals. Semantically similar queries can reuse a cached hypothetical embedding (semantic cache).

4. Adaptive activation. Only invoke HyDE for query types that benefit (open-ended, vocabulary-mismatched); skip for entity lookups — saves the extra call on most traffic.

5. Single hypothetical by default. Multi-hypothetical averaging improves robustness but multiplies cost linearly; start with N=1 and add only if eval shows instability.

6. Stream-overlap (limited). Unlike multi-query, you can't parallelize across hops, but you can start embedding as soon as the hypothetical finishes streaming.

Bottom line: HyDE's cost is the extra generation. Pushing that onto a cheap model + gating it adaptively recovers most of the latency budget.

Answer:

HyDE's benefit is conditional (encoder, domain, query type), so always A/B it on your data rather than assuming the paper's gains transfer.

Evaluation plan:

1. Stratify the eval set by query type, because HyDE helps unevenly:

   • Open-ended conceptual ("how does X work?") — HyDE expected to help.
   • Entity/factoid lookups ("invoice #4471 balance") — HyDE expected to hurt/no-op.
   • Out-of-domain vs. in-domain — HyDE helps more out-of-domain.

2. Retrieval metrics (primary): Recall@k, MRR, NDCG@10 — HyDE vs. raw-query baseline, per stratum. HyDE's effect is on retrieval, so measure there first.

3. End-to-end: answer correctness + faithfulness, to confirm retrieval gains translate to better answers.

4. Cost-adjusted comparison: report the retrieval lift alongside the added latency/$ — a small Recall gain may not justify doubling LLM calls.

5. Ablations:

   • HyDE vs. HyDE+raw-query fusion (does hedging help?).
   • N hypotheticals (1 vs 3 vs 5) — does averaging help enough to justify cost?
   • Small vs. large model for the hypothetical (quality vs. cost).

Expected pattern (from literature + practice): large gains for zero-shot/unsupervised encoders and out-of-domain queries; diminishing or negative returns when you have a fine-tuned in-domain retriever (it already handles the asymmetry).

Answer:

This is the key to knowing when HyDE earns its keep.

Zero-shot / unsupervised encoders (HyDE's home turf):

• These encoders are trained on document-document similarity (or general contrastive objectives), not on in-domain query→document relevance pairs.
• They handle the query/doc asymmetry poorly. HyDE bridges this gap by converting the query into a document — so the encoder only does what it's good at.
• Result: HyDE provides large, sometimes dramatic gains here. The original paper's headline result is HyDE making an unsupervised encoder competitive with fine-tuned retrievers, with no relevance labels.

Fine-tuned / supervised retrievers:

• These are explicitly trained on (query, relevant-doc) pairs, so they've learned to map queries into the document neighborhood — the very gap HyDE fixes.
• HyDE's marginal benefit shrinks, and the extra generation can even add noise.
• Result: often neutral-to-negative; the asymmetry is already handled by training.

Practical decision rule:

Framing: HyDE is, in effect, a label-free substitute for retriever fine-tuning. If you can afford to fine-tune on in-domain pairs, that's usually the stronger long-term fix; HyDE is the high-leverage move when you can't.

Answer:

HyDE is especially powerful cross-lingually, because the LLM can generate the hypothetical in the corpus language, bridging both the query/doc asymmetry and the language gap.

USE CASE: Users query in many languages; corpus is primarily English
          technical documentation.
PROBLEM: Cross-lingual dense retrieval is weak — a Spanish query embeds
         far from English answer passages even with multilingual encoders.

HyDE CROSS-LINGUAL PIPELINE
───────────────────────────
1. Detect query language (e.g., Spanish): "¿Cómo configuro la autenticación OAuth?"

2. Generate hypothetical IN THE CORPUS LANGUAGE (English):
     Prompt: "Write an English documentation passage that answers
              this question: {query}"
     → "To configure OAuth authentication, register your application
        to obtain a client ID and secret, then set the redirect URI..."
   This simultaneously TRANSLATES intent and produces answer-shaped text.

3. Embed the English hypothetical → retrieve English docs (now same language space)

4. Generate the final answer in the USER'S language, grounded in retrieved English docs.

WHY THIS BEATS naive multilingual retrieval
────────────────────────────────────────────
- The hypothetical lands in the SAME language + answer space as the corpus,
  so similarity is monolingual doc-to-doc (the encoder's strength).
- No separate translation system needed — the LLM does query translation
  and answer-shaping in one step.

ENHANCEMENTS
────────────
- Multi-hypothetical: generate hypotheticals in corpus language + user language,
  embed both, fuse — covers corpora with mixed-language content.
- Adaptive: skip HyDE for exact-match queries (product codes, error IDs)
  that are language-agnostic.

GUARDRAILS
──────────
- Low-resource query languages: validate the LLM can translate+answer; fall
  back to multilingual-encoder retrieval on the raw query if hypothetical quality is low.
- Always also retrieve on a translated raw query and fuse, so a bad hypothetical
  doesn't break retrieval.

MONITORING
──────────
- Recall@k per source language (catch languages where HyDE underperforms)
- Hypothetical language-correctness rate

The core trick: HyDE turns cross-lingual retrieval into monolingual document similarity by generating the hypothetical in the corpus language — folding translation and asymmetry-bridging into a single generation step.

Answer:

Yes — HyDE is a retrieval-stage transformation and composes cleanly with the rest of the stack.

HyDE + hybrid search (dense + sparse):

• HyDE improves the dense leg (embed the hypothetical).
• For the sparse/BM25 leg, the hypothetical also helps — it contributes answer-vocabulary keywords the raw query lacks. So embed the hypothetical for dense and optionally use it (or its key terms) for BM25.
• Fuse dense + sparse results with RRF.

query → hypothetical
   ├─ dense:  embed(hypo) → ANN search
   └─ sparse: BM25(hypo terms) or BM25(query)
   → RRF merge

HyDE + reranking:

• HyDE improves recall (gets the right docs into the candidate set); a cross-encoder reranker improves precision (reorders them).
• They're complementary: HyDE fixes "the relevant doc wasn't retrieved"; reranking fixes "it was retrieved but ranked low."
• Important: rerank with the original query (or query+hypo), not the hypothetical alone — the reranker should score relevance to the user's actual question, and cross-encoders handle query-doc asymmetry well (no HyDE needed there).

Full stack:

query → HyDE hypothetical → hybrid retrieval (dense+sparse) → RRF
      → cross-encoder rerank (on original query) → top-k → generate

Why this layering works: HyDE addresses the bi-encoder's asymmetry weakness at recall time; the cross-encoder reranker, which jointly encodes query+doc, doesn't have that weakness and should see the true query. Each component fixes a distinct failure.

Answer:

The theoretical framing (from the paper): HyDE reframes zero-shot dense retrieval as two decoupled subproblems:

1. Generative relevance modeling — an instruction-following LLM maps the query to a relevance-bearing document f(query) → hypothetical. This is where "understanding the query's intent" happens.
2. Document similarity — a contrastive encoder g maps documents to a space where sim(g(hypo), g(real_doc)) captures relevance. This is a purely unsupervised operation.

The encoder g is treated as a lossy compressor / denoiser: it projects the (possibly hallucinated) hypothetical back onto the manifold of real corpus documents. Incorrect details that don't correspond to any real document get "filtered out," while the correct topical/structural signal survives and drives retrieval.

What HyDE reveals about dense retrieval:

1. Query-document asymmetry is a first-class problem. Bi-encoders struggle because queries and documents are different distributions; document-document similarity is far more reliable. HyDE exploits this asymmetry rather than fighting it.

2. Relevance labels can be replaced by generation. The supervised signal that fine-tuning provides (which docs are relevant to which queries) can be synthesized by an LLM writing a relevant document — trading labeled data for generation compute.

3. Grounding tolerates hallucination. A surprising lesson: a factually wrong hypothetical still retrieves correct documents, because retrieval keys on topical/structural similarity, and the real corpus anchors the result. This decoupling of "fluency" from "factuality" is why HyDE is robust.

4. It's an instance of "query → pseudo-document" expansion, connecting modern dense retrieval back to classic IR pseudo-relevance-feedback ideas — but with an LLM generating the pseudo-document instead of mining it from top results.

Implication for system design: if your encoder is unsupervised/zero-shot, you can buy much of the benefit of a fine-tuned retriever by spending LLM tokens at query time — a compute-for-labels trade.

Answer:

Query → LLM generates a hypothetical answer document (no retrieval yet)
      → Embed the hypothetical document (NOT the original query)
      → ANN search using that embedding
      → Retrieved real passages → Generator uses the REAL passages
        (the hypothetical document is discarded after retrieval)

The critical detail visible in this diagram, easy to miss on a first read, is that the hypothetical document is used only to compute an embedding for retrieval — it never reaches the final generation step, and its factual accuracy is irrelevant to the final answer's accuracy (Q12's "grounding tolerates hallucination" finding). This is what makes HyDE simultaneously simple to add to an existing pipeline (it's a query-side, single-LLM-call preprocessing step) and robust to the LLM's own knowledge gaps, since a fabricated but topically-appropriate hypothetical document still retrieves the right real evidence.

Answer:

HyDE was introduced by Gao et al., Precise Zero-Shot Dense Retrieval without Relevance Labels (arXiv:2212.10496, 2022) — the paper's title emphasizes its core contribution precisely: achieving strong dense retrieval performance without any labeled relevance data or fine-tuning of the retriever, by using an LLM's generative capability to bridge the query-document gap instead.

The paper's headline result is that HyDE, paired with an entirely off-the-shelf, unsupervised contrastive encoder (Contriever), matched or exceeded fine-tuned dense retrievers on several retrieval benchmarks — a notable finding because it decouples strong retrieval performance from the expensive labeled-data-and-fine-tuning investment that dense retrievers (DPR, #38) otherwise require, trading it for LLM inference cost at query time instead (Q7's latency/cost profile).

Answer:

Both use an LLM to generate auxiliary text that improves retrieval, but at opposite ends of the pipeline (drawn out from Contextual Retrieval's own side, #14 Q15). HyDE intervenes at query time, generating a hypothetical answer fresh for every query and using it only for that one query's retrieval — no change to the index. Contextual Retrieval intervenes at index time, generating a context prefix for every chunk once, permanently changing what's stored and embedded in the index, with zero additional LLM calls at query time.

The two are complementary rather than competing: HyDE closes the query-document vocabulary gap regardless of how the corpus is indexed; Contextual Retrieval closes the chunk-ambiguity gap regardless of how the query is phrased. A production system could run both simultaneously — HyDE-generated hypothetical documents queried against a Contextual-Retrieval-indexed corpus — since neither technique's mechanism depends on or interferes with the other.

Answer:

The distinctive mechanism is embedding an LLM-generated hypothetical answer instead of the literal query text, exploiting the fact that a hypothetical answer, however fabricated, is written in the same style and vocabulary as the real documents it's trying to find — while a raw query is typically short, interrogative, and phrased very differently from the declarative prose it's searching for. Standard query embedding assumes the embedding model can bridge this stylistic gap directly; HyDE instead has the LLM do that bridging explicitly, by generating text that already looks like a document rather than a question.

This single substitution is what Q12's theoretical framing describes as "query → pseudo-document expansion" — a direct descendant of classic pseudo-relevance-feedback ideas in information retrieval, except the pseudo-document is generated by an LLM's parametric knowledge rather than mined from an initial retrieval pass's top results, which is why HyDE works even for genuinely zero-shot retrieval where no initial results exist yet to mine feedback from.

Answer:

The hypothetical document's style prompt is an under-appreciated knob relative to the others: since HyDE's whole mechanism depends on stylistic resemblance to real documents (Q16), a generic hypothetical-document prompt that doesn't match your corpus's actual register (e.g., generating conversational prose to search a corpus of formal legal text) can underperform even a raw query embedding, despite HyDE's generally strong reputation.

Answer:

Q12's own "grounding tolerates hallucination" finding explains why a factually wrong hypothetical usually still retrieves correctly — retrieval keys on topical and structural similarity, not factual correctness, and the real corpus anchors the final answer regardless of what the discarded hypothetical said. But this tolerance has a boundary: if the hypothetical's error is severe enough to shift its topic, not just a factual detail within a stable topic (for instance, hallucinating an entirely wrong entity name, date, or category rather than a wrong number within a correct topic), the resulting embedding can genuinely drift toward the wrong region of the corpus, and retrieval fails in a way "grounding tolerates hallucination" doesn't rescue.

Detection: for queries where HyDE underperforms raw-query retrieval on a labeled evaluation set (Q8), inspect the generated hypothetical documents specifically for topic-level (not just factual-detail-level) drift — a hypothetical about the wrong named entity or wrong general subject is the signature of this deeper failure, distinguishable from a merely factually-imprecise-but-topically-correct hypothetical that retrieval would tolerate fine. Mitigation: for domains where entity/topic-level hallucination is a known risk (obscure or rapidly-changing subject matter the generation model wasn't trained on well), consider generating multiple hypotheticals and averaging (Q17) to dilute the impact of any single generation's topic drift, or fall back to raw-query embedding when the generated hypothetical's own self-reported confidence is low.

Answer:

HyDE adds a full LLM generation call to every query's critical path (Q7) — for latency-sensitive deployments or very high query volume, this cost needs to be justified against the alternative of simply using a stronger or fine-tuned embedding model instead:

1. Build a golden set representative of your actual query distribution,
   including both short/interrogative queries (where HyDE's vocabulary-
   bridging benefit should be largest, per Q2) and already document-like
   queries (where HyDE should add little).

2. Baseline: raw-query embedding with your current retriever.
3. Candidate A: HyDE (raw query -> hypothetical -> embed hypothetical).
4. Candidate B (the key comparison HyDE decision gates often skip):
   a fine-tuned or simply stronger off-the-shelf embedding model,
   still embedding the raw query directly -- since Q12's own framing
   suggests HyDE is substituting compute for labeled fine-tuning data,
   the honest comparison is against paying that fine-tuning cost
   instead of paying HyDE's per-query LLM cost.

5. Compare accuracy, per-query latency, and total cost (ongoing
   per-query HyDE cost vs. one-time fine-tuning cost amortized over
   expected query volume) across all three.

6. Gate: choose HyDE if it clears baseline meaningfully AND is
   cost/latency-competitive with candidate B at your query volume;
   choose fine-tuning instead if volume is high enough that HyDE's
   recurring per-query cost exceeds a one-time fine-tuning investment
   within a reasonable payback period (the same volume-based logic
   used for every other fine-tune-vs-inference-time-technique decision
   in this bank).

The comparison against a fine-tuned retriever specifically (not just against a raw-query baseline) is the step most decision processes skip, but it's the more honest framing given Q12's own characterization of HyDE as a compute-for-labels trade — the real question is which side of that trade is cheaper for your specific query volume, not whether HyDE beats doing nothing.

Answer:

HyDE's added cost is one LLM generation call per query before retrieval even starts (Q7) — at scale, this is a straightforward multiplicative addition to standard RAG's cost structure: illustrative comparison at 1M queries/month, a cheap generation call averaging $0.0003/query for a short hypothetical document adds roughly $300/month in pure generation cost, plus the added latency of that call sitting in the critical path before retrieval can even begin (typically 100-300ms depending on model and hypothetical length, per this file's own Q7).

Controls: use the smallest/fastest model that produces topically-adequate hypotheticals (Q17), since factual accuracy doesn't matter for HyDE's mechanism to work (Q12) — this is one of the few LLM-call-in-the-pipeline decisions in this bank where quality requirements are genuinely lower than they might first appear; cache hypothetical-document embeddings for repeated or near-identical queries, the same semantic-caching pattern used throughout this bank (Naive RAG's #01 Q9); and apply conditional HyDE (skip it for queries that are already document-like or for which raw-query retrieval already performs adequately, detected via a cheap upfront heuristic or classifier) rather than paying HyDE's cost uniformly on every query regardless of whether that specific query actually needs the vocabulary-bridging benefit.

Answer:

The situation implies a small, low-traffic search tool, casual/vague user queries ("best time cheap flights europe"), and a corpus of blog-style posts written in a very different register than those queries — precisely the query-document asymmetry HyDE targets (Q1, Q2).

The straightforward approach is HyDE's simplest form: a single hypothetical document per query (no multi-hypothetical averaging, Q3's enhancement), generated by a fast/cheap model prompted to write in the corpus's actual blog-post style and length (Q6's style-matching guidance), then embedded and retrieved against as normal. At this traffic level there's no need for adaptive gating (Q5, Q7) that decides per-query whether HyDE is worth its cost — the added latency of one extra generation call is immaterial for a low-volume hobbyist-scale tool.

The trade-off worth flagging: a fabricated hypothetical can occasionally drift off-topic for a very niche or oddly-phrased query (Q5's hallucination-steers-retrieval-off-topic risk), and a small tool has no dedicated monitoring to catch this systematically. The cheap mitigation is to always retrieve on both the raw query and the hypothetical and fuse the results (Q4's RAG-Fusion-style hedge), so a single bad hypothetical doesn't fully override a reasonable raw-query result — a small addition worth the minor extra retrieval call.

Answer:

The hard constraints are a five-language cross-lingual gap combined with dense regulatory jargon (Q10's cross-lingual pattern, but now under formal audit requirements that Q10's own design didn't need to address), meaning every retrieval decision needs to be explainable after the fact, not just accurate at the time.

The approach follows Q10's cross-lingual HyDE pattern — generate the hypothetical in the corpus's language, collapsing translation and vocabulary-bridging into one step — but adds an audit layer on top: log the generated hypothetical, the retrieved real documents, and the final cited passages together for every query, explicitly labeling the hypothetical as a discarded, non-authoritative intermediate artifact rather than a source the answer relies on (Q13's "grounding tolerates hallucination" framing becomes something an auditor needs spelled out, not assumed). Validate hypothetical language-correctness per language pair (Q10's monitoring) and fall back to raw multilingual-encoder retrieval for the lower-resource languages where hypothetical quality is measurably weaker, rather than trusting HyDE uniformly across all five.

The real trade-off: audit logging a hallucination-prone intermediate artifact can itself raise auditor concern if it isn't framed correctly, so the mitigation isn't technical but presentational — the audit trail needs to make unambiguous that the hypothetical never reaches the compliance answer directly, only the real, cited documents it helped surface, exactly as Q13 already establishes for HyDE generally.

Monitor: recall@k per language pair, hypothetical language-correctness rate, and audit-log completeness (every query has its hypothetical, retrieved set, and final citations recorded) as a hard compliance gate, not just an operational nicety.