Graph RAG 的瓶颈不只在扩图：两阶段 Jev 怎样筛出可用证据

多跳问题常常把答案拆在几份材料里：问题问药物副作用，却没有给出药名；问合同责任，却没有写出相关条款。Zilliz 的 Vector Graph RAG 把这些关系和原文都存进 Milvus，再用 Jev 分两轮筛选关系与证据段落。项目方在 MuSiQue、2Wiki 各 1,000 道题上报告两阶段 Jev 1.14 的平均 Recall@5 为 86.61%；这个数字值得追问它测了什么，也值得和真实知识库的端到端质量区分开来。

要点

• Vector Graph RAG 不要求单独部署图数据库：Milvus 同时保存实体、关系和来源文本，向量搜索负责找起点，ID 关联负责展开候选子图。
• Jev 1.13 两阶段配置在项目报告的 2,000 道多跳问题上达到 86.07% Recall@5；1.14 报告 86.61%，但独立分析指出后者约 4.9 秒的 API 时延是基于小样本校准的估算。
• 这个测试衡量的是检索阶段能否把证据放进前五名，不是生成答案的正确率，也不等于用户自己的语料、索引成本和整体响应时间。

两轮分别筛什么

Vector Graph RAG 的第一步不是让大模型直接回答问题，而是把问题映射到语料里已有的实体和关系。建库时，项目从文档抽取三元组，保留实体、关系及其原文，再写入 Milvus。查询时先用向量搜索找可能相关的节点与边，顺着关联 ID 扩展出一批候选关系。传统图检索的难处由此出现：扩得少会漏掉跨文档的桥接线索，扩得多则会把主题相近、实际无助于回答的关系一并捞上来。

第一阶段 Jev 判断哪些关系值得继续追踪。它给候选关系打分，保留能回答问题的连接，也可能保留通往答案的中间关系。随后系统取回这些关系指向的原文片段，并把普通向量检索直接命中的片段合并进来、去重。第二阶段 Jev 面对的是文本证据而非图边：它根据问题把真正包含答案所需信息的段落排到前面，再交给后续生成模型。

这两个判断对象并不相同。图边可能值得沿着走，但边对应的长文段落不一定与当前问题相关；反过来，直接向量搜索也可能找到没有进入图结构的有用原文。把两类候选合并后再排，设计目标是同时减少「图上走错路」和「找到了关系却引用错段落」。代价也很明确：关系抽取和建库仍需生成模型，查询时又多出两轮决策模型调用。它减少的是候选筛选的盲目成本，不是把 Graph RAG 变成零模型或零延迟系统。

86.61% 代表什么

公众号文章介绍的公开测试使用 MuSiQue 与 2Wiki 两个多跳问答数据集，各 1,000 道题，并以 Recall@5 比较候选证据覆盖。项目评测与 Zilliz 的说明列出多种对照：普通向量检索、HippoRAG 2、单阶段 Jev，以及由 GPT-6 Luna、DeepSeek V4.1 Flash 等模型参与的重排配置。项目发布的 Jev 1.13 单阶段结果为 80.04%，加入第二阶段后为 86.07%；Jev 1.14 两阶段报告为 86.61%。这些是项目方报告的结果，读者应将它们视为待按自己的数据复测的基线，而非跨语料承诺。

配置	平均 Recall@5	报告中的额外模型 API 时间	数据来源与限制
Jev 1.13 单阶段	80.04%	2.28 秒	项目方结果
Jev 1.13 两阶段	86.07%	3.13 秒	项目方结果；独立分析讨论了完整两阶段方案
Jev 1.14 两阶段	86.61%	约 4.9 秒	项目方结果；时延为小样本校准估算
GPT-6 Luna 重排	82.70%	5.35 秒	项目对照结果
DeepSeek V4.1 Flash 重排	83.34%	10.97 秒	项目对照结果

数据来源：Vector Graph RAG 的评测说明、Zilliz 的技术文章及独立评测分析，均围绕同一项目实验；时延不是端到端请求时间。不同版本、数据集、生成模型和检索配置不能混作同一张无条件排行榜。

Recall@5 只回答一个窄问题：标注为相关的证据有没有进入系统前五条候选？它不回答最终答案是否完整、引用是否正确、回答是否忠实，也不包含从原始文档抽取实体关系的准确率。一个系统可以把证据排进前五，却仍在摘要、冲突消解或答案归因上失败。因此「超过 LLM 重排」应限定为该项目报告的这组数据与配置，而不是对所有 Graph RAG、所有大模型或生产知识库的普遍判断。

独立分析（2026-10-22）为这些数字补上了重要的阅读提示：Jev 1.14 的 86.61% 与时延估算 配有约 4.9 秒估算时延，作者说明估算基于小样本校准；Jev 1.13 的两阶段收益也来自完整方案，包括额外的直接段落召回，不能据此把全部提升单独归因于「第二次排序」。同一作者较早在另一组设置上评测，曾观察到单阶段 Jev 在更难多跳题上的差距。评测版本和题集不同，前后结果不能直接合并；它们共同说明，重排器效果依赖候选集质量、问题难度与具体配置。

不用图数据库的取舍

「Graph RAG 一定需要图数据库」并不成立，但也不能把「图数据存在向量数据库」读成「向量数据库原生提供图遍历」。Milvus 的官方 Graph RAG 教程同样展示了由向量搜索召回起点、再在应用侧通过邻接关系扩展的做法。Vector Graph RAG 的设计把实体、关系和原文放在同一向量存储体系中，再以 ID 关联完成检索路径，目标是减少额外基础设施和部署维护。

