知识图谱并非魔法，也不是万灵药。它们擅长多跳推理和可解释性，但也增加了复杂性，只有当用户真正提出“为什么”和“它们之间有什么联系”的问题时，这种复杂性才值得。

如果你最近参加过GenAI相关的大会，你可能听说过，知识图谱要么是企业AI的救星，要么就是彻头彻尾的骗子。经过 20 多年的软件开发，12 年的图谱系统构建，以及过去两年构建 GenAI 和知识图谱系统、代理以及代理内存解决方案，我可以告诉你，这两个阵营都有对有错——这就是问题所在。

在过去两年左右的时间里，我投入了大量时间研究各种使用知识图谱的技术，例如 GraphRAG、Agent、MCP等。在此期间，一些主要的误解占据了主流。在本文中，我将讨论我所见所闻的一些最常见的误解，并探讨我所认为的这些误解背后的真相。与往常一样，这些只是我的经验和观点，因此我鼓励其他人在此发表评论，无论是支持还是反对。以下是人工智能、大模型、大语言模型、AI代理、通用人工智能的关系，以便我们更好的理解下文所述的内容。

注意：就本文而言，我将知识图谱指代为通用数据结构，而不是特定的格式、数据模型或技术。图谱由许多不同的底层技术支持，例如库、框架、处理引擎、数据库等，所有这些技术都提供了本文强调的基本优势。

误解 1 — 知识图谱对于所有 GenAI 工作都至关重要

如果您一直在研究 GenAI 问题，您可能已经读过一篇或多篇博客文章，其中提到知识图谱有助于实现这些技术在生产层面的运作和扩展，有时甚至更大胆地称其至关重要，。这些大胆的论断通常伴随着一些轻描淡写的概念，例如图谱如何在这些工作中提供范式转变，但除了一些关于捕捉复杂关联数据中的关系、提供基础和实现推理的基本陈述之外，通常很少提供实质性的解释。

事实是，虽然有些工作会受益于它们所包含的结构化知识。

“对于一系列可靠性或安全关键型应用来说，结构化知识仍然不可或缺”

然而，添加这些数据确实会带来额外的成本，包括时间和金钱成本，以及复杂性，而且并不一定能提供更好的答案。例如，GraphRAG 经常被吹捧为比基于向量的 RAG 能为 LLM 提供更完整、更全面的上下文，因此推断其结果会更好。然而，实际情况远非如此。

对于问答任务，我们观察到 RAG 在单跳问题和需要详细信息的问题上表现更好，而 GraphRAG 在多跳问题上更有效。

您是否曾经见过 GraphRAG 应用程序的演示，让您不禁思考“这比矢量 RAG 的答案更好吗？”，并且对它们之间的差异感到有些失望。这是因为并非所有工作或问题都需要将概念联系在一起。在这些用例中，基于向量的 RAG 将提供相同或更好的性能。例如，让我们看一个销售应用程序的示例。如果问题是“我们第三季度的销售额是多少？”，那么这些信息很可能包含在单个文档的单个部分中。对于此用例，向量搜索很有可能找到相关信息来提供答案。但是，如果问题是“为什么第三季度的销售额下降？”，那么向量搜索会找到提及第三季度销售额的文档。但是，图谱将“第三季度销售额→客户投诉→延迟发货→供应商问题”连接起来，为 LLM 提供了可能影响这些结果的相关概念的更完整图景。

假设所提问题在语言上与向量中的数据相似，那么基于向量相似度的搜索将在 topK 中找到最相关的块，从而为 LLM 提供足够的上下文。只有当你需要跨多个文档块连接概念，或者查找概念相关但语言不相关的信息时，图谱中的结构化知识才会开始发挥显著的价值。

事实上，就连 Anthropic 也提到，对于较小的知识库（<20 万个词条），直接向模型提供完整的上下文比考虑更复杂的架构模式（例如 RAG）更有效。诚然，这是 LLM 提供商建议你使用更多词条，但我想说，其基本理念是，对于数据量较少的简单问题领域，在应用程序中添加图谱不会带来或只有有限的好处。

误解2——知识图谱将解决LLM幻觉

这或许是最常见且最具误导性的说法之一。让我澄清一下，在你的项目中添加图谱或任何其他技术并不能消除幻觉。正如我的一位同事常说的那样，“幻觉并非设计缺陷，而是其本身的功能”，而像OpenAI 这样的供应商现在也基本持同样的观点。LLM 中的幻觉是其工作原理的一个基本组成部分，它类似于手机在猜错单词时自动更正的功能，只不过它猜测的是下一个句子、段落等等。提供更相关的上下文和信息已被证明可以提高答案的准确性，但这也仅适用于所提问题是它拥有足够信息来回答的问题的情况。由于 LLM 的设计和评估方式，LLM 仍然可能并且会产生幻觉。

