LLM Agent 的图内存：扁平向量搜索遗漏的关系盲点

一个客户服务智能体知道用户偏好在早晨送货。它还知道用户的主要地址在西雅图。但它无法理解的是，西雅图的地址是一个仅在工作日使用的办公地址，而且由于用户三个月前提到的一项大楼限制，早晨送货窗口期在周一并不适用。每个事实都可以被单独检索，但它们之间的关系却不能。

这就是在基于扁平向量库（flat vector stores）运行的生产级智能体中常见的故障模式。每一条信息都像是一个漂浮在高维空间中的嵌入（embedding）。相似性搜索检索与查询匹配的事实，但它无法恢复事实之间的结构化连接——即在组合中赋予它们意义的“边”（edges）。

大多数智能体记忆架构是围绕向量数据库构建的，因为它们速度快、设置简单，且适用于大多数检索任务。这些失败案例非常微妙，以至于在有人注意到这种模式之前，它们往往已经出现在生产环境中了。

向量搜索究竟在做什么

向量记忆将信息转换为编码语义相似性的数值表示。当智能体需要检索内容时，它会对查询进行嵌入，并在高维空间中找到与其最接近的存储嵌入。在该空间中的近距离理论上应与相关性正相关。

根本问题在于，近距离编码的是主题相似性，而不是结构化关系。“西雅图的地址是一个办公地点”和“Pine Street 的大楼周一上午 10 点前不送货”可能都与有关西雅图送货调度的查询在距离上相当接近。但关键事实——即 Pine Street 的办公地址和周一的限制指向的是同一个地点——需要一种扁平存储无法表示的连接。智能体检索到了两个语义相似的事实，只能依靠你推断它们之间的关系。

当关系简单到足以让模型从近距离中重新构建时，这种方法是有效的。但在以下三种模式中，它会稳定地失效。

图记忆修复的三种检索失败

多跳缺口（Multi-hop gaps）。 许多有用的查询需要遍历中间节点，而这些节点本身在相似性搜索中的得分可能并不高。“该用户做出了哪些影响其当前订阅的承诺？”这一查询需要将过去关于价格预期的对话连接到当前的账单记录，再连接到最近的支持互动。这些中间节点都不匹配查询表面，因此都不会被检索到。模型给出的答案上下文不完整，而且这种不完整性是不可见的——它只是使用了它所拥有的信息。

一份 2025 年关于基于图的智能体记忆的调查直接描述了这种失败：“复杂查询的答案往往取决于原始查询中未出现的实体。纯粹的相似性匹配无法弥补这一差距。”需要检索的实体并不是那些看起来像查询的实体，而是那些与看起来像查询的实体相连的实体。

时序错位（Temporal displacement）。 向量库记录事实时没有固有的时间感知。六个月前真实的事实和上周变为真实的事实占据同样的扁平命名空间。如果没有显式的时序索引，查询返回的事实会按语义亲近度排序，而这与新近度或时序有效性没有相关性。

对于处理状态变化（用户偏好、项目状态、配置值、关系动态）的智能体来说，这会产生基于过时事实的自信回答。智能体告诉你支付方式已存档，因为它曾经被存档过。向量库没有机制知道卡片已过期，且你在三次对话前已经更新了它。

规模退化（Scale degradation）。 随着记忆的增长，语义相似的分段数量也会增加。一个拥有数十万条记忆的向量库返回的 top-k 结果集中，许多条目在主题上相关，但在事实上与特定查询的实际需求无关。模型接收到一个充满噪声的上下文窗口，并且必须在推理时辨别信号与噪声——这是一个不可靠的过程，它往往是静默地退化，而不是报错。

时序知识图谱如何解决这一问题

知识图谱将信息表示为通过有类型边（typed edges）连接的节点。与其将“用户偏好早晨送货”编码为一个漂浮的嵌入，图将其存储为：用户 → PREFERS → 早晨送货，并带有一个关联的时间范围。西雅图的办公地址变成了一个通过 HAS_ADDRESS 边连接的节点，并带有 LOCATION_TYPE: work 属性。周一的限制则变成该地址节点发出的一个边。

当智能体查询送货调度的上下文时，图遍历会遵循从用户到地址再到限制的边，从而恢复扁平检索无法重建的完整链条。

这种架构在生产环境中最相关的实现是双时态建模（bitemporal modeling），由 Zep 的 Graphiti 框架在这一领域率先提出。双时态跟踪为每个节点和边维护两个独立的时间线：事件时间（事情在现实世界中真实发生的时间）和摄取时间（智能体了解该事实的时间）。当事实被追溯修正、用户更新信息，或者智能体需要推理其在过去某个特定时刻所知的信息与现在所知的信息时，这种区分就显得至关重要。

Zep 在 LongMemEval（一个专门为跨多会话对话的复杂时态推理设计的基准测试）上发布的评估结果显示，与使用全上下文或向量检索的方法相比，准确率提高了多达 18.5%。延迟改进也非常显著：平均上下文 token 从 115,000 个下降到 1,600 个，响应延迟从 29–31 秒下降到 2.5–3.2 秒。图遍历的 P95 检索延迟为 300 毫秒。

