今回の論文
今回取り上げるのは、Shi-Qi Yan、Jia-Chen Gu、Yun Zhu、Zhen-Hua Ling による論文「Corrective Retrieval Augmented Generation」です。公開元は arXiv、研究分野は RAG、情報検索、長短文生成、検索品質評価です。URL は https://doi.org/10.48550/arXiv.2401.15884 です。
この論文を選んだ理由は、RAG の弱点である「検索が外れたときに、むしろ誤答を増やす」という実務上かなり大きい問題を正面から扱っているからです。社内検索、FAQ、調査支援、エージェントのツール利用など、検索を前提にした AI アプリは多いので、検索結果をそのまま信じずに補正するという発想は、そのまま開発に応用しやすいです。
どんな技術か
CRAG は、RAG の前提である「取ってきた文書はだいたい正しいはず」という楽観をやめて、まず検索結果の質を判定し、その判定に応じて次の行動を切り替える技術です。
通常の RAG は、検索した上位文書をそのまま LLM に渡して回答を作ります。しかし、検索結果にノイズが多いと、LLM は正しい知識を補うどころか、間違った文書に引っ張られて誤答しやすくなります。CRAG はここに「検索結果の自己点検」を差し込みます。
具体的には、検索文書が十分よいなら、その中の重要な断片だけを抽出して使います。逆に、検索結果が悪いなら、外部の Web 検索へ切り替えて知識を取り直します。判断が微妙なときは、内部検索と外部検索の両方を使います。要するに CRAG は、「検索してから答える」のではなく、「検索結果を査定してから、使い方を変えて答える」RAG です。
課題
この技術が解決しようとしているのは、RAG が検索品質に強く依存しすぎるという課題です。
何が難しいのかというと、生成モデルは入力文脈をかなり素直に信じてしまうからです。検索で関連性の低い文書が混ざると、モデルは正しい断片とノイズを自力で切り分けきれず、もっともらしい誤答を生成することがあります。これは、モデル自体が高性能でも避けにくい問題です。
既存の方法にも限界があります。標準的な RAG は、上位 k 件を取得してそのまま連結するだけなので、検索が少し外れただけで文脈全体の質が悪化します。高度な RAG でも、「検索するかどうか」の判断には踏み込んでいても、「検索結果が怪しいならどう補正するか」まで設計されていないことが多いです。
なぜこの課題を解く必要があるかというと、実際の AI システムでは検索失敗が珍しくないからです。社内文書は更新漏れや表記ゆれがありますし、業務データは不完全ですし、ユーザー質問も曖昧です。結果として、retriever が完全に正しい文書だけを返す前提は現実的ではありません。
実運用では、ここがそのまま UX の差になります。FAQ ボットが誤った手順を案内する、社内検索アシスタントが古い仕様を出す、リサーチエージェントが関係ない資料を根拠にする、といった問題はどれも検索品質の揺れから起きます。CRAG は、その揺れを前提にした設計です。
用語解説
- RAG（Retrieval-Augmented Generation）
- 外部知識を検索して LLM の入力へ追加する仕組みです。この記事では、RAG が便利である一方、検索結果の質が悪いとそのまま誤答要因になる点が重要です。
- Retriever
- 質問に関連しそうな文書を探して返す検索器です。CRAG は生成器そのものより、この retriever の出力品質が不安定なときにどう補正するかへ主眼を置いています。
- Knowledge Strip
- 文書を細かく分解した知識断片です。CRAG は文書全体を丸ごと使うのではなく、この粒度まで分解して必要な部分だけ再構成することでノイズを減らします。
- Retrieval Evaluator
- 検索結果が質問に対してどれだけ妥当かを採点する軽量モデルです。CRAG の中核で、ここがあることで「そのまま使う」「捨てて再検索する」「両方使う」を切り替えられます。
- Query Rewriting
- ユーザー質問を検索エンジン向けのキーワード列へ変換する処理です。CRAG では外部 Web 検索を使う際に導入されており、検索補正の精度に関わります。
技術の仕組み
CRAG の面白さは、巨大な新モデルを学習するのではなく、RAG パイプラインに補正レイヤーを差し込んで挙動を変えている点です。構造としては比較的シンプルですが、実運用で効く論点がかなり詰まっています。
基本アイデア
論文の基本アイデアは、検索結果を「正しい前提知識」として即採用しないことです。まず質問と各文書の組み合わせを採点し、その結果に応じて次のアクションを変えます。これにより、検索が当たっているときはそのまま活かし、外れているときは早めに別ルートへ逃がせます。
この発想は、検索精度を完璧に上げるよりも、検索失敗に強い生成系を作る考え方だと言えます。実務でも、retriever を常に最適化し続けるのは難しいので、失敗時のフェイルセーフを用意する価値は大きいです。
検索結果を採点する Retrieval Evaluator
CRAG では、質問と各検索文書を 1 組ずつ入力にして、関連性スコアを出す軽量 evaluator を使います。論文では T5-large を fine-tune しており、各文書について -1 から 1 の範囲で関連性を見積もります。
重要なのは、これを生成モデル本体にやらせていないことです。著者らは ChatGPT に関連性判定をさせる比較も行っていますが、専用 evaluator のほうが明確に高精度でした。つまり、検索結果の良し悪しは「ついでに LLM に聞く」より、専用の判定器として切り出したほうが安定しやすいという示唆があります。
3つのアクション分岐
CRAG は evaluator のスコアに上限閾値と下限閾値を設け、各検索文書を 3 つの状態に振り分けます。
Correct
少なくとも 1 件でも十分に高いスコアの文書があれば、検索は「使える」とみなします。ただし、その文書を丸ごと LLM に渡すのではなく、重要な箇所だけを抽出して使います。
Incorrect
すべての検索文書が低スコアなら、内部検索は失敗したと判断します。この場合はその結果を捨て、外部の Web 検索へ切り替えます。論文実装では Google Search API を使って URL を取り、そのページ内容を再度取り込みます。
Ambiguous
どちらとも言えない中間状態では、内部検索で取った知識と外部 Web から取った知識を併用します。慎重な fallback であり、完全 discard もしなければ完全 trust もしない設計です。
この 3 分岐はかなり実践的です。現場では「検索成功」か「検索失敗」かを二値で切ると扱いにくく、微妙なケースが大量に出ます。Ambiguous を設けることで、RAG の挙動を急に不安定にしないようにしています。
文書をそのまま使わず、Knowledge Strip に分解する
検索結果が使えると判断されたとしても、文書全体を入れるとノイズが多いままです。そこで CRAG は各文書を細粒度の knowledge strip に分解し、それぞれを evaluator でもう一度採点します。
そのうえで、関連性の低い strip を落とし、残った strip だけを元の順序でつなぎ直して generator に渡します。論文はこれを decompose-then-recompose と呼んでいます。RAG における「文書の top-k 取得」と「文脈圧縮」の中間にある操作だと考えるとわかりやすいです。
ここでの重要な工夫は、文書レベルだけでなく、文書内の情報粒度まで見ていることです。検索が当たっていても、文書全体の大半は不要ということはよくあります。CRAG はそこをそのまま削ります。
Web 検索で外部知識を補う
内部コーパスだけでは、そもそも正しい文書が存在しないことがあります。CRAG はこの状況を前提に、外部 Web 検索を補助知識源として使います。
論文では、質問を ChatGPT で検索向けキーワードへ書き換え、Google Search API で URL 群を取得し、ページ内容を抽出してから再び knowledge refinement をかけています。つまり、外部検索も「取ってきて終わり」ではなく、最終的には内部検索と同じく、必要部分だけを抽出して generator に渡します。
この設計は、いまのエージェント実装でもかなり参考になります。ツールを増やすだけでなく、ツール結果の品質査定と要約圧縮をセットで置くべきだ、ということです。
実験と結果
論文では、CRAG が標準 RAG や Self-RAG より本当に強いのか、また補正ロジックの各部品が効いているのかを検証しています。短文 QA だけでなく、長文生成や判断タスクも含めているので、応用範囲の広さが見えやすいです。
何を検証したのか
主な検証は 3 つです。1 つ目は、標準 RAG と比べて精度が上がるかです。2 つ目は、Self-RAG のような既存の高度な RAG に後付けしても改善するかです。3 つ目は、Correct、Incorrect、Ambiguous の分岐や、文書分解、検索語書き換えといった構成要素が本当に寄与しているかです。
どんなデータセットや評価指標を使ったのか
評価には 4 つのデータセットが使われています。PopQA は短文の知識質問で、指標は Accuracy です。Biography は人物伝記を長文生成するタスクで、指標は FactScore です。PubHealth は医療 claim の真偽判定、Arc-Challenge は科学系の多肢選択問題で、どちらも Accuracy が使われています。
つまり、単一の factoid QA だけではなく、短文回答、長文生成、真偽判定、選択式問題まで見ています。これは「検索が外れたときの悪影響」はタスクを問わず起きる、という論文の立場に合っています。
標準 RAG と Self-RAG に対してどう改善したか
結果を見ると、CRAG は標準 RAG に対して一貫した改善を出しています。たとえば SelfRAG-LLaMA2-7b を generator にした構成では、PopQA で RAG の 40.3 から CRAG は 59.3 に上がり、Biography では 59.2 から 74.1、PubHealth では 39.0 から 75.6、Arc-Challenge では 46.7 から 54.8 でした。
Self-RAG に対して後付けした Self-CRAG も改善しています。同じ SelfRAG-LLaMA2-7b 構成では、PopQA が 54.9 から 61.8、Biography が 81.2 から 86.2、PubHealth が 72.4 から 74.8 へ伸びています。Arc-Challenge は 67.3 から 67.2 とほぼ同等で、すべての条件で劇的改善というわけではありませんが、少なくとも大きく崩さずに他タスクを押し上げています。
ここから言えるのは、CRAG は「新しい generator を置き換える技術」ではなく、「既存の RAG 系に差し込める補正層」として価値があるということです。論文どおり plug-and-play 的に使える余地があります。
どの部品が効いていたのか
アブレーションでも、各部品を外すと性能が落ちています。PopQA の評価では、Correct、Incorrect、Ambiguous のどれを外しても精度が低下しました。つまり、3 分岐は飾りではなく、それぞれ役割があります。
さらに、knowledge refinement を外して元文書をそのまま generator に渡すと、SelfRAG-LLaMA2-7b ベースの CRAG は 59.3 から 47.0 まで下がっています。検索語の rewriting を外しても 56.6、外部知識の selection を外しても 53.8 へ落ちています。外部 Web 検索を使うだけでは足りず、取ってきた情報を絞る工程まで効いていることがわかります。
Retrieval Evaluator 自体の精度
Retrieval evaluator 単体の比較も興味深いです。PopQA 上での検索結果品質判定では、論文の T5 ベース evaluator は 84.3% の Accuracy を出し、ChatGPT は 58.0%、Chain-of-Thought を付けても 62.4%、few-shot を付けても 64.7% でした。
この結果は、RAG パイプラインの前段に置く判定器は、小さくても専用学習したほうが強い可能性を示しています。何でも大きな汎用 LLM に任せるのではなく、判定タスクは専用モジュール化したほうがよいという実装指針になります。
何に使える？
CRAG は、検索品質のばらつきがそのまま製品品質に響くアプリでかなり使いやすいです。特に「とりあえず top-k を突っ込む」構成から脱したい場面に向いています。
社内ドキュメント検索
社内 Wiki、議事録、運用手順書、仕様書の検索では、完全一致しない文書が混ざることが多いです。CRAG 的な evaluator を入れれば、検索結果をそのまま信じず、怪しいときは別索引や Web、あるいは人手確認フローに逃がせます。誤った手順提示を減らしやすいです。
RAG ベースのカスタマーサポート
FAQ ボットやサポート支援では、古い記事や不完全なヘルプ文書が混ざると危険です。CRAG のように検索結果の質を先に見てから、低品質なら検索し直す設計にすれば、もっともらしい誤案内を抑えやすくなります。
調査エージェントやリサーチ支援
エージェントが検索ツールを呼び出して調査する場合も、最初の検索が外れることは普通にあります。CRAG の考え方を使えば、検索結果の品質を数値で見積もり、低いときだけ再検索や別ツールを起動する制御ができます。これはエージェントの無駄な深掘りを減らすのにも効きそうです。
ハイブリッド検索の制御層
ベクトル検索、BM25、ナレッジグラフ検索、Web 検索など複数の検索経路を持つシステムでは、CRAG はそれらを切り替える制御層として使えます。論文では内部検索と Web 検索の切り替えですが、実務では社内DB検索、チケット検索、仕様書検索などに広げやすいです。これは論文の設計を実務に引き寄せた応用案です。
開発や事業へのヒント
この論文の価値は、RAG 改善を「より良い埋め込みモデルを選ぶ」話だけに閉じていないことです。検索後の制御と知識圧縮にも十分な改善余地があると示しています。
RAG の本当の弱点は retrieval miss だと考える
自分で AI アプリを作るなら、まず「誤答は generator のせいか、retrieval miss のせいか」を切り分けるべきです。CRAG は後者に対する設計です。ログを見ると検索がズレているケースが多いなら、プロンプト改善より先に evaluator 層を入れる価値があります。
検索結果をそのまま全部渡さない
論文の decompose-then-recompose は、実装の粒度をかなり現実的にしてくれます。文書単位の top-k 検索だけでは粗すぎるので、その後に文や段落レベルで選別するだけでも、コンテキスト効率と精度の両方を改善できる可能性があります。小規模プロダクトでも取り入れやすい部分です。
fallback 設計は最初から入れておく
社内コーパスだけで全質問に答える前提は崩れやすいです。CRAG は、内部検索がダメなら外部検索へ切り替える経路を最初から設計しています。実務では、Web 検索の代わりに別データソース、再検索、再ランク、ユーザーへの確認質問などを fallback にできます。
専用の小型判定器を持つ価値
検索品質判定のような限定タスクは、巨大モデルへの丸投げより、専用の軽量判定器として切り出したほうがよい場合があります。これはコストだけでなく、再現性やテスト容易性の面でも重要です。RAG を SaaS として提供するなら、こうした周辺モジュールが差別化要素になりえます。
今後注目すべき方向性
今後は、RAG を単なる「検索+生成」ではなく、「検索評価+補正+圧縮+生成」のパイプラインとして設計する流れが強まりそうです。特にエージェント文脈では、どのツール結果を採用し、どれを捨てるかの判断が重要になるので、CRAG 的な考え方はさらに広く効くはずです。ここは論文からの自然な延長としての考察です。
限界
CRAG にも明確な限界があります。まず、追加モジュールが増えるので構成が複雑になります。retrieval evaluator の学習、閾値調整、knowledge strip への分解、検索語書き換え、外部検索連携まで含めると、単純な RAG より運用負荷は高いです。
また、evaluator の精度に依存します。ここが誤判定すると、本来使える内部文書を捨てたり、逆にノイズを残したりします。つまり、RAG の弱点を補う代わりに、新たに「判定器の品質」という依存先が増えます。
外部 Web 検索にも注意が必要です。論文実装では Google Search API と Web ページ抽出を使っていますが、実運用ではレイテンシ、コスト、アクセス制限、ページの安定性、出典の信頼性管理が問題になります。社内向けプロダクトでは、そのまま同じ構成を入れにくい場合もあります。
さらに、論文の実験は 2024 年時点のモデルとデータセットに基づいています。最新の長文モデルや強い reranker を組み合わせた場合に同じ改善幅が出るかは別途検証が必要です。CRAG の考え方は有効でも、現代の実装では構成要素を置き換えて再設計する前提で見るのがよさそうです。
よくある質問
Q. CRAG は普通の RAG と何が一番違うのですか？
A. 一番の違いは、検索結果をそのまま信用しない点です。普通の RAG は上位文書をそのまま generator に渡しがちですが、CRAG はまず検索品質を査定し、その結果に応じて内部知識を絞るか、外部検索へ逃がすかを決めます。
Q. CRAG は reranker と同じものですか？
A. 似ている部分はありますが、同じではありません。reranker は主に文書順位の付け直しですが、CRAG は順位調整だけでなく、検索失敗時の分岐、文書内の知識断片選別、外部検索への切り替えまで含みます。より上位の制御ロジックです。
Q. 小規模な RAG アプリでも取り入れられますか？
A. 取り入れられます。フルの CRAG を再現しなくても、検索結果の品質スコアを出す、低スコア時だけ再検索する、長文文書を段落単位で再選別する、といった部分導入でも価値があります。特に誤答コストが高い業務アプリでは有効です。
Q. 外部 Web 検索を必ず使う必要がありますか？
A. 必須ではありません。論文では Web 検索を採用していますが、実務では別の社内データソース、専門DB、キャッシュ済みドキュメント群、あるいはユーザーへの確認質問でも代替できます。重要なのは「検索失敗時に別経路を持つ」ことです。
Q. CRAG の導入でまず検証すべきことは何ですか？
A. まずは、自分のシステムで誤答の何割が retrieval miss に起因しているかを見るべきです。その比率が高いなら、evaluator 層や fallback 分岐が効く可能性があります。逆に generator の推論ミスが主因なら、CRAG だけでは十分でないかもしれません。
今日の学び
この論文は、RAG が検索結果の質に依存しすぎて、検索が外れると誤答しやすくなる課題を扱いました。そこに対して、検索結果を評価する retrieval evaluator、3 つのアクション分岐、knowledge strip への分解と再構成、必要時の Web 検索という補正レイヤーで解こうとしました。
ここから得られるヒントは、RAG の改善は検索器の精度向上だけではないということです。検索結果を査定し、怪しいときは別経路へ逃がし、使える部分だけを高密度に渡す設計は、社内検索、FAQ、エージェント、調査支援など幅広い AI アプリでそのまま活かせます。