Graph RAG 是什麼？為什麼 2026 爆紅｜LangChain 筆記 Ep-5

本篇重點

Ep-1 到 Ep-4，我們把向量 RAG 從能跑、跑得準、讀得懂圖表，一路做到可以量化評估。這篇要處理它一個再怎麼調參數都解決不了的問題。

先講結論：當答案分散在很多結構雷同的文件裡時，向量 RAG 不是答不出來，是會很有自信地講錯。

這篇先把 Graph RAG 是什麼、為什麼 2026 年突然變成主流、跟前面四篇的 RAG 差在哪講清楚。建圖的實作留到 Ep-6，這裡只會出現一支腳本，用途是重現下面那個失敗實測，讓你自己驗證我不是空口說白話。

一、先看向量 RAG 在哪裡壞掉

概念之前先看實測，不然講什麼都是空的。

語料沿用 Ep-3 那份疾管署《傳染病統計暨監視年報-113年》，但這次不只用麻疹章節，改成取 4 個疾病：麻疹、登革熱、結核病、梅毒。

挑這 4 個的理由很重要：它們的發生率冠軍縣市各不相同。

疾病	每十萬人口發生率冠軍
麻疹	彰化縣 1.05
登革熱	高雄市 6.40
結核病	屏東縣 46.84
梅毒	臺東縣 63.54

這樣才看得出檢索有沒有把疾病跟縣市配對錯。

實測一：它把數字接到錯誤的疾病身上

問一個要跨章節找答案的問題：

問題：臺東縣在哪些疾病的發生率排名第一？
標準答案：梅毒（每十萬人口 63.54 居冠）

[top_k=4] 根據參考資料，臺東縣在以下幾個疾病的發生率排名第一：
          1. 結核病死亡率（每十萬人口3.66）
          2. 登革熱確定病例發生率（每十萬人口63.54）
          3. 結核病發生率（但不是最多，東部較西部高，南部較北部高）

看第 2 點。63.54 這個數字是對的，但它是梅毒的，不是登革熱的。

這比「答不出來」嚴重得多。一個說「我不知道」的系統你會去查證，一個講得頭頭是道還附上正確數字的系統，你會直接相信。

實測二：調大 top_k 讓它從誠實變成瞎掰

換一個問題，跑兩種 top_k：

問題：哪些傳染病的發生率冠軍縣市是高雄市？
標準答案：只有登革熱（每十萬人口 6.40 居冠）

[top_k=4]  不知道

[top_k=12] 根據參考資料，以下幾種傳染病的發生率冠軍縣市都是高雄市：
           1. 登革熱（113 年）
           2. 結核病（113 年）
           3. 麻疹（113 年）

k=4 時它老實說不知道，k=12 時它一次編了三個。結核病的冠軍是屏東縣、麻疹是彰化縣，兩個都錯。

這跟 Ep-4 的發現正好相反。那篇證明了「把 top_k 從 4 調到 9」是救回答案的關鍵。這裡同一個旋鈕往同方向轉，卻讓系統從誠實變成瞎掰。

同一個參數，兩篇的結論相反，而且都有數據。 差別在問題的類型：Ep-4 問的是單一事實（答案在某一段文字裡，撈到就對），這裡問的是跨章節聚合（答案要看過全部才知道）。

為什麼會這樣：chunk 沒有實體邊界

原因不在模型笨，在檢索單位。

向量 RAG 的檢索單位是 chunk，也就是「一段文字」。而這份年報有 18 種疾病，每一章都是同一個模板：

一、疫情描述 → (一)性別 → (二)年齡別 → (三)月份別 → (四)地區別 → (五)境外移入

切成 chunk 之後，「每十萬人口確定病例發生率以臺東縣 63.54 居冠」這段文字，跟其他 17 章的對應段落長得幾乎一模一樣。它們在向量空間裡擠成一團，語意相似度分不出誰是誰。

更關鍵的是：chunk 被撈出來之後，它「屬於哪個疾病」這件事就不見了。 那個資訊在章節標題，不在這段文字裡。LLM 拿到一堆長相雷同、又沒有身分標記的片段，把數字接錯是必然的。

這其實是 Ep-3 那個坑的放大版。那篇發現「圖片轉述看得到畫面裡有什麼，看不到這張圖是誰」，解法是把同頁文字接上去。但當你有 18 個章節、模板又高度重複時，補上下文已經救不回來了。

