GraphRAG vs RAG：知識圖譜如何在達成 100% 準確率的同時削減 90% Token 用量¶

文章資訊

作者：Muthukumaran　　日期：2026-06-06

原文標題：GraphRAG vs RAG: How a Knowledge Graph Cut Token Usage by 90% While Hitting 100% Accuracy

Medium 原連結：https://medium.com/@muthukumaran.42510/graphrag-vs-rag-how-a-knowledge-graph-cut-token-usage-by-90-while-hitting-100-accuracy-a5c11ba35452

🎧 摘要語音

🎧 全文語音

📝 重點摘要¶

TL;DR¶

在 TigerGraph 上以知識圖譜取代向量檢索，省 90% token 並維持滿分準確率。

核心問題¶

傳統 RAG（向量檢索＋LLM）只能取回「相似」的文字片段，無法取回「相互連結」的知識。面對需跨多個實體推理的問題（如「哪位物理學家的研究促成了 GPS 時間校正？」），向量檢索回傳段落、圖譜才回傳答案。作者想證明在 token 成本、準確率等指標上，圖譜全面優於向量檢索。

關鍵發現 / 數據¶

GraphRAG 每查詢約 382 tokens，比 Basic RAG 的 2,799 tokens 少 90%，成本降 93%。
三條 pipeline 的 LLM-as-a-Judge 通過率皆 100%；GraphRAG 的 BERTScore 達 0.9726。
Round 2 擴展至 1.08 億 token 維基科學語料（94,932 篇文章、約 85 萬 chunks），語料成長 40× 而查詢延遲維持平穩。
query 時以 448 tokens 的結構化實體脈絡取代 4,418 tokens 原始文字，知識量相同。
估算每月 1,000 萬次查詢可較 Basic RAG 省約 570 萬美元。

方法亮點¶

三 pipeline 並行比較：LLM-Only、Basic RAG、GraphRAG 同題同判，量化差異。
解決三個 GraphRAG 痛點：getDocumentChunks（取回同文件全部 chunk 解決兄弟段落遺失）、entityHopChunks（Chunk→實體→關係→Chunk 的多跳遍歷）、稀疏圖時以正則抽取實體名再做向量回退。
實體描述於 ingest 階段預先索引，成本只付一次，查詢端持續複利省 token。
疊加 6 項研究型技巧（PPR、Spreading Activation、PathRAG、Token Budget Controller、PolyG 路由、增量圖更新），各自帶來 +1.8%～+2.9% F1 或 92% 更快的再攝取。

對我的研究有用嗎？¶

痛點對應的三個 GSQL 設計（同文件 chunk 補全、多跳實體遍歷、實體層級向量回退）是 GraphRAG 工程化的實用模板，值得借鏡。把實體描述前置索引以壓縮查詢端 context 的思路，對 token 預算控制與 LLM-judge 評估流程也有參考價值。疊加的 6 項技巧附帶 ablation 數據，可作為延伸文獻入口。

評語¶

偏 hackathon 行銷成果展示，可疑點明顯：僅 10 題評測、100% 通過率與「圖譜全面勝出」結論說服力薄弱，省錢估算過度外推；概念與工程細節可參考，數據結論不宜盡信，略讀即可。

🌐 中英對照¶

Author: Muthukumaran 作者：Muthukumaran Published: 發布日期： Source: https://medium.com/@muthukumaran.42510/graphrag-vs-rag-how-a-knowledge-graph-cut-token-usage-by-90-while-hitting-100-accuracy-a5c11ba35452 來源：https://medium.com/@muthukumaran.42510/graphrag-vs-rag-how-a-knowledge-graph-cut-token-usage-by-90-while-hitting-100-accuracy-a5c11ba35452 Fetched: 2026-06-06T23:56:48.941238 擷取時間：2026-06-06T23:56:48.941238

GraphRAG vs RAG: How a Knowledge Graph Cut Token Usage by 90% While Hitting 100% Accuracy / GraphRAG 與 RAG 的對決：知識圖譜如何在達成 100% 準確率的同時將 Token 用量削減 90%¶

This was built for the GraphRAG Inference Hackathon by TigerGraph, where we went head-to-head against teams globally to prove graphs beat vector search on every metric that matters

本專案是為了 TigerGraph 主辦的 GraphRAG 推論黑客松 (GraphRAG Inference Hackathon) 而打造，我們在此與全球團隊正面交鋒，證明圖譜在每一項關鍵指標上都勝過向量搜尋 (vector search)。

Press enter or click to view image in full size

按下 Enter 或點擊以檢視完整尺寸圖片

