别再迷信向量检索了，GraphRAG 才是解决大模型幻觉的真方案

最近在优化几个 B 端 RAG 项目时发现，单纯依赖向量数据库（Vector DB）的方案在面对复杂逻辑查询时非常不稳定。最典型的问题就是“多跳推理”失效：当你询问一个涉及多个实体关联的问题时，模型检索到的往往是几段碎片化的文本。因为这些片段之间缺乏显性的逻辑链条，LLM 很容易在整合信息时产生事实性幻觉，靠概率去“猜”一个看起来很像正确答案的错误结论。

要根治这个问题，核心在于将检索逻辑从单纯的“语义相似度”升级为“结构化关系”。传统的 RAG 本质上是在海量文档里找最像的那几段话，而 GraphRAG 则是沿着“实体-关系-实体”的路径去寻找答案。

举个具体的例子，如果用户询问“A 公司的 CEO 在 B 事件中的立场”，传统 RAG 可能会检索到关于 A 公司的介绍和 B 事件的报道，但由于缺乏结构化关联，模型未必能精准锁定 CEO 这个具体个体在两两者之间的逻辑链路。而知识图谱通过 (CEO) -[任职]-> (A公司) 和 (CEO) -[参与]-> (B事件) 这样的三元组，直接将确定的事实链路喂给 LLM，把原本需要模型去“推断”的过程变成了简单的“阅读”。

对于开发者而言，这意味着技术栈的重心需要从 Embedding 模型的微调转移到图谱的构建上。目前最成熟的落地路径是利用 LLM 自动化提取实体和关系，并将其存储在 Neo4j 或 NebulaGraph 这样的图数据库中。在实际检索阶段，我建议采用“混合检索”策略：先通过向量检索快速定位到种子节点，然后迅速在图谱中进行 1-2 跳的邻居扩展（Neighbor Expansion），将检索到的结构化三元组与原始文本块共同作为 Context 注入 Prompt。

在具体的 Prompt 工程实现上，我建议采用一种“事实围栏”结构，强制模型在约束范围内回答。一个可参考的增强型检索 Prompt 结构如下：

已知事实关系：
1. {实体A} -- {关系R1} --> {实体B}
2. {实体B} -- {关系R2} --> {实体C}

参考文档片段：
{检索到的文本块}

请基于上述确定的事实关系和文档，回答问题：{用户问题}。如果事实关系中不存在相关链路，请直接回答不知道，不要尝试推断。

这种做法的精妙之处在于，它改变了 LLM 的工作模式。模型不再是单纯地预测下一个 token，而是在一个被结构化知识约束的子图内进行信息总结。

从行业趋势来看，RAG 正在进入深水区。早期的 RAG 方案相当于给模型配了一本字典，通过关键词或语义索引查词；而结合 KG 的 RAG 则是给模型配了一张逻辑地图。尤其在医疗、金融、法律等对准确率要求极高的 B 端场景中，单纯的向量检索已经触碰到了天花板。构建企业级知识图谱将成为降低幻觉的必经之路。当然，这也给开发者带来了新的挑战，比如如何低成本地维护图谱的实时更新，避免图谱本身演变成一个新的、难以维护的数据孤岛。