使用 Elasticsearch 导航检索增强生成图表

作者：来自 Elastic Louis Jourdain 及 Ivan Monnier

了解如何使用知识图谱来增强 RAG 结果，同时在 Elasticsearch 中高效存储图谱。本指南探讨了根据用户查询动态生成知识子图的详细策略。

检索增强生成 (RAG) 通过将大型语言模型 (LLM) 的输出基于事实数据来增强其性能，但传统的基于文档的 RAG 面临着诸如上下文窗口狭窄和数据不连贯等限制。一个有前途的解决方案是利用知识图谱，它将数据结构化为实体（entities）和关系（relationships），以实现更深入、更具上下文的检索。本文探讨了如何调整 Elasticsearch 以有效实现基于图的 RAG。通过动态构建和修剪针对用户查询的知识子图，并将它们线性化以用于 LLMs，这种混合方法无需额外的基础设施即可实现可扩展性和精确度，为基于事实的 AI 应用开辟了新的可能性。

背景

自 2022 年以来，随着大型语言模型 (LLMs) 的兴起及其令人印象深刻的语言生成能力，将它们集成到众多任务和应用程序中的需求日益增长。然而，由于 LLM 主要接受下一个单词预测的训练，因此它们容易产生幻觉，产生的输出有时可能不可靠且不基于事实信息。

为了解决这一限制，出现了一种称为检索增强生成 (Retrieval-Augmented Generation - RAG) 的新架构。RAG 旨在通过将 LLM 的输出建立在相关的特定领域数据上来确保其可靠性。尽管 RAG 的传统文档驱动方法前景光明，但它存在明显的局限性。具体来说，它只能利用数据库的一小部分 —— 通常是适合模型上下文窗口的少数文档。这种对数据的受限访问限制了它在需要更广泛地了解信息的情况下的有效性。

为了克服这一限制，研究人员提出利用知识图谱来增强 RAG 性能。与基于文档的方法不同，知识图谱允许实体之间存在结构化关系，从而实现更深入、更具上下文的检索。然而，将知识图谱无缝集成到 RAG 中仍然是一个挑战，尤其是在使用 Elasticsearch 等工具时，虽然 Elasticsearch 对于基于文档的 RAG 非常有效，但尚未为基于图的实现而设计。

在本文中，我们将探讨 Graph RAG 背后的直觉，以及如何创造性地重新利用 Elasticsearch 来实现它。我们将首先讨论传统的基于文档的 RAG 架构及其局限性。接下来，我们将研究在知识图谱上实现 RAG 的各种策略，以确定与我们的特定用例最相关的方法。最后，我们将深入解释如何使用 Elasticsearch 来存储和查询图结构，从而实现快速且可扩展的 Graph RAG 实现。

I）基于文档的 RAG：原理及其不足之处

A) RAG 架构入门

RAG（检索增强生成）背后的关键思想是根据与用户查询的相似性从数据存储中检索相关文档或文档片段（称为块 - chunk）。可选地，在重新排序阶段（可显著提高检索的精度）之后，将检索到的文档集成为 LLM 的上下文，以生成对用户查询的事实答案。

B）基于文档的 RAG 的局限性

虽然这种架构在学术界和企业界都引起了热情，并且显著帮助减少了幻觉，但在应用于大型（超过 10,000 个文档）和特定领域的数据集时，它往往无法产生正确的答案。这主要是由于以下几个因素：

查询依赖性：检索阶段高度依赖于用户的查询。格式不正确或不清楚的查询将无法产生最相关的文档。
特定领域的嵌入问题：在通用数据上训练的嵌入通常无法捕捉特定于特定领域的实体的含义。当所有文档都关注类似主题时，检索的精度会降低。
上下文窗口限制：经典 RAG 是短视的，因为它只能访问 LLM 上下文窗口中提供的文档的有限内容。
数据本身缺乏联系：文本文档通常不明确包含用户问题的答案，因为相关信息分散在多个文档中，这使得基于文本的检索器很难重建谜题。

因此，除非两个概念明确出现在同一个文档中，否则经典 RAG 系统很难识别不同实体之间的联系。这些琐碎的情况没有考虑到用户查询的全部范围，导致召回性能不佳。

