From Local to Global: A Graph RAG Approach to Query-Focused Summarization 论文学习 + 相关内容笔记

检索：根据用户的查询内容，从外挂知识库获取相关信息。具体来说，就是将用户的查询通过嵌入模型转换成向量，以便与向量数据库中存储的知识相关的向量进行比对。通过相似性搜索，从向量数据库中找出最匹配的前 K 个数据。
增强：将用户的查询内容和检索到的相关知识一起嵌入到一个预设的提示词模板中。
生成：将经过检索增强的提示词内容输入到大语言模型（LLM）中，以此生成所需的输出。流程图如下所示：

与普通RAG系统类似，GraphRAG整个Pipeline可划分为索引与查询两个阶段。索引过程利用LLM提取出节点（如实体）、边（如关系）和协变量（如 claim），然后利用簇检测技术对整个知识图谱进行划分，再利用LLM进一步总结。

1.3 当前RAG技术存在的问题

普通的RAG技术无法回答针对整个语料库的摘要性问题QFS。

对于QFS问题，使用RAG增强后的文本长度很容易超出已有的LLM模型的文本窗口大小。如果增大文本窗口，也容易导致信息迷失

相比之下，使用Graphrag技术可以综合QFS和RAG的优势：

1.使用预索引来支持RAG完成目标的全局总结，回答用户的总结性、概括性的问题，如“××文章的核心主题是什么？”

2.RAG 技术通过从外部知识库中检索相关信息，可以扩充要索引的源文本的数量

1.4 研究重点

论文探索了一种新的方法，利用图的模块性和簇检测算法，将图划分为由紧密相关节点组成的簇。这种方法有助于更有效地分析和理解图中的信息，从而提高信息处理的效率和准确性：

模块性（modularity）：是指图中节点可以自然地分成不同的群组或“簇”，这些群组内部的节点之间连接紧密，而群组之间的节点连接相对较少
簇检测算法（community detection algorithms），这些算法可以将图划分为若干个模块化的簇。在这些簇中，节点之间的关系更加紧密，形成一种自然的群组

2 GraphRAG处理流程和方法

2.1 整体流程

Source Documents
描述：原始输入数据，通常是大量的文本文件或文档。
操作：从源文档中提取文本并进行分块（chunking）。
Text Chunks
描述：从源文档提取并分块后的文本。每个块可能代表文档中的一小部分内容。
操作：对这些文本块进行领域定制的摘要（domain-tailored summarization），生成更具体的内容。
Element Instances
描述：经过第一次领域定制摘要后的元素实例，包含更具体的信息片段。
操作：再次进行领域定制的摘要，以进一步精炼和组织内容。
Element Summaries
描述：经过多次领域定制摘要后形成的元素摘要，代表了信息的精简形式。
操作：使用社区检测算法（community detection）将元素摘要划分成具有模块化特性的图社区（Graph Communities）。
Graph Communities
描述：通过社区检测算法得到的图社区，每个社区包含了密切相关的元素摘要。
操作：对每个图社区进行领域定制的摘要，生成社区级别的摘要（Community Summaries）
Community Summaries
描述：代表每个图社区的综合摘要，提供了社区内信息的整体视图。
操作：根据特定的查询需求，进行基于查询的摘要（query-focused summarization），得到社区答案（Community Answers）。
Community Answers
描述：针对查询从每个社区生成的答案，包含了与查询最相关的信息。
操作：汇总所有社区答案，进行进一步的基于查询的摘要，得到全局答案（Global Answer）。
Global Answer
描述：最终生成的答案，综合了所有社区的答案，提供了对查询的全面且简洁的回答。

Indexing Time 阶段：将大量文本数据进行预处理和组织，通过多次摘要和社区检测算法，将信息划分成结构化的模块，以便后续查询时高效检索和处理。
Query Time 阶段：在收到查询请求后，利用预处理阶段生成的图社区和摘要，快速生成与查询相关的答案。这个阶段的重点是针对特定查询需求。

2.2 具体流程

2.2.1 Source Documents → Text Chunks

在设计信息提取和处理系统时，文本块分割粒度的重要性:

文本块粒度选择：在分割源文档时，需要考虑文本块的长度（或粒度）。较短的文本块可能需要更多的 LLM 调用，但在信息提取方面可能更有效。
上下文窗口限制：LLM 有一个上下文窗口的限制，过长的文本块可能会导致部分信息无法被有效提取，影响回忆率。

