GraphRAG 必须用图数据库吗?

这道题问的是，不用图数据库到底能不能做出真正的[[GraphRAG]]。我觉得这个说法有一定道理，但有点绝对了。它的核心价值在于，图数据库能做一些[[向量数据库]]完全做不了的事，但落地的时候，很少只用一个库。

先说说图数据库为什么在某些场景下不可替代。最关键的其实是多跳关系推理，你可以这么理解：向量库本质上做的是相似度匹配，你给一个向量，它找最像的几个，但它不明白“A的朋友B在C公司工作”这种两层以上的关系。图数据库原生支持这种多跳遍历，比如你问“找朋友的朋友里做AI的”，写一句Cypher查询就出来了。而且它还能显式地给边加上属性，比如时间、权重，这样你可以过滤“最近三个月才认识的朋友”，向量库做不到。再一个就是结构化知识的整合，比如实体消歧，两个名字很相似的实体，需要看它们在图中的上下文才能判断是不是同一个，这种全局一致性约束只有图结构能搞。

但是，说“必须”用图数据库，那就太绝对了。小规模场景完全可以替代，比如节点数少于十万，直接用NetworkX这种内存图计算库，搭配向量库做检索，成本低很多。再比如只做简单的两跳查询，你可以预计算边的[[Embedding]]存到向量库里，虽然会存储膨胀、灵活性差，但够用。还有一些只读场景，比如离线分析，用图计算框架像GraphX跑一次，把结果存起来，不需要实时更新，也不用上数据库。

真正落地的时候，关键是要分清楚你做的到底是KG-[[RAG]]还是GraphRAG。前者是把[[知识图谱]]当增强检索的源，查的时候还是走关键词或向量，图数据库不是必须的。后者是微软定义的，基于图社区检测做全局摘要，底层其实可以用图算法库，不一定非要Neo4j这种数据库。

举个例子，比如电商平台的“商家满减政策”咨询。用户问“我买的手机参加满减吗，为什么结算没减”，背后要查商品、活动、优惠券、订单之间的多跳关系，这用图数据库就很自然。但如果你只是把活动政策文档切碎存向量，用户问同样的问题，可能召回的是另一条不相关的满减规则，因为向量相似度抓不到“这个手机属于这个活动”这种精确关系。所以这里图数据库是更好的选择。

不过这里有个坑，图数据库的写入性能通常比向量库差，如果业务是高频更新的，比如每分钟都有新活动上线，你得上实时流处理加图数据库的增量更新，不然查询结果会滞后。这个点面试官可能会追问你是怎么权衡的。

所以我的判断是，图数据库在复杂关系推理、动态更新、大规模场景下有不可替代性，但技术选型不能教条。我更倾向的做法是：先看数据规模，小规模用NetworkX加向量库；再看查询复杂度，简单两跳用向量库预计算；只有真的需要多跳推理和结构化约束时，才上图数据库。而且很多时候，图数据库和向量库是配合着用的，图负责关系推理，向量负责语义检索，各管一摊。