传统 RAG 的根本缺陷：GraphRAG 与上下文记忆才是正解

你的 AI 聊天机器人在关闭标签页的瞬间就会忘记一切。以下是目前还没人讨论的解决方案。

向一个典型的 RAG 驱动的 AI 助手提出一个依赖三分钟前提到的内容的追问，观察它如何悄无声息地丢失线索。标准的检索增强生成在基于相似性拉取相关文本块方面表现出色，但在理解信息片段之间如何真正关联、或在会话中保持对用户的认知方面却非常糟糕。这个缺口正是推动严肃 AI 应用开发走向 GraphRAG 和上下文记忆的原因——这是目前 AI 架构中发展最快的两个概念。

以下是标准 RAG 真正存在的问题、GraphRAG 和上下文记忆有何不同，以及如何思考基于它们进行构建。

标准 RAG 为何碰壁

传统 RAG 的工作原理是将文档分块、嵌入，然后检索与用户查询语义最相似的块。它简单、对直接的查询问题有效，已成为将 AI 响应扎根于真实数据的默认模式。

它也有真实的、众所周知的局限性，在生产环境中很快就会显现。

这些并不意味着标准 RAG 毫无用处。它是一个真正好的起点，但一旦应用需要跨关系进行推理或在多轮对话中记住有意义的内容，就会迅速失去用武之地。

一个具体的失败案例

想象一个面向中型公司运营团队的内部 AI 助手，它基于多年的供应商合同、合规文档和内部政策备忘录进行训练。有人问："如果新的数据驻留政策适用于我们的欧盟合同，哪些供应商会受到影响？"

标准 RAG 设置会分别检索提到"供应商"的块、提到"数据驻留政策"的块、以及提到"欧盟合同"的块。检索步骤中没有任何内容实际确认哪些供应商与哪些合同相关联，或者哪些合同属于欧盟管辖范围。模型只能从松散相关的文本中猜测这些联系，而在合规场景下，一个听起来自信但实际上是猜测的答案是非常危险的。

正是这类失败推动图方法从研究好奇心变成了今年真正的生产模式——在任何错误但听起来自信的答案成本高昂的场景中。

GraphRAG 实际上改变了什么

GraphRAG 将底层知识重构为图结构，实体作为节点，关系作为边，而不是扁平的嵌入文本块集合。系统不再仅基于相似性检索孤立的文本片段，而是可以遍历关系来回答需要连接多个事实的问题。

实体-关系结构。事实不仅被存储，还被连接：产品链接到供应商，供应商链接到地区，地区链接到法规

多跳查询支持。需要三个关联事实的问题可以通过遍历图来回答，而不是寄希望于三个事实恰好落在同一个检索到的块中

社区级摘要。基于图的方法可以汇总整个相关实体集群，使系统获得真正的概览，而不是一堆互不关联的片段

更好地处理稀疏或专业领域。在文档语料库规模小或高度专业化的场景下，关系结构通常能发现纯相似性搜索完全忽略的相关上下文

知识图谱实际上是如何构建的

值得对此进行一些解魅，因为"构建知识图谱"听起来比实际过程更 exotic。

实体提取。对源文档的初始遍历识别关键实体、人、产品、组织、法规、日期

关系提取。第二次遍历识别这些实体如何连接，哪个供应商供应哪个产品，哪个合同属于哪个管辖范围

图构建。实体成为节点，关系成为边，形成底层数据的结构化映射，而不是扁平的文本块堆

社区检测。相关的节点集群被分组，这使得扁平检索根本无法产生的社区级摘要成为可能

持续维护。随着源文档更新，图需要重新处理以反映新的实体和关系，这是大多数团队在规划构建时低估的步骤

上下文记忆：问题的另一半

GraphRAG 解决了关系问题。上下文记忆解决了持久性问题，即系统如何在对话中或跨会话记住相关信息，而不是每次都从零开始。

短期工作记忆跟踪当前会话中讨论过的内容，因此追问不需要重复用户已经给出的上下文

长期记忆跨会话持久化关于用户或任务的有意义的事实——回头客户的偏好、项目的持续状态、不需要重复的先前决定

选择性记忆——不是完全记忆——和记忆一样重要。一个设计良好的系统会决定什么真正值得保留，而不是逐字存储每条消息，这保持检索的快速和相关性，而不是膨胀

