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

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% 通過率與「圖譜全面勝出」結論說服力薄弱，省錢估算過度外推；概念與工程細節可參考，數據結論不宜盡信，略讀即可。