知识图谱可以提供结构化的事实信息，但 LLM 处理数据的基本方式仍然存在，这些方式可能会导致错觉。首先，仅仅因为你提供了正确的数据并不意味着不会出现错误的逻辑跳跃，或者模型会对所提供的数据做出合理的推断。其次，LLM 基于训练数据的概率计算来生成响应。这意味着即使给出了正确的数据，LLM 仍然可以创建看似合理但不正确的信息来填补任何空白。最后，知识图谱包含的信息量以及它在特定上下文中可以提供的信息量是有限的。这导致 LLM 依赖其训练来填补任何空白，这可能会导致不理想的响应，尤其是在数据有限和或提出新问题时。

从本质上讲，大语言模型 (LLM) 试图预测你认为他们想要的答案，而幻觉则是预测错误。知识图谱就像一本精准的参考书，然而，仅仅因为某人拥有正确的参考资料，并不意味着他们总是能够正确地使用它，或者在遇到参考资料以外的问题时停止胡编乱造。

误解3——图系统总是优于矢量或其他系统

这或许是所有误解中最具破坏性的，因为一些博客文章夸大了这种误解，这些文章展示了一些精心挑选的例子，表明基于图的系统产生了显著更好的结果。其含义很明显：如果你仍在使用“普通”的向量系统，那么性能就无从谈起。

事实远没有那么戏剧化，而且更有用。

正如我之前提到的，研究表明，GraphRAG 和传统 RAG 分别擅长不同类型的问题，但并不是说其中一种就普遍更胜一筹。我引用的系统评估论文发现：

“RAG 在单跳问题和需要详细信息的问题上表现更好，而 GraphRAG 在多跳问题上更有效。”

然而，我经常看到团队放弃完好的矢量 RAG 系统而用图谱重建，结果却发现他们的性能要么保持不变，要么变得更糟。

为什么会发生这种情况？

大多数现实世界的问题分布严重偏向单跳查询。让我们看一些实际的模式：

客户支持聊天机器人：

• 大多数问题都是简单的查找：“你们的退货政策是什么？”“我如何重置密码？”—— Vector 检索可以很好地处理这些问题
• 复杂的故障排除问题将受益于图检索
• 您需要决定是否值得为您的解决方案增加复杂性

内部知识库：

• 大多数查询都是事实检索：“第三季度的收入是多少？”“谁拥有项目 X？”并且可以通过向量检索很好地处理
• 图谱的优势主要体现在分析问题上：“为什么 X 项目会失败？”“这些举措之间有什么关联？”
• 如果您的分析是在其他地方完成的（BI 工具、报告），那么图谱只会增加复杂性而无益处。

没人谈论的性能权衡

即使在图谱为多跳问题提供更好答案的用例中，它也会带来很少被强调的成本：

• 延迟：图遍历 + LLM 推理通常比向量相似性搜索 + LLM 推理花费的时间更长，主要是因为发送的上下文量更大
• 复杂性：需要构建、维护和调试的组件更多（图构建、实体提取、关系建模）
• 令牌使用：多跳检索通常会引入更多上下文，从而增加每个查询的成本
• 脆弱性：不良的实体提取或关系建模可能会使结果比简单的方法更差

问题不是“图谱更好，”而是“它在哪些方面更好？

”这里有一个实用的框架：分析实际用户查询的样本并对其进行分类：

• 单跳、直接提问→ 向量检索可能足够且更快；
• 多跳推理问题→图检索增加价值；
• 探索性/分析性问题→图谱可能会增加价值；
• 混合工作→考虑采用混合方法，对问题进行分析并将其路由到适当的位置以使用向量、图谱或两者共用。

令人不安的真相

图谱并非总是最佳选择，GraphRAG 并非天生就是“更好的 RAG”，图谱也并非天生就比非图谱“更好”——它是针对不同问题类型优化的不同数据结构。将其视为通用升级会导致过度设计的解决方案，其性能不如更简单的替代方案。我曾与一些公司合作，由于图谱增加了复杂性，他们投入生产的时间比计划长了数月甚至数年。最糟糕的是？投入生产后，他们的最终用户并没有注意到明显的差异。那些从图谱中看到真正价值的公司，是那些已经测量了问题分布并确认确实需要大规模多跳推理的公司。

如果您还没有完成该分析，那么您还没有准备好决定任何架构，您已经准备好运行实验了。

那么图谱何时能提供价值？

真相——大型语言模型 (LLM) 可以从图的多跳推理和可解释性中受益

