2026 RAG 选型指南：Vector、Graph、Vectorless 该怎么挑

检索找到了某个语义上接近的片段，LLM 围绕它写出一段文字，但是没人发现答案是错的。这是 vector RAG 调参解决不了的失败问题。而现在有2种方法可以解决他：

• GraphRAG 增加了一层 knowledge graph，用来描绘实体之间的关系。
• Vectorless RAG 完全抛弃向量数据库，让 LLM 直接对文档结构进行推理。

这篇文章将介绍它们之间的差异，让你不必花三周读论文也能为自己的系统做出正确选择。

为什么传统 Vector RAG 正在失效

Vector RAG 之所以成为标准是因为它真的能用。

把文档分块，对块做 embedding，然后按相似度检索。对简单查询来说：快、便宜、够用。

但是Vector RAG 会出现三种失败模式。

第一，它没有"关系"这个概念。语义相似度找的是"听起来像 query"的 chunk，无法跟踪"第 4 节中的法规交叉引用了附录 C 中的例外条款"。这两节在 embedding 空间里可能相距很远，即使其中一节定义了另一节。模型永远看不到这种关联。

第二，chunking 破坏了结构。把一份财务报告切成 512-token 的窗口，就把表格和它的表头、脚注和它所限定的数字、多段答案和它们的上下文都断开了。一个单元格里的数字脱离列标题就毫无意义，而 chunking 会把这种关系剥离掉。这不是 chunk size 能调好的问题，是架构层面的局限。

第三，当查询变复杂，准确率会崩溃。在 Diffbot 的 benchmark 上，没有 knowledge graph 支持时，每个 query 涉及的实体数超过 5 个之后，准确率会退化到 0%。Metrics & KPIs 与 Strategic Planning 这两个类别里，传统 vector RAG 在 schema-bound query 上的准确率都是 0，不是低是零。

GraphRAG：当关系本身就是答案

GraphRAG 不替代向量搜索。它增加了一层向量搜索本质上无法复现的能力：一张关于事物如何彼此关联的地图。

不再把文档集合当作一袋 chunk，而是构建一张 knowledge graph。实体（人、公司、概念、法规）成为节点，实体之间的关系成为边。这张图能以向量相似度永远做不到的方式，把"GDPR Article 17 由 European Data Protection Board 执行"这样的关系刻画出来。

工作流程分步如下：

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)

这里最大的一个误区是用 GraphRAG 必须先有一张现成的 knowledge graph。其实不需要，因为可以直接用 LLM 来构建它。抽取 pipeline 会读取你的文档并自动构建图。

GraphRAG 真正擅长的事情：

• 多跳问题："Company A 使用的供应商里，哪些同时供应 Company B 的竞争对手？"
• 全局综合："这 500 篇研究论文里有哪些主要主题？"
• 关系型查询，需要顺着连接走，而不只是找相似文本
• 监管合规分析，其中交叉引用承担关键作用

GraphRAG 在企业场景下相比传统 RAG 实现了 72–83% 的 comprehensiveness，准确率提升 3.4 倍。

最初的 Microsoft GraphRAG 方案，索引一份典型企业语料库需要 $20–500，因为它需要 LLM 调用来从每一份文档中抽取每一个实体和关系。Microsoft 在 2025 年发布的 LazyGraphRAG 改变了这个问题：把摘要延迟到查询时再计算，索引成本降至完整 GraphRAG 的 0.1%，代价是每个查询多 2–8 秒。

GraphRAG 失效的场景：

• 简单事实查询。"What is our refund policy?" 这种问题不需要 knowledge graph。
• 实时知识。图索引需要时间，所以在快速变化的数据上会滞后。
• 小型、简单的文档集合，基础设施成本会盖过收益。
• 研究表明，当数据规模达到 5–15 million tokens 时，性能提升会进入平台期，因为图遍历在超大数据集上会失去区分度。

"GraphRAG 不是更好的 RAG。它是为另一类问题设计的检索方法。"

如果你为简单事实查询去搭建它，那就是花了几千美元的索引基础设施，去回答一个 50 行的向量 pipeline 在 200ms 内就能解决的问题。

Vectorless RAG：当结构胜过相似度

Vectorless RAG 走的是更难的一个方向，它不是在已有的检索模型上加一层图，而是直接发问：如果整个检索模型本身就是错误的起点呢？

PageIndex 是 vectorless RAG 的主要框架，由 VectifyAI 的 Mingtian Zhang 和 Yu Tang 在 2025 年 9 月发布，在 GitHub 上获得了超过 23,000 个 star。它的核心借鉴自 AlphaGo：不要穷举搜索，而是用学到的策略进行智能导航。

传统 RAG 找的是在语义上与 query 相似的 chunk；PageIndex 让 LLM 推理"答案应该在文档结构的哪个位置"，然后直接导航过去。这就是人类专家实际使用文档的方式——打开它，扫一眼目录，去到相关章节，读那张表。

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

这正是专家阅读文档的方式。不是关键词搜索也不是 embedding 相似度。打开报告，扫目录，去到相关章节，读相关表格——PageIndex 教 LLM 做的就是这件事。

由 PageIndex 驱动的 Mafin 2.5 在 FinanceBench 上达到了 98.7% 的准确率。传统 vector RAG 约 50%，无 RAG 的 GPT-4o 约 31%，Perplexity 约 45%。相对 vector RAG 49 个百分点的差距，不是渐进式改进，是另一个量级的结果。

差距这么大的原因有三个：

