ストーリー
田
田中VPoE
ここまでの手法は「検索パイプラインを改善する」アプローチだった。次は発想を変えて「RAGシステム自身が自分の回答品質を評価し、必要に応じて改善する」アプローチを学ぼう
あなた
RAGシステムが自分で「この回答は本当に正しいか？」を判断するんですか？
あ
田
田中VPoE
そうだ。人間がレビューするのと同じようにLLMが自身の回答を評価する。Self-RAGは「検索が必要かどうか」「検索結果が関連しているか」「生成した回答が根拠に基づいているか」を自己判断する
あなた
すごい仕組みですね。ただ、LLMの判断も間違うことがありますよね？
あ
田
田中VPoE
その通り。だから補正メカニズムも含めたCRAG（Corrective RAG）というアプローチもある。両方を理解しておこう
Self-RAG（Self-Reflective RAG）
基本概念
Self-RAGは、RAGパイプラインの各段階で「反省トークン」を生成し、自己評価を行うフレームワークです。
Self-RAGの処理フロー:
[Step 1: 検索の必要性判断]
クエリ: "Pythonの最新バージョンは？"
→ Retrieve判定: YES（最新情報が必要）
クエリ: "1+1は？"
→ Retrieve判定: NO（検索不要、LLM知識で回答可能）
[Step 2: 検索結果の関連性評価]
検索結果: "Python 3.13がリリースされました..."
→ Relevance判定: RELEVANT
検索結果: "Javaの最新バージョンは..."
→ Relevance判定: IRRELEVANT → 除外
[Step 3: 回答の忠実性評価]
生成した回答: "Python 3.13が最新です"
検索結果に基づいているか？
→ Faithfulness判定: SUPPORTED
[Step 4: 回答の有用性評価]
生成した回答はクエリに対して有用か？
→ Utility判定: 5/54つの反省トークン
| トークン | 判断内容 | 出力 |
|---|---|---|
| Retrieve | 検索が必要か？ | YES / NO |
| IsREL | 検索結果は関連しているか？ | RELEVANT / IRRELEVANT |
| IsSUP | 回答は検索結果に基づいているか？ | FULLY SUPPORTED / PARTIALLY / NOT SUPPORTED |
| IsUSE | 回答はクエリに対して有用か？ | 1〜5のスコア |
CRAG（Corrective RAG）
基本概念
CRAGは検索結果の品質を評価し、不十分な場合に補正アクションを取るフレームワークです。
CRAGの処理フロー:
[Step 1: 通常のRAG検索]
クエリ → ベクトル検索 → Top-K結果
↓
[Step 2: 検索結果の品質評価]
LLMが各検索結果を「Correct / Ambiguous / Incorrect」に分類
↓
[Step 3: 品質に応じた補正アクション]
├── Correct（正確）: そのまま使用
├── Ambiguous（曖昧）: 知識の精錬（不要部分を除去）
└── Incorrect（不正確）: Web検索で補完、またはクエリを変換して再検索
↓
[Step 4: 最適化されたコンテキストでLLM生成]3つの補正アクション
| 評価結果 | 説明 | アクション |
|---|---|---|
| Correct | 検索結果がクエリに対して正確に関連 | 結果をそのままLLMに渡す |
| Ambiguous | 一部関連するが不十分、または確信が持てない | 知識の精錬（関連部分の抽出 + 不要部分の除去） |
| Incorrect | 検索結果がクエリに関連していない | 代替検索（Web検索、クエリ変換して再検索） |
Self-RAGとCRAGの比較
| 観点 | Self-RAG | CRAG |
|---|---|---|
| 評価タイミング | 生成前・生成中・生成後 | 検索後（生成前） |
| 評価対象 | 検索の必要性、関連性、忠実性、有用性 | 検索結果の正確性 |
| 補正方法 | 検索スキップ、結果フィルタリング | 知識の精錬、代替検索 |
| 実装複雑度 | 高（専用モデルまたは複数LLM呼び出し） | 中（評価 + 補正ロジック） |
| レイテンシ影響 | 大（複数回の評価） | 中（1回の評価 + 補正） |
実践的な適用パターン
軽量版Self-RAG
本番環境では完全なSelf-RAGは重いため、軽量版を適用するのが現実的です。
軽量版Self-RAGの実装:
[Step 1] 通常のRAGパイプラインで回答生成
[Step 2] 生成後の品質チェック（LLM 1回呼び出し）
「以下の回答は提供されたコンテキストに基づいていますか？
回答が根拠に基づいている場合は"SUPPORTED"、
根拠がない推測を含む場合は"NOT_SUPPORTED"と判定してください」
[Step 3] 判定に基づくアクション
├── SUPPORTED → 回答をそのまま返す
└── NOT_SUPPORTED → 「情報が不十分です」と回答する、
またはクエリを変換して再検索CRAG的な検索品質チェック
検索品質チェックの実装:
検索結果（Top-5）に対して:
LLMプロンプト:
「以下の検索結果はクエリ「{query}」に対して関連していますか？
各結果を"RELEVANT"または"IRRELEVANT"で評価してください。」
結果:
├── 結果1: RELEVANT → 使用
├── 結果2: RELEVANT → 使用
├── 結果3: IRRELEVANT → 除外
├── 結果4: RELEVANT → 使用
└── 結果5: IRRELEVANT → 除外
→ RELEVANT率が50%未満の場合、クエリを変換して再検索コストとレイテンシの考慮
| 手法 | 追加LLM呼び出し | レイテンシ追加 | コスト増 |
|---|---|---|---|
| 品質チェックなし | 0回 | 0ms | 0% |
| 検索結果の関連性チェック | 1回 | 300〜500ms | +20% |
| 軽量版Self-RAG | 2回 | 500〜800ms | +40% |
| フルSelf-RAG | 3〜5回 | 1〜3秒 | +100〜200% |
「品質チェックにもコストがかかる。全クエリに適用するのではなく、ユーザーフィードバックが悪いクエリパターンに限定するのも手だ」 — 田中VPoE
まとめ
| ポイント | 内容 |
|---|---|
| Self-RAG | 検索の必要性、関連性、忠実性、有用性を自己評価 |
| CRAG | 検索結果の品質を評価し、不十分な場合に補正アクションを実行 |
| 軽量版 | 全評価ではなく、生成後の忠実性チェックに限定 |
| コスト | 品質チェックの追加LLM呼び出しによるコスト・レイテンシ増に注意 |
チェックリスト
- Self-RAGの4つの反省トークンの役割を理解した
- CRAGの3つの補正アクションを理解した
- 軽量版Self-RAGの実装パターンを理解した
- 品質チェックのコスト・レイテンシへの影響を理解した
次のステップへ
次は「高度なRAGパターン」を学びます。Graph RAG、Agentic RAG、Multi-hop RAGなど、より複雑な検索・推論パターンを理解しましょう。
推定読了時間: 30分