从 0 到 1 实现 TinyGraphRAG：彻底解决传统 RAG 的分块割裂与全局查询痛点

YBAdvanceFu

于 2025-08-26 01:16:25 发布

阅读量635

点赞数 20

CC 4.0 BY-SA版权

文章标签：人工智能机器学习自然语言处理大模型模型知识图谱

本文链接：https://blog.csdn.net/YBAdvanceFu/article/details/150809133

在大模型技术席卷各行各业的今天，“幻觉” 与 **“知识滞后”** 始终是制约其落地的两大核心痛点。为了解决这些问题，检索增强生成（RAG）技术应运而生 —— 通过在大模型生成回答前引入外部知识库的参考文本，让输出更精准、更可靠。

但传统 RAG 并非银弹：分块策略会割裂文档语义（比如 “小明的爷爷叫老明” 和 “小明的爷爷是木匠” 被分成两个 chunk，查询 “小明认识的木匠叫什么” 时无法联动）；全局信息查询（如 “文档中小明所有家人的信息”）更是难如登天。

为此，GraphRAG 技术横空出世 —— 它将非结构化文本转化为结构化的知识图谱，通过实体与关系的关联打破分块壁垒，同时支持全局信息聚合。本文将带您从 0 到 1 实现一个轻量级 GraphRAG 系统（TinyGraphRAG），基于智谱 AI 大模型与 Neo4j 图数据库，覆盖 LLM 模块、Embedding 模块、知识抽取、图存储与社区聚类全流程，让您彻底掌握 GraphRAG 的核心原理与工程实现。

一、为什么需要 GraphRAG？传统 RAG 的 3 大致命缺陷

在动手实现前，我们必须先明确：GraphRAG 不是 RAG 的替代，而是进阶优化。传统 RAG 的痛点，正是 GraphRAG 的发力点。

1. 分块割裂：语义连续性被破坏

传统 RAG 的分块策略（如固定长度分块、语义分块）会将关联信息拆分到不同 chunk 中。例如：

Chunk1：小明的爷爷叫老明
Chunk2：小明的爷爷是一个木匠
Chunk3：小明的爷爷去年退休了

当用户查询 “小明认识的木匠叫什么名字？” 时，传统 RAG 会优先召回含 “木匠” 的 Chunk2，但 Chunk2 没有 “老明” 这个关键信息；而含 “老明” 的 Chunk1 可能因与 “木匠” 关联性低被遗漏 ——明明信息都在，却因分块割裂无法形成有效回答。

2. 全局查询困难：分散信息无法聚合

若用户需要 “文档中小明所有家人的信息”，传统 RAG 需要遍历所有可能含 “小明家人” 的 chunk，不仅召回效率低，还容易遗漏分散在不同位置的信息（如爸爸的职业在 Chunk5、妈妈的爱好在 Chunk12）。传统 RAG 本质是 “点对点” 的检索，无法实现 “面到面” 的全局信息汇总。

3. 复杂推理能力弱：缺乏关系关联

当查询涉及多步推理（如 “小明的爷爷的徒弟是谁？”），传统 RAG 需要召回 “爷爷是木匠”“木匠有个徒弟叫小李” 两个 chunk，且需大模型额外关联这两个信息 —— 过程繁琐且容易出错。

而 GraphRAG 通过知识图谱的形式，将 “小明”“爷爷（老明）”“木匠”“小李” 等实体以 “父子”“师徒” 等关系关联，上述问题将迎刃而解：

语义割裂：实体 “爷爷（老明）” 关联 “木匠” 属性，无需依赖分块；
全局查询：直接检索 “小明” 的所有关联实体（家人），自动聚合信息；
复杂推理：通过 “爷爷（老明）→师徒→小李” 的关系路径，一步完成推理。

二、TinyGraphRAG 架构设计：核心模块与工作流程

TinyGraphRAG 的核心思路是 **“文本→结构化知识（三元组）→知识图谱→智能检索”**，整体架构分为 5 大模块：

图片来自于datawhalechina/tiny-universe/TinyGraphRAG

