グラフ拡張RAG（GraphRAG）実践

RAGからGraphRAGへ：なぜグラフが必要なのか

従来のRAGは、ドキュメントをスライスし、ベクトル化し、類似チャンクを検索し、連結して回答を生成する方法です。この方法は単純な事実クエリには効果的ですが、エンティティ間の関係を理解し、多段階推論を必要とする質問には対応できません。例えば、「量子コンピューティングの創始者が学んだ大学は、他にどのノーベル賞受賞者を輩出しましたか？」という質問は、まず「量子コンピューティングの創始者」を見つけ、次に「大学」を見つけ、最後に「その大学のノーベル賞受賞者」を検索する必要があり、3回の関係ホップが必要です。GraphRAGはまさにこのような問題を解決するために生まれました。知識グラフでエンティティと関係を明示的にモデル化し、検索に関係推論能力を持たせます。

GraphRAGのアーキテクチャ設計

GraphRAGの核心は、従来のRAGにグラフ層を追加することです。完全なアーキテクチャは3つの部分で構成されます：ドキュメント処理層（ドキュメント解析→エンティティ認識→関係抽出→グラフ構築）、グラフストレージ層（Neo4j/Neptuneがエンティティと関係を格納し、Cypherクエリとグラフトラバーサルをサポート）、ハイブリッド検索層（ベクトル検索とグラフ検索の融合、クエリタイプに基づいて検索戦略を動的に選択）。重要な設計は検索ルーティングです：単純な事実クエリはベクトル検索へ、関係推論クエリはグラフ検索へ、複合クエリは両方を組み合わせます。

知識グラフの構築

from openai import OpenAI
from neo4j import GraphDatabase
import json

client = OpenAI(api_key="your-deepseek-api-key", base_url="https://api.deepseek.com")
driver = GraphDatabase.driver("bolt://localhost:7687", auth=("neo4j", "password"))

def extract_entities_relations(text):
    """DeepSeekを使用してテキストからエンティティと関係を抽出"""
    prompt = f"""以下のテキストからエンティティと関係を抽出し、JSON形式で返してください：
{{
  "entities": [{{"name":"エンティティ名","type":"人物/組織/場所/概念"}}],
  "relations": [{{"source":"エンティティA","target":"エンティティB","relation":"関係の説明"}}]
}}
テキスト：{text[:3000]}"""
    resp = client.chat.completions.create(model="deepseek-chat",
        messages=[{"role":"user","content":prompt}])
    return json.loads(resp.choices[0].message.content)

def build_graph(text):
    """Neo4j知識グラフを構築"""
    data = extract_entities_relations(text)
    with driver.session() as session:
        for ent in data["entities"]:
            session.run(
                "MERGE (e:Entity {name: $name}) SET e.type = $type",
                name=ent["name"], type=ent["type"]
            )
        for rel in data["relations"]:
            session.run(
                "MATCH (a:Entity {name: $s}), (b:Entity {name: $t}) "
                "MERGE (a)-[r:RELATES {desc: $desc}]->(b)",
                s=rel["source"], t=rel["target"], desc=rel["relation"]
            )

def graph_search(query, hops=2):
    """グラフ多段階検索"""
    with driver.session() as session:
        result = session.run(
            f"""MATCH path = (start:Entity)-[*1..{hops}]-(related)
            WHERE start.name CONTAINS $query
            RETURN [n in nodes(path) | n.name] as entities,
                   [r in relationships(path) | r.desc] as relations
            LIMIT 10""", query=query
        )
        return [{"entities": r["entities"], "relations": r["relations"]} for r in result]

# 使用例
text = "アラン・チューリングはロンドンで生まれ、ケンブリッジ大学で数学を学び、コンピュータ科学の父と呼ばれています。"
build_graph(text)
results = graph_search("チューリング")
print(json.dumps(results, ensure_ascii=False, indent=2))

ハイブリッド検索戦略

