HyDE（Hypothetical Document Embeddings）は、質問をそのままベクトル検索に使うのではなく、まずLLMに質問への「仮の回答」を書かせ、その仮の回答のベクトルで資料を検索する方法です。2022年にGaoらが発表した論文で提案され、ACL 2023で発表されました。

Precise Zero-Shot Dense Retrieval without Relevance LabelsWhile dense retrieval has been shown effective and efficient across tasks and languages, it remains difficult to create effective fully zero-shot dense retrieval systems when no relevance label is available. In this paper, we recognize the difficulty of zero-shot learning and encoding relevance. Instead, we propose to pivot through Hypothetical Document Embeddings~(HyDE). Given a query, HyDE first zero-shot instructs an instruction-following language model (e.g. InstructGPT) to generate a hypothetical document. The document captures relevance patterns but is unreal and may contain false details. Then, an unsupervised contrastively learned encoder~(e.g. Contriever) encodes the document into an embedding vector. This vector identifies a neighborhood in the corpus embedding space, where similar real documents are retrieved based on vector similarity. This second step ground the generated document to the actual corpus, with the encoder's dense bottleneck filtering out the incorrect details. Our experiments show that HyDE significantly outperforms the state-of-the-art unsupervised dense retriever Contriever and shows strong performance comparable to fine-tuned retrievers, across various tasks (e.g. web search, QA, fact verification) and languages~(e.g. sw, ko, ja).arXiv.org（arxiv.org）

ただし、HyDEは現在では、まず最初に試す方法としてはあまり勧められていません。その理由は記事の後半で説明します。

埋め込みとベクトル検索の基本は、以前の記事で説明しています。

エンベディングとは | しがないRAG屋さんRAGの検索で使う埋め込み（ベクトル化）について、仕組み、近さの測り方、モデルの選び方をまとめます。しがないRAG屋さん（rag-ya-san.com）

何のために使うのか

ベクトル検索では、質問のベクトルと資料のチャンクのベクトルを比べます。しかし、質問と資料は文章の形が大きく違います。

  • 質問は短く、「〜は何日前まで？」のような問いかけの形
  • 資料は長く、「〜は取得日の3日前までに申請してください」のような説明の形

この違いのせいで、内容は合っていても、ベクトルが十分に近くならないことがあります。HyDEは、質問を「資料に書かれていそうな文章」に書き換えてから検索することで、この差を埋めようとする方法です。

どう動くのか

通常のベクトル検索とHyDEの違いは、検索に使うベクトルを何から作るかです。

通常のベクトル検索とHyDEの比較。通常は質問をそのまま埋め込みモデルでベクトルにして検索する。HyDEは質問からLLMで仮の回答を作り、その仮の回答をベクトルにして検索する

処理の流れを順番に書くと、次のようになります。

HyDEの処理の流れ。利用者の質問を受けたRAGアプリが、LLMに仮の回答を書かせ、それを埋め込みモデルでベクトルにしてベクトルデータベースを検索する。見つかった実際の資料のチャンクと質問をLLMに渡して、資料に基づく回答を作る

  1. 利用者の質問をLLMに渡し、「この質問に答える文章を書いて」と依頼する
  2. LLMが仮の回答を書く（この時点では、内容が正しくなくてもかまわない）
  3. 仮の回答を埋め込みモデルでベクトルにする
  4. そのベクトルに近いチャンクを、ベクトルデータベースから検索する
  5. 見つかった実際のチャンクと質問をLLMに渡し、資料に基づいて回答させる

仮の回答の内容が間違っていてもよい理由について、論文では、埋め込みモデルがベクトルに変換する段階で細かい誤りは薄まり、「どういう内容の文章か」という特徴が残るためだと説明しています。最終的な回答は、仮の回答ではなく、検索で見つかった実際の資料をもとに作ります。

現在の位置づけ：最初に試す方法としては勧められない

HyDEは、論文の発表当時は有効な方法として注目され、多くのRAGの解説で紹介されました。しかし現在は、次のような理由から、最初に試す方法としてはあまり勧められていません。

論文が想定していた状況との違い