例如，考虑以下查询：

“List some startups that were founded by former employees of Google. - 列出一些由谷歌前员工创立的初创公司。”

经典 RAG 只会检索最明确的文档，例如：

“Ben Silbermann, one of Pinterest's founders, previously worked at Google before launching the now-iconic visual discovery platform Pinterest. - Pinterest 的创始人之一 Ben Silbermann 曾在谷歌工作，之后推出了现在标志性的视觉发现平台 Pinterest。”

但是，关键信息可能存在于数据库中，但分散在多个文档中。例如：

“Ben Silbermann, hired at Google … - Ben Silbermann，受雇于 Google……”
“Pinterest was founded by Ben Silbermann… - Pinterest 由 Ben Silbermann 创立……”

在这种情况下，检索阶段将错过连接，因为查询的两个组成部分（“former Google employee - 前 Google 员工” 和 “startup founder - 初创公司创始人”）不会同时出现在单个文档中。

相比之下，数据库的其他表示形式（例如知识图谱）可以无缝链接这些概念，从而提供全面而准确的响应。

II）如何用知识图谱聊天？

A) 什么是知识图谱？

知识图谱 (Knowledge Graph - KG) 由 Google 等公司推广，是一种以最精细的级别表示信息的工具。从数学上讲，知识图谱是一种图，其中：

节点（nodes）表示重要实体或概念（可以包括其他字段或属性）。
边（edges）表示这些实体之间的关系。这些关系可以来自特定本体中的预定义列表（例如，“connects_to”、“is_located_in”），也可以更加开放和灵活。

知识图谱可以表示为三元组列表，形式如下：

（实体 1、关系、实体 2）

然后可以有效地将这些三元组存储在各种类型的数据库中（Elasticsearch 仅引用其中一种...）。

有几种常用的方法可以从文本数据库构建 KG，要么使用传统的 NLP 技术（命名实体识别 (Named Entity Recognition - NER) 来识别实体，基于规则的系统来提取关系，信息提取模型来提取三元组），要么使用大型语言模型 (Large Language Models - LLMs)。

构建 KG 有几个优点：

统一表示（Unified Representation）：整个数据库中的信息被合并为一个对象。
细粒度数据（Fine-Grained Data:）：KG 捕获精确、细粒度的信息，减少噪声内容和不相关的数据。
数学运算（Mathematical Operations）：图形结构允许进行强大的数学运算，例如节点聚类、最短路径识别或模块度估计。

这些属性使知识图谱特别适合于确定实体之间的联系、提出相关见解以及丰富对用户查询的响应。

B) Graph RAG 与 Document RAG

出于上述所有原因，利用知识图谱 (Knowledge Graphs - KG) 代替或结合经典 RAG 方法似乎是克服基于文档的系统局限性的有希望的解决方案。

与传统的基于文档的方法相比，基于图形的 RAG 可以提供几个优势：与仅基于单个文档检索信息的传统 RAG 不同，Graph RAG 可以突出显示实体之间的关系，即使它们不在同一文档中同时出现。这对于发现隐式连接特别有用。通过依赖结构化三元组（实体、关系、实体），KG 提供了数据库的合成和无噪声版本。这增加了 RAG 系统的召回率，因为相关连接不限于文档边界。

例如，想象一下问：“Tell me all you know about Nancy Pelosi - 告诉我你所知道的关于南希·佩洛西的一切”。在经典的 RAG 设置中，最相关的检索文档可能会关注她作为政治家的角色。这种冗余信息往往会导致信息重复，并忽略她生活的其他方面，例如她的教育或私人生活。相比之下，知识图谱会显示更多样化和结构化的信息，例如：

(Nancy Pelosi, is_a, Politician)
(Nancy Pelosi, studied_at, Trinity College)
(Nancy Pelosi, born_in, Baltimore)

这种结构化数据消除了嘈杂的内容，同时提供了对查询实体的更全面的视图。

尽管在概念上听起来很相似，但 Graph RAG 和 Document RAG 在技术上却截然不同。

