TigerVector: Supporting Vector Search in Graph Databases for Advanced RAGs

本文介绍了 TigerVector，这是一个集成于 TigerGraph 原生图数据库中的系统，通过扩展顶点属性类型、构建 MPP 向量索引框架以及增强 GSQL 查询语言，实现了向量搜索与图查询的高效融合，从而显著提升了混合搜索能力、可扩展性及性能。

要点

这篇文章介绍了一个名为 TigerVector 的新系统，它是由普渡大学和 TigerGraph 团队共同开发的。为了让你轻松理解，我们可以把整个故事想象成升级一家超级图书馆。

1. 背景：为什么我们需要这个新系统？

想象一下，现在的**大语言模型（AI）**就像一位博学但有点“死脑筋”的图书管理员。

• 传统的做法（向量数据库）： 管理员手里只有一本“关键词索引本”。如果你问“关于猫的故事”，他只能根据“猫”这个词去翻书。但他不知道“猫”和“狗”是邻居，也不知道“猫”在“公园”里遇到了“狗”。这导致他找到的书往往不够精准，甚至答非所问。
• 图数据库的做法（GraphRAG）： 管理员手里有一张巨大的“关系地图”。他知道谁和谁认识，谁和谁有关联。这能帮他理解复杂的上下文，比如“那个喜欢猫的人，他的朋友是谁”。

痛点： 以前，如果你想让管理员既懂“关键词”又懂“关系图”，你得给他配两个助手：一个专门管关键词（向量库），一个专门管关系图（图数据库）。

• 问题： 这两个助手各干各的，数据要跑来跑去（数据孤岛），而且他们经常对不上号（数据不一致）。比如，关键词助手说“这是张三写的”，关系图助手说“张三没写过”，这就很尴尬。

2. TigerVector 是什么？

TigerVector 就是把这两个助手合并成了一个“超级全能管理员”，并且让他住进了同一个办公室（TigerGraph 数据库）。

它不再让数据在两个系统间搬运，而是直接在同一个地方，既支持关键词搜索（向量搜索），又支持关系推理（图查询）。

3. 它是如何工作的？（核心黑科技）

为了让这个“超级管理员”既快又准，TigerVector 用了几个聪明的招数：

🏗️ 招数一：把“书”和“书皮”分开存（解耦存储）

• 比喻： 想象一本书，里面的文字（普通属性，如作者、标题）很轻，但书皮上贴了一张巨大的、复杂的“全息地图”（向量数据，如内容的语义）。
• 做法： 以前，大家把地图和文字硬塞在一起，找地图时得把整本书都翻一遍，很慢。TigerVector 把“全息地图”单独拿出来，放在一个专门的“地图仓库”里，但通过编号和原来的书一一对应。
• 好处： 找地图时，直接去地图仓库，不用翻文字书，速度飞快；而且更新地图时，不会弄乱原来的文字。

🚀 招数二：千人千面，同时开工（MPP 并行架构）

• 比喻： 以前图书馆只有一个管理员，你让他找 1 亿本书，他得累死。
• 做法： TigerVector 把图书馆分成了几千个小隔间（分区），每个隔间都有一个管理员（计算核心）。当你问问题时，所有管理员同时在自己的隔间里找，最后把结果汇总。
• 好处： 就像让 1000 个人同时找书，速度比一个人快几百倍。

🧩 招数三：一张嘴说两种语言（GSQL 语言增强）

• 比喻： 以前你要找书，得先对管理员说“我要找关于猫的书”（向量搜索），然后拿着结果去问另一个管理员“这些书里哪本是张三写的”（图查询）。
• 做法： TigerVector 发明了一种新语言（GSQL 的扩展），你可以直接说：“帮我找张三写的、关于猫的、最像‘可爱’这个词的书。”
• 好处： 一句话搞定，不用在两个系统间跳来跳去，还能把“找书”和“找关系”完美融合。

4. 它有多厉害？（实验结果）

作者把 TigerVector 和其他几个著名的“图书馆”做了比赛：

• 对手 A（Neo4j）： 老牌图数据库，现在也加了向量功能。
  • 结果： TigerVector 比它快 3 到 5 倍，而且找得更准。
• 对手 B（Amazon Neptune）： 亚马逊的云服务，功能很强但很贵。
  • 结果： TigerVector 在便宜 22 倍的硬件上，跑得比它快 2 倍，效果还一样好。
