前言

在 RAG 应用开发中,如何存储和检索知识是一个核心问题。向量数据库和图数据库代表了两种截然不同的知识表达范式。本文将深入对比这两种方案,探讨它们的本质差异和适用场景。

向量数据库的兴起

主流向量数据库对比

2023 年是向量数据库的爆发年,主流方案各有特色:

Pinecone (云服务):

  • 完全托管,开箱即用
  • 性能优秀,延迟低(<100ms)
  • 按使用量计费,成本可控
  • 劣势:数据必须上传到云端

Weaviate (开源 + 云):

  • 支持多种向量化模型
  • 内置 GraphQL API
  • 可本地部署或使用云服务
  • 社区活跃,文档完善

Milvus (开源):

  • 高性能,支持十亿级向量
  • 支持多种索引算法(HNSW, IVF, ANNOY)
  • 适合大规模生产环境
  • 部署复杂度较高

Chroma (开源):

  • 轻量级,嵌入式部署
  • Python-first 设计,开发友好
  • 适合原型开发和中小规模应用
  • 性能不如 Milvus/Pinecone

选择建议:

  • 快速原型: Chroma
  • 生产环境: Pinecone(云) 或 Milvus(自建)
  • 混合需求: Weaviate

向量检索的工作原理

向量数据库的核心是 ANN (Approximate Nearest Neighbor) 算法。

暴力搜索的问题:

1
2
3
4
5

# 对每个查询向量,计算与所有向量的距离
for vec in database:
    distance = cosine_similarity(query, vec)
# 时间复杂度: O(N * D),N=向量数量,D=维度
# 百万级向量时不可接受

ANN 算法的权衡:

  • 牺牲一点准确性,换取巨大的速度提升
  • 返回"近似"最近邻,而非"精确"最近邻
  • 实践中准确率可达 95%+,速度提升 100-1000 倍

主流 ANN 算法:

  1. HNSW (Hierarchical Navigable Small World):

    • 构建多层图结构
    • 查询时从顶层快速定位,逐层细化
    • 速度快,准确率高,内存占用大

  2. IVF (Inverted File Index):

    • 先聚类,查询时只搜索相关簇
    • 内存友好,适合大规模数据
    • 准确率略低于 HNSW

  3. Product Quantization:

    • 向量压缩技术
    • 大幅减少内存占用
    • 适合超大规模(十亿级)向量

图数据库的知识表达

Neo4j: 显式建模实体关系

图数据库用**节点(Node)和关系(Relationship)**显式表达知识。

核心概念:

1
2
3

(Person:张三)-[:WORKS_AT]->(Company:阿里巴巴)
(Person:张三)-[:KNOWS]->(Person:李四)
(Person:李四)-[:LIVES_IN]->(City:杭州)

与关系数据库的区别:

  • 关系数据库: 关系隐藏在外键中,需要 JOIN 查询
  • 图数据库: 关系是一等公民,遍历即查询

优势:

  • 关系查询极快(无需 JOIN)
  • 表达能力强(多跳关系、路径查询)
  • 适合社交网络、知识图谱、推荐系统

劣势:

  • 需要预先定义关系
  • 模糊查询能力弱
  • 数据建模成本高

Cypher 查询语言

Cypher 是 Neo4j 的查询语言,表达力极强。

示例 1: 查找朋友的朋友

1
2
3

MATCH (me:Person {name: "张三"})-[:KNOWS]->(friend)-[:KNOWS]->(fof)
WHERE fof <> me
RETURN DISTINCT fof.name

示例 2: 最短路径查询

1
2
3
4

MATCH path = shortestPath(
  (a:Person {name: "张三"})-[:KNOWS*]-(b:Person {name: "王五"})
)
RETURN path

示例 3: 推荐系统

1
2
3
4
5
6
7

// 推荐与我兴趣相似的人喜欢的书
MATCH (me:Person {name: "张三"})-[:LIKES]->(book:Book)<-[:LIKES]-(other:Person)
MATCH (other)-[:LIKES]->(recommendation:Book)
WHERE NOT (me)-[:LIKES]->(recommendation)
RETURN recommendation.title, COUNT(*) AS score
ORDER BY score DESC
LIMIT 10

这种声明式查询在关系数据库中需要复杂的多表 JOIN,而在图数据库中自然直观。

两种范式的本质差异

模糊相似 vs 精确关系

这是两种范式的本质差异:

向量数据库: 模糊相似

1
2
3
4
5

查询: "如何学习编程?"
返回:
  - "编程入门指南" (相似度: 0.89)
  - "学习 Python 的方法" (相似度: 0.85)
  - "程序员成长路径" (相似度: 0.78)
  • 基于语义相似度
  • 不需要精确匹配
  • 能发现隐含关联

