Key Findings
  • GraphRAG 透過自動建構知識圖譜並結合社群偵測與階層摘要，在全域性問題（「整個語料庫的主要主題是什麼？」）上，回答完整性較傳統向量 RAG 提升 50–70%
  • Microsoft Research 開源的 GraphRAG 系統採用 LLM 驅動的實體與關係抽取管線，將非結構化文本轉換為知識圖譜，無需人工標註即可完成圖譜建構
  • Local Query 適合精確事實查詢、Global Query 適合全域摘要與主題分析——兩種機制互補，涵蓋企業知識問答的完整場景
  • 企業級 GraphRAG 部署需整合圖資料庫（Neo4j / ArangoDB）、向量資料庫與 LLM 推論引擎，建議以混合檢索架構分階段落地

一、傳統 RAG 的瓶頸：為何向量檢索不夠

檢索增強生成（Retrieval-Augmented Generation, RAG）自 Lewis 等人於 2020 年提出以來[3]，已成為企業部署大型語言模型（LLM）的主流架構。其核心邏輯是：將企業文件切割為文本片段（chunks），透過嵌入模型轉換為向量，儲存於向量資料庫中；使用者提問時，以查詢向量檢索語義最相近的 chunks，作為 LLM 生成回答的上下文。這種方法在單點事實查詢場景表現優異，但隨著企業實際部署的深入，其結構性侷限逐漸暴露。

Gao 等人在 2023 年的 RAG 綜述研究中[5]指出，傳統向量 RAG 面臨三個核心瓶頸。第一是全域性問題的無力：當使用者提出「這批文件的核心主題是什麼？」或「所有報告中最常出現的風險因子為何？」這類需要橫跨整個語料庫進行綜合分析的問題時，向量檢索只能回傳與查詢語句表面語義相似的少數 chunks，無法提供全局視角。第二是多跳推理的斷裂：許多專業問題的回答需要串聯多個分散的知識片段——例如「A 公司的供應商 B 的工廠位於哪個地震帶？」——這要求系統理解實體之間的關係鏈，而非僅僅匹配語義相似度。第三是語義孤島效應：固定長度的文本分塊策略將原本語義連貫的段落強行切割，導致跨段落的因果關係、時序關係和層級關係在檢索過程中遺失。

更根本的問題在於，向量空間是一個「扁平」的語義表示——所有知識被壓縮為高維空間中的點，彼此之間只有距離關係，而缺乏結構性的連結。企業知識的本質是一張網絡：法規引用其他法規、產品依賴供應鏈、研究論文互相引用。當我們將這張網絡壓扁為一組向量時，大量的結構性資訊便不可逆地遺失了。這正是 GraphRAG 試圖解決的根本問題。

二、GraphRAG 的核心思想：結構化知識的力量

GraphRAG 的核心思想可以用一句話概括：在向量檢索之上，疊加一層知識圖譜的結構化理解。Microsoft Research 的 Edge 等人在 2024 年發表的開創性論文[1]中，正式提出了「從局部到全域」的 Graph RAG 方法，為這一方向奠定了學術與工程基礎。

知識圖譜（Knowledge Graph）是以圖結構（節點與邊）表示知識的形式化方法。Hogan 等人在 ACM Computing Surveys 的權威綜述中[4]定義了知識圖譜的三要素：實體（entities，圖中的節點，代表人、地、物、概念等）、關係（relations，圖中的邊，代表實體之間的語義連結）、屬性（attributes，附著於節點或邊的描述性資訊）。GraphRAG 的創新在於，它不要求事先手動建構知識圖譜，而是利用 LLM 的語言理解能力，從非結構化文本中自動抽取實體與關係，動態建構知識圖譜。

Pan 等人在 IEEE TKDE 發表的 LLM 與知識圖譜整合路線圖[2]中，將這種整合分為三種模式：KG 增強 LLM（用圖譜知識強化模型推理）、LLM 增強 KG（用語言模型自動建構圖譜）、以及 LLM 與 KG 的協同推理。GraphRAG 綜合運用了後兩種模式——先以 LLM 建構圖譜，再以圖譜結構輔助 LLM 的檢索與推理。

從系統架構的角度，GraphRAG 在傳統 RAG 的「索引 → 檢索 → 生成」管線中，插入了三個關鍵環節：圖譜建構（將文本轉換為實體-關係圖）、社群偵測（對圖譜進行層級化的社群分群）、社群摘要（為每個社群生成自然語言摘要）。這三個環節使得系統不僅能回答局部的精確問題，更能回答需要全局視角的開放性問題——這是傳統向量 RAG 無法達成的能力。

