在构建企业级知识库(如设备维修脑、智能客服、规章制度问答)时,检索架构的选择直接决定了大模型回答的准确率和逻辑深度。以下是普通 RAG、GraphRAG 以及目前工业界最前沿的"混合 RAG"的优缺点剖析。
1、 普通 RAG (纯向量/语义检索)
普通 RAG 的核心思想是**"算距离"**。它将用户的提问转化为高维空间中的向量,寻找字面意思或语义最相近的文本切片(Chunks)。
1.1 优点
- 构建成本极低:只需"切块 -> 向量化 -> 存入 FAISS/Milvus",几乎不需要复杂的预处理逻辑。
- 检索速度快:向量数据库的 ANN(近似最近邻)搜索效率极高,毫秒级响应。
- 模糊容错率高:即使提问里有错别字,或者使用了不同的描述方式(如"坏了"对应"故障"),也能通过语义空间强行拉回。
- 单点事实召回强:非常适合回答"某某参数是多少"、"某某条款怎么规定"这种答案集中在单一文本块内的问题。
1.2 痛点
- 多跳推理能力为零 (Multi-hop):无法跨越多个文本片段建立逻辑联系。例如,无法推导出"打开后盖 -> 拧螺丝 -> 用螺丝刀 -> 断开表笔"这条隐性知识链。
- 极易被"噪音"欺骗 (语义混淆) :只要文本含有高权重关键词(如刚才案例中的
PX-500 示波器警告),就会被错误召回,导致大模型产生严重的"张冠李戴"式幻觉。 - 缺乏全局视野:大模型看到的永远是一堆破碎的、彼此孤立的纸片,无法回答"总结一下该设备的所有常见故障"这类宏观问题。
2、 GraphRAG (纯图谱检索)
GraphRAG 的核心思想是**"找逻辑连线"**。它提前利用大模型将文本结构化为"实体-关系-实体"的网络,查询时从起点沿着网线去抓取知识。
2.1 优点
- 无敌的多跳推理能力 :能够沿着
[r*1..3]这样的逻辑链条,精准拉取跨越多个章节的关联知识。 - 物理隔离噪音 (精准避坑):完全不依赖字面相似度。哪怕两段警告长得一模一样,只要它们在图谱中没有连线(分属不同设备),图查询就绝对不会把混淆数据带进来。
- 强可解释性:每一次回答都能给出严密的证据链(A 导致 B,B 需要 C),这在医疗、工业排障、司法等容错率为 0 的场景中至关重要。
2.2 缺点
- 建库成本极高 (烧钱且慢):每一段文本入库前,都需要调用大模型去抽取实体和关系,不仅极其消耗 Token,而且耗时较长。
- 高度依赖抽取质量 (Garbage in, garbage out):如果构建阶段大模型漏抽了某个关键实体,或者抽错了关系名,检索时这条路就彻底断了。
- 入口匹配死板:纯图查询缺乏模糊匹配能力。用户搜"十字起子",如果图谱节点叫"螺丝刀",纯 Cypher 查询就会因为完全匹配不上而返回空(这就需要引入混合检索)。
3、混合 RAG (向量 + 图谱 双擎驱动)
这也是我们将要实现的架构,被称为**"Vector-Graph Hybrid RAG"**。它是目前解决复杂业务场景的黄金标准。
3.1 工作原理
- Milvus (向量域) 负责找门把手 :利用向量的模糊匹配能力,将用户含糊不清的提问("那个拧螺丝的工具")精准对齐到图谱中的标准实体节点(
Entity: 金属螺丝刀)。 - Neo4j (图谱域) 负责顺藤摸瓜:拿着找准的实体节点作为"种子(Seed)",在图数据库中执行多跳扩展,抓取出完整的逻辑上下文子图。
- 反查与整合 :将结构化的图路径转换成文本描述,或沿着
MENTIONED_IN关系把原文 Chunk 捞出来,一起打包喂给大模型。
3.2 混合架构的绝对优势
- 互补短板:用向量的"柔性"解决了图谱"入口太硬"的问题;用图谱的"刚性关系"解决了向量"容易串台、无法推理"的问题。
- 双通道召回:在实际应用中,通常会将向量库直接召回的 Top-K 文本,与图数据库遍历出来的逻辑文本合并(或者计算综合得分去重),从而保证既有事实细节,又有宏观逻辑。
3.3 对比总结表
| 维度 | 普通 RAG (纯 Milvus) | 纯 GraphRAG (纯 Neo4j) | 混合 RAG (Milvus + Neo4j) |
|---|---|---|---|
| 核心机制 | 算语义距离 | 走逻辑关系网 | 对齐入口点 + 扩展关系网 |
| 开发难度 | (极简) | (需要清洗图数据) | (需要双库同步与调度) |
| 检索成本 | 极低 | 低 | 中等 |
| 防噪音能力 | 极弱 (看字面词频) | 极强 (看业务连通性) | 极强 (兼顾容错与精准) |
| 多步推理 | 基本没有 | 极强 (原生支持) | 极强 |
| 典型应用 | 查客服话术、看单篇文档 | 分析企业架构、供应链跟踪 | 工业设备排障、复杂医疗诊断 |
结论 :如果你的业务场景只是"查阅死知识",普通 RAG 足够了;但只要涉及"故障排查、复杂操作指引、因果关系推理",走向混合 RAG 架构是唯一且必经之路。