6月30日、Soroush Hashemifar らが「Diagnosing and Repairing Factual Errors in RAG under Budget Constraints」と題した論文を公開した。予算制約のある実運用環境でRAGの事実誤りを診断・修正するモデル非依存フレームワーク「D2R-RAG」を提案する内容で、「まず原因を診断し、原因に応じた最小コストのアクションを取る」という設計思想が核心にある。
RAGはなぜ本番環境で壊れるのか
RAG（Retrieval-Augmented Generation）は、LLMの回答を外部ドキュメントに基づかせることで事実精度を高める手法として広く使われている。しかし、実運用に乗せると意外ともろい。
失敗パターンは主に2種類だ。
- 検索の失敗：関連する証拠が取得できない、または取得されても関連性が低い
- 生成の失敗：証拠は取得できているのに、LLMがその内容を忠実に反映した回答を生成しない
既存の対策の多くは、モデルのファインチューニングや内部シグナルへのアクセス（ログitトークン確率など）を前提としていた。これはクローズドな環境でしか使えず、APIで提供されるブラックボックスモデルには適用できない。また、単純に「失敗したら上位モデルにエスカレーション」という戦略は、レイテンシとコストが青天井になる。
D2R-RAGの設計思想：診断してから直す
本論文が提案するD2R-RAG（Diagnose-to-Repair RAG）は、以下の2ステップで動作する。
1. 軽量な失敗診断（Diagnose）
クエリ・取得された証拠・生成された回答という外部から観察可能なシグナルのみを使って、失敗の種類を分類する。内部状態へのアクセスは不要で、ブラックボックスAPIでも動作する。この分類結果を「失敗シグネチャ（failure signature）」と呼ぶ。
失敗シグネチャとは、「検索は成功したか」「証拠と回答の整合性はあるか」といった観察可能な指標の組み合わせによって、失敗の種類を一意に特定するラベルのようなものだ。たとえば「証拠は取得できているが回答が証拠と矛盾している」ならば生成側の失敗と診断され、「取得された文書がクエリとほぼ無関係」ならば検索側の失敗と診断される、という具合に機能する。
2. 制約付き修正アクション選択（Repair）
失敗シグネチャに応じて、あらかじめ定義された小さな修正アクションセットの中から、明示的なレイテンシ制約とVRAM制約を満たす範囲で最適な対処を選択する。単一の「何でも解決策」を使うのではなく、診断結果に応じてアクションを切り替えることでコスト効率を高める。
このアーキテクチャの核心は「無駄に重いアクションを取らない」という設計にある。検索の問題なのに再生成コストをかけても意味がなく、逆もしかりだ。
実験結果：FEVERとHotpotQAで検証
評価は2つのベンチマークで行われた。
- **FEVER**：Wikipedia上のクレームが事実かどうかを検証する事実検証ベンチマーク。検索精度と照合能力が問われる
- **HotpotQA**：複数のドキュメントをまたいで推論する必要があるマルチホップ質問応答ベンチマーク
結果として、複数の計算予算（compute budget）のレベルにわたって、最近のベースライン手法を上回る精度と効率のトレードオフを達成した。特定の単一予算に最適化するのではなく、複数の予算レベルで安定して良好な結果を示している点が実用上の強みだ。
論文中では「精度と効率のトレードオフ（accuracy--efficiency trade-offs）」という表現が繰り返し使われており、コスト意識が設計の根幹にあることがわかる。
実装面での注意点
コードはGitHub（CyberScienceLab/D2R-RAG）で公開されている。
論文が強調する「モデル非依存（model-agnostic）」という特性は、GPT-4oやClaude 3.5などのAPIモデルを使った構成でも原理上は適用可能であることを意味する。ただし、実験でどのモデルをバックエンドとして使用したかの詳細はアブストラクトには記載がなく、論文本文の確認が必要だ。
また、修正アクションのセットが「small set（小さなセット）」と表現されており、アクション空間を意図的に絞っている。これはレイテンシ予測を安定させるための設計判断と見られる。
なお、本論文のarXiv番号は「2606.29377」であり、通常の命名規則（YYMM.NNNNN）に照らすと2026年6月公開の論文として整合する。枝番の数字が大きいため違和感を覚える読者もいるかもしれないが、投稿数の多い月では5桁の枝番が大きな値になることは珍しくない。
まとめ
D2R-RAGが解こうとしている問題は、RAGを本番に乗せているエンジニアなら誰もが直面したことのある「なぜこの回答は間違っているのか」という問いだ。その原因を診断せずに一律の修正を当てても効果は薄く、かつコストがかかる。診断を先に行い、原因に応じた最小コストのアクションを取るというアプローチは、プロダクション環境での実装指針として参考になる。
詳細はDiagnosing and Repairing Factual Errors in RAG under Budget Constraintsを参照していただきたい。