在具体的实验中，较短的文本块（如 600 tokens）比较长的文本块（如 2400 tokens）能够提取出更多的实体引用。平衡回忆率和精确度：在设计信息提取系统时，需要找到回忆率和精确度之间的平衡，既能获取尽可能多的相关信息，又能确保提取的信息准确。

2.2.2 Text Chunks → Element Instances

文本块的信息提取流程，利用大型语言模型（LLM）从文本中提取图节点和边的信息，并根据不同领域的需求进行定制。

该流程的关键点包括：

多部分提示：分阶段提取实体和关系。首先是识别文本中所有的实体，获取它们的基本信息，然后再去识别这些实体之间的关系，这包括明确指出关系的来源和目标实体，以及这些关系的具体描述。
领域定制：默认的提示是通用的，适用于一般的命名实体提取。但是，对于某些专业领域，需要提供特定的示例，使模型能更精准地提取相关的实体和关系。
协变量提取：除了实体和关系外，系统还支持提取附加的相关信息（协变量），这些信息可以帮助更全面地理解提取出的节点实例。例如，某个实体作为主语或宾语的具体语句、时间信息等。
多轮信息收集：

为了确保尽可能完整的提取信息，系统进行多轮信息收集。在每轮中，如果有遗漏的实体，系统会通过提示引导模型再一次提取。

系统首先询问模型是否已经提取了所有实体，使用对数几率偏差（logit bias）来确保模型必须明确回答“是”或“否”。如果模型确认有遗漏的实体，系统会给出进一步的提示，鼓励模型继续寻找和提取遗漏的信息。

通过这种多轮的收集和检查，系统可以使用更大的文本块进行处理，从而减少 LLM 调用的次数，同时保证提取信息的质量和完整性。

2.2.3 Element Instances → Element Summaries

进行进一步的总结，将提取的每个实例级的信息整合成更简洁、更具描述性的文本块。这个过程涉及对相关实例的进一步处理，生成每个图元素的总结信息一个潜在的问题是，LLM 可能会以不同的格式或方式提取同一个实体的信息。这可能导致同一实体在图中被表示为多个不同的节点，造成数据的冗余和不一致。

虽然存在重复和变体的问题，但在接下来的步骤中，系统会检测和总结所有相关实体的“社区”。由于 LLM 能够识别出不同名称下的相同实体，只要这些变体之间有足够的连接性，系统就能够处理这些变体，确保图结构的完整性和一致性。

这种方法利用丰富的描述性文本来表示图中的节点，使得系统能够处理复杂的、可能包含噪声的数据结构。该方法采用了更丰富的描述性文本，这使得它能够更好地处理复杂和不一致的信息，同时保留了传统知识图谱的推理能力。

2.2.4 Element Summaries → Graph Communities

之前的步骤创建的索引，可以被构造为同质无向加权图，这种图结构中，所有节点和边都是同质的，连接关系没有方向，且每条边都带有权重。这种图模型用于表示实体及其之间的关系。

对于这样的图，可以使用社区检测算法将图划分为节点社区，这些社区内的节点之间的连接比与图中其他节点的连接更强。

Leiden 算法是一种社区检测算法，因其能够在处理大规模图时有效地发现层次结构而被选中。层次结构的发现有助于更深入地理解数据中不同层次的关系和相互作用。

在层次结构中，每一层都将图中的节点分为不同的社区，且每个节点只属于一个社区（互斥），所有节点都被分配到某个社区（集体穷尽）。这种划分方式允许对图进行分层处理和总结，从而提高了处理和总结的效率。

该图展示了使用Leiden算法在MultiHop-RAG数据集上检测到的图社区结构：

层次
根社区在第0层次，这是初始的分层划分，展示了整个网络的最高层次的社区分布。
子社区在第1层次，进一步细分根社区，揭示了更详细的内部结构。
节点
每个节点代表一个实体。节点的大小与它们的“度”成正比，度越高，节点越大，意味着该实体与更多其他实体有关联。每个节点的颜色代表其所属的社区，不同颜色对应不同的社区组。
节点布局
使用OpenORD和Force Atlas 2布局算法进行布局，这些算法通过模拟引力和斥力使节点自动排列，尽可能地减少节点间的重叠，确保相关节点之间的关系清晰可见。

2.2.5 Graph Communities → Community Summaries

