微软开源GraphRAG技术的部署测试和效果评价

一、GraphRAG基本介绍

GraphRAG 是一种基于图的检索增强方法，由微软开发并在2024年7月初开源，最为新鲜热乎的知识图谱与大模型融合的前沿开源技术。它通过结合LLM和图机器学习的技术，从非结构化的文本中提取结构化的数据，构建知识图谱，以支持问答、摘要等多种应用场景。GraphRAG的特色在于利用图机器学习算法进行语义聚合和层次化分析，从而能够回答一些高层次的抽象或总结性问题，这是常规RAG系统的短板。

二、GraphRAG的核心流程

GraphRAG的核心在于其处理流程，包含2个阶段：Indexing和Querying。

• 在Indexing阶段：GraphRAG将输入文本分割为多个可分析单元（称为TextUnits）。使用LLM提取实体、关系和关键声明。然后通过层次聚类技术（例如Leiden算法）对图谱进行社区划分，并生成每个社区的摘要
• 在Querying阶段：这些结构被用来提供材料，以作为LLM的context来回答问题。查询模式包括全局搜索和局部搜索

  全局搜索：通过利用社区的总结来推理关于语料库整体问题的答案

  局部搜索：通过扩展到特定实体的邻居和相关概念来推理关于特定实体的问题

  它通过构建知识图谱和社区分层，以及利用图机器学习技术，增强了对复杂信息的问答性能，尤其是在需要全面理解大型数据集或单一大型文档的语义概念时。

  

三、GraphRAG的安装与测试

• graphrag安装

  pip install graphrag

环境依赖 pytorch2.3.0-tensorflow2.16.1-gpu-py310-cu121-ubuntu22.04

推理GPU配置

• 创建文件并初始化索引

  mkdir -p ./ragtest/input

  将待构建图谱的文档（《红楼梦》第18回-元春省亲，见附录），存放在input目录下（对pdf文件进行格式转换，目前graphrag仅支持三种格式，csv txt和markdown）

  文本格式encoding为utf-8

  初始化环境变量

  python -m graphrag.index --init --root ./ragtest

  配置settings.yaml文件中的llm和embedding（将llm和embeddding中应用的大模型切换为deepseek和智谱AI的embedding-2，这两个都提供百万级的免费试用token）

  

对文件创建索引

python -m graphrag.index --root ./ragtest

