GraphRAG vs Vectorless RAG vs Vector RAG（2026 進階情境工程指南）

文章資訊

作者：Divy Yadav　　日期：2026-06-13

原文標題：GraphRAG vs Vectorless RAG vs Vector RAG (A 2026 Guide to Advanced Context Engineering)

Medium 原連結：https://pub.towardsai.net/graphrag-vs-vectorless-rag-vs-vector-rag-a-2026-guide-to-advanced-context-engineering-e8e9264cab38

⭐ 收藏

🎧 摘要語音

🔊 朗讀全文（收藏後自動生成）

---

📝 重點摘要

TL;DR

向量 RAG 已觸天花板，關係用 GraphRAG、結構用 Vectorless RAG，最佳解是自適應路由。

核心問題

傳統向量 RAG 靠語意相似度檢索，遇到複雜問題會結構性失效：無法理解實體關係、切塊破壞文件結構、且不會報錯而是「自信地給出錯誤答案」。文章探討兩種新架構如何從不同方向突破此瓶頸，以及該如何為產品選對工具。

關鍵發現 / 數據

• Diffbot benchmark：當每個查詢的實體數超過 5 個、且無知識圖譜支援時，向量 RAG 準確率降至 0%（Metrics/KPIs、Strategic Planning 類別皆為零）。
• GraphRAG 在企業情境達 72–83% 完整性，準確率提升 3.4 倍。
• Vectorless RAG（PageIndex/Mafin 2.5）在 FinanceBench 達 98.7% 準確率，向量 RAG 約 50%、純 GPT-4o 約 31%、Perplexity 約 45%。
• GraphRAG 索引成本 $20–500；LazyGraphRAG 將其降至 0.1%，代價是每查詢多 2–8 秒。
• GraphRAG 效能在 5–15M tokens 後趨於平緩，圖遍歷的鑑別力下降。

方法亮點

• GraphRAG：用 LLM 自動抽取實體與關係建圖（無需現成知識圖譜），Leiden 演算法做社群偵測 + 社群摘要，支援全域與局部查詢。
• Vectorless RAG（PageIndex）：不切塊、不嵌入、不用向量庫；保留文件樹狀結構，讓 LLM 像專家般「看目錄→導航到對應章節」，借鑑 AlphaGo 的策略式導航。
• Adaptive RAG：以查詢分類器路由——簡單查詢走向量 RAG，關係查詢走 GraphRAG，結構化文件走 Vectorless。

對我的研究有用嗎？

對 LLM Graph / GraphRAG 研究者頗有參考價值：LazyGraphRAG 的「延後社群摘要至查詢時」是降本關鍵思路；GraphRAG 效能隨 token 規模 plateau 的觀察值得在大型圖實驗中驗證；PageIndex 的樹狀結構導航提供了「結構 vs 相似度」的對照基線，可作為 GraphRAG 在結構化文件上的競品比較。

評語

觀念清晰、定位準確的科普佳作，適合快速建立架構分類框架；但數據多引自單一來源（Diffbot、廠商自評 benchmark），缺乏獨立驗證與引用連結，宜當作觀念地圖而非可信實證，深讀價值中等。

---

🌐 中英對照

Author: Divy Yadav 作者：Divy Yadav

Published: 發布日期：

Source: https://pub.towardsai.net/graphrag-vs-vectorless-rag-vs-vector-rag-a-2026-guide-to-advanced-context-engineering-e8e9264cab38 來源：https://pub.towardsai.net/graphrag-vs-vectorless-rag-vs-vector-rag-a-2026-guide-to-advanced-context-engineering-e8e9264cab38

Fetched: 2026-06-13T01:06:27.839607 擷取時間：2026-06-13T01:06:27.839607

---

Press enter or click to view image in full size

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

GraphRAG vs Vectorless RAG vs Vector RAG (A 2026 Guide to Advanced Context Engineering) / GraphRAG 對比 Vectorless RAG 對比 Vector RAG（2026 進階上下文工程指南）

Why traditional vector search is hitting a ceiling, how two radically different architectures are replacing it, and which one belongs in your next production system / 為什麼傳統向量搜尋 (Vector Search) 正觸及瓶頸、兩種截然不同的架構如何取而代之，以及你的下一個正式環境系統該採用哪一種

Here is what actually happens in most RAG systems: the retrieval finds something semantically close, the LLM writes a confident paragraph around it, and nobody notices the answer is wrong until a user files a complaint six weeks later.

