HyDE (Hypothetical Document Embeddings) 2022（ハイドハイポセティカルドキュメントエンベディングス2022）
Gao ら CMU 2022年 RAG 改良手法。LLM で仮想ドキュメント生成→そのembedding で検索→クエリ-ドキュメント間 vocabulary gap 解消
概要
HyDE（Hypothetical Document Embeddings）は 2022年12月にカーネギーメロン大学の Luyu Gao・Xueguang Ma・Jimmy Lin（Waterloo 大）・Jamie Callan が arXiv:2212.10496 で発表した RAG（Retrieval-Augmented Generation）改良手法（論文「Precise Zero-Shot Dense Retrieval without Relevance Labels」）。
従来 RAG は「ユーザクエリ → embedding → ベクトル検索」の単純フローで、クエリ（短文・口語）とドキュメント（長文・文書体）の embedding 空間が乖離する vocabulary gap 問題があった。HyDE は中間に「LLM で仮想ドキュメント生成」ステップを挟み、生成された仮想ドキュメントの embedding で検索することでこの問題を根本解決。BEIR ベンチマーク（11 タスク）で従来 Dense Retrieval（DPR・Contriever）を 20-40% 上回る Zero-shot 性能達成。
LangChain・LlamaIndex 等の主要 RAG フレームワークに採用され、現代 RAG パイプラインの標準テクニックとなった。論文では「relevance ラベルなし（教師なし）で SOTA」というインパクトが強く、その後の Self-RAG (2023)・CRAG (2024)・GraphRAG (2024) 等の系統研究の起点となった重要研究。
主な特徴・仕組み
- 3段階フロー: クエリ → LLM で仮想ドキュメント生成 → 仮想ドキュメント embedding でベクトル検索
- 仮想ドキュメント生成: GPT-3.5/4 等で「このクエリに答える理想的ドキュメント」を生成（150-300字）
- embedding モデル: Contriever / E5 / BGE 等の標準モデル使用、特別な fine-tune 不要
- vocabulary gap 解消: クエリ（短文）vs ドキュメント（長文）の語彙ギャップを LLM が橋渡し
- Zero-shot 性能: BEIR 11 タスク平均で従来手法 +20-40% 向上
- 計算コスト: 仮想ドキュメント生成 1回 + ベクトル検索 1回（標準 RAG 比 +1 LLM call）
- レイテンシ: 標準 RAG +200-500ms（LLM 仮想ドキュメント生成時間）
- 品質: 専門ドメイン・低リソース言語で特に効果大（汎用クエリでは差小）
- OS バージョン: 論文 v1 (2022-12)・各フレームワーク実装多数
スペック比較表
| 項目 | HyDE (2022) | 標準 RAG | BM25 | DPR (2020) |
|---|---|---|---|---|
| 仮想ドキュメント生成 | あり | なし | なし | なし |
| Zero-shot 性能 | 高 (+20-40%) | 中 | 中-低 | 中 |
| 計算コスト | 中 (LLM call +1) | 低 | 最低 | 低 |
| ラベル必要 | なし | なし | なし | あり (学習用) |
| 採用例 | LangChain, LlamaIndex | 標準 RAG | Elasticsearch | Facebook RAG |
具体例・対応製品
- LangChain HypotheticalDocumentEmbedder: 公式実装、3行で利用可
- LlamaIndex HyDEQueryTransform: LlamaIndex 標準サポート
- Haystack HyDERetriever: Haystack RAG パイプライン統合
- Vespa HyDE Use Case: Vespa.ai 公式ガイド、エンタープライズ検索向け
- Weaviate HyDE Integration: Weaviate.io コミュニティ実装
選び方・注意点
- 専門ドメイン RAG で効果大: 医療・法律・金融等の専門用語多用ドメインで +40% 向上報告
- 汎用 QA では差小: Wikipedia 系汎用 QA では +10-20% 程度、コスト見合いで判断
- LLM 選択: GPT-3.5 で十分（GPT-4 でも僅差）、Llama 3 8B 等の OSS でも実用可
- 仮想ドキュメント品質: hallucination リスクあるが、検索目的なので影響軽微
- レイテンシ問題: 200-500ms 増加、低レイテンシ要件には不向き
- マルチクエリ拡張併用: HyDE + RAG Fusion で更に性能向上可能
- キャッシュ重要: 同じクエリの仮想ドキュメント生成キャッシュで再呼出し節約
関連用語との違い
| 用語 | 違い |
|---|---|
| HyDE (2022) | 仮想ドキュメント生成で vocabulary gap 解消 |
| Self-RAG (2023) | 検索要否を LLM が動的判断 |
| CRAG (2024) | 検索結果の正確性評価 + Web 検索フォールバック |
| GraphRAG (2024) | ドキュメントをグラフ構造化 |
| LightRAG (2024) | グラフ + ベクトルハイブリッド軽量版 |
よくある質問（FAQ）
Q1: なぜ仮想ドキュメントの方が検索精度高い？ A: 短文クエリ（例「PostgreSQL の MVCC とは」）と長文ドキュメント（PostgreSQL 公式ドキュメント MVCC 章）は embedding 空間で離れている。LLM が「PostgreSQL の MVCC は MultiVersion Concurrency Control の略で、トランザクションごとに...」と長文化してから検索すると、ドキュメント側の embedding と近づく。
Q2: hallucination は問題ないか？ A: 検索目的なので影響軽微。仮想ドキュメントに事実誤認があっても、検索後の生成段階で正しい実ドキュメントを参照するため最終出力は正確。ただし仮想ドキュメントが完全に的外れだと検索失敗するリスクあり。
Q3: GPT-4 を仮想ドキュメント生成に使う価値は？ A: GPT-3.5 と GPT-4 で差は +5-10% 程度、コスト 20倍を考えると GPT-3.5 で十分。専門ドメインで GPT-4 が顕著に有利な場合のみ、コスト見合いで採用。
まとめ
- CMU 2022年12月発表・RAG 改良手法
- LLM で仮想ドキュメント生成 → embedding 検索
- vocabulary gap 解消で BEIR 11 タスク +20-40% 向上
- LangChain・LlamaIndex 等の主要フレームワーク採用
- Self-RAG・CRAG・GraphRAG 系統研究の起点