コンテンツへスキップ
GraphRAGの実験:RAGパイプラインにナレッジグラフを追加する

GraphRAGの実験:RAGパイプラインにナレッジグラフを追加する

← 全記事

最近、私たちのチームでは Microsoft が提案する GraphRAG と LazyGraphRAG の要素を取り入れ、実験的に実装を行っています。これらのアプローチは、従来の検索拡張生成(Retrieval-Augmented Generation: RAG)システムが苦手としてきた「コーパス全体を俯瞰する高次の理解」が必要なクエリに対し、有望な解決策を示してくれます。

RAG システムの問題領域

同僚いわく、LLM は一般知識の保持と文章生成は得意だけれど、特定ドメインの文脈知識が抜け落ちている──まさにそのとおりです。そのギャップを埋める代表的手段が RAG で、セマンティック検索などを使って関連情報を取り込み、クエリ回答に活用します。

私自身、LLM にナレッジベースを組み込む必要があるときは、EC 企業で検索パイプラインを作っていた頃と同じように、既製モデルやファインチューニング済みモデルでベクトルデータベースを検索し、必要なら外部ツールで最新情報を取得するやり方を採ってきました。

この方法は、ChatGPT が登場した当初に目立っていた深刻な幻覚をかなり抑えてくれました。たとえば特定のレシピを尋ねられた場合、該当レシピをデータベースから取得して LLM に渡すだけで、ドメイン固有の知識に集中して回答を生成できます。

従来型 RAG の限界

従来型 RAG は具体的なクエリには強いものの、抽象的で俯瞰的な問いにはめっぽう弱い――大統領令のコーパスで試すと、その差は歴然でした。

  • 「2023 年に移民取り締まりを扱った大統領令は?」のような具体的な質問なら、関連文書や抜粋をきちんと返してくれます。
  • ところが「すべての大統領令に共通する主要テーマは?」「政策の優先順位は時系列でどう変化した?」といった俯瞰的な質問になると、まるで役に立ちません。

理由は単純で、従来型 RAG はクエリと“響きが似ている”文書を探すだけだからです。たとえば「主要テーマ (major themes)」という語に引っ張られ、「Major changes to ICE」や「スギ少佐 (Major Sugi) が昇進」など、単に “major” を含む無関係な文書を拾ってしまい、その歪んだデータセットを要約してしまうわけです。

後からどれだけ要約を工夫しても、もはや軌道修正はできません。最初に概念の全体像を見ていない限り、手遅れなのです。

こうした欠点は、大規模コーパスを俯瞰して理解するタスクで特に顕著であり、まさにそこで Microsoft の GraphRAG などの新技術が力を発揮します。

GraphRAG: Microsoft のグラフベース手法

Microsoft の GraphRAG は、公開論文 で提案された手法で、知識グラフを用いた情報検索によって LLM の知識ベースを拡張します。大まかな流れは次のとおりです。

  1. コーパスを用意する(インターネットテキスト、商品カタログ、大統領令など)。
  2. LLM でエンティティとリレーションを抽出し、知識グラフを構築する。
  3. グラフにコミュニティ検出(クラスタリング)をかけ、高レベルのグループ化を行う。
  4. 各コミュニティに含まれるデータをまとめ、要約を生成する。
  5. ユーザーがクエリを出すと、ノードレベルとコミュニティレベルの情報を組み合わせて回答する。

コミュニティレベルの情報がノード群とその入力データを丸ごと保持しているため、LLM は集約作業を減らし、生成に専念できます。

LazyGraphRAG: より効率的なアプローチ

続いて Microsoft が発表した LazyGraphRAG は、LLM 呼び出し回数を最小化する実装です。

  1. まず RAG パイプラインでコーパス全体にセマンティック検索をかける。
  2. 関連サブセットが特定できたら、その部分だけを LLM に通して知識グラフを構築。
  3. そのサブセットでコミュニティ検出と要約を行う(ここで初めて要約ができる)。
  4. 得られた構造体を RAG に利用する。

LLM 呼び出しを後段に送るぶん、クエリ時にグラフ生成と要約が走り、計算コストが増えます。概念上はより強力ですが、計算コストは私たちの方式より確実に高くなります。

私たちの実装: 中間的アプローチ

