大家好我是大煊。我以前对数据库的理解很朴素业务数据放 MySQL热点数据放 Redis搜索复杂一点再上 Elasticsearch。所以我第一次在一个 AI 客服项目里看到 Neo4j 时第一反应不是兴奋而是疑惑一个电商客服系统为什么还要搞图数据库我的数据库世界只有“表”做 Java 后端时我最熟的就是表。用户表、订单表、商品表、权限表、日志表。这些数据最大的特点是结构固定。比如订单表关心的是字段含义order_id订单号user_id用户status状态price金额这种数据 MySQL 非常擅长。事务、一致性、索引、SQL 查询都很稳。所以过去很多年我几乎没想过一个问题已经有 MySQL 了为什么还需要别的数据库AI Agent 遇到的问题开始变了学习 AI Agent 以后我发现它要回答的问题和传统 CRUD 不太一样。传统系统更常见的问题是订单 1001 发货了吗用户 41 有没有售后单这类问题本质是在查一条记录。但 AI 客服还会遇到另一类问题有没有 256G 的手机70 多寸的电视有哪些非有机的大米有哪些品牌这些问题表面是在聊天底层其实是在问数据之间是怎么连起来的。手机是分类。小米 12S Ultra 是 SPU。8GB256GB 某个颜色是 SKU。256G、颜色、屏幕尺寸是属性。品牌、分类、属性、商品之间全是关系。MySQL 能存关系为什么还要 Neo4j这是我一开始最疑惑的地方。MySQL 当然能存关系。商品表、品牌表、分类表、中间表一样可以建。甚至你愿意写 SQL也能一路 Join 出结果。但问题是关系一多查询会越来越绕。在这个项目的 Neo4j 里我看到的电商图谱大概是这样的节点含义示例数据Category1/2/3一级、二级、三级分类电脑办公 / 电脑整机 / 笔记本Trademark品牌RedmiSPU标准商品小米 12S UltraSKU具体规格商品小米 12S Ultra 8GB128GBAttr商品属性256G、蓝色、70 英寸User用户user_id41关系主要有三种关系白话解释Belong属于Have拥有View浏览过一条商品链路大概是SKU - SPU - 三级分类 - 二级分类 - 一级分类再补两条SPU - 品牌 SKU - 属性 User - 浏览过的 SKU这就不是单纯“查表”了。它更像把一张商品 ER 图变成了可以直接查询的数据库。AI 为什么越来越喜欢图数据库因为 AI 问题里经常不只需要“相似文本”还需要“关系路径”。普通 RAG 更像文档切片 - 找相似内容 - 交给大模型回答它适合问退货政策是什么因为退货政策通常就是一段文档。但如果用户问有没有 256G 的手机这时更像是在走一条路径手机分类 - 某款手机 - 具体 SKU - 256G 属性如果用户问我之前看过的商品里有哪些是小米品牌那又要走用户 - 浏览过的 SKU - SPU - 品牌这就是 Neo4j 的价值。它让 AI 客服不只是“找相似文档”还可以“沿着关系找答案”。所以 MySQL 过时了吗当然不是。我现在的理解是它们解决的问题不一样。问题更适合谁查订单状态MySQL查物流、售后MySQL查退货政策、FAQ普通 RAG查商品分类、品牌、属性关系Neo4j如果用户问“订单有没有发货”交给 MySQL。如果用户问“退货政策是什么”交给文档 RAG。如果用户问“有没有某个属性的商品”Neo4j 就更自然。所以不是 AI 项目非要堆数据库。而是 AI Agent 遇到的问题已经从“查一条记录”变成了“理解一句话然后在一堆关系里找答案”。我最大的收获以前做 Java 后端我更多思考的是数据应该放哪张表现在看 AI Agent 项目我开始多问一个问题这些数据之间有什么关系这是我第一次真正理解 Neo4j 的地方。它不是为了显得架构复杂。它是在 MySQL 之外多了一层“关系记忆”。可以把它想成一张可以被程序查询的业务关系图。MySQL 解决“记录是什么”。Neo4j 解决“它和谁有关”。这个边界一清楚AI 客服为什么不只用 MySQL就好理解多了。