图数据库: 精确关系

1
2
3
4

查询: (Person:张三)-[:KNOWS]->(?)
返回:
  - (Person:李四)
  - (Person:王五)
  • 基于显式定义的关系
  • 精确、确定、可解释
  • 需要预先建模

对比表:

维度 向量数据库 图数据库
知识表达 隐式(向量空间) 显式(节点+关系)
查询方式 相似度检索 路径遍历
适用场景 语义搜索、推荐 关系查询、推理
数据建模 简单(只需向量化) 复杂(需定义关系)
可解释性 弱(黑盒) 强(关系明确)
扩展性 优秀 一般

检索效率对比

向量数据库:

  • 查询复杂度: O(log N) (HNSW) 或 O(√N) (IVF)
  • 适合: 百万到十亿级向量
  • 瓶颈: 向量维度(高维度影响性能)

图数据库:

  • 查询复杂度: O(E),E=遍历的边数
  • 适合: 复杂关系查询,多跳路径
  • 瓶颈: 图的稠密度(关系太多时性能下降)

实际性能:

  • 向量检索: 毫秒级(百万向量)
  • 图遍历: 毫秒到秒级(取决于跳数和图规模)

结论: 向量数据库在大规模相似度检索上更有优势,图数据库在复杂关系推理上不可替代。

混合方案: GraphRAG

向量检索 + 图遍历

GraphRAG 试图结合两种范式的优势:

核心思想:

  1. 用向量检索找到相关的起始节点
  2. 用图遍历扩展相关的实体和关系
  3. 综合向量相似度和图结构信息

架构示例:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

用户查询: "张三认识的人中,谁在阿里巴巴工作?"

Step 1: 向量检索
  query_vec = embed("张三认识的人中,谁在阿里巴巴工作?")
  candidates = vector_db.search(query_vec, top_k=10)
  # 找到与"张三"相关的节点

Step 2: 图遍历
  MATCH (person:Person {name: "张三"})-[:KNOWS]->(friend)
        -[:WORKS_AT]->(company:Company {name: "阿里巴巴"})
  RETURN friend.name

Step 3: 结果融合
  # 综合向量相似度和图路径的置信度

优势:

  • 向量检索提供召回能力
  • 图遍历提供精确关系
  • 可解释性更强

挑战:

  • 系统复杂度高
  • 需要维护两套存储
  • 数据一致性问题

实际应用场景

何时需要 GraphRAG?

适合场景:

  1. 金融风控: 需要追踪复杂的关联关系(担保链、股权穿透)
  2. 医疗诊断: 症状→疾病→药物的多跳推理
  3. 法律分析: 案例之间的引用关系和相似度
  4. 企业知识库: 文档相似度 + 组织架构关系

不适合场景:

  1. 简单问答: 只需语义匹配,不需要关系推理
  2. 文档检索: 纯相似度搜索,向量数据库足够
  3. 快速原型: GraphRAG 的建模成本太高

实践建议:

  • 90% 的 RAG 应用用向量数据库就够了
  • 只有在明确需要关系推理时才考虑 GraphRAG
  • 可以先用向量数据库,后期按需引入图数据库

为什么大部分 RAG 选择了向量?

向量数据库成为主流的原因:

1. 开发成本低

  • 无需预先定义关系
  • 文本向量化即可使用
  • 快速迭代,快速上线

2. 语义理解能力强

  • 能理解同义词、近义词
  • 跨语言检索(多语言向量模型)
  • 处理模糊查询

3. 扩展性好

  • 轻松支持百万到十亿级数据
  • 水平扩展简单
  • 云服务成熟(Pinecone, Weaviate Cloud)

4. 与 LLM 天然契合

  • LLM 本身就是向量模型
  • Embedding API 开箱即用
  • 端到端的工作流

图数据库的位置:

  • 不是 RAG 的主流方案
  • 但在特定领域(金融、医疗、法律)不可替代
  • 未来可能是向量+图的混合方案

结论: 向量数据库是 RAG 的默认选择,图数据库是特殊场景的补充。

小结

向量数据库和图数据库代表了两种知识表达哲学:

  1. 向量数据库: 隐式、模糊、语义相似,适合大规模文本检索
  2. 图数据库: 显式、精确、关系推理,适合复杂关系查询
  3. GraphRAG: 混合方案,结合两者优势,但复杂度更高
  4. 实践选择: 90% 场景用向量数据库,特殊领域考虑图数据库

有了存储方案,下一个问题是:如何将文本切块、向量化、检索? 这就是 RAG 工程化实践的核心。