追求生产质量 Graph RAG：开始容易，完成难

Rifx.Online
Programming , Data Science , Generative AI
01 Nov, 2024

克服图形 RAG 生产化的挑战

当我阅读最近在 VentureBeat 上关于 Glean 刚刚在最新融资轮中获得超过 2.6 亿美元的文章时，我有两个直接的直觉。首先，看到这个非常公开的图形 RAG 示例充分发挥其作为一种强大、有价值的技术的潜力，能够比以往任何时候都更高效地将人们与知识连接起来，这让我感到满意。其次，读到以下内容让我感到惊讶但又颇具验证性：

世界上最大的共享出行公司之一亲身体验了其带来的好处。在专门投入整个工程团队开发类似的内部解决方案后，他们最终决定转向 Glean 的平台。

“在一个月内，他们在 Glean 平台上的使用量翻了一番，因为结果是显而易见的，”Glean 的首席营销官 Matt Kixmoeller 说。

虽然我对新闻文章中提到的失败感到惊讶，但根据我自己的经验以及同事和客户的经历，努力将图形 RAG 推向生产是我所预料的。我并不是说我期望大型科技公司在构建自己的图形 RAG 系统时会失败。我只是期望大多数人会在构建和生产化图形 RAG 时遇到困难——即使他们已经有一个非常成功的概念验证。

我在 The New Stack 上对 VentureBeat 文章做了一个高层次的反应，在这篇文章中，我想深入探讨为什么图形 RAG 可能如此难以做到正确。首先，我将指出，利用最新工具，开始使用图形 RAG 变得多么简单。然后，我将深入探讨一些特定的图形 RAG 挑战，这些挑战使其从研发转向生产变得如此困难。最后，我将分享一些关于如何最大化成功机会的图形 RAG 的建议。

开始使用图形 RAG 很简单

如果一家大型共享出行公司无法有效构建自己的平台，那么我为什么会说自己实现图形 RAG 很简单呢？

首先，支持 RAG 和图形 RAG 的技术在过去一年中取得了长足的进步。十二个月前，大多数企业甚至没有听说过检索增强生成。现在，RAG 支持不仅是像 LangChain 这样的最佳 AI 构建工具的关键特性，而且几乎每个主要的 AI 参与者都有 RAG 教程，甚至还有 Coursera 课程。尝试 RAG 的快速入门途径层出不穷。

微软可能不是第一个做图形 RAG 的公司，但他们在今年早些时候发布的研究博客文章中对这一概念进行了大力推动，并继续致力于相关技术的研究。

在 Medium 上，还有一篇来自谷歌的一位生成 AI 工程师的很好的概念介绍，包含了一些技术细节。此外，在 Towards Data Science 上，还有一篇最近的、非常详尽的关于构建图形 RAG 系统的操作指南，以及在科学出版物数据集上进行测试的内容。

在传统图形数据库和分析领域，知名品牌 Neo4j 在其旗舰图形数据库产品中增加了向量能力，以响应最近的生成 AI 革命，并为需要复杂图形分析和深度图形算法的项目提供了一系列优秀的工具平台，除了标准的图形 RAG 功能外。他们还提供了图形 RAG 入门指南。

另一方面，您甚至不需要图形数据库就可以做图形 RAG。许多刚接触图形 RAG 的人认为他们需要部署一个专门的图形数据库，但这并不是必要的，实际上可能会使您的技术栈变得更加复杂。

我的雇主 DataStax 也有图形 RAG 指南。

当然，两个最受欢迎的生成 AI 应用程序组合框架，LangChain 和 LlamaIndex，各自都有自己的图形 RAG 介绍。此外，还有一篇 DataCamp 文章同时使用了这两者。

有了所有可用的工具和教程，开始使用图形 RAG 是简单的部分……

…但将图形 RAG 投入生产是困难的

