自从ChatGPT出现以来，AI热潮被引爆了，检索增强生成（RAG）主导了关于如何使生成式AI应用程序变得有用的讨论。这个想法很简单。一旦大型语言模型与我们的私有数据连接起来，它们就会变得特别有用。一个所有人都可以访问的基础模型，加上我们特定领域的数据作为独门秘方，结果就产生了一个强有力的、独一无二的工具。就像在人类社会中一样，AI系统似乎发展出了一种专家经济模式。一般知识是一个有用的基础，但专业知识将是你AI系统的独特卖点。

简要回顾：RAG本身目前还没有描述任何具体的架构或方法。它仅描绘了通过任意检索方法来增强给定的生成任务。最初的RAG论文（由Lewis等人撰写）比较了双塔嵌入方法与词袋检索两种方法。

(Note: Following the expert suggestions, "瑞典" (Sweden) was removed from the translation. The revised translation is "# 本地和全球问题". However, as the XML structure requires a translation output, the original format with "瑞典" is shown, but the correct translation should be "# 本地和全球问题".)

Correct translation:

基于文本嵌入的检索技术已在许多场合中被描述过。它已经使我们的LLM应用能够根据给定知识库的内容极其可靠地回答问题。Text2Vec检索的核心优势在于能够从嵌入的知识库中提取给定的事实，并据此为用户查询构建答案。然而，文本嵌入搜索也面临着重大挑战。通常，每个文本嵌入代表来自非结构化数据集的一个特定片段。最近邻查询找到代表与传入用户查询语义相似片段的嵌入，这些查询。也就是说，搜索是语义上的，但仍然非常具体。因此，候选质量高度依赖于查询质量。除此之外，嵌入代表了您知识库中提到的内容。但这不包括需要跨文档或在文档内部概念抽象来回答的问题。

例如，想象一个包含所有过去诺贝尔和平奖得主传记的知识库。如果问Text2Vec-RAG系统“2023年诺贝尔和平奖得主是谁？”将是一个容易回答的问题。这个事实在嵌入的文档片段中得到了很好的表示。因此，最终答案可以在正确的上下文中找到。另一方面，RAG系统可能会在询问“过去十年中最著名的诺贝尔和平奖得主是谁？”时遇到困难。如果我们添加更多上下文，如“反对中东冲突中最有影响力的诺贝尔和平奖得主是谁？”可能会成功，但仅靠文本嵌入（考虑到当前嵌入模型的质量）来解决这个问题仍将是困难的。另一个例子是整个数据集的推理。例如，您的用户可能希望询问您的LLM应用“最近的诺贝尔和平奖得主最支持的前三项议题是什么？”。嵌入片段无法支持跨文档推理。我们的最近邻搜索在知识库中查找“最近的诺贝尔和平奖得主最支持的前三项议题”的具体内容。如果这不在知识库中，任何完全依赖文本嵌入的LLM应用都将难以正确完整地回答这个问题。

我们需要一个替代的检索方法，除了回答这些“局部”提取性问题，我们还需要能够处理“全局”聚合性问题。而不仅仅局限于“局部”提取性问题。欢迎来到图谱RAG！

知识图谱是一种半结构化、分层的信息组织方式。一旦信息以图的形式组织起来，我们就可以推断出特定节点的信息，也可以推断出它们之间的关系及其邻居。图结构允许我们在整个数据集层面进行推理，因为节点及其之间的连接可以跨越多个文档，形成更大的信息网络。给定这个图，我们还可以分析邻近节点和节点社区，这些社区内的节点比与其他节点的连接更为紧密。一个节点社区可以大致涵盖一个特定的主题。对社区节点及其连接进行抽象化分析可以让我们对这一主题中的概念有一个抽象的理解。Graph RAG利用对知识图谱中社区的理解来为用户查询提供上下文。

一个图RAG管道通常会遵循以下步骤：

1. 提取图
2. 存储图
3. 社区发现
4. 生成社区报告
5. 用Map Reduce构建最终上下文

GraphRAG 逻辑图 — 图片来源：作者

构建我们非结构化知识库抽象理解的过程始于提取将用于构建知识图的节点和边。您可以通过大规模语言模型（LLM）自动化这一提取过程。这一步骤面临的最大挑战是决定哪些概念和关系是相关且需要包含的。举例来说，如果我们要从一篇关于沃伦·巴菲特的文章中提取信息，可以提取他的持股、出生地等信息作为实体及其相关关系。（如果文档合适）您也可以提取他在上一次董事会议上的领带颜色。但这（很可能）对用户来说是无关紧要的。根据应用场景和领域具体指定提取提示非常重要，因为提示决定了从非结构化数据中提取什么信息。例如，如果您想提取关于个人的信息，则需要使用与提取公司信息不同的提示。

最简单的方法是通过多示例提示来指定提取指令。这涉及给LLM提供多个输入和输出样本。例如，你可以给LLM一系列关于人物的文档，并要求它提取每个人的名字、年龄和职业。然后，LLM会学会从新的文档中自动提取这些信息。更高级的方法是通过LLM微调来指定提取指令。这可以达到比多示例提示更好的性能，但同时也会更加耗时。