大多數檢索增強生成 (RAG, Retrieval-Augmented Generation) 系統實際發生的情況是這樣的：檢索找到了某個語意上相近的內容，大型語言模型 (LLM, Large Language Model) 圍繞它寫出一段語氣篤定的文字，而直到六週後有使用者提出投訴，才有人注意到這個答案是錯的。

No error. No log entry. Just a system that runs smoothly and quietly misleads people.

沒有錯誤。沒有日誌記錄。只有一個運作順暢、卻悄無聲息地誤導人們的系統。

This is the failure mode that vector RAG cannot fix by tweaking parameters. It is structural. And in 2026, two architectures are breaking through it in completely different directions.

這是 Vector RAG 無法靠調整參數來修復的失效模式。它是結構性的。而在 2026 年，有兩種架構正以完全不同的方向突破它。

• GraphRAG adds a knowledge graph layer that maps relationships between entities.

• GraphRAG 增加了一個知識圖譜 (Knowledge Graph) 層，用以對應實體之間的關係。

• Vectorless RAG throws out the vector database entirely and has the LLM reason over document structure instead.

• Vectorless RAG 則徹底丟棄向量資料庫 (Vector Database)，改由 LLM 直接針對文件結構進行推理。

Neither is a drop-in replacement.

這兩者都不是能直接替換上去的方案。

Both solve real problems; the other genuinely cannot.

兩者各自解決了真實存在的問題，而對方確實無法處理。

This article explains the difference clearly enough that you can pick the right one for your system without spending three weeks reading papers.

本文會把其中的差異講得夠清楚，讓你不必花三週讀論文就能為你的系統挑出正確的方案。

Press enter or click to view image in full size

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

Why Traditional Vector RAG Is Breaking / 為什麼傳統 Vector RAG 正在失靈

Vector RAG became the standard because it works.

Vector RAG 之所以成為標準，是因為它確實有效。

Chunk your documents, embed the chunks, store them, retrieve by similarity. For simple factual lookup: fast, cheap, good enough.

把文件切塊 (Chunk)、將切塊嵌入 (Embed)、儲存起來、再依相似度檢索。對於簡單的事實查詢來說：快速、便宜、夠用。

The problem starts when the questions get harder.

問題從問題本身變難時開始浮現。

Three failure modes vector RAG cannot escape:

Vector RAG 無法逃脫的三種失效模式：

1. It has no concept of relationships. Semantic similarity finds chunks that sound like the query. It cannot follow “the regulation in Section 4 cross-references the exception in Appendix C.” Those two sections may be far apart in embedding space even though one defines the other. The model never sees the connection.

1. 它沒有「關係」這個概念。 語意相似度找的是聽起來像查詢的切塊。它無法跟進「第 4 節中的法規交叉引用了附錄 C 中的例外條款」。那兩個章節在嵌入空間 (Embedding Space) 中可能相距甚遠，即便其中一個定義了另一個。模型從未看見這個關聯。

2. Chunking destroys structure. When you split a financial report into 512-token windows, you sever tables from their headers, footnotes from the numbers they qualify, and multi-part answers from their context. A number in a cell is meaningless without its column header, and chunking strips that. This is not a chunk size problem. It is an architectural limitation.

2. 切塊會摧毀結構。 當你把一份財報切成 512 個詞元 (Token) 的視窗時，你切斷了表格與其標題、註腳與它所修飾的數字、以及由多個部分組成的答案與其上下文之間的聯繫。一個儲存格中的數字若沒有它的欄位標題就毫無意義，而切塊把這層關係剝除了。這不是切塊大小的問題，而是架構上的限制。

3. Accuracy collapses as queries get complex. On Diffbot’s benchmark, accuracy degrades to 0% as the number of entities per query increases beyond five without knowledge graph support. Both Metrics & KPIs and Strategic Planning categories showed zero accuracy from traditional vector RAG on schema-bound queries. Not low. Zero.

3. 隨著查詢變複雜，準確率全面崩潰。 在 Diffbot 的基準測試 (Benchmark) 中，在沒有知識圖譜支援的情況下，當每次查詢的實體數量超過五個時，準確率會降至 0%。在受限於結構描述 (Schema) 的查詢上，「指標與關鍵績效指標 (Metrics & KPIs)」與「策略規劃 (Strategic Planning)」這兩個類別中，傳統 Vector RAG 的準確率皆為零。不是偏低，是零。

