架構

GraphRAG 實施指南：從文字文件到生產級知識圖譜檢索

作者：IdeaBosque最後更新：2026年8月26日

Microsoft 的 GraphRAG 研究在複雜多實體查詢上展示了 86% 的全面性，而傳統向量 RAG 在同一評估集上僅為 57%——29 個百分點的差距在問題需要遍歷關係而非僅匹配文字時就會顯現。差距的存在是因為產品知識是一個圖：依賴關係、版本、相容性、替代品、定價層級和區域可用性限制是關係，而非嵌入。然而大多數團隊從傳統 RAG 開始，因為 GraphRAG 的建構成本歷史上為 12-16 週，而僅向量檢索為 6-8 週。過去一年發布的兩個開源工具——Neo4j 的 neo4j-graphrag Python 套件及其 SimpleKGPipeline 和 GraphRAG SDK 1.0（LLM 無關，2026 年 4 月）——大幅降低了建構成本，使 GraphRAG 在數週內可行，而非數月。本指南介紹將非結構化文件轉化為生產級知識圖譜檢索系統的五階段流程：模式設計、實體提取、社群檢測、圖檢索和代理整合。它指出了成本陷阱、治理衰退風險，以及傳統 RAG 以 30% 的努力獲得 85% 結果的決策點。

關鍵要點

86% 全面性 vs 57% 向量 RAG — Microsoft GraphRAG（Edge et al., 2024）在複雜多實體查詢上測量了基於圖的檢索與向量 RAG 的對比。29 個百分點的差距是遍歷關係而非匹配嵌入的結構性優勢。
檢索準確率提升 77.6%，解決時間減少 28.6% — LinkedIn 在 Jira 工單上的 GraphRAG 生產部署測量了這兩項指標與基線向量 RAG 的對比。圖結構捕獲了向量搜尋遺漏的內容。
GraphRAG 使 AI 代理的準確性提高 80% — Neo4j 關於幻覺減少的白皮書發現，圖結構化檢索將模型錨定在已驗證的關係中，減少了虛假答案。GraphRAG 不僅是更好的檢索；它是一種幻覺緩解技術。
傳統 RAG 以 30% 的努力達到 GraphRAG 85-90% 的效能 — GraphRAG 從頭建構需要 12-16 週，而傳統 RAG 為 6-8 週，且每查詢的圖更新為 O(N) 每工單，而每文件為 O(1)。85% 的閾值是決策點。
SimpleKGPipeline 和 GraphRAG SDK 1.0 將建構縮短到數週 — neo4j-graphrag Python 套件提供了一個 SimpleKGPipeline，在單一非同步流程中處理文字分割、實體提取、嵌入和圖建構。GraphRAG SDK 1.0 是 LLM 無關的，支援 OpenAI、Anthropic、Google、Cohere 和 100+ 本地模型透過統一介面。

五階段流程

生產級 GraphRAG 系統有五個階段。每個階段有一個影響成本、準確性和維護負擔的決策點。各階段是順序但迭代的——實體提取饋入社群檢測，社群檢測饋入檢索，而治理三者的模式隨著語料庫揭示新實體類型而精煉。

該流程將非結構化文字轉化為可查詢的知識圖譜，然後檢索將 LLM 回答錨定在已驗證關係中的子圖：

階段 1：模式設計 — 決定提取品質的決策

模式是領域和提取流程之間的契約。它定義了存在哪些節點類型、哪些關係類型連接它們，以及哪些實體-關係模式是有效的。寬鬆的模式（無約束）產生一個有數百種虛假實體類型的嘈雜圖。嚴格的模式（約束模式）產生一個乾淨的圖，但可能遺漏模式未預期到的關係。

Neo4j 的 neo4j-graphrag Python 套件允許將模式物件傳遞給 SimpleKGPipeline，包含三個欄位：node_types、relationship_types 和 patterns。patterns 欄位是約束——它告訴 LLM 哪些實體-關係-實體三元組是有效的。對於 B2B 產品支援圖，模式可能如下：