生成社区报告，这些报告旨在帮助理解大型数据集的全局结构和语义，并且可以作为回答全局查询的图基索引的一部分。下面是对这个过程的逐步解释：

目的：

报告式摘要：创建关于Leiden层次结构中每个社区的报告式摘要。
适用性：这种方法适用于非常大的数据集。
用途：
- 独立价值：摘要本身有助于理解数据集的整体结构和语义。
- 辅助理解：即使没有具体的问题，用户也可以通过浏览不同层级的社区摘要来发现感兴趣的总体主题。
- 查询回答：摘要还可以被用作图基索引的一部分，以回答全局查询。

叶级社区摘要生成：从最底层开始，逐步构建摘要，确保最重要的信息被包含在内。

元素摘要：叶级社区由节点、边和协变量组成。
优先级排序：根据节点的度数（连接其他节点的数量）对边进行排序。
摘要生成：
- 按照优先级顺序，从高到低添加源节点、目标节点、关联的协变量以及边本身的描述到LLM（Large Language Model）的上下文窗口中。
- 迭代添加直到达到上下文窗口的令牌限制。

更高级别的社区摘要生成：在更高层级上，如果需要减少摘要的长度，则采用子社区的摘要来代替单个元素的摘要，以保持上下文的连贯性和重要性。

元素摘要的处理：
- 如果所有元素摘要的总长度在上下文窗口的令牌限制内，则直接添加所有的元素摘要。
- 如果超出限制，则按照子社区元素摘要的长度从长到短进行排序。
- 逐渐用较短的子社区摘要替换较长的元素摘要，直到所有摘要适合上下文窗口的大小。

2.2.6 Community Summaries → Community Answers → Global Answer

当用户提出查询时，给定了社区层级，可以通过以下多阶段的过程生成最终答案：

准备社区摘要：
随机打乱和分块：首先，将社区摘要随机打乱，以确保信息的均匀分布。然后，将这些摘要分成预定大小的块。这样做的目的是将相关信息分散到多个块中，而不是将其集中在单个上下文窗口中，从而避免信息的丢失。
映射社区答案：
- 生成中间答案： 对每个块并行生成中间答案。语言模型（LLM）会处理这些块，生成每个块的答案。
- 评分： 同时，LLM 会为每个生成的中间答案提供一个0到100之间的分数，这个分数表示答案对回答目标问题的帮助程度。分数为0的答案会被过滤掉，意味着这些答案被认为对问题没有帮助。
整合为全球答案：
- 排序和选择： 将所有中间答案按帮助程度的分数降序排序。然后，逐步将最有帮助的答案添加到新的上下文窗口中，直到达到令牌限制。
- 生成最终答案： 使用这个最终的上下文窗口生成返回给用户的全球性答案。
随机打乱：
假设有一个包含 100 个社区摘要的列表，随机打乱过程可能会把原本在前面或后面的摘要位置交换，使得每个块中包含不同的信息点，从而避免了信息集中或遗漏的问题。最终，你会得到若干个随机顺序的摘要块，这些块将用于生成中间答案和最终答案。

3 模型评估

3.1 数据集选择

博客转录文本数据集：

总词符数：约 100 万个词符。
文本块数量：1,669 个文本块。
每个文本块大小：600 个词符。
重叠词符：相邻文本块之间有 100 个词符重叠。

新闻文章数据集：

总词符数：约 170 万个词符。
文本块数量：3,197 个文本块。
每个文本块大小：600 个词符。
重叠词符：相邻文本块之间有 100 个词符重叠。

3.2 查询设计

使用LLM来生成查询问题

目标：评估 RAG 系统在处理具有更广泛语境的任务时的有效性。即，评估系统在需要理解整个数据集内容的情况下的表现，而不仅仅是处理特定文本片段。

方法：以活动为中心，出发点是围绕用户和他们要执行的任务来进行设计。

流程：

给定数据集的描述：首先，需要对数据集进行简短描述。这帮助系统了解数据集的主题和内容范围。
识别潜在用户和任务：利用 LLM 来识别可能对数据集感兴趣的用户，以及每个用户可以执行的任务。这一步的重点是找出数据集的应用场景和用户需求。
生成问题：对于每个用户和任务的组合，要求 LLM 生成多个问题。这些问题需要使用整个数据集的内容进行回答，而不是针对单个文本细节。

参数设置：