• 对手 C（Milvus）： 专门做向量搜索的“特种兵”，速度极快。
  • 结果： TigerVector 竟然能和它打成平手，甚至在某些情况下更快！

5. 这对我们意味着什么？

简单来说，TigerVector 的出现，让AI 变得更聪明、更懂上下文，而且成本更低。

• 以前： 你想让 AI 分析“某位客户在所有社交媒体上对某款产品的负面评价”，AI 可能只能找到几篇带“负面”关键词的文章，漏掉了很多隐含的抱怨。
• 现在： 有了 TigerVector，AI 可以瞬间找到所有相关的人，顺着他们的关系网，把那些没有直接说“负面”但意思相近的评论都挖出来，还能把这些评论和具体的产品、时间、地点串联起来。

总结一句话：
TigerVector 就像给数据库装上了“透视眼”和“超级大脑”，让它在处理海量数据时，既能看清细节（向量搜索），又能看懂全局关系（图搜索），而且不用花双倍的钱去养两个系统。这对于未来构建更智能的 AI 应用（比如更精准的医疗诊断、更懂你的购物助手）来说，是一个巨大的进步。

技术摘要

TigerVector 技术总结：面向高级 RAG 的图数据库向量搜索支持

1. 研究背景与问题定义

背景：
检索增强生成（RAG）技术通过从外部数据源检索相关上下文来增强大语言模型（LLM）的准确性。目前的 RAG 主要依赖向量数据库（如 Milvus），但纯向量搜索在复杂应用场景中存在局限：

• 关系缺失： 无法捕捉数据对象之间准确的语义关系。
• 提示命中率低： 检索到的上下文可能与用户查询不完全对齐，导致需要多次迭代调用 LLM，增加延迟和成本。
• GraphRAG 的兴起： 为了解决上述问题，基于图数据库的 GraphRAG 被提出，利用图结构存储知识图谱。然而，现有的图数据库在向量搜索支持上存在不足。

核心问题：
如何在图数据库系统中高效地支持向量搜索，实现“向量 + 图”的混合搜索（VectorGraphRAG），同时解决以下挑战：

1. 性能挑战： 向量数据在图数据库中通常不是“一等公民”，难以达到专用向量数据库（如 Milvus）的性能。
2. 可用性挑战： 缺乏统一的查询语言来支持纯向量搜索、过滤向量搜索以及基于图模式的混合搜索。
3. 更新挑战： 需要支持事务一致且高效的向量数据更新（插入、删除、修改），且不影响图数据。
4. 管理挑战： 如何高效管理多种类型的向量嵌入（如文本、图像）。

现有方案的局限性：
现有的图数据库（如 Neo4j, Amazon Neptune）虽然开始支持向量搜索，但存在性能低下、不支持高级搜索（如过滤搜索、混合搜索）、更新非原子性、缺乏多嵌入类型支持等问题。

---

2. 方法论与系统设计

TigerVector 是集成在 TigerGraph（一种大规模并行处理 MPP 原生图数据库）中的新系统，旨在无缝融合向量搜索与图查询。

2.1 核心架构设计

• 解耦存储（Decoupled Storage）：
  • 将向量嵌入（Embeddings）与其他图属性（如 ID、名称）的存储分离。
  • 向量数据存储在独立的“嵌入段（Embedding Segments）”中，而图数据存储在“顶点段（Vertex Segments）”中。
  • 优势： 减少数据复制，优化磁盘 I/O，允许独立管理向量索引，避免向量更新拖慢图数据重建（Vacuum）过程。
• MPP 架构利用：
  • 利用 TigerGraph 的 MPP 特性，将图和向量数据按顶点段分区。
  • 每个嵌入段拥有独立的向量索引（HNSW）。
  • 查询时，任务分发到多个节点并行执行本地搜索，最后由协调器合并结果，最小化网络通信开销。
• 事务与更新机制（MVCC-based）：
  • 采用多版本并发控制（MVCC）处理向量更新。
  • 两阶段 Vacuum 流程：
    1. Delta Merge： 将内存中的向量增量（Deltas）刷写到磁盘文件。
    2. Index Merge： 将增量文件合并到向量索引快照中。
  • 支持原子更新，确保向量更新与图属性更新的事务一致性。

2.2 数据模型与查询语言增强

