用一套向量库搞定多跳问答：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缺乏。"

要回答这个问题，需要：

1. 从问题中识别"2型糖尿病的一线用药"
2. 找到文档A，得知答案是"二甲双胍"
3. 以"二甲双胍"为新的检索词，找到文档B
4. 才能最终组装出完整答案

Naive RAG 在第1步做了向量检索，但问题向量和文档B的相似度很低（问题里没出现"二甲双胍"），所以根本召回不到文档B。这就是多跳问答的本质困难：中间推理节点不在原始问题里。

---

传统解法的代价

方案A：迭代式 RAG（IRCoT）

让大模型一边推理一边检索，像人读书一样，发现知识空缺就去搜索。

问题：LLM 调用次数不可控，3次到10次不等，延迟抖动严重，P99 毫无保障，API 费用爆炸。

方案B：GraphRAG（微软方案）

把所有文档构建成知识图谱，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 调用的秒级延迟比起来，基本可以忽略。

---

性能数据

在三个多跳问答学术基准上，Recall@5 对比如下：

基准	Naive RAG	Vector Graph RAG	提升
HotpotQA（2跳）	90.8%	96.9%	+6.1%
2WikiMultiHopQA（跨文档）	66.4%	94.1%	+27.7%
MuSiQue（2-4跳，最难）	41.6%	73.0%	+31.4%
平均	66.3%	87.8%	+21.5%

平均 Recall@5 达到 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 在不依赖这套复杂设施的情况下：

• HotpotQA：96.9% vs 96.3%（基本打平）
• 2WikiMultiHopQA：94.1% vs 90.4%（领先 3.7%）
• MuSiQue：73.0% vs 74.7%（略逊 1.7%）

总体来说是 “以最简单的基础设施，达到接近 SOTA 的效果”。

---

这套方案适合谁

几个判断条件：

适合用的场景：

• 知识库规模中等（几万到几十万文档），文档之间存在跨段落逻辑关联
• 团队已经在用 Milvus，不想再维护一套 Neo4j
• 需要可控的延迟和成本（2次 LLM 调用，不会突然爆炸）
• 医疗、法律、技术文档等知识密集型问答场景

不太适合的场景：

• 只需要"大意是什么"这类宏观问题（Microsoft GraphRAG 更合适）
• 超大规模知识图谱（亿级实体），Milvus 多次查询的开销会放大
• 已有成熟 Neo4j 基础设施的团队（迁移成本不值得）

---

部署方式（极简）

Vector Graph RAG 支持本地文件模式，最简单的启动方式：

# 克隆项目
git clone https://github.com/zilliztech/VectorGraphRAG
cd VectorGraphRAG

# 安装依赖
pip install -r requirements.txt

# 本地 Milvus Lite 模式（不需要外部服务）
from pymilvus import MilvusClient

client = MilvusClient("./local_graph_rag.db")  # 本地文件模式

# 初始化三张表
rag = VectorGraphRAG(client=client, llm_api_key="your_key")

# 添加文档
rag.add_documents(["你的知识库文档列表..."])

# 提问
result = rag.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