文章目录
- 前言
- [Neo4j 解决什么问题？](#Neo4j 解决什么问题？)
- 举几个商城客服例子
- Graph特别适合
- 什么情况下不用Neo4j？
- Neo4j什么时候值得加？
- RAG什么时候会遇到瓶颈？
- 一个经典例子
- Neo4j在RAG里的位置
- Graph什么时候调用？
- Neo4j怎么建？
- 对于你的项目
- 面试题练手？
前言
RAG智能电商客服什么时候上Neo4j？ 这是一个非常好的问题。
RAG + Neo4j = GraphRAG。
实际上，90% 的 RAG 项目根本不需要 Neo4j。
项目（商城 + AI 客服），建议：
第一版不要引入 Neo4j，等你真正遇到"关系查询"的问题再加。
从工程角度分析。
Neo4j 解决什么问题？
普通 RAG 擅长回答：
text
文档里写了什么？例如：
js
退款政策是什么？
七天无理由怎么申请？
iPhone16支持国补吗？
运费怎么算？这些：
js
Question
↓
Vector Search
↓
Chunk
↓
LLM就足够了。
但是，
Neo4j解决的是：
实体之间的关系。
例如：
js
Apple
↓
生产
↓
iPhone16
↓
属于
↓
手机
↓
支持
↓
国补
↓
需要
↓
实名认证它存的是：
js
Node
↓
Relation
↓
Node
↓
Relation而不是：
Chunk举几个商城客服例子
例如：
用户问：
苹果16支持国补吗？
普通RAG：
找到：
Chunk1
苹果16支持国补...回答。
完全没问题。
但是用户问：
哪些品牌支持国补？
知识其实散落：
js
Apple文档
Huawei文档
Xiaomi文档
Honor文档Vector Search：
可能：
js
Apple排第一
Huawei排第五
小米没召回结果：
回答不完整。
Graph：
js
Brand
↓
Product
↓
Policy
↓
Region查询：
js
MATCH
Brand
↓
SUPPORT_POLICY
↓
国补直接得到：
js
Apple
Huawei
Honor
Xiaomi比Vector稳定。
Graph特别适合
例如：
产品依赖关系
js
MacBook
↓
Compatible
↓
Magic Mouse
↓
Need
↓
Bluetooth5.0用户：
MacBook能不能配Magic Mouse？Graph：
秒查。
复杂退款
例如：
js
退款政策
↓
地区
↓
广东
↓
商品类型
↓
定制商品
↓
会员等级
↓
VIPGraph：
直接：
js
Policy
↓
ApplicableTo
↓
Region
↓
ApplicableTo
↓
VIP而不是让LLM自己理解。
企业知识库
例如：
js
员工
↓
属于
↓
部门
↓
属于
↓
事业部
↓
负责人
↓
CEO用户：
张三老板是谁？Graph：
非常强。
什么情况下不用Neo4j？
目前项目：
商城客服知识：
js
退款政策
物流
订单
FAQ
商品说明
售后这些：
都是文档。
不是：
关系网络。所以：
js
PostgreSQL+pgvector
完全够。Neo4j什么时候值得加？
例如：
以后你增加：
AI导购用户：
js
给我推荐一个
支持Apple Pencil
支持国补
预算5000
11寸以上
OLED
256G以上
今年发布
支持教育优惠这里：
关系：
js
Product
↓
Brand
↓
Category
↓
Promotion
↓
Region
↓
Accessory
↓
Inventory
↓
CouponGraph开始发挥价值。
例如：
js
Product
↓
CompatibleWith
↓
Accessory
↓
Need
↓
Power
↓
Need
↓
Protocol用户：
js
这个充电器能不能给MacBook和iPhone一起充？Graph很好查。
RAG什么时候会遇到瓶颈？
例如：
用户：
js
哪些商品
支持国补
还能使用PLUS优惠
库存大于10
支持次日达
深圳有货这是：
关系查询。
不是：
语义检索。
Vector：
很难。
Graph：
天然。
一个经典例子
知识：
js
退款政策
↓
适用于
↓
普通商品
↓
不适用于
↓
定制商品另外：
js
定制商品
↓
属于
↓
特殊商品用户：
js
特殊商品支持七天无理由吗？Chunk：
可能没有：
特殊商品
↓
七天无理由Graph：
特殊商品
↓
就是
↓
定制商品
↓
不支持直接推理。
Neo4j在RAG里的位置
很多人误解：
js
Neo4j
替代
VectorDB不是。
真正：
js
Question
↓
Query Analyzer
↓
Hybrid Retriever
├── Vector Search
├── BM25
└── Graph Search
↓
Merge
↓
LLMGraph：
只是：
第三种Retriever。
例如：
LangChain：
js
VectorRetriever
+
GraphRetriever
+
KeywordRetriever一起。
Graph什么时候调用？
不是：
所有问题。
例如：
QueryAnalyzer：
js
{
route:"graph"
}或者：
js
{
route:"hybrid"
}例如：
退款政策↓
Vector。
订单查询↓
API。
推荐支持国补并兼容Apple Pencil的产品↓
Graph。
Neo4j怎么建？
例如：
js
(:Product)
(:Category)
(:Brand)
(:Coupon)
(:Promotion)
(:Region)
(:Policy)关系：
js
BELONG_TO
SUPPORT
COMPATIBLE_WITH
APPLY_TO
REQUIRE
SELL_IN例如：
Product
↓
BELONG_TO
↓
CategoryCypher：
cypher
MATCH
(p:Product)-[:BELONG_TO]->(c:Category)
RETURN p对于你的项目
我建议：
第一阶段
PostgreSQL
+
pgvector做好：
-
Hybrid Retrieval
-
Query Rewrite
-
Rerank
-
Citation
-
Evaluation
这是最重要。
第二阶段
增加：
知识图谱但是：
不要全部知识都Graph。
只Graph：
js
商品
品牌
分类
政策
优惠
配件
兼容性
地区
组织关系文档：
仍然：
Vector第三阶段
真正GraphRAG：
Question
↓
Intent
↓
Vector Search
+
Graph Query
+
Business API
↓
Merge Context
↓
LLM面试题练手？
为什么你的项目没有Neo4j？
好的回答：
我没有为了使用Graph而使用Graph。我的客服知识主要是退款政策、FAQ、商品说明和售后文档，这些属于非结构化文本，Hybrid Retrieval已经能够很好解决，因此第一阶段采用PostgreSQL + pgvector。
如果以后扩展到AI导购、商品兼容性、优惠规则、组织关系或者复杂依赖查询，我会把这些天然具有关系结构的数据抽取成知识图谱，Neo4j作为Graph Retriever，与向量检索并行工作，而不是替代向量数据库。
常见演进路线
现在的项目
js
第一阶段（现在）
NestJS
+
PostgreSQL
+
pgvector
+
Redis
+
LangChain
↓
第二阶段
加入 Hybrid Retrieval
(BM25 + Vector + Rerank)
↓
第三阶段
加入 Evaluation（评测体系）
↓
第四阶段
加入 Neo4j（Graph Retriever）
↓
第五阶段
演进为真正的 GraphRAG这样每一步都有明确的工程价值，也符合大多数企业的实际演进路径。
最后强调一点： Neo4j 不是因为"用了 RAG 就必须上"，而是当你的知识中实体之间的关系本身就是答案的重要组成部分时，它才真正发挥价值。对于目前的商城客服，先把 Hybrid RAG 做扎实，比提前引入 GraphRAG 更有价值。