RAG (Retrieval-Augmented Generation) のアーキテクチャ解説
LLM の弱点を補う RAG の構成要素を 1 枚図で理解する。Embedding / Vector DB / リランキングの役割分担。
RAG (検索拡張生成) は、LLM が学習時に持っていない最新情報・社内ドキュメント・固有データに対応するための定番パターンです。構成要素とよくある落とし穴を整理します。
なぜ RAG が必要か
- LLM は学習時点の知識しか持たない (cutoff 問題)
- 社内文書などプライベートデータを事前学習に入れられない
- 出典付き回答が要求される業務 (法務・医療) に対応したい
ファインチューニングと比べて、データ更新が即反映され、コストもかからないという利点があります。
標準的な構成要素
- Chunker: 文書を一定サイズに分割
- Embedding モデル: 各 chunk をベクトル化 (OpenAI text-embedding-3, BGE など)
- Vector DB: ベクトル類似検索 (pgvector / Qdrant / Pinecone / Weaviate)
- Retriever: クエリを同じ空間にベクトル化して上位 k 件を取得
- Reranker (任意): cross-encoder で上位結果を再スコアリング
- LLM: 検索結果をコンテキストとして回答生成
失敗しやすいポイント
- チャンクサイズ: 長すぎると雑音が増え、短すぎると文脈が欠ける。512〜1024 トークンが目安
- メタデータ不足: 日付・部署・公開範囲などでフィルタできないと精度が出ない
- 評価セットの欠如: 手動で 30〜50 件の Q&A ペアを先に作り、変更前後で比較する
- ハルシネーション: prompt に「根拠がない場合は答えない」を明示する / 引用強制
発展パターン
- Hybrid search: キーワード (BM25) + ベクトル検索を組み合わせ、用語一致と意味検索の両方を活用
- HyDE: LLM で仮想回答を生成し、そのベクトルで検索する
- Agentic RAG: 検索が不足したら追加クエリを自律的に生成
まず作るべきもの
評価セット (30-50 ペア) と、手動で算出できる Hit@k / MRR。これを先に用意せずに構成を変えると、改善しているのか後退しているのか分からなくなります。