# 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 调用，需权衡成本


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET 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?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.