CRAG（Corrective Retrieval-Augmented Generation）（コレクティブアールエージー）
検索結果の品質をLLMが事後評価し、低品質な文書を除外・修正してから回答を生成するRAG改良手法。2024年にYan et al.が提案し、検索結果の信頼性を自動で担保する。
CRAG（Corrective Retrieval-Augmented Generation）とは
CRAGは、RAGパイプラインにおける検索結果の品質問題を解決するフレームワークである。2024年にShiqi Yan et al.が論文「Corrective Retrieval Augmented Generation」で提案した。通常のRAGは検索で取得した文書をそのままLLMに渡すが、検索結果が不正確・無関係な場合でもLLMはそれを根拠として使ってしまい、ハルシネーションの原因になる。CRAGは検索結果を3段階（Correct/Incorrect/Ambiguous）で評価し、不正確な場合はWeb検索にフォールバックすることで回答品質を保証する。
主な特徴・仕組み
- 検索結果の3段階評価: 軽量な評価モデル（T5-large等）で検索結果のクエリ関連性をスコアリング
- Correct（信頼度 > 0.7）: そのまま利用
- Incorrect（信頼度 < 0.3）: 検索結果を破棄し、Web検索（Google/Bing API）にフォールバック
- Ambiguous（0.3〜0.7）: 検索結果とWeb検索結果を併用
- Knowledge Refinement: Correct判定の文書からも不要な情報を除去し、クエリに関連する部分のみを抽出
- Web検索フォールバック: 内部ナレッジベースでカバーできないクエリに対し、リアルタイムWeb情報で補完
- プロンプトベース適用: Self-RAGと異なりファインチューニング不要。GPT-4o・Claude Sonnet 4.6・Llama 3等どのモデルにも適用可能
- 評価モデルコスト: T5-largeベース評価器は1クエリあたり約50ms。LLM本体の推論時間に比べて無視できるレベル
- ベンチマーク: PopQA・Biography・PubHealthで従来RAGを+3〜8%上回る精度
- LangGraph実装: LangGraphの公式テンプレート「Corrective RAG」として提供されており、導入容易
処理フロー
| ステップ | 処理 | 判定 |
|---|---|---|
| 1 | クエリ入力 | — |
| 2 | ベクトルDB検索（Top-K文書取得） | — |
| 3 | 評価モデルで関連性スコアリング | Correct / Incorrect / Ambiguous |
| 4a | Correct → Knowledge Refinement | 不要情報除去 |
| 4b | Incorrect → Web検索フォールバック | Google/Bing API |
| 4c | Ambiguous → 両方を統合 | 内部+Web |
| 5 | 精製された文書でLLM回答生成 | — |
スペック比較
| 手法 | ファインチューニング | 検索評価 | フォールバック | 導入難度 | 精度向上 |
|---|---|---|---|---|---|
| 通常RAG | 不要 | なし | なし | ★☆☆ | ベースライン |
| HyDE | 不要 | なし | なし | ★★☆ | +5〜15% |
| Self-RAG | 必須 | あり（内蔵） | なし | ★★★ | +10〜20% |
| CRAG | 不要 | あり（外部評価器） | Web検索 | ★★☆ | +3〜8% |
選び方・注意点
- クローズドモデルで使える: GPT-4o・Claude等のAPI経由モデルでも適用可能。Self-RAGが使えない環境での第一選択肢
- Web検索API費用: フォールバック時にGoogle Custom Search API（$5/1,000クエリ）やBing Search API（$7/1,000クエリ）のコストが発生
- 評価モデルの精度: T5-largeベースの評価器は汎用的だが、専門ドメイン（医療・法律）ではドメイン特化の評価器が推奨
- レイテンシ: 評価ステップ+潜在的なWeb検索で、通常RAGより200〜800ms増加
- プライバシー: Web検索フォールバックはクエリを外部APIに送信するため、機密情報を含むクエリには不適
関連用語との違い
CRAGの核心は「検索後の品質保証」にある。HyDEが検索クエリの改善、Self-RAGが検索要否の自律判断にフォーカスするのに対し、CRAGは「検索はするが結果が悪ければ別ソースから補完する」という実用的なアプローチ。Web検索フォールバックは内部ナレッジベースの不足を補うため、企業導入時に「ナレッジベースが完璧でなくても動く」安心感を提供する。
よくある質問（FAQ）
Q1: CRAGとSelf-RAGはどちらを選ぶべき？ A: ファインチューニング環境があり最高精度を求めるならSelf-RAG。API経由のクローズドモデルで手軽に導入したいならCRAG。CRAGはプロンプトエンジニアリングのみで実装でき、導入のハードルが低い。
Q2: Web検索フォールバックを無効化できる？ A: 可能。CRAGの評価ステップのみ使い、Incorrect判定の場合は「情報不足で回答できません」と返す設定にできる。機密環境ではこの設定が推奨。
Q3: LangGraphでCRAGを実装するのにどのくらいかかる？ A: LangGraph公式テンプレート「Corrective RAG」を使えば、ベクトルDB（Chroma/Pinecone）とWeb検索API（Tavily）の設定込みで約2〜3時間で動作するプロトタイプが構築できる。本番化にはエラーハンドリング・ロギング・評価パイプラインの追加で1〜2日程度。
まとめ
- CRAGは検索結果を3段階評価し、低品質な結果をWeb検索でフォールバックするRAG改良手法
- ファインチューニング不要でGPT-4o・Claude等のクローズドモデルにも適用可能
- LangGraphの公式テンプレートとして提供されており導入容易
- Self-RAGが使えない環境での実用的な代替として、企業RAGシステムに広く採用