微软的 GraphRAG 项目在知识密集型文档任务中展示了同样的优势。在年度报告分析（一个具有密集实体关系和多跳依赖的领域）中，从纯向量检索切换到图结构检索使“正确”答案的比例从 50% 提升到了 80%。在需要跨多个文档章节进行综合的查询中，综合性得分比传统 RAG 高出 72–83%。

这种模式在各个领域都成立。在以下任务中，图记忆的一致表现优于向量记忆：

• 答案取决于事实之间的关联，而不仅仅是存在哪些事实
• 状态随时间变化，且必须区分当前状态与历史状态
• 相关的上下文与查询并不直接相似，但与相似的内容相连

生产环境中图内存的实际成本

性能方面的理由很充分。但在运营层面，你需要诚实面对所承担的工作量。

实体提取的准确性是一个硬性依赖。 知识图谱的质量取决于填充它的实体和关系。使用 LLM 从非结构化文本中提取实体会引入噪声——现实世界中同一个实体，如“西雅图办公室”、“Pine 街上的大楼”和“Pine 街办公点”，可能会被存储为三个独立的节点而不是一个。实体解析（Entity resolution）——即合并指向同一个现实世界对象的引用——在生产系统中仍然是一个未解决的问题。Graphiti 使用基于 LLM 的提取和名称匹配，但解析质量取决于底层模型，并且随着实体词汇表的模糊度增加而下降。

模式演进（Schema evolution）并非易事。 向量存储在设计上是无模式的：你嵌入任何拥有的内容，并通过相似性进行检索。知识图谱则需要决定存在哪些节点类型、边类型以及它们携带哪些属性。这些决策需要容纳不符合初始模式的信息，因为智能体（agent）会遇到设计者未预料到的信息。僵化的模式会导致有效信息在摄入时被丢弃。过于松散的模式则会产生万物互联的图，导致遍历返回过多内容。

在生产环境中行之有效的模式是：从少量与你实际领域匹配的定义良好的节点类型开始，使用动态边类型来表示不完全符合模式的关系，并运行自动化验证以捕获结构漂移。

写入延迟高于向量更新（upsert）。 在向量存储中追加新的嵌入（embedding）速度快且可并行化。向知识图谱添加节点涉及实体解析、关系推理、模式验证，并可能需要修改现有节点以反映更新后的事实。对于高频交互模式——每分钟处理数十条消息的智能体——写入路径可能成为瓶颈。生产系统通过将事件日志作为主要写入路径并异步更新图来处理这一问题，在内存层接受最终一致性。

决策框架

三个问题决定了你的智能体内存架构是否需要图结构。

第一：你的智能体是否需要回答那些正确答案取决于多个事实之间如何关联，而不仅仅取决于事实本身的问题？如果用户问题的答案需要遍历超过一步的关系——用户拥有账户，账户拥有订阅，订阅拥有支付方式——而智能体经常在这方面出错，那么你面临的是图结构可以解决的多跳检索问题。

第二：你的智能体是否在长的时间跨度内运行，其中状态会发生变化，且需要区分当前状态与历史状态？面向客户的智能体、项目管理智能体，以及任何管理演进配置的智能体都会面临这个问题。如果你的智能体自信地使用过时的事实，那么你面临的是双时态图建模（bitemporal graph modeling）可以解决的时间推理问题。

第三：你的内存是否正在增长到语义相似性搜索开始返回嘈杂、低精度结果的规模？这通常在 top-k 检索集针对本应有精确答案的查询包含明显无关项时变得显而易见。

如果以上都不适用，一个配置良好的、具有新近度加权的向量存储会更简单、更快，图基础设施的运营成本也就不再合理。

如果其中一个或多个适用，混合方法是实际的答案：向量搜索处理广泛的语义匹配，知识图谱处理关系遍历和时间推理，而检索查询则将两者结合。向量检索找到锚点节点；图遍历从那里扩展以恢复连接的上下文。这就是 Zep 的生产实现结构，也是在纯向量内存无法处理的极端情况下能够存续的模式。

开启这一模式的关键

让构建智能体的工程师理解图内存的心智模型是：知识图谱不是更好的搜索索引。它是一种回答不同类型问题的不同数据结构。

向量存储回答的是：“哪些存储的信息与此查询相似？”当你需要主题相关的信息时，这是一个有用的问题。

知识图谱回答的是：“这个实体如何通过何种关系与这些其他实体相连，以及在何时相连？”当你的智能体运行在一个事物相互关联、随时间变化且需要组合推理的世界中时，这是一个必要的问题。

团队描述的大多数“模型丢失了上下文”或“智能体忘记了我们谈话的内容”等智能体故障，并不是模型的失败。它们是检索架构的失败：正确的信息存在于内存存储中，但检索机制无法以正确的形式恢复它。图内存是架构层，它填补了扁平相似性搜索在结构上无法处理的那类查询的空白。