TRADITIONAL VECTOR RAG ARCHITECTURE  

Document → Chunk (512 tokens) → Embed → Vector DB  
                                              ↓  
Query → Embed Query → Similarity Search → Top-K Chunks → LLM → Answer  
Problems this creates:  
- Chunks lose context from neighboring sections  
- No relationship traversal between entities  
- "Close enough" embedding ≠ "relevant" for complex queries

Most teams figure this out six months after they needed to. After they have explained to users why the AI confused two entities that share similar embeddings, or confidently cited a document that contradicts the actual answer.

大多數團隊都是在需要明白這件事的六個月之後才弄懂。在他們已經向使用者解釋過為什麼 AI 混淆了兩個共享相似嵌入的實體之後，或在 AI 言之鑿鑿地引用了一份與真實答案相互矛盾的文件之後。

GraphRAG: When Relationships Are the Answer / GraphRAG：當關係本身就是答案

Press enter or click to view image in full size

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

GraphRAG does not replace vector search.

GraphRAG 並非取代向量搜尋。

It adds a layer that vector search fundamentally cannot replicate: a map of how things connect.

它增加的是一個向量搜尋從根本上無法複製的層：一張關於事物如何彼此連結的地圖。

The core idea:

核心理念：

Instead of treating your document collection as a bag of chunks, GraphRAG builds a knowledge graph. Entities (people, companies, concepts, regulations) become nodes.

GraphRAG 不把你的文件集合當成一袋切塊，而是建構出一個知識圖譜。實體（人物、公司、概念、法規）成為節點 (Node)。

Relationships between them become edges. The graph captures that “GDPR Article 17 is enforced by the European Data Protection Board” in a way that vector similarity never could.

它們之間的關係則成為邊 (Edge)。這張圖能以向量相似度永遠做不到的方式，捕捉到「《一般資料保護規範》(GDPR) 第 17 條由歐洲資料保護委員會 (European Data Protection Board) 執行」這樣的資訊。

How it works, step by step:

它如何運作，逐步拆解：

GRAPHRAG ARCHITECTURE  

Documents  
    ↓  
Entity Extraction (LLM identifies: people, orgs, concepts)  
    ↓  
Relationship Extraction (LLM identifies: who connects to what and how)  
    ↓  
Community Detection (Leiden algorithm groups related entities)  
    ↓  
Community Summaries (LLM summarizes each cluster)  
    ↓  
Knowledge Graph (nodes + edges stored in graph database)  


Query Time:  
User Query → Graph Traversal → Relevant Nodes + Edges → LLM → Answer  
For global queries: Community summaries pre-answer "what themes exist?"  
For local queries: Direct traversal to specific entity clusters

The biggest myth is that you need a pre-existing knowledge graph to use GraphRAG. You do not. You use the LLM to build it. The extraction pipeline reads your documents and constructs the graph automatically.

最大的迷思在於，以為要使用 GraphRAG 就得先有一個既存的知識圖譜。並非如此。你是用 LLM 來建構它。萃取管線 (Extraction Pipeline) 會讀取你的文件並自動建構出這張圖。

What GraphRAG genuinely excels at:

GraphRAG 真正擅長之處：

• Multi-hop questions: “Which vendors does Company A use that also supply Company B’s competitors?”

• 多跳 (Multi-hop) 問題：「A 公司所使用的供應商中，有哪些同時也供貨給 B 公司的競爭對手？」

• Global synthesis: “What are the major themes across these 500 research papers?”

• 全域綜整 (Global Synthesis)：「這 500 篇研究論文橫跨的主要主題是什麼？」

• Relationship queries that require following connections, not just finding similar text

• 需要跟進連結、而非僅僅找到相似文字的關係型查詢

• Regulatory compliance analysis where cross-references are load-bearing

• 交叉引用具有關鍵承載作用的法規遵循 (Regulatory Compliance) 分析

GraphRAG achieves 72–83% comprehensiveness versus traditional RAG, with a 3.4x accuracy improvement in enterprise scenarios.

相較於傳統 RAG，GraphRAG 達到 72–83% 的完整度 (Comprehensiveness)，在企業情境中準確率提升達 3.4 倍。

The honest cost:

老實說的成本：

The original Microsoft GraphRAG approach costs $20–500 to index a typical enterprise corpus.

微軟最初的 GraphRAG 方法，為一個典型的企業語料庫建立索引需花費 20 至 500 美元。

