Neo4j

一句话

图数据库——存的是实体和关系，不是行和列。 查「A 和 B 什么关系」比传统 SQL 快几个数量级。

核心概念

(张三) -[:认识]-> (李四) -[:就职于]-> (某公司) -[:位于]-> (杭州)
  │                                        │
  └────────:同学────────────────────────────┘

• 节点（Node）：实体，如人、公司、城市
• 关系（Relationship）：实体之间的连线，如 认识、就职于
• 属性（Property）：节点和关系上挂的键值对

为什么需要它（在 RAG 场景中）

传统 RAG 用向量检索文档片段，擅长回答「XX 是什么」。但遇到需要多跳推理的问题就吃力了：

「张三的同事的同学的公司在哪个城市？」

这个问题需要在关系网络上跳 4 跳。用 SQL 写是灾难级的 self-join，用 Neo4j 的 Cypher 查询一行搞定：

MATCH (a:人 {name:'张三'})-[:同事]-(b)-[:同学]-(c)-[:就职于]->(d:公司)-[:位于]->(e:城市)
RETURN e.name

应用场景

场景	说明	典型查询
知识图谱问答	实体间多跳关系推理	「珍珠奶茶里的珍珠用什么工艺制作？」
推荐系统	基于关系的协同推荐	「和 A 用户相似的人也买了什么？」
反欺诈	交易网络中的异常环路检测	「是否存在资金环形流转？」
供应链追溯	产品 → 原料 → 供应商的链路追踪	「这批零件来自哪个工厂、经过哪些中转？」
组织架构分析	公司/团队/人员的层级关系	「张三的上级链的所有人是谁？」

横向对比

	MySQL/PostgreSQL	ES	Milvus	Neo4j
数据模型	表（行+列）	文档（JSON）	向量（浮点数组）	图（节点+关系）
核心能力	事务、聚合、JOIN	全文检索、倒排索引	语义相似度搜索	多跳关系推理
查询语言	SQL	DSL / ES	QL	向量 API
多跳查询	🔴 多层 JOIN 灾难	🔴 不支持	🔴 不支持	🟢 天然适合
关键词匹配	🟡 LIKE 慢	🟢 BM25	🔴 不支持	🔴 不支持
语义搜索	🔴 不支持	🔴 不支持	🟢 核心能力	🔴 不支持

优缺点

优点：

• 多跳关系查询是原生 O(1) 沿边跳转，对比 SQL 的多次 JOIN 是质的飞跃
• 数据模型更直观——现实世界本来就是「实体+关系」的网状结构
• Cypher 语法表达力强：(A)-[:关系]->(B)-[:关系]->(C) 一眼看懂

缺点：

• 学习曲线陡——Cypher 和 SQL 的思维模型完全不同（关系优先 vs 表优先）
• 不适合海量文本全文检索（那是 ES），不适合语义模糊匹配（那是 Milvus）
• 图谱质量决定回答质量——垃圾图谱 = 垃圾回答。构建高质量知识图谱本身是一门工程

如何选择

你要解决的问题是——
├─→ 「文档里有没有提到 X 这个词？」 → ES
├─→ 「哪些内容和这个意思差不多？」   → Milvus
├─→ 「A 和 B 有什么关系？经过什么路径？」 → Neo4j
└─→ 「不确定，用户可能问各种类型」   → Agentic RAG（让 LLM 帮你路由）

核心判断标准：如果你的查询里出现了「谁的」、「什么关系」、「经过什么路径」、「跳几层」 —— 用 Neo4j。如果只是「是什么」、「怎么做」 —— 用传统 RAG。

小结

Neo4j 补齐了 RAG 体系中最薄弱的环节——关系推理。ES 管词条、Milvus 管语义、Neo4j 管关系，三者各司其职，组合起来才是完整的检索能力矩阵。一个前端转全栈的学习者，不需要成为图数据库专家，但需要能判断「这个问题该不该用图来解」。

下一步

• GraphRAG — 在图谱上做 RAG 的完整方案
• Cypher — Neo4j 的查询语言速览