節點類型： Product, Component, Supplier, PriceTier, CustomerSegment, Region, Document, Ticket
關係類型： SUBSTITUTE_OF, DEPENDS_ON, COMPATIBLE_WITH, SUPPLIED_BY, PRICED_IN, AVAILABLE_IN, RESOLVED_BY
模式： (Product, SUBSTITUTE_OF, Product), (Product, DEPENDS_ON, Component), (Product, SUPPLIED_BY, Supplier), (Product, PRICED_IN, PriceTier), (Product, AVAILABLE_IN, Region), (Ticket, RESOLVED_BY, Document)

模式是第一個成本陷阱。過於狹窄的模式會遺漏重要的關係（LLM 提取「產品 A 由供應商 X 製造」，但 Vendor 不是定義的節點類型，因此關係被丟棄）。過於寬泛的模式會產生噪音（LLM 將每個名詞提取為實體，用無用的節點淹沒圖）。解決方案是迭代的：從基於圖必須回答的問題的約束模式開始，在樣本語料庫上執行提取，檢查圖是否有遺漏的關係和噪音，然後精煉。在模式穩定之前，典型需要兩到三次迭代。

階段 2：實體提取 — 成本中心

實體提取是 LLM 做工作的地方——也是成本累積的地方。每個文字塊被發送到 LLM，並帶有一個提示，要求它提取匹配模式的實體和關係。Microsoft 的 GraphRAG 索引流程使用 LLM 驅動的方法：每個塊使用 LLM 分析，以在提示模板引導下提取命名實體和關係。FalkorDB GraphRAG SDK 1.0提供相同的 LLM 驅動提取，但與 LLM 無關——它透過統一介面支援 OpenAI、Anthropic、Google、Cohere、本地開源模型和 100+ 其他模型，這意味著可以透過選擇更便宜的模型進行提取、更強的模型進行查詢回答來優化提取成本。

成本算術很簡單：1,000 個文字塊需要 1,000 次 LLM 呼叫進行實體提取。以 GPT-5.6 Sol 每百萬輸入 token $4 和每百萬輸出 token $20 的價格，一個 1,000 塊的語料庫，每塊 500 token 和每塊 200 token 的提取輸出，輸入 token 約 $4，輸出 token 約 $4——提取過程約 $8。一個 10,000 塊的語料庫成本為 $80。提取是每次語料庫建構的一次性成本，但在語料庫變更時會重複。這就是模型選擇的推理經濟學發揮作用的地方：使用更便宜的開源權重模型進行提取（例如 Qwen3.8 Max 每百萬輸出 token $2）將輸出 token 成本減半，而不會對結構化實體-關係提取的品質產生實質影響。

實體消歧跟隨提取。LLM 可能從一個塊提取"Jon"，從另一個塊提取"Jon Marquez"——兩者指的是同一個人。SimpleKGPipeline 自動處理此問題，合併具有相同標籤和名稱屬性的實體。對於生產系統，通常需要自訂實體消歧邏輯——名稱模糊匹配、基於上下文的消歧或高價值實體的人工審核。跳過實體消歧會產生一個有重複節點的圖，這會破壞關係遍歷（查詢從"Jon"遍歷，但答案連接到"Jon Marquez"）。

階段 3：社群檢測 — 全域查詢的賦能者

社群檢測是使 GraphRAG 能夠回答傳統 RAG 無法回答的全域問題的關鍵。Microsoft 的 GraphRAG 方法（Edge et al., 2024）引入了「從本地到全域」的範式：在實體被提取且圖被建構後，社群檢測演算法（Leiden 或 Louvain）將相關實體分組為簇，LLM 為每個社群生成摘要。這些社群摘要使全域搜尋成為可能——諸如「整個語料庫的主要主題是什麼？」之類的問題——而向量 RAG 無法回答，因為它檢索的是沒有主題結構的孤立塊。

