はじめに
はじめまして、株式会社IGSAでAIエンジニアをしている加藤です。
IGSAでは、脳の健康管理アプリ「はなしてね」をはじめとするプロダクト開発と、パートナー事業における共同プロジェクトを通じて、AI技術に関するリサーチを継続的に行っています。
その一環として、RAGの発展形として注目されているGraphRAGについて調査を行いました。本記事では、調査内容をベースに得られた知見を整理して紹介します。
この記事の概要
RAG（Retrieval-Augmented Generation）は、LLM が持っていない外部知識を検索してきて、プロンプトに足してから生成するためのアーキテクチャです。
このとき、外部知識の保存方法としてベクトルデータベース がよく使われます。
一方、GraphRAG は知識グラフ（Knowledge Graph, KG） を使って RAG を強化しようとするアプローチです。
この記事では、
- GraphRAG は従来の RAG と何が違うのか？
- GraphRAG の典型的な構造（コンポーネント）はどう整理できるのか？
- 実運用で使われている例はあるのか？
を中心に、GraphRAGサーベイ論文と周辺資料をもとに整理していきます。
対象読者
- LLM や RAG について「なんとなく仕組みは知っている」という方
- Knowledge Graph（知識グラフ）という言葉は聞いたことあるけど、RAG とどう結びつくのかイメージが湧いていない方
理論の解説記事ではなく、GraphRAGの大枠把握と実務における実現可能性を考える記事です。
参照元
本記事は主に以下のサーベイ論文の内容を参照し作成しました。
Retrieval-Augmented Generation with Graphs (GraphRAG)
あわせて、GraphRAG の実運用例を紹介しているブログ記事や、Knowledge Graph RAG システムの構築事例も適宜参照しています。
ベースとなる知識
RAGのおさらい
RAG（Retrieval-Augmented Generation）は、「外部検索＋文章生成」 のパターンをもつアーキテクチャです。
ごく単純な例でいうと：
- チャンク1: 「富士山は日本一高い山です」
- チャンク2: 「信濃川は日本一長い川です」
というコーパスを考えます。また
- クエリ: 「日本一高い山は何ですか？」
を考えます。
まず、クエリと文書をベクトル化し、類似度が高いチャンクを取得します。この場合類似度が高いチャンクとして、チャンク1が取得されることが期待されます。次に取得したクエリとチャンクを両方LLMに渡すことで、チャンク情報に基づく「日本一高い山は富士山です」という回答を得る、というイメージです。
RAGの利点としては、
- LLM本体はファインチューニングしなくてもよい
- 知識の更新は「外部情報源の更新」で済む
- どの文書を根拠に回答したかが、ある程度トレースできる
といった点があります。
従来型RAGが持つ課題
しかし、従来の「ベクトルDBを用いたRAG」には、いくつかの限界があります。
特に外部知識に起因する部分を一部挙げると、
- 関係性に基づく検索が苦手
- マルチホップな推論が必要なクエリに弱い
とされています。
例えば、
「機能Xに問題があるとき、影響を受ける部品は？」
というクエリを考え、対象となる情報として
「機能Xは処理Yを行う」
「処理Yは部品A,Bを使う」
が存在すると考えます。
このように記述が散らばっているとき、単純な類似度検索では
- 「機能X」と「部品A,B」が同じチャンクに含まれているとは限らない
- 「X」「Y」「A, B」の関係性（因果・包含）の構造を直接使えない
といった理由で、情報を集められない場合があります。
この対処として、
- クエリを分割して検索する
- 類似度検索＋ルールベースのフィルタを組み合わせる
ことがありますが、「関係を情報として持った検索を行う」 方が自然なドメインも多いはずです。
ここで登場するのがKnowledge Graph（知識グラフ） です
知識グラフ（Knowledge Graph）とは
Knowledge Graph（KG）は、ざっくり言うと、
エンティティ（モノ・人・概念など）をノード、それらの関係をエッジとして表現した、構造化データベース です。
What Is Google’s Knowledge Graph?
例えば、
「Steve Jobs」 - born in - 「San Francisco」
「San Francisco」 - located in - 「California」
といった関係性が保存されています。このように「主語 - 述語 - 目的語」の三つ組（トリプル）で記述されることが多いです。
また、Google Knowledge Graphのように一般知識を網羅的に集めたものに加えて、特定ドメインに特化したものも存在します。
農業ナレッジグラフの構築に関する考察による領域ナレッジグラフの構築モデルの提案（図1より抜粋）
GraphRAGは、このKnowledge GraphをRAGの「外部知識」として利用する アーキテクチャです。
「類似なテキストを探すRAG」から「関連するノードとパスを辿るRAG」への拡張と捉えると良いのではないかと思います。
GraphRAGとは何か
5つのコンポーネントによる全体像
GraphRAG のサーベイ論文では、システム構成を次の 5 コンポーネントで整理しています。
1. Query Processor
自然言語のクエリを、グラフ検索に適した形に変換する
2. Data Source
Knowledge Graph、およびその保存形式
3. Retriever
Knowledge Graphを用いてグラフ探索・マルチホップ・ランキング等を行う
4. Organizer
取得したグラフ情報を、LLMに渡せるテキスト（構造）に整形
5. Generator
整形済みのコンテキストをもとにLLMが回答を生成
従来のRAGとGraphRAGの対応表
シンプルなRAGとの対応としては、以下のように解釈しました。
| コンポーネント | GraphRAG | シンプルなRAG |
|---|---|---|
| Query Processor | グラフ検索に利用するクエリ変換（手段多） | 入力クエリの埋め込み取得 |
| Data Source | Knowledge Graph | ベクトルDB |
| Retriever | グラフ探索・マルチホップ・ランキング等（手段多） | ベクトル検索 |
| Organizer | 取得知識の構造化 | × |
| Generator | LLMでの応答・要約 | LLMでの応答・要約 |
Organizer はシンプルなRAGだとあまり意識されない考え方だと思いますが、GraphRAGにおいてはコンポーネントとして明確化されているようです。
GraphRAGの各コンポーネント詳細
Data Source（Knowledge Graphの構築と保存）
構築方法
KGの構築方法は大きく以下の方法に分けられます。
-
手動構築
これは対象ドメインの専門家がスキーマとトリプルを手作業で定義するものです。正確に作成しやすいですが、大規模なKGは難しいでしょう。 -
ルールベース構築
固有表現抽出（NER）やパターンマッチ等の手法でエンティティを抽出し、定義したルールや辞書を用いてリレーションを自動的に結ぶ手法です。 -
LLMベース
テキストからLLMによってエンティティやリレーションを抽出する方法です。LangChainやLlamaIndex等に、KG構築を行うモジュールは出てきています。
小規模なPJTやPoCでは、LLMを絡めた半自動構築に落ち着くケースが多いように思います（その場合は、KGの評価手法や、KGの更新は難点が残ります）
保存方法
技術的には、以下の方法で保存されるようです
-
グラフデータベース
Neo4j, TigerGraph など。
クエリ言語としてはCypher、GSQLなどを利用します。 -
標準化されたグラフ記述形式
RDF（Resource Description Framework）
「主語 - 述語 - 目的語」のトリプルとして記述し、SPARQLなどのクエリ言語を利用します。
Query Processor
Query Processorはテキスト形式のクエリとグラフ構造データソースの橋渡し を行うコンポーネントです。以下のような技術が用いられ、Retrieverにとって適した形に変換されます
固有表現認識（NER）
クエリに含まれるエンティティ候補（人名、地名、製品名など）を抽出します。例えば、「赤ちゃんの目の色を推測する最良の方法は？」という質問では、NER は「赤ちゃん」「目」「色」といったエンティティを抽出し、KG検索の初期シードとなります。
最近は、NER専用モデルだけではなくLLMを用いたNER手法も研究されているようです
関係抽出（RE）
NERで取得したエンティティ間の関係性を抽出します。例えば、「中国の首都はどこですか？」という質問では、RE は「中国 - 首都」という関係を特定します。
クエリ構造化
グラフ検索クエリ（Cypher, GraphQL…）への変換、SQLへの変換などを指します
クエリ分解/拡張
複数の質問が混ざっているクエリを分割したり、不足している条件を推測して補完するなどの技術を指します。
これは、シンプルなRAGにおけるクエリ分解/拡張と近い役割です
Retriever
Query Processorの出力をもとに、KGから関連情報を検索する コンポーネントです。
シンプルなRAGでは、「Text-in, Text-out」が基本で検索しますが、GraphRAGは「{Text, Graph} -in , {Text, Graph} -out」の4パターンとなります。また、グラフの探索手法のバリエーションも非常に多いです。グラフ構造や他コンポーネントの特性を考慮して手法を選択する必要があります。
一般に、シードエンティティの特定 とエンティティ取得 の2段階からなります。これはある元となるエンティティを見つけ、そこから探索していくイメージです。
Retrieverの種類の分類方法は複数あるようですが、ヒューリスティック/学習型による分類 と、探索方法による分類を紹介します。
ヒューリスティック型
これは、ルールやスコアリングを組み合わせてサブグラフを取得する手法です。以下のような考え方があります。
- NERで取得したエンティティと、グラフノードをリンキングする考え方
- クエリで指定されたリレーションと一致するエッジを特定する考え方
- ノード間の近接性に基づく考え方、ノードの役割に基づく考え方
- NERやREで取得した情報を元に、サブグラフを取得する考え方
学習型
こちらは、クエリとグラフ構造のマッピングを学習させるアプローチになります。つまり、KGの関係性についてNN, GNN（Graph Neural Network）を学習して情報を抽出するということです。
このNNの考え方としては、ノード/エッジ/グラフレベルがあります。また、ノード/エッジ/グラフを一様にベクトル表現する手法もあるようです。
例えば、クエリをエッジ特化重みにエンコード→類似トリプルの取得といった構造が考えられます。
探索方法による区分
様々な手法が紹介されていたため、ここでは各手法の方法概要を紹介します
-
トラバーサル型
グラフを走査し、特定の質問に役立つパスを抽出するものです。例えばNERを用いて取得したシードエンティティからk個のパスを取得→ クエリとエンティティのテキスト埋め込みを入力として学習したモデル等で関連度を計算しパスを取得するといった方策があります。これはグラフの特性を踏まえた様々な探索方法があります。次に探索すべきパスをLLMで判定させる場合や、探索の戦略にビームサーチを利用するなど、様々なものが考えられます。 -
サブグラフ型
シードエンティティから一定の距離や一定のスコアを持つサブグラフを取得する手法です。この場合、outputがサブグラフ となり、次のコンポーネントに移るということです。 -
ルールベース型
グラフ検索クエリを作成し、KGから事前定義のテンプレートに一致するパスを取得するものです。 -
GNN型
クエリに対する正解エンティティは1, それ以外は0を与えるように学習し、推論時は確率が閾値を超える（シード以外の）エンティティを候補とし、シードからの最短路を抽出するなどのものです。（他の学習戦略もあると思います。） -
類似度ベース型
エンティティのテキスト・関係情報をチャンク化してベクトルに埋め込む手法です。これはグラフのエッジを用いてベクトルDBを構築する形であり、シンプルなRAGのイメージにかなり近い手法と言えます。 -
関係ベース型
LLMを用いて元クエリを部分文に分割し、各文に対応するエンティティ集合を取得 → 続いてLLMで各部分文に対する上位k個の関連関係を取得 → 対応するエンティティ集合を持ち、かつ関係をもつものを取得するといった手法です。 -
融合型リトリーバー
各Retrieverの戦略を融合したものも構築することができます。
全体を通して、これがデファクトスタンダードな検索手法というものは存在していない印象 です。従来のRAGではセマンティック検索＋キーワード検索が中心で、それ以上の手法が用いられることは多くありませんが、GraphRAGでは複数の検索戦略が提案されている点が特徴と言えるでしょう。
参考に、論文中のグラフ探索イメージを記載します。
Retrieval-Augmented Generation with Graphs (GraphRAG) Figure5 (a)より抜粋（NER、REを用いたグラフ探索イメージ）
Retrieval-Augmented Generation with Graphs (GraphRAG) Figure5 (c)より抜粋（グラフのベクトル取得のイメージ）
Organizer
Organizerは取得したテキスト/グラフを、LLMが扱いやすいテキストデータに変換する部分です。
変換前の事前処理として、取得したグラフが多い場合は以下手法などで重要度の高いものを取得するプロセスを挟みます。
- graph pruning（枝刈り）
エンティティ、リレーションなどのスコアリングを行い、重要度の低い部分を枝刈りする手法です。 - Reranker
取得したグラフが多い場合、重要度が高いものからリランキングしたいことがあります。取得数を絞ることや、attentionはプロンプト内のどの位置に属するかで注意バイアスがあるため順序を入れ替える場合に用いられます
Organizerの処理としては、以下のようにグラフからLLMに入力するためのテキストに変換します。
- タプル型オーガナイザ
（エンティティ - リレーション - エンティティ（- …））の形式でプロンプトに入れる手法です。 - テキスト型オーガナイザ
グラフをLLM/テンプレートベースで文章にする手法です。 - その他
Python class定義等に変換するなどの手法もあるようです。
Generator
LLM等を用いて文章を生成する部分になります。（LLM自体の性能向上の話になるため、詳細は省きます）
GraphRAGの課題
論文中では、GraphRAGの課題が挙げられていました。
その中で個人的には、グラフの構築 、評価方法 、信頼性 が課題になりやすそうと感じています。
また、実際に運用された例が少なく、解く問題を正しく定義する難しさも論文中では指摘されています。次セクションからは、実際どの程度運用例があるかを調べた結果になります。
実運用例
やはりGraphRAGを実装している事例はまだ多くないようですが、2つ紹介します。
NASA: 人物情報知識グラフによる専門家検索
NASAは多数の職員、プロジェクトが存在するため、膨大なドキュメントが存在し「誰が何を知っているか、どんなプロジェクトに関わってきたか」把握しにくい課題があったとされています。
そこで、pdf, DB, documentなどの非構造データからPeople Knowledge Graphを構築し、GraphRAGが構築されています。
例えば「誰が自律ロボット開発に詳しいか？」という質問に対して
- ベクトルDB → 全ての自律的ロボットの開発をしている人を探し出すのは（ピンポイントな資料がない限り）難しい
- 知識グラフ → 自律的ロボット開発のエンティティに関係がある人物を抽出する
といった流れで回答精度が上がるというイメージだと思います。
Cedars-Sinai: アルツハイマー病研究
（3. Cedars-Sinai: Knowledge-Aware Automated Machine Learning in Alzheimer’s Researchの内容）
医療ドメインでは、遺伝子・薬剤・臨床試験等の多くのエンティティと関係が存在します。
この例では、60万以上のエッジを持つKGを構築 → 複雑な質問を分解 → KGから適切な文脈を取得することで、研究に関連する情報取得を円滑に行うシステムが提案されています。
知識グラフを利用することで、使用した情報のパスを明示的に辿ることができるため、説明性が重要な医療ドメインとは、特に相性が良さそうな分野だと考えられます。
まとめと所感
GraphRAGは、一言で言うとRAGの外部知識ストア部分を、Knowledge Graphに置き換えるアーキテクチャです。
特徴的な点は、Query Processor / Retriever / Organizer の設計が従来RAGより幅があり、それにより精度向上が望める点だと思います。しかし、Knowledge Graphの設計・構築・評価にはコストがかかるため、現時点では実運用の事例は多くありません。主に、大規模かつ複雑な関係性を追いかける必要があるドメインで、一部活用が始まっている段階だと考えられます。
現状では、「知識間の関係」を特に重視するデータを扱う場合に検討する、やや重めの選択肢のひとつという位置づけだと捉えています。
IGSAについて
IGSAは、社会を温かく柔らかく持続的に支えるAIシステムにより、持続可能な幸せを目指す、東京大学松尾・岩澤研究室発のAIカンパニーです。
脳の健康管理アプリ「はなしてね」や、中古品の画像解析SaaS「スグトリ」などのAIプロダクト提供に加え、潜在的な課題に対し柔軟な開発支援を行うパートナー事業を展開。センシングAI技術を活用した状態の定量化と分析により、人の意思決定をサポートしています。