企业知识库里，有一类问题很容易把纯向量 RAG 问住：
那个在第三季度报告中被提到的项目负责人，他之前的主管是谁？
系统可能找到第三季度报告，也可能召回包含“项目负责人”的片段，但答案还差一条关系链：先确认这个人是谁，再去另一份材料里查他此前向谁汇报。
如果两条信息被切进不同的 Chunk，文字之间又没有明显的语义重叠，向量检索就可能只交回半截证据。LLM 仍能生成一句通顺的话，只是未必正确。
Meta Intelligence 的资料将 RAG 的提出时间追溯到 2020 年。AWS 对它的解释则更直接：让大语言模型在生成回答前访问训练数据之外的权威知识库，而且不需要重新训练模型。它解决了知识如何接入、如何更新的问题，却不保证散落在多份文档里的关系一定能被找回来。
向量能找近邻，找不到“汇报给”
常见的 Naive RAG 链路并不复杂：文档切片、生成向量、写入 Milvus 或 Zilliz 等向量数据库，再把 top-k 片段交给 LLM。查询制度原文、产品说明，或者某段材料中的明确事实时，这套方法足够直接。
麻烦出现在多跳问题里。
向量检索寻找的是语义近邻，而“项目负责人—此前主管”“合同条款—引用定义”属于明确关系。两段文字在业务上紧密相连，在向量空间里却可能相距很远。用户如果再问“公司目前的整体研发进度”，系统往往只能召回项目 A、项目 B、人员安排等局部材料，很难仅凭相似度拼出完整结构。
一篇可引用的 CSDN 文章将架构分为 Naive RAG（2023）、Advanced RAG（2024）和 RAG 2.0（2026），并给出“准确率从 70% 提升至 95%+”的说法。按这组数字计算，差距至少为 25 个百分点。不过，该摘要没有提供测试集和评测口径，因此只能把它视为该来源的结果，不能当成所有项目的效果承诺。
GraphRAG 换掉的不是向量库，而是索引单位
传统 RAG 主要保存 Chunk 及其向量。GraphRAG 还会从文档中抽取实体、关系和来源位置，把原本散落的信息连起来。
假设两份文档分别写着“张三向李四汇报”和“李四负责 A 项目”，进入图谱后可以表示为：
张三 → 汇报给 → 李四
李四 → 负责 → A 项目
此时，检索不再完全依赖两段文字是否相似。系统可以沿着关系边查找人物、项目和组织之间的连接，再回到对应文档取证。
常见的 GraphRAG 做法还包括社区发现：把联系紧密的实体归到同一主题，并生成不同层级的摘要。面对“整体研发进度”这类全局问题，系统可以先定位相关社区，再调取摘要和原始材料，不必只靠几个孤立片段临时拼接。
但图谱并不会自动解决所有指代。“他”究竟是谁，仍要结合当前对话和原文进行实体对齐。它真正能做的是：身份一旦确认，后续查询可以沿着已经保存的关系继续走，而不是期待相关片段碰巧成为向量近邻。
图谱路径不是证据，答案还得回到原文
一条更稳妥的混合检索链路可以写成：
用户问题 → 向量召回候选文档 → 实体对齐 → 图谱遍历 → 回取原文片段 → LLM 生成答案
向量检索先缩小范围，图谱负责补齐关系，最后再把原始文档和位置交给模型。这个回取步骤不能省。实体抽取、关系识别都有可能出错，如果只把一条图谱路径当作事实，错误也会顺着路径进入最终答案。
查询也没必要全部走图谱。用户只想查看某项制度的原文，直接使用向量检索通常更省事；问题涉及人物关系、合同依赖或跨文档链路时，再调用 GraphRAG。混合方案的重点不是把链路拉长，而是把问题送到合适的检索路径。
建图比查询更费功夫
GraphRAG 的主要成本通常压在索引阶段。系统需要让 LLM 扫描文档，抽取实体和关系，还可能生成不同层级的摘要。文档更新后，相关节点、关系与摘要也要同步调整。
这笔成本很难用固定倍数概括。文档长度、关系密度、摘要层级都会改变 Token 消耗、构建时间和维护工作量。
生产环境可以按材料的重要程度分级处理：
- 高频基础知识和普通说明文档继续使用向量检索；
- 涉及关键人物、合同条款和复杂业务链路的材料再建立知识图谱；
- 内容变化时进行增量抽取和更新，减少全量重建；
- 图谱中的关系始终回连原始文档，保留可核验的出处。
可引用素材还把 Agentic RAG、GraphRAG 和 MCP 并列为 2026 年企业级 RAG 的三类范式。三者并不是同一种组件：GraphRAG 用来组织关系，Agentic RAG 负责选择检索路径，MCP 可以放在工具和数据源接入一侧。全部接入系统，不等于答案自然会变准。
Agent 可以选路，但必须有刹车
Agentic RAG 更像查询路由器。收到问题后，它先判断任务类型：明确事实直接查向量库，跨文档关系进入图谱，证据不足时再改写查询或追加检索。
这种循环可以减少“一次没搜全就开始回答”的情况，也会增加模型调用和接口往返。部署时至少要记录查询改写、召回文档、图谱路径与最终证据，并设置明确的停止条件。否则，所谓自我修正很容易变成反复检索，响应时间和 Token 成本一起上涨。
先看自己的问题集，再决定要不要上图
Milvus、Zilliz 等向量能力仍然适合处理非结构化文本和候选内容召回。知识图谱补充的是实体关系、跨文档路径与全局组织。两者配合时，可以把系统理解为：
向量层 + 知识图 + 更新流
是否值得建设 GraphRAG，取决于真实查询。如果大部分答案都能在单个片段中找到，纯向量方案已经够用。若用户经常追问“谁向谁汇报”“某条款依赖哪份定义”“几个项目之间有什么联系”，图谱才更可能带来实际收益。
还有一个更基础的条件：实体和关系必须能够稳定定义。同一人物在不同文档里有多种写法、关系类型缺少统一规则，GraphRAG 只会把噪声整理成一张成本更高的图。
上线前应使用自己的问题集评测，不要直接套用单篇资料中的 70% 和 95%+。RAG 2.0 真正改变的，也不是把向量数据库撤掉，而是把一部分关系判断从模型的临时猜测，移到可检索、可更新、能回到原文核验的数据层。