每个步骤使用了 N = 5 这个参数值，识别出 5 个潜在用户，每个用户有 5 个潜在任务，对于每个（用户、任务）组合，生成 5 个问题，这总共为每个数据集生成了 5×5×5=125 个测试问题

潜在用户、任务、问题，由LLM根据对目标数据集的简短描述生成

3.3 实验条件

研究者比较了六种不同的条件，具体如下：

Graph RAG：这一方法基于图结构，将信息组织成不同层次的社区，以此来回答用户的问题。它使用了四个层次的社区（C0、C1、C2、C3）：
- C0：使用根级别（最高级别）社区的总结来回答用户的问题。这是数量最少的社区层次。
1. C1：使用高级别社区的总结来回答用户的问题。这些社区是 C0 的子社区，如果 C0 中不存在，则投射为 C0 的社区。
2. C2：使用中间级别社区的总结来回答用户的问题。这些社区是 C1 的子社区，如果 C1 中不存在，则投射为 C1 的社区。
3. C3：使用低级别社区的总结（数量最多）来回答用户的问题。这些社区是 C2 的子社区，如果 C2 中不存在，则投射为 C2 的社区。
Text Summarization (TS)：这一方法直接对源文本应用了一种类似 map-reduce 的方法进行文本摘要。它将源文本进行重新洗牌和分块，用于 map-reduce 摘要阶段。
Naïve “Semantic Search” RAG Approach (SS)：这是一个简单的 RAG 实现方法。文本块被检索并添加到可用的上下文窗口，直到达到指定的令牌限制为止。

条件 C0-C3 所依赖的图索引是使用通用提示（generic prompts）创建的，但也使用了实体类型和 few-shot 示例（few-shot examples）是针对数据域进行定制。

这意味着，虽然提示是通用的，但为确保适用于特定数据集（例如播客、新闻），对提示和示例进行了适当的调整。

3.4 评估指标

Comprehensiveness（全面性）

全面性是评估生成内容质量的一个关键指标，尤其是在复杂问题的回答中。它确保回答不仅包括了问题的核心要点，还涵盖了相关的所有细节和背景信息。

Diversity（多样性）

多样性确保生成内容不仅仅是单一的观点或信息，而是包括了多种视角和见解。这有助于提供更全面和丰富的回答，满足不同读者的需求。

Empowerment（赋能性）

赋能性衡量生成回答对读者的实际帮助程度。有效的回答应能够使读者更好地理解话题，并能够根据提供的信息做出明智的决策或判断。

Directness（直接性）

直接性确保生成回答能够明确、清晰地回应问题的核心，避免模糊或偏离主题。它帮助读者迅速获取所需的信息。

比较方法：头对头比较，即直接比较

GraphRAG（C2）和SS（Naive Rag）的比较：

在全面性、多样性、直接性方面，更强

3.5 配置

这里主要指上下文窗口配置：大型语言模型处理文本数据时，模型在一次处理中可以访问的文本片段的最大长度

我们的目标是确定我们的基线条件（SS）的最佳上下文大小，然后对所有查询时LLM的使用统一使用它。为此，我们测试了四种上下文窗口大小： 8k、16k、32k和64k。令人惊讶的是，测试的最小上下文窗口大小（8k）在所有全面性（平均赢得率58.1%）的比较中普遍更好，而在多样性（平均赢得率= 52.4%）和赋能性（平均赢得率52.4%=51.3%）方面表现更好。鉴于我们更喜欢更全面和多样化的答案，因此我们使用了一个固定的上下文窗口大小为8k个标记来进行最终评估。

3.6 结果对比

索引过程产生了播客数据集的一个由8564个节点和20691条边组成的图，以及新闻数据集的一个由15754个节点和19520条边组成的更大的图。该表显示了在每个图的社区层次结构的不同层次上的社区摘要的数量。

Unit: 对于C0-C3指社区摘要，对于TS指文本块

Token:词符

3.6.1 GraphRAG vs. SS

对比的点是 Global Approaches vs. Naïve RAG：

Global Approaches：指的是通过社区摘要和知识图谱等全局方法的策略，更全面和多样地回答问题。
Naïve RAG：一种直接检索文本块的朴素问答方法，简单地根据查询找到相关文本段落并提供给用户。

对比结果：

全面性：
- Podcast 数据集：胜率为 72-83%。
- News 数据集：胜率为 72-80%。
多样性：
- Podcast 数据集：胜率为 75-82%。
- News 数据集：胜率为 62-71%。
直接性：Naïve RAG 在直接性上表现最好。

