ローカルGraphRAG：知識グラフによるRAG（ガイド 上級者向け）

#GraphRAGの利点は？

法律事務所のコーパスを想像してください。契約書200件、メール500通、裁判所の判断80件です。そこで、「過去3年間の顧客との契約で言及されている主な法的リスクは何ですか。また、それらはどの継続取引先との契約に関係していますか？」と質問します。従来のベクトルRAGは、「関連性のある」チャンクを5個または10個検索してLLMに渡し、LLMは……一部の情報しか見えていない状態で回答します。文書を横断するパターンを見逃してしまうのです。

GraphRAGは、単に生の文章の抜粋を返すのではなく、構造に基づいて推論します。誰が何に言及しているか、どのエンティティが繰り返し現れるか、それらがどのような関係で結ばれているかを捉えます。文書群についてのこの種の総合的な（「グローバルな」）質問では、グラフ方式がベクトル方式を上回ります。まさにそれを示したのが、2024年のMicrosoft Researchの原論文です。

#GraphRAG とベクトルRAGの本質的な違い

両方のアプローチには共通の目的があります。LLMのプロンプトに外部コンテキストを取り込み、ハルシネーションを抑えることです。ただし、取得する情報は同じではありません。

ベクトルRAG

コーパスをチャンクに分割し、チャンクごとに埋め込みを計算して、ベクトルデータベース（ChromaDB、Qdrant、FAISS）に保存します。クエリ時には、コサイン類似度に基づいて最も近いk個のチャンクを取得します。

GraphRAG

LLMに各チャンクからエンティティと関係を抽出させ、グラフを構築し、エンティティをコミュニティにまとめ、各コミュニティを要約します。クエリを受けたときは、グラフを走査するか、コミュニティの要約を集約します。

ベクトル検索の強み

インデックス作成が速く（10 MBのテキストで数分）、低コストで、的を絞った質問（「Acmeの契約の解約条項は何ですか？」）に非常に適しています。

GraphRAGの強み

全体を俯瞰する質問（「繰り返し現れるテーマは何ですか？」「接続数が最も多いエンティティはどれですか？」）に適しており、エッジを通じて詳細に追跡でき、マルチホップにも標準で対応しています。

ベクトル検索の弱点

ドキュメント間のつながりが失われます。意味的に離れた3つのドキュメントを結び付ける必要がある質問では、適切なチャンクを取得できません。

GraphRAGの弱点

インデックス作成の負荷が高い：各チャンクをLLMで処理する必要があります。10MBのコーパスでは、数時間と大量のVRAMが必要になると見込んでください。一方、ベクトル方式なら5分で完了します。

#内部の仕組み

GraphRAGの完全なパイプラインは5つのステップを連続で実行します。すべてのステップがLLMを使用しています（クラスタリングを除く）。

1. 01
   Chunking

   通常のRAGと同様に、コーパスを500～1500トークンの文章区間に分割します。区間の長さは抽出の品質に直接影響します。短すぎるとLLMが関係を見落とし、長すぎると一部の関係を忘れてしまいます。
2. 02
   エンティティおよび関係の抽出

   各チャンクを、「すべてのエンティティ（人物、組織、場所、概念）と、それらの間の関係を抽出してください。JSON形式で出力してください。」といった構造化されたプロンプトとともにLLMに渡します。この工程にはコストがかかります。チャンクごとにLLMを1回呼び出すためです。
3. 03
   グラフの構築

   抽出されたエンティティはノードに、関係はエッジになります。複数のチャンクに現れる同一のエンティティは統合されます（エンティティ解決と呼ばれ、多くの場合、埋め込みや正規化ルールを使って行われます）。
4. 04
   コミュニティの検出

   クラスタリングアルゴリズム（Microsoft では Leiden、nano-graphrag ではよりシンプルなもの）を使って、結び付きの強いノードをコミュニティにまとめます。これらのコミュニティが「全体を見渡す」推論の鍵となります。
5. 05
   コミュニティの概要

   LLMは、各コミュニティに含まれるエンティティと関係に基づいて、そのコミュニティのテキスト形式の要約を生成します。これらの要約が、全体に関する質問に対する検索の単位になります。

クエリ処理において、GraphRAGは2つのモードを区別します。ローカル（特定のエンティティとその近傍の検索）と、グローバル（コミュニティの要約の集約）です。その後、LLMが取得したコンテキストと質問を組み合わせ、最終的な回答を生成します。

#ローカルデプロイメントに使えるツール