构建 LLM 应用程序的根本挑战之一源于其固有的不可预测性和可能产生幻觉，再加上其训练数据是静态的且可能已过时。事实证明，为 LLM 提供更相关、更可靠的数据，可以提供更准确、一致和更可靠的响应。在许多架构模式（例如 RAG）中，这些“黄金”数据是从 LLM或应用程序之外的数据源检索的。但是，既然数据源如此之多，为什么人们还要关注知识图谱呢？

我认为这归结于图谱或关系数据库所回答问题的根本性质：图谱回答的是“如何”和“为什么”的问题，而不是“什么”和“多少”的问题。我们这些从事图谱工作的人常说：“当数据中的联系与数据本身一样重要时，图谱就表现出色”——但我们很少深入探究这在实践中究竟意味着什么。我的一位同事曾说过：关系数据会告诉你某人购买了多少白酒以及购买了哪种类型的白酒，而图谱数据会告诉你他们为什么购买，以及他们接下来可能会购买什么。

举个具体的例子：假设你正在分析白酒购买情况。关系数据库查询可能会告诉你：

• 顾客张三上个月购买了 12 瓶汾酒和 6 瓶茅台酒
• 平均每位顾客每月购买 8 瓶白酒
• 本季度汾酒销量增长15%

这些都是关于“发生了什么”的宝贵见解。但现在，不妨考虑一下，通过遍历关系，图谱可以揭示什么：在图谱结构中，你不仅存储购买记录，还存储实体之间的关系。张三购买了白酒 A。白酒 A 与白酒 B 共享酒香型信息。购买白酒 A 的顾客也经常购买白酒 C。白酒 C 是由张三在社交媒体上关注的白酒厂酿造的。现在，你可以回答不同的问题了：

张三为什么要买那种汾酒？（他一直在探索清香风格的白酒，购买了类似的白酒，并关注这家白酒厂）

接下来你应该推荐什么白酒？（按照他的购买记录→相似的口味→他还没有尝试过的评价很高的白酒的路径）

这位顾客是如何发现你的品牌的？（追踪路径：朋友推荐→共同购买场合→产品发现）

关键区别在于，关系数据库针对聚合和过滤离散数据点进行了优化。而图则针对遍历数据点之间的连接进行了优化。当你的业务问题需要理解“是什么导致了这个问题”或“什么与这个问题相关”时，你就是在要求图遍历关系——这在 SQL 中代价高昂且笨拙（想想多个 JOIN 语句，它们的复杂度会呈指数级增长），但在图查询中却很自然。

简而言之：如果您需要计数、分类和聚合，请使用关系数据。如果您需要发现影响链、隐藏的联系和多步骤推理路径，请考虑使用图谱。

这种在数据中寻找联系和模式的能力提供了一定程度的数据推理能力，可以帮助大语言模型填补其知识上的空白。

让我们看看这如何应用于两个常见的 GenAI 工作负载，GraphRAG 和 Agentic Memory

2024 年 4 月，微软研究院发布了论文《从局部到全局：基于 GraphRAG 的查询中心摘要方法》，这是第一篇广泛讨论如何利用图谱增强 RAG 架构有效性的论文。自该论文发表以来，涌现出许多遵循这一基本理念的论文、博客文章、工具包、公司等，它们认为图谱比单纯的语义搜索能够提供更好的上下文信息。

GraphRAG 通过在检索阶段利用知识图谱的固有连通性，扩展了传统的检索增强生成 (RAG)。传统 RAG 通常对单个文档或块执行语义搜索，而 GraphRAG 通常但并非总是利用语义或全文搜索来查找起始实体，然后遍历关系以提供更完整的上下文信息。

例如，GraphRAG 并非仅仅检索关于产品的单一事实，而是经常使用类似基于向量的语义搜索来查找相关的产品描述，然后顺藤摸瓜找到相关产品、客户行为和历史模式——本质上是执行“多跳”检索，以捕捉更广泛的上下文。这意味着，当 LLM 接收到检索到的信息时，它获得的不仅仅是孤立的事实，而是这些事实之间如何相互关联的更完整的图景。这种更丰富的上下文有助于 LLM 通过理解不同信息之间的关系来生成更准确、更细致的响应，类似于人类如何运用关联知识来推理复杂主题。图路径的可解释性也使得 LLM 更容易理解和验证其得出结论的过程。