这是数据科学中一个非常古老的故事：一种新的软件方法论、技术或工具在研究环境中解决了一些重要问题，但行业在将其构建为每天提供价值的产品时却面临困难。这不仅仅是软件开发的努力和专业水平的问题——即使是最大的、最优秀的团队也可能无法克服解决现实世界问题所涉及的现实数据的不确定性、不可预测性和不可控性。

不确定性是构建和使用数据中心系统的固有部分，这些系统几乎总是具有某些随机性、概率或无界输入的元素。而且，当输入和输出是非结构化的时，不确定性可能会更大，这正是 LLM 和其他 GenAI 应用程序的自然语言输入和输出的情况。

想要尝试图形 RAG 的人通常已经拥有一个现有的 RAG 应用程序，该应用程序在简单用例中表现良好，但在一些更复杂的用例和需要跨知识库多个信息片段的提示中失败，可能涉及不同的文档、上下文、格式或甚至数据存储。当回答问题所需的所有信息都在知识库中，但 RAG 系统找不到时，这似乎是一个失败。从用户体验 (UX) 的角度来看，确实如此——没有给出正确的答案。

但这并不一定意味着 RAG 系统存在“问题”，它可能正如其设计那样运行。如果没有问题或错误，但我们仍然没有得到想要的响应，那一定意味着我们期望 RAG 系统具备它根本没有的能力。

在我们具体探讨为什么将图形 RAG 投入生产很困难之前，让我们先看看我们试图解决的问题。

图形 RAG 解决的主要挑战

因为普通的 RAG 系统（没有知识图谱）仅基于向量搜索来检索文档，所以只能检索与查询在语义上最相似的文档。那些完全不相似或相似度不够的文档则被排除在外，通常不会在查询时提供给生成响应的 LLM。

当我们需要回答提示中的问题的文档并不都是与提示在语义上相似时，RAG 系统往往会遗漏一个或多个文档。这种情况可能发生在回答问题时需要混合一般性和专业性的文档或术语，并且当文档在细节上非常密集时，某些对这个特定提示非常重要的细节可能会被埋没在与该提示不太相关的相关细节中。请参见这篇文章，了解 RAG 如何遗漏文档的例子，因为两个相关概念（在这种情况下是“太空针”和“下皇后安妮社区”）在语义上并不相似，并且请参见这篇文章，了解重要细节如何被埋没的例子，因为向量嵌入是“有损”的。

当我们看到检索“失败”未能找到正确的文档时，可能会想要尝试改进向量搜索或使其更贴合我们的用例。但这需要调整嵌入，而嵌入是复杂的、混乱的、计算成本高昂的，甚至微调的成本更高。此外，这甚至不是解决问题的最佳方法。

例如，看看上面链接的例子，我们真的想使用一个将“太空针”和“下皇后安妮社区”在语义向量空间中放得很近的嵌入算法吗？不，微调或寻找一个将这两个术语在语义空间中放得非常近的嵌入算法可能会产生一些意想不到和不希望的副作用。

最好不要强迫语义模型去做一个地理或旅游信息更适合的工作。如果我是一个依赖于了解这些地标所在社区的旅行或旅游公司，我宁愿建立一个能够确定这些信息的数据库——这个任务比让语义向量搜索完成同样的任务要容易得多……而且没有完全的确定性。

因此，这里主要的问题是，我们有一些我们知道以某种方式相关的概念和信息，但在语义向量空间中并不相关。某些其他（非向量）信息来源告诉我们，我们正在处理的各种概念之间存在联系。构建图形 RAG 应用的任务是有效地将这些概念之间的连接捕捉到知识图谱中，并利用图形连接来检索更相关的文档，以响应提示。

总结一下我们试图通过图形 RAG 解决的问题：存在半结构化、非语义的信息连接着我非结构化文档中出现的许多概念——我希望利用这些连接信息来补充语义向量搜索，以检索最适合回答我用例中提示和问题的文档。我们只是想让检索变得更好，并希望使用一些外部信息或外部逻辑来实现这一点，而不是仅仅依赖语义向量搜索来连接提示与文档。