論文のタイトルは「Precise Zero-Shot Dense Retrieval without Relevance Labels」で、検索用の学習データ（質問と正解文書の組）がない状況で、性能を上げることを目的としていました。比較の相手も、そうした学習データを使わずに作られた埋め込みモデル（Contriever）です。現在のRAGでは、検索用に学習された埋め込みモデルを使うことが一般的なので、HyDEで改善できる余地は論文の条件より小さい可能性があります。

応答が遅くなり、誤った情報が混ざることがある

HyDEは検索の前にLLMで文章を1回生成するため、その分だけ時間がかかります。2025年に発表された、小さなLLM（Gemma 1B・4B）で通常のRAGとHyDEを比べた研究では、HyDEは通常の方法より43〜60%遅くなりました。さらに、個人のプロフィール情報に関する質問では、HyDEを使った構成がすべての質問で、プロフィールにない日付や件数を作り出したと報告されています。

Assessing RAG and HyDE on 1B vs. 4B-Parameter Gemma LLMs for Personal Assistants IntegretionResource efficiency is a critical barrier to deploying large language models (LLMs) in edge and privacy-sensitive applications. This study evaluates the efficacy of two augmentation strategies--Retrieval-Augmented Generation (RAG) and Hypothetical Document Embeddings (HyDE)--on compact Gemma LLMs of 1 billion and 4 billion parameters, within the context of a privacy-first personal assistant. We implement short-term memory via MongoDB and long-term semantic storage via Qdrant, orchestrated through FastAPI and LangChain, and expose the system through a React.js frontend. Across both model scales, RAG consistently reduces latency by up to 17\% and eliminates factual hallucinations when responding to user-specific and domain-specific queries. HyDE, by contrast, enhances semantic relevance--particularly for complex physics prompts--but incurs a 25--40\% increase in response time and a non-negligible hallucination rate in personal-data retrieval. Comparing 1 B to 4 B models, we observe that scaling yields marginal throughput gains for baseline and RAG pipelines, but magnifies HyDE's computational overhead and variability. Our findings position RAG as the pragmatic choice for on-device personal assistants powered by small-scale LLMs.arXiv.org（arxiv.org）

仮の回答に含まれる誤りに検索が引っ張られると、関係のない資料が見つかることもあります。とくに、社内の固有の情報のように、LLMがもともと知らない内容ほど、仮の回答は的外れになりやすくなります。

ライブラリでも古い機能として扱われている

LangChainのHyDEの実装（HypotheticalDocumentEmbedder）は、LangChain v1で、古い機能をまとめた langchain-classic パッケージに移されました。公式の移行ガイドでは、このパッケージに移した機能を「Legacy code（古いコード）」と呼んでいます。

LangChain v1 migration guide - Docs by LangChainDocs by LangChain（docs.langchain.com）

なお、HyDEそのものを「非推奨」と明記した公式の文書は、調べた範囲では見つかりませんでした。ここでの「勧められない」は、上のような理由から、他の方法を先に試すほうがよいという意味です。

先に試したい方法

検索の精度を上げたい場合は、次の方法を先に試すのがおすすめです。

  1. ハイブリッド検索：キーワード検索とベクトル検索を組み合わせる
  2. リランキング：検索結果を精度の高いモデルで並べ替える
  3. 埋め込みモデルの見直し：日本語で評価の高いモデルに変える

それでも、質問が極端に短い・あいまいといった理由で検索がうまくいかない場合に、HyDEを候補の1つとして試します。その際は、前に説明した評価の仕組みを使って、本当に改善したかを確かめます。

RAGの評価とは | しがないRAG屋さんRAGの回答の良し悪しを測る方法について、検索と回答生成を分けて評価する考え方と、よく使われる指標をまとめます。しがないRAG屋さん（rag-ya-san.com）

注意点

  • 応答時間と費用が増える：質問ごとにLLMの呼び出しが1回増えます。
  • LLMが知らない分野では逆効果になりうる：仮の回答が的外れだと、検索も的外れになります。
  • 仮の回答を利用者に見せない：仮の回答は検索のためだけの文章です。そのまま回答として表示すると、誤った情報を伝えることになります。

HyDEは「質問と資料の文章の形の違いを埋める」という考え方を知るうえでは分かりやすい例です。ただ、実際のRAGに入れるかどうかは、評価の結果を見て判断するのが確実です。