Agentic RAGにおいてエージェントが生成した回答の品質を自己評価し、不足・誤り・矛盾を検出して自律的に修正する機能。CRAG・Self-RAG等の手法が代表的。
Agentic RAGの自己修正（Self-Correction）は、エージェントが生成した中間結果や最終回答を自ら評価し、品質が基準に満たない場合に自律的に修正プロセスを起動する機能である。従来のRAGでは検索結果をそのまま信頼して回答を生成していたが、Agentic RAGでは「検索結果は本当に正確か」「回答に矛盾はないか」「情報は十分か」といった自己検証を組み込む。
2023年にAkari Asaiらが提案した手法。LLMが特殊なリフレクショントークンを生成し、検索の必要性判断・検索結果の関連性評価・回答の裏付け検証を行う。
| リフレクショントークン | 役割 | 判定値 |
|---|---|---|
| Retrieve | 検索が必要か判断 | yes / no / continue |
| ISREL | 検索結果がクエリに関連するか | relevant / irrelevant |
| ISSUP | 回答が検索結果に裏付けられるか | fully supported / partially / no support |
| ISUSE | 回答がユーザーに有用か | 1-5のスケール |
検索結果の品質を評価し、不十分な場合に修正アクションを実行する手法。
CRAGの特徴は、検索結果の品質に応じてアクションを切り替えるスイッチメカニズムにある。これにより、ベクトルDBの検索結果が不十分な場合でも、Web検索という代替手段で情報を補完できる。
クエリの複雑度に応じて処理戦略を適応的に切り替える手法。単純なクエリには軽量な処理を、複雑なクエリには完全な自己修正ループを適用する。
自己修正プロセスは以下のループ構造で実装される。
| 検出された問題 | 修正アクション |
|---|---|
| 関連性不足 | クエリを再構成して再検索 |
| 情報不足 | 追加の検索クエリを生成 |
| 矛盾検出 | 矛盾する情報源の信頼性を比較検証 |
| 事実性不足 | 主張を弱める or 追加の裏付けを検索 |
| 回答不完全 | 未回答の部分に対する追加検索 |
無限ループを防ぐために以下の停止条件を設定する。
自己修正の判断にはスコアリング関数が必要である。以下の多次元スコアリングが一般的である。
検索結果とクエリの意味的類似度。Cross-EncoderやLLM-as-Judgeで算出。
生成された回答が検索結果に基づいているかの度合い。NLIモデルやentailmentスコアで算出。
回答がユーザーの質問に対して実用的かの度合い。LLM-as-Judgeで1-5スケール評価。
各次元のスコアを重み付け平均して総合品質スコアを算出する。閾値以下の場合に修正ループが起動する。
生成された文中の固有名詞・数値・日付を抽出し、検索結果と照合する。不一致があれば「この情報は検証できませんでした」と明示する。
回答に対する確信度を3段階（高・中・低）で表示し、ユーザーが情報の信頼性を判断できるようにする。
自己修正を繰り返しても品質基準に達しない場合のフォールバックを定義する。「この質問には確信を持って回答できません。以下は参考情報です」といった誠実な回答が推奨される。
A1: Self-RAGは検索の必要性判断から回答の品質評価まで一貫したリフレクション機能を提供するため、ファインチューニングが可能な環境に適しています。CRAGは検索結果の品質に応じた修正アクションに特化しており、既存のLLMをそのまま使える利点があります。実運用では両者の概念を組み合わせることが多いです。
A2: 修正が必要なケースのみループを実行する「怠惰な修正（Lazy Correction）」パターンが有効です。初回の回答生成時に信頼度スコアを算出し、閾値以上であれば修正ループをスキップします。これにより70-80%のクエリでは追加レイテンシが発生しません。
A3: はい、過修正（Over-correction）のリスクがあります。修正を重ねるうちに本来正しかった情報を上書きしてしまうケースです。対策として、修正前後のスコアを比較し、スコアが下がった場合は修正を棄却する「ロールバック機構」を実装することが推奨されます。