私たちの実験では、GraphRAG と LazyGraphRAG の“いいとこ取り”を狙ったハイブリッド方式を採用しました。

  1. 前処理ステージ
    • コーパス全体からエンティティとリレーションを抽出して知識グラフを構築。
    • コミュニティ検出を行い、各コミュニティの要約をあらかじめ生成。
  2. クエリ時ステージ
    • ユーザーの質問を受けたら、セマンティック検索で関連するノードまたはコミュニティを素早く絞り込む。
    • 事前構築したグラフから必要な文脈のみ取り出し、回答生成に利用する。

この方式には以下の利点があります。

  • 効率性: 重い処理を前もって片付けるため、クエリ応答が高速。

  • いいとこ取り: 知識グラフの豊かな構造とセマンティック検索のスピードを両立。

  • コスト効率: GraphRAG のように全データセットで LLM を回す必要も、LazyGraphRAG のように都度グラフを作る必要もない。

  • 潜在的な欠点: コミュニティ要約を事前生成するため、LazyGraphRAG が得意とする「最新データをクエリ時に取り込む柔軟性」は少し落ちます。

EC 向け検索システムを作ってきた経験からも、すべてのコミュニティを毎回検索するのは非効率です。まずセマンティック検索で範囲を絞り、そのうえでグラフを使う戦略を選びました。

知識グラフ構築の実験

知識グラフの面白さは、その柔軟性にあります。ある論文では「ほとんど非構造と言っていいほど自由で、見方によっては何でもグラフにできる」と冗談めかして語られていました。たとえばコンピュータビジョンは RGB チャンネルで構成された 2D グラフ、言語は単語が一方向に連なる 1D 有向グラフと見ることもできます。極端に言えば、すべてがグラフであり、同時にどれもグラフではない──そんなパラドックスです。

私たちの GraphRAG パイプラインでは、LLM を使って自由形式の属性を付与しデータを拡充しています。EC カタログなら色・柄・スタイル・サイズ、大統領令なら関係機関・政策分野・関係者などを抽出します。

ドメイン特化型の知識グラフと複数ドメインをまたぐ汎用的な知識グラフの双方で手応えがあり、任意のコーパスを、該当分野を専門とするエージェントなら誰でも扱えるようにできる点が強みです。

結果と観察

従来型 RAG が苦手だった俯瞰的な質問に対し、GraphRAG ベースのパイプラインは集約やトレンド分析で明らかに性能が向上しました。

興味深いことに、コミュニティ検出と要約が済んだあとは、実際のグラフ構造を直接使わない場合が大半でした。それでも当面は大きな支障はありません。だからこそ、より汎用的な知識グラフを作り、任意のコーパスを専門エージェントに委ねられる設計を試しています。

まとめと今後の展望

GraphRAG と LazyGraphRAG の知見を取り入れた実験から、知識グラフを RAG パイプラインに統合すると、具体的な質問だけでなく高レベルの集約的な洞察も提示できると確認できました。

前処理で知識グラフを構築し、コミュニティ検出と要約を済ませ、クエリ時は高速なセマンティック検索に頼る。この仕組みによって、LLM への過剰な負荷を避けつつ包括的な回答を提供できます。

従来型 RAG の弱点を補い、幅広いユースケースでスケーラブルかつコスト効率の高いソリューションになり得ると考えています。

今後の方向性としては、次のようなテーマに注目しています。

  • 高度なグラフ表現: 静的なリレーションだけでなく、時間とともに変化する動的インタラクションもとらえる表現を追求する。特に状況が激しく変わる領域では必須。
  • グラフ構造の深い統合: Graph Neural Networks(GNN)を活用し、推薦システム PinSage などの成功例を踏まえながら、グラフ情報を LLM の推論に直接取り込む。
  • 自動グラフ更新とリアルタイム解析: 新しいデータが入るたびに知識グラフを動的に更新し、リアルタイムで分析できるようにする。
  • ハイブリッド推論と説明性: グラフの構造化された性質と LLM の生成能力を組み合わせ、回答の根拠を特定のノードやコミュニティにまで遡れる、透明性の高いシステムを目指す。

構造化されたグラフ表現とセマンティック検索を組み合わせることで、私たちはより知的で文脈感度の高いシステムを実現できると信じています。複雑で相互に関連する情報を、より正確・明快に解釈し提示する世界がすぐそこまで来ています。

4 posts · 2,285 words · ~11 min total read · 20 tags · hugo 0.148.2 · 6fc2542 · built Mar 18 22:36
2389 Radio
2389 RADIO Select a station