表 1：基于文档和基于图形的 RAG 解决方案比较
Document-Based RAG	Graph-Based RAG
易于实施	原理简单/实现起来不简单如何检索以及检索什么？如何将其提供给 LLM？
仅限于提供有限数量的上下文（上下文窗口的技术限制）	专注于三元组。能够在提示中提供更大比例的知识库
无法连接超过 k 个文档的信息	能够（参见图的数学性质）轻松确定命名实体之间的链接（或不存在的链接）并使用来自所有文档的信息。

C）实现图 RAG 的不同方案

最近的研究探索了几种将知识图谱与大型语言模型 (LLMs) 连接起来的方法。以下是最有前途的策略：

1) 节点和关系提取

此方法嵌入知识图谱的组件、其顶点（节点）和边（关系，使用与查询所用的嵌入方法一致的相关嵌入技术）。然后根据向量相似性检索这些嵌入。例如，在研究“Graph Reasoning for Question: Answering with Triplet Retrieval - 问题的图推理：使用三元组检索回答”（Li 等人，2023 年）中，作者提出将 KG 三元组线性化为句子并嵌入它们以检索最相关的三元组。然而，这种方法与经典的 RAG 非常相似，其中 KG 三元组充当 “块”。它未能充分利用知识图谱独特的数学和结构属性，例如关系路径和图遍历。

2) 图形聚类和聚类汇总 (Microsoft：https://arxiv.org/abs/2404.1613)

此技术涉及将相似节点分组为聚类（clusters）并选择最相关的聚类（clusters）来回答查询。通过汇总聚类，系统在与 LLM 交互之前降低了图形的复杂性。虽然具有创新性，但这种方法在计算上很昂贵，尤其是对于具有高维数据的大规模图形。

3) 将查询转换为图形查询

受文本到 SQL （text-to-SQL）技术的启发，这种方法将用户的自然语言查询转换为图形数据库查询（例如，使用 Cypher for Neo4j）。然后执行图形查询以提取最相关的子图以供 LLM 处理。

不幸的是，这种方法仅适用于可以有效转换为数据库样式查询的查询。它需要将数据存储在能够执行此类查询的图形数据库中，这就需要为混合 RAG 架构维护两个单独的数据存储（一个用于文档，一个用于图形）。

虽然这些策略很有前景，但它们也面临着重大挑战，例如计算成本、有限的可扩展性和基础设施复杂性。我们希望从知识图谱的强大属性中受益，同时确保可扩展性和效率，并且不使存储基础设施翻倍。希望我们能想出创造性的方法来使用 Elasticsearch 来实现这一目标。

III）使用 Elastic 存储图谱：操作方法？

总体而言，包含 10 万个文档的数据存储可以转换为具有大约 200 万个关系的知识图谱 (knowledge graph - KG)。这些庞大的图谱结构难以理解，操作起来也非常耗费资源。但是，两个简单的观察可以帮助我们重新表述和简化任务：

用户理解（User Comprehension）：最终用户只对他们能理解的内容感兴趣。具有几十个节点的图谱是可管理的，而具有数百万个节点的图谱则毫无用处。
六度原则（The Six Degrees Principle）：根据匈牙利科学家 Frigyes Karinthy（以 “Kevin Bacon - 凯文·培根” 游戏而闻名）的说法，每个人与其他人最多握手六次。在受限环境中，这个数字会进一步下降。同样的原则适用于实体和概念：我们不需要关注整个图谱来回答特定问题。

因此，关键思想是提取与用户问题相关的连贯知识子图。这是可以实现的，因为 KG 在文本数据库中以三元组（源 - source、目标 - destination、关系 - relation）的形式存储。三元组可以选择性地包含文档中说明关系的句子。

A) 将你的 KG 提供给信息饥渴的 LLM 的四步流程

假设我们想在一个专注于法国外交政治的大型数据库中找出 Nancy Pelosi 和 Rachida Dati（法国最无礼的政治家之一）之间的关系。经典 RAG 无法找到相关联系，因为这两个实体没有出现在数据库中的同一篇文档中。我们能在图中恢复这两个女人之间的联系吗？这实际上可以通过四个步骤实现：