實際工作流程：

在實體-關係圖上執行社群檢測（Leiden 演算法）。演算法將圖分區為密集連接實體的簇。Memgraph 3.0 將 Leiden 作為內建演算法提供，Neo4j 透過 Graph Data Science 庫提供。
對於每個社群，將社群的實體和關係發送給 LLM 以生成摘要。這是第二次 LLM 成本過程——每個社群一次呼叫，而非每個塊，因此通常比提取過程便宜。
將社群摘要與圖一起儲存。在查詢時，全域搜尋檢索最相關的社群摘要並使用它們回答主題問題。本地搜尋遍歷特定子圖以回答實體特定問題。

兩種搜尋模式服務於不同的問題。本地搜尋透過從 SKU 節點遍歷圖來回答「哪些產品與 SKU X 相容？」。全域搜尋透過查詢跨數百個實體聚合的社群摘要來回答「我們產品目錄中的主要供應鏈風險是什麼？」。傳統 RAG 都無法回答——向量搜尋檢索單獨的塊，而非主題摘要。

階段 4：圖檢索 — 確定性查詢，非語義猜測

圖檢索是 GraphRAG 與傳統 RAG 分歧最大的地方。傳統 RAG 嵌入查詢，在向量索引中搜尋最相似的塊並返回它們。GraphRAG 透過確定性查詢遍歷圖——Neo4j 的 Cypher，任何圖資料庫的 GQL——返回已驗證的關係，而非語義近似。

檢索層通常結合兩種策略：

圖遍歷 — Cypher 查詢從實體節點遍歷到其關係。對於支援問題「客戶 Y 可以在區域 Z 獲得產品 X 的批量價格嗎？」，查詢遍歷：Product X -> PRICED_IN -> BulkTier, Product X -> AVAILABLE_IN -> Region Z, CustomerSegment Y -> QUALIFIES_FOR -> BulkTier。如果遍歷成功，答案錨定在已驗證的圖關係中。如果任何連結缺失，圖會明確說明——不像向量搜尋返回相似但錯誤的塊。
向量相似度 — 對於不需要關係遍歷的問題，基於塊嵌入的向量搜尋（與圖一起儲存）處理語義匹配。GraphRAG SDK 1.0結合兩者：「多路徑檢索結合圖遍歷和語義搜尋，跨檢索策略的排序結果合併。」這種混合方法將圖用於結構化問題，向量用於語義問題，根據查詢類型自動路由。

可稽核性優勢是除錯好處。當圖查詢返回錯誤答案時，人工可以追溯路徑（Ticket -> Product -> Tier -> Segment -> Region -> Stockout）並準確看到哪個關係缺失或不正確。當向量搜尋返回錯誤答案時，人工看到的是一個沒有路徑可追溯的文字塊。Neo4j 的 GraphRAG 文件將其表述為「GraphRAG 恢復了向量丟棄的內容——人類可閱讀的顯式知識。」LinkedIn 在生產中測量的 77.6% 檢索準確率提升基於這種可稽核性：當圖錯誤時，可以找到並修復錯誤；當向量錯誤時，只能猜測。

階段 5：代理整合 — MCP 模組和治理衰退

最後階段將圖檢索作為型別化 MCP 工具暴露給 AI 代理。代理不直接編寫 Cypher 查詢——它呼叫 rag_query(question: string) -> answer 或 get_substitutes(sku: string) -> list[Product] 等工具，MCP 模組在內部將其轉換為圖查詢。這遵循 MCP Module Code Standard 模式：型別化工具定義、輸入驗證、每次呼叫稽核日誌和速率限制。