二、Graph RAG 是什麼

理解了上面的失敗，Graph RAG 的想法就很直觀了：

既然問題出在「檢索單位是一段沒有身分的文字」，那就把檢索單位換成「實體與關係」。

同樣一句「每十萬人口確定病例發生率以臺東縣 63.54 居冠」，向量 RAG 存的是這段字串，Graph RAG 存的是這個結構：

(:Disease {name: "梅毒"})
    -[:INCIDENCE {year: 113, rate: 63.54, rank: 1}]->
(:County {name: "臺東縣"})

差別在哪？這個結構裡，「梅毒」和「臺東縣」是綁死的。 沒有任何方式可以在查詢時把 63.54 接到登革熱身上，因為那條邊根本不存在。

上面那三個把向量 RAG 打敗的問題，在圖上都變成很單純的查詢：

問題	在圖上怎麼做
臺東縣在哪些疾病排名第一	找出所有指向臺東縣、且 `rank=1` 的邊
哪些疾病的冠軍是高雄市	同上，換一個節點
哪些縣市同時是兩種以上疾病的前三名	找 `rank<=3` 的邊，依縣市分組數數量

第三題特別值得注意：那是聚合運算，不是檢索。向量檢索本質上是「找最像的 k 個」，它沒有「數一數」這個能力。top_k 調到多大都沒用。

三、為什麼 2026 年突然爆紅

知識圖譜不是新東西，Google 2012 年就在用了。那為什麼 Graph RAG 是這兩年才紅？

答案不是技術突破，是價格。

時間	發生什麼事
2024/07	Microsoft 開源 GraphRAG，效果驚人
	但建索引一份資料集要燒到 $33,000 的 LLM 費用
2024/11	Microsoft 推出 LazyGraphRAG，把 LLM 呼叫延後到查詢時
	索引成本降到完整 GraphRAG 的 0.1%，跟向量 RAG 同級
2026	成本門檻消失，向量 + 圖的混合架構成為企業主流

為什麼原本那麼貴

Microsoft 那套 GraphRAG 的索引流程是這樣：

把文件切段，用 LLM 抽出每一段的實體與關係
用 Leiden 演算法做社群偵測，把關聯緊密的實體分群
對每一個社群，再用 LLM 生成一份摘要報告
社群是階層式的，所以每一層都要生一次

第 3 步是燒錢的原因，一份大資料集可能分出成千上萬個社群，每個都要跑一次 LLM 生摘要，而且這是建索引時就要全部做完，不管使用者之後會不會問到那個主題。

LazyGraphRAG 改了什麼

它的核心觀念是：先別急著生摘要，等使用者真的問了再說。

索引階段只用便宜的 NLP 技術抽出概念與共現關係，建一個輕量的圖，真正需要 LLM 理解的部分，延後到查詢時針對相關的子圖才做。

代價是查詢變慢一點，換來的是索引成本從 $33,000 掉到跟向量 RAG 同一個級距，這個交換對絕大多數團隊來說非常划算，也是 Graph RAG 從「企業級奢侈品」變成「一般團隊也能考慮」的轉捩點。

四、有兩個東西都叫 Graph RAG

這是最容易搞混的地方，很多教學混為一談，實際上是兩條路線：

路線 A：Microsoft GraphRAG（社群摘要派）

文件 → LLM 抽實體關係 → Leiden 社群偵測 → 每個社群生摘要
                                              ↓
                        查詢 → global search（掃所有社群摘要）
                             → local search（只看相關的小範圍）

global search：回答「這份資料的主要議題是什麼」這種需要通盤理解的抽象問題
local search：回答聚焦在少數實體上的問題

強項是「你不知道要問什麼」的探索型分析，缺點是貴、慢、建好之後資料更新麻煩。

路線 B：Text2Cypher（圖查詢派）

文件 → 抽出結構化事實 → 存進圖資料庫（例如 Neo4j）
                            ↓
       自然語言問題 → LLM 翻譯成 Cypher → 查詢 → 生成回答

把自然語言翻成圖資料庫的查詢語言，讓資料庫去做精確的過濾與聚合。

強項是精確查詢與聚合運算，成本低，缺點是問題必須能翻成明確的查詢，對於「整體趨勢如何」這種模糊問題沒轍。

