JaydenAI的博客

不论是索引还是查询都需要涉及针对LLM的调用，在模型不变的情况下，LLM响应内容的质量基本由指定的提示词来决定。默认提示是使用 GraphRAG 系统的最简单方法。它旨在开箱即用，只需极少的配置。有关索引和查询的每项默认提示的更多详细信息，请参阅手动调优页面。Prompt Tuning是GraphRAG 索引流程开始前的一个可选但强烈推荐的步骤，目的是让用于知识图谱生成的提示词适配你的特定数据领域，从而提升实体抽取和关系抽取的质量。

目前我们对GraphRAG的四种查询模式（Basic、Local、Drift和Global）的设计和实现原理，虽然它们擅长从全局着眼来回答问题，但是很多情况下也不能一次就能提供你想要的答案。我们可以采用Agent常用的交谈方式，通过继续追问来获取更多信息。几乎所有这样的应用都会根据当前上下文提供一组候选的问题供你选择，GraphRAG为此专门设计一个名为Question Generation（以下简称QGen）的模块。

[GraphRAG实现原理-20:四种查询方式之四：Global Search]详细介绍了作为搜索引擎的`GlobalSearch`，了解了Global Search查询模式的执行流程。这篇文章会补充剩下的内容，进一步了解命令行`graphrag query --method global`内部如何创建`GlobalSearch`对象，并利用它来完成基于Global Search模式的搜索。我们还会通过一个演示程序探索在一个典型的搜索场景中，Map和Reduce两个阶段会进行怎样的LLM调用。

Global Search是 GraphRAG中专门用于回答语料库级**全局性**问题的查询模式，例如*这个数据集的主要主题是什么*”或*有哪些跨领域的趋势*。它不依赖某个具体的实体锚点，而是通过Map-Reduce方式对预先构建的社区报告进行遍历和合成。

[上篇]对作为DRIFT Search搜索引擎的`DRIFTSearch`进行了深入的介绍，从而了解了该模式完整的执行流程。这篇文章我主要想通过一个简单的实例演示这种查询方式特有的不断追问的推理风格。而且这个实例并不是为了说明DRIFT Search有多强大，正好相反，而是反映了这个种查询模式在一些场景中不但效果不好，而且还极其昂贵。在这之前，我们来补充一些必要的内容。

[GraphRAG实现原理-17:四种查询方式之二：Local Search]介绍了Local Search查询模式的涉及和实现原理。RIFT Search在Local Search之上增加了一层社区级别的全局引导。普通Local Search直接从查询映射到实体，起点完全依赖实体相似度。DRIFT则先用社区报告做一轮宽泛的语义铺开，由社区报告**教会**系统应该追问什么，再将追问下放到实体层面执行。这使得DRIFT能触及比单次Local Search更广泛的事实集合。

[GraphRAG实现原理-16：四种查询方式之一：Basic Search]对Basic Search的设计和实现原理进行了详细介绍。我们知道这种查询模式直接检索基于`TextUnit`的向量数据表，找到与查询文本生成的嵌入向量相似度最高的`top k`个切片，并生成后续调用LLM的上下文。Local Search的执行流程可以概括为：以实体向量检索为入口，沿知识图谱扩展上下文，再按token预算筛选装配，最终交给LLM生成答案。

前面的系列文章主要介绍了GraphRAG索引的构建，我使用了10篇文章详细介绍了构成`standard`索引管道的10个`Workflow`。这个管道执行之后会生成一系列的索引表，这些表最终是为查询服务的。GraphRAG主要提供了Basic、Local、DRIFT和Global四种类型查询模式，本篇文章主要介绍最简单的Basic模式。

很多人觉得GraphRAG不会像Baseline RAG那样继续使用向量数据库，其实不然。GraphRAG支持四种Query模式，Local Search会先用向量检索定位相关实体，再沿知识图谱扩展出关联的关系、社区报告和原始文本块，组装成上下文交给LLM。DRIFT Search在Primer阶段会从向量数据库中检索社区报告，Follow-up阶段本质上就是基于Local search的迭代。Basic Search自身就是针对Baseline RAG的实现。

为了解决Baseline RAG信息割裂的问题，GraghRAG先从原始文本中提取实体关系图，进而生成具有层级关系的社区。它相当于将原来非关系的完全离散的信息重新组成成树形化的可检索结构，最终解决RAG系统的终极问题：为查询提供全面（召回率）和匹配（准确率）的上下文。对于Global查询来说，它可以利用从上层社区开始检验当前社区是否与对当前查询相关，如果不相关，它就放弃当前社区并且可以选择不在继续向上追溯（可配置）。

为了确保提供的文本能够被LLM正常处理（至少不能超出上下文窗口上限） ，需要将导入的文档借助`create_base_text_units`这个`Worfkow`转换成代表切片的`TextUnit`对象，并存入`text_units`表中。本篇文章介绍的`create_final_text_units`这个`Workflow`会为每个`TextUnit`反向补充其关联的实体、关系和协变量ID，生成最终版的文本单元表，从而建立从**源文本块**到**图谱元素**的双向可溯源链接。