治理衰退風險是大多數 GraphRAG 教程忽略的設計考慮。當知識圖譜用作代理的檢索層時，圖的約束和策略成為代理上下文視窗的一部分。如果上下文視窗是可壓縮的——考慮到長執行代理的經濟學，所有上下文視窗都是——從圖載入的約束可能在壓縮期間被靜默丟棄。一個正確檢查「此產品在區域 Z 是否可用？」的代理可能在上下文壓縮事件後停止檢查，因為約束在上下文中，而非程式碼中。解決方案是架構性的：關鍵約束必須由 MCP 模組的程式碼強制執行，而非代理的上下文。如果違反約束，模組拒絕工具呼叫，無論代理的上下文說什麼。這與kill-switch 架構強制執行的模式相同：依賴於代理記得表現良好的治理是在壓縮下失敗的治理。

決策點：何時建構 GraphRAG vs 傳統 RAG

並非每個檢索問題都需要知識圖譜。決策框架建立在一個問題上：查詢是否需要遍歷向量相似度無法表示的關係？

標準	傳統 RAG	GraphRAG
建構時間	6-8 週	從頭 12-16 週；使用 SimpleKGPipeline 或 GraphRAG SDK 4-8 週
每查詢更新	每文件 O(1)	每受影響實體子圖 O(N)
全面性	多實體查詢 57%	多實體查詢 86%
檢索準確率	基線	+77.6%（LinkedIn 生產）
幻覺率	基線	-80%（Neo4j 白皮書）
可稽核性	文字塊，無路徑	人工可追溯圖路徑
成本驅動	向量索引大小	每塊提取的 LLM 呼叫
問題類型	「查詢相似文字」	「遍歷關係：替代品、依賴、相容性」
何時選擇	70% 查詢是語義相似度	30% 查詢需要關係遍歷

85% 閾值：當大多數查詢是語義相似度查找時，傳統 RAG 以 30% 的努力達到 GraphRAG 85-90% 的效能。當查詢需要遍歷向量搜尋扁平化的關係時——產品相容性、替代鏈、依賴解析、多跳推理——GraphRAG 成為正確選擇。對於回答「查找關於 API 認證文件」的支援團隊，傳統 RAG 足夠。對於回答「哪個 API 版本與此產品依賴相容，以及在該區域不可用時替代品是什麼」的支援團隊，GraphRAG 是唯一返回正確答案的檢索策略。

成本陷阱及如何避免

提取成本陷阱。 實體提取每塊需要一次 LLM 呼叫。一個 50,000 文件的語料庫，每文件 10 塊，是 500,000 次 LLM 呼叫。以每 1,000 塊 $8 計算，僅提取過程就是 $4,000。解決方案：使用更便宜的模型進行提取（結構化實體-關係提取是一個邊界明確的任務，不需要前沿模型），使用更強的模型進行查詢回答。GraphRAG SDK 1.0 的 LLM 無關架構支援這種拆分——提取和檢索使用不同模型。

實體消歧陷阱。 沒有實體消歧，圖包含破壞遍歷的重複節點。從一個文件提取的"Product A"和從另一個文件提取的"ProductA"是兩個節點，而非一個。SimpleKGPipeline 處理基本消歧（相同標籤和名稱），但生產系統需要模糊匹配和高價值實體的人工審核。為此做預算——這不是可選的。

治理衰退陷阱。 載入到代理上下文中的圖約束容易受到上下文壓縮的影響。解決方案是架構性的：在 MCP 模組的程式碼中強制執行關鍵約束，而非代理的上下文中。代理「知道」的約束是可以被遺忘的約束；程式碼強制執行的約束是持久的約束。

維護陷阱。 GraphRAG 不是一次建構。當語料庫變更時，提取流程必須為受影響的文件重新執行，圖必須更新。每查詢的圖更新是 O(N)——更新一個實體可能需要為所有連接的實體重新提取關係。傳統 RAG 的每查詢更新是 O(1)——一個文件變更，一個向量重新嵌入。對於頻繁變更的語料庫，GraphRAG 的維護成本可能在一年內超過建構成本。