Ian Chou's Blog

GraphRAG 深度解析：自動知識圖譜的威力與局限

GraphRAG 深度解析：自動知識圖譜的威力與局限

TL;DR

Part 1：什麼是 GraphRAG？

1.1 普通 RAG 的問題

普通向量搜尋只看「局部相似」：

Query: "這個系統的完整流程是什麼？"
       ↓
向量搜尋 → 找到相似段落
       ↓
[段落A] [段落B] [段落C]
（零散的、沒有順序、不知道關係）

問題：AI 只拿到碎片，無法理解「A → B → C」的流程。

1.2 GraphRAG 的解法

GraphRAG 先建立「知識圖譜」，再用圖譜回答：

建圖階段：
文件 → LLM 提煉 → "Kubernetes" → 用到 → "LanceDB" → 部署到 → "Railway"

查詢階段：
Query: "系統流程？"
       ↓
圖譜遍歷 → 找到完整鏈條
       ↓
Kubernetes → LanceDB → Railway（有順序、有關係）

Part 2：5 分鐘快速上手

2.1 安裝

pip install graphrag

2.2 建圖譜

# 建立資料夾
mkdir graphrag-blog && cd graphrag-blog

# 複製你的文件
cp ../your-blog/*.md ./

# 設定（可選，用預設也行）
cat > settings.yaml << EOF
llm:
  model: gpt-4o-mini
  api_key: $OPENAI_API_KEY
embedding:
  model: text-embedding-3-small
chunk_size: 512
EOF

# 一鍵建圖譜！
graphrag index --root .

自動做的事：

  1. 將文件切成 chunks
  2. LLM 提煉 entities（概念）
  3. LLM 提煉 relations（關係）
  4. 建立圖譜索引

時間：100 個 MD 文件約 3-5 分鐘
成本：約 $0.3-0.5（小型專案）

2.3 查詢

# 全局問答（遍歷整個圖譜）
graphrag query "這個系統的完整架構是什麼？" --method global

# 局部問答（圖譜 + 向量混合）
graphrag query "LanceDB 怎麼用？" --method local --json

Part 3：GraphRAG 的「全局」是什麼？

3.1 Global vs Local 模式

模式 做法 適用
Global 遍歷整個圖譜，產生社區摘要 「整體架構」「全貌」
Local 局部圖 + 向量搜尋 「具體問題」「細節」

3.2 「全局」的真正意思

重要認知：GraphRAG 的「全局」是它從文件理解出來的，不是「真正的全局」。

GraphRAG 建圖流程：
1. 讀你的文件
2. LLM 提煉出它「認為」的概念和關係
3. 建成圖譜

問題：

Part 4：GraphRAG vs 手動知識圖譜

我在 Career RAG 專案中有一個手動維護的 skill-graph.json：

{
  "LangChain": {
    "implies": ["Python", "LLM"],
    "relatedTo": ["RAG", "Vector Database"]
  }
}

4.1 比較

面向 GraphRAG 手動 skill-graph.json
建立方式 LLM 自動提煉 專家手動設計
知識來源 文件內容 領域專業知識
準確度 可能有偏差 精確（你控制）
可控性 黑盒 白盒（可編輯）
維護 每次重建 手動更新
適用 探索未知 定義領域知識

4.2 何時用哪個？

需求 選擇
「LangChain 代表會 Python 嗎？」 ✅ 手動 skill-graph
「這個專案的流程是什麼？」 ✅ GraphRAG
「定義技能之間的關係」 ✅ 手動 skill-graph
「從 blog 探索關聯」 ✅ GraphRAG

Part 5：GraphRAG 的局限

5.1 品質取決於 LLM

同一份文件，不同 LLM 可能提煉出：

GPT-4o: "Kubernetes" → "部署到" → "Railway"
GPT-4o-mini: "K8s" → "用於" → "雲端"

哪個對？不確定。

5.2 文件沒寫 = 圖譜沒有

你的文件沒提到 "LangChain implies Python"
→ GraphRAG 不會知道
→ 但 skill-graph.json 可以明確定義

5.3 成本

Part 6：實際建議

6.1 你需要 GraphRAG 嗎？

你的問題是什麼？

├── 「技能 A 代表技能 B 嗎？」
│   └── ❌ 用手動 skill-graph
│
├── 「這份文件的整體流程？」
│   └── ✅ 考慮 GraphRAG
│
├── 「找相關的程式碼片段」
│   └── ❌ 用 LanceDB Hybrid
│
└── 「探索文件之間的關聯」
    └── ✅ 考慮 GraphRAG

6.2 混合架構

如果真的需要，可以混合使用：

┌─────────────────────────────────────┐
│         Skill Graph (手動)          │
│   精確的領域知識（技能推斷）         │
└─────────────────────────────────────┘
                 +
┌─────────────────────────────────────┐
│         GraphRAG (自動)             │
│   從文件探索的關係（全局問答）       │
└─────────────────────────────────────┘
                 +
┌─────────────────────────────────────┐
│         LanceDB Hybrid              │
│   精準的內容檢索（局部搜尋）         │
└─────────────────────────────────────┘

關鍵學習

  1. GraphRAG 不是魔法：它的「全局」是 LLM 從文件猜出來的
  2. 適合探索，不適合定義：領域知識還是要手動維護
  3. 門檻很低：5 分鐘就能建好，試試無妨
  4. 成本要考慮：頻繁更新的專案可能不划算
  5. 混合使用：GraphRAG + 手動圖譜 + 向量搜尋可以互補

相關資源