GraphRAGの核心的価値はハイブリッド検索にあります。クエリタイプに基づいて検索パスをインテリジェントに選択します。検索ルーターを実装します：まず軽量な分類器でクエリタイプ（事実クエリ/関係クエリ/複合クエリ）を判断し、次に異なる検索器にルーティングします。事実クエリはベクトル検索（高速で正確）、関係クエリはグラフ検索（多段階推論をサポート）、複合クエリはまずグラフ検索で関連エンティティを見つけ、次にベクトル検索で詳細なコンテキストを取得し、最後に融合してランキングします。融合にはRRF（逆数ランク融合）または加重和を使用します。

GraphRAGの限界と最適化

GraphRAGは強力ですが、いくつかの実際的な課題があります：構築コストが高い（エンティティ抽出と関係構築は時間がかかりトークンを消費し、大規模ドキュメントではコストが顕著）、グラフ品質（LLM抽出には漏れや誤りがあり、手動検証または高品質な抽出プロンプトが必要）、コールドスタート問題（新しい分野では既存のグラフがなく、大量のラベル付きデータが必要）。最適化の提案：バッチ抽出でAPI呼び出しのオーバーヘッドを削減、エンティティリンキングによる曖昧性解消の導入、高頻度エンティティのインデックスを事前構築、グラフ更新戦略（増分更新 vs 再構築）の設定。

企業知識管理におけるGraphRAGの応用

私たちは多国籍製造企業にGraphRAGを導入し、50か国に分散する技術文書と特許を管理しました。従来のRAGはここで完全に失敗しました。ユーザーは「ドイツのギアボックス設計チームは摩擦係数を下げるためにどの材料を使用しましたか？」と尋ねます。この質問は組織知識（「ドイツチーム」→チーム情報はHR文書に）、技術知識（「ギアボックス設計」→製品文書に）、材料知識（「摩擦係数を下げる」→特許と研究論文に）にまたがります。GraphRAGはクロスドキュメントのエンティティ関係グラフを構築することでこの問題を解決しました。HR文書から（ドイツチーム→担当→ギアボックス設計）を抽出し、製品

GraphRAGのインデックス構築パフォーマンス最適化

知識グラフ構築におけるエンティティ抽出は最も時間のかかるステップです。100万字のドキュメントセットでは、LLMを使ってセグメントごとに抽出すると数時間かかり、APIコストも高額になります。最適化案：階層的抽出—まずspaCyなどの軽量NLPツールで高速なエンティティ認識（秒単位）を行い、その後LLMで関係抽出を行います。これにより、LLM呼び出し回数をO(セグメント数)からO(エンティティペア数、spaCyでフィルタリング済み)に削減します。バッチ抽出—複数のセグメントを1つのプロンプトにまとめて一括抽出し、LLMのバッチ処理能力を活用します。インクリメンタル更新—新しいドキュメントが追加された場合、グラフ全体を再構築するのではなく、新しいドキュメント内のエンティティと関係のみを抽出し、既存グラフとの接続ポイントを見つけます。最適化後、100万字のグラフ構築時間は6時間から45分に短縮され、APIコストは120ドルから18ドルに削減されました。

GraphRAGと従来のRAGのハイブリッドデプロイ

GraphRAGは従来のRAGを完全に置き換える必要はありません。両者は共存し、クエリタイプに基づいてインテリジェントにルーティングできます。私たちが設計したハイブリッドルーティング戦略：クエリが入ると、まず軽量な分類器（DeepSeekの高速分類プロンプトに基づく、約200ms）を通過し、クエリタイプを判断します。事実クエリ（例：「Python 3.12のリリース日」）→従来のRAG（ベクトル検索、最速かつ最も正確）；関係クエリ（例：「Pythonを誰が作成し、彼は他にどのプロジェクトで働いていますか？」）→GraphRAG（グラフのマルチホップ検索）；複雑な混合クエリ→最初にGraphRAGで関係を見つけ、次に従来のRAGで詳細を取得します。分類器の精度は94%で、誤った検索エンジンにルーティングされる割合はわずか6%です。これは単一の方法を一様に使用した場合の失敗率よりもはるかに低いです。このハイブリッドアーキテクチャにより、総合的なクエリシナリオでの精度は単一RAGの72%から89%に向上しました。