(耗时20多分钟，消耗token50万左右，要是用openai的api那可太贵了

查询阶段

数据查询分为高级查询和具体问题查询，高级查询比如问主题，使用global模式。具体问题查询比如问细节，使用local模式数据查询

高级问题,method参数使用global

局部查询，method参数用local

部分回答示例，可以看到在红楼梦这一回的人物关系理解和检索上，效果满足需求。

python -m graphrag.query --root ./ragtest --method global '是谁让宝玉来园中玩耍的'

SUCCESS: Global Search Response: 宝玉来园中玩耍的原因涉及家族内部的亲情和支持，以及家族领导者的管理和教育。

首先，贾母对宝玉的关爱体现在日常的互动和特殊时刻的经济援助，这包括允许他在园中自由玩耍，体现了家族内部的亲情和支持 [Data: Reports (15)]。

其次，贾政作为家族的领导者和文学讨论的推动者，对宝玉进行管理和教育，包括安排他在园中的活动 [Data: Reports (20)]。

综合来看，宝玉来园中玩耍是贾母的关爱和贾政的管理共同作用的结果。

python -m graphrag.query --root ./ragtest --method local '是谁让宝玉来园中玩耍的'

SUCCESS: Local Search Response: 宝玉来园中玩耍是由贾母安排的。根据提供的数据，宝玉因思念秦钟而忧戚，贾母常命人带他到园中来戏耍 [Data: Sources (4)]. 这表明贾母关心宝玉的情绪状态，并采取行动帮助他缓解忧愁。

python -m graphrag.query --root ./ragtest --method global '总结下园中的景观'

SUCCESS: Global Search Response: ### 翠嶂园林社区的景观设计

翠嶂园林社区以翠嶂为核心，围绕其展开一系列的园林设计和文化活动。翠嶂作为园林中的一座山，其设计目的是为了遮挡视线并增加园林的趣味性 [Data: Reports (11)]。此外，亭子及其周边景观以‘亭子’为中心，周围环绕着‘清溪泻雪’和‘石磴穿云’的自然景观。亭子不仅是讨论命名的地点，也是连接这些自然景观的核心 [Data: Reports (1)]。

自然与人工的融合

宝玉对自然和人工的差异有深刻理解，并质疑人工造作的美学价值。他对杏花村和田庄的命名和布局提出了自己的见解，显示出他对自然美的独特追求和审美品味 [Data: Reports (15)]。宝玉还能够识别和讨论各种植物，如杜若蘅芜、金す草等，显示出他的知识渊博和对自然界的深刻理解。这些讨论不仅丰富了社区的文化内涵，也反映了宝玉对自然美的追求 [Data: Reports (15)]。

院落与植物景观

院落及其植物景观以‘院落’为中心，是一个集休息与观赏植物于一体的空间。院落与‘碧桃花’和‘西府海棠’等植物有着紧密的地理和功能关系 [Data: Reports (13)]。青溪和花园水系统社区以青溪为中心，青溪是一个复杂的花园水系统，其源头来自东北山坳，流经村庄，最后返回花园 [Data: Reports (17)]。

建筑与自然环境的结合

清凉瓦舍和大主山社区以清凉瓦舍为中心，清凉瓦舍是一个独特的建筑结构，位于大主山的分支点，周围环绕着各种异草 [Data: Reports (5)]。这些设计不仅增强了社区的自然美感，也体现了人与自然和谐共存的理念。

python -m graphrag.query --root ./ragtest --method local '对园中出现的景观进行美感排序'

SUCCESS: Local Search Response: 在探讨园林中的景观美感时，我们可以从多个角度进行分析，包括自然元素、建筑特色以及文化内涵等。以下是对园中出现的景观进行美感排序的几个关键点：

自然元素的美感

自然元素如山水、植物等，往往给人以宁静和和谐的感觉。例如，“翠嶂”作为园林中的一座山，不仅增加了园林的趣味性，还因其自然形成的美丽而受到赞赏[Data: Entities (17); Relationships (55, 107)]。此外，“清凉瓦舍”周围的异草和自然环境融为一体，增添了独特的美丽和香气[Data: Entities (69); Relationships (118, 119)]。

建筑特色的美感

建筑特色如桥梁、亭台楼阁等，展现了人类与自然和谐共存的艺术。例如，“柳阴中的桥”通过这座桥可以到达不同的路径，连接到一所清凉瓦舍，展现了路径选择的决策能力和对园林布局的熟悉[Data: Entities (68); Relationships (43)]。

文化内涵的美感

文化内涵如诗词、历史故事等，为园林增添了深厚的文化底蕴。例如，“游幸”这一活动不仅决定了园林的命名和装饰，还体现了贵妃的权威和影响力[Data: Entities (9); Relationships (103)]。

综合美感排序

综合考虑自然元素、建筑特色和文化内涵，我们可以对园中景观进行如下美感排序：

1. 翠嶂：因其自然形成的美丽和增加园林趣味性的功能[Data: Entities (17); Relationships (55, 107)]。
2. 清凉瓦舍：周围异草和自然环境融为一体，增添了独特的美丽和香气[Data: Entities (69); Relationships (118, 119)]。
3. 柳阴中的桥：展现了路径选择的决策能力和对园林布局的熟悉[Data: Entities (68); Relationships (43)]。
4. 游幸：体现了贵妃的权威和影响力，决定了园林的命名和装饰[Data: Entities (9); Relationships (103)]。

   通过这种排序，我们可以更深入地理解园林中各个景观的美感价值，并欣赏其背后的自然、建筑和文化元素。

四、GraphRAG流程解析

Indexing阶段——

Source Documents → Text Chunks：将源文档分割成文本块；

Text Chunks → Element Instances：使用大模型从每个文本块中提取图节点和边的实例；

Element Instances → Element Summaries：使用大模型为每个图元素生成摘要；

Element Summaries → Graph Communities：使用社区检测（leiden算法）将图划分为社区；

Graph Communities → Community Summaries：使用大模型为每个社区生成摘要报告（reports），这些摘要包含一个概述，以及引用社区子结构中的关键实体、关系和声明；

Community Summaries → Community Answers → Global Answer：使用社区摘要生成局部答案，然后汇总这些局部答案以生成全局答案。

最终生成的图数据是以graphml语法的字符串形式，存储在.parquet文件中

Global search阶段——

Global Search是基于整个数据集的推理。常规RAG在处理需要跨数据集聚合信息后进行组合回答的场景时很难有很好的表现。例如，“数据中的top 5主题是什么？”这种问题查询效果会很差，因为常规RAG的处理方式是：依赖于数据集中存在语意相似的文本内容的向量检索。如果知识库中没有文本内容包含这个问题的答案，则无法给出高质量的回答。

然而，使用 GraphRAG 可以回答此类问题，因为 LLM 生成的知识图谱的结构可以告诉我们整个数据集的结构（以及主题）。这使得私有数据集能够组织成有意义的语义clusters，并且这些clusters已被预先总结。通过使用我们的全局搜索方法，LLM 在响应用户查询时可以使用这些cluster来总结这些主题，并回答用户对整个数据集的问题。

在global查询模式下的数据来源是create_final_nodes.parquet、create_final_entities.parquet和create_final_community_reports.parquet。

查询流程为：

1.从create_final_community_reports.parquet文件中获取选中的community_report数据；

2.基于选中的community_reports列表批量请求大模型（这里由于community_reports内容较多，会耗费较多的大模型Token），让大模型基于每个community_report回答用户的问题；（map过程）

3.把上述获取的大模型返回结果列表整合成一个完整的答案并返回给用户，这个整合过程也是通过大模型完成的。（reduce过程）

Local search阶段——

给定用户查询（或加上对话历史记录），Local Search会从知识图谱中识别出一组与用户输入在语义上相关的实体。这些实体作为进入知识图谱的入口点，能够提取进一步相关的细节,如相连实体、关系、实体协变量（与实体相关的变量）和社区报告。此外，它还从原始输入文档中提取与已识别实体相关的相关文本chunk。然后对这些候选数据源进行优先级排序和过滤，以适应预定义大小的单个上下文窗口，该窗口用于生成对用户查询的响应。

local查询模式下，与global模式相比，多了几个数据来源create_final_text_units.parquet和create_final_relationships.parquet

1.基于用户的问题通过语义相似度计算相似度高的实体Entity；

2.基于选中的Entity获取对应的Community内容；

基于聊天上下文和community_content构建prompt内容，调用大模型并将结果返回给用户。

五、GraphRAG的官方测评和优化方法

微软开源博客上对于官方测试文档的评价

基于微软官方发布的博客来看，微软采用了一个LLM评分器来给GraphRAG和Baseline RAG的表现进行评估。

基于一系列的指标，包括全面性（提取的上下文内容的完整性，包括隐含的信息）、人类赋权（提供来源的材料或其他上下文信息）和多样性（提供不同的视角或问题的角度）。从初步评测结果来看，GraphRAG在这些指标上都优于Baseline RAG。

除此之外，微软还实用了SelfCheckGPT来进行忠实度的绝对测量，来确保基于原材料的事实性和连贯性结果。结果也显示出GraphRAG在忠诚度上达到了与Baseline RAG类似的水平。目前微软也在开发一个评估框架，用来进一步衡量上述问题类型的性能。

从使用GraphRAG对《红楼梦》中出场人物最多章节《元春省亲》的indexing和querying过程来看，可以看到GraphRAG的优缺点都非常明显。

优点——

1.知识全面：得益于在Indexing过程中构建的实体关系图、社区、原始文档切片等信息，在内容检索时（包含向量检索与结构化数据检索），它能够获取到更丰富、更多层的信息，提供更全面的回答；

2.有据可查：在生成各个索引的过程中，都引入了源文档chunk，保持对源数据的忠诚，使得回答可靠。

缺点——

1.耗时长、成本高：在Indexing的过程中，需要频繁调用LLM（例如抽取实体、实体和关系的总结、社区总结等）并调用外部算法（例如社区检测），会使得索引时间拉长，并且LLM调用消耗的tokens过高；

2.扩展性：在数据集膨胀到更高数量级时，除了耗时与成本更长外，其构建Indexing过程的稳定性也需要进一步测试；

3.延迟高：由于在检索时需要进行多路召回、过滤和排序，所以在回答问题延迟上也会相应增加；

4.准确性不够：在查询和时间日期等相关的实体时，准确性下降较大；

总的来说，GraphRAG还是一个非常强大的工具，提供了一整套完成的pipeline来完成非结构化文本进行知识抽取、索引构建和知识问答的流程，提高了从非结构化数据中提取Insight的能力，弥补现有RAG模式的不足。但它在耗时、成本、扩展性等方面仍会是在应用到生产环境中的几大挑战点。

针对其他场景的非结构化文本进行GraphRAG图谱构建和知识抽取，考虑的优化方法：

1.采用本地部署的ollama大模型进行文档解析和抽取，更好地对照问答结果；

2.图谱构建时的实体抽取和指代消解等流程，考虑采用neo4j的graph builder组件，或者蚂蚁开源的图谱抽取大模型oneke（预计下一版本有一个基于llama3-8b微调的，支持（半）开放抽取，目前是schema约束的抽取）

3.写prompt优化输出。