昨天算過一筆帳:代理式檢索每一跳 85% 正確率,三跳串起來端到端只剩約 61%。誤差會被連乘,而連乘的根源是「關係」這件事一直到查詢當下才被臨時拼湊出來。GraphRAG 走的是另一條路——把文件裡的實體與關係在建索引時就抽出來、結構化成一張圖,查詢時走的是已經算好的邊,而不是讓模型一跳一跳猜。代價也很直接:建圖那一刀砍下去,成本與維護負擔完全是另一個量級。今天要把這條路的流程、兩種查法、真實花費,以及什麼情況下不該碰,一次講清楚。
📖 學
先定義清楚 GraphRAG 在解什麼題。傳統向量 RAG 的世界觀是「文件是一堆彼此無關的切片」,檢索就是找出跟問題最像的幾片。這個假設在「某條規定寫在哪裡」這種問題上完全夠用,但碰到「這三年來有哪些供應商同時牽涉到 A 專案和 B 事件」就徹底失效——答案不在任何單一切片裡,而分散在幾十份文件中,必須先把散落的提及串成同一個實體,再沿著關係彙整。GraphRAG 的做法是把非結構化文字轉成「實體節點 + 關係邊」的圖,讓這種跨文件彙整變成圖上的鄰居查詢,而不是碰運氣的相似度比對。
建圖流程大致是四步,每一步都吃 LLM。第一步實體抽取:把每個切片丟給模型,要它輸出「這段裡有哪些人、組織、產品、事件」,並附上一句描述。第二步關係抽取:同一次呼叫通常會順便要模型輸出「實體 A 與實體 B 之間是什麼關係、強度多少」。第三步是最容易被低估的實體解析與摘要——同一個實體會在幾十個切片被提及幾十次,系統要把「台積電」「TSMC」「台灣積體電路製造」判定為同一個節點,再用 LLM 把它的幾十段描述壓縮成一段權威描述,關係邊同理。第四步社群偵測:用 Leiden 之類的圖分群演算法把節點切成階層式社群(C0、C1、C2、C3 由粗到細),然後對每一個社群、每一層,各自跑一次 LLM 生成社群摘要。注意第三步和第四步的呼叫次數不是跟文件量線性相關,而是跟「實體數 × 提及次數」與「社群數 × 層數」相關,這就是帳單失控的來源。
有了這張圖,查詢分成兩種完全不同的走法。Local search 處理「特定實體」的問題:先用向量找到最相關的幾個實體節點,再往外撈它的鄰居、關係邊、以及這些節點對應的原始切片,組成 context 交給模型。Global search 處理「整份資料集的主題」問題:它不做相似度比對,而是把所有(某一層的)社群摘要分批丟給模型,每批各生成一段部分答案並自評相關度,最後再把這些部分答案 reduce 成最終回答。這是一種廣度優先的掃描,所以它答得出「這批文件的主要議題是什麼」,但也因此每問一次就要掃過大量社群摘要。
| 向量 RAG | GraphRAG local | GraphRAG global | |
|---|---|---|---|
| 適合的問題 | 誰、什麼、何時、何地 | 某實體的關聯脈絡、兩跳關係 | 整體主題、跨文件彙整 |
| 檢索單位 | 文字切片 | 實體、關係邊 + 原始切片 | 社群摘要(批次掃過) |
| 查詢成本 | 最低 | 中 | 高(隨社群數成長) |
| 失效情況 | 答案分散在多份文件 | 需要全域視角 | 問題其實只指向單一段落 |
成本的實際量級,微軟自己的數字最有說服力。Microsoft Research 在 LazyGraphRAG 那篇部落格裡直接寫明:LazyGraphRAG 的建索引成本與純向量 RAG 相同,也就是完整 GraphRAG 的 0.1%;在答案品質與 GraphRAG global search 相當的前提下,查詢成本低 700 倍以上。換句話說,完整 GraphRAG 的索引開銷,是向量 RAG 的一千倍。它們的實驗設定是 5,590 篇 AP 新聞、100 題合成查詢(50 題 local、50 題 global),以 Comprehensiveness、Diversity、Empowerment 三個指標讓 LLM 兩兩對決評分。結果是:LazyGraphRAG 只花 GraphRAG C2 層 global search 查詢成本的 4%,就在 local 與 global 兩類問題上都顯著勝過所有對照組,包括吃 64K context 的長視窗向量 RAG。
LazyGraphRAG 的省法值得拆開看,因為它揭示了成本到底花在哪。它把建索引時的 LLM 呼叫幾乎全部拿掉——用 NLP 名詞片語抽取取代 LLM 實體抽取,只做概念與共現關係,再用圖統計跑社群結構,完全不生成社群摘要;所有 LLM 使用延後到查詢時才發生:先讓模型把問題拆成 3 到 5 個子查詢,用切片嵌入排序社群,再用一個廉價模型逐句評估相關度,並在相關社群裡遞迴深入。這條設計說明了一件事:GraphRAG 的貴,九成貴在「預先用 LLM 摘要每一個實體、每一條關係、每一層社群」,而不是貴在圖本身。
維護代價比建置成本更難處理,而且很少人一開始就算進去。文件更新時,新切片抽出的實體可能與既有節點衝突,關係邊的權重要重算,更麻煩的是社群結構會漂移——加進一批新文件後,Leiden 分群結果可能整個重排,那所有社群摘要就得重生成一次。這也是 LightRAG 這類方案主打的痛點:它把實體與關係描述本身做成向量,檢索時用相似度查而不是全圖走訪,並設計了增量更新演算法,讓新資料能併進去而不必重建整張圖。實務上還有一個沒人愛做的髒活是實體解析:同名不同人、同人不同名、縮寫與全稱,一旦解析錯了,圖上就會多出一條假邊,而假邊產生的錯誤答案比檢索不到更難察覺,因為它看起來言之鑿鑿。
那什麼時候不該用 GraphRAG?幾條明確的線。第一,你的問題九成是單一事實查找(「請假規定是幾天」),那圖只是昂貴的裝飾,rerank 和 hybrid search 就夠了。第二,你的語料本身已經是結構化的(資料庫、表格、工單系統),那應該直接寫 SQL 或用 text-to-query,不必先把結構拆成文字再用 LLM 抽回結構——這是繞一大圈自找麻煩。第三,語料更新頻繁(每天進新文件),重建圖的成本會持續咬人,除非你選的是支援增量更新的實作。第四,語料量太小,幾百份文件塞得進長 context,直接餵給模型比建圖划算。第五,你沒有能持續維護 schema 與實體解析規則的人——GraphRAG 不是一次性專案,它是一個需要有人養的系統。
最後是最常見的兩個誤解。誤解一是「GraphRAG 全面優於向量 RAG」:微軟自己在同一篇文章裡明講,vector RAG 在 local query 上表現優異,因為答案跟問題長得像、就落在特定文字區域;GraphRAG 的優勢區間是 global query,兩者是互補而非取代關係。誤解二是「上了 GraphRAG 就要拋棄向量檢索」:事實上主流實作都是混合的,local search 本身就靠向量找入口節點,LazyGraphRAG 更是用切片嵌入來排序社群。務實的路徑是分層落地:先用一週把真實流量的問題分類,量出「需要跨文件彙整」的比例;如果不到 15%,就別動,把力氣留給 rerank;如果超過三成,先從輕量方案(LightRAG、LazyGraphRAG)起步,量到明確增益之後,再考慮是否值得付完整 GraphRAG 的索引與維護費用。
🧠 記
- GraphRAG 的核心轉換:把「關係」從查詢時臨時推理,移到建索引時預先結構化,用來避開多跳檢索的誤差連乘。
- 建圖四步:實體抽取 → 關係抽取 → 實體解析與描述摘要 → 社群偵測(Leiden)+ 社群摘要。後兩步是成本爆炸點。
- Local search 靠向量找實體入口再往外擴,答特定實體題;global search 批次掃社群摘要做 map-reduce,答全域主題題。
- 微軟實測數字:LazyGraphRAG 索引成本僅完整 GraphRAG 的 0.1%,同品質下 global 查詢成本低 700 倍以上;用 C2 global search 4% 的查詢成本即全面勝出。
- 貴的不是圖,是「用 LLM 預先摘要每個實體、每條關係、每層社群」。拿掉這步,成本就回到向量 RAG 等級。
- 維護代價:社群結構會隨新文件漂移導致摘要重生成;實體解析錯誤會製造假邊,而假邊的錯誤答案最難察覺。
- 五個不該用的情境:問題以單一事實查找為主、語料本身已結構化、更新極頻繁、語料小到塞得進 context、沒人能長期維護。
✍️ 實踐
今天不建圖,先做一份「值不值得建圖」的證據。步驟:第一,從真實或模擬流量抽 40 題,逐題標記兩個標籤——「答案是否落在單一文件內」以及「是否需要跨三份以上文件彙整」。第二,把需要跨文件彙整的那幾題,拿去餵你現有的 hybrid + rerank 管線,人工判定答對與否,算出這一類問題的正確率。第三,把同樣幾題手動整理成「實體—關係」清單(例如「供應商 X —供應— 專案 A」),看看這些關係是否真的能從你的文件裡穩定抽出來;抽不出來的,GraphRAG 也救不了。自我檢查有三個數字:跨文件題佔比、現有管線在這類題上的正確率、以及可穩定抽出的關係比例。三個數字分別低於 15%、高於 80%、低於 50% 的任何一項成立,今天的結論就是「先別建圖」——這個結論同樣值得寫下來,它省下的可能是幾萬塊的索引帳單。
🔗 延伸學習
- LazyGraphRAG: Setting a new standard for quality and cost（Microsoft Research） — 成本數字與 GraphRAG／LazyGraphRAG 建索引流程的逐步對照表都在這篇,今天引用的數據來源。
- From Local to Global: A Graph RAG Approach to Query-Focused Summarization（arXiv 2404.16130） — GraphRAG 的原始論文,社群偵測與 map-reduce global search 的設計出處。
- LightRAG: Simple and Fast Retrieval-Augmented Generation（arXiv 2410.05779） — 雙層檢索與增量更新演算法,適合看「輕量圖檢索」怎麼設計。
- microsoft/graphrag（GitHub） — 官方實作,想動手跑 local／global search 從這裡開始。
💬 問 AI
我有一批文件語料,想評估是否值得從 hybrid RAG 升級到 GraphRAG。
我的情境:
- 語料類型:（例如內部技術文件／客服工單／合約）
- 文件數量與更新頻率:（例如 3000 份、每週新增 50 份）
- 目前管線:hybrid search（BM25 + 向量）+ rerank + 單次生成
請幫我:
1. 設計一份「問題分類表」,讓我把 40 題真實流量分成三類:
單一事實查找／單文件內多段推理／需跨多份文件彙整,
每類給 2 個判斷準則與 1 個範例,避免我分類時搖擺。
2. 根據我的更新頻率,估算完整 GraphRAG（LLM 實體抽取 + 社群摘要）
與輕量方案（LightRAG／LazyGraphRAG）的建置與維護成本差異,
把「社群結構漂移導致摘要重生成」這項單獨列出來。
3. 給我一個明確的 go／no-go 判斷規則:
跨文件題佔比、現有管線在該類題的正確率、關係可抽取比例
這三個數字要落在什麼範圍,才值得建圖。