GraphRAG 指南：知識圖譜何時勝過向量 RAG（何時不行）

GraphRAG 指南：知識圖譜何時勝過向量 RAG（何時不行）

GraphRAG 沒有死，但也不是預設選項。microsoft/graphrag 在 2026-07-18 發布 v3.1.1，GitHub 星數達到 35,088，而三篇 2026 年的基準測試論文如今公開承認：它經常輸給單純的向量檢索。所以這篇 GraphRAG 指南只回答一個剩下的問題：知識圖譜值得那筆索引帳單嗎？

該不該用 GraphRAG？短答案

當你的問題會跨越實體、或橫跨整個語料庫時，用 GraphRAG，例如「我們最大的客戶同時也是哪些供應商？」。單跳事實查詢、文件更新頻繁、延遲預算吃緊的場景，留在原生 RAG 或混合 RAG 就好。圖譜只有在多跳問題上才回得了本，其他場景都是多花錢。

GraphRAG 沒有死，也不是預設選項。當問題屬於多跳或橫跨整個語料庫時，它賺得回索引帳單；不是的時候，它就是在燒錢。

精簡版：

• GraphRAG 贏在多跳與跨語料庫問題；原生 RAG 贏在單跳查詢。
• 2026 年的基準測試結果褒貶不一：圖譜有助於聚合，卻可能傷害細粒度摘要。
• 成本落在索引階段，來自 LLM 擷取呼叫，而不是查詢階段。
• 在動手蓋任何東西之前，先在自己的語料庫上把 Basic Search 當對照組跑一遍。

如果你已經有一套可用的向量 RAG 管線，唯一要決定的就是上面那層圖譜值不值得養。下面這張表用六列講完了整個論證；凡是寫「留在原生 RAG」的地方，都是誠實的答案，比供應商願意承認的還常見。BM25 加向量的混合檢索在完全不用圖譜的情況下，就能覆蓋這些場景的大部分。

GraphRAG 到底是什麼：從切片到社群

GraphRAG 是在知識圖譜上、而不是在互不相連的切片上做檢索增強生成。索引階段，LLM 從你的文件裡擷取實體與關係，Leiden 演算法把這些實體分群成社群，每個社群再產生一份摘要。查詢階段，圖譜加上這些摘要，能回答 top_k 切片窗口在結構上就答不出來的問題。

管線從頭到尾：

Documents
  |
  v
Chunks --> LLM entity + relationship extraction
  |
  v
Knowledge graph (entities = nodes, relations = edges)
  |
  v
Leiden community detection --> community summaries
  |
  v
Vector index over entity + community descriptions

兩個階段各司其職。索引階段是花錢的那個：每個切片都要一次 LLM 呼叫來抽出實體與關係，社群摘要又在其上疊加更多呼叫。查詢階段才是回報出現的地方。因為圖譜明確儲存了關係，「我們最大的客戶同時也是哪些供應商？」這類問題變成一次走訪，而不是祈禱正確的兩個切片剛好落進同一個 top_k 窗口。

摘要之所以重要，是因為 Global Search 實際讀的就是它們：跨語料庫的問題由預先寫好的社群文章來回答，而不是原始切片。而每一條邊都是 LLM 的一次判斷，存成三元組，你甚至能在真正的圖譜資料庫裡用 Cypher 查詢。這個設計也是索引主導成本的原因，下面的數字會讓這件事具體起來。

一個站得住腳的框架：原生 RAG 檢索的是段落，GraphRAG 檢索的是結構。你選的嵌入模型對向量層仍然重要，你的向量資料庫仍然儲存描述，但圖譜才是新的承重結構。官方Index Overview 文件完整說明了每個階段。

GraphRAG 的四種查詢方法是什麼？

GraphRAG 查詢引擎內建四種方法：Local Search、Global Search、DRIFT Search 與 Basic Search。Local Search 從特定實體向外推理，Global Search 聚合整個語料庫的社群摘要，DRIFT Search 以遞迴方式混合兩者，Basic Search 則是單純的向量基準。第五個功能 Question Generation 位於引擎之上，而不是與其他四者並列。

我們在 2026-07-30 查了 microsoft.github.io/graphrag/query/overview/ 的線上文件，數字是四種。多數排名型指南只列出兩種或三種。同一輪檢查也發現，Index 與 Query 兩個 overview 頁面上「lazy」這個詞出現了零次，這對下面的成本章節很重要。

最值得你注意的就是最後一列。Basic Search 是內建的原生向量基準，它的存在就是讓你在自己的語料庫上，用圖譜跟單純檢索做 A/B 測試，搞清楚圖譜有沒有賺回它的帳單。這不是冷知識；它就是本指南整套決策程序濃縮成的一個功能。先跑 Basic Search。如果 Local、Global 或 DRIFT search 在你真正會被問到的問題上贏不過它，圖譜就是成本，不是升級。