怎麼選

你的問題長這樣	該用
「這批資料的主要議題有哪些」	路線 A
「哪些疾病的冠軍縣市是高雄市」	路線 B
「X 跟 Y 之間有什麼關聯」	看深度，淺的用 B、需要摘要用 A
「文件裡有沒有提到 X」	都不用，向量 RAG 就夠了

Ep-6 會走路線 B，理由是我們前面那三個問題都是精確聚合型的，Cypher 的排序與計數正好對症；而且路線 A 建索引要燒大量 token，跟這個系列「本地 Ollama 免費跑」的定位衝突。

五、跟前面四篇的 RAG 差在哪

	向量 RAG（Ep-1 到 Ep-4）	Graph RAG
檢索單位	chunk，一段文字	實體與關係
怎麼找	語意相似度取前 k 個	沿著關係邊走、或用圖查詢語言
建索引成本	低，切一切嵌入就好	高，要先把文字讀懂並抽成結構
擅長	「文件裡有沒有講到 X」	「X 跟 Y 什麼關係」「跨文件聚合」
不擅長	答案分散多處、需要數數或取交集	模糊的、沒有明確查詢目標的問題
典型失敗	撈到相似片段後張冠李戴	抽取階段出錯，整條線都錯
資料更新	加一份文件重新嵌入就好	要重新抽實體、可能要重建關係

注意最後兩列 Graph RAG 不是升級版，是用建索引的複雜度換查詢的精確度，抽取階段抽錯了，圖查得再漂亮也是錯的，而且錯得比向量 RAG 更難發現，因為結構化的答案看起來就是很可信。

六、什麼時候不該用 Graph RAG

值得強調的是：Graph RAG 不是拿來取代向量 RAG 的，兩者混用才是務實的作法。以下情況不要為了用而用：

你的問題都是單點查詢：「請假規定是什麼」「這個錯誤怎麼解」，向量 RAG 又快又便宜，建圖是浪費。
文件沒有清楚的實體結構：訪談逐字稿、會議記錄、心得文章，硬抽實體只會抽出一堆雜訊。
資料變動頻繁：圖的維護成本比重新嵌入高很多。
你還沒有評估機制：這點最重要。Ep-4 的教訓是，沒有評估你根本不知道改動有沒有效，只會以為有效。Graph RAG 的變因比向量 RAG 多得多，沒有評估就上，等於在更大的黑箱裡瞎調。

反過來，這篇開頭那種結構雷同、答案分散、需要聚合的語料，正是圖能發揮的地方。

小結

這篇沒有寫程式，但釐清了三件事：

向量 RAG 有個調參數解決不了的限制 chunk 是沒有身分的文字片段，當語料裡有大量結構雷同的章節時，它會把數字接到錯誤的實體上，而且講得很有自信。實測顯示調大 top_k 只會讓它有更多素材去編。
Graph RAG 的核心是換檢索單位 從「一段文字」換成「實體與關係」，讓實體之間的綁定關係變成結構的一部分，而不是靠語意相似度去猜。
它會紅是因為變便宜了 2024 年 Microsoft 開源時索引一份資料要 $33,000，LazyGraphRAG 把 LLM 呼叫延後到查詢時，成本降到只剩 0.1%，才讓一般團隊有機會用。

下一篇 Ep-6 進實作：用 regex 加 LLM 混合抽取把 18 個疾病章節變成知識圖譜、存進 Neo4j、讓本地模型生 Cypher 查詢，最後用 Ep-4 的評估框架驗證它到底有沒有比向量 RAG 好。

先預告一個實作時踩到的坑：本地模型在沒有範例的情況下，生出來的 Cypher 是 0/4 可用，錯到用了 Cypher 根本不存在的 SQL 語法。細節下一篇講。

系列導覽

Ep-0：LLM、LangChain、AI Agent 與 MCP 是什麼：概念打底
Ep-1：RAG 入門，把八個步驟串成可跑的程式：基本架構
Ep-2：進階檢索，混合檢索與 Reranking：提升準確度
Ep-3：多模態 RAG，讓 LLM 讀懂含圖表 PDF：處理圖片
Ep-4：用 RAGAS 驗證指標可不可信：量化評估
Ep-5（本篇）：Graph RAG 概念
Ep-6（撰寫中）：Neo4j 知識圖譜實作，動手建圖