将图形与 RAG 集成的指导原则

考虑到上述动机——使用“外部”信息来建立语义搜索可能遗漏的文档连接——在构建和测试图形 RAG 应用程序时，我们可以牢记一些指导原则：

图形应包含高质量、有意义的概念和连接
概念和连接应与用例集中的提示相关
图形连接应补充而不是替代向量搜索
应优先考虑一步和两步图形连接的实用性；依赖于超过三步的连接应仅限于专业用例。

也许在未来的文章中，我们将深入探讨遵循这些原则的细微差别和潜在影响，但目前我只想指出，这个列表旨在共同提高可解释性，防止过于复杂，并最大化构建和使用图形 RAG 系统的效率。

遵循这些原则以及软件工程和数据科学的其他核心原则，可以增加成功构建有用且强大的图形 RAG 应用程序的机会，但在此过程中肯定会有陷阱，我们将在下一节中概述。

你的图形 RAG 应用可能无法投入生产的原因

任何花费大量时间围绕数据、复杂算法、统计学和人类用户构建软件的人都可能理解，在构建像图形 RAG 这样的系统时存在很多不确定性。在数据准备和加载、构建知识图谱、查询和遍历图形、结果汇编和提示构建，以及几乎工作流程中的任何其他点，都可能发生意外情况。

在上面，我们讨论了如何轻松实现图形 RAG 以获得初步结果，但要获得良好的结果，更不用说生产级别的结果了，可能会很困难。接下来，我们将看看在构建和测试图形 RAG 应用时可能遇到的一些潜在问题。

图形RAG的表现与普通RAG相差无几

如果您的图形RAG系统的性能与普通RAG大致相同，可能有多种原因。一般来说，这似乎意味着图形并没有为系统增加价值，但这可能是由于低质量的知识图、图的利用不足、参数设置不佳或其他许多原因造成的。或者，根本没有问题；向量搜索可能在寻找正确的文档方面表现出色，而图形根本不需要。

需要关注的事项：

您是否有普通RAG无法很好处理的示例提示，但您期望图形RAG能够成功处理？您能否在这些提示上进行“调试”，看看后台发生了什么？
知识图是否包含语义搜索可能无法建立的有意义连接？您能否找到在图中连接的概念对的示例，其相关文档在向量空间中相距甚远？知识图应该在“远离”的文档之间建立有意义的连接。

你（仍然）看到幻觉

如果你在使用图形 RAG 时看到的幻觉与使用普通 RAG 时不同，我会怀疑某处存在错误或参数设置不当。如果你看到的幻觉水平相似，这听起来像是一个超出图形方面的一般问题。

需要关注的事项：

你的文档集是否包含对引发幻觉的提示的正确响应？向量搜索是否找到了这些文档？
从检索到的文档中获取的正确响应是否正确插入到传递给 LLM 的提示上下文中？

图表“过大”

当您的知识图谱“过大”或过于密集时，可能会出现两种主要问题。首先，可能会出现扩展性问题，我将在下面讨论。其次，图遍历可能导致“过多”的文档，这些文档必须重新排序和过滤。如果重新排序和过滤策略与检索和图遍历元素不兼容，您可能会在图刚发现重要文档后立即将其过滤掉。

需要关注的内容：

图遍历后返回了多少文档，多少被重新排序或过滤掉？通过强图连接找到的文档是否能成功存活于过滤中？
您是否构建了一个充满适合您用例的有意义连接的知识图谱？在图中，您能否找到许多对您的用例过于通用或无关的概念或连接？您的知识图谱中有多少是由低质量信息组成的？

图形“太小”

根据上述，如果图形“太大”，可能会充满低质量的连接。而如果图形“太小”，我希望那里存在的连接是有意义的，这很好，但缺失的连接主要有两种类型。第一种是由于图形构建过程中出现的错误引起的。第二种是由于图形构建未针对其进行设计。不同上下文或不同格式的数据可能会被不同的图形构建方法以不同的方式处理。

