简要回答
Vector RAG 用纯向量检索，适合简单语义相似度查询；GraphRAG 用图结构（知识图谱/实体关系图），适合多跳推理和实体关系查询。ICLR 2026 基准验证：多跳推理 GraphRAG 优于 Vector RAG，简单语义相似度 Vector RAG 更优。选型判据是数据是否有明确实体关系结构、是否需要多跳推理。实际生产常采用混合方案。
标准回答
一、Vector RAG 的原理与适用场景
Vector RAG 将文档切块后 embedding 到向量空间，查询时用 ANN 检索最相似的块。优势：部署简单（向量库即可）、生态成熟（LangChain/LlamaIndex 默认支持）、适合简单语义相似度查询。劣势：无法处理实体关系、不支持多跳推理。典型场景：FAQ 检索、文档摘要、语义搜索。
二、GraphRAG 的原理与适用场景
GraphRAG 将文档中的实体和关系抽取为知识图谱，查询时沿图结构遍历。优势：天然支持多跳推理（A→B→C）、实体关系查询、结构化回答。劣势：需要实体抽取和图谱构建（成本高）、查询延迟可能更高。典型场景：竞品分析、供应链关系查询、合规审计链。
三、ICLR 2026 基准验证
VentureBeat 报道的 ICLR 2026 基准测试给出了明确的场景边界：多跳推理（如"A 的同事 B 在哪家公司工作"）GraphRAG 显著优于 Vector RAG；实体关系查询（如"X 产品的竞争对手有哪些"）GraphRAG 优于 Vector RAG；简单语义相似度（如"总结这篇文档"）Vector RAG 更优且更快。
四、选型决策树与混合方案
四步决策树：数据是否有明确实体关系结构？→ 否：Vector RAG；是否需要多跳推理？→ 否：Vector RAG；查询是否涉及实体关系？→ 否：Vector RAG；以上都是 → GraphRAG 或混合方案。多数企业采用混合方案——GraphRAG 处理关系查询，Vector RAG 处理语义搜索，用 Loop Engineering 管理长会话中的子 Agent 路由。
常见误区
⚠️ 常见踩坑
误区一：认为 GraphRAG 全面优于 Vector RAG。实际简单语义相似度场景 Vector RAG 更快更简单，GraphRAG 的图谱构建成本远高于 Vector RAG 的 embedding。
误区二：忽略图谱构建成本。GraphRAG 需要实体抽取和关系抽取，构建成本远高于 Vector RAG 的简单 embedding，且图谱需要持续维护以保持时效性。
误区三：认为两者互斥。实际生产常混合使用，各取所长——Vector RAG 处理 80% 的简单查询，GraphRAG 处理 20% 的复杂关系查询。
追问
追问 1：GraphRAG 的实体抽取和图谱构建有哪些主流方案？成本如何？
追问 2：如何设计混合 RAG 架构，让 GraphRAG 和 Vector RAG 协同工作？
查询路由层设计：用轻量分类器（BERT-base 或规则）判断查询类型——语义搜索（"总结这篇文档"）→Vector RAG，关系查询（"A 的同事在哪工作"）→GraphRAG，混合查询→两路并行后合并。共享 embedding 层：Vector 索引和 Graph 索引共享同一套 embedding 模型，减少重复计算和存储。结果融合策略：两路结果按置信度加权合并（Vector 结果权重 0.6，Graph 结果权重 0.4），GraphRAG 结果补充实体关系上下文（如 "A 的同事 B" 补充 B 的公司信息）。缓存优化：高频查询结果缓存到 Redis，Graph 查询结果缓存到内存图（如 NetworkX），减少重复计算。
🔗 相似问题
同一考点的不同问法，换着练更稳
延伸学习
按主题分类的相关资源，便于系统复习