3.6.2 GraphRAG vs. TS

对比的点是 Community Summaries vs. Source Texts：

TS方法直接对源文本应用类似 map-reduce 的方法进行文本摘要。
与直接使用源文本相比，社区摘要在全面性和多样性上略有提升，特别是在中间层次和低层次的摘要上。

对比结果：

Podcast 数据集：
- 中间层次的摘要在全面性上的胜率为 57%，多样性上的胜率也是 57%。
News 数据集：
- 低层次的摘要在全面性上的胜率为 64%，多样性上的胜率为 60%。

GraphRAG可扩展性优势：

相比于TS方法，Graph RAG在处理低层次社区摘要（C3）时，所需的上下文 tokens 数量减少了 26-33%。在处理根层次社区摘要C0时，所需的 tokens 数量减少了超过 97%。在分数上能以较少的 token 成本达到与其他全局方法相竞争的性能。

4 相关内容

4.1 indexing workflow

构建索引的基本过程如下：首先，它会将输入文本进行拆分，然后提取实体与关系，生成摘要信息，并根据这些信息构建内存中的图结构。接下来，它会从这个图中识别出各个社区，为每个社区创建报告，并在图中创建文本块节点和文档节点。

1. create_base_text_units

create_base_text_units 是整个pipeline的第一个workflow, 它的作用是对txt的文件内容按照特定的策略进行切分操作，默认是按照token进行切分, chunk操作的输入是text，对于一个text 经过chunk操作后会得到多个chunks。

2. create_base_extracted_entities

GraphRAG就会采用graph_intelligence策略从每个chunk来提取需要的实体。

这里有个情况需要考虑，不同的数据块可能会抽取出相同的实体。比如说，第一个和第二个数据块都可能包含"草帽路飞"这个实体。

这时候，GraphRAG会采用一种名为merge_graphs的操作，把多个子图合并成一个新的大图。如果遇到相同的节点，那么GraphRAG就会执行concat操作，也就是将对应的属性和关系进行合并。

比如对于一个实体：‘哥尔·D·罗杰’，经过merge之后会包含多个description的列表: [‘哥尔·D·罗杰是罗杰海贼团的船长’, ‘哥尔·D·罗杰是被称为“海贼王”的男人，他在被行刑受死之前说了一句话，开启了“大海贼时代”’]

通过merge_graphs操作，GraphRAG能够有效地处理重复的实体，并把多个chunk对应的Graph整合成一个新的Graph，形成一个更加完善和详细的数据图。

3. create_summarized_entities

通过merge_graphs的操作，将多个子图合并到一个全新的大图之后，GraphRAG会进一步对这个大图的节点和关系的描述使用graph_intelligence进行总结。

总结所使用的prompt中文翻译如下：

你是一位负责生成以下提供数据的综合摘要的有用助手。根据一个或两个实体，以及一系列描述，这些描述都与同一个实体或一组实体有关。请将所有这些描述合并成一个单一的、全面的描述。确保包括所有描述中收集到的信息。如果提供的描述存在矛盾，请解决这些矛盾，并提供一个单一的、连贯的摘要。确保用第三人称写作，并包括实体名称，以便我们拥有完整的上下文。 ####### -数据- 实体: {entity_name} 描述列表: {description_list} ####### 输出:

执行summarize_descriptions操作后，原来图形中的多个description就被整合为了一个全新的、详尽的描述。

4. create_base_entity_graph

这一步是做社群检查的，使用Leiden算法:

将实体进行分类，拿三国举例，比如周瑜和孙策属于吴国，曹操和司马懿属于魏国，刘备和关羽属于蜀国，而吴国、魏国、蜀国都属于东汉，其中东汉是一个大社群，魏蜀吴是三个小社群，当执行查询时，可以指定社区的级别，如果指定的是低级别社群，那么查找的结果就比较微观，比如问三国时期有哪些著名人物，如果指定的社群为吴国，那么匹配的就只有周瑜和孙策，如果指定的社群为东汉，那么就能找到更多的著名人物。

经过create_base_entity_graph之后，Graph按照层级被划分出多个子图，每个子图对应一个level。

5. create_final_entities

对节点做embedding，方便进行之后的query

6. create_final_nodes

该步骤属于 Network Visualization 阶段，由于生成的图谱一般不是一个平面图（可以通过在平面上绘制其顶点和边而不出现边的交叉），通过使用降维技术操作将非平面图映射到平面上。

