9月1日、Salesforce Engineeringが「Why AI Gets Facts Right, Answers Wrong: GraphRAG Fixes It」と題した記事を公開した。RAGが「正しい事実」を取得しながら「間違った答え」を返す構造的な問題と、GraphRAGがそれをどう解決するかについて詳しく解説した内容だ。
GraphRAGとは、ナレッジグラフとRAG（Retrieval-Augmented Generation）を組み合わせた検索拡張手法である。通常のRAGがテキストチャンクのベクトル類似度検索に依存するのに対し、GraphRAGはエンティティ間の「関係」をグラフ構造として保持し、その関係を連鎖的にたどる「グラフトラバーサル（graph traversal）」によって多段推論を実現する。Microsoftが2024年に公開したGraphRAGの研究が先行事例として知られており、本記事はSalesforceが独自の実装で得た知見を整理したものだ。
「正しい引用、間違った結論」という問題
AIエージェントが顧客の返品申請を却下する。担当者が確認すると、ポリシーには確かに「90日以内」と書いてある。購入日を確認すると、その期限を過ぎている。——事実は両方とも正確だ。しかし、この顧客はGoldメンバー向けの例外規定により、実際には返品資格があった。
SalesforceのエンジニアリングチームがAgentforceの開発で直面したのが、まさにこの問題だ。必要な事実はすべてシステム内に存在している。しかし——
- 製品分類はカタログにある
- 例外規定はWikiにある
- メンバーシップ情報はCRMにある
通常のRAGパイプラインは「一般ポリシー」を見つけるが、適用ポリシーを決定する関連事実を組み合わせることができない。これが「フラットなチャンクの袋（flat bag of chunks）」問題と呼ばれる現象だ。ベクトル検索やキーワード検索は関連パッセージを返せても、チャンク間・ドキュメント間の必要な接続を見落とす。「正確な証拠を取得すること」と「十分な証拠を取得すること」は、別のエンジニアリング問題なのである。
GraphRAGがマルチホップ検索で補う仕組み
具体例で見てみる。顧客が購入した製品「WM-500」（価格899ドル）をたどると：
- WM-500 → 分類：Major Appliance（大型家電）
- Major Appliance → 適用ポリシー：120日間の延長返品ウィンドウ
- 延長ポリシー → 適用条件：500ドル超の購入 かつ Gold/Platinumメンバー
顧客はチャット上で「壊れた洗濯機」の話をしており、「製品分類」や「メンバーシップ閾値」などとは一言も触れていない。類似度検索だけでは「Major Appliance」という中間ファクトに到達できない。この中間ファクトは、クエリ文とのベクトル距離では近くないが、答えに至るうえで決定的な役割を果たす——これがグラフトラバーサルによる多段推論が必要な理由だ。
GraphRAGはナレッジグラフとRAGを組み合わせる。エンティティと関係をソースコンテンツから抽出してグラフ化し、検索時にエージェントが関係を連鎖的にたどる「マルチホップ検索」を実現する。グラフが検索の方向を示し、テキストチャンクが証拠と引用を補完する構造だ。
グラフの「設計ミス」は事後に補えない
GraphRAGが機能するには、グラフの構造自体が正確である必要がある。Salesforceの実装では責任を二層に分離している：
- TBox（スキーマ層）：エンティティの型と関係を定義する「設計図」。たとえば「MembershipTierというエンティティがReturnPolicyというエンティティと"governs"という関係を持つ」といったルールを記述する層だ
- ABox（インスタンス層）：実際の顧客のGoldメンバーシップ、WM-500の購入記録、899ドルという価格など具体的なデータ。TBoxで定義された型・関係に従って個々の事実を格納する
この二層構造はオントロジー工学の概念に由来する。TBoxが「Goldメンバーは延長返品ポリシーの対象となる」という関係を定義していて初めて、ABoxにある「顧客XはGoldメンバーである」「商品YはMajor Applianceである」というインスタンスが推論に使えるようになる。
AIがコンテンツからTBoxの候補を自動生成し、ビジネスユーザーがそれを検証してからインスタンス抽出に進む、というワークフローになっている。メンバーシップ要件がTBoxから抜けていたら、どれだけABoxにデータを追加しても資格判定はできない。設計図の欠陥は事後のデータ投入では修復できない。
非構造化ドキュメントと構造化データをつなぐポインタ
もう一つの課題が、ドキュメント由来の概念と構造化データのマッピングだ。グラフがポリシーと価格閾値を正確に表現していても、実際の購入金額が構造化システム（DBテーブルなど）に存在する場合、エージェントはそこへのルートを知らなければならない。
Salesforceの実装では、グラフエンティティから構造化情報への直接ポインタを付与する。これにより、エージェントは「似た名前のテーブルを推測して探す」のではなく、確立された接続をたどってデータを取得できる。このポインタは準備フェーズで設定しておくものであり、リクエストのたびに再発見するコストを省く設計だ。
RAGパイプラインの故障箇所を特定する3ステップ
記事では、エージェントが誤答を返した際の診断アプローチとして、以下の3点を確認するよう整理している：
- 取得コンテキストを確認する：カタログに分類情報はあるか。エージェントはその分類から延長ポリシーへとたどれているか。類似度マッチだけに依存していないか。
- 設計図（TBox）を確認する：グラフ上で延長ポリシーのメンバーシップ要件が表現されているか。構造から欠けているなら、追加データでは解決しない。
- レコードへの接続を確認する：資格条件は表現されているが、購入レコードへのポインタは明示されているか。都度メタデータを検索して解決させていないか。
記事は「最も関連性の高いパッセージが最終的に誤答をもたらすのは、決定的な事実がその一歩先の関係にある場合だ」と指摘する。「より多くの関連パッセージを取得する」のではなく、その関係がどこで消えているかを見つけることがエンジニアに求められるスキルだということだ。
詳細はWhy AI Gets Facts Right, Answers Wrong: GraphRAG Fixes Itを参照していただきたい。
