开篇一个根深蒂固的联想每次有人提知识图谱紧接着的一句话几乎一定是“那我们用 Neo4j 吧。”好像知识图谱和图数据库是绑定的。上了知识图谱就必须上图数据库不上图数据库就不算知识图谱。这是一个被混淆了十年的概念。知识图谱是怎么组织数据的决策图数据库是存在哪里的选型。它们是两个正交的维度可以自由组合。本文做两件事用一个 SQL 例子证明知识图谱可以存在 MySQL 里跑得好好的给出什么时候才真正需要图数据库的判断标准读完你能分清数据组织方式和存储介质不再被上了知识图谱就得用图数据库带偏。一、知识图谱 vs 图数据库两个正交维度所有存记忆/存知识的方案都可以从两个正交维度去看维度 1存什么形态数据组织方式 - 原始消息ChatMessage日志形态 - 结构化条目有 type / subject / status 等元数据 - 向量嵌入embedding一串数字 - 知识图谱节点 边有向图 维度 2放哪里存储介质 - 内存Map进程内 - 文件JSONL / SQLite - 关系型数据库MySQL / PostgreSQL - 内存型数据库Redis - 向量数据库Milvus / pgvector / Pinecone - 图数据库Neo4j / Graphiti / Amazon Neptune知识图谱落在维度 1图数据库落在维度 2。知识图谱是一种用图的方式组织数据的形态选择–实体是节点关系是边(用户A) --[对花生过敏]-- (花生) (用户A) --[亲属]-- (用户B) (用户B) --[对坚果过敏]-- (坚果) (花生) --[属于]-- (坚果类)这是怎么组织数据的问题跟存在哪完全无关。图数据库是一种专门存图结构、做图查询的存储介质–它原生存节点和边查询用 Cypher 这种图遍历语言。它们可以自由组合。知识图谱可以存在图数据库里也可以不存在。二、知识图谱可以存在 MySQL 里这是最反直觉但最重要的一点。用两张表就能存知识图谱-- 节点表CREATETABLEkg_node(idVARCHARPRIMARYKEY,typeVARCHAR,-- User / Food / Categoryprops JSON-- 其他属性);-- 边表CREATETABLEkg_edge(from_idVARCHAR,-- 起点to_idVARCHAR,-- 终点typeVARCHAR,-- RELATIVE_OF / ALLERGIC_TO / BELONGS_TOprops JSON-- 边的属性什么时候说的、谁说的);查用户亲属的过敏史用 SQL JOIN 模拟图遍历SELECTf.props-$.contentFROMkg_edge e1-- 用户-亲属JOINkg_edge e2ONe1.to_ide2.from_id-- 亲属-事实JOINkg_node fONe2.to_idf.id-- 事实内容WHEREe1.from_iduserAANDe1.typeRELATIVE_OFANDe2.typeSAIDANDf.props-$.contentLIKE%过敏%;这是知识图谱–节点 边组织数据完整表达了用户-亲属-事实的关联结构。但这不是图数据库–存在 MySQL 里查询用 SQL JOIN没有 Neo4j 什么事。而且它能跑。大多数企业知识图谱就是这么存的没毛病。三、知识图谱可以存在的五种介质不只是 MySQL。知识图谱可以落在很多种介质里介质怎么存知识图谱怎么查适合图数据库原生节点边Cypher 图遍历深度遍历、关系推理关系型 DBnodes 表 edges 表SQL JOIN 模拟图遍历大多数企业知识图谱内存对象引用 邻接表代码遍历小规模图谱文件JSON / RDF / Turtle加载后遍历离线知识图谱导出向量 DB每个节点存一个 embedding向量相似不算真正的图谱查询最后一行要特别注意把知识图谱的节点存在向量数据库里查询只能做找相似节点做不了顺着边推理用户亲属的过敏史查不出来。向量数据库不是知识图谱的正确存储介质–这是个常见的误用。四、什么时候才真正需要图数据库知识图谱存在 MySQL 里能跑但有一个会爆炸的问题图遍历深度变深时SQL JOIN 的性能急剧下降。1 跳用户 - 他说过的事实 - 1 次 JOIN毫秒级 2 跳用户 - 亲属 - 亲属说过的事实 - 2 次 JOIN毫秒级 3 跳用户 - 亲属 - 亲属的同事 - 同事说过的事实 - 3 次 JOIN开始慢 5 跳以上多表 JOIN 爆炸 - MySQL 扛不住 - 这时候需要图数据库为什么关系型 DB 的 JOIN 是笛卡尔积每次 JOIN 都要把两表的行数相乘。5 跳意味着 5 次 JOIN复杂度是 O(表大小^5)–百万行表的 5 次方是 10^30宇宙毁灭都查不完。图数据库用邻接表索引图遍历的复杂度是 O(分支因子^深度)跟表大小无关只跟图的局部结构有关。加上索引优化5 跳查询实测毫秒级。Neo4j 查 5 跳O(分支因子^深度)索引优化后毫秒级 MySQL 查 5 跳5 次 JOINO(表大小^5)爆炸这就是图数据库存在的唯一理由深度遍历。浅度遍历的知识图谱不需要图数据库关系型 DB 够深度遍历的才需要。五、知识图谱选型判断标准你的查询要几跳要不要上图数据库看你的核心查询的遍历深度你的知识图谱查询要几跳 1 跳用户 - 他说过的事实 - 关系型 DB 的 1 次 JOIN毫秒级完全够 2 跳用户 - 亲属 - 亲属的事实 - 关系型 DB 的 2 次 JOIN毫秒级够 3 跳用户 - 亲属 - 同事 - 同事的事实 - 关系型 DB 的 3 次 JOIN开始慢 - 如果查询频繁考虑图数据库 5 跳跨多实体的复杂关联 - 关系型 DB 爆炸 - 必须用图数据库大多数企业知识图谱的查询是 1-2 跳关系型 DB 完全够。不要为了看起来高级就上 Neo4j–运维成本、学习曲线、生态成熟度都是代价。六、Agent Memory 场景判断回到 AI Agent 的记忆系统。要不要知识图谱、要不要图数据库按场景判断场景要不要知识图谱要不要图数据库存用户对花生过敏不需要一条结构化条目够不需要存用户说过 X后来改口说 Y不需要标记取代链够不需要查用户亲属的过敏史需要跨实体关联看遍历深度浅的话关系 DB 也行查这个 PR 沉寂 3 天了关联 CI 失败 负责人请假需要多跳推理大概率需要查3 个月前这条事实当时对不对需要时序推理Zep/Graphiti 用图做双时间轴双时间轴图数据库的另一个用武之地最后那个场景3 个月前这条事实当时对不对值得展开。这是图数据库特别是 Zep/Graphiti的另一个杀手级特性双时间轴。validFrom / validTo 事实在现实世界中的有效期 对花生过敏 validFromT1, validToT3 T1 到 T3 期间为真 不过敏 validFromT3, validTonull T3 之后为真 recordedAt 系统什么时候录入这条记忆 fact1.recordedAt T1 T1 时录入 fact2.recordedAt T3 T3 时录入关系型 DB 的记忆只有录入时间回答不了上周三时用户对花生过敏吗。图数据库通过边的 validFrom/validTo 能回答这种时序问题–查 validFrom 周三 validTo 的事实。如果你的 Agent 需要时序推理“当时知道什么、什么时候知道的”图数据库是有价值的选择。七、总结知识图谱 用图组织数据的形态选择维度 1 图数据库 专门存图、查图的存储介质维度 2 知识图谱 ≠ 图数据库 知识图谱可以存在图 DB / 关系 DB / 内存 / 文件 图数据库专门存知识图谱节点 边 选不选用知识图谱看你要不要关系推理 选不选用图数据库看遍历深度浅的用关系 DB 够深的才需要图 DB三句话收束知识图谱是设计决策怎么组织数据图数据库是工程选型存在哪里。它们正交可以自由组合。知识图谱不一定要用图数据库。两张表 SQL JOIN 就能存知识图谱大多数企业就是这么做的。图数据库的唯一理由是深度遍历。浅度遍历用关系型 DB 够深度遍历5 跳才需要图 DB。时序推理是另一个加分项。下次有人提知识图谱先问他“你的查询要几跳” 再决定上不上图数据库。