11.2 Graph RAG 与知识图谱

11.2.1 向量检索的局限

传统向量检索基于语义相似度,在许多场景下效果显著,但存在固有局限:

  • 难以捕捉实体间的关系:向量相似度无法表达"A是B的子公司"这类结构化关系

  • 跨多个文档的推理能力弱:当答案需要整合多个文档的信息时,单纯的相似性检索力不从心

  • 无法处理复杂的关联查询:如"找出所有投资了AI公司的PE基金合伙人"这类多跳查询

11.2.2 Graph RAG 的概念

Graph RAG 将知识图谱与 RAG 结合,通过实体和关系增强检索能力。知识图谱以(实体,关系,实体)三元组的形式存储结构化知识,可以表达复杂的关联关系。

spinner

通过图结构,可以轻松回答诸如"公司A的CEO毕业于哪个城市的学校"这类需要多跳推理的问题。

11.2.3 Graph RAG 的工作流程

Graph RAG 的典型流程包含四个阶段:

  1. 实体识别:从用户查询中提取关键实体

  2. 图检索:在知识图谱中查找相关节点和边

  3. 上下文构建:将图结构转换为文本上下文

  4. 生成回答:基于增强上下文生成答案

spinner

11.2.4 相较于向量检索的优势

场景
向量检索
Graph RAG

实体关系查询

多跳推理

困难

自然支持

结构化查询

不支持

支持

可解释性

全局理解

局部相似

全局视角

11.2.5 实现方式

构建知识图谱

从非结构化文档中提取实体和关系是构建知识图谱的关键步骤:

实体提取

使用 NER(命名实体识别)或 LLM 提取实体:

关系抽取

识别实体之间的关系:

图谱构建流程

spinner

实践中可以使用 LLM 进行实体和关系的提取:

图检索策略

局部子图提取

以查询相关实体为中心,提取 N 跳范围内的子图:

路径查询

查找两个实体之间的关系路径,适用于关联分析:

社区检测

识别高度关联的实体簇,整体提取相关社区:

  • 适用于主题聚类

  • 可以提供全局视角的摘要

将图结构转换为上下文

检索到的子图需要转换为 LLM 可理解的文本:

11.2.6 与向量检索结合

实践中,混合使用 Graph RAG 和向量检索效果更好:

spinner

融合策略:

  • 互补增强:向量检索提供详细描述,图检索提供关系结构

  • 相互验证:两种方式的结果相互印证

  • 按需切换:根据查询类型选择主要方法

11.2.7 工具与框架

工具
特点
适用场景

Neo4j + LangChain

成熟的图数据库,丰富的生态

企业级部署

Microsoft GraphRAG

自动图谱构建,社区摘要

大规模文档集

LlamaIndex

支持多种图索引模式

灵活定制

Amazon Neptune

云原生图数据库

AWS 生态

11.2.8 Microsoft GraphRAG 特点

微软开源的 GraphRAG 框架提供了一套完整方案:

  1. 自动建图:使用 LLM 从文档中自动提取实体和关系

  2. 社区检测:识别实体社区,生成社区级摘要

  3. 分层索引:支持局部查询和全局查询

  4. 全局摘要:可以回答需要全文档理解的问题

11.2.9 实践建议

  1. 评估适用性:知识密集、关系复杂的场景最受益;简单问答可能不需要

  2. 渐进式实施:先从核心实体开始构建图谱,逐步扩展

  3. 维护图质量:定期更新和清理过时的实体和关系

  4. 结合向量检索:发挥各自优势,而非完全替代

  5. 关注构建成本:图谱构建需要额外的 LLM 调用,需权衡成本

Last updated