• Cross-reference following：PageIndex 通过树结构跟踪 "see Appendix G"。向量相似度对文档引用没有任何概念。
• Structure preservation：表格的表头、脚注、单元格关系作为树节点保留下来。chunking 会破坏这些。
• Multi-step reasoning：需要从两个不同章节取数据的问题，由迭代式导航来处理，而不是一次性检索。

PageIndex 也不是通用替代品。它是一种特化工具，适合"准确性高到值得付出更高开销"的场景。

"vectorless" 这个说法引来过质疑：PageIndex"完全是通过对 LLM 的迭代和递归调用来实现的"。它并没有消除依赖，只是把向量近似换成了 LLM 推理近似。两种方式都有成本。

那些 LLM 调用会累积。如果你有数百万份文档而 query 又简单，vectorless RAG 会比 vector RAG 慢、贵，且没有有意义的精度提升。这种开销只有在准确性是首要约束时才划得来。

深度对比

下面是这三种架构在生产环境中真正会出现差异的几个维度：

GraphRAG 和 Vectorless RAG 不是彼此竞争的关系。它们解决的是不同问题。

• GraphRAG 适合需要在大规模文档集合中理解关系的场景。
• Vectorless RAG 适合需要从复杂文档的内部结构中得到精确答案的场景。

2026 年新的生产模式是 Adaptive RAG：一个 query classifier 根据复杂度，把每个 query 路由到合适的 pipeline。简单 query 走 vector RAG（快、便宜）；复杂 query 走 agentic RAG；关系型 query 走 GraphRAG。这样可以达到最优的成本-质量权衡。

实际应用模式

GraphRAG 真正发挥价值的场景，几乎都是关系密集型的：

• 竞争情报："我们所在市场里，哪些公司和我们在评估的物流商也是合作关系？"
• 监管合规：跨司法管辖区映射各项法规之间如何交叉引用
• 研究综合：在数千篇论文中找到任何单篇都未明确指出的关联
• Cedars-Sinai 拥有 1.6 million 条边的阿尔茨海默病研究图，这类医疗应用就是这一方向的早期证据

Vectorless RAG 取胜的地方，是那些"差不多就行"完全不可接受的精度敏感领域：

• 金融分析：来自 SEC 备案的精确数字，50% 准确率的 RAG 系统在这里是危险的
• 法律文档审阅：合同条款抽取，其上下文依赖具有关键作用
• 技术文档：在结构化规范中作答，表格关系很重要的场景
• 任何文档内部结构和文本本身一样有意义的领域

传统 Vector RAG 仍然占优的地方：

• 大型、非结构化的文本集合（博客文章、邮件归档、新闻文章）
• 简单的语义搜索，embedding 相似度能可靠地找到正确内容
• 高吞吐、低复杂度的 query，速度和成本是主要约束
• 原型与早期阶段系统，图索引或树索引的开销暂时不划算

决策框架：哪种架构适合你的问题

在做决定之前可以先回答这四个问题。

用户在问什么样的问题？

• "文档 X 关于 Y 是怎么说的？" → Vector RAG 或 Vectorless RAG
• "A 在所有文档里和 B 是什么关系？" → GraphRAG
• "给我这张表里的精确数字" → Vectorless RAG

准确性有多重要？

• "差不多就行"可以接受 → Vector RAG
• 错误会带来真实后果（金融、法律、医疗） → Vectorless RAG 或 GraphRAG

文档结构是什么样的？

• 非结构化文本、长文章、对话内容 → Vector RAG
• 结构化报告、备案、有内部引用的合同 → Vectorless RAG
• 大型集合，跨文档存在相互关联的实体 → GraphRAG

延迟和成本约束是什么？

• 亚秒级响应、高并发、预算紧 → Vector RAG
• 中等延迟可接受，准确性优先 → Vectorless RAG
• 可接受前期索引成本，需要处理复杂关系 → GraphRAG

目前生产系统实际在做什么

没有任何一种架构能在所有场景里通吃，在做最好的 AI 系统的团队，并不是只挑一种方案而是在做路由。

入口处坐着一个 query classifier。简单的语义问题走 vector RAG；复杂的关系问题走 GraphRAG；结构化文档查询走 vectorless RAG。每个 query 根据自己真正需要什么，找到对应的检索路径。

这比单一 pipeline 更难搭。但在规模化场景下，它准确性更高、成本更低——大多数系统里，绝大部分 query 都是简单的，简单的 query 不需要图遍历或迭代式 LLM 导航的开销。

Adaptive RAG 模式按 query 复杂度做路由：

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

这不是理论，而是认真的工程团队此刻正在向生产环境交付的东西。

总结

那些上线了有问题的 RAG 系统的团队并不是工程能力差。他们正确地使用了 vector RAG。只不过 vector RAG 不是回答用户真正问的那些问题的合适工具。

RAG 已经不再是一种技术而是三种共用一个名字的检索方式。

Vector RAG 是乐观的匹配：找到接近的东西，然后期望它是对的。

GraphRAG 是结构性的映射：在问题到来之前就已经知道关系。

Vectorless RAG 是有意识的导航：推理答案在哪里，而不是基于相似度分数去猜。

理解这一区别的团队，正在搭建一些检索不再是瓶颈的系统。不理解的团队，则在不断打磨 prompt，去掩盖那些一开始就注定无法在复杂场景下工作的检索。

https://avoid.overfit.cn/post/2f4642ffd6f8405aab78e4e3c574620f

by Divy Yadav