实现记忆的不同方法

并非所有上下文记忆系统都以相同方式工作，选择正确的方法很重要。

大多数严肃的生产系统最终使用某种混合方法，因为仅滑动窗口无法跨会话持久化，而仅靠摘要往往会丢失事实提取保留的有用的具体细节。

这两个部分如何配合

GraphRAG 和上下文记忆解决不同的问题，目前最强大的 AI 应用正在将两者结合，而不是选择其一。

GraphRAG 处理跨知识库的推理，连接存在于不同文档或记录中的事实

上下文记忆处理跨对话本身的推理，记住用户已经告诉系统的内容

两者结合，使 AI 应用能够回答这样的问题："考虑到我们上周讨论的更新，这是否适用于我之前提到的客户"——通过从知识图谱中提取关系结构，并从记忆中召回上下文

差异的简化说明

多跳问题上的标准 RAG：

"哪些供应商受到新进口法规的影响？"分别检索提到"供应商"的块和提到"进口法规"的块，无法保证系统连接哪个供应商实际受到哪个法规的影响。

同一问题的 GraphRAG：

遍历连接到地区节点再连接到法规节点的供应商节点，返回与受影响地区实际链接的特定供应商，因为这种关系是明确建模的，而不是从文本相似性推断的。

加上上下文记忆：

如果用户之前说过"本季度我们专注于欧洲供应商"，系统会召回该上下文并相应地缩小答案范围，用户无需重复。

团队常犯的错误

对每个用例都跳到 GraphRAG，而简单、分块良好的标准 RAG 设置对于直接的查询任务确实足够，添加不必要的复杂性而没有真正收益

构建无差别存储所有内容的记忆，这会使检索膨胀，实际上使响应更慢、更嘈杂，而不是更智能

将图构建视为一次性任务，而知识图谱需要随着实体和关系的变化进行持续维护

完全忽略评估，在没有系统方法测试它是否真正比它取代的更简单的基线改善了答案质量的情况下就上线 GraphRAG 或记忆系统

将记忆与日志混为一谈，存储原始对话历史并称之为记忆，而没有真正决定什么值得长期保留的处理流程

快速决策框架

你的用例是否真正需要跨多个文档或记录连接事实，还是大多数查询是简单的单事实查找？

你的应用是否需要跨轮次或跨会话记住信息，还是每次交互自然地自包含？

你有持续的资源来维护随底层数据演变的知识图谱吗？

在你的特定用例中，一个错误但听起来自信的答案成本有多高？成本越高，为 GraphRAG 添加的结构提供的理由就越充分

评估时团队常见的 问题

GraphRAG 是否完全取代标准 RAG？不会，大多数生产系统同时使用两者。简单的查找仍然可以通过标准检索，而多跳推理问题通过图路由。

这会增加多少延迟？与单次相似性搜索相比，图遍历增加了一些开销，尽管具有高效遍历模式的良好索引图在大多数交互式用例中保持可控。在实际数据上进行基准测试至关重要，而不是假设。

这只对大型企业值得吗？不。更小、更专业化的领域往往收益更大，因为稀疏的文档语料库正是关系结构往往比纯相似性搜索增加最多价值的场景。

为什么值得正确构建

将图构建、检索遍历和记忆持久化正确地结合在一起，确实比启动一个基本 RAG 管道更复杂，而且很容易低估知识图谱随数据变化所需的持续维护。这正是那种将真正更智能的 AI 应用与在演示中看起来更智能的应用区分开来的 RAG 开发和 AI 应用架构工作，在承诺全面构建之前获得第二意见通常是值得的。

标准 RAG 让很多 AI 应用起步，对于很多用例仍然是正确的选择。但一旦应用需要跨关系推理或在对话中记住有意义的内容，扁平的、孤立的检索模型很快就会走到尽头。GraphRAG 和上下文记忆正是今年弥补这一差距的理念组合，理解你何时真正需要它们，而不仅仅是如构建它们，正在迅速成为构建严肃 AI 产品的任何人的核心技能。

你的团队已经开始尝试 GraphRAG 或持久记忆了吗，还是标准 RAG 仍在处理你抛给它的所有问题？很好奇大家实际进展到什么程度。