数据输入层：接收用户上传的非结构化文本（如 TXT、Markdown）；
基础能力层：提供 LLM（实体 / 关系抽取）与 Embedding（向量编码）能力，基于智谱 AI API 实现；
数据预处理层：分块→实体抽取→关系抽取（三元组）→实体消歧，将非结构化文本转化为结构化数据；
图存储层：基于 Neo4j 存储实体与三元组，构建知识图谱；
检索推理层：支持实体查询、关系查询与社区聚类（全局信息聚合），为大模型提供精准知识。

三、从 0 到 1 实现 TinyGraphRAG：代码详解与实战

接下来，我们将基于 Python 实现 TinyGraphRAG 的每一个核心模块，所有代码均可直接运行（需替换自己的 API 密钥与 Neo4j 配置）。

3.1 环境准备：依赖库安装

首先安装所需依赖库，包括智谱 AI SDK、Neo4j 驱动、哈希工具等：

3.2 基础模块实现：LLM 与 Embedding

GraphRAG 的核心依赖大模型（抽取实体 / 关系）与 Embedding（向量编码），我们先实现这两个基础模块，通过抽象基类统一接口，方便后续扩展（如替换为 OpenAI、讯飞等模型）。

3.2.1 LLM 模块：基于智谱 AI 实现

首先定义 LLM 抽象基类BaseLLM，规定所有 LLM 实现必须包含predict方法：

接着实现智谱 AI 的 LLM 子类ZhipuLLM，调用智谱 Chat API：

测试 LLM 模块：替换api_key与model_name，运行以下代码验证：

若输出 GraphRAG 的正确解释，说明 LLM 模块正常工作。

3.2.2 Embedding 模块：基于智谱 AI 实现

同理，先定义 Embedding 抽象基类BaseEmb，规定get_emb方法（输入文本，输出向量）：

实现智谱 AI 的 Embedding 子类ZhipuEmb：

测试 Embedding 模块：

若输出 768 维向量（智谱embedding-2默认维度），说明 Embedding 模块正常。

3.3 图存储模块：与 Neo4j 交互

GraphRAG 需要图数据库存储实体与关系，我们选择 Neo4j（开源、易用、图算法丰富）。首先需要准备 Neo4j 环境：

下载 Neo4j：Neo4j Desktop Download | Free Graph Database Download
启动 Neo4j 服务，记录URL（默认bolt://localhost:7687）、用户名（默认neo4j）、密码（首次启动设置）。

接下来实现 Neo4j 交互类Neo4jGraph，封装 Cypher 查询（Neo4j 的查询语言，类似 SQL）：

测试 Neo4j 连接：

若输出 “Neo4j 连接成功！” 且实体数量为 0，说明图存储模块正常。

3.4 核心流程：文本→三元组→知识图谱

这是 TinyGraphRAG 的核心环节，包括文本分块→实体抽取→关系抽取→实体消歧→图谱构建5 个步骤。

3.4.1 步骤 1：文本分块（滑动窗口策略）

传统分块会割裂语义，我们采用滑动窗口分块（相邻分块有重叠），减少信息丢失。同时为每个分块生成唯一 ID（基于 MD5 哈希）：

我们把提取出的三元组信息导入这个 Cypher 语句中，接着，通过 neo4j 的 driver，我们可以在 neo4j 中执行这个语句，即可实现三元组的导入。

导入后的图谱如图所示：

图片来自于datawhalechina/tiny-universe/TinyGraphRAG

完成导入后，我们就已经构建出了一个根据文档内容提取出的知识图谱。

当你运行完本文中的所有代码，一个能解决传统 RAG 痛点的 TinyGraphRAG 系统就已经搭建完成了 —— 它或许没有工业级系统的复杂优化（如增量更新、分布式部署），但却完整覆盖了 GraphRAG 的核心逻辑：从文本中 “榨取” 结构化知识，用图谱打破信息割裂，用社区聚类实现全局聚合。

回过头看，GraphRAG 的价值从来不是 “替代 RAG”，而是补全 RAG 的能力边界：当传统 RAG 卡在 “分块割裂”“全局查询难” 的瓶颈时，GraphRAG 用 “实体 - 关系” 的范式给出了新解法。比如在医疗领域，它能关联 “疾病 - 症状 - 药物” 的复杂关系；在教育领域，它能梳理 “知识点 - 考点 - 例题” 的知识脉络；在企业知识库中，它能聚合 “产品 - 功能 - 客户反馈” 的全维度信息。

如果你想将这个系统落地到实际项目中，有 3 个方向可以优先优化：