`extract_graph`和`finalize_graph`这两个`Workflow`先后执行后，完整的实体关系图被构建出来。这张图已经体现了实体之间的关系，每个实体和关系还分别附加了度数（Degree：实体相连的关系数量）和组合度数（Combined Degree：关系两端实体度数之和）。这张图在经过`create_communities`这个`Workflow`执行之后会进一步生成社区（Community）。

当完整的实体关系图从提供的文本提取之后，其实很遗漏了很多动态的内容。GraphRAG将它们视为协变量（`covariate`）存储在`covariates`表中。Covariate这个名称借鉴了统计学中的**协变量**概念，意指那些与主体相关、但本身并非核心结构（实体或关系）的附加信息。索引管道利用`extract_covariates`这个`Workflow`利用LLM提取这些信息。

[GraphRAG实现原理-09:调用LLM提取实体关系图]介绍了如何利用`extract_graph`借助LLM的力量将所有的文档切片转换成实体关系图，这张图具体体现在生成`entities`和`relations`表中。但是这张图目前仅仅描述了两个实体之间是否有关系，缺少必要的指标。实体的度数利用`finalize_graph`这个`Workflow`来计算并添加，这个Wokflow还会额外计算并添加关系组合度数。

GraphRAG的Graph本质上是从输入文档中提取出来的实体关系图。这张图以抽取的实体作为节点，实体之间的关系作为边的五向图。实体关系图的提取是整个索引管道最核心的部分，此功能是通过`standard`管道中命名为`extract_graph`的`Workflow`完成。

到目前为止，我们已经系统介绍了组成`standard`管道的前两个`Workflow`的作用、设计和实现。其中`load_input_documents`用来加载原始的输入文档，`create_base_text_units`则对生成的文档进行分割并生成代表切片的`TextUnit`列表。本篇文章介绍的第三个命名为`create_final_documents`的`Workflow`则负责将`TextUnit`的ID会写到文档中，使这样文档和切片就具双向引用。

[GraphRAG实现原理-06:加载输入并转换成标准文档]介绍了作为`standard`索引管道的一个命名为`load_input_documents`的`Workflow`，它会设置的`InputReader`加载相应输入文件并将它们转换成标准的`TextDocument`，最后利用代表输出存储的`Storage`和对应的`TableProvider`存入`documents`表中。由于文档的内容最终会递交给LLM处理，必须将文档切割成能够被LLM处理的切片。

[GraphRAG实现原理-04:构建知识图谱的索引管道]详细介绍了用来构建知识图谱的索引管道以及创建方式，我们知道GraphRAG默认构建了四条索引管道，其中两条（`standard`和`fast`）针对全量初始化索引，另外两条（`standard-update`和`fast-update`）针对增量更新索引。`standard`和`fast`的区别主要体现在前者使用LLM来构建知识图谱，后者则使用传统的NLP的做法，索引后者更快且免费。

[GraphRAG实现原理-04:构建知识图谱的索引管道]详细介绍了用来构建知识图谱的索引管道以及创建方式，在本篇文章中我们将重点介绍这个管道的执行原理。通过这篇文章，我们将会对执行`graphrag index`和`graphrag update`命令提取并执行管道的流程有一个清晰的认识。

[GraphRAG实现原理-02:基于社区（Community）的知识图谱]介绍了组成整个知识图谱的5张表，它们连同向量数据库都是调用`graphrag index`命令实时索引（Indexing）的产物。整个索引是一个预先编排好的Sequential类型的工作流，但是这里不能叫工作流，叫管道（Pipeline），工作流（Workflow）是对组成管道的单个处理步骤的称呼。如果你了解LangChain，可以将Pipeline和Workflow分别视为Chain和`Runnable`，而`Runable`可大

[GraphRAG实现原理-02:基于社区（Community）的知识图谱]介绍了组成整个知识图谱的5张表。由于我们采用基于文件系统的存储，所以这五张表体现为对应的`.parquet`文件。GraphRAG并没有对存储做任何的限制，所以它通过`Storage`这个抽象类对存储进行了抽象。既然存储是抽象的概念，数据表也是，与之相关的是`Table`和`TableProvider`这两个抽象类。

GraphRAG的知识图谱并非简单的**节点-边**二元结构，而是一个由 Entity（实体）、Relationship（关系）、Claim/Covariate（声明/协变量）、Community（社区）和Community Report（社区报告） 五层要素构成的、兼具细粒度事实与宏观主题的层次化知识体系。它们分别承担着“点”、“线”、“细节”、“团块”和“摘要”的角色

GraphRAG是一种结构化的、分层的检索增强生成 (RAG) 方法，它不同于使用纯文本片段的简单语义搜索方法。GraphRAG的流程包括：从原始文本中提取知识图谱，构建社群层级结构，为这些社群生成摘要，然后在执行基于 RAG 的任务时利用这些结构。