• Embedding 数据类型：
  • 引入新的 EMBEDDING 数据类型，替代简单的 LIST<FLOAT>。
  • 管理元数据：维度、模型类型、距离度量、索引类型等。
  • 支持嵌入空间（Embedding Space）：允许同一模型生成的多个顶点类型共享相同的 Schema 定义。
• GSQL 语言扩展：
  • 声明式向量搜索： 扩展 ORDER BY ... LIMIT 语法，引入 VECTOR_DIST 关键字。
  • 高级搜索支持：
    • 过滤向量搜索： 结合图属性过滤（Pre-filter 策略）。
    • 基于图模式的向量搜索： 在特定的图遍历路径上执行向量搜索。
    • 向量相似度连接（Vector Similarity Join）： 在图模式定义的两组节点间寻找最相似的点对。
  • VectorSearch() 函数： 提供灵活的程序化接口，可接受顶点集变量作为输入（过滤），返回顶点集变量作为输出，支持查询块组合（Query Composition）。

---

3. 主要贡献

1. TigerVector 系统： 首个在分布式图数据库（TigerGraph）中深度集成高效向量搜索的系统，实现了向量与图数据的统一管理。
2. 高性能 MPP 索引框架： 通过解耦存储和分段索引设计，实现了与专用向量数据库（Milvus）相当甚至更优的性能，同时远超现有图数据库。
3. 统一的混合查询语言： 通过增强 GSQL，支持纯向量、过滤向量、图模式向量搜索及相似度连接，无需在多个数据库间切换。
4. 事务一致性更新： 设计了基于 MVCC 的增量更新机制，解决了向量索引更新与图数据更新之间的冲突，保证了 ACID 属性。
5. 多嵌入类型支持： 通过 Embedding 类型和 Embedding Space 概念，灵活支持不同模型生成的多种向量数据。

---

4. 实验结果

实验在 SIFT100M/1B 和 Deep100M/1B 数据集上进行，对比对象包括 Neo4j、Amazon Neptune 和 Milvus。

• 向量搜索性能：
  • 对比 Neo4j： TigerVector 的吞吐量高出 3.77 倍至 5.19 倍，召回率（Recall）高出 23% 至 26%。
  • 对比 Amazon Neptune： 在硬件成本仅为 Neptune 的 1/22.42 的情况下，吞吐量高出 1.93 倍至 2.7 倍，且保持相似的召回率。
  • 对比 Milvus（专用向量库）： TigerVector 实现了 1.07 倍至 1.61 倍 的更高吞吐量，证明了在图数据库内集成向量搜索不会牺牲性能，甚至因 C++ 实现和 MPP 架构而更具优势。
• 可扩展性：
  • 随着节点数量增加，吞吐量呈线性增长（8 节点时性能提升显著）。
  • 数据规模从 1 亿扩展到 10 亿（10 倍），在保持高召回率下，QPS 仅下降约 10%，显示出极佳的线性扩展能力。
• 索引构建与更新：
  • 索引构建时间比 Neo4j 快 5.2 倍至 6.8 倍，比 Milvus 快 1.86 倍至 2.16 倍。
  • 增量更新机制高效，仅在更新比例超过 20% 时建议重建索引。
• 混合搜索（Hybrid Search）：
  • 在 LDBC-SNB 基准测试的混合查询中，向量搜索部分通常在毫秒级完成，证明了图遍历与向量搜索结合的高效性。

---

5. 意义与展望

• 推动 Advanced RAG 发展： TigerVector 为构建 VectorGraphRAG 提供了理想的基础设施，能够同时利用向量语义和图结构关系，显著提升 LLM 的回答质量和上下文相关性。
• 消除数据孤岛： 统一系统消除了向量数据与图数据之间的移动，降低了数据一致性维护成本，简化了访问控制。
• 通用性启示： 虽然基于 TigerGraph 构建，但其解耦存储、分段索引、MVCC 更新等设计决策对其他图数据库（如 Neo4j, Neptune）具有普适的参考价值。
• 落地应用： TigerVector 已集成至 TigerGraph v4.2（2024 年 12 月发布），并开放社区版下载，标志着图数据库在 AI 时代的重要演进。

总结： TigerVector 成功解决了在图数据库中高效支持向量搜索的难题，通过创新的架构设计和语言扩展，实现了性能、功能与一致性的平衡，为下一代基于 LLM 的数据检索应用奠定了坚实基础。