GraphRAG (Graph Retrieval-Augmented Generation · 图谱检索增强生成)

一句话

在图谱上做 RAG。 不是从文档里搜片段，而是从知识图谱里搜关系和路径。

和传统 RAG 的区别

	传统 RAG	GraphRAG
数据存储	文档切块 → 向量库	实体+关系 → 图数据库
检索方式	向量相似度	Cypher 图查询
擅长问题	「XX 是什么」	「A 和 B 什么关系」「从 X 经过什么路径到 Y」
典型问题	「LangGraph 是什么」	「珍珠奶茶有哪些配料？这些配料分别用什么工艺制作？」

核心流程

用户提问 → LLM 生成 Cypher 查询 → Neo4j 执行 → 拿结果 → LLM 组织回答

关键步骤是 Text-to-Cypher：让 LLM 把自然语言问题翻译成 Neo4j 的查询语句。这和 Text-to-SQL 同思路。

应用场景

场景	为什么 GraphRAG 合适	传统 RAG 的不足
生物医药	「某药物靶点参与的通路中，哪些基因是已知致癌基因？」需要关系链路	只能搜到描述文档，无法串联关系
法律合规	「这条法规引用了哪些判例？被哪些后续法规修正？」需要引用网络	无法建立法规间的引用图
企业内部知识库	「这个项目涉及哪些团队？各团队负责人的汇报链？」需要组织关系	只能返回文档片段，无法关联
学术研究	「这篇论文引用了哪些人？这些人又各自被谁引用？」需要引用图	返回论文摘要，无法展示引用图谱
故障排查	「这个服务的依赖链是什么？哪一环挂了会影响哪些上游？」需要依赖图	找到文档，无法追踪依赖链路

横向对比：三种 RAG 架构

	传统 RAG	Agentic RAG	GraphRAG
检索驱动	固定管道	LLM 自主决策	知识图谱结构
适合问题	单跳事实查询	多步骤拆解	多跳关系推理
数据依赖	文档/向量库	多数据源	知识图谱
灵活性	低（固定流程）	高（动态决策）	中（图结构限制）
复杂度	⭐	⭐⭐⭐	⭐⭐⭐⭐
前置投入	文档清洗+向量化	检索策略设计+路由逻辑	知识图谱构建
典型实现	LangChain RAGChain	LangGraph Agent	Neo4j + Text-to-Cypher

优缺点

优点：

• 多跳推理是原生能力——从 A 问到 D 不需要联网搜 4 次，一次图遍历搞定
• 回答可解释性强——能展示完整的推理路径（A→B→C→D），不是黑箱
• 适合结构化知识域——有明确实体和关系的领域（医学、法律、供应链）

缺点：

• 图谱构建门槛高——需要花大量精力提取实体、定义关系、去重消歧
• 不适合模糊语义搜索（那是 Embedding），不适合海量全文检索（那是 ES）
• 图谱质量和覆盖度直接影响回答质量——维护成本高于单纯的文档向量化
• Text-to-Cypher 的准确率是瓶颈——LLM 生成的查询可能语法错误或逻辑错误

如何选择：传统 RAG vs Agentic RAG vs GraphRAG

你的知识库特点——
├─→ 大量非结构化文档，问题偏「是什么/怎么做」
│     → 传统 RAG（向量检索 + LLM 生成）
│
├─→ 数据源多样，问题类型不固定，用户会问意想不到的事
│     → Agentic RAG（让 LLM 自己决定检索策略）
│
├─→ 知识高度结构化，有明确的实体和关系网，用户问「谁和谁什么关系」
│     → GraphRAG（图检索 + 多跳推理）
│
└─→ 以上都有，且需要最灵活的处理能力
      → Agentic RAG + GraphRAG 混合（LLM 自主路由到图检索或向量检索）

实用建议：不要一上来就建知识图谱。先用传统 RAG 跑通，发现大量问题是多跳关系推理时，再引入 GraphRAG。GraphRAG 不是 RAG 的默认选项，而是关系推理场景的专用武器。

小结

GraphRAG 解决了「从关系查答案」的问题——当你的知识不仅是独立文档，而是彼此关联的网时，GraphRAG 比传统 RAG 更精准。但它不是银弹，建图成本高、维护成本高。判断标准很简单：如果你的用户常问「A 和 B 什么关系」，就用 GraphRAG；如果常问「X 是什么」，传统 RAG 就够了。

下一步

• Neo4j — GraphRAG 的底层存储
• Agentic RAG — 让 LLM 自主决定走向量还是走图谱