これは何の論文か
スキル-RAG の中心問いは、RAG がうまく答えられなかったときに、ただ検索を繰り返すだけでよいのか、というもの。既存の adaptive 検索は、retrieve するか、何回 retrieve するかを制御する方向に寄りがちだった。しかし 難しい事例では、関連文書がまったく無いのではなく、質問の形と証拠空間の合い方が悪く、近いが答えに足りない文書を拾い続けることがある。
論文はこの状態をクエリ-証拠対応づけずれとして捉える。広すぎる質問は証拠への焦点化が必要で、複数の前提が絡む質問は de組み立てが必要で、表現が文書側の索引とずれている質問は rewriting が必要になる。つまり検索失敗は一種類の失敗ではなく、型を持った失敗として扱える、という見方である。
スキル-RAGは、隠れ状態 診断器 でモデル内部の失敗状態を検出し、プロンプトベースの スキル ルーター で原因を診断する。ルーター はクエリ書き換え、質問分解、証拠への焦点化、exit の四つから選び、次の検索前にクエリまたは証拠の向きを直す。診断器は、検索前と検索後の二段階でゲートとして働く。
実験では Gemma2-9B を使い、HotpotQA、NQ、TriviaQAを in-領域、MuSiQueと 2WikiMultiHopQAを out-of-領域 として評価する。スキル-RAGは Probing-RAG に対して、特に OOD で大きく改善し、MuSiQueで ACC +6.1、2WikiMultiHopQAで +13.6 を示す。
面白いのは、スキルを増やせば増やすほどよい、という結論ではないこと。表現-space analysis では、四つのスキル vocabulary は失敗状態の構造に合っている一方、LLM に六つ以上のスキルを自動生成させるとクラスタ構造が崩れる。少数のよく切られたスキルが、RAG の失敗回復には効く。
スキル-RAGは、RAGの post-検索失敗を、再検索の回数調整ではなく、失敗型に応じたスキル選択として扱う論文である。
対象にしているのは、検索をしても答えが直らない しつこい失敗である。論文は、その多くが 関連証拠の不在だけではなく、クエリと証拠空間 の対応づけずれに由来すると見る。
提案手法は、軽量な 隠れ状態 診断器 とプロンプトベースの スキル ルーター を組み合わせる。診断器 はモデルの内部状態から、回答準備ができているか、検索や 回復 が必要かを判定する。
何が問題だったのか
RAG は検索を足せば答えが良くなるように見えるが、実際には検索後にも失敗が残る。関連文書を取ったのに質問の焦点とずれている、複数の条件を分解できていない、証拠のどこを見ればよいか絞れていない、そもそも検索を続けるべきでない、という失敗が混ざる。
こうした失敗に対して、単にもう一度検索するだけでは弱い。同じクエリを少し変えても、問題が質問分解にあるなら直らない。証拠はあるのに読み方がずれているなら、追加検索より証拠への焦点化が必要になる。
問題は、検索後の失敗を一つの「検索不足」として扱ってしまうことだ。失敗の型を見分け、次に取るべき回復行動を選べなければ、検索ラウンドを増やしてもコストだけが増える。
Skill-RAG は、検索失敗を typed な回復問題として扱う。クエリ書き換え、質問分解、証拠への焦点化、終了判断を、失敗状態に応じて選ぶ検索スキルとして位置づける。
既存の RAG 改善は、検索するかどうかのゲート、検索器の改善、クエリ書き換え、再ランキングなどを個別に扱うことが多い。しかし、回答生成後に残った失敗がどの型なのかを見て、次の回復行動を選ぶ枠組みは弱かった。
また、検索後の失敗を平均正解率だけで見ると、何が直ったのかが分かりにくい。クエリが悪いのか、質問が複合的すぎるのか、証拠の読み方が悪いのか、もう終了すべきなのかを分けないと、改善策も選べない。
Skill-RAG は、その不足を「もう一度検索するか」ではなく、「失敗がどの型なのかを診断して、次の検索行動を選ぶ」問題として補う。ここを押さえると、クエリ書き換え、質問分解、証拠への焦点化、終了判断は単なる候補手順ではなく、検索失敗の型に対応する回復スキルとして読める。
提案手法の中身
入力は、ユーザーの質問、検索で得た証拠、モデルが途中で作った推論と回答、そして生成時の隠れ状態である。
最初に、隠れ状態診断器が、モデル内部知識だけで答えられるか、検索が必要かを判定する。検索が必要なら BM25 で証拠を取り、証拠を条件に回答を生成する。
生成後にも診断器を使う。回答が十分なら終了し、まだ失敗状態なら次の回復へ進む。ここで重要なのは、検索前だけでなく、検索後の回答状態も見る点である。
失敗状態が検出されると、プロンプトベースのスキルルーターが、元の質問、失敗した推論、現在の証拠を読む。ルーターは、ずれの原因を見て、次に使う検索スキルを選ぶ。
選択肢は四つある。クエリ書き換えは、検索語が証拠語彙とずれている時に使う。質問分解は、複数条件や複数ホップが混ざっている時に使う。証拠への焦点化は、証拠はあるが見るべき箇所が絞れていない時に使う。exit は、これ以上検索しても改善しにくい時に使う。
選ばれたスキルは、クエリや証拠の向きを直して次の検索ラウンドへつなぐ。このループは、診断器が十分と判定する、ルーターが exit を選ぶ、または最大ラウンドに達するまで続く。
どうやって確かめたのか
評価では、検索失敗の状態ごとにスキルを選ぶことが、難しい質問でどれだけ効くかを見る。HotpotQA、NQ、TriviaQA を領域内、MuSiQue と 2WikiMultiHopQA を分布外として扱う。
比較対象は、標準検索を繰り返す方法、診断器だけを使う方法、Probing-RAG、Skill-RAG である。すべての方法で BM25 検索器を使い、検索器そのものの違いではなく、失敗状態の診断とスキル選択の差を見る。
測る指標は、回答の正解率、分布外データでの改善幅、どの検索スキルが選ばれたか、スキル数を増やした時にルーティングが崩れないかである。
結果はどうだったのか
分布外の難しい質問で改善が大きい
スキル-RAG は Probing-RAG に対して、MuSiQue で ACC +6.1、2WikiMultiHopQA で +13.6 を示す。どちらも分布外の複数ホップ質問なので、単なる検索回数の追加ではなく、失敗状態に応じた回復行動が効いたと読める。
領域内でも性能を落としにくい
HotpotQA、NQ、TriviaQA でも competitive または state-of-the-art に近い性能を示す。分布外で強くするための仕組みが、領域内の標準的な QA を壊していない点が重要である。
隠れ状態分析では、直せる失敗と直しにくい失敗が分かれる
三回の標準検索後も間違う難しい事例の隠れ状態埋め込みを見ると、対応づけずれ系の修正可能な失敗と、検索器の上限や不足知識に近い修正しにくい失敗が分かれる。ここから、何でも再検索するのではなく、失敗型に応じた回復が必要だと分かる。
スキルは増やしすぎない方がよい
四つのスキルではクラスタが収縮し、修正可能な失敗が減る。一方で、LLM に六つ以上のスキルを自動生成させると、クラスタ構造が崩れ、過度に細かいスキル集合がルーティングを難しくする可能性が示される。
事例ではクエリ書き換えが脱線を防いでいる
My Hero Academia の映画公開日の例では、Probing-RAG は再検索で off-topic な band にずれる。スキル-RAG はクエリ書き換えを選び、Japan release date へクエリを直して正しい July 5, 2018 に到達する。
限界・注意点
- スキル ルーター はプロンプトベースの なので、基盤 LLM の指示追従能力に依存する。弱いモデルでは診断品質が落ちる可能性がある。
- 四つのスキル vocabularyは open-領域 QA ベンチマークから導かれている。科学論文、多言語コーパス、企業内文書など、検索 characteristic が違う領域では分類が足りない可能性がある。
- 実験は主に Gemma2-9B で行われている。モデルサイズやアーキテクチャをまたいだ広い検証は今後の課題として残る。
- 検索器は BM25 で統一されている。dense 検索やハイブリッド検索、エージェント型検索ハーネスとの組み合わせでは、失敗状態やスキルの効き方が変わる可能性がある。
おい丸のようなエージェントにどう使えるか
おい丸のような作業支援エージェントでは、検索に失敗した時に「もっと検索する」だけでは弱い。質問の分解が必要なのか、別の語彙で探すべきなのか、今ある証拠を読み直すべきなのか、もう止めるべきなのかを分ける必要がある。
この論文を使うなら、検索失敗ログを「検索不足」だけでまとめない。rewrite、decompose、focus、exit のどれに近いかを分類し、次に同じ失敗が起きた時の回復行動として残す。
注意点として、スキルの種類を増やしすぎるとルーティングが難しくなる。少数の分かりやすい回復行動に絞り、どの失敗型で使うかを明確にする方が運用しやすい。
Q&A
この論文の中心問いは？
RAG が検索後も失敗したとき、ただ再検索するのではなく、失敗状態を診断して適切な検索スキルを選べるか、という問い。
スキル-RAG のスキルとは何？
検索を直す操作の種類。クエリ書き換え、質問分解、証拠への焦点化、exit の四つが定義されている。
隠れ状態 診断器 は何をする？
モデルの 隠れ状態から、回答できる状態か、検索や 回復 が必要な失敗状態かを判定する軽量な分類器として働く。
なぜ出力だけでなく 隠れ状態を見るの？
論文は、検索が詰まっている状態がモデル内部表現に構造として現れると見ている。出力後の retry signal だけでなく、内部状態をゲートに使うのが狙い。
クエリ書き換えはどんなときに使う？
質問の表面表現がコーパスの索引や文書表現とずれているときに、retrievable 証拠に合う形へクエリを書き換える。
質問分解はどんなときに使う？
複数段 クエリの前提が絡み合っていて、一度の検索では必要な推論ステップを分けにくいときに、複数の サブクエリへ分解する。
証拠への焦点化はどんなときに使う？
質問が広すぎて、関係はあるが答えに足りない文書を拾い続けるときに、欠けている証拠スロットを狙って検索を絞る。
exit スキルは諦めるだけ？
単なる失敗ではなく、証拠不足やモデル能力限界など、検索を続けても改善しにくい irreducible 事例を識別し、不要な推論コストを避ける役割。
一番重要な実験結果は？
OOD ベンチマークで Probing-RAG より大きく改善したこと。MuSiQueで ACC +6.1、2WikiMultiHopQAで +13.6 を示している。
スキルは多いほど良い？
この論文の結果では、そう単純ではない。LLM に六つ以上のスキルを自動生成させると失敗表現の クラスタ構造 が崩れ、ルーティングが難しくなる可能性が示される。
実務 RAG に使うなら何を見る？
失敗ログを、rewrite、decompose、focus、exit のどれに近いか分類する。単に top-k や検索回数を増やす前に、クエリと証拠空間 のずれ方を見る。
この論文の限界は？
ルーター がプロンプトベースので LLM 能力に依存すること、四つのスキルが別ドメインで十分とは限らないこと、実験が主に Gemma2-9B に限られること。
関連する記事
- Self-RAG、Adaptive-RAG、FLARE、DRAGIN、Probing-RAG を並べると、検索の trigger、depth、critique、隠れ状態ゲート、スキルルーティングの違いが見えやすい。
- コーパスを直接歩く検索エージェント や grepだけで十分なのか と合わせると、検索スキルを選ぶ以前に、コーパスをどう歩けるようにするか、検索結果をどうエージェントに渡すかというハーネス側の論点に接続できる。
- 実務 RAG に引くなら、失敗ログを「再検索すべき」だけで終わらせず、rewrite が必要か、分解が必要か、証拠を絞るべきか、そもそも exit すべきかに分類してみるとよい。
- エージェントスキル運用の文脈では、スキルを増やすほど良いのではなく、失敗空間の構造に合った少数のスキル vocabulary を保つ、という設計原則として読める。