RAGは本当に不要になる？ IBMの「STAIR」とハルシネーション65分の1を読み解く
「RAGはもう終わり。IBMが、ハルシネーションを65分の1に減らす検索技術を開発した」
そんな趣旨の投稿をXで見かけました。RAGを使ったシステムを作っている人なら、気になる話です。
本当に、これまでの仕組みは不要になるのでしょうか。
元の研究は、IBMの研究者らによる STAIR（STructure Aware Information Retriever）。論文を読むと、目次を使って情報を探す工夫に加え、「65分の1」という数字の意味も見えてきます。
私の読み取りでは、この研究はRAGを不要にする根拠にはなりません。RAGの検索部分をどう改善できるか、という観点で読むと参考になります。
2026年10月28日時点の公開資料に基づく解説です。STAIR論文はarXivのv2（2026年10月13日改訂）を参照しています。数値は著者らの報告で、筆者による再現実験は行っていません。論文の書誌情報
まず、RAGは「探す」と「書く」の組み合わせ
RAGは、Retrieval-Augmented Generationの略。モデルが覚えている知識に加え、検索で取り出した情報を使って文章を生成する考え方です。RAGの原論文
例えば、社内の休暇制度について質問されたとします。関連する就業規則を探し、その内容を材料に回答する。この流れを分けてみます。
- ① 質問を受け取る例：「半日単位で有給休暇を取れる？」
- ② 関連する情報を探す例：就業規則の「年次有給休暇」の節を選ぶ。STAIRを活用するとしたら、この検索工程。
- ③ 選んだ節の本文を取り出す休暇の条件や申請方法など、回答の根拠にする文章を用意する。
- ④ 根拠を使って回答を書く取り出した本文を読んで説明する。検索先が正しくても、回答内容の確認は別に必要。
ここで重要なのは、検索方法と回答生成を分けて考えられることです。検索のやり方が変わっても、それだけで「検索した情報を使って答える」という仕組み全体が不要になるわけではありません。
RAGそのものの基本は、以前のRAGの仕組みと開発者向けサービスを整理した記事でも紹介しています。
STAIRの工夫は「目次を使って探す」こと
分厚い本で調べ物をするとき、私たちは目次を見ます。「休暇」の章、その中の「有給休暇」の節、と範囲を絞ってから本文を読むはずです。
STAIRも、文書の目次構造を検索に生かします。質問と目次を入力し、答えがありそうな末端の節を出力するように、言語モデルを追加学習する手法です。論文4節
公開実装も、文書から学習データを準備し、モデルを学習させ、検索結果を評価する構成になっています。資料を置くだけで使える万能な検索サービスとは違い、学習・評価を伴う仕組みです。著者らの公開実装
「検索後に内容の真偽を判定して、嘘を完全に取り除くフィルター」と捉えると、役割を取り違えてしまいます。
「65分の1」は、何の間違いが減った数字？
ここが、今回いちばん気になった点です。
論文では、ハルシネーションを有効な末端の節ではない検索先を生成することと定義しています。例えば、目次にない節名を作ってしまうようなケースです。
比較対象はDifferentiable Search Index（DSI）という、モデルに検索先を生成させる手法です。6.2節の報告値を並べると、次のようになります。
- 比較対象：DSI3.25%有効な末端の節でない
検索先を出した割合 - 提案手法：STAIR0.05%同じ種類の
誤生成の割合 - 報告値の比65分の13.25 ÷ 0.05 ＝ 65
回答文の誤情報率ではない - 正しい節を1位に選ぶ82.6%STAIRのRecall@1
別の指標として評価
「最新のRAGシステム全般と比べて、回答の嘘が65分の1になった」という実験ではありません。論文5.1節・6節
数字の改善は注目に値します。ただし、その意味を広げすぎないことも大切です。
「存在する節を選ぶ」と「正しく答える」は違う
就業規則の例に戻って、間違いを3つに分けてみます。
A 存在しない検索先を作る
目次にない「半日休暇の特別規定」という節名を出す。今回の「65分の1」は、このような検索先の誤生成に関する数字。
B 存在するが、違う節を選ぶ
有給休暇を聞かれているのに「育児休業」の節を選ぶ。有効な検索先でも、質問に合うとは限らない。
C 正しい節を読んでも、回答を間違える
規則に条件が書いてあるのに「誰でも無条件で取れる」と回答する。検索先の妥当性だけでは防げない。
図書館で考えると、Aは「存在しない本の請求記号を案内する」、Bは「実在する別の本を案内する」、Cは「正しい本の内容を読み違えて説明する」に近いでしょう。
案内先の実在率が高まることは有益です。でも、その数字をそのまま「説明が正しい確率」に置き換えることはできません。
STAIRのRecall@1は82.6%と報告されています。これは正しい節を検索の1位に選べたかを見る指標で、最終回答の正答率ではありません。論文表4
どんな資料でも、そのまま同じ効果が出る？
論文の評価は、6分野・18冊の書籍から作ったSearchTomeが中心です。著者らも、全体構造がある文書に評価が限られること、大規模な企業データでの検証が今後の課題であることを述べています。論文3節・8節
実際の社内資料には、見出しが整っていないメモも、更新が頻繁な手順書も、読む人によって閲覧権限が異なる文書もあります。
導入を検討するなら、私は次の点を確かめたいと思います。これは論文の実証結果ではなく、運用を考えるうえでの確認事項です。
- 資料が更新されたら追従できるか。 追加学習の頻度やコストも含めて考える。
- 答えのない質問を扱えるか。 どれかの節を選ぶ能力と、「この資料では答えられない」と判断する能力を分けて試す。
- 利用者の権限を守れるか。 検索の正確さとは別に、見せてよい情報だけを扱う設計を確認する。
- 最後の回答まで正しいか。 検索先・取得した本文・回答文を、それぞれ評価する。
手元の資料で、これまでの検索方法と比較して初めて、導入する価値を判断できます。
RAGを作る側が持ち帰れるヒント
この研究から私が持ち帰りたいのは、文書の構造も、情報を探すための手掛かりになるという視点です。
例えば、手順書の「申請」という見出しだけを見るより、「休暇制度 → 有給休暇 → 申請」という親子関係が分かるほうが、人には探しやすくなります。検索に渡す情報を設計するときも、こうした関係を残す価値はありそうです。
ただし、既存システムで見出しを残す改善と、STAIRを実装することは同じではありません。前者はこの研究から着想を得た実務上の工夫で、同じ性能が得られると保証されたものでもありません。
「65分の1」という数字に出会ったら、まずは何を、何と比べて、どの条件で測ったのかを見る。そのうえで、自分の仕事に使える工夫を探す。
STAIRは、その読み方を練習する題材としても興味深い研究でした。