Graph RAG 是微軟在論文《From Local to Global: A Graph RAG Approach to Query-Focused Summarization》（https://arxiv.org/abs/2404.16130）提出的新方法，透過建立基於圖形的文本索引，提升 LLM 對「全局性問題」（需要理解整個語料庫才能回答的問題）的回答品質。它能有效處理大規模文本語料庫，並且可隨著源文本數量與問題的普遍性擴展。本文整理我對這篇論文的筆記：Graph RAG 的完整工作流程、兩大階段的處理細節，以及和傳統 RAG 的實測比較。
什麼是 Graph RAG？為什麼傳統 RAG 不夠用？
RAG 的目的是提升 LLM 在回答問題時的準確度和廣度：先從外部數據來源檢索資料，再將這些資料與問題一起放入 LLM 的上下文中，讓模型更有針對性地回答。
但傳統 RAG 面對「整個資料集在講什麼」這類全局性問題時表現不佳，因為它只會檢索少數幾個最相關的片段。Graph RAG 的做法不同：
- Graph RAG 管道利用 LLM 衍生的文本圖索引進行資料處理。首先從來源文件構建出實體知識圖，將文件中的實體與其關聯關係組織成網狀結構。
- 在索引建立階段使用 LLM 進行「群體預摘要」，針對每個相似的實體群體生成摘要，以便更快速地調用相關資訊。
- 查詢進來時，直接使用這些預摘要快速生成「全局答案」，不僅提升答案的全面性和多樣性，還能有效降低生成回答時的 token 成本。
Graph RAG 系統的工作流程是什麼？
- Graph RAG 系統先生成知識圖譜，將文本中的實體和關係組織成「社區」的層次結構（例如將相關人物和概念歸為同一群），讓每個「社區」包含特定主題的內容，便於更精準地檢索和總結資料。
- 當用戶提出問題時，系統從不同層次的社區中選擇最合適的摘要來生成答案，這些答案以多階段的方式組合，確保包含關鍵且更全面的回應。
和一般 RAG 不同，Graph RAG 使用「圖形索引」來組織和檢索資料，能更好地處理大型資料集，並在回答問題時提供更豐富、全面的答案。透過圖形索引，Graph RAG 達到更高效的資料組織和檢索效果，在處理多樣性問題上表現更佳——對於需要長期反覆查詢的資料集特別有價值，因為索引成本相對較低，但效果很好。
第一步驟：如何預處理參考資料？
Text Chunks → Element Instances
從文本中識別 Chunks 和提取實體（例如人、地點、組織）及其之間的關係（Instances），以構建結構化的圖形表示。
- 實體識別與關係提取
- 每段源文本被分割為更小的片段。在每個片段中，系統要識別出「節點」和「邊」兩種元素，分別代表「實體」和「實體之間的關係」。
- 系統利用 LLM 的多部分提示來達到這個目的：首先識別出所有實體，包括它們的名稱、類型（如人名、地點、組織等）和描述；接著識別出實體之間的明確關係，並提供詳細的關係描述。
- 自訂與特定領域優化
- 對於特定領域（如醫學或法律），可以加入專門的少量示例（few-shot examples），使 LLM 更好地理解並識別該領域的專業實體。例如醫學領域可能包含藥品、疾病、治療方法等特定實體，透過少量專門示例，LLM 能更精確地從特定領域文本中提取相關資訊。
- 若希望從節點中提取更多資訊（例如日期、描述或其他相關變數），可以使用次要的提示來實現。這些額外資訊（或「協變量」）能為實體提供更多上下文，例如該實體是什麼主題、對象、來源範圍、開始和結束日期等。
- 多輪收集過程
- 為了達到更高的準確性和完整性，系統使用多輪「收集」方法。LLM 先對提取結果進行初步檢查，並以「是/否」的強制決策過程判斷是否所有實體都已完全提取；若確認存在遺漏，則再進行一輪收集。
- 系統會引導 LLM 進一步搜尋缺失的實體，甚至明確提示「在上次提取中錯過了許多實體」，確保模型在後續階段彌補缺失。
- 這種多輪收集方法的優點是：可以使用較大的文本片段（塊）提高處理效率，同時不影響提取品質或引入額外噪音。
Element Instances → Element Summaries
如何將提取的實體、關係和主張進一步轉換為更精簡且有意義的摘要，以構建支持查詢的圖形索引：
- 從實例（Instances）到摘要（Summaries）的轉換
- 使用 LLM 來「提取」來源文本中的實體、關係和主張，其實就是一種抽象總結。LLM 不僅要理解文本中明確表述的資訊，還要將隱含資訊（例如隱含的實體關係）轉換為獨立且有意義的摘要。
- 為了讓每個圖形元素（實體節點、關係邊、主張的附加資訊）更具體明確，需要進行額外一輪的 LLM 總結，將實例級別的資訊整合為單一的描述性文本塊，方便查詢時直接使用。
- 實體引用一致性的挑戰
- 一個潛在問題是，LLM 可能以不同的格式或名稱引用相同的實體，導致相同實體被多次提取，形成重複的節點。
- 為克服這個問題，方法設計上會在後續步驟中偵測並彙整所有相關「社群」實體。LLM 能辨識出多個名稱變體背後的同一實體——只要這些變體有足夠的連結性，即便名稱不同，系統仍能將它們歸為同一實體群體，降低重複節點的影響。
- 與典型知識圖的區別
- 傳統知識圖依賴簡潔的三元組（主體、謂語、賓語）進行推理，但這可能過於簡化，無法包含較複雜或隱含的資訊。
- 相較之下，這種基於 LLM 的方法能在圖形節點中保留豐富的描述性文字，更符合全球查詢導向的摘要需求，也更能利用 LLM 處理多變而含糊資訊的能力，使索引更具韌性，能適應可能包含噪音的圖結構。
Element Summaries → Graph Communities
將之前建立的圖形索引進一步分割成「社群」或「群組」，以便更有效地進行資訊總結：
- 圖形模型的建立
- 前一步已建立一個索引，可表示為「同質無向加權圖」：實體節點透過關係邊相互連接，每條邊的權重反映該關係實例的標準化計數（即該關係被檢測到的頻率）。
- 圖中兩個節點之間的關聯越強，邊的權重就越高，能反映這些實體之間的連結強度。
- 社群檢測的意義
- 透過「社群檢測」算法，將圖劃分為不同的社群。社群中節點之間的關聯性，比它們與其他社群節點的關聯更強，因此每個社群代表彼此關聯較緊密的一組實體。
- 社群劃分讓我們可以根據不同主題、概念或上下文，將實體分成幾個更具內部一致性的子圖，便於之後的資訊總結。（論文中使用 Leiden 算法來調整社群間的層次性結構。）
Graph Communities → Community Summaries
透過社群劃分，可以採用「分而治之」的方法進行全球性資訊總結：將整體圖分為多個社群後，針對每個社群進行摘要，再匯總出完整的回答。
社群摘要的目標與用途：
- 這些報告式摘要讓用戶能在無特定查詢的情況下，直接從整體視角快速了解資料集的結構與語義。例如先在高層級瀏覽不同社群的摘要以尋找感興趣的主題，再逐層深入至提供更多細節的低層級報告。這些摘要也可作為支持回答全局查詢的資料索引。
社群摘要的生成方法：
- 葉級社群（最小社群）：先處理最基礎、最小的社群單位。對這些社群中的元素（節點、邊、協變量），系統依據「顯著性」排序，並將摘要按順序加入 LLM 的上下文窗口，直到達到 token 上限。排序方式是根據邊的來源和目標節點的度數（度數總和越高，代表該連結越重要），因此越顯著的邊，其相關描述（來源節點、目標節點、連結的協變量和邊本身的描述）會優先被加入摘要。
- 高層級社群：對包含多個葉級社群的高層級社群，若其元素摘要總數沒有超過上下文窗口的 token 限制，就按照葉級社群的方式生成摘要；若超過限制，則優先處理並排名較短的子社群摘要，將較長的元素摘要替換成子社群的簡短摘要，直到所有內容符合上下文窗口限制。這樣的替換策略確保在盡可能保留資訊的同時符合 token 限制，達到最佳化的摘要效果。
報告式摘要的價值：
- 這種層次化、逐步濃縮的社群摘要方式，讓用戶可以「分層瀏覽」逐層深入，從全局到細節快速了解資料結構。
- 在資料量極大的情況下，這些摘要有助於維持資訊的完整性與重點，並能快速查詢與定位。
第二步驟：如何根據使用者提問生成最終答案？
收到查詢後，系統利用之前生成的社群摘要來產生最終答案，過程分為三步（Community Summaries → Community Answers → Global Answer）：
- 準備社群摘要：將所有社群摘要隨機打亂，再分成大小合適的小塊，確保資訊平均分佈，不會因集中於單一區塊而造成資訊缺失。
- 生成中間答案：從每一小塊生成「中間答案」，並為每個答案打分（0-100），分數越高表示對回答用戶問題越有幫助。分數為 0 的答案會被過濾掉。
- 匯總成最終答案：將中間答案按分數從高到低排列，逐一加入最終答案的文本中，直到達到內容限制，組合出一個完整且最具幫助的「全球答案」。
這樣的流程確保系統在回答問題時，不僅能全面涵蓋內容，還能提供最相關的資訊。
如何測試 LLM 的全局理解能力？
為了評估 RAG 系統能否有效「理解」大型數據集，需要設計特殊的問題，測試它是否具備全局性的理解能力，而不只是找出某些具體事實：
- 為什麼要特別的問題：一般的問答數據集（例如 HotPotQA）都是直接查找具體答案，像是「誰是某事件的參與者」。這種方法不足以測試 RAG 系統能否「理解」數據集的整體內容或背景意涵。
- 如何生成這些問題：先給 LLM 簡單描述數據集的內容，讓它想像數據集的「潛在用戶」有哪些、這些用戶會有什麼需求或任務；接著讓 LLM 為每個「用戶＋任務」組合生成一組問題——這些問題需要理解整個數據集才能回答，而不是只針對其中一部分內容。
- 最後的測試問題：設置 N=5，即生成 125 個問題，用來測試 RAG 系統的整體理解和處理能力，評估系統是否能把握數據集的整體結構和意義。
以「科技記者」為例：
- 用戶設定：這位用戶是一位科技記者，關注科技產業趨勢，特別是科技領袖如何看待「政策和法規」的影響。
- 任務描述：從眾多 Podcast 文字稿中找出科技領袖們對政策、法規的觀點——需要的是整體理解，而非回答單一事實性問題。
- 問題設計：基於這個任務設計 5 個高層次問題，都需要整體視角的資訊才能回答：
| 問題 | 考察能力 |
|---|---|
| 哪些集數主要涉及科技政策和政府監管？ | 掃描所有集數，找出相關內容並給出範圍性回應 |
| 客人如何看待隱私法對科技發展的影響？ | 從各集數提取與隱私法影響相關的觀點和分析 |
| 有任何嘉賓討論創新與倫理考量之間的平衡嗎？ | 辨識並統整與創新、倫理相關的討論 |
| 客人提到的對現行政策的建議變更是什麼？ | 整理嘉賓們的政策改進建議，具體又概括 |
| 是否討論科技公司與政府之間的合作，以及如何進行？ | 找出嘉賓提到的合作模式及其描述 |
Graph RAG 和 Native RAG 的比較結果如何？
以「哪些公共人物在各種娛樂文章中被反覆提及？」這個全局性問題為例：
| 方法 | 回答表現 |
|---|---|
| Graph RAG | 給出「娛樂界知名公眾人物概述」：先總結娛樂產業的廣度（電影、電視、音樂、體育、數位媒體），再分類列出演員和導演、爭議中的公眾人物、音樂家和高管、運動員和教練、網紅和企業家等群體，並說明這些人物在文化敘事、產業趨勢和公共話語中的影響力。 |
| Native RAG | 直接列出泰勒·斯威夫特、特拉維斯·凱爾西、布蘭妮·斯皮爾斯、賈斯汀·汀布萊克等具體人物，再逐一簡述其受關注的原因與影響。 |
結論：在回答的全面性、多樣性、準確性上 Graph RAG 都勝出，而簡潔性和具體性則由原本的 RAG 勝出。依問題性質選擇方法即可：要全局趨勢洞察用 Graph RAG，要具體事實查詢用傳統 RAG。
延伸閱讀
- Graph RAG：圖形式的檢索增強生成，讓 LLM 回答全局性問題：同樣聚焦 Graph RAG、RAG，可接著比較不同情境的做法。
- 檢索增強生成（RAG）與 RETA-LLM 框架完整解析：同樣聚焦 RAG、LLM，可接著比較不同情境的做法。
- 檢索增強生成（RAG）如何讓 LLM 回答更準確：同樣聚焦 RAG、檢索增強生成，可接著比較不同情境的做法。
常見問題
Graph RAG 和傳統 RAG 有什麼差別？
傳統 RAG 直接從向量索引檢索最相關的文本片段，適合具體事實型問題；Graph RAG 則先用 LLM 從文本建立實體知識圖，透過社群檢測分群並預先產生階層式社群摘要，查詢時匯總各社群的中間答案。這讓 Graph RAG 能回答需要理解整個語料庫的全局性問題。
Graph RAG 的索引建立成本高嗎？
索引階段需要多次呼叫 LLM 進行實體抽取、摘要和社群報告生成，建置成本確實比傳統向量索引高。但索引建立一次後可反覆查詢，且查詢時靠預先產生的社群摘要生成答案，反而能降低每次回答的 token 成本，適合需要長期反覆查詢的資料集。
Graph RAG 使用什麼演算法做社群檢測？
論文使用 Leiden 算法。它先將實體關係構建成同質無向加權圖（邊的權重為關係出現頻率），再以 Leiden 算法劃分出層次性的社群結構，讓每個社群包含主題相近、關聯緊密的實體，供後續分層摘要使用。
什麼情況該用 Graph RAG？
當你的問題偏向全局性、主題總結型——例如「這批文件的主要趨勢是什麼」「資料集中反覆出現哪些主題」——Graph RAG 的全面性和多樣性明顯優於傳統 RAG。若需求是精準的事實查詢（找特定片段、具體答案），傳統 RAG 反而更簡潔、更便宜。
Graph RAG 如何處理同一實體的不同名稱？
LLM 抽取實體時可能以不同格式或名稱引用同一實體，造成重複節點。Graph RAG 不在抽取階段強行合併，而是靠後續社群檢測：只要名稱變體之間有足夠連結性，系統就會將它們歸入同一實體群體，降低重複節點的影響。
參考資料
最後更新
2026-08-28（原文發布於 2024-11-11，本文保留原始筆記內容並補上 GEO 結構。）
關於作者 {#author}
Claire Chang ｜ 企業 AI 導入與流程轉型顧問。專注於 AI Agent 架構設計、ERP 系統整合與企業 AI 治理。
首次發布：2024-11-11