RAGのアキレス腱：情報は見つけられても、正しく集約できるとは限らない

要点

RAGは、答えがいくつかの特定の文章内に存在する場合に高い効果を発揮します。

しかし、ユーザーがトレンドの把握、事例数の集計、あるいは数千件の文書を横断した情報集約を求める場合、システムには単なる検索以上の処理が必要です。

GraphRAGは、AIがエンティティを特定し、それらの関係性を理解するのに役立ちます。

しかし、

「どの情報同士が関連しているか」を理解することと、「いくつあるのか、合計はいくらなのか、何パーセントなのか」を正確に算出することは同じではありません。

特に、元の文書に集計済みのレポートが存在しない場合、集約処理は単なる検索問題ではなく、大規模なデータ処理問題になります。

RAGは実際にどれだけのデータを見ているのか？

一般的なRAGシステムは、次のような流れで動作します。

文書

文書を小さなチャンクに分割する
質問との関連性が高いチャンクを検索する
検索したチャンクをAIモデルに渡す
回答を生成する

この方法は、次のような具体的な質問に適しています。

「返金ポリシーの有効期間はどのくらいですか？」

答えが一つの文章内に存在する場合、システムはその文章を正しく取得するだけで済みます。

では、次の質問はどうでしょうか。

「過去1年間で、顧客から最も多く寄せられた苦情を3つ挙げてください」

正確に回答するためには、AIは十分な量のデータを確認し、類似した意見をグループ化し、重複を除外し、それぞれのカテゴリの出現頻度を比較する必要があります。

これは、単に関連する一つの文章を見つける問題ではありません。

論文『From Local to Global: A Graph RAG Approach to Query-Focused Summarization』では、このような要求を「グローバル質問」と呼んでいます。

グローバル質問とは、文書集合全体の大きな傾向や全体像を理解する必要がある質問です。

著者らは、従来のRAGがこの種の質問を苦手とする理由について、少数の関連文章を検索する問題というよりも、質問に基づいて文書全体を要約する問題に近いからだと説明しています。

出典：
https://arxiv.org/abs/2404.16130

GraphRAGは分散した情報をつなぐ

ベクトル検索の制約の一つは、文書の各チャンクが比較的独立した単位として扱われることです。

しかし、実際の情報は多くの場合、関係の連鎖として存在します。

顧客A

製品Xを購入

決済エラーが発生

カスタマーサポートに連絡

返金を要求

これらの情報は、複数のメール、サポートチケット、レポートに分散している可能性があります。

GraphRAGは、次の方法でこの問題に対応します。

文書からエンティティと関係性を抽出する
ナレッジグラフを構築する
関連するエンティティをコミュニティに分類する
各コミュニティの要約を生成する

この構造により、データ全体を俯瞰する必要がある質問を、より適切に処理できるようになります。

『From Local to Global』の実験では、定性的かつグローバルな質問に対して、GraphRAGは基本的なRAGよりも包括的で多様な回答を生成しました。

簡単に言えば、GraphRAGはAIが次のようなことを理解するのに役立ちます。

誰と誰が関係しているのか
どの出来事がどの製品と関係しているのか
どのトピックが一緒に出現しやすいのか
文書全体に分散した問題がどのようにつながっているのか

これは、意味的な類似度だけに基づいて文章を検索する方法と比べて、大きな進歩です。

関係性を理解できても、正確に計算できるとは限らない

ある企業が2万件のサポートチケットを保有しており、次の質問をするとします。

「前四半期に決済エラーを経験した顧客は何人いましたか？」

正しく回答するためには、システムは次の処理を行う必要があります。

関連するすべてのチケットを特定する
決済エラーとログインエラー、返金問題を区別する
複数のチケットが同じインシデントを指しているか判断する
重複したデータを除外する
正しい期間でフィルタリングする
データセット全体を対象に件数を集計する

GraphRAGは、顧客、取引、製品、インシデントを結びつけることができます。

しかし、初期のGraphRAGアーキテクチャでは、自然言語で書かれたコミュニティ要約を統合することでグローバルな回答を生成します。

元の研究は、GraphRAGが文書集合全体に対して、次のような演算を正確に実行できることを証明するために設計されたものではありません。

COUNT
SUM
AVG
パーセンテージの計算
時系列の数値比較

したがって、次のように考えるのは正確ではありません。

「GraphRAGはグローバル質問に強いのだから、文書全体に含まれるあらゆる数値も正しく計算できるはずだ」

トレンドを要約することと、正確な数値を算出することは、異なる問題です。

論文『Structured RAG for Answering Aggregative Questions』では、多くのRAGシステムが、必要な情報がコーパスの一部にしか存在しないケースに最適化されていると説明しています。

そのため、多数の文書から事実を収集し、それらを集約する必要がある質問では、性能が低下します。

同研究で提案されたS-RAGは、データ取り込みの段階で構造化された表現を作成し、自然言語の質問を、その構造に対する形式的なクエリへ変換します。

出典：
https://arxiv.org/abs/2511.08505

文書に集計済みの情報が存在しない場合

文書内に次のような要約がすでに存在する場合、RAGの仕事は比較的簡単です。

