今回の論文
今回取り上げるのは、University of Washington、Allen Institute for AI、IBM Research AI の Akari Asai、Zeqiu Wu、Yizhong Wang、Avirup Sil、Hannaneh Hajishirzi による 2023 年の論文「Self-RAG: Learning to Retrieve, Generate, and Critique through Self-Reflection」です。公開元は arXiv で、研究分野は RAG、LLM の推論制御、長文生成の事実性向上です。URL は https://arxiv.org/abs/2310.11511 です。
この論文を選んだ理由は、RAG の実装で現場がよく抱える「毎回検索すると重い」「検索結果が微妙でもそのまま使ってしまう」「根拠付き回答を作りたいが品質が安定しない」という問題に、かなり実践的な設計で答えているからです。単に検索を足すのではなく、検索の要否判断、根拠の吟味、出力の自己評価までを 1 つの生成モデルに寄せている点が、プロダクト設計のヒントになります。
どんな技術か
Self-RAG は、LLM が「まず検索するべきか」を自分で判断し、検索した場合はどの文書が役立つかを評価し、その根拠に支えられた文章を生成しながら、さらに自分の出力が十分に裏づけられているかも点検する技術です。
普通の RAG は、質問が来たら固定本数の文書を毎回検索して、まとめてプロンプトに入れる形が多いです。このやり方は単純ですが、検索が不要な質問にも必ず検索が走りますし、質の低い文書が混ざってもそのまま生成に流れ込みやすいです。Self-RAG はそこを変えて、Retrieve、IsRel、IsSup、IsUse という特別なトークンを生成しながら、検索の必要性、文書の関連性、根拠による支持、最終出力の有用性をモデル自身に評価させます。
要するに、Self-RAG は「検索付き生成」ではなく、「検索を使うかどうかも含めて生成の一部として学習した RAG」です。RAG を外付けの前処理として扱うのではなく、生成の途中判断として組み込んでいるのが大きな特徴です。
課題
Self-RAG が解決しようとしている課題は、従来の RAG が検索を固定フローとして扱いすぎていることです。実際の質問には、外部知識が必須なものもあれば、モデル内部の知識や推論だけで十分なものもあります。それにもかかわらず、毎回同じように上位数件を入れると、不要な情報までコンテキストに入り、生成品質や速度を下げてしまいます。
難しいのは、検索すれば必ず正しくなるわけではない点です。検索器が取ってきた文書が本当に relevant か、答えのどの部分を支えているか、十分な根拠があるかは別問題です。既存の方法では、検索結果を「入れたかどうか」までしか制御しておらず、「その検索結果が生成にどう効いたか」を細かく見ていないことが多いです。
なぜこの課題を解く必要があるかというと、RAG は検索品質が悪いとむしろ回答を崩すからです。社内ナレッジ検索、FAQ ボット、エージェント、長文レポート生成では、外部情報を使うこと自体よりも、いつ使うか、どの情報を採用するか、どこまで根拠として扱うかの方が重要になります。特に、引用付き回答や業務支援のように「それらしい答え」では足りない場面では、単純な固定検索型 RAG の限界がはっきり出ます。
用語解説
- RAG（Retrieval-Augmented Generation）
- 検索で取った文書を LLM の入力に足して生成する枠組みです。Self-RAG はこの基本形を前提にしつつ、検索の有無や使い方までモデル自身に学習させる点が違います。
- Reflection Token
- Self-RAG が生成中に出す特別トークンです。検索するか、文書が関連しているか、生成文が根拠に支えられているかなどを表します。この論文の核心は、この自己評価信号を通常の次トークン予測に埋め込んだことです。
- Adaptive Retrieval
- 質問ごと、あるいは生成途中ごとに検索の要否を変える考え方です。Self-RAG では Retrieve トークンの確率を使って検索頻度を調整でき、不要な検索を減らしつつ必要な場面では根拠を取りにいけます。
- Critic Model
- 学習用データに反省用トークンを付与するための補助モデルです。Self-RAG ではこの critic が事前にラベルを作り、その後で最終的な generator がそれを真似して学習します。推論時に critic を別途動かさない設計が実務上重要です。
- Grounding
- 生成内容を外部根拠に結びつけることです。Self-RAG では IsSup トークンが「その文章は文書に支えられているか」を見るため、単なる関連文書提示ではなく根拠付き生成に近づけています。
技術の仕組み
Self-RAG の基本アイデアは、検索と自己評価をすべて「生成するトークン」として扱うことです。外側に検索オーケストレーションを組むのではなく、モデルが自分で 検索する / しない を判断し、検索後の候補も自分で採点しながら、最終的な出力を選びます。
4種類の reflection token を使う
論文では 4 種類の reflection token を使います。Retrieve は検索が必要かを表し、値は yes no continue です。IsRel はある文書が質問解決に有効かどうかを表し、relevant か irrelevant を取ります。IsSup は生成した文が根拠にどこまで支えられているかを fully supported partially supported no support で表します。IsUse はその応答全体の有用性を 1 から 5 で評価します。
重要なのは、これらが後付けのスコアではなく、通常の語彙に追加されたトークンとして学習される点です。つまりモデルは、文章だけでなく「この文章をどう評価するか」も次トークン予測として出します。
まず検索するべきかを決める
推論時には、各セグメントの生成前に Retrieve トークンを出して、検索が必要かを判定します。論文では 1 文ごとを 1 セグメントとして扱っていますが、考え方自体はより細かい単位にも応用できます。
もし Retrieve=No なら、そのまま通常の LLM のように次の文を生成します。Retrieve=Yes なら検索器を呼び出して候補文書を取り、各文書ごとに並列で続きを生成します。これによって、毎回固定で 5 件検索して全投入する RAG とは違い、必要な場面だけ検索が走る構造になります。
検索結果ごとに関連性と根拠性を点検する
検索した後は、各候補文書について IsRel を出し、その文書が質問に役立つかを見ます。さらに、その文書を使って生成したセグメントに対して IsSup を出し、本当にその文書で支えられているかを見ます。最後に IsUse で応答としての有用性も評価します。
ここが Self-RAG の肝です。従来の RAG は「上位検索文書を入れて 1 本の回答を出す」ので、検索結果の質が悪くても生成器が吸収しきれないことがあります。Self-RAG は、文書ごとに候補生成と自己採点を並行して行うので、関連性は高いが支持が弱い文書や、逆に部分的にしか役立たない文書を弾きやすくなっています。
critic でラベルを作り、generator に自己反省を覚えさせる
学習は 2 段構成です。最初に critic model を作り、各入力・出力ペアに対して reflection token を付ける役を担わせます。論文では GPT-4 によるラベルを使って critic を教師あり学習し、その critic が大規模学習データへ reflection token を付与します。
その後、最終的な generator model を、反省トークンと検索文書が挿入されたコーパスで通常の言語モデル学習として訓練します。つまり PPO や別報酬モデルを推論時に回すのではなく、反省のしかた自体を次トークン予測に蒸留している構造です。これにより、推論時は generator 1 本で完結します。
推論時は soft な再ランキングもできる
Self-RAG は、単にトークンを出して終わりではなく、そのトークン確率を使って候補を並べ替えます。論文ではセグメント単位の beam search を使い、IsRel、IsSup、IsUse の望ましい値の確率を線形結合してスコア化します。
これにより、実運用では重みを変えて挙動を調整できます。たとえば引用精度を重視したいなら IsSup の重みを上げ、自由記述の自然さを優先したいなら IsUse を相対的に重視する、といった使い分けが可能です。論文の面白い点は、これを追加学習なしの推論時設定として扱っていることです。
実験と結果
論文では、Self-RAG が本当に固定検索型 RAG より強いのか、検索なしモデルより良いのか、長文生成や引用付き生成でも効くのかを検証しています。対象タスクはかなり広く、短い事実質問から長文生成まで含んでいます。
何を検証したのか
評価は 6 タスクで行われています。短文の open-domain QA として PopQA と TriviaQA、閉集合タスクとして PubHealth と ARC-Challenge、長文生成として biography generation と ALCE-ASQA が使われています。
指標もタスクに応じて分かれています。QA や分類では accuracy、Biography では FactScore、ASQA では正確性に相当する str-em と ROUGE、文章の流暢さを見る MAUVE、さらに citation precision と citation recall が使われています。つまり、単に答えが合っているかだけでなく、長文の根拠性まで見ています。
全体結果
Self-RAG は 7B と 13B の両方で評価されており、論文の表では非 proprietary モデルの中でほぼ全タスク最良です。13B の Self-RAG は PopQA で 55.8、TriviaQA で 69.3、PubHealth で 74.5、ARC-Challenge で 73.1 を記録しています。Biography の FactScore は 80.2、ASQA では str-em 31.7、ROUGE 37.0、MAUVE 71.6、citation precision 70.3、citation recall 71.3 でした。
7B 版でもかなり強く、PopQA 54.9、PubHealth 72.4、Biography の FactScore 81.2、ASQA の citation precision 66.9 など、高い水準を示しています。特に citation precision と recall は、多くの通常 RAG ベースラインが一桁台から数十台前半にとどまる中で大きく伸びています。
どこが改善されたのか
興味深いのは、検索を足しただけのベースラインよりも、Self-RAG の方が安定して強い点です。たとえば同じ表では、Llama2-FT は PubHealth 64.3、ARC 65.8、ASQA citation precision 5.0、recall 7.5 でしたが、13B Self-RAG はそれぞれ 74.5、73.1、70.3、71.3 まで伸びています。つまり、検索文書を与えるだけではなく、「どの文書を採用し、どこまで根拠とみなすか」を学習したことが効いています。
また、論文中では PubHealth や ARC-Challenge のようなタスクでは、通常の retrieval baseline が検索なし版からあまり伸びない例も示されています。これは、検索器が文書を取ってきても、その利用のしかたが雑だと性能が上がらないことを意味します。Self-RAG はまさにこの穴を埋めようとしている手法です。
アブレーションが示すこと
アブレーションでも傾向ははっきりしています。7B の縮小設定では、Self-RAG の PopQA / PubHealth / ASQA は 45.5 / 73.5 / 32.1 でしたが、検索なし学習の No Retriever では 43.6 / 67.8 / 31.0、reflection token なしの No Critic では 42.6 / 72.0 / 18.1 に落ちています。推論時に単純に top1 文書を取る設定でも PopQA と ASQA が大きく悪化しています。
この結果から言えるのは、Self-RAG の性能は「検索したから」ではなく、「検索の判断」「根拠の採点」「候補の再ランキング」がまとまって効いているということです。特に IsSup を使って支持の強さを見ている点が、引用精度の改善に直結していると読めます。
何に使える？
Self-RAG は、根拠が必要な生成タスクにかなり広く応用できます。特に、毎回検索したいわけではないが、必要なときには確実に根拠を取りたい場面に向いています。
社内ナレッジ検索と業務アシスタント
社内文書 QA では、質問によってはナレッジ検索が必要ですが、定型質問や雑談に近い問い合わせでは不要なこともあります。Self-RAG の adaptive retrieval は、こうした混在ワークロードで無駄な検索を減らしつつ、必要な質問には根拠付きで答える設計に向いています。
引用付きレポート生成
調査レポート、法令要約、競合分析のように、文章だけでなく「どの情報源に基づくか」が重要な用途では、IsSup による支持判定が役立ちます。特に、各文や各セグメント単位で根拠性を見る設計は、引用をただ最後に並べるより信頼しやすい構造です。
RAG エージェントの中間判断
エージェントは検索、要約、ツール呼び出しを何度も挟みます。Self-RAG の考え方は、そのたびに固定検索するのではなく、「今の段階で検索すべきか」をエージェント自身に判断させる設計へ流用できます。論文自体は汎用エージェントを直接扱っていませんが、技術的な延長としてかなり自然です。
高価な検索基盤のコスト抑制
ベクトル検索や Web 検索にコストがかかるシステムでは、検索を減らせるだけでも意味があります。Self-RAG は検索を 0 か 1 で固定せず、閾値で頻度を調整できるため、精度とコストのトレードオフ制御にも使えます。これは SaaS の原価設計でも有効です。
開発や事業へのヒント
この論文から得られる一番大きなヒントは、RAG の改善対象は retriever だけではないということです。検索前、検索中、検索後の判断までモデル化すると、同じ検索器でもかなり性質が変わります。
まずは fixed-top-k を疑う
もし自分で AI アプリを作るなら、最初に見直すべきなのは「とりあえず上位 5 件を毎回入れる」設計です。質問によって必要な検索量は違うので、検索の発火条件や停止条件を持たせるだけでも、レイテンシ、トークン消費、ノイズ混入の 3 つを同時に改善できる可能性があります。
根拠性を relevance とは別に扱う
多くの実装では「関連文書が取れたか」しか見ませんが、実務では「その文書が回答の主張を本当に支えているか」の方が重要です。Self-RAG の IsRel と IsSup を分ける発想は、そのまま reranker や answer verifier の設計に流用できます。小規模プロダクトでも、最低限この 2 層は分けて評価する価値があります。
推論時パラメータをプロダクト設定にできる
論文では IsSup などの重みを変えて挙動を調整できます。これは、プロダクト側で「厳密モード」「高速モード」「探索モード」のような応答スタイルを分ける設計につながります。学習済みモデルを複数持たなくても、推論ポリシーで体験を切り替えられるのは実装上かなり扱いやすいです。
小さく始めるなら full Self-RAG でなくてもよい
Self-RAG 全体をそのまま再現するのは重いです。critic の教師データ作成や特別トークン付き学習が必要だからです。ただし発想だけでも活かせます。たとえば、検索要否判定器、根拠支持判定器、回答有用性判定器 を別モジュールで作り、後から 1 つに寄せていく構成は現実的です。
限界
Self-RAG には明確な限界もあります。まず学習コストが軽くありません。critic を作るための教師データ収集、retriever を挟んだデータ拡張、reflection token を含む再学習が必要で、普通の prompt-only RAG より導入ハードルは高いです。
また、論文では critic ラベルの初期生成に GPT-4 を使っています。最終推論では critic 不要でも、学習時の品質はこのラベルに依存します。したがって、完全再現や別ドメイン適用では、反省トークンの付け方が性能を大きく左右する可能性があります。
実運用では、セグメントごとに検索判断と候補比較を行うため、単純な 1 回検索型 RAG より推論フローが複雑です。検索回数は減らせても、beam search や候補採点の実装難度は上がります。高スループットな本番基盤では、品質改善と運用複雑性のどちらを取るか見極めが必要です。
さらに、citation precision を強く追うと出力が短くなったり、創造性が落ちたりする可能性があります。論文でも IsSup の重みを上げると citation precision は改善する一方、MAUVE とのトレードオフが出ると分析しています。つまり、正確さを上げるほど何らかの生成自由度を失う場面はあります。
よくある質問
Q. Self-RAG は普通の RAG と何が一番違うのですか？
A. 一番の違いは、検索を固定前処理ではなく生成中の判断として扱う点です。毎回同じ本数を検索するのではなく、必要なときだけ検索し、しかも検索結果が relevant か、回答を support しているかまでモデル自身が見ます。
Q. 既存の RAG システムにも応用できますか？
A. そのまま再学習なしで完全移植するのは難しいですが、考え方は十分応用できます。まずは検索要否判定、根拠支持判定、回答再ランキングの 3 つを分けて追加するだけでも、固定 top-k RAG より実務的な品質改善が見込めます。
Q. Self-RAG はエージェントにも向いていますか？
A. 向いています。特に、各ステップで検索が本当に必要かを見極めたいエージェントと相性がよいです。ただし、論文自体は汎用エージェント実験ではないので、ワークフロー設計への応用は一部推測を含みます。
Q. なぜ citation precision が高くなるのですか？
A. Self-RAG は IsSup で「この文はこの根拠に支えられているか」を見ながら候補を選ぶためです。関連文書があるだけではなく、文単位で支持の強さを採点しているので、引用と主張のズレが減りやすくなります。
Q. 小規模チームが今すぐ取り入れるならどこから始めるべきですか？
A. まずは fixed-top-k をやめて、検索要否の判定を入れるところからです。その次に、回答生成後に根拠支持を別モデルまたはルールで点検する構成を足すと、Self-RAG の価値を比較的低コストで試せます。
今日の学び
この論文は、RAG が毎回同じように検索して同じように文書を流し込むため、不要検索や根拠の弱い生成を起こしやすいという課題を扱いました。これに対して Self-RAG は、検索の要否判断、文書の関連性評価、根拠支持の点検、有用性評価を reflection token として学習し、生成そのものの一部として扱いました。
ここから得られるヒントは、RAG の改善は検索器の精度向上だけでは足りないということです。検索をいつ使うか、どの根拠を採用するか、どの出力を残すかまで設計して初めて、実用的で信頼しやすい生成に近づきます。固定フローの RAG から、判断可能な RAG へ進むことが次の実装テーマだとわかります。