GraphRAG：把知識做成圖，讓 LLM 沿著關係推理

TL;DR 向量搜尋找相似，圖搜尋走關係。當問題需要跨多個實體的推理（岩場→路線→完攀者→難度分布），GraphRAG 比標準 RAG 更有優勢。

#rag #graphrag #knowledge-graph #multi-hop #microsoft

Knowledge Graph 的結構
GraphRAG 的查詢模式
microsoft/graphrag 的現況
圖真的比較好嗎
圖的建構
Graph + Vector 混合
在攀岩社群的潛力
工程成本
整體來說
更新紀錄
參考資料

系列: RAG 技法大全 (25 / 52)

Self-Reflection + LLM-as-Judge：讓 AI 評估自己的回答 LongRAG：用長上下文模型重新思考 RAG 的 Chunking 策略

🌏 English version

標準 RAG 找的是「語義相近的文件」，但有些問題需要的不是語義相似，而是關係推理。

「龍洞哪些路線是第一次戶外攀岩的人完攀的」—— 這個問題涉及：

完攀記錄（誰完攀了什麼路線）
使用者資料（他是第幾次戶外）
路線屬性（難度、類型）

向量搜尋找不到這些關係，它只能找「語義上關於新手完攀的文件」，無法沿著實體關係走。

GraphRAG 在知識圖譜上做搜尋，沿著實體之間的關係走，適合這類 multi-hop 多跳推理問題。

Knowledge Graph 的結構

攀岩場景的知識圖譜可能長這樣：

[Region: 北部]
    ↓ contains
[Area: 瑞芳]
    ↓ contains
[Crag: 龍洞]
    ↓ has_route
[Route: 龍洞北壁某路線]
    ↓ has_grade     ↓ has_type      ↓ completed_by
[Grade: 5.11a]  [Type: 運動攀登]  [User: Alice]
                                        ↓ has_level
                                   [Level: 中級]

每個節點是一個實體，每條邊是一種關係。圖查詢可以沿著邊走，組合多個條件。

GraphRAG 的查詢模式

Microsoft GraphRAG（論文 2024 年 4 月發表）最為人知的是兩種查詢模式，Local Search 與 Global Search：

Local Search：從特定實體出發，沿著關係擴展，回答關於特定實體的問題。

問：「龍洞有哪些適合中級攀岩者的路線」
→ 找到 Crag: 龍洞
→ 遍歷 has_route 邊 → 找到所有路線
→ 過濾 grade 在中級範圍的
→ 取路線描述 → 送給 LLM 生成回答

Global Search：以 map-reduce 的方式掃過所有 LLM 事先生成的 community report（不是在圖上做數值聚合排序），回答「整體趨勢」類的問題。官方說明

問：「台灣北部最受歡迎的岩場是哪些」
→ 聚合 Region: 北部 下所有 Crag
→ 計算每個 Crag 的完攀記錄數
→ 排序後取 Top-K
→ 送給 LLM 生成回答

不過官方 query engine 後來又多了兩種：DRIFT Search（把 community 摘要帶進 local search 的起點，再把查詢展開成後續追問）與 Basic Search（就是一般向量 RAG，放在同一套工具裡方便對照）。實際用哪一種、各自的參數怎麼調，直接看官方 Query Engine 文件比較保險。

microsoft/graphrag 的現況

這裡要先講一件會影響選型的事：microsoft/graphrag repo 已經進入維護模式。repo README 上的公告寫得很直白——自 2024 年 7 月首次釋出以來前沿模型能力變化劇烈，專案「largely in maintenance mode」，不再接受新功能 PR，只做 bug 修復與相依套件（尤其 CVE）更新。它同時聲明這是研究專案的示範程式碼，不是官方支援的 Microsoft 產品。

所以如果你打算把它當成生產基礎設施，要有心理準備：能用，但不會再往前跑。

另一個常被引用的後續是 LazyGraphRAG。微軟研究院在 2024 年 11 月的部落格宣稱它「建索引成本與一般向量 RAG 相同、是完整 GraphRAG 的 0.1%」，而在全域查詢上「品質與 GraphRAG Global Search 相當，但查詢成本低 700 倍以上」。做法是不預先做 LLM 摘要，把 LLM 呼叫延後到查詢階段。

要注意的是：這些數字全部來自那篇部落格，沒有經同儕審查的論文，而且 LazyGraphRAG 並沒有隨 microsoft/graphrag 開源（社群在 repo discussion 追問釋出時程多年未果，如今 repo 又進了維護模式）。把它當成一個「思路方向」比當成「可以裝來用的東西」實際。

圖真的比較好嗎