三、知識圖譜自動建構：從非結構化文本到圖

GraphRAG 的第一個技術環節，是將非結構化文本自動轉換為知識圖譜。這個過程在 Microsoft 的開源實作中[9]被稱為「Indexing Pipeline」（索引管線），主要包含四個步驟。

步驟一：文本分塊（Text Chunking）。與傳統 RAG 類似，GraphRAG 首先將長文件切割為可管理的文本片段。但與固定長度分塊不同，GraphRAG 建議使用較大的 chunk size（例如 1200 tokens），以確保每個片段包含足夠的上下文來識別實體間的關係。分塊策略直接影響下游實體抽取的品質——過小的 chunks 會導致跨句關係被切斷。

步驟二：實體與關係抽取（Entity & Relationship Extraction）。這是 GraphRAG 的核心創新。系統使用 LLM（如 GPT-4 或 Claude）逐一處理每個 chunk，透過精心設計的提示模板（prompt template）指示模型識別文本中的實體（人名、組織、地點、概念、事件等）及其之間的關係。Trajanoska 等人的研究[10]已證明，LLM 在知識圖譜建構任務上的表現可與傳統的監督式抽取模型媲美，甚至在開放領域場景中表現更佳。

步驟三：實體解析與圖合併（Entity Resolution & Graph Merging）。不同 chunks 中抽取的實體可能以不同名稱指向同一個實體（例如「Microsoft」與「微軟」、「MSFT」）。GraphRAG 透過 LLM 驅動的實體解析來合併這些重複實體，建構統一的全域知識圖譜。Ji 等人在知識圖譜綜述中[6]指出，實體解析是圖譜建構中最具挑戰性的環節之一，LLM 的語義理解能力為此提供了新的解法。

步驟四：圖嵌入生成（Graph Embedding）。最終，系統為圖譜中的每個節點和邊生成向量嵌入，使得後續的檢索操作可以同時利用圖結構和向量語義兩種索引。這個雙重索引機制是 GraphRAG 能夠靈活支援不同查詢類型的關鍵。

四、社群偵測與階層摘要

GraphRAG 最具創新性的設計之一，是在知識圖譜上引入社群偵測（Community Detection）與階層摘要（Hierarchical Summarization）。這兩個機制的結合，使得系統能夠回答傳統 RAG 完全無法處理的全域性問題[1]。

社群偵測是圖論中的經典問題：在一張大型圖中，識別出內部連結緊密但彼此之間連結稀疏的子圖（社群）。GraphRAG 採用 Leiden 演算法——一種改進的 Louvain 社群偵測方法——對知識圖譜進行多層級的分群。Leiden 演算法的優勢在於其可以產生階層式的社群結構：Level 0 是最細粒度的社群（少數幾個高度相關的實體），Level 1 是多個 Level 0 社群的聚合，以此類推，形成一棵社群樹。

每個社群被識別後，GraphRAG 使用 LLM 為其生成自然語言社群摘要（Community Summary）。摘要涵蓋該社群中的核心實體、關鍵關係及其語義主題。例如，在一個企業內部文件的知識圖譜中，某個 Level 1 社群的摘要可能是：「此社群涵蓋公司的亞太區營運，主要實體包括台灣子公司、新加坡區域總部與三家代工合作夥伴，核心關係為供應鏈管理與區域合規。」

階層摘要的價值在於預先計算全域知識結構。當使用者提出「這批文件的核心主題是什麼？」這類問題時，系統不需要遍歷所有原始文本——只需查閱頂層社群摘要，即可提供結構化的全局回答。這是一種將「索引時間計算」換取「查詢時間效率」的策略。Edge 等人在論文中報告[1]，在全域性問題上，GraphRAG 的回答完整性（comprehensiveness）和多樣性（diversity）顯著優於基線向量 RAG 系統，而回答延遲則透過社群摘要的預計算得以控制。

Peng 等人的研究[7]進一步證實，當 LLM 能夠存取結構化的外部知識摘要時，其事實準確率和自我修正能力均顯著提升，這為社群摘要作為 LLM 增強手段提供了理論支持。

五、Local Query vs Global Query 機制