2026 年的基準測試到底發現了什麼？

三篇 2026 年的基準測試論文發現，GraphRAG 在多跳與多事實聚合任務上有幫助，但在其他場景經常輸給原生 RAG。其中一篇甚至專門建了一個基準來找出圖譜輸在哪裡。三篇都同意：輸贏取決於問題類型，而不是語料庫規模。證據顯示 GraphRAG 是情境型工具，不是預設選項。

第四項工作 GraphRAG-Bench（儲存庫）跨 16 個學科、20 本教科書評估了九種 GraphRAG 方法，從更廣的角度得到同樣的結論。

三篇論文在一點上交會：圖譜在多跳聚合上賺回成本，在細粒度召回上賠掉成本。

我們的解讀：傷害是炒作週期造成的，這些論文是修正。沒有一篇說圖譜毫無用處。它們一致說的是：讓 GraphRAG 擅長跨語料庫主題的那個聚合步驟，正是模糊掉細粒度細節的同一個步驟。WildGraphBench 是最清楚的例子：圖譜幫助了從中等數量來源做的多事實聚合，卻在同一份評估中傷害了摘要的精確度。這不是矛盾；是同一個機制出現了兩次。

實務上的後果是：你無法只靠文獻做出這個決定。論文告訴你該測試哪些問題類型，而不是你的語料庫是不是其中之一。這正是上面方法章節那個 Basic Search 對照組的用途。

GraphRAG 要花多少錢？（以及人人都講錯的 LazyGraphRAG 注意事項）

GraphRAG 的成本是索引階段的帳單，不是查詢階段的，這正是它讓人意外的原因。從每個切片擷取實體與關係的 LLM 呼叫，加上社群摘要那一輪，才是它昂貴的原因。你在任何查詢執行之前就先付了錢。查詢階段比較便宜，但不是免費：Global Search 會對社群摘要扇出，每個社群一次 LLM 呼叫，所以上面的方法表把它標成「高」。

唯一公開的硬數據來自 Microsoft Research。2024-11-25，該團隊回報 LazyGraphRAG 的索引成本與向量 RAG 相同，且只有完整 GraphRAG 成本的 0.1%；在查詢成本方面，它以 GraphRAG global search 4% 的查詢成本，在本地與全域兩種查詢類型上都優於受測的競爭方法（Microsoft Research）。這些是 Microsoft 的數字，出自 Microsoft 的部落格，我們如實轉述；我們自己沒有跑過計價的索引。

以下是多數文章漏掉的更正。LazyGraphRAG 不是一個 pip install 選項。根據 Microsoft 自己在 2025-06-06 的編輯註記，它發布在 Microsoft Discovery 與 Azure Local，而不是開源套件。我們在 2026-07-30 查了官方 Index Overview 與 Query Overview 頁面：兩個頁面上「lazy」這個詞都出現了零次。所以如果某篇指南把 LazyGraphRAG 列成你今天下午就能啟動的變體，它是在重複一個在開源世界裡早已不成立的說法。

你今天能做的：在本機執行擷取模型。透過 Ollama 把索引步驟指向本機模型，能從最貴的階段移除按 token 計費的 API 費用；再搭配自建向量儲存，就能讓帳單的其餘部分逼近零。

哪個 GraphRAG 函式庫真的有人在維護？

被引用最多的六個 GraphRAG 函式庫裡，有兩個分別已經六個月、九個月沒有 push。我們在 2026-07-30 從 GitHub API 拉了這些數字，下面這份普查就是老一輪評比文章跳過的檢查，附上讓你在決定採用哪個之前重新執行的指令。LightRAG 與 microsoft/graphrag 是活躍的；nano-graphrag 與 fast-graphrag 正滑向棄置。

for r in HKUDS/LightRAG microsoft/graphrag getzep/graphiti neo4j/neo4j-graphrag-python gusye1234/nano-graphrag circlemind-ai/fast-graphrag; do gh api "repos/$r" --jq '.full_name,.stargazers_count,.pushed_at,.open_issues_count'; done

我們的解讀：星數是虛榮指標；push 日期才是關鍵數字。LightRAG 與 microsoft/graphrag 都在活躍維護，Graphiti 以時序圖譜路線緊跟在後。nano-graphrag 與 fast-graphrag 就是老文章仍然只憑名氣推薦的那兩個，而兩者都已經半年沒有發布。

怎麼選：想要帶有四種官方查詢方法的參考實作，選 microsoft/graphrag；想要最活躍、足跡更輕的專案，選 LightRAG；已經在用某廠商資料庫的，就選 neo4j-graphrag-python 這類廠商維護的函式庫。任何最近 push 比你的專案還早半年的東西，都不要用。