Microsoft GraphRAG

リファレンス実装（github.com/microsoft/graphrag）。機能がそろっていて丁寧に作られていますが、動作は重めです。もともとAzure OpenAI向けに設計されているため、Ollamaで使えるように移植するには根気が必要です。インデックス作成には非常に多くのトークンを消費します。

nano-graphrag

Ollama にネイティブに対応した最小限の実装（~1000行）（github.com/gusye1234/nano-graphrag）。ここではこれを活用します：理解する必要のあるコードが10倍少なく、同じコンセプトです。

LightRAG

より新しいバージョンで、問い合わせの遅延を最適化。Ollama と互換性があります。Microsoft GraphRAGよりも簡単で、nano-graphragよりも構造化されています

LlamaIndex KnowledgeGraphIndex

すでにLlamaIndexを使っている場合は、すぐに統合できます。ただし、この方式はより簡素で、コミュニティには対応していません。

#前提条件

Ollamaがインストールされ、正常に動作している

そうでない場合は、まず当サイトのOllamaインストールガイドに沿って進めてください。

堅牢な推論能力を持つLLM（14～24B）

エンティティ抽出には相応の処理能力が必要です。gpt-oss 20B、Mistral Small 24B、またはQwen 3.5 9B（下限の目安）がうまく機能します。8B未満では、生成されるJSONの形式が不正になることがよくあります。

ローカルエンベディングモデル

nomic-embed-text を Ollama で使用するか、sentence-transformers による bge-m3 / multilingual-e5-large を使用

最低16 GB の VRAM

12GBでも8〜9BのQ4モデル（Qwen 3.5 9B）で間に合わせることはできますが、インデックス作成は遅くなります。16GBならgpt-oss 20BまたはMistral Small 24Bを読み込めます。24GB（RTX 4090、M-Max）なら余裕があります。

Python 3.10+

nano-graphrag および現代のほとんどの RAG フレームワークは 3.10 以上を要します。

#1. nano-graphrag でコーパスをインデックス化

まずOllama側でモデルを準備してください。このチュートリアルでは、gpt-oss 20B（デフォルトの量子化はMXFP4、約14 GB）を使用し、埋め込みにはnomic-embed-textを使用します。

ollama pull gpt-oss:20b
ollama pull nomic-embed-text
ollama serve  # si pas déjà en service

次に、専用のvenvにnano-graphragをインストールしてください。

python -m venv .venv
source .venv/bin/activate  # Linux/macOS
pip install nano-graphrag

インデックススクリプトは二十行程度です。Ollama に OpenAI 互換エンドポイントをポート 11434 で接続して実行します。

import asyncio
from nano_graphrag import GraphRAG, QueryParam
from nano_graphrag.llm import ollama_model_if_cache, ollama_embedding

WORKING_DIR = "./graphrag_cache"

async def main():
    rag = GraphRAG(
        working_dir=WORKING_DIR,
        best_model_func=ollama_model_if_cache,
        cheap_model_func=ollama_model_if_cache,
        embedding_func=ollama_embedding,
        best_model_kwargs={"model_name": "gpt-oss:20b"},
        cheap_model_kwargs={"model_name": "gpt-oss:20b"},
    )

    with open("corpus.txt", encoding="utf-8") as f:
        text = f.read()

    await rag.ainsert(text)

if __name__ == "__main__":
    asyncio.run(main())

インデックス作成を開始してください。コーパスのサイズと GPU に応じて、所要時間は数分（テキスト 1 MB）から数時間（50 MB）を見込んでください。

python index.py

最後に、graphrag_cache/ フォルダにはシリアル化されたグラフ、エンベディング、コミュニティのサマリーが含まれます。

#2. グラフに問い合わせる

インデックスが構築されると、クエリは数秒で応答します。これは、LLMがコーパス全体ではなく、グラフから取得されたコンテキストのみを読み込むためです。

import asyncio
from nano_graphrag import GraphRAG, QueryParam
from nano_graphrag.llm import ollama_model_if_cache, ollama_embedding

async def main():
    rag = GraphRAG(
        working_dir="./graphrag_cache",
        best_model_func=ollama_model_if_cache,
        cheap_model_func=ollama_model_if_cache,
        embedding_func=ollama_embedding,
        best_model_kwargs={"model_name": "gpt-oss:20b"},
        cheap_model_kwargs={"model_name": "gpt-oss:20b"},
    )

    # Mode global : synthèse à partir des résumés de communautés
    print(await rag.aquery(
        "Quels sont les thèmes principaux du corpus ?",
        param=QueryParam(mode="global")
    ))

    # Mode local : recherche centrée sur des entités
    print(await rag.aquery(
        "Quelle est la position de l'entreprise X sur le sujet Y ?",
        param=QueryParam(mode="local")
    ))

