ナレッジグラフ、エンタープライズ設計、そして本番導入チェックリスト
連載「階層型RAG完全ガイド」について:
本シリーズは全5回を通じて、特定のフレームワーク（LangChain, LlamaIndex等）に依存せず、本番環境で真に機能する**検索システム設計（Retrieval System Design）**の基礎から応用までを網羅的に解説します。
1. なぜツリー構造だけでは不十分なのか？ グラフ思考（Graph Thinking）の導入
Part 4 で解説したRAPTORは、階層的な要約ツリーによって大域的コンテキストの取得を可能にしました。しかし、ツリー構造には依然として解けない固有の死角が存在します。それは、「複数のドキュメント間にまたがる横断的な関係性（Cross-document Connections）」 を表現できないという点です。
例：行政区画の境界線と東海道新幹線
- 行政区画（ツリー構造：国 ＞ 都道府県 ＞ 市区町村）： 東京都と愛知県と大阪府は、それぞれ独立した行政ブランチとして分断されており、縦の親子関係しか見えません。
- 交通インフラ（グラフ構造：東海道新幹線・東名高速道路）： 実際には1本の高速交通網が「東京 - 名古屋 - 大阪」を物理的に結びつけ、人や物流が日々行き来しています。
企業のナレッジ空間も全く同じです。1人の重要人物、1つのコア技術、あるいは特定のセキュリティ脆弱性が、社内の50以上の異なるドキュメントに断片として出現します。GraphRAG（ナレッジグラフ拡張RAG）は、これら点在する情報を1本の生きた知識ネットワークとして統合します。
2. GraphRAGを構成する4大要素
マイクロソフト（Microsoft Research）が提唱するGraphRAGは、非構造化テキストを以下の4つのエンティティ群へと構造化します。
[ Entity: 担当者X ] ──────( Relationship: 兼務取締役 )──────> [ Entity: A社 ]
│ │
└──────────────────[ Claim: 2023年に監査指摘受領 ]──────────┘
-
Entity（エンティティ / 実体）： 人物、組織、製品、技術、概念などの固有ノード（
Person,Organization,Technology,Vulnerability）。 -
Relationship（リレーションシップ / 関係性）： エンティティ間の関係を表すエッジ（
INVESTED_IN,SUPPLIES_TO,DEVELOPED_BY）。 - Claim / Fact（クレーム / 事実・主張）： 日付やステータスが付与された具体的な客観的事実や監査記録。
- Community（コミュニティ / 密結合クラスタ）： グラフ上で密接に結びついたエンティティ群。グラフクラスタリングアルゴリズム（Leiden Algorithm）によって多層的に自動検出されます。
3. GraphRAGのインデックス構築フロー
詳細な処理ステップ：
-
固有表現・関係抽出（NER & Relation Extraction）： 各チャンクから
(Entity A, Relationship, Entity B)のトリプレットおよびClaimsをLLMで構造化抽出。 - エンティティ統合（Entity Resolution）： 表記揺れ（例：「マイクロソフト」「MSFT」「日本マイクロソフト株式会社」）を1つの正規化エンティティに名寄せ統合。
- 階層的コミュニティ検出（Community Detection）： Leiden法を用いて、グラフ全体を大コミュニティ（Level 1）、中コミュニティ（Level 2）、小コミュニティ（Level 3）に分割。
- コミュニティ要約レポートの生成（Community Summaries）： LLMが各コミュニティ内の全ノード・エッジ・クレームを読み込み、網羅的な「コミュニティ要約レポート」を作成。このレポートをベクトル化して検索可能にします。
4. Local Search vs Global Search の使い分け
GraphRAGは、質問の粒度に応じて2つの全く異なる検索エンジンを提供します。
┌──────────────────────────────────────────────────────────────────────────┐
│ 1. LOCAL SEARCH（個別エンティティに関する深い質問） │
│ 質問例: 「A社との部品供給契約を承認したのは誰か？」 │
│ フロー: エンティティ "A社" を特定 ──> 近傍ノード（Neighbors）と関係性を探索│
│ ──> 紐づく原文チャンクを抽出して回答生成 │
└──────────────────────────────────────────────────────────────────────────┘
┌──────────────────────────────────────────────────────────────────────────┐
│ 2. GLOBAL SEARCH（全体傾向・コーパス全域の包括的質問） │
│ 質問例: 「今年度のサプライチェーンにおける主要な構造的リスクは何か？」 │
│ フロー: 生テキストは走査しない ──> Level 1/2の「コミュニティ要約レポート」群を取得│
│ ──> 各要約をLLMで並列処理（Map）──> 最終回答を統合生成（Reduce） │
└──────────────────────────────────────────────────────────────────────────┘
5. メタデータ階層とエンタープライズ権限制御（Enterprise ACL）
本番運用において最もクリティカルな要件は、部署間・テナント間でのデータ漏洩を完全に防ぐセキュリティ機構です。
事前フィルタリング（Hard Pre-filtering）の徹底
ベクトル検索やグラフ探索を実行する前に、認証トークンから抽出したユーザーコンテキストを用いて、データベースレベルで検索空間を厳密に遮断します。
security_filter.py
# Qdrant / Milvus / OpenSearch 等における事前フィルタ設定例
search_filter = {
"must": [
{"key": "tenant_id", "match": {"value": user_session.tenant_id}},
{"key": "department", "match": {"value": user_session.department}},
{"key": "clearance_level", "range": {"lte": user_session.security_clearance}}
]
}
6. エンタープライズ本番アーキテクチャの完全設計図
Part 1からPart 5までのすべての要素技術を結集した、エンタープライズグレードの本番RAGパイプラインです。
ユーザーの質問 (User Query)
│
[ 1. Guardrails & Safety ]
(入力検証・プロンプトインジェクション検知)
│
[ 2. Intent & Domain Router ]
(質問分類：ピンポイント / 全域分析 / SQL集計)
│
┌──────────────────────┴──────────────────────┐
▼ ▼
[ 3A. セキュリティフィルタ ] [ 3B. クエリ変換・拡張 ]
(テナント・部署・閲覧権限) (HyDE・Step-Back・代名詞補正)
│ │
└──────────────────────┬──────────────────────┘
│
[ 4. Hybrid Retrieval Orchestrator ]
│
┌──────────────┬─────────────┼─────────────┬──────────────┐
▼ ▼ ▼ ▼ ▼
[ Sparse BM25 ] [ Dense Vector] [Parent-Child] [ Graph/RAPTOR] [ SQL / API ]
(完全一致・品番) (意味類似度) (文書構造維持) (全域要約推論) (構造化DB集計)
│ │ │ │ │
└──────────────┴─────────────┼─────────────┴──────────────┘
│
[ 候補プール: Top 50 ]
│
[ 5. Cross-Encoder Reranker ]
(高精度な再ランキング・ノイズ除去)
│
[ 厳選候補: Top 5 ]
│
[ 6. Context Assembler & Compactor ]
(親チャンク重複排除・トークン圧縮)
│
[ 7. Prompt Assembly ]
│
[ 8. LLM 回答生成 ]
│
[ 9. Hallucination Check & Citation ]
(グラウンディング検証・引用文献付与)
│
最終回答
7. 階層型RAG 5大パターンの総合比較
| 評価軸 | Flat RAG | Parent–Child | Multi-Rep | RAPTOR | GraphRAG |
|---|---|---|---|---|---|
| 文脈の深さ | 低い | 極めて高い | 高い | 極めて高い | 全域的（Global） |
| 適合率（Precision） | 中程度 | 極めて高い | 極めて高い | 高い | 極めて高い |
| 再現率（Recall） | 低い | 高い | 極めて高い | 極めて高い | 最高 |
| 構築コスト（LLM） | $0$ | ほぼ $0$ | 中程度 | 高い | 極めて高い |
| 検索レイテンシ | < 100ms | < 150ms | < 150ms | 200 - 400ms | 500ms - 2s |
| 実装・運用難易度 | 容易 | 容易 | 中程度 | やや高 | 最高 |
| 最適なユースケース | 短文FAQ | 規程集・契約書 | 表・コード・画像 | 大部レポート・論文 | 全社ナレッジベース |
8. 本番選定のための意思決定ツリー（Decision Tree）
9. 本番運用における主要アンチパターン
本番運用で避けるべき6大失敗パターン:
- 小規模データへのGraphRAG乱用： 数百ページの文書に対して高額なLLMコストを投じてGraphRAGを組むこと。Parent-Child＋Rerankerの構成で95%の要件はより高速・低コストに解決できます。
- 構造を無視した固定文字数カット： テーブルの分断や文の途中切断を放置すること。
-
型番・コード検索へのベクトル検索単体運用：
ERR_504_GATEWAYやCTR-2024-001のような識別番号は、必ず BM25（キーワード完全一致） を併用すること。 - Parent Chunkの重複展開： 重複排除を行わずに同一の親テキストを多重にプロンプトへ詰め込み、コンテキスト枠を浪費すること。
- 更新時の同期不全： 原文が修正されたにもかかわらず、Summary Node や Community Summary の再生成を怠り、古い知識が残留すること。
- 評価メトリクスの欠如（No Evaluation）： テストセットを用意せず、エンジニアの主観的な感覚だけでチャンクサイズやプロンプトを調整すること。
付録
付録A — 検索品質評価（Evaluation Playbook）
評価なきシステム改善は、計器を見ずに飛行機を操縦するようなものです。
1. オフライン評価とオンライン評価の分離
- オフライン評価（Offline Evaluation）： コード修正やモデル変更時に、静的なテストデータセット（Golden Dataset）を用いて自動実行。CI/CDパイプラインに組み込み、性能劣化（Regression）を検知。
- オンライン評価（Online Evaluation）： 実運用中のユーザーフィードバック（Good/Bad、コピー率、再検索率）の収集と、ランダムサンプリングログに対する LLM-as-a-Judge による継続監査。
2. 検索フェーズの主要指標（Retrieval Metrics）
- Recall@K: 正解のコンテキストが上位 $K$ 件以内に含まれている割合（目標：$K=5$ で $0.85 \sim 0.90$ 以上）。
- Precision@K: 取得した $K$ 件のうち、真に関連していた文書の割合。
- MRR (Mean Reciprocal Rank): 最初の正解文書が出現した順位の逆数平均。
- NDCG (Normalized Discounted Cumulative Gain): 関連度の高い文書が上位に並んでいるかを測る順位考慮指標。
3. 生成フェーズの主要指標（Generation Metrics - Ragas / TruLens基準）
- Faithfulness（忠実性 / 根拠性）： LLMの回答が、プロンプトに渡されたコンテキストのみに基づいているか（ハルシネーションの検知）。
- Context Precision（コンテキスト適合度）： 関連情報がプロンプトの先頭近くに配置されているか。
- Answer Relevance（回答適合度）： ユーザーの質問の意図に対して過不足なく答えているか。
4. Golden Dataset の作成手法
- ドキュメント群から代表的なテキストブロックを100〜200件ランダム抽出。
- 高性能LLM（GPT-4o, Claude 3.5 Sonnet等）を用いて、
(Question, Ground_Truth_Context, Ground_Truth_Answer)の三つ組を自動生成。 - 業務担当者（ドメインエキスパート）がレビューし、少なくとも50〜100件の高品質な正解セットを確定。
付録B — 階層型RAG 導入10ステップチェックリスト
| ステップ | フェーズ名 | 具体的アクション | 達成すべきアウトプット |
|---|---|---|---|
| 01 | Data Audit | 対象文書の形式、表・コードの割合、見出し階層の深さを調査。 | データ棚卸しシート・トークン試算 |
| 02 | Parser Strategy | ドキュメント種別ごとに最適な専用パーサーを選定・検証。 | 構造を壊さないテキスト・表抽出パイプライン |
| 03 | Metadata Schema |
doc_id, parent_id, section_title, tenant_id を定義。 |
Pydantic による共通スキーマ定義 |
| 04 | Hierarchy Builder | Parent (1000 tokens), Child (150-200 tokens), Overlap (15%) を設定。 | 親子リレーションツリーの構築 |
| 05 | Multi-Rep Gen | 表データに対する要約文生成、重要FAQに対する想定質問生成。 | 検索用マルチベクトルの生成 |
| 06 | Dual Storage | Vector Store（Child/Summary）と Document Store（Parent全文）を構築。 | Key-Valueで連携する二重ストレージ基盤 |
| 07 | Hybrid Pipeline | Dense Vector + Sparse BM25 のハイブリッド検索（RRF統合）を実装。 | 意味検索とキーワード完全一致の両立 |
| 08 | Reranker Setup | Cross-Encoder Reranker（BGE-Reranker等）を組み込み、上位5件を厳選。 | プロンプトノイズの70%削減 |
| 09 | Context Assembler | 親チャンクの重複排除とコンテキスト整形処理を実装。 | トークン効率に優れたプロンプト生成機構 |
| 10 | Monitoring & Ops | Langfuse や Arize Phoenix によるトレーシングと品質モニタリングを開始。 | レイテンシ・コスト・精度の常時可視化ダッシュボード |
12. シリーズの終わりに
いかなるRAGアーキテクチャも、すべての課題を一撃で解決する「銀の弾丸（Silver Bullet）」ではありません。優れたAIエンジニアの真価は、データの性質を正しく見極め、不要な複雑性を排除し、要件に対して最もシンプルで費用対効果の高い構造を選択することにあります。
最も推奨される本番導入ステップは以下の通りです。
Flat RAGの適正化 ──> + Hybrid Search ──> + Reranker ──> Parent–Child ──> Multi-Rep ──> RAPTOR / GraphRAG
本シリーズが、皆様の堅牢で信頼性の高いエンタープライズRAGシステムの設計・開発の一助となれば幸いです。
参考文献
- Edge, D., et al. (2024). From Local to Global: A Graph RAG Approach to Query-Focused Summarization (Microsoft Research) - arXiv:2404.16130
- Microsoft Official Project. GraphRAG Open Source Repository & Architecture Docs
- Es, S., et al. (2023). RAGAS: Automated Evaluation of Retrieval Augmented Generation - arXiv:2309.15217
- Trajanoska, M., et al. (2023). Enhancing Knowledge Graph Construction with Large Language Models
- Arize AI. Phoenix: Open-Source LLM Tracing, Observability & Evaluation
- Langfuse Engineering. Open-Source LLM Engineering & Tracing Platform