> For the complete documentation index, see [llms.txt](https://yeasy.gitbook.io/context_engineering_guide/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://yeasy.gitbook.io/context_engineering_guide/di-san-bu-fen-jin-jie-ji-shu-yu-jia-gou/10_advanced/10.2_graph_rag.md).

# 10.2 Graph RAG 与知识图谱

## 10.2.1 向量检索的局限

传统向量检索基于语义相似度，在许多场景下效果显著；而现代检索系统也常会叠加元数据过滤、关键词检索、重排序和查询分解等能力。即便如此，**当问题强依赖显式关系结构时**，单靠向量相似度仍然不够理想：

* **对实体间关系的表达较弱**：向量相似度能找“相关内容”，但不天然表达“A 是 B 的子公司”这类关系边
* **跨多个文档的关系推理更依赖额外编排**：当答案需要整合多个文档的信息时，往往要配合查询分解、重排序或多轮检索
* **对复杂关联查询不够直接**：如“找出所有投资了 AI 公司的 PE 基金合伙人”这类多跳问题，若只有相似度检索，通常还需要额外的结构化约束

## 10.2.2 Graph RAG 与记忆脑图的概念

**Graph** [**RAG**](/context_engineering_guide/di-er-bu-fen-he-xin-ji-shu-yu-ce-le/05_select/5.1_rag_principles.md) 将知识图谱与 RAG 结合，通过实体和关系增强检索能力。知识图谱以（实体，关系，实体）三元组的形式存储结构化知识，可以表达复杂的关联关系。

**从全量图谱到“记忆脑图”工程模式的演进** 然而在工业界实践中，全量构建知识图谱的成本极其高昂，且对实体抽取的强一致性要求异常苛刻，导致系统异常脆弱。因此，更具工程价值的演进形态是构建轻量化的图结构。本书把这种折中模式称为 **“记忆脑图（Memory Mind Map）”**（注：这是本书引入的工程实践术语，便于讨论；并非来自某篇统一标准论文或官方规范——业界类似思路常被表述为 “lightweight knowledge graph”、“sparse knowledge structure” 或 GraphRAG 的轻量变体）。

记忆脑图介于松散的分块（Chunking）与重度的图谱之间，它摒弃了盲目全量建图的思路，通过引入本书所称的 **“Chain of Memory（主动记忆过程）”** 工程模式，让系统像领域专家一样进行阅读理解与“主动抽取”——**系统会自觉过滤掉通识内容，仅保留对当前业务场景具有差异化、可复用价值的要点信息**，最终形成以根节点（Root Node）和主题节点（Topic Node）为核心骨干的轻型脑图网络。

```mermaid
graph LR
    A["公司A"] --> |"收购"| B["公司B"]
    B --> |"总部"| C["城市X"]
    A --> |"CEO"| D["人物Y"]
    D --> |"毕业于"| E["大学Z"]
    E --> |"位于"| C
```

图 10-2：图谱结构与多跳推理

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

## 10.2.3 Graph RAG 的工作流程

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

1. **实体识别**：从用户查询中提取关键实体
2. **图检索**：在知识图谱中查找相关节点和边
3. **上下文构建**：将图结构转换为文本上下文
4. **生成回答**：基于增强上下文生成答案

```mermaid
graph LR
    A["用户查询"] --> B["实体提取"]
    B --> C["图谱检索"]
    C --> D["子图提取"]
    D --> E["上下文构建"]
    E --> F["LLM生成"]
```

图 10-3：Graph RAG 工作流程

## 10.2.4 相较于向量检索的优势

| 场景     | 向量检索                 | Graph RAG |
| ------ | -------------------- | --------- |
| 实体关系查询 | 可借助元数据与重排增强，但关系表达不显式 | 强         |
| 多跳推理   | 通常需要额外的查询规划或多轮检索     | 更自然       |
| 结构化查询  | 可结合过滤条件与混合检索         | 更适合       |
| 可解释性   | 中等，更多依赖片段证据          | 高         |
| 全局理解   | 偏局部相似性               | 更适合全局关系视角 |

## 10.2.5 实现方式

### 构建知识图谱

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

**实体提取**

使用 NER（命名实体识别）或 LLM 提取实体：

```
文档: "张三是A公司的CEO，A公司总部位于北京，2024年收入达10亿元..."

提取的实体:
- 人物: 张三
- 组织: A公司
- 地点: 北京
- 金额: 10亿元
- 时间: 2024年
```

**关系抽取**

识别实体之间的关系：

```
提取的关系:
(张三, 职位, A公司CEO)
(A公司, 总部, 北京)
(A公司, 收入_2024, 10亿元)
```

**图谱构建流程**

```mermaid
graph TB
    A["原始文档"] --> B["文档分块"]
    B --> C["实体提取"]
    C --> D["关系抽取"]
    D --> E["去重合并"]
    E --> F["知识图谱"]
```

图 10-4：知识图谱构建流程

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

```python
prompt = """
从以下文本中提取实体和关系，输出JSON格式：
文本：{text}

输出格式：
{
  "entities": [{"name": "实体名", "type": "类型"}],
  "relations": [{"head": "头实体", "relation": "关系", "tail": "尾实体"}]
}
"""
```

### 图检索策略

**局部子图提取**

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

```python
def extract_subgraph(graph, seed_entities, max_hops=2):
    visited = set()
    subgraph = []

    for entity in seed_entities:
        bfs(graph, entity, max_hops, visited, subgraph)

    return subgraph
```

**路径查询**

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

```cypher
MATCH path = (a:Entity {name: "张三"})-[*1..3]-(b:Entity {name: "北京"})
RETURN path
```

**社区检测**

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

* 适用于主题聚类
* 可以提供全局视角的摘要

### 将图结构转换为上下文

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

```python
def graph_to_text(subgraph):
    lines = []
    for triple in subgraph:
        head, relation, tail = triple
        lines.append(f"- {head} {relation} {tail}")
    return "\n".join(lines)

# 输出示例：
# - 张三 担任 A公司CEO
# - A公司 总部位于 北京
# - A公司 收购 B公司
```

## 10.2.6 图/脑图与向量框架的混合增强

实践中，无论是经典的 Graph RAG 还是轻便的记忆脑图结构，与底层向量检索进行双路融合都能获得最佳的召回效果：

在记忆脑图架构下，系统会为关键树状路径和主题节点预计算嵌入（Embedding），实现 **“脑图结构 + 向量特征”** 的双保险——既保留了宏观的逻辑组织脉络，又能通过微观的语义相似度精准命中目标子节点。

```mermaid
graph TB
    A["查询"] --> B["向量检索"]
    A --> C["图检索"]
    B --> D["文档片段"]
    C --> E["结构化关系"]
    D --> F["结果融合"]
    E --> F
    F --> G["生成"]
```

图 10-5：混合检索增强策略

融合策略：

* **互补增强**：向量检索提供详细描述，图检索提供关系结构
* **相互验证**：两种方式的结果相互印证
* **按需切换**：根据查询类型选择主要方法

## 10.2.7 工具与框架

| 工具/方案类型     | 特点             | 适用场景   |
| ----------- | -------------- | ------ |
| 图数据库 + 编排框架 | 成熟的图查询能力与生态    | 企业级部署  |
| GraphRAG 框架 | 自动建图、社区摘要、分层索引 | 大规模文档集 |
| 数据索引框架的图扩展  | 支持多种图索引模式      | 灵活定制   |
| 云托管图数据库     | 托管运维、可扩展       | 云生态集成  |

## 10.2.8 图检索增强生成框架特点（示意）

一些 GraphRAG 框架会提供一套相对完整的方案：

1. **自动建图**：使用 LLM 从文档中自动提取实体和关系
2. **社区检测**：识别实体社区，生成社区级摘要
3. **分层索引**：支持局部查询和全局查询
4. **全局摘要**：可以回答需要全文档理解的问题

## 10.2.9 实践建议

1. **评估适用性**：知识密集、关系复杂的场景最受益；简单问答可能不需要
2. **渐进式实施**：先从核心实体开始构建图谱，逐步扩展
3. **维护图质量**：定期更新和清理过时的实体和关系
4. **结合向量检索**：发挥各自优势，而非完全替代
5. **关注构建成本**：图谱构建需要额外的 LLM 调用，需权衡成本