1）从用户查询中提取相关节点

使用命名实体识别 (named entity recognition - NER) 管道，我们从用户查询中提取主要实体和概念。

2）使用 Elastic 生成相关知识子图

由于我们已经从用户的问题中提取了最相关的实体，如果有多个实体，我们可以查询该图以确定它们是否紧密相关。虽然查询具有数百万个节点的图形数据库并计算最短路径的成本可能非常高，但使用对源和目标的过滤搜索，提取存储在 Elastic 中的三元组的节点非常简单。我们利用此功能使用以下过程从查询实体中迭代扩展搜索：

要检查两个实体是否连接：

我们首先检查两者之间是否有直接关系。
如果没有，则使用过滤查询检索连接到这两个实体之一的节点列表。
利用 Elastic 堆叠布尔查询的能力，我们检查关系存储是否包含链接到第一个实体的任何元素与链接到第二个实体的任何元素之间的至少一个连接。
- 如果发现连接，我们将停止图形扩展。
- 否则，我们重复该过程，检查连接到第一个和第二个实体的节点的所有直接邻居。
我们将迭代次数限制为三次，因为两个通过超过六跳连接的实体仅具有松散的关系。

图 3：如何动态构建连接 Nancy Pelosi 和 Rachida Dati 的知识图谱？

我们动态生成的子图的大小很难预测，完全取决于查询和数据集的内容。在动态图生成过程中，我们强制执行的唯一约束是，我们不会为每个节点收集超过 100 个邻居。因此，在最佳情况下，如果两个实体之间存在直接连接，则该图将包含最多 2 个（主要实体）+ 2 x 100 = 202 个（主要实体的直接邻居）节点和 201 条边。除此之外，由于查询的 Elastic 10 000 结果默认限制（我们认为这是合理的，因此没有为此进行扩展），每个扩展阶段最多可以带来 10 000 个新节点，因此在最坏情况下，对于具有两个实体的查询，该图可能包含 3（nb_of_hops）x 2（扩展过程的两侧）x 10 000 = 60 002 个节点。

但实际上这样的数字永远无法达到，主要是由于知识图谱的固有拓扑结构，通常显示少量中心（具有高基数的节点），并且有许多节点只有一个邻居（数据库中唯一的实体），这不会扩大搜索范围。数据库中最常见的实体的基数约为 24700，而像 “Rachida Dati” 这样的 “适度” 实体只有 60。每个节点的平均连接数为 16.75。即使在过程中捕获了一些高基数实体，将每个实体的邻居数量限制为 100 个关系也可以确保生成的子图很少大于 1000 个节点。这也是因为枢纽通常与所有其他枢纽相连，因此如果我们想要连接与枢纽相连的实体，路径会非常短（跳数越少，邻居数量的指数漂移就越小），但如果我们想要连接连接不太紧密的节点，路径会更长，但只能遍历基数较低的实体，确保图的大小不会膨胀。

此策略允许我们动态生成仅包含与用户查询相关的节点和边的子图。最后将两位政客联系起来。

3) 图修剪 - Graph pruning

这个子图（几百个关系）足够小，可以进行非常便宜的图操作，但仍然太大，无法直接输入到 LLM 来生成答案。因此，我们需要一个启发式方法来简化它：

第一步：仅选择感兴趣的实体之间最短路径上的关系，从而避免嘈杂的三元组。
第二步：如果剩余的关系集仍然太大，我们将应用图修剪算法。该算法减少了关系的数量，同时最小化了删除的最短路径的数量并保留了出现在这些路径上的实体的多样性。

图 4：图修剪算法的结果，限制路径数量（从 18 条减少到 5 条），同时保持节点多样性

此修剪操作将极大地限制图的大小，仅保留查询实体的直接邻居（100 x nb_entity 节点）和出现在最短路径上的节点。我们无法提前预测有多少条最短路径，因为这取决于图的拓扑结构，但最小化循环可确保在最坏情况下仅保留 100 x nb_entity + nb_shortest_paths x 7（3 跳 x 2 + 1 个连接）节点。