GraphRAG 定義了兩種互補的查詢機制——Local Query（局部查詢）和 Global Query（全域查詢）——分別針對不同類型的使用者問題，提供最適切的檢索與生成策略。

Local Query 適用於需要精確事實的具體問題，例如「陳教授在 2024 年發表了哪些關於圖神經網路的論文？」或「A 公司與 B 公司的合作關係始於何時？」。其運作流程如下：首先，系統從查詢中抽取關鍵實體；接著，在知識圖譜中定位這些實體，並沿著其鄰域關係（1-hop 或 2-hop 鄰居）收集相關的實體、關係與原始文本片段；最後，將收集到的結構化知識與原始文本一併作為上下文，送入 LLM 生成回答。Sun 等人在 ICLR 2024 發表的 Think-on-Graph 研究[8]展示了一種類似的策略：讓 LLM 在知識圖譜上進行「圖上推理」（graph-based reasoning），沿著實體關係鏈逐步探索答案。

Global Query 適用於需要全局視角的開放性問題，例如「整個語料庫中涉及最多的法規風險領域有哪些？」或「所有專案報告中的共同失敗模式是什麼？」。其運作流程截然不同：系統不從查詢中抽取實體，而是直接查閱預計算的社群摘要。具體而言，系統將適當層級的社群摘要批次送入 LLM，要求模型根據查詢問題對每個社群生成一個部分回答（partial answer）並附上重要性評分；然後，將所有部分回答依評分排序、合併、去重，最終生成一個涵蓋全局視角的綜合回答。

兩種機制的互補性可以用一個類比來理解：Local Query 類似於在圖書館中查詢特定書籍的特定章節，而 Global Query 類似於請圖書館員對整個館藏做主題分析報告。Edge 等人在消融實驗中發現[1]，Global Query 在處理「sensemaking」類型問題時，其回答的完整性比基線向量 RAG 提升約 50–70%，但在精確事實查詢上，Local Query 的效率和準確度更優。因此，企業部署 GraphRAG 時，應根據業務場景的查詢類型分佈，選擇適當的查詢機制組合，甚至可以建構一個路由層（query router），自動判斷問題類型並分派至對應的查詢管線。

六、GraphRAG vs 傳統 RAG：效能比較

為了量化 GraphRAG 相對於傳統向量 RAG 的優勢與代價，我們從五個維度進行系統性比較，結合 Edge 等人的實驗數據[1]與產業實踐觀察。

評估維度 傳統向量 RAG GraphRAG（Local） GraphRAG（Global）
精確事實查詢 優秀 優秀（略優） 不適用
全域摘要 / 主題分析 差 中等 優秀
多跳推理 差（需多次檢索） 優秀（圖遍歷） 中等
回答完整性 中等 良好 優秀（+50–70%）
索引建構成本 低（嵌入計算） 高（LLM 抽取 + 社群偵測 + 摘要生成）
查詢延遲 低（毫秒級） 中（圖遍歷 + LLM） 中高（多輪 LLM 摘要合併）
LLM Token 消耗 低 中 高（與社群數成正比）

優勢一：全域理解能力。這是 GraphRAG 最顯著的優勢。傳統 RAG 在回答「語料庫中的主要主題」這類問題時，只能回傳與查詢表面語義相近的幾個 chunks，無法提供結構化的全局分析。GraphRAG 的社群摘要機制預先計算了知識的層級結構，使得全域查詢成為可能。

優勢二：多跳推理。知識圖譜的圖結構天然支援關係鏈的遍歷。當回答一個問題需要串聯「A 是 B 的供應商」「B 的工廠位於 C」「C 屬於地震帶 D」三個分散的知識片段時，圖遍歷可以在 O(n) 時間內找到這條路徑，而向量檢索可能需要多次迭代且無法保證路徑完整性[8]。

代價一：索引成本。GraphRAG 的索引建構需要對每個 chunk 呼叫 LLM 進行實體與關係抽取，再進行社群偵測與摘要生成。根據 Microsoft 的文件，對於一個中等規模的語料庫（約 10 萬個 chunks），完整的索引管線可能消耗數百萬 tokens 的 LLM 呼叫，建構時間在數小時至數天之間。這意味著 GraphRAG 更適合知識庫變動頻率較低的場景——例如法規庫、技術手冊、研究論文集——而非實時更新的新聞流或社交媒體數據。

