Vector-Graph-RAG-用一套向量库搞定多跳问答无需图数据库

用一套向量库搞定多跳问答Vector Graph RAG 的工程哲学方向AI / RAG工程 / 向量数据库做过 RAG 的工程师大概都被多跳问答折磨过。问一个简单问题——“二甲双胍适合哪类糖尿病患者”——Naive RAG 能直接命中召回率不错。但换成需要两步推理的问题——“治疗2型糖尿病的一线用药有哪些副作用”——你先要找到二甲双胍是2型糖尿病的一线用药再从另一段文本找到二甲双胍的副作用包括……两步之间需要推理桥梁纯向量相似度检索完全没有这个能力。业界的标准答案是 GraphRAG引入 Neo4j 这类图数据库把实体和关系存进去用 Cypher 语言遍历图结构。听起来优雅实际部署就是一个字重。2026年4月23日Zilliz 开源了一套叫Vector Graph RAG的方案。它的核心思路是图的逻辑结构可以用向量数据库来承载你不需要一个真正的图数据库。多跳问答到底难在哪先把问题说清楚。问题治疗2型糖尿病的一线用药有哪些副作用 文档A二甲双胍是治疗2型糖尿病的一线用药已被WHO认可。 文档B二甲双胍的常见副作用包括恶心、腹泻长期使用可能导致维生素B12缺乏。要回答这个问题需要从问题中识别2型糖尿病的一线用药找到文档A得知答案是二甲双胍以二甲双胍为新的检索词找到文档B才能最终组装出完整答案Naive RAG 在第1步做了向量检索但问题向量和文档B的相似度很低问题里没出现二甲双胍所以根本召回不到文档B。这就是多跳问答的本质困难中间推理节点不在原始问题里。传统解法的代价方案A迭代式 RAGIRCoT让大模型一边推理一边检索像人读书一样发现知识空缺就去搜索。问题LLM 调用次数不可控3次到10次不等延迟抖动严重P99 毫无保障API 费用爆炸。方案BGraphRAG微软方案把所有文档构建成知识图谱Neo4j 存储Cypher 查询。问题需要同时维护向量库 图库两套系统数据同步是噩梦文档更新一次两套系统都要重建Leiden 算法构建社区图谱索引阶段就贵得离谱团队要学 Cypher运维要处理两套扩缩容最终结论GraphRAG 更适合回答这份数据大概讲了什么这类宏观问题而不是精确的多跳推理。Vector Graph RAG 的设计Zilliz 的思路可以用一句话概括图的本质是实体关系的拓扑网络这套结构完全可以用关系型 ID 引用 向量化来实现不需要专门的图数据库。数据结构三张 Milvus Collection┌─────────────────┐ ┌──────────────────────┐ ┌──────────────┐ │ Entities │ │ Relations │ │ Passages │ │─────────────────│ │──────────────────────│ │──────────────│ │ id: E001 │◄─────│ subject_id: E001 │ │ id: P001 │ │ name: 二甲双胍 │ │ object_id: E002 │─────►│ text: ...二甲│ │ vector: [...] │ │ predicate: 一线用药 │ │ 双胍...副作用│ │ relation_ids: │ │ passage_id: P001 │ │ ... │ │ [R001, R002] │ │ vector: [...] │ │ vector: [...] │ └─────────────────┘ └──────────────────────┘ └──────────────┘三张表通过 ID 互相引用形成了一个逻辑图谱。实体有向量可以语义搜索关系有向量三元组文本也可以被检索原始段落单独存储用于最终生成答案。检索流程四步走用户提问 │ ▼ ① 种子检索 从问题中提取关键实体在 Entities 表做向量搜索 → 找到2型糖尿病相关实体 │ ▼ ② 子图扩展核心步骤 用实体 ID 查询关联的 relation_ids → 从 Relations 表找到二甲双胍是2型糖尿病的一线用药 → 顺着关系边发现中间实体二甲双胍 │ ▼ ③ LLM 重排一次性 把扩展出的候选关系全部丢给 LLM一次筛选去噪 → 不是让 LLM 反复迭代检索而是一次性判断哪些关系有用 │ ▼ ④ 答案生成 用筛选出的高质量 Passages 喂给 LLM → 生成最终回答子图扩展那一步用的是多次 Milvus 主键查询ID Lookup耗时 20-30ms。跟 LLM 调用的秒级延迟比起来基本可以忽略。性能数据在三个多跳问答学术基准上Recall5 对比如下基准Naive RAGVector Graph RAG提升HotpotQA2跳90.8%96.9%6.1%2WikiMultiHopQA跨文档66.4%94.1%27.7%MuSiQue2-4跳最难41.6%73.0%31.4%平均66.3%87.8%21.5%平均 Recall5 达到 87.8%比 Naive RAG 提升约 19.6 个百分点。在成本方面整个检索过程固定2次 LLM 调用1次重排 1次生成相比 IRCoT 的 3-10 次API 成本降低约 60%速度快 2-3 倍。与 HippoRAG 2 的对比业界目前的 SOTA 是 HippoRAG 2它依赖 ColBERTv2 做密集检索需要额外的向量化基础设施。Vector Graph RAG 在不依赖这套复杂设施的情况下HotpotQA96.9% vs 96.3%基本打平2WikiMultiHopQA94.1% vs 90.4%领先 3.7%MuSiQue73.0% vs 74.7%略逊 1.7%总体来说是“以最简单的基础设施达到接近 SOTA 的效果”。这套方案适合谁几个判断条件适合用的场景知识库规模中等几万到几十万文档文档之间存在跨段落逻辑关联团队已经在用 Milvus不想再维护一套 Neo4j需要可控的延迟和成本2次 LLM 调用不会突然爆炸医疗、法律、技术文档等知识密集型问答场景不太适合的场景只需要大意是什么这类宏观问题Microsoft GraphRAG 更合适超大规模知识图谱亿级实体Milvus 多次查询的开销会放大已有成熟 Neo4j 基础设施的团队迁移成本不值得部署方式极简Vector Graph RAG 支持本地文件模式最简单的启动方式# 克隆项目gitclone https://github.com/zilliztech/VectorGraphRAGcdVectorGraphRAG# 安装依赖pipinstall-rrequirements.txt# 本地 Milvus Lite 模式不需要外部服务from pymilvusimportMilvusClient clientMilvusClient(./local_graph_rag.db)# 本地文件模式# 初始化三张表ragVectorGraphRAG(clientclient,llm_api_keyyour_key)# 添加文档rag.add_documents([你的知识库文档列表...])# 提问resultrag.query(治疗2型糖尿病的一线用药有哪些副作用)print(result)整个部署下来没有 Neo4j、没有额外的图遍历服务就是一个 Python 文件 一个 SQLite 风格的 Milvus Lite 文件。个人思考这套方案让我想到一个老问题我们真的需要图数据库还是只需要图的思维Neo4j 的核心能力是图遍历算法BFS/DFS/最短路径这些在真正的知识图谱应用比如金融反欺诈的关系链追踪里确实不可替代。但在 RAG 场景里我们需要的其实只是找到相关实体然后沿着关系跳跃一层或两层——这个操作用 ID 查询完全可以模拟压根不需要图遍历算法。Zilliz 这次做的事情本质是把系统复杂度换成了数据建模的复杂度不需要维护图数据库但需要在数据入库时仔细设计三元组的抽取和关系建模。这个权衡对于大多数工程团队来说是值得的——代码复杂度可以封装系统复杂度很难封装。对于正在做 RAG 工程的同学这套方案值得认真评估。参考资料Zilliz Blog - “Vector Graph RAG Without a Graph Database”发布于2026-04-23