检索增强生成 (RAG) 是一种有效的方法，可以让 AI 从您希望它处理的特定数据集提取信息。这个想法相对简单——尽管生成式 LLM 在它们所做的事情方面非常出色，但它们并非无所不知。因此，如果我们希望 LLM 根据我们文档中的特定信息生成响应，我们首先必须向它提供这些信息（上下文）。
RAG 是解决该问题的方案，并且已成为我们今天在野外看到的几乎所有知识库搜索系统的普遍方案。您还需要什么？ 在本文中，我们想强调您的数据及其外观，以及数据中宝贵的信息，可能会决定哪种 RAG 对其最有效。
在许多情况下，相关的上下文可能存在于我们数据的 content 中，但在某些应用中，其他信息可以帮助提高 RAG 应用的性能。例如，图 RAG 允许根据数据库中数据点之间的关系检索上下文。通过将基于向量搜索的 RAG 和图 RAG 结合到混合 RAG 系统中，我们可以根据它们的上下文含义以及我们数据中的关系返回结果。为了帮助您理解这两种方法之间的区别，我们还创建了一个您可以在 Colab 中运行的配方。
🧑🍳 这篇博文附带一个配方和辅助函数，所有这些都可以在 ms-graphrag-neo4j 仓库 中找到。您还可以将特定的“Naive RAG vs GraphRAG with Neo4J & Weaviate”配方作为 Colab 在此 打开
什么是 RAG 以及它擅长什么
RAG 代表“检索增强生成”。让我们关注第一个词：检索。让 LLM 根据特定上下文响应某事的第一个步骤是在第一位检索该相关上下文。
什么是 Naive RAG？
检索上下文可以通过许多方式完成，但迄今为止最常见的方式是对给定数据集进行语义搜索（向量搜索）。这使我们进入了“Naive RAG”这个术语，它只是一个具有基于向量搜索检索的简单问答系统。在大多数 RAG 系统中，“R”（检索）都基于向量搜索。这使我们能够使用查询的语义含义并使用嵌入模型来编码用户查询和我们可能存储的所有数据（如 Weaviate 等专为此目的设计的向量数据库）来提取最相关的数据。
由于 Naive RAG 的基本性质，它是检索任何给定查询的相关上下文的绝佳方式，然后 LLM 可以使用该上下文生成响应。大多数用于 Naive RAG 的数据集包含嵌入，其中包含一个“text”字段列表，对于每个字段，我们都有一个嵌入
重要的是要注意，每个条目都是一个独立的条目。每个条目都有一个可以用向量（嵌入）表示的含义。因此，Naive RAG 能够访问的唯一信息是每个条目的独立向量。这种数据表示方式不表示数据点之间的任何关系，而是在向量空间中它们的含义接近程度。
以我们配方中的示例为例。在这里，我们将展示对包含（虚构）合同（例如合作、雇佣等）的数据集的 RAG，这些合同是在个人和公司之间签订的。对于每个合同，我们都有 contract_text、author 和 contract_type。然后我们继续向量化所有这些信息，其中每个合同都有一个代表其含义的向量。
当我们询问有关数据的问题时，它非常擅长获取与我们刚刚提出的问题最相关的合同。
Naive RAG 不够的地方
现在，在大多数情况下，数据点之间的所谓关系可能与任何给定的搜索任务无关。但是对于这些合同，您可能已经开始想象，编码关系的东西可能非常宝贵。例如，对于我们检索的每个合同，我们都知道作者，但我们检索的上下文不编码进一步的信息，例如作者签署合同的人是否与其他作者有关系。考虑到这一点，让我们继续了解图 RAG 👇
什么是 GraphRAG？
GraphRAG 最近已成为一个总称，指的是广泛使用知识图谱的 RAG 方法。在这个总称下，出现了许多方法，每种方法都不同于它们利用基于图谱的检索来增强 LLM 响应的方式（了解更多 此处）。
其中，Microsoft 的 GraphRAG 实现 已成为最受欢迎和广泛采用的方法之一。
Microsoft 的 GraphRAG 流程图。图片来自[Edge 等人，2024]根据 CC BY 4.0 许可。
Microsoft 的 GraphRAG (MS GraphRAG) 通过在两个阶段利用 LLM 来增强知识图谱的构建。在初始阶段，从源文档中提取实体和关系并进行总结，为流程图中所示的知识图谱奠定基础。
GraphRAG 如何扩展 Naive RAG 功能
MS GraphRAG 与 naive RAG 的不同之处在于，它能够在构建知识图谱后检测图社区并为一组密切相关的实体生成特定于领域的摘要。这种分层方法将来自各种文本来源的碎片化信息集成到对实体、关系和社区的连贯且有组织的表示中。
生成的实体和社区级别摘要可用于在 RAG 应用程序中响应用户查询时提供相关信息。此外，结构化的知识图谱能够应用多种检索方法，例如将图搜索和向量搜索结合在一起，从而增强整体搜索和检索体验
使用 Neo4j 实现 GraphRAG
对于这篇博文，我们开发了一个简化的 Python 项目，它封装了所有提示，以避免让您承担过多的代码。虽然此实现是一个概念验证，而不是生产就绪的代码，但它提供了一个实用的演示。您可以轻松初始化 Neo4j 驱动程序并将其传递给这个简化的 Ms Graph RAG 实现，以查看概念在实际中的应用。
提取实体和关系
我们使用与我们在基线 RAG 实现中使用的相同的虚拟 金融数据集。该数据集包含涉及各方的 100 个合同。对于 MS GraphRAG 方法，最关键的配置决策涉及指定应提取和总结哪些实体类型，因为此选择从根本上塑造了所有下游结果。鉴于我们专注于合同，我们优先提取关键实体类别，包括人员、组织和地点。
allowed_entities = ["Person", "Organization", "Location"]
await ms_graph.extract_nodes_and_rels(texts, allowed_entities)
提取结果后，我们应该得到以下结果
紫色节点是包含其文本和元数据的合同，而绿色节点代表提取的实体。每个实体都有一个名称和描述，并且它们可以彼此之间具有多个关系，如上图所示。
生成社区摘要
当一个实体在多个合同中被提及时，它将具有多个描述，因为它会为每个合同获得一个描述。同样，如果它们出现在多个块中，实体之间可以存在多个关系。为了整合信息，该实现继续进行实体和关系总结，我们使用 LLM 生成简洁的摘要并解决重复或冗余信息。
await ms_graph.summarize_nodes_and_rels()
结果是
修改后的模型现在显示实体之间的一个统一的摘要关系，其中包含来自所有输入源的汇总信息。此外，每个实体都收到一个全面的摘要，该摘要可能非常详细，正如为 Danny Williams 生成的详细资料所示。
在索引过程的最后阶段，我们采用图算法，特别是莱顿算法，来识别网络中的社区。这些社区代表着密集连接的节点集群，它们彼此之间的连接比与图的其余部分更强。
在这个可视化中，社区通过实体颜色来区分。这说明了密集连接的节点如何自然地聚集成社区。
MS GraphRAG 的理念是生成涵盖多种关系和节点的全面高级摘要。通过将互连的信息综合成一个连贯的画面，从而提供更全面的概述。
await ms_graph.summarize_communities()
构建知识图谱后，我们可以进入检索部分。
混合本地图谱 & 向量搜索
有多种有效的方法可以从知识图谱中检索信息。Microsoft GraphRAG 团队演示了 三种不同的方法
- 全局搜索
- 本地搜索
- DRIFT 搜索
本地搜索方法通过智能地将 AI 提取的知识图谱信息与源文档中的相关文本片段合并来生成响应。本地搜索对于需要详细了解语料库中特定实体或概念的问题特别有效（例如，“薰衣草精油提供哪些治疗益处？”）。
本地搜索是一种检索和响应生成方法，它通过根据用户问题的特定实体来查找文档集中最相关的信息来工作。其工作原理如下
实体识别：当用户提出问题时，系统会识别与查询在语义上相关的关键实体（人物、地点、概念等）。
知识图谱导航：这些识别出的实体充当进入知识图谱的入口点，允许系统
- 查找连接的实体（关系）
- 提取相关的属性和特性
- 从社区报告或其他来源提取上下文信息
在 在 Weaviate 中索引我们的实体 后，我们将实现一个利用向量数据库和图数据库的检索管道。首先，Weaviate 的语义搜索功能会根据查询的含义识别最相关的实体。然后，我们可以使用 Neo4j 的图遍历功能来发现连接的实体、关系和社区结构，从而揭示直接连接和更广泛的上下文网络，这些网络可能无法仅通过向量搜索立即显现。这种混合方法结合了向量搜索的语义理解和图数据库的关系智能，以实现全面的信息检索。
retriever = WeaviateNeo4jRetriever(driver=driver,
client=client,
collection="Entities",
id_property_external="entity_id",
id_property_neo4j="name",
retrieval_query=retrieval_query
)
首先，我们查询 Weaviate 向量数据库，以识别基于语义相似性与用户问题相关的实体。检索到的实体 ID 作为我们映射到 Neo4j 图数据库中相应节点的链接点。
在后台，系统随后执行一个 Cypher 查询，该查询遍历知识图谱，沿着实体之间的关系提取上下文相关的信息。Weaviate 的语义搜索能力与 Neo4j 的面向关系的结构相结合，创建了一个能够理解数据中内容和连接的检索系统。检索查询是
retrieval_query = """
WITH collect(node) as nodes
WITH collect {
UNWIND nodes as n
MATCH (n)<-[:MENTIONS]->(c:__Chunk__)
WITH c, count(distinct n) as freq
RETURN c.text AS chunkText
ORDER BY freq DESC
LIMIT 3
} AS text_mapping,
collect {
UNWIND nodes as n
MATCH (n)-[:IN_COMMUNITY*]->(c:__Community__)
WHERE c.summary IS NOT NULL
WITH c, c.rating as rank
RETURN c.summary
ORDER BY rank DESC
LIMIT 3
} AS report_mapping,
collect {
UNWIND nodes as n
MATCH (n)-[r:SUMMARIZED_RELATIONSHIP]-(m)
WHERE m IN nodes
RETURN r.summary AS descriptionText
LIMIT 3
} as insideRels,
collect {
UNWIND nodes as n
RETURN n.summary AS descriptionText
} as entities
RETURN {Chunks: text_mapping, Reports: report_mapping,
Relationships: insideRels,
Entities: entities} AS output
"""
这个 Cypher 查询从初始实体集合遍历到它们对应的邻居、社区、块等等。
如果我们用相同的 Weaviate 示例进行测试，我们会得到以下答案（注意：此演示中的所有数据都是生成的 👍）
Weaviate is a corporation organized under the laws of both the State of
California and the State of Delaware. Its principal place of business is
primarily located in San Francisco, CA, with additional offices at 123
Innovation Drive, Tech City, CA, and 123 Tech Lane, Silicon Valley, CA.
The company is involved in a wide range of activities, including
consulting, software development, data analysis, cloud storage, technical
support, and project management services. Weaviate is actively engaged in
partnerships to develop innovative AI solutions and advanced data
processing technologies, contributing resources and expertise to these
collaborations.
....
GraphRAG 的已知局限性
与传统 RAG 的基于块的方法相比，MS GraphRAG 提供更以实体为中心的索引和检索，从而提供更丰富的实体和社区描述。但是，它面临着静态 LLM 生成摘要的挑战，这些摘要需要定期完全重新索引才能捕获新数据中的更新。此索引管道可能会产生大量的 token 成本。相比之下，传统 RAG 在添加新数据时不需要重新索引管道来生成摘要，从而实现更高效的更新。此外，节点具有数千个连接时，可扩展性可能会成为一个问题，并且高度连接的通用实体类型必须进行过滤，以防止结果出现偏差。为摘要所需的全面预处理既是细节的优势，也是保持当前信息的局限性。
总结
虽然 Naive RAG 是检索增强生成的一个简单有效的起点——尤其是在您的数据结构良好且自包含时——但 Graph RAG 通过理解实体之间的关系和上下文更进一步。当您的数据包含丰富的连接和依赖关系时，例如合同、研究论文或组织记录，它尤其强大。通过在混合系统中结合这两种方法，您可以利用语义相似性和结构洞察力的优势，从而提供更细致、更准确和更有洞察力的响应。无论您是刚刚开始使用 RAG，还是希望通过 GraphRAG 突破界限，选择正确的策略都始于了解您的数据。
准备开始构建了吗？
请查看 快速入门教程，或使用 Weaviate Cloud (WCD) 的免费试用版构建令人惊叹的应用程序。