That upfront bill is real.

這筆前期帳單是真實存在的。

It requires LLM calls to extract every entity and relationship from every document. Microsoft’s 2025 update, LazyGraphRAG, reduced this significantly. LazyGraphRAG reduces indexing cost to 0.1% of full GraphRAG by deferring community summarization to query time, at the cost of 2–8 additional seconds per query.

它需要透過 LLM 呼叫，從每份文件中萃取每個實體與每段關係。微軟 2025 年的更新版本 LazyGraphRAG 大幅降低了這項成本。LazyGraphRAG 透過將社群摘要 (Community Summarization) 延後至查詢時才進行，把索引成本降到完整版 GraphRAG 的 0.1%，代價是每次查詢額外增加 2 至 8 秒。

Where GraphRAG fails:

GraphRAG 失靈之處：

• Simple factual lookup: “What is our refund policy?” does not need a knowledge graph

• 簡單的事實查詢：「我們的退款政策是什麼？」並不需要知識圖譜

• Real-time knowledge: Graph indexing takes time, so it lags on fast-changing data

• 即時知識： 圖譜索引需要時間，因此在快速變動的資料上會有延遲

• Small, simple document collections where the infrastructure cost outweighs the benefit

• 小型、簡單的文件集合，其基礎設施成本超過了帶來的效益

• Research shows performance gains plateau at 5–15 million tokens as graph traversal becomes less discriminative with massive datasets.

• 研究顯示，當資料集規模龐大時，圖譜走訪 (Graph Traversal) 的鑑別力會下降，效能提升在 500 萬至 1,500 萬詞元處趨於平緩。

“GraphRAG is not a better RAG. It is retrieval for a different category of question.”

「GraphRAG 不是一種更好的 RAG，而是針對另一類問題的檢索方式。」

Build it for simple factual lookup and you have spent thousands of dollars on indexing infrastructure to answer questions that a 50-line vector pipeline would have handled in 200ms.

若你為了簡單的事實查詢而建構它，那你就是花了數千美元在索引基礎設施上，去回答那些一條 50 行的向量管線在 200 毫秒內就能處理完的問題。

Vectorless RAG: When Structure Beats Similarity / Vectorless RAG：當結構勝過相似度

Press enter or click to view image in full size

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

Vectorless RAG took a harder path. Instead of adding a graph layer on top of the existing retrieval model, it asked: what if the whole retrieval model is the wrong starting point?

Vectorless RAG 走了一條更難的路。它不在既有的檢索模型之上加一層圖譜，而是反問：如果整個檢索模型本身就是錯誤的起點呢？

PageIndex, the primary framework for vectorless RAG, was published in September 2025 by Mingtian Zhang and Yu Tang at VectifyAI. It has over 23,000 GitHub stars. The core insight borrows from AlphaGo: instead of searching exhaustively, navigate intelligently using a learned strategy.

PageIndex 是 Vectorless RAG 的主要框架，由 VectifyAI 的 Mingtian Zhang 與 Yu Tang 於 2025 年 9 月發布。它在 GitHub 上擁有超過 23,000 顆星。其核心洞見借鑒自 AlphaGo：不做窮舉式搜尋，而是運用一套習得的策略來進行智慧導航。

The shift in plain terms:

用白話來說的轉變：

Traditional RAG finds chunks that are semantically similar to the query. PageIndex asks the LLM to reason about where the answer would be in the document’s structure, then navigates there directly. The way a human expert actually uses a document: open it, scan the table of contents, go to the relevant chapter, read the table.

傳統 RAG 找的是與查詢語意相似的切塊。PageIndex 則要求 LLM 推理出答案會落在文件結構中的何處，然後直接導航到那裡。這正是人類專家實際使用文件的方式：打開它、掃視目錄、翻到相關章節、閱讀表格。

How Vectorless RAG works:

Vectorless RAG 如何運作：

VECTORLESS RAG ARCHITECTURE (PageIndex)  

Document Ingestion:  
PDF/Doc → Tree Indexing (preserves natural hierarchy)  
         → Chapter → Section → Subsection → Table cells  

NO chunking. NO embeddings. NO vector database.  

Tree structure looks like:  
├── Chapter 1: Revenue  
│   ├── 1.1 Q1 Results  
│   │   ├── Table: Revenue by Region  
│   │   └── Footnotes: Currency adjustments  
│   └── 1.2 Q2 Results  
└── Chapter 2: Expenses  