值得把反面證據一起放進來。2025 年的 GraphRAG-Bench（《When to use Graphs in RAG》）開宗明義指出：儘管概念上很有說服力，「近期研究一再回報 GraphRAG 在許多真實任務上輸給 vanilla RAG」，因此他們才做了一個涵蓋事實檢索、複雜推理、脈絡摘要與創造性生成的分級基準，來釐清圖結構到底在什麼條件下才真的有用。

換句話說，「有實體關係就該上圖」不是安全的預設。上圖之前先確認你的問題型態確實是多跳關係推理，而不只是換個方式做語義檢索——後者用向量搜尋就好，還便宜很多。

圖的建構

有兩種建構方式：

手動定義：根據業務邏輯定義實體和關係，從結構化資料（資料庫）填充。

// 從資料庫建構圖
const graph = new KnowledgeGraph();

for (const crag of crags) {
  graph.addNode({ id: crag.id, type: 'Crag', properties: crag });
  graph.addEdge({ from: crag.areaId, to: crag.id, relation: 'contains' });
}

for (const route of routes) {
  graph.addNode({ id: route.id, type: 'Route', properties: route });
  graph.addEdge({ from: route.cragId, to: route.id, relation: 'has_route' });
}

LLM 自動提取：從非結構化文字中提取實體和關係，建構圖。Microsoft GraphRAG 用這種方式，從文件中提取 entity 和 relationship。

攀岩場景有清晰的資料庫 schema，手動定義更準確，不需要靠 LLM 從文字推斷。

Graph + Vector 混合

GraphRAG 不是取代向量搜尋，而是補充它。混合架構：

查詢
  ↓
[Query Classification]
  ├ 關係型查詢 → [圖查詢] → 結構化結果 → LLM 生成
  ├ 語義型查詢 → [向量搜尋] → 相似文件 → LLM 生成
  └ 混合型查詢 → [圖查詢 + 向量搜尋] → 結合結果 → LLM 生成

圖查詢擅長「誰完攀了什麼」、「這個岩場屬於哪個地區」這類關係問題；向量搜尋擅長「描述類似 X 的路線」這類語義問題。

在攀岩社群的潛力

幾個用 GraphRAG 能顯著改善的查詢：

社群推薦：「和我程度差不多的攀岩者最近在爬什麼路線」

圖查詢：找到相近程度的使用者 → 找他們最近的完攀記錄 → 取路線

進階路徑規劃：「我完攀了龍洞 5.10b 之後，下一條應該挑戰什麼」

圖查詢：找類似風格但難度稍高的路線 → 考慮其他人的完攀順序

岩場關係查詢：「龍洞附近還有什麼岩場」

圖查詢：找到龍洞所屬 Area → 找同一 Area 的其他 Crag

這些查詢靠向量搜尋很難實現，但在知識圖譜上走幾步就能找到。

工程成本

GraphRAG 的工程複雜度比標準 RAG 高很多：

需要維護圖資料庫（Neo4j、或用 D1 模擬）
圖查詢語言（Cypher、Gremlin）有學習成本
圖和向量索引要同步更新

在 Cloudflare Workers 環境，沒有原生的圖資料庫支援。可以用 D1 模擬簡單的圖（adjacency list），但複雜的圖遍歷效能會受限。

整體來說

GraphRAG 解決的是向量搜尋的一個盲點：關係推理。對有明確實體關係、而且問題確實需要多跳的垂直領域（攀岩、醫療、法律），知識圖譜有機會顯著提升查詢品質——但這是「有機會」，不是保證，GraphRAG-Bench 的結論就是「常常反而輸給 vanilla RAG」。

代價則是確定的：工程複雜度大幅提升，加上官方參考實作已停止演進。對攀岩社群平台，標準 RAG 目前已經夠用，GraphRAG 是值得在後期評估的方向，特別是當「推薦系統」和「社群關係查詢」需求越來越強時——評估時記得先跑一組自家的多跳查詢，用實測決定，別用直覺。

更新紀錄

2026-08-19：對照官方文件逐篇查證翻新，移除易腐內容，並收進「RAG 技法大全」系列

參考資料

From Local to Global: A Graph RAG Approach to Query-Focused Summarization (2024) — Edge et al.，GraphRAG 原始論文
Microsoft GraphRAG - GitHub — 官方實作，README 已標示進入維護模式
GraphRAG Query Engine 文件 — Local / Global / DRIFT / Basic 四種查詢模式
LazyGraphRAG: Setting a new standard for quality and cost — 微軟研究院部落格，成本數字出處（未經同儕審查，程式碼未開源）
When to use Graphs in RAG: A Comprehensive Analysis for Graph Retrieval-Augmented Generation — Xiang et al.，GraphRAG-Bench，指出 GraphRAG 常輸給 vanilla RAG
NobodyClimb 系統架構：Cloudflare 全端攀岩社群平台
NobodyClimb AI 架構：20 節點 RAG Pipeline