asyncio.run(main())

#ローカルでの計算コスト：どの程度を見込むべきか

ここは誰もが初めて知ったときに驚く点です。GraphRAGで5 MBのテキストをインデックス化するには、同じコーパスを使うベクトルRAGの約50〜200倍の計算量が必要です。以下に、規模感をつかむための具体的な目安を示します。

コーパス 1 MB（約300ページ）

gpt-oss 20B（MXFP4）でRTX 4090を使用：インデックス作成に約25分。RTX 3060 12GB（部分オフロード）では約3時間。Mac M3 Max 64GBでは約40分。

コーパス5MB（約1500ページ）

RTX 4090：約2時間。M4 Pro 48GB：約3時間。この容量を超える場合は、夜間の実行を予定してください。

ピーク時のVRAM使用量

gpt-oss 20B（MXFP4）モデルは常時約14 GBを占有します。nomicの埋め込みがさらに約1 GBを使います。VRAMが16 GB未満の場合は、CPU側のメモリへの退避（部分的なオフロード）が発生すると考えてください。

クエリのコスト

ローカルモードでは数秒、グローバルモード（複数のコミュニティを集約）では5〜30秒です。インデックス作成に比べれば、負担は軽いものです。

増分再インデックス

nano-graphrag は現在、既存のグラフを適切に更新することができません。新しいドキュメントを10％追加する場合、部分的または完全なインデックス再構築が必要です。Microsoft GraphRAG はこの点でより優れた処理を実現しています。

#GraphRAGがベクトル検索を本当に上回る場面

GraphRAGはベクトルRAGの普遍的な代替手段ではありません。特定の用途ではその性能を大きく上回りますが、他の用途では明確に劣ります。

コーパスベースの要約

「話題Xに関する私たちの200件のメールで議論されている、主な5つのテーマは何ですか？」→ GraphRAGが圧勝します。ベクトル検索では5〜10件のメールしか取得できませんが、グラフはコミュニティを集約します。

マルチホップの質問

「AcmeとBeta Corpの両方と取引しているサプライヤーはどこですか？」→ GraphRAGはエッジをたどることでこの問いを解決します。ベクトル検索では、適切なチャンクを見つけ、結合処理をLLMに頼る必要があります。

関係の探索

「アトラスプロジェクトに関連する最も頻繁に言及される人物は誰ですか？」→ GraphRAGはこれに自然に適しています（中心性、隣接関係）。ベクトルデータには関係性という概念がありません。

特定の事実に関するQ&A

「2024年3月12日付のAcmeの契約では、事前通知期間はどのくらいですか？」→ ベクトルRAGが有利です。より高速で、より正確で、インデックス作成のコストも低くなります。

更新が非常に頻繁なコーパス

毎日新しいドキュメントを追加すると、GraphRAGの再インデックスコストが非常に高くなるため、ベクトル検索またはベクトル検索＋BM25に限定してください。

コーパスサイズ < 500 KB

グラフは不要です。32k トークン以上のコンテキストを使えるなら、LLM は全文をコンテキスト内で読めます。GraphRAG を使う意義があるのは、コンテキストに収まりきらないほど大きなコーパスの場合だけです。

#さらに詳しく

GraphRAGは活発に研究・開発が進む分野で、実装もベンチマークも急速に変化しています。さらに学ぶための手がかりをいくつか紹介します。

ローカル RAG：入門

ベクトル検索を使うRAGの概念にまだ曖昧な点がある場合は、GraphRAGを本番環境に導入する前に、入門ガイドで基礎を固めるとよいでしょう。

チャンキング戦略

エンティティ抽出の品質は、チャンクのサイズと整合性に直接依存します。本ガイドでは、適切な実践方法を詳しく解説します。

BM25とベクトル検索を組み合わせたハイブリッド検索

GraphRAG と従来の検索を組み合わせるには、まずハイブリッド検索を見てください。複数のシグナルを組み合わせるという考え方は同じです。

ローカルAI向けGPUの選び方

GraphRAGのインデックス作成は多くのリソースを消費します。現在、メモリ容量8～12 GBのGPUを使っている場合、16～24 GBに移行すると処理ペースが大きく変わります。