Query Time:  
User Query → LLM inspects Table of Contents tree  
           → LLM reasons: "Revenue figures would be in Chapter 1"  
           → LLM navigates to Chapter 1.1, retrieves context  
           → LLM generates answer with exact citations  
If incomplete → LLM navigates further → Iterates until answer is found

This is how a human expert reads a document. Not keyword search. Not embedding similarity. You open the report, scan the table of contents, go to the relevant chapter, read the relevant table. That is exactly what PageIndex teaches the LLM to do.

這就是人類專家閱讀文件的方式。不是關鍵字搜尋，不是嵌入相似度。你打開報告、掃視目錄、翻到相關章節、閱讀相關表格。這正是 PageIndex 教 LLM 去做的事。

The results are hard to argue with:

結果難以反駁：

Mafin 2.5, powered by PageIndex, achieved 98.7% accuracy on FinanceBench. Traditional vector RAG: approximately 50%. GPT-4o with no RAG: approximately 31%. Perplexity: approximately 45%. That 49-point gap over vector RAG is not incremental improvement. It is a different category of result.

由 PageIndex 驅動的 Mafin 2.5 在 FinanceBench 上達到 98.7% 的準確率。傳統 Vector RAG：約 50%。不搭配 RAG 的 GPT-4o：約 31%。Perplexity：約 45%。相對於 Vector RAG 那 49 個百分點的差距，並非漸進式的改進，而是另一種等級的結果。

Three reasons the gap is this large:

差距如此之大的三個原因：

• Cross-reference following. PageIndex navigates “see Appendix G” through the tree. Vector similarity has no concept of document references.

• 跟進交叉引用。 PageIndex 能透過樹狀結構導航「參見附錄 G」。向量相似度則沒有文件引用這個概念。

• Structure preservation. Tables keep their headers, footnotes, and cell relationships as tree nodes. Chunking destroys them.

• 保留結構。 表格的標題、註腳與儲存格關係都以樹狀節點的形式被保留下來。切塊則會摧毀它們。

• Multi-step reasoning. Questions requiring data from two separate sections get handled by iterative navigation, not a single retrieval pass.

• 多步驟推理。 需要從兩個獨立章節取得資料的問題，是透過迭代式導航來處理，而非單一次的檢索。

The honest limitations:

老實說的限制：

PageIndex is not a universal RAG replacement. It is a specialized tool that makes sense when accuracy justifies higher overhead.

PageIndex 並非通用的 RAG 替代品。它是一種專用工具，只有在準確率足以合理化更高的額外開銷時才划算。

The “vectorless” framing drew pushback because PageIndex “gets there completely and totally with iterative and recursive calls to an LLM.” It is not eliminating dependencies. It is replacing vector approximation with LLM reasoning approximation.

「無向量 (vectorless)」這個說法引來了反彈，因為 PageIndex「完全、徹底是靠對 LLM 進行迭代與遞迴呼叫才達成這一切」。它並未消除依賴，而是用 LLM 推理的近似，取代了向量的近似。

Both have costs.

兩者都有成本。

Those LLM calls add up. If you have millions of documents and simple queries, vectorless RAG is slower and more expensive than vector RAG for no meaningful accuracy gain. The overhead is justified only when accuracy is the primary constraint.

那些 LLM 呼叫會累積起來。如果你有數百萬份文件以及簡單的查詢，Vectorless RAG 會比 Vector RAG 更慢、更貴，卻換不到有意義的準確率提升。只有在準確率是首要限制條件時，這份額外開銷才合理。

The Deep Comparison / 深入比較

Here is how the three architectures actually differ across the dimensions that matter in production:

以下是這三種架構在正式環境中真正重要的各個維度上，實際上有何不同：

Press enter or click to view image in full size

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

The edge case most articles miss:

多數文章漏掉的邊界情況：

GraphRAG and Vectorless RAG are not competing with each other.

GraphRAG 與 Vectorless RAG 並非彼此競爭。

They solve different problems.

它們解決的是不同的問題。

• GraphRAG excels when you need to understand relationships across a large document collection.

• 當你需要理解橫跨大型文件集合的關係時，GraphRAG 表現出色。

• Vectorless RAG excels when you need precise answers from the internal structure of complex documents.

• 當你需要從複雜文件的內部結構中取得精確答案時，Vectorless RAG 表現出色。