Graphiti 值得一則有範圍的註記：它的時序圖譜設計是為時間感知資料上的檢索而建的，並與 agent 記憶重疊，我們在Graphiti 與時序圖譜記憶指南中另行涵蓋。更廣的領域，請看 RAG 工具全景。

第 200 天之後什麼會壞：圖譜漂移與重新擷取

圖譜漂移是你上線後要繳的稅，而且它穩居實務工作者異議的第一名是有原因的。每篇教學都把圖譜當成蓋一次的東西。真正的團隊在第 200 天卡住。

有三樣東西會衰化。第一，文件更新時的重新索引。當 40 份文件變動，你不能只重新嵌入它們；你必須對變動的切片重跑 LLM 擷取、把新實體跟舊圖譜對齊、重新計算受影響的社群及其摘要。有一篇 Medium 指南說增量更新很簡單。r/Rag 上的實務工作者不同意。一個 2026-04-25 討論串的發文者，在大約 600 份文件上跑 BM25 加 BGE-M3，講得很直白：「基於 LLM 的實體／關係擷取很吵，而文件更新時的重新索引看起來很痛苦。」

第二，實體解析的衰化。「Acme Corp」、「Acme」與「ACME Corporation」在不同月份、不同文件裡出現，分裂成三個本該是一個的節點。沒有任何東西會自動合併它們。

第三，在擷取時為真、後來悄悄不再為真的關係。reports_to 邊過期時，沒有人會收到警報。

def on_documents_changed(changed_docs):
    stale = find_affected_nodes(changed_docs)
    re_extract(changed_docs)
    reconcile_entities(stale)
    recompute_communities(affected_only=True)
    re_summarize(affected_communities)

程式碼庫是最糟的案例，也是最有趣的。自動完成現在會浮現「graphrag for codebase」、「graphrag claude code」與「graphrag mcp server」，而程式碼庫是一個每小時都在變的圖譜：每次 commit 都重寫呼叫邊、移動符號、刪除函式。這是按排程發生的圖譜漂移，沒有任何每夜重新索引能完整跟上。這也是為什麼嚴肅的程式碼圖譜工具把邊交給 tree-sitter 與 LSP 這類確定性剖析器，把 LLM 保留給邊周圍的文章：docstring、commit 訊息、審查討論串。如果你要為一個 repo 建圖譜，用 LLM 建變動慢的那一層，用剖析器建變動快的那一層。

開發者實際上怎麼說 GraphRAG？

現役開發者意見分裂，而 Google 似乎知道這件事：有一個 Reddit 討論串在「graphrag vs rag」上排到第二名，這是搜尋引擎在告訴你，這個主題要的是同儕意見，不是廠商文案。

懷疑是真實的。在 r/Rag 的 2024 年討論串「Would you always recommend (knowledge) graph RAG over normal RAG?」（10 點，86% 贊同）裡，u/EncartaIt 寫道：「我找到的所有教學都過度簡化，並沒有真正為知識圖譜模式提出有力論證。」u/Prestigious_Run_4049 更直接：「我覺得 graph rag 就是炒作。大家愛談論它，聽起來很酷，但沒有人在真實使用場景裡真的用。」不是每個人都同意。u/pytheryx 從正式環境經驗出發，指出圖譜檢索在清單型問題上會贏，這類問題需要的脈絡超過 top_k 回傳的切片數；他的白皮書語料庫需要大約 50 個切片才能給出完整答案。

2026 年的討論串比較節制。u/Popular_Sand2773：「多數 graph rag 架構在規模化時根本是在作弊。你先跑標準向量或中繼資料檢索找到種子節點，然後四處走訪。」u/ggone20，經營一個大約三億件產物的系統：「在規模下，要回答真實問題，你根本離不開它們。」

我們的解讀與兩個討論串裡最銳利的論點一致：轉折點是問題的複雜度，不是語料庫的規模。這也是上面基準測試的發現，所以我們站在把工具限定在多跳工作的實務工作者那邊，而不是宣稱它已死的那邊。

Techsy 怎麼做

以下是我們在客戶建置上使用的順序，而且刻意很無聊。

第一，先證明混合檢索的上限。我們聽到的多數「我們需要圖譜」需求，實際上是偽裝成圖譜需求的切片或重新排序問題。一條 BM25 加向量的管線，配上像樣的 reranker，能回答的比團隊預期的多。

第二，在動手蓋任何東西之前，先在自己的語料庫上把 Basic Search 當對照組跑。那正是第四種查詢方法的用途：一個單純向量基準，讓你在自己的資料上、用自己的問題，跟圖譜做 A/B 測試。

第三，只有當某一類經測量會失敗的問題輸給對照組時，才去建圖譜。如果多跳或跨語料庫的查詢沒過，你就有真實案例。如果過了，你剛幫自己省下一筆索引帳單和一個漂移問題。

