你該使用哪種 RAG？向量、無向量與知識圖譜 RAG 全面對決

原始來源與檔名：20260512_2026-05-06T095807+0800-Which RAG Should You Use?.md

來源：[[FYL]] / Medium — 2026-04-22 原始檔名：2026-05-06T095807+0800-Which RAG Should You Use?.md

NAPKIN | 餐巾紙

餐巾紙公式

Vector RAG = Fast, Cheap, Good for Keywords/Semantics. Fails at Cross-Doc Reasoning. Vectorless RAG = Easy Setup, High Breadth. Fails at Cost/Token limits at scale. Knowledge Graph (KG) RAG = High Setup Cost, Excels at Relational & Aggregation. Cost-effective post-setup. Best Approach = Combine based on query needs.

當你在開發 RAG (檢索增強生成) 系統時，選擇正確的檢索策略至關重要。作者使用食譜資料集對比了三種方法：傳統的 Vector RAG (基於向量相似度)、Vectorless RAG (把所有資料塞進 Prompt 讓 LLM 自己看)、以及 Knowledge Graph RAG (預先抽取實體關係建立圖譜)。結論是：Vector RAG 便宜快速但無法做跨文本推理；Vectorless RAG 最聰明但 Token 費用在資料量大時會破產；Knowledge Graph RAG 建置成本高，但極度擅長宏觀關聯與聚合分析。

一句話

不要盲目迷信向量資料庫 (Vector DB)。如果你只是要查「蘋果派怎麼做」，傳統的 Vector RAG 又快又便宜。如果你資料量很小，乾脆用 Vectorless RAG 把文件全部丟給大模型讀。但如果你要問的是「這 1000 份食譜裡，最常跟肉桂一起使用的材料是什麼？」，向量檢索絕對會失敗，這時你需要預先抽取出關聯的 Knowledge Graph RAG。依照你的「問題類型」來選擇，甚至混合使用，才是成熟的系統架構。

餐巾紙草圖

[ The RAG Trade-off Triangle ]

                  Vectorless RAG
                  (Simple Setup, Highest Token Cost)
                       /\
                      /  \
                     /    \
                    /      \
 Vector RAG        /________\     KG RAG
 (Fast, Cheap,                    (High Setup Cost,
 Poor Reasoning)                  Best Relational Reasoning)

* Q: "Apple pie recipe?" -> Vector RAG
* Q: "What's the most common ingredient across all 1000 recipes?" -> KG RAG

ROUND 1: SKELETON | 骨架掃描

“這篇文章在說什麼”

實驗設計: 使用近 1000 份食譜的資料集，設計 5 種不同複雜度的查詢（基礎關鍵字、條件限制、語義理解、跨文檔推理、宏觀聚合），來測試三種 RAG 策略。
Vector RAG (向量 RAG):
- 將文本轉為 Embeddings 存入 FAISS，依賴相似度搜尋。
- 優點：極快、Token 消耗極低 ($0.004/query)。
- 缺點：碰到「跨文檔關係」或「聚合統計」直接陣亡。
Vectorless RAG (無向量 RAG):
- 依賴 LlamaIndex 的 SummaryIndex，將全部文本載入內存交給 LLM (使用 TREE_SUMMARIZE 避免 Token 爆表)。
- 優點：不用建 Index、不依賴 Embeddings，上下文理解最強。
- 缺點：在 100 篇食譜時費用就是 Vector RAG 的 18 倍；資料量一放大就無法擴展。
Knowledge Graph RAG (知識圖譜 RAG):
- 預先用 LLM 抽取「實體」(食材、技巧) 與「邊」(使用)，建立圖結構。查詢時只給 LLM 相關的局部圖譜。
- 優點：能看見隱藏的結構關係（例如發現肉桂連接了 100 份食譜）、擅長跨文件推導、查詢成本低。
- 缺點：前置處理成本高，且非常依賴 Prompt 限制實體命名規範（否則會產生圖譜碎片化）。

ROUND 2: DISSECTION | 血肉解剖

“憑什麼這麼說”

核心論證鏈

向量編碼的是「意義」，圖譜編碼的是「結構」: Vector RAG 之所以無法回答「綜合 100 篇文獻的結論」，是因為它每次只抓取 Top-K 個最相似的碎塊，它從根本上就看不見資料庫的全貌。KG RAG 將孤立的文本節點透過關聯線串起，賦予了系統「宏觀視野」。
沒有單一神兵利器: 作者的 Benchmark 清晰顯示，Q1 (直接檢索) Vector RAG 最快；Q2 (條件約束) Vectorless 表現最好；Q5 (聚合分析) 只有 KG RAG 能給出具體引用的精準答案。系統設計者必須根據 Query 種類做動態路由。

關鍵證據

節點破碎化問題: 作者指出 KG RAG 實作時的血淚教訓：如果沒有在 Prompt 中嚴格規定標準化輸出，LLM 會把 “Granny Smith apples” 和 “granny smith apple” 辨識為兩個不同節點，悄悄摧毀圖譜的連通性。

邊界條件

LLM-as-a-Judge 的局限: 作者坦承，評測分數有時會獎勵「語氣流暢的廢話」而非「絕對準確」。這呼應了開發 Agent 系統時必須建立高質量 Golden Datasets 的重要性。

ROUND 3: SOUL | 靈魂提取

“還能怎么用”

知識連結: 本文完美印證了《Supercharge your RAG with Multi-Agent Self-RAG》中提到的痛點：單次檢索的 RAG 在複雜問題上必然失敗。Self-RAG 是從「流程邏輯」解決問題（多搜幾次）；而 KG RAG 則是從「資料結構」解決問題（先建立關聯）。在頂級架構中，這兩者往往是結合的。
深層洞見: **“Vectors encode meaning. Graphs encode structure. These are different things.” (向量對意義進行編碼。圖譜對結構進行編碼。這是兩件不同的事。) ** 這是對 RAG 本質最深刻的洞察。不要試圖用算數（向量距離）去解決幾何問題（拓撲結構）。
行動呼籲: 檢查你目前的 RAG 應用。如果你發現用戶常常問「統整一下…」、「這兩者有什麼關聯」這類問題，而你的系統總是在胡說八道，請立刻停止優化 Embedding 模型或調整 Top-K。你需要引入 Knowledge Graph 抽取層，或是實作 Query Routing 將複雜問題交給 Vectorless RAG 處理。