自己改善型RAG — 検索結果を評価して引き直す

基本のRAGは一方通行です。検索して、引いた文書を渡して、答えさせる。この構造には検索が外れたときに気づく仕組みがありません。

しかも悪いことに、LLM は無関係な文書を渡されても「情報がありません」とは言わず、渡された文書から無理に答えを組み立てる傾向があります。出典付きで、自信のある文体で、間違った答えが返る。RAG を導入したのに信頼性が上がらない、という感覚の正体はここにあります。

横にスクロール

共通する構造

Self-RAG・CRAG・Agentic RAG と名前は違いますが、骨格は同じです。

質問
  ↓
検索
  ↓
[判定] 引いた文書は、この質問に答えるのに十分か？
  ↓                          ↓
十分                       不十分
  ↓                          ↓
生成                       打ち手を選ぶ
  ↓                        （再検索 / クエリ変更 / 別ソース / 諦める）
[判定] 回答は文書に基づいているか？        ↓
  ↓              ↓                      戻る
根拠あり       根拠なし
  ↓              ↓
返す           作り直す or 諦める

判定が2箇所にあることに注目してください。検索結果の評価（引けたか）と生成結果の評価（根拠に基づいているか）は別の問題で、前者だけでは幻覚を止められません。

判定器をどう作るか

判定の質がすべてを決めます。実装の選択肢は3つあります。

スコアの閾値だけに頼るのは危険です。ベクトル検索の類似度は、コーパスやクエリによって絶対値が動くため、「0.7以上なら十分」といった固定閾値は安定しません。「上位1件のスコアが極端に低い」という明らかな失敗の検出には使えますが、微妙なケースの判断には向きません。

リランカを既に入れているなら、その関連度スコアは判定に流用できます。cross-encoder はクエリと文書を突き合わせて評価しているので、bi-encoder の類似度より判定材料として信頼できます。

LLM に判定させる方式は精度が高い代わりに、候補ごとに呼ぶとコストが跳ねます。上位数件をまとめて1回のプロンプトで評価させる形にすると、呼び出しは1回で済みます。

打ち手の設計

不十分と判定されたとき、何をするか。

クエリを変えて引き直す。 クエリ変換の各手法がそのまま打ち手になります。1回目が失敗した情報を使えるのが利点で、「この語で引いたら関係ない文書ばかりだった」という結果を踏まえて言い換えられます。

検索先を変える。 ルーティングの分類が外れていた可能性があります。別のコーパスや、フィルタを緩めた検索を試します。

外部の検索に逃がす。 社内コーパスに無い一般知識なら、Web検索へ切り替えます。CRAGが提案する経路の1つで、内部に無いものを内部で探し続けないという判断です。

諦めて正直に答える。 最も重要な打ち手です。「提供された資料の中には、この質問に答える情報が見つかりませんでした」と返すのは失敗ではなく、正しい振る舞いです。無理に答えさせるより価値があります。

ループを閉じる

ここが実装で最も事故りやすい箇所です。

必ず設ける制限
  最大反復回数        : 2〜3回。それ以上引き直しても改善しないことが多い
  累積トークン予算    : 1質問あたりの上限を決める
  累積レイテンシ予算  : 体感を壊さない上限（例: 10秒）
  終了条件            : 上限に達したら必ず「分かりません」経路へ落とす

コストに見合うか

自己改善型は確実に高くつきます。判定に1回、再検索に1回、再生成に1回——素朴に実装すると、基本のRAGの3〜5倍のコストとレイテンシになります。

導入判断の順序は次の通りです。

1. まず基本を固める。 チャンク設計・ハイブリッド検索・リランキングで検索を良くするほうが、はるかに安く効きます。1回目の検索が当たるなら、ループは要りません。
2. 失敗の型を測る。 評価で、失敗が「検索が外れている」のか「検索は当たっているのに生成が悪い」のかを分けます。前者ならループが効き、後者なら効きません。
3. 部分的に入れる。 全質問にループを回す必要はありません。明らかに検索が失敗したときだけ（スコアが極端に低い、結果がゼロ）作動させれば、平均コストはほとんど上がらずに最悪ケースだけが改善します。

3つ目が実務的な落としどころです。全質問で判定LLMを呼ぶのではなく、安価なスコア閾値で「明らかな失敗」だけを拾い、そこにだけ打ち手を投入します。

まとめ

• 基本のRAGは一方通行で、検索が外れても気づけない。LLM は無関係な文書からでも自信のある答えを作る。
• 共通構造は「引いた文書が十分かを判定し、不十分なら別の手を打つ」。判定は検索結果と生成結果の2箇所に要る。
• スコアの閾値だけに頼らない（絶対値が不安定）。リランカのスコア流用か、上位をまとめて1回のLLM判定が現実的。3値判定にすると打ち手が自然に決まる。
• 打ち手はクエリ変更・検索先変更・外部検索・諦める。「分かりません」と答えるのは失敗ではなく正しい振る舞い。
• ループは必ず有限に閉じる。最大反復・トークン予算・レイテンシ予算・上限到達時の経路を先に決める。
• コストは3〜5倍になる。まず基本を固め、失敗の型を測り、明らかな失敗時だけ作動させるのが実務的。