GraphRAG与知识图谱
一、GraphRAG介绍
1.1 什么是 Graph RAG?
Graph RAG(Retrieval-Augmented Generation),是一种基于知识图谱的检索增强技术, 通过构建图模型的知识表达,将实体和关系之间的联系用图的形式进行展示,然后利用大语言模型 LLM进行检索增强。
GraphRAG是微软研究院开发的一种创新型检索增强生成(RAG)方法,基于MIT开源协议,旨在提高大语言模型LLM在处理复杂信息和私有数据集时的推理能力
1.2 GraphRAG诞生背景
传统RAG是将一篇文章打碎拆分为几个小的章节(chunks),然后embedding后存入向量库,在查询阶段,RAG将用户指令挨个在向量库与这些chunks的embedding向量进行相似度匹配,然后输出最匹配的k个作为prompt的上下文(context),无论是在文档预处理进向量库阶段,还是用户查询阶段,都没加考虑各个chunk之间的关联,这就形成了普通RAG技术的先天设计缺陷。
传统rag:
解决外部知识的详情介绍,某些细节的检索。
比如: 比如孔乙己是哪里人?
graphRAG:
跨多个段落,甚至多个文章。
文章中的主要主题是什么?
GraphRAG提出了一种回答总结类问题的算法思路,下面展示了GraphRAG算法的工作流程,包括索引建立阶段(index time)和查询阶段(query time)。
1.3 graphrag的基本概念
- Document(文档)- 系统中的输入文档。这些文档要么代表CSV 中的单独行,要么代表单独的 .txt文件。
- TextUnit(文本块)- 要分析的文本块。这些块的大小、重叠以及它们是否遵守任何数据边界可以在下面配置。一个常见的用例是设置CHUNK_BY_COLUMNS为id,以便文档和 TextUnits 之间存在一对多关系,而不是多对多关系。
- Entity(实体)- 从 TextUnit 中提取的实体。这些实体代表人物、地点、事件或您提供的其他实体模型。
- Relationship(关系)- 两个实体之间的关系。这些关系由协变量生成。
- Covariate(协变量)- 提取的声明信息,其中包含可能受时间限制的实体的陈述.
- Claim(声明)- 代表具有评估状态和时间限制的积极事实陈述,以协变量(Covariates)的称呼在各处使用。
- Community Report(社区报告)- 一旦生成实体,我们就对它们执行分层社区检测,并为该层次结构中的每个社区生成报告。
- Node(节点)- 包含已嵌入和聚集的实体和文档的呈现图形视图的布局信息。
1.3.1 索引建立(index time)
索引建立阶段,属于数据预处理阶段,主要目的是从提供的文档集合中,提取出知识图谱(Knowledge Graph),然后以聚类算法(Leiden),将知识图谱分为数个社区(community),并总结每个社区(community)所表达的含义(community summary)。
graphRAG索引阶段流程图:
1.3.2 Querying过程
从上面的介绍,我们了解到在构建索引的过程中,GraphRAG会生成实体关系图、社区层级结构,以及它们的sumamry、source chunk等各种维度的信息,以向量和结构化的方式进行存储。下面我们介绍在检索时如何使用这些信息来做信息增强。Query分两种类型,分别为Local Search和Global Search。
1.3.2.1 Local Search
local Search是一种基于Entity的回答模式。它结合知识图谱中的结构化数据和输入文档中的非结构化数据,在查询时通过相关实体信息扩展 LLM 上下文。该方法非常适合回答需要理解输入文档中提到的具体实体的问题(例如,“孔乙己和掌柜的之间的关系?”)。
其流程图如下所示:
给定用户查询(或加上对话历史记录),Local Search会从知识图谱中识别出一组与用户输入在语义上相关的实体。这些实体作为进入知识图谱的入口点,能够提取进一步相关的细节,如相连实体、关系、实体协变量(与实体相关的变量)和社区报告。此外,它还从原始输入文档中提取与已识别实体相关的相关文本chunk。然后对这些候选数据源进行优先级排序和过滤,以适应预定义大小的单个上下文窗口,该窗口用于生成对用户查询的响应。
1.3.2.2 Global Search
Global Search是基于整个数据集的推理。常规RAG在处理需要跨数据集聚合信息后进行组合回答的场景时很难有很好的表现。例如,“本文的主题是什么?”这种问题查询效果会很差,因为常规RAG的处理方式是:依赖于数据集中存在语意相似的文本内容的向量检索。如果知识库中没有文本内容包含这个问题的答案,则无法给出高质量的回答。
然而,使用 GraphRAG 可以回答此类问题,因为 LLM 生成的知识图谱的结构可以告诉我们整个数据集的结构(以及主题)。这使得私有数据集能够组织成有意义的语义clusters,并且这些clusters已被预先总结。通过使用我们的全局搜索方法,LLM 在响应用户查询时可以使用这些cluster来总结这些主题,并回答用户对整个数据集的问题。
其流程图如下所示:
给定用户查询(或加上对话历史记录),Global Search使用从图的社区层次结构中指定级别生成的一系列 LLM 社区报告作为上下文数据,以 map-reduce 方式生成响应。在 map 步骤中,社区报告被分割成预定义大小的文本chunks。每个文本chunk然后用于生成一个中间响应,其中包含一个要点列表,每个要点都附有一个表示该要点重要性的数值评级。在 reduce 步骤中,从中间响应中筛选出最重要的要点进行汇总,并将其用作上下文生成最终响应。
全局搜索响应的质量会受到用于社区报告来源的社区层次结构级别的显著影响。较低的层次级别报告更为详细,通常会产生更为全面的响应,但由于报告数量的增加,这也可能增加生成最终响应所需的时间和 LLM 资源。
1.4 Graph RAG 思想一句话总结
Graph RAG 思想: 对用户输入的query提取实体,然后构造子图形成上下文,最后送入大模型完成生成
二、知识图谱介绍
知识图谱(Knowledge Graph)是一种以结构化形式描述现实世界实体及其关系的技术,通过将数据组织为“节点-边-节点”的三元组(如“北京-是-中国首都”),构建出语义关联的网络。
核心组成:
- 实体(Entities):表示具体或抽象的事物,如“李白”“北京”。
- 关系(Relationships):连接实体的边,定义交互方式,如“出生于”“首都”。
- 属性(Attributes):描述实体的特征,如“李白-字太白”“北京-人口2170万”。
- 本体(Ontology):领域内的概念体系与关系约束,如“城市-国家”间的“首都”关系。
示例:在医疗领域,知识图谱可链接“糖尿病”“胰岛素”“高血糖”等实体,通过“治疗方法”“症状”等关系辅助诊断。
应用场景:
- 推荐系统:基于用户兴趣关联商品(如喜欢科幻电影的用户推荐《三体》)。
- 智能问答:解析复杂问题(如“哪些法国导演获得过奥斯卡奖?”)。
- 金融风控:通过企业关联网络识别欺诈风险。
- 医疗健康:辅助诊断(如根据症状推荐可能的疾病及用药)。
三、图数据库与neo4j
3.1 市面上图数据库介绍
3.1.1 排名:
https://db-engines.com/en/ranking/graph+dbms
3.1.2 主流图数据库
3.2 neo4j
neo4j学习地址:
https://www.w3cschool.cn/neo4j/neo4j_need_for_graph_databses.html
3.2.1 docker安装neo4j社区版
docker run -d -p 7474:7474 -p 7687:7687 --name neo4j -v /home/neo4j/data:/data -v /home/neo4j/logs:/logs -v /home/neo4j/conf:/var/lib/neo4j/conf -v /home/neo4j/import:/var/lib/neo4j/import neo4j:5.5.0-community
访问地址:http://localhost:7474/
默认账号密码:
neo4j || neo4j
3.2.1 cql实例
简介:
3.2.2 操作实例
增加一个节点:
create (n:Person {name:"孔乙己",age:31})
带有关系属性:
create (p:Person{name:"孔乙己",age:31})-[: 偷书 { 金额 :3000}]->(n:Person{name:"丁举人",age:35})
删除节点:
create (n:Person {name:"掌柜",age:33});
match (n:Person{name:"掌柜"}) delete n;
-- 根据id删除
match (n:Person) where id(n)=3 delete n
删除关系:
MATCH (p:Person {name: "孔乙己", age: 31})-[f:`偷书`]->(n:Person {name: "丁举人", age: 35}) DELETE f
修改:
加上标签:
match (t:Person) where id(t)=0 set t:衣服 return t;
加上属性:
match (a:衣服) where id(t)=0 set a.衣服="长衫" return a
修改属性:
match (a:衣服) where id(a)=0 set a.衣服="破烂的长衫" return a
查:
match (p:Person) - [:偷书] -> (n:Person) return p,n
效果:
3.2.3 红楼梦示例
红楼梦知识图谱示例:
https://grapheco.org/
贾宝玉知识图谱
薛蟠知识图谱
四、GraphRAG
git地址:
https://github.com/microsoft/graphrag
前置操作:
ollama pull qwen2.5:7b
ollama pull quentinz/bge-large-zh-v1.5
4.1 安装graphRAG
4.1.1 安装 GraphRAG
pip install graphrag
需要 Python 3.10-3.12 环境
4.1.2 创建知识数据文件夹
安装完整后,需要创建一个文件夹,用来存储你的知识数据,目前 GraphRAG 只支持 txt 和 csv 格式。
mkdir -p ./ragtest/input
4.1.3 准备一份数据放在 /ragtest/input 目录下
4.1.4 初始化工作区
首先,我们需要运行以下命令来初始化:
python -m graphrag.index --init --root ./ragtest
运行完成后,在 ragtest 目录下生成以下两个文件:settings.yaml。ragtest 目录下的结构如下:
- settings.yaml:GraphRAG 的核心配置文件,允许用户自定义模型、嵌入模型、存储设置和管道参数,通过 YAML 格式提供灵活的配置选项;
4.2 修改配置文件支持本地部署大模型
首先确保已安装 Ollama。
安装qwen2.5 7b和bge-large-zh-v1.5;
4.2.1 修改.setting.yaml
右边为修改后的内容:
注意这里:默认的chunks.size是1200。 较大的块会导致输出保真度较低,参考文本意义较小;使用较大的块可以大大缩短处理时间。
4.2.2 运行 GraphRAG 构建知识图谱索引
python -m graphrag.index --root ./ragtest
构建知识图谱的索引需要一定的时间,构建过程如下所示:
成功:
4.3 修改源码支持本地部署大模型
接下来修改源码,保证进行 local 和 global 查询时给出正确的结果。
4.3.1 修改成本地的 Embedding 模型
修改源代码的目录和文件:
/root/miniconda3/lib/python3.10/site-packages/graphrag/llm/openai/openai_embeddings_llm.py
改动如下:
4.3.2 修改 Embedding 模型
修改源代码的目录和文件:
/root/miniconda3/lib/python3.10/site-packages/graphrag/query/llm/oai/embedding.py
修改如下:
4.4 GraphRAG 效果测试
4.4.1 local 查询
执行命令:
python -m graphrag.query --root ./ragtest --method local "孔乙己和掌柜的关系是什么?"
4.4.2 global 查询
执行命令:
python -m graphrag.query --root ./ragtest --method global "本文主题是什么?"
4.4.3 提示微调 prompt tuning
参加【提示微调 prompt tuning.txt】
五、GraphRAG详情
GraphRAG 采用了知识图谱的理念,在底层实现中同时使用了图数据库和向量数据库。图数据库存储有关实体和实体间关系的数据,而向量数据库则存储与文本单元相对应的嵌入向量空间。
本地搜索(Local Search):基于实体的推理
本地搜索方法将知识图谱中的结构化数据与输入文档中的非结构化数据结合起来,在查询时用相关实体信息增强 LLM 上下文这种方法非常适合回答需要了解输入文档中提到的特定实体的问题(例如,"洋甘菊有哪些治疗功效?)
全局搜索(Global Search): 基于全数据集推理
根据LLM生成的知识图谱结构能知道整个数据集的结构(以及主题)这样就可以将私有数据集组织成有意义的语义集群,并预先加以总结。LLM在响应用户查询时会使用这些聚类来总结这些主题;
五、将graphRAG生成的文件导入到neo4j查看
具体实现【参见demo】。
查看graphrag索引后,各个实体之间的关系:
六、GraphRAG的适用场景
6.1 总结对比:GraphRAG vs 传统 RAG
场景类型 | 传统 RAG 的局限性 | GraphRAG 的优势 |
---|---|---|
跨文档分析 | 信息碎片化,难以关联全局语义 | 通过知识图谱实现全局语义关联 |
实时数据处理 | 全量索引重建成本高 | 支持增量更新,降低维护开销 |
多模态整合 | 依赖单一文本模态,异构数据处理难 | 统一图结构融合文本/表格/图谱数据 |
复杂推理任务 | 单跳检索,难以支持多步逻辑推理 | 基于图的多跳推理能力 |