对现有 Milvus 用户，这种结构可能让试验门槛更低：少一套图数据库，默认 Milvus Lite 还能用本地文件起步。对已有成熟图平台、需要复杂遍历或细粒度图约束的团队，换成向量检索加 ID 关联未必更简单；还要看关系更新、索引一致性、并发与可观测性。项目文档说明按来源更新与删除支持增量操作，但源数据更新不是跨所有集合的事务原子提交，异常中断后可能需要重试以恢复一致状态。

Graph 扩展本身也不是免费午餐。EMNLP 2026 关于迭代 Graph RAG 的研究指出，朴素地扩大图检索范围可能引入噪声，简单问题未必受益，桥接证据仍可能难以找到。Vector Graph RAG 的两阶段筛选试图控制候选膨胀，但能否做到，取决于实际语料中的关系抽取质量、向量召回覆盖率和筛选预算。若文档关系表达不完整，后续排序器无法凭空补出缺失边。

这里的「不需要图数据库」也不代表「建库不花钱」。官方快速开始仍依赖 OpenAI API 默认配置；文档抽取、实体关系抽取、向量化和最终回答会消耗模型或嵌入服务资源。Jev 的关系筛选与段落重排是另一条服务依赖。读者应把总拥有成本拆成存储与运维、离线抽取、向量检索、每次查询的筛选调用和最终生成，而不是只比较查询时的两三秒数字。

先用自己的问题验收

Vector Graph RAG 适合答案需要跨材料拼接、关系路径能描述清楚、并且候选关系数量高到普通向量检索容易漏证据的场景。它不是所有知识库的默认升级。若常见问题的答案都在单个段落里，先用普通向量检索建立基线，再增加图关系和两阶段排序，才能知道额外复杂度是否换来可见收益。

一轮实测至少应同时记录四类结果：第一，证据召回，关注 Recall@5 或更贴近产品的召回指标；第二，答案质量，人工检查正确性、完整性和引用是否支撑答案；第三，端到端成本，包括抽取失败率、索引更新时间、每问模型调用与总时延；第四，稳定性，检查资料更新或删除后关系、原文与向量是否一致。把简单题、多跳题、缺边题、冲突资料和无法回答题分开统计，避免总体平均数掩盖失败类型。

可以先从几十个真实问题开始：为每题标注必要证据，分别跑普通向量、单阶段 Jev 和两阶段 Jev，固定模型版本与候选数；随后对结果盲审，而不是只比较项目 README 的数字。若两阶段方案只改善了候选召回，却没有让答案与引用更可靠，用户未必会感受到收益。若最难的问题确实需要跨文档桥接，而召回提升能稳定复现，再投入更完整的增量更新、监控和权限设计。

把公开数据迁移到自己的验收集时，先把每道问题需要的证据片段列出来，再记录系统在每个阶段的命中情况：实体有没有被识别，关系有没有进入候选，原文是否取回，最终段落是否排进前五。这样能分辨改进来自关系扩展、直接向量召回，还是第二阶段排序，也能避免只看最终答案猜原因。若问题答案由同一段明确陈述，额外扩图可能只是增加候选和调用；若答案跨资料、依赖中间实体，才更能检验第一阶段是否找对桥接关系。

更新路径也应该单独验收。Vector Graph RAG 文档提供按来源更新和删除的接口，适合把一份资料替换或撤下；但项目说明这些写入不是跨所有集合的事务提交。上线前可专门测试「中断后重试」「删除来源后查询」「重复导入同一来源」三个情况，确认文本、关系与向量是否仍对应同一版本。还应记录一次完整查询的调用次数、各阶段耗时和失败重试，而不只保存平均延迟。对于含权限分区的内部知识库，来源权限如何映射到实体、边和检索结果，也需要项目使用方在应用层验证，不能仅凭同库存储就推断访问控制已自动解决。

这套检查能把「效果提升」拆成可处理的工程问题：如果实体漏抽，先改抽取或清洗；如果起点命中却扩不出桥接边，检查关系覆盖和遍历策略；如果原文已取回但排名靠后，再评估 Jev 阶段二；如果检索证据准确但答案错误，问题已转到生成与引用。每个环节分别记账，才能决定是否值得承担图结构带来的额外索引和维护工作。

还要固定评测边界：同一批文档、同一切分方式、同一生成模型和相同的 top-k，避免把输入条件变化误认成检索器进步。若换了语料或 Jev 版本，应另建结果行，不把新旧数字直接平均。对业务团队而言，最有用的比较不是论文表里谁的均值最高，而是系统在自己的高价值问题上能否稳定找到同一组证据、在无答案时能否明确 abstain，以及资料改动后能否及时反映到检索结果。

我们的判断是，Vector Graph RAG 最值得关注的不是「又有一个 Graph RAG 框架」，而是把两种筛选明确分工：先决定沿哪些关系走，再决定引用哪些原文。它让关系检索的质量—延迟权衡更容易被测量，也让盲点更清楚：官方基准只覆盖指定数据和候选设置，独立复现与真实语料验收仍不可省略。可先读本站的 Vector Graph RAG 项目页了解安装，再与 SAG-Wiki和 LEANN对照不同 RAG 系统削减成本的方式。