代價二：系統複雜度。傳統 RAG 只需向量資料庫即可運作，而 GraphRAG 需要額外引入圖資料庫、社群偵測演算法、LLM 抽取管線等元件，系統的部署與維運複雜度顯著上升。企業在評估導入 GraphRAG 時，應將這些營運成本納入 TCO（Total Cost of Ownership）計算。

七、圖資料庫選型：Neo4j、ArangoDB 與 Neptune

GraphRAG 系統的核心基礎設施之一是圖資料庫，負責儲存與查詢知識圖譜。當前市場上有三類主流選擇，各自適合不同的企業場景與技術條件。

Neo4j 是最成熟的原生圖資料庫，使用 Cypher 查詢語言，在知識圖譜領域擁有最完整的生態系統。Neo4j 的優勢在於其高度最佳化的圖遍歷效能、豐富的視覺化工具（Neo4j Browser、Bloom），以及與 LLM 框架的深度整合（LangChain 的 Neo4jGraph、LlamaIndex 的 KnowledgeGraphIndex）。根據 Ji 等人的知識圖譜調查[6]，Neo4j 在學術研究與產業應用中均佔有主導地位。對於以知識圖譜為核心的 GraphRAG 系統，Neo4j 是首選。其社群版免費開源，企業版提供叢集部署與進階安全功能。

ArangoDB 是一款多模型資料庫，同時支援文件（JSON）、圖（Graph）與鍵值（Key-Value）三種資料模型。其 AQL（ArangoDB Query Language）統一了三種模型的查詢介面。ArangoDB 的獨特價值在於，企業不需要為圖資料庫和文件資料庫分別部署獨立的系統——一套 ArangoDB 即可同時儲存原始文件 chunks 與知識圖譜。這降低了系統架構的複雜度，特別適合中小型企業或資源有限的團隊。缺點是其圖查詢效能在超大規模圖（數十億邊）上不及 Neo4j。

Amazon Neptune 是 AWS 的全託管圖資料庫服務，支援 Apache TinkerPop Gremlin 和 SPARQL 兩種查詢介面。Neptune 的核心優勢是雲端全託管——無需管理基礎設施、自動備份、跨可用區高可用。對於已深度使用 AWS 生態系統的企業，Neptune 與 SageMaker（ML 訓練）、Bedrock（LLM 推論）、S3（文件儲存）的整合最為順暢。但 Neptune 的成本較高，且缺乏 Neo4j 在知識圖譜生態中的豐富第三方整合。

評估面向 Neo4j ArangoDB Amazon Neptune
資料模型 純圖（Property Graph） 多模型（文件 + 圖 + KV） Property Graph + RDF
查詢語言 Cypher AQL Gremlin / SPARQL
圖遍歷效能 極佳 良好 良好
LLM 框架整合 豐富（LangChain、LlamaIndex） 中等 中等（AWS Bedrock）
部署模式 自建 / 雲端（Aura） 自建 / 雲端（Oasis） AWS 全託管
適合場景 知識圖譜密集型應用 多模型資料需求的中型團隊 深度 AWS 用戶

八、企業級 GraphRAG 系統架構設計

將 GraphRAG 從研究原型推進至企業級生產系統，需要一套完整的架構設計，涵蓋資料管線、查詢引擎、基礎設施三個層面。以下我們基於 Microsoft Research 的開源框架[9]與產業最佳實踐，提出一個可落地的參考架構。

8.1 系統架構總覽

企業級 GraphRAG 系統架構:

┌─────────────────────────────────────────────────────┐
│  使用者介面層（Chat UI / API Gateway）              │
└─────────────────────┬───────────────────────────────┘
                      │
┌─────────────────────▼───────────────────────────────┐
│  查詢路由層（Query Router）                          │
│  ┌──────────────┐  ┌──────────────┐                  │
│  │ Local Query  │  │ Global Query │                  │
│  │ Engine       │  │ Engine       │                  │
│  └──────┬───────┘  └──────┬───────┘                  │
└─────────┼─────────────────┼──────────────────────────┘
          │                 │
┌─────────▼─────────────────▼──────────────────────────┐
│  檢索層                                              │
│  ┌────────────┐  ┌────────────┐  ┌────────────┐      │
│  │ 圖資料庫   │  │ 向量資料庫 │  │ 社群摘要   │      │
│  │ (Neo4j)    │  │ (Milvus)   │  │ 索引       │      │
│  └────────────┘  └────────────┘  └────────────┘      │
└──────────────────────────────────────────────────────┘
          ▲                 ▲              ▲