The emerging production pattern in 2026 is Adaptive RAG: a query classifier routes each query to the appropriate pipeline based on complexity. Simple queries go to vector RAG (fast, cheap). Complex queries go to agentic RAG. Relationship queries go to GraphRAG. This delivers the optimal cost-quality tradeoff.

2026 年正在興起的正式環境模式是自適應 RAG (Adaptive RAG)：一個查詢分類器 (Query Classifier) 會根據複雜度，將每筆查詢路由 (Route) 到合適的管線。簡單查詢交給 Vector RAG（快速、便宜）。複雜查詢交給代理式 RAG (Agentic RAG)。關係型查詢交給 GraphRAG。這帶來了最佳的成本與品質權衡。

Real-World Application Patterns / 真實世界的應用模式

Where GraphRAG wins:

GraphRAG 勝出之處：

The use cases where GraphRAG proves its worth are all relationship-heavy:

GraphRAG 能證明其價值的使用案例，全都是高度仰賴關係的：

• Competitive intelligence: “Which companies in our market partner with the same logistics providers we’re evaluating?”

• 競爭情報 (Competitive Intelligence)：「我們市場上有哪些公司，與我們正在評估的同一批物流供應商有合作關係？」

• Regulatory compliance: Mapping how regulations cross-reference each other across jurisdictions

• 法規遵循： 對應法規如何跨司法管轄區彼此交叉引用

• Research synthesis: Finding connections across thousands of papers that no single paper makes explicit

• 研究綜整： 找出橫跨數千篇論文、卻沒有任何單一論文明確指出的關聯

• Healthcare applications like Cedars-Sinai’s 1.6 million edge Alzheimer’s research graph are early evidence of where this goes

• 像是 Cedars-Sinai 那張擁有 160 萬條邊的阿茲海默症研究圖譜這類醫療保健應用，正是此方向發展的早期佐證

Where Vectorless RAG wins:

Vectorless RAG 勝出之處：

Precision-sensitive domains where “close enough” answers are not acceptable:

那些「差不多」的答案無法被接受、對精確度敏感的領域：

• Financial analysis: Exact numbers from SEC filings, where a 50% accurate RAG system would be dangerous

• 財務分析： 取自美國證券交易委員會 (SEC) 申報文件的精確數字，在這裡一個準確率只有 50% 的 RAG 系統會很危險

• Legal document review: Contract clause extraction where context dependencies are load-bearing

• 法律文件審閱： 上下文依賴具有關鍵承載作用的合約條款萃取

• Technical documentation: Answering from structured specs where table relationships matter

• 技術文件： 從表格關係至關重要的結構化規格中作答

• Any domain where the document’s internal structure carries as much meaning as its text

• 任何文件內部結構與其文字承載同等意義的領域

Where traditional Vector RAG still wins:

傳統 Vector RAG 仍然勝出之處：

• Large, unstructured text collections (blog posts, email archives, news articles)

• 大型、非結構化的文字集合（部落格貼文、電子郵件封存檔、新聞文章）

• Simple semantic search where embedding similarity reliably finds the right content

• 嵌入相似度能可靠找到正確內容的簡單語意搜尋

• High-volume, low-complexity queries where speed and cost are the dominant constraints

• 速度與成本為主導限制條件的高量、低複雜度查詢

• Prototyping and early-stage systems where the overhead of graph or tree indexing is not yet justified

• 圖譜或樹狀索引的額外開銷尚不合理的原型開發與早期階段系統

Decision Framework: Which Architecture Fits Your Problem / 決策框架：哪種架構適合你的問題

Press enter or click to view image in full size

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

Before choosing, answer these four questions:

在做選擇之前，先回答這四個問題：

1. What kind of questions are users asking?

1. 使用者問的是哪一類問題？

• “What does document X say about Y?” → Vector RAG or Vectorless RAG

• 「文件 X 對於 Y 是怎麼說的？」→ Vector RAG 或 Vectorless RAG

• “How does A relate to B across all documents?” → GraphRAG

• 「A 與 B 橫跨所有文件是如何關聯的？」→ GraphRAG

• “Give me the exact number from this table” → Vectorless RAG

• 「給我這張表格裡的精確數字」→ Vectorless RAG

2. How much does accuracy matter?

2. 準確率有多重要？

• “Good enough” is acceptable → Vector RAG

• 「夠用就好」是可以接受的 → Vector RAG