「第3四半期には1,240件のサポートリクエストがあり、そのうち28％が決済に関するものでした」

この場合、システムは該当する文章を取得するだけで済みます。

しかし、実際のデータは、次のような個別レコードだけで構成されていることが少なくありません。

チケット1：カードで支払いができない

チケット2：代金は引き落とされたが、注文が確定されていない

チケット3：同じ金額が二重に請求された

……

チケット20,000

決済エラーの総件数を直接記載した文書は存在しません。

質問に答えるためには、システム自身が集計処理を構築する必要があります。

レコードを収集する

事実を抽出する

異なる表現を正規化する

レコードを分類する

重複を除外する

計算を実行する

結果を検証する

この処理が難しい理由は、検索システムに十分に高い再現率が必要だからです。

関連データの一部でも検索から漏れると、件数や割合が誤ったものになる可能性があります。

『From Chat Logs to Collective Insights: Aggregative Question Answering』で提案されたベンチマークでは、18万2,000件を超える実際の会話データを対象に、集約型の質問応答が評価されています。

結果によると、現在の手法は主に次の二つの問題に直面しています。

大規模なデータに対する推論が難しい
十分なデータを処理するための計算コストが非常に高い

これは、非構造化データの集約が、依然として完全には解決されていない問題であることを示しています。

出典：
https://arxiv.org/abs/2505.23765

取得するチャンクを増やせば解決できるのか？

単純な方法として、取得するチャンク数を5件から100件に増やすことが考えられます。

しかし、より多くの情報を取得すれば、必ずしも良い結果が得られるわけではありません。

システムは新たに次の問題へ直面する可能性があります。

重複情報が増える
コンテキストが長くなり、ノイズが増える
処理コストが上昇する
どの事実を計算対象にすべきか判断しにくくなる
質問との意味的類似度が低い重要なグループが漏れる可能性がある

論文『RAPTOR: Recursive Abstractive Processing for Tree-Organized Retrieval』は、文書を複数の階層で整理・要約することで、この問題の一部に対応しています。

システムは、チャンクを平面的に検索するのではなく、詳細な文章と上位レベルの要約の両方を取得できます。

ただし、RAPTORが主に改善するのは、コンテキストの理解と情報検索です。

決定論的な計算ツールの代わりになるものではありません。

出典：
https://arxiv.org/abs/2401.18059

実用的なアーキテクチャはどう設計すべきか？

信頼性の高いシステムでは、まずユーザーがどの種類の質問をしているかを判定する必要があります。

ユーザーが情報を探したい場合

例：

「返金を受けるための条件は何ですか？」

従来型のRAGとリランキングの組み合わせで対応できる可能性があります。

ユーザーが関係性を理解したい場合

例：

「決済エラーと関連することが多い製品はどれですか？」

GraphRAGは、エンティティとその関係性を整理できるため、より適している可能性があります。

ユーザーが数値を集約したい場合

例：

「今四半期に発生した失敗取引の総額はいくらですか？」

AIには質問の解釈と処理計画の作成を担当させ、フィルタリング、件数集計、計算は次のような決定論的ツールへ委任するべきです。

SQLまたは分析用データベース
DataFrame
集約機能を持つ検索エンジン
明確なスキーマを持つナレッジグラフ
制御されたコード実行環境

実用的な処理フローは次のようになります。

ユーザーが質問する

AIが質問の種類を分類する

RAGまたはGraphRAGが根拠となる情報を収集する

構造化ツールがデータをフィルタリングし、計算する

システムが結果を検証する

AIが自然言語で結果を説明する

結論

RAGは、情報検索を得意としています。

GraphRAGはさらに一歩進み、システムが関係性を理解し、データの定性的な全体像を形成するのに役立ちます。

しかし、文書集合全体を対象とした件数、合計、平均、割合など、正確な数値を求める質問に対しては、検索と要約だけでは不十分です。

元のデータに集計済みのレポートが存在しない場合、システムは数千件の非構造化文書を、計算可能なデータへ変換しなければなりません。

その時点で、問題はRAGだけではなくなります。

完全なデータ処理・分析パイプラインが必要になります。

アーキテクチャを選択する前に、組織はユーザーが何を求めているのかを明確にする必要があります。

「一つの情報を見つけたいのか、関係性を理解したいのか、それともデータ全体を対象に計算したいのか？」

これらの質問は、会話型インターフェース上では似て見えるかもしれません。

しかし、背後ではまったく異なるシステムが必要です。

参考文献

Darren Edge et al.
From Local to Global: A Graph RAG Approach to Query-Focused Summarization.
arXiv:2404.16130
https://arxiv.org/abs/2404.16130

Parth Sarthi et al.
RAPTOR: Recursive Abstractive Processing for Tree-Organized Retrieval.
arXiv:2401.18059
https://arxiv.org/abs/2401.18059

Omri Koshorek et al.
Structured RAG for Answering Aggregative Questions.
arXiv:2511.08505
https://arxiv.org/abs/2511.08505

Wentao Zhang, Woojeong Kim, and Yuntian Deng.
From Chat Logs to Collective Insights: Aggregative Question Answering.
arXiv:2505.23765
https://arxiv.org/abs/2505.23765