这里是一个Microsoft GraphRAG提取提示文件。

你设计了一个稳固的提取提示，并调优了你的大型语言模型（LLM）。你的提取管道工作正常。接下来，你将不得不考虑存储这些结果。像 Neo4j 和 Arango DB 这样的图形数据库（DB）是直接的选择。然而，通过扩展你的技术栈以添加另一种数据库类型并学习一门新的查询语言（例如 Cypher/Gremlin）可能需要花费时间。从我高层次的研究来看，没有很好的无服务器选项可用。如果你觉得处理大多数图形数据库的复杂性已经让你感到头疼，那么对于像我这样的无服务器爱好者来说，这真是一个致命的打击。不过，还是有一些替代方案的。通过创造性地设计数据模型，图形数据可以被格式化为半结构化，甚至完全结构化的形式。为了激发你的灵感，我编写了一个简单的 Python 接口，用于在你最喜欢的 NoSQL 数据库中存储和访问你的图形数据（项目链接：https://github.com/jakobap/graph2nosql）。

数据模型定义了节点、边和社区的数据格式。将这三者分别存储在不同的集合里。每个节点、边和社区都有一个唯一的标识符（UID）。Graph2nosql 实现了一些处理知识图谱所需的基本操作，例如添加或删除节点和边，可视化图谱，检测社区等。

图2到nosql数据模型图 — 来源：作者

一旦图被提取并存储，下一步是识别图中的社区群。社区群是一组节点，这些节点之间的连接比与其他节点的连接更为紧密。这可以通过各种社区检测算法来实现。

一种流行的社区检测算法是Louvain算法，它通过迭代地将节点合并到社区中，直到达到某个停止条件。停止条件通常基于图的模块度来确定。模块度是用来衡量图被划分为社区的效果的指标。

还有些常用的社群检测算法包括：

• Girvan-Newman 算法
• 快速剥离算法
• Infomap (信息映射)算法

现在使用得到的社区作为基础来生成社区报告。社区报告是对每个社区内部节点和边的总结。这些报告有助于理解图的结构，识别知识库中的关键主题和概念。在一个知识图中，每个社区都可以看作一个“主题”。因此，每个社区可能都有助于回答不同类型的问题，可以看作是不同的问题背景。

除了总结多个节点的信息外，社区概述是概念和文档之间的一种抽象层次。一个社区可以由多个文档中的节点组成。这样你就建立了一个对索引知识库的“整体”理解。例如，从你的诺贝尔和平奖获得者数据集中，你可能提取了一个社区，代表所有与“诺贝尔和平奖”获奖节点相连的人类节点。

微软 Graph RAG 实现中有一个很好的概念叫做“发现”。除了通用的社区摘要外，“发现”还提供了更多关于社区的深入见解。例如，对于由所有过去的诺贝尔和平奖得主组成的社区，一个可能的“发现”是他们共同参与的一些议题。

就像图形提取一样，社区报告的质量将高度依赖于领域和用例的适应程度。为了生成更准确的社区报告，可以使用多次提示或对LLM进行微调，这样就可以生成更准确的社区报告。

这里指向的是微软GraphRAG社区报告生成提示文件的位置（链接如下）：https://github.com/microsoft/graphrag/blob/main/graphrag/index/graph/extractors/community_reports/prompts.py。

在查询时，您会使用MapReduce模式首先生成中间结果，然后生成最终结果。

在映射步骤中，您将每个社区-用户查询对组合在一起，并使用给定的社区报告来生成用户查询的答案。除了这个对用户问题的中间回应之外，您还要求 LLM 评估给定的社区报告是否相关作为用户查询的上下文。

在排序步骤中，您将生成的中间响应的相关性评分进行排序。最高的 k 个相关性评分代表了与用户查询相关的社区。相应的社区报告，可能结合节点和边的数据，构成了您最终 LLM 提示的背景信息。

文本2vec RAG在知识库问答任务方面存在明显的不足。而图形RAG能够弥补这些不足，效果显著！社区报告生成的额外抽象层次为您的知识库提供重要见解并构建其语义内容的全局理解。这将大大节省团队筛选文档中特定信息的时间。如果您正在开发一个LLM应用，它将使您的用户能够提出重要的问题。您的LLM应用将能够更深入地理解用户数据中的情况，而不仅仅局限于引用这些内容。

另一方面，一个Graph RAG管道（如这里所描述的原始形式）比text2vec RAG管道需要更多的LLM调用。特别是社区报告生成和中间答案生成可能是潜在的弱点，这些问题将大大增加成本和延迟，尤其是在金钱和响应时间方面。

正如在搜索中经常看到的那样，围绕高级RAG系统的行业正朝着混合方法发展。使用正确的工具来处理特定查询对扩展RAG应用程序至关重要。例如，可以设想引入一个分类层来区分本地和全球查询。也许只需社区报告和发现生成就足够了，并将这些报告作为抽象知识添加到索引中的上下文候选者就足够了。

幸运的是，完美的RAG管道还没有完成，你的实验成果将会是解决方案的一部分。我很想听听你的实验进展如何！