TL;DR: We built a 3-pipeline benchmarking system on TigerGraph GraphRAG. GraphRAG uses 90% fewer tokens than Basic RAG, achieves 100% LLM-as-a-Judge pass rate, and scores 0.97 BERTScore — hitting every bonus threshold. Scaled to a 108-million-token Wikipedia corpus in Round 2. Here’s exactly how we did it.

重點摘要 (TL;DR)： 我們在 TigerGraph GraphRAG 上打造了一套三管線 (3-pipeline) 基準測試系統。相較於基礎 RAG，GraphRAG 使用的 Token 減少了 90%、達成 100% 的「LLM 作為評審 (LLM-as-a-Judge)」通過率，並取得 0.97 的 BERTScore ——命中了每一個加分門檻。在第二輪中更擴展到一個包含 1.08 億個 Token 的維基百科語料庫 (corpus)。以下就是我們具體的做法。

The Problem / 問題所在¶

LLMs burn thousands of tokens per query. Basic RAG (vector search + LLM) helps, but it retrieves similar chunks — not connected knowledge. A question like “Which physicist’s work led to GPS time corrections?” requires reasoning across multiple entities. Vector search returns paragraphs. Graphs return answers.

大型語言模型 (LLM) 每次查詢都會消耗數千個 Token。基礎 RAG（向量搜尋 + LLM）有所幫助，但它檢索的是相似的文字區塊 (chunk)——而非相互關聯的知識。像是「哪位物理學家的研究促成了 GPS 時間校正？」這樣的問題，需要跨越多個實體 (entity) 進行推理。向量搜尋回傳的是段落，而圖譜回傳的是答案。

Press enter or click to view image in full size

按下 Enter 或點擊以檢視完整尺寸圖片

What We Built / 我們打造了什麼¶

A 3-pipeline system that runs every query through three approaches simultaneously:

一套三管線系統，會同時讓每個查詢經過三種不同的方法處理：

Pipeline 1 — LLM-Only: No retrieval. Baseline. ~142 tokens/query.
管線 1 — 僅使用 LLM (LLM-Only)： 不進行檢索。作為基準線。每次查詢約 142 個 Token。
Pipeline 2 — Basic RAG: Vector embeddings + top-K chunks. ~2,799 tokens/query.
管線 2 — 基礎 RAG (Basic RAG)： 向量嵌入 (vector embeddings) + 前 K 個文字區塊 (top-K chunks)。每次查詢約 2,799 個 Token。
Pipeline 3 — GraphRAG: TigerGraph entity traversal + compact KG context. ~382 tokens/query.
管線 3 — GraphRAG： TigerGraph 實體遍歷 (entity traversal) + 精簡的知識圖譜 (Knowledge Graph, KG) 上下文。每次查詢約 382 個 Token。

Built on the official TigerGraph GraphRAG repo, with 14 novel techniques added on top.

以官方的 TigerGraph GraphRAG 儲存庫 (repo) 為基礎打造，並在其上額外加入了 14 項創新技術。

Press enter or click to view image in full size

按下 Enter 或點擊以檢視完整尺寸圖片

The Architecture (4 Layers) / 系統架構（四層）¶

Layer 4: Evaluation    — Groq Llama-3.3-70B judge · BERTScore · F1/EM  
Layer 3: LLM           — 12 providers (Gemini, Claude, GPT-4, Groq, Mistral...)  
Layer 2: Orchestration — Adaptive Router · 3-Pipeline Manager · NoveltyEngine  
Layer 1: Graph         — TigerGraph Cloud · GSQL traversal · Entity/Relation store

Round 2: Scaling to 108 Million Tokens

第二輪：擴展至 1.08 億個 Token

Round 1 ran on 2.5M tokens. For Round 2 we scaled to a 108,874,614-token Wikipedia science corpus — 94,932 articles, ~850K chunks — verified with Gemini’s count_tokens API. TigerGraph Savanna's native graph traversal kept query latency flat as the corpus grew 40×.

第一輪是在 250 萬個 Token 上運行。到了第二輪，我們擴展到一個包含 108,874,614 個 Token 的維基百科科學語料庫——共 94,932 篇文章、約 85 萬個文字區塊——並以 Gemini 的 count_tokens API 進行驗證。即使語料庫擴大了 40 倍，TigerGraph Savanna 的原生圖譜遍歷 (native graph traversal) 仍讓查詢延遲 (latency) 保持平穩不變。

Three GraphRAG Pain Points We Solved / 我們解決的三個 GraphRAG 痛點¶

Pain Point 1 — Sibling chunk loss: Standard GraphRAG retrieves a single top-K chunk. If context spans the next paragraph, it’s lost. Fix: getDocumentChunks GSQL query fetches all chunks from the same document, ordered by chunk_index.