需要关注的内容：

你是否使用带有实体/关键词提取的LLM构建了知识图谱？你是否捕获了每个文档中所有有意义的实体，还是LLM限制了其输出？
在你的文档中，有哪些概念和连接是你期望出现在知识图谱中的，但似乎缺失了？你期待它们何时以及如何被添加到图谱中？为什么它们实际上没有被添加到图谱中？

你找不到“适中”图表

你是否觉得可以构建一个“过大”或“过小”的图表，但无法构建一个中等大小的图表？

需要注意的事项：

你正在更改哪些参数或方法来从小到大或反向变化？这些是否应该对图表质量产生如此大的影响？你能否研究一些根据所使用的图表构建设置意外出现或消失的图表元素？
另请查看上面“过大”和“过小”部分的相关提示。

你的实现需要新的软件或增加部署复杂性

这是一个经典的数据科学问题：构建非常酷炫和前沿的方法，却看到开发团队拒绝或难以将你笔记本中的代码引入生产环境。坚持使用最流行、支持最好的以及大部分开源的工具，可以更容易地进入生产，特别是如果你的组织在其他地方已经使用这些工具的话。

需要关注的事项：

你的实现是否需要为图形创建新的数据存储？你可能不需要图形数据库，而且可能能够使用你的生产向量存储来处理图形。
你是否在使用一些最流行的开源工具来构建AI应用程序，比如LangChain？这些工具可以减少代码复杂性，使应用程序更具可移植性，并扩展潜在的集成和进一步开发。

你的实现无法扩展

文章 Scaling Knowledge Graphs by Eliminating Edges 在 The New Stack 中展示了一种使图形 RAG 非常可扩展的方法。像上面提到的，最流行、支持最好的、并且大多数是开源的工具通常是无痛扩展的最佳路径，但这并不总是容易。

需要关注的内容：

哪一部分无法扩展？图遍历、重新排序、结果汇编，还是其他？请参见上面的“The graph is too big”以获取更多提示。
你是否有某个特定组件无法很好地扩展？有时使用内存中的图形库，如 ‘networkx’ — 或者甚至是图形数据库 — 来执行复杂的图形操作可能会造成资源瓶颈。你可能想要切换到更可扩展的图形操作选项。
你是否在使用并行 API 调用来处理大部分繁重的工作，还是在尝试在主应用逻辑中进行复杂或高成本的计算？

在生产中利用图形RAG获得成功

创建成功的图形RAG系统的关键在于构建一个知识图谱和遍历逻辑，以补充语义向量检索，而不是取代或与之竞争。图形设计应旨在在合适的时间连接正确的节点、知识、实体和文档，从而能够组装合适的文档，以产生最有帮助和可操作的查询响应。

关于Glean，值得注意的是，内部文档数据集是图形RAG的一个完美用例。知识图谱可以连接人、项目、产品、客户、会议、地点等——所有这些在数量上都受到组织规模和其工作内容的限制。构建和管理一个由数千名员工组成的图形比例如尝试对维基百科上提到的所有人或大型财务或法律文档数据库中的所有人做同样的事情要可行得多。因此，Glean做出的第一个重大决策可能是找到一个很好的图形RAG用例来解决问题。

图形RAG系统的一个常被低估的方面是输入数据的质量和将其传输到目的地的管道的可靠性。这与数据工程和传统软件开发的关系大于与AI的关系。在以往的技术范式中，由于数据类型和访问方法的不兼容，连接不同的数据系统是一个挑战。现在，AI和LLMs使得将不同来源的非结构化数据整合成为可能，从而允许将来自各种来源的数据整合到一个单一的RAG系统中。这种集成能力使得LLMs能够处理和理解来自各种来源的非结构化数据，例如内部网页、维基、代码库、数据库、Google文档和聊天记录。仅仅将所有这些信息连接在一起，并通过单一接口使其可访问，就可以带来巨大的收益。