当我们观察Agentic Memory时，我们会看到非常相似的模式。当思考长期代理记忆的需求，AI代理随着时间的推移维护和利用自身经验和知识的能力，知识图谱提供了一种自然的结构，可以以有意义的方式组织和连接这些记忆。与平面文档存储或简单的键值记忆不同，图结构允许代理创建丰富的、相互关联的表示，以体现其经验、决策和学习到的信息。例如，代理可以跨时间连接相关的交互，关联相似的经验，并在其学习到的概念之间建立关系。这种网络化的记忆结构支持更复杂的推理，因为代理可以遍历这些连接来查找相关的经验或知识，就像人类的联想记忆一样。

当代理需要做出决策或响应查询时，它可以沿着这些关系路径从多个相关记忆中收集上下文，不仅理解单个事实，还能理解它们如何相互关联形成更广泛的模式。这一点尤其强大，因为它允许代理随着时间的推移发展出更细致的理解，将新的经验整合到现有的知识网络中，而不是作为孤立的数据点存在。

另一个我之前没有立即意识到的价值是，为代理提供图谱表示可以降低延迟，减少令牌或成本，从而提高效率。让我们看看 Zep 的论文（ZEP：用于代理记忆的时态知识图谱架构）中的下图，他们比较了为代理提供记忆的完整上下文和相同记忆的图谱表示的效果。

全上下文与基于图的内存表示的比较。这里的得分显示，不同方法的准确率大致相当（55-71%），这似乎有些不相上下。但这才是关键所在——基于图的方法在保持同等质量的同时，效率得到了显著提升。延迟降低了 10 倍，令牌使用量降低了 70 倍。对于每天处理数千次查询的生产系统来说，这并非微不足道的优化，而是经济可扩展系统与经济可扩展系统之间的区别。

入门：你应该从哪里开始

快速验证测试：

在构建任何内容之前，请手动追踪 10-20 个最常见的用户查询。你能通过单个文档查找来回答这些问题吗？还是你会在脑海中将多个来源的信息串联起来？

这 15 分钟的练习比任何架构辩论都更有价值。如果你经常在文档之间跳转来回答问题，图谱可能会有所帮助。如果大多数答案都存在于单个文档中，那就坚持使用向量搜索。

如果你确实需要图谱：从小处着手

如果你确定图谱能够提升价值，那就不要急于在第一天就对整个领域进行建模。我见过的最成功的实施都遵循以下模式：

• 从一个高价值用例开始（通常是当前系统失败的多跳问题）
• 最低限度建模（核心实体和 2-3 种关键关系类型）
• 衡量你的基线（向量 RAG 或更简单的方法）
• 仅当看到清晰的投资回报率 (ROI) 时才进行扩展

我见过一些团队为了处理一个查询，花了几个月的时间完善他们的本体。一开始很混乱，但很快学会了，然后根据实际使用模式进行改进。

图的真正作用：结构化知识解决结构化问题

在审视了炒作和现实之后，我们得出的结论是：知识图谱并非万能的解决方案，也不是灵丹妙药——它只是一种在特定情况下才有效的专用工具。GenAI领域正在日趋成熟，超越“一刀切”的思维模式。正如我们不会使用图数据库进行简单的键值查找，也不会使用关系数据库进行网络分析一样，我们不应该将知识图谱默认用于所有 GenAI 应用。问题不在于“我应该使用知识图谱吗？”，而在于“我的问题是否需要理解概念如何跨多个跳转连接？”

当图谱真正增加价值时：

• 您的用户提出涉及多个相关概念的问题
• 数据点之间的关系与数据本身同样重要
• 你需要可解释的推理路径（谁影响了谁，为什么提出这个建议）
• 您正在构建持久的代理记忆，必须将一段时间内的经历联系起来

当它们增加复杂性而没有带来好处时：

• 您的整个知识库适合上下文窗口（<200k 个标记）
• 问题主要是单跳查找
• 您的数据自然适合表格格式，并且查询是聚合
• 你需要快速交付并首先迭代快速工程

我见过的最成功的 GenAI 实现并不是那些跳上知识图谱潮流的实现，它们都是从简单开始，衡量用户真正关心的内容，并且只有当简单的方法遇到明显的限制时才增加结构复杂性。

或许最重要的洞见是：大语言模型 (LLM) 让我们重新思考如何构建和检索信息，但它们并没有改变数据架构应该与查询模式匹配的基本原则。图擅长解答“为什么”和“它们之间如何关联”的问题。如果这些问题并非用户真正关心的问题，那么无论图多么复杂，都无法创造价值。

真正的机会并不在于在任何地方应用知识图谱，而在于足够深入地理解何时值得付出复杂性成本。

您的看法是什么？

我特别好奇：

• 您是否构建了真正影响 LLM 绩效的知识图谱？
• 或者您是否见过团队针对不需要的问题过度设计图形解决方案？
• 您使用什么决策标准来确定何时添加这种复杂性？

文章来自：51CTO