GraphRAG产业化应用落地挑战和探索：知易行难 - 企业大模型独角兽Glean实践之四

本文链接：https://blog.csdn.net/h1453586413/article/details/143989795

知识图谱中的冒险：知识图谱有价值。由 Brian Godsey 使用 DALL-E 生成。

The Quest for Production-Quality Graph RAG: Easy to Start, Hard to Finish | by Brian Godsey | Nov, 2024 | Towards Data Science

摘要

尽管构建GraphAG 系统很容易上手，但将其投入生产却困难重重，这篇文章探讨了GraphRAG 的优势、挑战以及成功部署的关键策略，并指出了在生产过程中可能遇到的问题和解决方法。

Key Takeaways:

* 虽然如今有很多工具和教程使GraphRAG 易于上手，但将其投入生产却很难。

* GraphRAG 的主要挑战在于解决普通 RAG 系统因仅基于向量搜索而错失相关文档的问题。

* 成功部署GraphRAG 的关键在于构建一个补充而非替代向量搜索的知识图谱。

* 生产过程中可能遇到的问题包括：GraphRAG 性能与普通 RAG 相近、出现幻觉、知识图谱过大或过小，以及可扩展性问题

* 解决这些问题需要检查知识图谱的质量、参数设置、文档集以及检索和过滤策略。

* 选择流行且支持良好的开源工具可以简化开发和部署。

* 选择合适的用例至关重要，例如 Glean 选择了内部文档数据集这个易于管理的用例。

Source:

https://towardsdatascience.com/the-quest-for-production-quality-graph-rag-easy-to-start-hard-to-finish-46ca404cee3d

正文