想讓你的檢索架構多一雙眼睛？預約免費諮詢。

關於作者

Mert Batur 是 Techsy.io 的共同創辦人，團隊為 B2B 客戶交付 AI agent、自動化系統與語音／SDR 管線。他寫的是 Techsy 團隊在正式環境實際使用的 LLM 工具堆疊。在客戶建置上，他做檢索架構的決策：何時混合檢索就夠了，何時一個語料庫才真的需要圖譜。在 LinkedIn 與他聯繫。

常見問題

GraphRAG 如何運作？

GraphRAG 把你的文件索引成知識圖譜。LLM 從每個切片擷取實體與關係，Leiden 演算法把這些實體分群成社群，每個社群再產生一份摘要。查詢時，引擎搜尋圖譜與這些摘要，因此能串起落在不同切片裡的事實。

GraphRAG 和 RAG 有何不同？

標準 RAG 檢索 top-k 個最相似的切片，把它們餵給模型。GraphRAG 檢索的是結構：實體、實體之間的關係，以及預先寫好的社群摘要。那層額外結構正是讓它能回答多跳與跨語料庫問題的原因，也是讓索引變慢、變貴的原因。

我什麼時候該用 GraphRAG？

當你的問題跨越實體或橫跨整個語料庫時使用，例如供應商重疊問題，或在數千份文件上做反覆出現的主題分析。單跳事實查詢、快速變動的語料庫、延遲或成本預算吃緊的場景，跳過它。如果一條單純的混合管線已經能回答某類問題，圖譜就是只加成本、不加價值。

GraphRAG 死了嗎？

沒有，但它也不是預設選項。2026 年的基準測試顯示，它在日常任務上經常輸給原生 RAG，這殺死了炒作，同時在多跳與聚合問題上仍然獲勝。誠實的框架是情境型的：GraphRAG 在對的問題類型上賺回成本，在其餘場景賠錢。

GraphRAG 的查詢方法有哪些？

官方查詢引擎內建四種：Local Search 用於以實體為中心的問題，Global Search 用於跨語料庫聚合，DRIFT Search 遞迴混合兩者，Basic Search 用於單純向量檢索。第五個功能 Question Generation 位於其上。最重要的是 Basic Search：它是你拿來跟圖譜 A/B 測試的對照組。

GraphRAG 索引要花多少錢？

成本落在索引階段，來自從每個切片擷取實體與關係的 LLM 呼叫，加上社群摘要。Microsoft Research 回報 LazyGraphRAG 的索引成本只有完整 GraphRAG 的 0.1%，且與向量 RAG 相同，但該變體發布在 Microsoft 產品裡，而不是開源函式庫。我們自己沒有跑過計價的索引。

我可以用 Ollama 在本機跑 GraphRAG 嗎？

可以。microsoft/graphrag 函式庫讓你能把索引與查詢指向由 Ollama 提供的本機模型，這能從擷取步驟移除按 token 計費的 API 費用。你用速度與品質換成本：本機模型在實體擷取上較弱，所以在普通硬體上，預期圖譜較吵、索引執行較久。

LightRAG 和 Microsoft GraphRAG 哪個比較好？

它們最佳化的目標不同。LightRAG（38,353 星，2026-07-30 push）最活躍、執行較輕；microsoft/graphrag（35,088 星，v3.1.1）是帶有四種官方查詢方法的參考實作。要一個高效率的正式環境圖譜，選 LightRAG；要忠於規格的行為與 Basic Search 對照組，選 Microsoft 的。

GraphRAG 是誰、什麼時候建立的？

Microsoft Research 建立了 GraphRAG。團隊在 2024 年發表論文，並以 MIT 授權維護開源 microsoft/graphrag 儲存庫，文件位於 microsoft.github.io/graphrag。參考函式庫在 2026-07-18 達到 v3.1.1，一個活躍的第三方實作生態系（包括 LightRAG 與 Graphiti）已圍繞它成長。

結論：圖譜何時賺回它的成本

證據指向同一個方向，所以以下是我們的立場。

• GraphRAG 沒有死。它是情境型的，2026 年的基準測試公開這麼說。
• 它在多跳實體問題與跨語料庫聚合上賺回索引帳單。它在單跳查詢上賠錢。
• 成本是索引階段的帳單，而人人引用的便宜變體 LazyGraphRAG，從來沒有進過開源函式庫。
• 圖譜在上線後會衰化：實體解析漂移、關係過期，所以要為重新索引編列預算。
• 在動手蓋任何東西之前，先在自己的語料庫上把 Basic Search 當對照組跑。

一句話：當你的問題是多跳或跨語料庫時，知識圖譜才賺回它的成本，在此之前都不算。如果你想讓檢索架構多一雙眼睛，預約免費諮詢。