1. GraphRAG

1.1 什么是GraphRAG

GraphRAG既指一种RAG方法，也指微软的开源项目，在这篇文章中，主要指微软的这个开源项目。我们也将通过GraphRAG的实践来了解其原理，并和传统的RAG进行效果的对比。 在GraphRAG的首页，是这么来介绍这种方法的：GraphRAG 是一种结构化的、分层的检索增强生成（RAG）方法，而不是使用纯文本片段的语义搜索方法。GraphRAG 过程包括从原始文本中提取出知识图谱，构建社区层级(这种结构通常用来描述个体、群体及它们之间的关系，帮助理解信息如何在社区内部传播、知识如何共享以及权力和影响力如何分布)，为这些社区层级生成摘要，基于这些，提升RAG的能力 在这段话中，“纯文本片段的语义搜索方法”可以理解为基础RAG，而GraphRAG则首先从文本中提取知识图谱，并利用知识图谱式对RAG进行增强。 通过微软的研究人员发表了论文《From Local to Global: A Graph RAG Approach to Query-Focused Summarization》可以更加细致的了解GraphRAG的来龙去脉。首先，明确GraphRAG的出发点——解决传统RAG遇到的问题：在处理全局查询时表现不佳。传统RAG在面对需要对整个文本集合进行全面理解的全局问题时，往往难以提供高质量的回答。GraphRAG通过构建实体知识图和预先生成社区摘要来克服这一限制，从而提高答案的全面性和多样性。

1.2 GraphRAG的原理

结合论文和官方文档，GraphRAG的基本流程如下图： 分为两阶段：索引阶段和查询阶段

1.2.1 索引阶段

索引阶段包含了如下的操作：

1. 构建TextUnits。通过文本抽取、切片和embedding，最终转化为TextUnits。TextUtils是接下来做图抽取的基本单元，可以看作是传统RAG的Chunk。这一阶段的流程如下： create_base_text_utils.parquet文件保存了这个阶段的处理结果，如下图：
2. 图抽取。在这个阶段将分析每个TextUnit并提取出图的基本要素：Entity（实体）、Relationship（关系）以及TextUnit对应的Claims（声明），这个阶段的基本流程如下： 图抽取可以细分为以下的几个步骤：

• 实体和关系的抽取 将通过大模型从每一个TextUnit中抽取实体和关系。这步的输出是包含一系列实体（包括名称、类型和描述）和关系（包含源、目标和描述）。同样名称和类型的实体以及同样源、目标的关系进行合并操作，在合并操作中，这些被合并的实体和关系的描述将以列表的形式存储。
• 实体和关系的总结 对于上一步中合并实体、关系生成的各自的描述列表，将利用大模型对这个列表进行总结，这样所有的实体和关系都将拥有一个简洁的描述。
• 声明(Claims)提取和发布 抽取后生成的对应文件为create_base_extracted_entities.parquet文件。文件内容只有1行，对应的是entity_graph，可以看到其是一个GraphML格式的图表示。

1. 图增强。 在第2步我们已经获取了一个可用的图，在图增强这步将进一步挖掘这个图，来获取更多的信息。这里主要有两个步骤：社区发现和图嵌入（Node2Vec），如下图所示：

• 社区发现 在这步中，使用Hierarchical Leiden算法生成社区。社区的个数通过配置阈值来控制。
• 图Embedding 在此步骤中，使用 Node2Vec 算法生成图的向量表示。这将使我们能够理解图的隐式结构，并在查询阶段提供一个额外的向量空间，用于搜索相关概念。
• 图表格发布 上面的步骤完成后，将生成最终的实体和关系表。 社区发现的结果保存在create_final_communities.parquet文件中，下面是文件的部分内容： 每行是一个社区的信息，包括所属层级，所包含的关系id以及TextUnit ID。 这个流程同样还会生成最终的实体表和关系表，对应的文件分别为create_final_entities.parquet 和 create_final_relationships.parquet。 实体表每一行代表一个实体，内容包括了描述和实体描述的embedding，如下图： 也同样包含了id、名称、关联的TextUnit id 同时，也保存了实体的类型 关系表每一行代表一个关系，包含了起点、起点度数、终点、终点度数，同样也包含了关联TextUnit id

1. 社区总结 我们已经有了实体和关系的图谱、实体的社区层次结构以及node2vec生成图的嵌入式表达。 在这个步骤中，基于社区数据生成每个社区的报告，流程如下：

• 生成社区报告 在这个步骤中，将借助LLM为每个社区生成摘要，这样，我们可以理解每个社区包含的独特信息。
• 总结社区报告 在这个步骤中，在通过LLM对社区报告进行总结，进行简化。
• 社区Embedding 在这个步骤中，对社区报告、社区报告总结、社区报告标题进行embedding操作，生成社区的向量表示。 社区总结的实际数据写入create_final_comunity_reports.parquet文件 在表中记录了社区的描述、总结，以及对其做的重要性评级与原因。

1. 文档处理 这里的文档指的是在进行index操作时，input文件夹中的文档。文档处理的流程如下：

• 增加列（仅针对CSV文件） 如果处理的是 CSV 数据，可以配置工作流向文档输出添加额外字段。这些字段应存在于输入的CSV表中。
• 链接到TextUnit 在此步骤中，将每个文档与第一阶段创建的TextUnits链接。这样我们能够理解哪些文档与哪些TextUnit相关，反之亦然。
• 文档Embedding 在这个步骤中，首先重新对文档进行re-chunk操作，注意，这次操作进行overlap，然后为每个chunk生成embedding。然后对chunk的向量进行加权平均（权重根据token数量计算）作为document embedding。这可以帮助我们理解文档之间的隐含关系，并帮助我们生成文档的网络表示。
• 文档表输出 在这个步骤中保存文档表 在“文档处理”这个步骤中，会将处理好的内容保存到create_final_documents.parquet文件 在这个表中，有多少个文档就有多少行。

