前言
在当今大模型应用百花齐放的时代，大致有两条主流的技术路线：
- 微调：通过特定知识对模型进行训练和微调，使其内化这些知识，从而从根本上提升模型的能力。
- 检索增强生成（RAG）：利用 RAG 技术，让大模型调用外部知识源，借助外部知识来提升模型的表现。
相比于微调，RAG 更加轻量化，成本也更低，因此广受欢迎。然而，由于大模型在处理 token 时存在限制，调用外部知识源时可能会遇到文本长度的限制，这在某些场景下可能导致上下文信息的丢失，从而影响答案的准确性。
微软近期开源的知识图谱 RAG（以下使用：Graph RAG）技术，能够将复杂的、大规模文本数据集转化为易于理解和操作的知识结构，以便更好地理解文本之间的相互关系。
Graph RAG 的强大在于能够处理更多的文档，更多的数据，能够更高效的给出更全面，更准确，更多样性的回答。
但更高更快更强的 Graph RAG 真的适合你吗？
什么是知识图谱？
有一句非常出名的话相信大家都听过：最多通过六个人你就能够认识任何一个陌生人。 这就是著名的六度分隔（Six Degrees of Separation）理论，它最好的具现化就是利用知识图谱。
知识图谱（Knowledge Graph）是一种用于表示和组织知识的结构化数据模型。它通过节点（实体）和边（关系）来表示现实世界中的各种事物及其相互关系。知识图谱的核心目标是将信息以一种机器可理解的方式进行存储和组织，从而支持复杂的查询和推理。
理论高大上，但大家在生活中肯定或多或少的都接触过知识图谱，下面就是一张简单的清华大学的知识图谱。
可以看到与中间节点（实体）清华大学相关的知识（实体）都通过一条条边（关系）联系在一起。同样，如果将每个人都看作一个个知识节点（实体），将形成一个复杂而又庞大的知识图谱，从而也可以验证六度分隔理论的有效性。
什么是 Graph RAG？
显然，从名字上来看 GraphRAG 是建立在RAG的概念基础之上，同时利用了知识图谱。
Graph RAG 一共有以下 6 个关键步骤：
- 源文档 -> 文本块
与传统 RAG 的第一步一样，需要将源文档合理切分成文本块，这一过程在 RAG 中至关重要会直接影响大模型调用外部信息的准确性，从而影响最终答案的准确性。对于切分方案的研究有很多，像窗口上下文检索就能在一定程度上解决切分长短的问题。
- 文本块 -> 元素实例
这一步与传统的 RAG 不同，目前的 RAG 方案基本都是将切分的文本块进行 Embedding。而 Graph RAG 需要将切分文本块通过大模型（LLM）进行识别，提取中文本中的所有实体及其相关属性（包括名称，类型和描述），然后识别实体间的关系，以及关系的描述。这些信息将以一组分隔的元组形式输出，为构建图索引做好准备。
- 元素实例 -> 元素摘要化
上个步骤中使用大模型（LLM）从文本中提取出的信息，已经是一种摘要的形式。但仍然可能存在隐含关系未被提出出来，所以还需要通过大模型（LLM）将实例进行进一步提取，作为下一步构建图社区的索引。
一般步骤二和步骤三建议使用 Prompt Engineering 实现。步骤二倾向于根据源文本含义提取表层实体和关系，步骤三倾向于根据实例提取隐含的关系。
- 元素摘要 -> 构建图社区（社区可以理解为数据集）
将步骤三种提取出的元素摘要看作一种索引，利用社区检测算法构建出图社区。下面就是 Graph RAG 论文中的展示的基础层级社区图。
可以看出上图的节点中有着明显的亲疏关系，通过这层关系就可以将图划分为多个社区，社区中的节点更符合同一个主题，同时一个大社区下还可以分为多个小社区，从而也可以将社区分成多个等级。
- 图社区 -> 社区摘要
针对图中的各个社区生成出对应摘要，这些摘要在没有用户提问时，对于理解社区的全局结构和整体概念有重要作用；在有用户提问时，可以作为输入到大模型（LLM）的上下文，帮助模型更好的理解。
- 社区摘要 -> 社区答案 -> 全局答案
整合社区摘要，生成全局答案。
生成全局答案的过程分为三步，简单描述就是：
- 针对用户问题，通过不同的社区摘要生成社区答案。
- 大模型（LLM）对于社区答案进行打分，一般是 0-100，分数为 0 的答案直接过滤掉，并将所有有效的（非 0）社区答案降序排列。
- 将社区答案作为有效资料添加到生成全局答案的上下文中，直到达到 token 限制，最终生成全局答案。
Graph RAG 适合我吗？
很明显，Graph RAG 能够提供更多高质量，高相关性的上下文给模型，对于复杂问题的处理，答案的全面性，多样性和准确性都优于传统的基于 Vector RAG。
同时在针对复杂问题，大模型需要调用大量外部知识的场景下，Graph RAG token 的使用成本也相较于传统的 Vector RAG 更低，同时也在一定程度上避免了信息有可能在较长上下文中“丢失”的情况。
但并非所有数据的检索都是以知识图谱的方式为最优解，有些数据可能本身就不能图谱化。另外Graph RAG 中大量采用了大模型（LLM）的能力，例如提取实例，社区答案评分等，整个方案非常依赖大模型（LLM）本身的能力强弱，若是大模型（LLM）本身的能力比较弱，构建的知识图谱（图社区）质量比较差，那最后生成答案的质量大概率不如传统的 Vector RAG。
这里同时也有另一条思路，我们可以采用传统的手段来构建知识图谱，来保证知识图谱的高质量，后续的流程再基于 Graph RAG 实现。
Graph RAG 为解决复杂问题提供了一种非常优秀的方案，但并非解决一切场景的银弹，Graph RAG 同样增加了整个系统的复杂性，极大的依赖大模型（LLM）的能力，知识图谱的质量等，引入了其他的风险。
总的来说，在有明确目标的场景，和简单的场景下，采用传统的 RAG 方式就能满足；Graph RAG 更适合在用强力大模型（LLM）的加持下，对于复杂场景的处理。
尾言
从 Graph RAG 的设计中可以看出，我们更期望大模型（LLM）能够充分利用其庞大的知识储备，并结合人类处理复杂问题的思维方式，更好地应对复杂场景，逐步向真正的智能体迈进。
Graph RAG 相关的更多信息细节可查看：arxiv.org/pdf/2404.16…
