RAG（検索拡張生成）

Retrieval-Augmented Generation。外部知識ベースの検索とLLM生成の統合。幻覚軽減と知識の動的更新。

最終更新：2025年11月

1. RAGの概要

1.1 RAGとは

RAG（Retrieval-Augmented Generation）（Lewis et al. 2020）：

外部知識を検索し、その情報を基にLLMが回答を生成。

1.2 なぜRAGが必要か

課題 RAGによる解決
知識の古さ 最新データを検索可能
幻覚（ハルシネーション） 根拠に基づく回答
ドメイン知識の不足 専門文書を参照
出典の不明確さ 参照元を提示可能

1.3 RAG vs ファインチューニング

観点 RAG ファインチューニング
知識更新 即時（データ追加のみ） 再訓練が必要
コスト 低（推論時のみ） 高（訓練コスト）
出典 明示可能 困難
適用範囲 事実的知識 スタイル・形式

2. アーキテクチャ

2.1 基本的な流れ

1. 質問: 「Transformerとは何ですか？」
     ↓
2. 検索: 質問をベクトル化、関連文書を検索
     ↓
3. コンテキスト構築: 検索結果を整理
     ↓
4. 生成: LLMが検索結果を参照して回答
     ↓
5. 回答: 「Transformerは2017年に提案された...」

2.2 コンポーネント

┌─────────────────────────────────────┐
│            RAGシステム              │
├─────────────────────────────────────┤
│  [Data Ingestion]                   │
│    文書 → チャンキング → 埋め込み   │
│           ↓                         │
│  [Vector Store]                     │
│    ベクトルDB（Pinecone, Chroma等） │
│           ↓                         │
│  [Retriever]                        │
│    クエリ → 検索 → 関連文書         │
│           ↓                         │
│  [Generator]                        │
│    コンテキスト + 質問 → LLM → 回答 │
└─────────────────────────────────────┘

2.3 オフライン処理（インデックス構築）

  1. 文書の収集・前処理
  2. チャンクに分割
  3. 埋め込みモデルでベクトル化
  4. ベクトルDBに保存

2.4 オンライン処理（クエリ時）

  1. クエリを埋め込み
  2. 類似度検索
  3. 上位k件を取得
  4. プロンプトに組み込み
  5. LLMで生成

3. 検索（Retrieval）

3.1 埋め込みモデル

モデル 特徴
OpenAI text-embedding-3 高性能、API利用
Cohere Embed 多言語対応
BGE オープンソース、高性能
E5 Microsoft、多言語
GTE Alibaba、汎用

3.2 ベクトルデータベース

DB 特徴
Pinecone マネージド、スケーラブル
Weaviate オープンソース、ハイブリッド検索
Chroma 軽量、開発向け
Qdrant Rust実装、高速
pgvector PostgreSQL拡張

3.3 検索手法

  • Dense Retrieval：埋め込みベースの意味検索
  • Sparse Retrieval：BM25等のキーワード検索
  • Hybrid：両者を組み合わせ

3.4 リランキング

検索結果を再順位付け：

  • Cross-Encoder：クエリと文書をペアで評価
  • Cohere Rerank：商用リランカー
  • 検索の精度を大幅に向上

4. チャンキング

4.1 なぜチャンキングが重要か

  • LLMのコンテキスト長制限
  • 検索精度への影響
  • 関連情報の抽出精度

4.2 チャンキング戦略

方法 説明
固定長 一定の文字数/トークン数で分割
文・段落単位 自然な区切りで分割
セマンティック 意味的なまとまりで分割
再帰的 階層的に分割

4.3 オーバーラップ

チャンク間で重複を持たせる：

  • 文脈の断絶を防ぐ
  • 一般的に10-20%程度

4.4 チャンクサイズの選択

  • 小さすぎ：文脈不足、検索ノイズ増加
  • 大きすぎ：無関係な情報を含む、コスト増
  • 一般的に200-1000トークン程度

5. 生成（Generation）

5.1 プロンプト構成

以下のコンテキストを参照して質問に答えてください。
コンテキストに情報がない場合は「わかりません」と答えてください。

コンテキスト:
{retrieved_documents}

質問: {user_question}

回答:

5.2 引用・出典の付与

回答を生成する際、情報の出典を[1], [2]のように示してください。

コンテキスト:
[1] 文書A: ...
[2] 文書B: ...

質問: ...

回答: Transformerは2017年に提案されました[1]。

5.3 回答品質の向上

  • 情報の統合：複数のチャンクを統合
  • 矛盾の処理：情報が矛盾する場合の対応
  • 不確実性の表現：確信度の低い情報の扱い

6. 高度なRAG

6.1 Query変換

  • Query Rewriting：検索に適した形式に書き換え
  • Query Expansion：同義語・関連語の追加
  • HyDE：仮想的な回答を生成して検索

6.2 Self-RAG

Asai et al. (2023)：検索の必要性を自己判断。

  • 検索が必要かを判断
  • 検索結果の関連性を評価
  • 回答の裏付けを確認

6.3 Corrective RAG (CRAG)

検索結果の品質を評価・修正：

  • 検索結果が不十分なら追加検索
  • 無関係な結果をフィルタリング
  • Web検索へのフォールバック

6.4 Agentic RAG

エージェントがRAGを制御：

  • 複数ステップの検索
  • 検索戦略の動的調整
  • 異なるデータソースの組み合わせ

6.5 Graph RAG

知識グラフとの統合：

  • エンティティ間の関係を活用
  • 推論パスの説明可能性
  • 複雑なクエリへの対応

7. 評価

7.1 評価指標

指標 対象
Retrieval Precision 検索結果の関連性
Retrieval Recall 関連文書の網羅性
Answer Relevance 回答の質問への関連性
Faithfulness 回答とコンテキストの整合性
Answer Correctness 回答の正確性

7.2 評価フレームワーク

  • RAGAS：RAG評価の標準ツール
  • LlamaIndex Evaluation：組み込み評価
  • TruLens：トレーシングと評価

7.3 よくある問題

  • 関連文書が検索されない
  • 検索結果を無視した回答
  • 矛盾する情報の混在
  • 過度に長い/短い回答

8. 参考文献

  • Lewis et al. (2020). "Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks" NeurIPS
  • Gao et al. (2023). "Retrieval-Augmented Generation for Large Language Models: A Survey" arXiv
  • Asai et al. (2023). "Self-RAG: Learning to Retrieve, Generate, and Critique through Self-Reflection" arXiv
  • Yan et al. (2024). "Corrective Retrieval Augmented Generation" arXiv