1. 网络可视化 这步操作，主要是通过高维向量空间的降维来实现可视化，在此不展开。

1.2.2 Query阶段

上面介绍了Index阶段生成图谱以及图谱增强，在Query阶段，GrapyRAG会利用这些生成的信息来更好的回答问题。GraphRAG的Query分为两种：Local Search 和Global Search。

1. Local Search Local Search基于实体进行问答，在查询时通过实体扩展LLM的上下文，因此特别适合针对具体实体的问题（例如：“洋甘菊的治疗属性是什么？”），基本的流程如下图： 对于用户的问题（如果有历史对话，也会带上），Local Search会通过Embedding来匹配抽取出的实体。这些实体作为进入知识图谱的入口点，能够提取进一步相关的细节,如相连实体、关系、实体协变量（与实体相关的变量）和社区报告。此外，它还从原始输入文档中提取与已识别实体相关的相关文本chunk。然后根据配置的上下文窗口利用LLM来构建对用户问题的回答。
2. Global Search Global Search是基于整个数据集的推理。由于原理的限制常规的RAG只能基于点状信息（匹配到的Chunk片段）去回答问题，而不具备总结全局信息的能力。举个例子，针对《西游记》问“哪些妖怪是有背景的？”，常规RAG无法给出高质量的回答。GraphRAG在此类问题上有比较好的表现，因为 LLM 生成的知识图谱的结构可以告诉我们整个数据集的结构（以及主题）。这使得私有数据集能够组织成有意义的语义聚类，并且这些聚类已被预先总结。通过使用我们的全局搜索方法，LLM在响应用户查询时可以使用这些聚类来总结这些主题，并据此回答问题。Global Search的流程如下： Global Search使用社区报告集合作为上下文，使用类似Map-Reduce方式来生成响应。在Map步骤中，社区报告被分割成预定义大小的文本块。然后使用每个文本块生成一个中间响应，其中包含一个观点列表，每个观点都附有一个数字评级，表示该观点的重要性。在Reduce步骤中，从中间响应中筛选出的一组最重要的观点来聚合并用作上下文来生成最终响应。全局搜索响应的质量在很大程度上受到选择用于获取社区报告的社区层级的影响。较低层级的报告较为详细，因此往往会产生更全面的响应，但由于报告数量较多，生成最终响应所需的时间和LLM资源也可能会增多（Token消耗巨大）。

2.GraphRAG 实践

参考GraphRAG官方文档的QucikStart可以通过命令行快速实现一个Demo，这里我们通过python代码来实现。一些预备工作，比如python环境和GraphRAG包安装就不赘述了。

1. 准备好数据跟目录 这个目录将保存配置文件、输入的数据（通常是文档）以及生成的数据、日志数据。这里我们创建一个目录，名为ragxiyou，目录创建好之后,执行命令

python -m graphrag.index --init --root ragxiyou

命令执行成功后，目录结构如下： 还需手动创建一个input目录来保存输入的文档。

1. 配置LLM和Embedding模型 .env文件用于配置大模型的api key。我使用的是本地部署的Qwen2 70B模型（使用了4张80G显存的A800显卡，通过xinfernece部署,如果有条件使用open ai的接口或者Azure代理的open ai的接口，推荐使用4o mini，可以节省成本），因此这里不需要配置api key，只需要配置一个自定义的字符串，如下图： 接下来配置setting.yaml ,主要是配置模型的相关参数，首先是大模型，如下图： 接着是embedding模型，我是在本地部署的bge-m3,写了一个简单的server来提供openai的兼容接口，可以从github获取源码来运行，bge-m3的模型也可以通过huggingface或者国内的模塔社区获得，setting.yaml中关于embedding模型的配置如下图： 另外需要说一下，在llm配置时要关注一下max_token，默认的max_token为4000，我在使用本地部署的qwen2 70B时这个数量会导致请求llm报错，调整到1500时可以正常跑完。
2. 进行Index index过程非常简单，只要输入一行命令即可：

python -m graphrag.index --root ragxiyou

执行命令后，会将每个步骤的日志在后台输出 全部完成后如下图： 在output文件夹中，会有一个以时间戳命名的目录，保存本次index生成的数据

1. 测试Query 完成Index流程后，Query就比较容易了，执行下面的Global Search命令：

python -m graphrag.query \

--root ragxiyou \

--method global \

"孙悟空和牛魔王家族有什么关系?"

GraphRAG给出的答案如下： 可以看到，回答中首先给出了关系概述，比较完整的概括了孙悟空和牛魔王家族各个成员之间的关系，以及牛魔王家族各个成员的关系，作为对比，我们可以看一下常规RAG给出的答案。这里使用Dify快速搭建一个常规RAG应用，并分别使用4o和Qwen2作为llm，作为对比 GraphRAG使用的是Qwen2 70B模型，可以看出

1. 比基于常规RAG的Qwen2 70B模型给出的答案要全面也更精准；
2. 比基于常规RAG的4o模型给出答案也要全面和精准，特别是对关系的描述和总结。 可以看出对于这种全局总结问题，GraphRAG具有一定优势。

3. 总结

本文说明了GraphRAG针对的问题，基本的原理，并通过一个案例实践的GraphRAG的整个过程，并与传统RAG进行了对比。 接下来，将进一步探索的主题：

1. GraphRAG 图谱的可视化；
2. GraphRAG 与LLM交互的部分，Prompt以及Token消耗；
3. GraphRAG 核心流程的源码。