餐饮连锁企业网站建设方案,北京软件研发公司,北京网吧,服务号 wordpress作者#xff1a;来自 Elastic Louis Jourdain 及 Ivan Monnier 了解如何使用知识图谱来增强 RAG 结果#xff0c;同时在 Elasticsearch 中高效存储图谱。本指南探讨了根据用户查询动态生成知识子图的详细策略。 检索增强生成 (RAG) 通过将大型语言模型 (LLM) 的输出基于事实数…作者来自 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 的上下文以生成对用户查询的事实答案。 图 1传统基于文档的 RAG 系统的架构。 B基于文档的 RAG 的局限性
虽然这种架构在学术界和企业界都引起了热情并且显著帮助减少了幻觉但在应用于大型超过 10,000 个文档和特定领域的数据集时它往往无法产生正确的答案。这主要是由于以下几个因素
查询依赖性检索阶段高度依赖于用户的查询。格式不正确或不清楚的查询将无法产生最相关的文档。特定领域的嵌入问题在通用数据上训练的嵌入通常无法捕捉特定于特定领域的实体的含义。当所有文档都关注类似主题时检索的精度会降低。上下文窗口限制经典 RAG 是短视的因为它只能访问 LLM 上下文窗口中提供的文档的有限内容。数据本身缺乏联系文本文档通常不明确包含用户问题的答案因为相关信息分散在多个文档中这使得基于文本的检索器很难重建谜题。
因此除非两个概念明确出现在同一个文档中否则经典 RAG 系统很难识别不同实体之间的联系。这些琐碎的情况没有考虑到用户查询的全部范围导致召回性能不佳。
例如考虑以下查询
“List some startups that were founded by former employees of Google. - 列出一些由谷歌前员工创立的初创公司。”
经典 RAG 只会检索最明确的文档例如
“Ben Silbermann, one of Pinterests 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 RAGGraph-Based RAG易于实施原理简单/实现起来不简单 如何检索以及检索什么如何将其提供给 LLM仅限于提供有限数量的上下文上下文窗口的技术限制专注于三元组。能够在提示中提供更大比例的知识库无法连接超过 k 个文档的信息能够参见图的数学性质轻松确定命名实体之间的链接或不存在的链接并使用来自所有文档的信息。 C实现图 RAG 的不同方案
最近的研究探索了几种将知识图谱与大型语言模型 (LLMs) 连接起来的方法。以下是最有前途的策略 1) 节点和关系提取
此方法嵌入知识图谱的组件、其顶点节点和边关系使用与查询所用的嵌入方法一致的相关嵌入技术。然后根据向量相似性检索这些嵌入。例如在研究“Graph Reasoning for Question: Answering with Triplet Retrieval - 问题的图推理使用三元组检索回答”Li 等人2023 年中作者提出将 KG 三元组线性化为句子并嵌入它们以检索最相关的三元组。然而这种方法与经典的 RAG 非常相似其中 KG 三元组充当 “块”。它未能充分利用知识图谱独特的数学和结构属性例如关系路径和图遍历。 2) 图形聚类和聚类汇总 (Microsofthttps://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部分用户查询的命名实体和概念识别 2使用 Elastic 生成相关知识子图
由于我们已经从用户的问题中提取了最相关的实体如果有多个实体我们可以查询该图以确定它们是否紧密相关。虽然查询具有数百万个节点的图形数据库并计算最短路径的成本可能非常高但使用对源和目标的过滤搜索提取存储在 Elastic 中的三元组的节点非常简单。我们利用此功能使用以下过程从查询实体中迭代扩展搜索
要检查两个实体是否连接
我们首先检查两者之间是否有直接关系。如果没有则使用过滤查询检索连接到这两个实体之一的节点列表。利用 Elastic 堆叠布尔查询的能力我们检查关系存储是否包含链接到第一个实体的任何元素与链接到第二个实体的任何元素之间的至少一个连接。 如果发现连接我们将停止图形扩展。否则我们重复该过程检查连接到第一个和第二个实体的节点的所有直接邻居。 我们将迭代次数限制为三次因为两个通过超过六跳连接的实体仅具有松散的关系。 图 3如何动态构建连接 Nancy Pelosi 和 Rachida Dati 的知识图谱 我们动态生成的子图的大小很难预测完全取决于查询和数据集的内容。在动态图生成过程中我们强制执行的唯一约束是我们不会为每个节点收集超过 100 个邻居。因此在最佳情况下如果两个实体之间存在直接连接则该图将包含最多 2 个主要实体 2 x 100 202 个主要实体的直接邻居节点和 201 条边。除此之外由于查询的 Elastic 10 000 结果默认限制我们认为这是合理的因此没有为此进行扩展每个扩展阶段最多可以带来 10 000 个新节点因此在最坏情况下对于具有两个实体的查询该图可能包含 3nb_of_hopsx 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 73 跳 x 2 1 个连接节点。 4) 图形文本线性化
为了回答用户的查询我们选择了图形的相关部分但需要将其转换为可以输入到 LLM 以生成最终答案的格式。我们选择将图形线性化为文本格式从图形中生成两种类型的 “pseudo-documents - 伪文档”。 图 5从图中创建伪文档的两种方法 这些伪文档是通过将 KG 的三元组连接成可读格式而创建的。文档存储中说明每个三元组的句子也包括在内从而增强了可读性并提供了支持证据。然后这些文档被输入到 LLM作为经典 RAG 检索器检索到的文档的替代或补充。 图 6线性化图表的示例 B) 利用 Elasticsearch 可塑性的时间优化策略
利用 Elasticsearch (ES) 对文本数据的高效检索功能我们可以动态构建、简化和线性化图形其时间相当于传统 RAG 管道中文档检索和重新排序所需的时间。这是在最终答案生成之前无需调用 LLM 甚至使用嵌入模型即可实现的。
这种节俭的方法可以在包含超过 10 万个文档的语料库上无缝扩展在最坏的情况下只需不到 2 秒即可连接多个实体。以下 ES 功能使这成为可能
组合过滤布尔查询用于限制构建图形所需的查询数量最多 10 个 ES 查询用于构建具有三个扩展阶段的 KG我们在这里不包括任何查询因为它们可能比实际文章占用更多位置。过滤 KNN 查询应用于根据三元组与用户查询的相似性有效地重新排序三元组。 图 7KNN 查询提取与用户查询最相关的实体的关系 由于实体可以与不同的关系相关联因此可以通过从关系索引中派生出第二个索引称为聚合关系索引来实现进一步的优化。由于每个实体平均有 17 个关系因此使用聚合关系索引除以 17 可以减少检索过程某些步骤的延迟。 此索引仅存储两个实体之间每个链接的来源、目的地和出现次数。通过这样做
仅保留一个对象来表示实体 A 和 B 之间的链接。计算复杂度降低特别是对于基数较高的节点。 图 9查询聚合关系索引快速了解节点连接到哪些节点的方法 我们使用三重 ES 索引结构使用单个数据库引擎实现了基于文档和图形的混合 RAG 系统。这种方法无需额外的基础设施即可实现高效的图形构建和检索。 图 10结合文档和基于图形的检索的整个混合 RAG 流程概览 结论
使用知识图谱增强检索增强生成 (Retrieval-Augmented Generation - RAG) 是一项快速发展且前景光明的事业。虽然研究人员和从业者提出了各种策略但许多实现都缺乏实际大规模应用所需的简单性和可扩展性。
本文概述的方法展示了如何利用 Elasticsearch 的向量数据库功能来动态生成针对每个用户查询量身定制的相关子图。通过专注于知识图谱中最重要的部分此方法避免了对单独的图形数据存储的需求降低了基础设施的复杂性同时有效地扩展到数百万个文档和关系。
想要获得 Elastic 认证了解下一次 Elasticsearch 工程师培训的时间
Elasticsearch 包含许多新功能可帮助你为你的用例构建最佳搜索解决方案。深入了解我们的示例笔记本以了解更多信息开始免费云试用或立即在你的本地机器上试用 Elastic。 原文Navigating graphs for Retrieval-Augmented Generation using Elasticsearch - Elasticsearch Labs