痛點 1 — 兄弟區塊遺失 (Sibling chunk loss)： 標準的 GraphRAG 只檢索單一的前 K 個文字區塊。如果上下文延伸到了下一個段落，那部分就會遺失。解決方法：getDocumentChunks GSQL 查詢會擷取同一份文件中的所有文字區塊，並依照 chunk_index 排序。

Pain Point 2 — Entity relationship blindness: Vector search can’t traverse relationships. Fix: entityHopChunks GSQL — hops Chunk → MENTIONS → Entity → RELATED_TO → Entity → back to Chunks, surfacing thematically linked content the query never touched.

痛點 2 — 實體關係盲區 (Entity relationship blindness)： 向量搜尋無法遍歷關係。解決方法：entityHopChunks GSQL——以 Chunk → MENTIONS → Entity → RELATED_TO → Entity → 回到 Chunks 的方式跳轉 (hop)，浮現出查詢本身從未觸及、但在主題上相互關聯的內容。

Pain Point 3 — Empty entity-hop fallback: If entity-hop returns nothing (sparse graph), context is empty. Fix: regex-extract capitalized entity names, embed them, and fall back to vector search on the entities — not the raw query.

痛點 3 — 實體跳轉為空時的後備機制 (Empty entity-hop fallback)： 如果實體跳轉沒有回傳任何結果（稀疏圖譜），上下文就會是空的。解決方法：以正規表達式 (regex) 擷取首字母大寫的實體名稱，將其嵌入向量化，然後針對這些實體（而非原始查詢）退而進行向量搜尋。

Press enter or click to view image in full size

按下 Enter 或點擊以檢視完整尺寸圖片

Benchmark Results / 基準測試結果¶

10 Wikipedia science questions. Gemini 2.5 Flash. Independent judge: Groq Llama-3.3–70B.

10 道維基百科科學問題。使用 Gemini 2.5 Flash。獨立評審：Groq Llama-3.3–70B。

Pipeline | Tokens/Query | Cost/Query | LLM-Judge | BERTScore
LLM-Only | 142 | $0.000014| 100% | —
Basic RAG | 2799| $0.000611| 100% | —
GraphRAG | 382| $0.000043 | 100% | 0.9726
GraphRAG vs | −90% | −93% | BONUS ✅ | BONUS ✅

管線 | 每次查詢 Token 數 | 每次查詢成本 | LLM 評審 | BERTScore
僅使用 LLM | 142 | $0.000014 | 100% | —
基礎 RAG | 2799 | $0.000611 | 100% | —
GraphRAG | 382 | $0.000043 | 100% | 0.9726
GraphRAG 對比 | −90% | −93% | 加分 ✅ | 加分 ✅

Press enter or click to view image in full size

按下 Enter 或點擊以檢視完整尺寸圖片

Press enter or click to view image in full size

按下 Enter 或點擊以檢視完整尺寸圖片

The Token Story / Token 的故事¶

GraphRAG’s entity descriptions are pre-indexed at ingest time. At query time, instead of sending 4,418 tokens of raw chunk text, we send 448 tokens of structured entity context: “General relativity: geometric theory of gravitation published by Albert Einstein in 1915.” Same knowledge, 90% fewer tokens, zero accuracy loss.

GraphRAG 的實體描述會在資料攝取 (ingest) 時就預先建立索引。在查詢時，我們不再傳送 4,418 個 Token 的原始文字區塊內容，而是傳送 448 個 Token 的結構化實體上下文：「廣義相對論：阿爾伯特・愛因斯坦於 1915 年發表的重力幾何理論。」相同的知識，Token 減少了 90%，且準確率毫無損失。

At 10M queries/month, that’s ~$5.7M/month saved vs Basic RAG. The graph index is paid once at ingest — savings compound per query.

以每月 1,000 萬次查詢計算，相較於基礎 RAG，每月可節省約 570 萬美元。圖譜索引只需在攝取時付出一次成本——而節省的效益則會隨著每次查詢累積複利。

Press enter or click to view image in full size

按下 Enter 或點擊以檢視完整尺寸圖片

14 Novel Techniques / 14 項創新技術¶

We layered 6 research-backed novelties on top of the base TigerGraph GraphRAG:

我們在基礎的 TigerGraph GraphRAG 之上，疊加了 6 項有研究依據的創新技術：