当我在 VentureBeat 上读到最近一篇关于 Glean 如何在最新一轮融资中获得超过 2.6 亿美元的文章时(https://venturebeat.com/data-infrastructure/how-to-take-advantage-of-a-generative-tool-fueling-gleans-260m-raise-graph-rag/)企业智能知识库企业Glean利用GraphRAG融资2.6亿美元，我立即有两个直觉。首先，看到 graph RAG 的这个非常公开的例子发挥了它作为一种强大、有价值的技术的潜力，它比以往任何时候都更有效地将人们与知识联系起来，这让我感到欣慰。其次，读起来感觉很令人惊讶，但也很有效：

世界上最大的拼车公司之一亲身体验了它的好处。在专门组建了一整个工程师团队来开发类似的内部解决方案后，他们最终决定过渡到 Glean 的平台。

“在一个月内，他们在 Glean 平台上的使用率翻了一番，因为结果就在那里，”Glean 的首席营销官 Matt Kixmoeller 说。

尽管我在新闻文章中读到失败的消息感到惊讶，但根据我的经验以及同事和客户的经验，努力将 Graph RAG 引入生产是我所期望的。我并不是说我预计大型科技公司在构建自己的图谱 RAG 系统方面会失败。我只是预计大多数人将努力构建和生产GraphRAG — 即使他们已经有一个非常成功的概念验证。

我在 The New Stack 中写了一篇对 VentureBeat 文章的高层次回应，在本文中，我想更深入地探讨为什么GraphRAG 如此难以正确。首先，我将指出使用最新工具开始使用 Graph RAG 变得多么容易。然后，我将深入探讨GraphRAG 的一些具体挑战，这些挑战可能使得从 R&D 引入生产变得如此困难。最后，我将分享一些关于如何使用 GraphRAG 最大限度地提高成功机会的技巧。

GraphRAG 入门非常简单

那么，如果一家大型拼车公司不能有效地构建自己的平台，那我为什么会说自己实现 GraphRAG 很容易呢？

知识图谱中的冒险：道路清晰。由 Brian Godsey 使用 DALL-E 生成。

首先，支持 RAG 和GraphRAG 的技术在过去一年中取得了长足的进步。12 个月前，大多数企业甚至没有听说过检索增强RAG。现在，不仅 RAG 支持是 LangChain 等最佳 AI 构建工具的关键功能，而且 AI 领域的几乎每个主要参与者都有一个 RAG 教程，甚至还有一门 Coursera 课程。尝试 RAG 不乏快速切入点。https://www.coursera.org/projects/introduction-to-rag

Microsoft 可能不是第一个开发GraphRAG 的公司，但他们在今年早些时候的一篇研究博客文章中大力推动了这个概念，并且他们继续致力于相关技术。

在 Medium 上，还有一个很好的概念介绍，其中包含一些技术细节，来自 Google 的一位 genAI 工程师。https://towardsdatascience.com/graph-rag-a-conceptual-introduction-41cd0d431375

而且，在 Towards Data Science 中，最近有一篇非常详尽的 how-to 文章，介绍了构建GraphRAG 系统和在科学出版物数据集上进行测试。https://towardsdatascience.com/how-to-implement-graph-rag-using-knowledge-graphs-and-vector-databases-60bb69a22759

作为传统图谱数据库和分析领域的知名品牌，Neo4j 为响应最近的一代 AI 革命，在其旗舰图谱数据库产品中添加了矢量功能，并且他们拥有出色的工具平台，适用于除了标准图谱 RAG 功能外，还需要复杂图谱分析和深度图谱算法的项目。他们还有一个 Graph RAG 入门指南。

https://neo4j.com/developer-blog/graphrag-ecosystem-tools/

另一方面，您甚至不需要图数据库来进行GraphRAG。许多新手认为他们需要部署一个专门的图数据库，但这并不是必要的，实际上可能只是让您的技术栈变得更加复杂。

我的雇主 DataStax 也有 Graph RAG 指南。https://bit.ly/4862Lrl

当然，两个最流行的 gen AI 应用程序组合框架 LangChain 和 LlamaIndex 都有自己的GraphRAG 介绍。有一篇 DataCamp 文章同时使用了这两种方法。https://www.datacamp.com/tutorial/knowledge-graph-rag

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

…但是将 Graph RAG 投入生产环境很困难

这是数据科学中一个非常古老的故事：一种新的软件方法、技术或工具解决了研究环境中的一些棘手问题，但行业努力将其构建到每天提供价值的产品中。这不仅仅是软件开发的努力和熟练程度的问题——即使是最大、最好和最聪明的团队也可能无法克服解决现实世界问题所涉及的真实世界数据的不确定性、不可预测性和不可控性。

知识图谱中的冒险：难度 9 级。由 Brian Godsey 使用 DALL-E 生成。

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

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

但这并不一定意味着 RAG 系统存在“问题”，它可能完全按照设计执行。如果没有问题或 bug，但我们仍然没有得到我们想要的响应，那一定意味着我们期望 RAG 系统具有它根本没有的功能。

在我们了解为什么 graphRAG 难以投入生产之前，让我们先看看我们试图解决的问题。

GraphRAG 解决的主要挑战

由于普通 RAG 系统（没有知识图谱）仅基于向量搜索检索文档，因此只能检索与查询语义最相似的文档。语义上完全不相似或不够相似的文档将被排除在外，并且通常不会提供给在查询时生成对提示的响应的 LLM。

当我们需要在提示中回答问题的文档在语义上与提示并不相似时，RAG 系统通常会遗漏其中的一个或多个文档。当回答问题需要通用和专用文档或术语的混合，并且当文档详细程度很高时，即此特定提示的一些非常重要的详细信息被隐藏在与此提示不相关的相关详细信息中间时，可能会发生这种情况。请参阅本文Your Documents Are Trying to Tell You What’s Relevant: Better RAG Using Links | by Brian Godsey | Sep, 2024 | Towards Data Science https://towardsdatascience.com/your-documents-are-trying-to-tell-you-whats-relevant-better-rag-using-links-386b7433d0f2，了解 RAG 缺失文档的示例，因为两个相关概念（在本例中为“Space Needle”和“Lower Queen Anne neighborhood”）在语义上不相似，请参阅本文，了解由于向量嵌入是“有损”而隐藏在细节密集文档中的重要细节的示例。Vector Embeddings Are Lossy. Here’s What to Do About It. | by Brian Godsey | Sep, 2024 | Towards Data Science

https://towardsdatascience.com/vector-embeddings-are-lossy-heres-what-to-do-about-it-4f9a8ee58bb7

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

例如，查看上面链接的示例，我们是否真的想要使用一种嵌入算法，将文本 “Space Needle” 和 “Lower Queen Anne neighborhood” 在语义向量空间中靠得很近？不，微调或找到一种在语义空间中将这两个术语非常紧密地放在一起的嵌入算法可能会产生一些意想不到和不希望的副作用。

最好不要试图强迫语义模型完成地理或旅游信息更适合的工作。如果我是一家旅行或旅游公司，依靠知道这些地标在哪个街区，我宁愿建立一个可以确定地了解这些事情的数据库——这项任务比让语义向量搜索完成相同的任务要容易得多…没有完全的确定性。

所以，这里的主要问题是，我们知道概念和信息在某种程度上是相关的，但在语义向量空间中却无关。其他一些（非矢量）信息来源告诉我们，我们正在研究的各种概念之间存在联系。构建GraphRAG 应用程序的任务是有效地将概念之间的这些联系捕获到知识图谱中，并使用图谱连接检索更多相关文档以响应提示。

知识图谱中的冒险：注意你的步骤。由 Brian Godsey 使用 DALL-E 生成。

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

将 Graph 与 RAG 集成的指导原则

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

1. 图谱应包含高质量、有意义的概念和联系
2. 概念和连接应与用例集中的提示相关
3. 图谱连接应补充而不是替换向量搜索
4. 应优先考虑一步和两步图谱连接的有用性;依赖三个以上的步骤来建立连接应仅用于特殊使用案例。

也许在以后的文章中，我们将深入探讨遵循这些原则的细微差别和潜在影响，但现在，我只想指出，此列表旨在共同提高可解释性，防止过度复杂，并最大限度地提高构建和使用GraphRAG 系统的效率。

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

知识图谱中的冒险：策略游戏。由 Brian Godsey 使用 DALL-E 生成。

GraphRAG 应用程序可能无法投入生产的原因

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

上面，我们讨论了如何轻松实现GraphRAG 来获得初步结果，但很难获得好的结果，更不用说生产质量的结果了。接下来，我们看看您在构建和测试GraphRAG 应用程序时可能遇到的一些潜在问题。

知识图谱中的冒险：未开发的原始价值。由 Brian Godsey 使用 DALL-E 生成。

GraphRAG 并不比普通RAG 好多少

如果您的GraphRAG 系统的性能与普通 RAG 系统的性能大致相同，则可能有多种原因。一般来说，这似乎意味着图谱没有为系统增加价值，但这可能是由低质量的知识图谱、图谱利用不足、次优参数设置或许多其他原因引起的。或者，可能根本没有问题;Vector Search 可能在查找正确的文档方面做得非常出色，根本不需要图谱。

看什么：

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

你（仍然）看到幻觉

如果您在图谱RAG 中看到幻觉，而您在普通 RAG 中看不到，我会怀疑某处存在错误或参数设置错误。如果您看到类似程度的幻觉，这听起来像是图谱方面之外的一般问题。

看什么：

您的文档集是否包含对引起幻觉的提示的正确响应？矢量搜索能找到这些文档吗？
检索到的文档的正确响应是否正确插入到传递给 LLM 的提示的上下文中？

图谱“太大”

当您的知识图谱“太大”或太密集时，可能会出现两种主要类型的问题。首先，扩展可能存在问题，我将在下面讨论。其次，图谱遍历可能会导致 “太多” 文档，然后必须重新排名和过滤。如果重新排名和筛选策略不能很好地与 retrieval 和 graph traversal 元素配合使用，则最终可能会在图谱刚刚发现重要文档后立即筛选掉它们。

看什么：

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

图谱“太小”

如上所述，如果图谱 “太大”，则它可能充满了低质量的连接。如果图谱 “太小”，我希望那里的连接是有意义的，这很好，但缺少的连接主要有两种类型。第一个是由图构建过程中的一个 bug 引起的。第二个是由不是为其设计的图谱构造引起的。不同上下文或不同格式的数据可能通过不同的图谱构造方法进行不同的处理。

看什么：

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

您找不到 “中等” 图谱

您是否觉得您可以构建一个 “太大” 或 “太小” 的图谱，但你不能在中间构建一些东西？

看什么：

您要更改哪些参数或方法以从小到大或再次返回？这些应该对图谱质量产生如此大的影响吗？您能否研究一些意外出现或消失的图谱元素，具体取决于您使用的图谱构造设置？
另请参阅上面“大”和“小”部分中的相关提示。

您的实施需要新软件或增加部署复杂性

这是一个典型的数据科学问题：构建非常酷和尖端的方法，却看到开发团队拒绝或努力将笔记本中的代码引入生产环境。坚持使用最受欢迎、支持最充分且大部分开源的工具可以更轻松地进行生产，尤其是在您的组织已经在其他地方使用这些工具时。

看什么：

您的实施是否需要为图谱创建新的数据存储？您可能不需要图谱数据库，并且可能还可以将生产矢量存储用于图谱。
您是否正在使用一些最流行的开源工具来构建 AI 应用程序，例如 LangChain？这些可以降低代码复杂性，使应用程序更具可移植性，并扩展潜在的集成和进一步开发。

您的实施无法扩展

文章 Scaling Knowledge Graphs by Eliminate Edges in The New Stack https://thenewstack.io/scaling-knowledge-graphs-by-eliminating-edges/展示了一种使GraphRAG 非常可扩展的方法。如上所述，最受欢迎、最受支持且大部分开源的工具通常是实现轻松扩展的最佳途径，但这并不总是那么容易。

看什么：

哪个部分没有缩放？图遍历、重新排名、结果编译还是其他？有关更多提示，请参阅上面的“图谱太大”。
您是否有某个特定的组件不能很好地扩展？有时，使用像 ‘networkx’ 这样的内存图谱库 — 甚至是图谱数据库 — 来执行复杂的图谱操作可能会导致资源瓶颈。您可能希望切换到更具可扩展性的图谱操作选项。
您是使用并行 API 调用来处理大部分繁重的工作，还是尝试在主应用程序逻辑中执行复杂或昂贵的计算？

在生产环境中使用 GraphRAG 取得成功

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

知识图谱中的冒险：知识就是金钱。由 Brian Godsey 使用 DALL-E 生成。

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

GraphRAG 系统的一个经常被低估的方面是输入数据的质量和可靠性以及将其获取到那里的管道。这与数据工程和传统软件开发的关系更大，而不是 AI。在以前的技术范式中，由于数据类型和访问方法不兼容，连接不同的数据系统具有挑战性。现在，AI 和 LLM 支持集成不同来源的非结构化数据，从而允许将来自不同来源的数据整合到单个 RAG 系统中。这种集成功能使 LLM 能够处理和理解来自各种来源的非结构化数据，例如内部网页、Wiki、代码存储库、数据库、Google Docs 和聊天日志。只需将所有这些信息连接在一起并使其从单个界面访问即可成为一个巨大的胜利。

前进的道路

为任何用例构建GraphRAG 系统都涉及利用基础组件，例如矢量和图谱的数据存储、嵌入和 LLM，并通过 LangChain 和 LlamaIndex 等开源编排工具进行增强。这些工具有助于开发强大、可扩展和高效的系统，有望在未来公司通过自动化和简化来优化知识工作，从而取得实质性成功。

知识图谱和GraphRAG 系统（尤其是 Glean）等公司的公开成功，展示了这些技术对内部用例的有效性，通过提高组织效率来创造价值。然而，外部、企业和面向消费者的产品的更广泛应用潜力在很大程度上仍未得到开发，这为其他公司提供了许多探索机会。

也许值得注意的是，我们已经处于所谓的“信息时代”至少 30 年了，直到最近一两年，我们才真正开始组装构建块，以连接跨来源、跨想法、跨文档和跨概念的所有信息。这样我们的软件系统就可以做出与我们作为人类日常知识工作中使用的相同类型的推理、逻辑和判断。有些人称之为 “智能时代”。

虽然最初专注于简单明了的决策，但 AI 的轨迹是管理更复杂的场景，从而显著提高时间和成本的效率。这一激动人心的演变使许多 AI 应用程序（包括图谱 RAG）在改变知识在各种环境中互连和利用的方式方面发挥着关键作用。A Guide to GraphRAG, a New Way to Push the Boundaries of GenAI Apps | by DataStax | Building Real-World, Real-Time AI | Medium