┌─────────┴─────────────────┴──────────────┴───────────┐
│  索引管線（Indexing Pipeline）                         │
│  文本分塊 → 實體抽取 → 圖合併 → 社群偵測 → 摘要生成  │
└─────────────────────┬────────────────────────────────┘
                      │
┌─────────────────────▼───────────────────────────────┐
│  資料來源（企業文件、知識庫、法規庫、技術手冊）       │
└─────────────────────────────────────────────────────┘

8.2 索引管線的工程考量

索引管線是 GraphRAG 系統中計算成本最高的環節。企業在設計索引管線時，需要關注以下工程面向：

8.3 查詢路由層設計

查詢路由層的職責是判斷使用者問題的類型，並分派至 Local Query 或 Global Query 引擎。一個有效的路由策略是使用 LLM 作為分類器：將使用者查詢送入一個輕量級 LLM，要求其判斷該問題屬於「精確事實查詢」（路由至 Local）還是「全域分析/摘要」（路由至 Global），或者「混合型」（兩者並行，結果融合）。

Pan 等人的研究[2]指出，LLM 與知識圖譜的協同推理在需要多步驟邏輯推演的場景中尤為關鍵。企業可進一步擴展路由層，加入第三種查詢模式——Graph Traversal Query（圖遍歷查詢），專門處理多跳推理問題，沿知識圖譜的關係鏈逐步收集證據。

8.4 分階段落地路線圖

  1. 第一階段 POC（4–6 週）：選擇一個邊界明確的知識庫（如內部技術手冊或法規文件集），使用 Microsoft GraphRAG 開源框架建構端到端原型，驗證圖譜品質與查詢效果。以 Neo4j Community Edition 作為圖資料庫
  2. 第二階段 MVP（2–3 個月）：實作增量索引管線、查詢路由層與基本的品質監控儀表板。整合至企業現有的 chatbot 或知識問答介面
  3. 第三階段 Production（3–6 個月）：導入企業級圖資料庫叢集、LLM 成本最佳化、完善的審計日誌與權限控制。建立領域專家參與圖譜維護的工作流程
  4. 第四階段 Scale（持續）：將 GraphRAG 架構擴展至更多業務領域的知識庫，建構跨領域的統一知識圖譜，探索圖譜驅動的 Agent Workflow 應用

九、結語：知識圖譜與 LLM 的融合趨勢

GraphRAG 的出現，標誌著 RAG 架構從「扁平向量檢索」邁向「結構化知識推理」的典範轉移。這不僅是一次技術升級，更是一種思維模式的轉變——從把知識當作向量空間中的點，到把知識當作一張互相連結的語義網路。

從學術研究的走向來看，LLM 與知識圖譜的融合正在加速。Pan 等人的路線圖[2]勾勒了三條平行發展的技術軌跡：知識圖譜增強 LLM 的推理能力、LLM 自動化知識圖譜的建構與維護、以及兩者在複雜推理任務上的深度協同。Sun 等人的 Think-on-Graph[8]展示了 LLM 如何在知識圖譜上進行「圖上推理」，為未來的 Agent 系統提供了一種可解釋且可審計的推理範式。

然而，我們也必須清醒地認識到 GraphRAG 目前的局限。索引建構的 LLM 成本在大規模語料庫上仍然高昂；自動抽取的圖譜品質尚未達到完全可信的水準；社群摘要在快速變化的知識領域中可能迅速過時。這些問題並非無解，但需要持續的工程最佳化與學術突破。

對於企業技術決策者，我們的建議是：不要等到 GraphRAG 完美才行動，但也不要在不理解其限制的情況下盲目導入。從一個邊界明確的 POC 開始，量化 GraphRAG 在你的特定業務場景中的增益與成本，再決定是否擴大投入。知識圖譜技術的價值是累積性的——圖譜建構得越完善，查詢品質越高，而這需要時間和領域專家的持續投入。

超智諮詢的研究團隊持續追蹤 GraphRAG、知識圖譜與 LLM 整合領域的最新突破，並協助企業客戶設計符合其業務需求的下一代知識架構。從圖譜建構策略到圖資料庫選型，從查詢引擎設計到全系統效能最佳化，我們致力於將最前沿的研究成果轉化為企業可落地的技術方案。