• Errors have real consequences (financial, legal, medical) → Vectorless RAG or GraphRAG

• 錯誤會帶來真實後果（財務、法律、醫療）→ Vectorless RAG 或 GraphRAG

3. What is the structure of your documents?

3. 你的文件結構為何？

• Unstructured text, long articles, conversational content → Vector RAG

• 非結構化文字、長篇文章、對話式內容 → Vector RAG

• Structured reports, filings, contracts with internal references → Vectorless RAG

• 帶有內部引用的結構化報告、申報文件、合約 → Vectorless RAG

• Large collections with interconnected entities across documents → GraphRAG

• 實體橫跨文件彼此相連的大型集合 → GraphRAG

4. What are your latency and cost constraints?

4. 你的延遲與成本限制為何？

• Sub-second responses, high volume, tight budget → Vector RAG

• 次秒級回應、高流量、預算吃緊 → Vector RAG

• Moderate latency acceptable, accuracy critical → Vectorless RAG

• 可接受中等延遲、準確率至關重要 → Vectorless RAG

• Upfront indexing cost acceptable, complex relationships needed → GraphRAG

• 可接受前期索引成本、需要處理複雜關係 → GraphRAG

DECISION MATRIX  

Query type            Structure    Accuracy need    Choose  
─────────────────────────────────────────────────────────  
Semantic lookup       Unstructured Normal           Vector RAG  
Multi-hop relations   Any          High             GraphRAG  
Structured doc exact  Structured   Very high        Vectorless RAG  
Global themes         Large corpus Normal           GraphRAG  
Simple factual        Any          Normal           Vector RAG  
High-entity queries   Any          High             GraphRAG or Vectorless  
Cross-ref navigation  Structured   Very high        Vectorless RAG  
Mixed complexity      Any          Varies           Adaptive RAG (hybrid)

What the Best Production Systems Are Actually Doing / 最頂尖的正式環境系統實際上在做什麼

The honest answer is that no single architecture dominates across all use cases. Teams building the best AI systems are not picking one approach. They are routing.

老實說的答案是：沒有任何單一架構能在所有使用案例中稱霸。打造最佳 AI 系統的團隊並非只挑一種方法，而是在做路由。

A query classifier sits at the entry point. Simple semantic questions go to vector RAG. Complex relationship questions go to GraphRAG. Structured document queries go to vectorless RAG. Each query finds the right retrieval path based on what it actually needs.

一個查詢分類器坐鎮入口處。簡單的語意問題交給 Vector RAG。複雜的關係問題交給 GraphRAG。結構化文件查詢交給 Vectorless RAG。每筆查詢都會根據它實際所需，找到正確的檢索路徑。

This is more complex to build than a single pipeline. It is also dramatically more accurate and cheaper at scale. Because the majority of queries in most systems are simple, and simple queries do not need the overhead of graph traversal or iterative LLM navigation.

這比單一管線更難建構，但在規模化時也大幅更準確、更便宜。因為在大多數系統中，多數查詢都是簡單的，而簡單查詢並不需要圖譜走訪或迭代式 LLM 導航的額外開銷。

The Adaptive RAG pattern routes based on query complexity:

自適應 RAG 模式會依據查詢複雜度進行路由：

User Query → Complexity Classifier  
                 ↓  
    Simple? → Vector RAG (fast, cheap)  
    Complex? → GraphRAG or Vectorless RAG (accurate)  
    Relationship? → GraphRAG  
    Structured doc? → Vectorless RAG

This is not theoretical. It is what serious engineering teams are shipping into production right now.

這並非紙上談兵。這正是認真的工程團隊此刻正在推上正式環境的東西。

The Thing Worth Sitting With / 值得細細品味的一件事

Here is what I keep coming back to: the teams that shipped broken RAG systems were not bad engineers. They were using vector RAG correctly. It just was not the right tool for the questions their users were actually asking.

我一再回想到的是這一點：那些推出了失靈 RAG 系統的團隊，並非不稱職的工程師。他們正確地使用了 Vector RAG。只是它並非適合其使用者實際所問問題的正確工具。

RAG is not one technology anymore. It is three different retrieval philosophies that happen to share a name.

RAG 已不再是單一種技術。它是三種恰好共用同一個名字的不同檢索哲學。

Vector RAG: optimistic matching. Find what is close and hope it is right.

Vector RAG： 樂觀式比對。找出相近的內容，然後寄望它是對的。