PPR Confidence Retrieval (CatRAG) — +2.9% F1 in ablation
PPR 信賴度檢索 (PPR Confidence Retrieval)（CatRAG）——在消融實驗 (ablation) 中提升 +2.9% 的 F1 分數
Spreading Activation (SA-RAG) — +1.8% F1
擴散激活 (Spreading Activation)（SA-RAG）——提升 +1.8% 的 F1 分數
Flow-Pruned Paths (PathRAG) — bridge question accuracy
流量剪枝路徑 (Flow-Pruned Paths)（PathRAG）——提升橋接型問題 (bridge question) 的準確率
Token Budget Controller (TERAG) — enforces token ceiling per query
Token 預算控制器 (Token Budget Controller)（TERAG）——為每次查詢強制設定 Token 上限
PolyG Hybrid Router (RAGRouter-Bench) — +2.1% F1
PolyG 混合路由器 (PolyG Hybrid Router)（RAGRouter-Bench）——提升 +2.1% 的 F1 分數
Incremental Graph Updates (TG-RAG) — 92% faster re-ingestion
增量式圖譜更新 (Incremental Graph Updates)（TG-RAG）——重新攝取速度加快 92%

Try It Live / 即時試用¶

Dashboard: tigergraph-dashboard.vercel.app
儀表板 (Dashboard)： tigergraph-dashboard.vercel.app
GitHub: github.com/MUTHUKUMARAN-K-1/graphrag-inference-hackathon
GitHub： github.com/MUTHUKUMARAN-K-1/graphrag-inference-hackathon

Bring your own API key — enter it directly in the UI. No server-side key storage.

自備你自己的 API 金鑰——直接在使用者介面 (UI) 中輸入即可。伺服器端不會儲存任何金鑰。

Built for the GraphRAG Inference Hackathon by TigerGraph · #GraphRAGInferenceHackathon #TigerGraph #GraphRag

為 TigerGraph 主辦的 GraphRAG 推論黑客松而打造 · #GraphRAGInferenceHackathon #TigerGraph #GraphRag

🔤 關鍵術語¶

英文	繁中譯名	文章中的脈絡 / 簡短說明
GraphRAG	圖譜檢索增強生成	以知識圖譜實體遍歷取代向量檢索的 RAG 變體，token 用量比 Basic RAG 少 90%
RAG (Retrieval-Augmented Generation)	檢索增強生成	「向量檢索 + LLM」的基本架構，檢索相似 chunk 補充 LLM 上下文
Knowledge Graph (KG)	知識圖譜	以實體與關係構成的結構化知識，回傳「答案」而非段落
Vector Search / Vector Embeddings	向量檢索／向量嵌入	Basic RAG 的檢索方式，找語意相似片段，無法遍歷實體關係
Entity Traversal	實體遍歷	GraphRAG 在圖上沿實體與關係跳轉以取得相連知識
BERTScore	BERTScore（語意相似度評分）	評估生成答案品質的指標，GraphRAG 達 0.9726
LLM-as-a-Judge	以 LLM 作為評審	用獨立 LLM（Groq Llama-3.3-70B）判定答案是否通過，達 100% pass rate
Top-K Chunks	Top-K 片段檢索	Basic RAG 取相似度最高的 K 個文本片段送入 LLM
Chunk	文本片段	文件切分後的最小檢索單位，依 `chunk_index` 排序
GSQL Traversal	GSQL 圖查詢遍歷	TigerGraph 的圖查詢語言，執行 `getDocumentChunks`、`entityHopChunks` 等遍歷
Entity / Relation Store	實體／關係儲存	圖層中儲存實體與其關聯（如 MENTIONS、RELATED_TO）
Entity-Hop	實體跳轉	`Chunk → MENTIONS → Entity → RELATED_TO → Entity → Chunks` 的多跳檢索路徑
Token Budget Controller	Token 預算控制器	TERAG 技術，對每個 query 強制 token 上限
PPR (Personalized PageRank) Confidence Retrieval	個人化 PageRank 信心檢索	CatRAG 技術，消融實驗中提升 +2.9% F1
Spreading Activation	擴散激活檢索	SA-RAG 技術，沿圖節點擴散以提升檢索，+1.8% F1
Flow-Pruned Paths	流量剪枝路徑	PathRAG 技術，改善跨實體 bridge question 的準確度
Hybrid Router	混合路由器	PolyG / Adaptive Router，依查詢選擇檢索策略，+2.1% F1
Incremental Graph Updates	增量圖更新	TG-RAG 技術，re-ingestion 速度提升 92%
F1 / EM (Exact Match)	F1 分數／完全匹配	評估層使用的答案準確度指標
Ingest / Re-ingestion	資料攝取／重新攝取	圖索引在攝取時一次建立，實體描述預先索引，查詢時成本攤提