7. create_final_communities

创建community table

8. join_text_units_to_entity_ids

建立text_unit到entity的映射关系

9. create_final_relationships

创建relationship table

10. join_text_units_to_relationship_ids

将text_unit_id映射到它所包含的relationship_id

11. create_final_community_reports

用于生成社区摘要：借助LLM生成每个社区的摘要信息，用来了解数据集的全局主题结构和语义。这也是Microsoft GraphRAG的核心价值所在，也是回答QFS问题的关键。

12. create_final_text_units

把对应的chunk和这个chunk有的document_ids, entity_ids, relationship_ids 做关联，成一张表。

13. create_base_documents

建立document和text_unit的对应关系表

14. create_final_documents

建立document和text_unit_ids的对应关系表

4.2 query workflow

Global Search

在接收到用户查询以及（可选的）对话历史后，全局搜索方法使用来自图社区层级结构中指定层级的一系列由LLM生成的社区报告作为上下文数据，以map-reduce的方式生成响应。

在map步骤中，社区报告被分割成预定义大小的文本块。每个文本块然后用于生成一个包含多个要点的中间响应，每个要点都会伴随一个数值评分，表示该要点的重要性。

在reduce步骤中，会对中间响应中的最重要要点进行筛选和聚合，并将这些要点用作上下文来生成最终响应。

全局搜索的响应质量会受到用于获取社区报告的社区层级选择的显著影响。较低的层级具有更为详细的报告，往往能生成更为全面的响应，但由于报告量大，可能会增加生成最终响应所需的时间和LLM资源。

Local Search

在接收到用户查询以及（可选的）对话历史后，本地搜索方法会从知识图谱中识别出与用户输入语义相关的一组实体。

这些实体作为进入知识图谱的访问点，从而提取出更多相关的细节，如连接的实体、关系、实体的协变量以及社区报告。

此外，它还从与已识别实体相关的原始输入文档中提取相关的文本块。这些候选数据源随后会被优先排序并过滤，以适应预定义大小的单一上下文窗口，最终用于生成对用户查询的响应。

4.2 处理大型数据的优势

Graph RAG 利用了图的自然模块性来对数据进行划分，以实现全局摘要。这一特点使得 Graph RAG 在处理大型复杂数据集时具有独特的优势。具体而言：

全局摘要（Global Summarization）：通过对图进行模块化划分，Graph RAG 能够在更高层次上对数据进行总结和概括。
数据分区（Data Partitioning）：利用图的模块性，Graph RAG 能够有效地将数据分成多个部分，便于管理和检索。
更强的可扩展性：这种方法提高了系统的可扩展性，能够处理更大规模和更复杂的数据集。

4.3 自我记忆和并行生成

Graph RAG整合了其他系统的多个概念，具体如下：

自我记忆（Self-memory, Selfmem）：类似于Cheng等人在2024年提出的概念，Graph RAG使用社区摘要作为一种自我记忆，帮助生成增强型检索。这使得在后续的生成周期中更有效地使用之前的信息。
并行生成社区答案（Parallel Generation of Community Answers）：通过使用社区摘要并行生成答案，这种方法类似于Shao等人在2023年提出的迭代或联邦检索生成策略。

4.4 知识图谱可视化

当GraphRAG完成索引过程后，它默认会将构建知识图谱所需的所有数据持久化。这些数据被存储在输出目录中，并采用Parquet文件格式。在查询阶段，这些Parquet文件会被加载到内存和向量数据库中。这样做的好处在于，我们可以直接从内存和数据库中检索信息，而无需再次从原始数据源抽取和处理数据。

由于parquet文件可以很简单的通过pandas库读取成DataFrame表，所以在了解其结构后，就可以通过Cypher语句导入成Neo4j图数据库中的节点与关系。

4.5 预处理流程对比

上下两条流程展示了不同的路径，用来处理数据集中的文本块

上方流程（GraphRAG路径）：

这条路径主要通过GraphRAG（图检索增强生成模型）进行处理，涉及图的构建和图机器学习（Graph ML）操作。
文本块经过GraphRAG的处理，进行信息抽取，然后通过图归纳（Graph Induction）生成图结构。这个图结构用于表示层次、主题检测、实体总结等高级语义信息。
生成的图结构和信息进一步细化，最终参与语义总结，形成不同层次的社区。

下方流程（Baseline RAG路径）：