GraphRAG: structural mapping. Know the relationships before the question arrives.

GraphRAG： 結構式對應。在問題到來之前就先掌握好關係。

Vectorless RAG: deliberate navigation. Reason about where the answer lives instead of guessing from similarity scores.

Vectorless RAG： 刻意式導航。推理出答案所在之處，而非從相似度分數中瞎猜。

The teams that understand this distinction are building systems where retrieval is not the bottleneck. The teams that do not are iterating on prompts to cover for retrieval that was never going to work at complexity.

理解這項區別的團隊，正在打造檢索不再是瓶頸的系統。不理解的團隊，則還在反覆調整提示詞 (Prompt)，去掩飾那個面對複雜情況時注定行不通的檢索。

My prediction: in 18 months, “do you use vector RAG or adaptive RAG?” will become the question that separates production-grade teams from demo teams. The same way “do you have evals?” already does.

我的預測：18 個月後，「你用的是 Vector RAG 還是 Adaptive RAG？」將成為區分正式環境等級團隊與只會做展示團隊的問題。就如同「你有評測 (Evals) 嗎？」如今已扮演的角色。

“The field moved from ‘does retrieval work?’ to ‘which retrieval architecture?’ in two years. The teams that make that shift early will stop explaining to users why the AI got it wrong.”

「這個領域在兩年內，從『檢索行得通嗎？』轉移到了『該用哪一種檢索架構？』。及早做出這項轉變的團隊，將不必再向使用者解釋為什麼 AI 弄錯了。」

If you found this useful, you’ll get much more like this in my newsletter every week.

如果你覺得這篇有用，每週都能在我的電子報中讀到更多類似的內容。

I break down AI into simple, visual and practical ideas you can actually use with high-quality articles every week.

我每週透過高品質文章，把 AI 拆解成簡單、視覺化且實用、你真正用得上的觀念。

Join here: 在此加入： https://aiengsimplified.beehiiv.com/

---

🔤 關鍵術語

英文	繁中譯名	文章中的脈絡 / 簡短說明
GraphRAG	圖譜檢索增強生成	在 RAG 上增加知識圖譜層，將實體間的關係建模為節點與邊
Vectorless RAG	無向量檢索增強生成	捨棄向量資料庫，讓 LLM 直接對文件結構進行推理導航（代表框架 PageIndex）
Vector RAG	向量檢索增強生成	傳統做法：切塊、嵌入、依相似度檢索；複雜查詢時準確率崩潰
Knowledge Graph	知識圖譜	將實體化為節點、關係化為邊的結構，捕捉向量相似度無法表達的連結
Vector Embeddings	向量嵌入	將文字區塊轉為向量以供相似度搜尋；無法表達跨段落的關係
Semantic Similarity	語意相似度	向量檢索的核心，只能找「聽起來像」查詢的區塊，非真正相關
Chunking	文件切塊	將文件切成固定 token 視窗（如 512），會破壞表格、註腳等結構
Entity Extraction	實體抽取	GraphRAG 用 LLM 從文件中辨識人、組織、概念等實體以建圖
Relationship Extraction	關係抽取	LLM 辨識實體之間「誰與誰、如何連結」以建立圖的邊
Community Detection	社群偵測	用 Leiden 演算法將相關實體分群
Leiden Algorithm	Leiden 演算法	GraphRAG 用於將相關實體聚類成社群的圖演算法
Community Summaries	社群摘要	LLM 為每個實體叢集生成摘要，供全域查詢預先回答主題
Graph Traversal	圖譜遍歷	查詢時沿節點與邊走訪以找到相關實體叢集
Multi-hop Questions	多跳問題	需跨多層關係連結才能回答的查詢，GraphRAG 的強項
LazyGraphRAG	延遲式 GraphRAG	Microsoft 2025 更新，將社群摘要延後到查詢時，把索引成本降至 0.1%
PageIndex	PageIndex	Vectorless RAG 主要框架，將文件建為樹狀索引並讓 LLM 推理導航
Tree Indexing	樹狀索引	保留文件自然階層（章 → 節 → 表格），不切塊、不嵌入
Adaptive RAG	自適應 RAG	以查詢分類器將每個查詢路由到最合適管線的混合架構
Query Classifier	查詢分類器	依複雜度將查詢導向 vector / graph / vectorless 管線
FinanceBench	FinanceBench	金融問答基準；Mafin 2.5（PageIndex）達 98.7% 準確率