---

前言

昨天阅读了 Mem0。Mem0 已经不只是一个停留在论文中的研究方案，而是一套面向实际 Agent 应用的长期记忆系统。

今天阅读的 Zep 同样具有明显的工程化和生产化导向。

在传统 RAG 系统中，外部知识通常来自相对静态的文档库。系统预先把文档切分、向量化并存入数据库，等用户提问时再检索相关片段。

这套方式很适合下面这类知识：

产品说明书
企业规章制度
论文和技术文档
长期变化较少的知识库

但 Agent 的长期记忆和普通文档检索存在明显区别。

Agent 需要处理的是一个持续变化的世界。例如：

用户以前住在北京，后来搬到了上海；
用户原本打算八月旅行，后来将计划推迟到十月；
客户最初对某个产品感兴趣，之后已经完成购买；
员工之前属于 A 部门，现在转入 B 部门。

这些信息并不是静态文档，而是会随着对话和业务数据不断更新的动态事实。

如果系统只保存当前状态，就可能丢失历史变化；如果简单地把所有历史事实都保留下来，又可能在召回时混淆哪些信息当前仍然有效。

因此，企业级 Agent 记忆系统需要解决的不只是：

如何从大量历史数据中找到相关信息？

还要解决：

一条事实什么时候成立？什么时候失效？新事实如何改变旧关系？如何同时保留当前状态和历史轨迹？

这篇论文提出了 Zep，一种面向 AI Agent 的记忆层服务。

Zep 的核心组件是 Graphiti。Graphiti 是一个具有时间感知能力的动态知识图引擎，能够持续接收：

• 正在发生的对话；
• 结构化业务数据；
• 文本和 JSON 数据；
• 用户、企业和外部世界中的动态信息。

随后，Graphiti 会将这些信息组织成动态知识图，并记录事实和关系的有效时间。

与静态 RAG 不同，Zep 不只是从固定文档中召回文本，而是尝试建立一个能够持续演化的 Agent 记忆世界模型。

简单来说：

普通 RAG 更像是在文档库中查资料，而 Zep 更像是在维护一个会随着时间不断变化的事实与关系网络。

---

零、论文基本信息

• 论文名称：Zep: A Temporal Knowledge Graph Architecture for Agent Memory
• 发表平台：arXiv preprint
• Graphiti 代码仓库：getzep/graphiti
• 实验代码仓库：getzep/zep-papers
• 作者信息：
  • Preston Rasmussen，Zep AI
  • Pavlo Paliychuk，Zep AI
  • Travis Beauvais，Zep AI
  • Jack Ryan，Zep AI
  • Daniel Chalef，Zep AI

---

一、静态 RAG 为什么不适合长期 Agent 记忆？

RAG 的核心流程通常是：

文档
→ 切分
→ 向量化
→ 存入检索库
→ 根据问题召回相关文本
→ 拼接到 Prompt 中回答

这套流程隐含了一个重要假设：

文档库中的信息总体上是相对稳定的。

例如，一篇产品手册加入知识库之后，通常不会每隔几分钟改变一次。

但是，Agent 长期交互中的记忆恰恰是动态的。

1. 对话信息会持续变化

用户可能在不同时间表达不同状态：

一月：
我正在考虑换工作。

三月：
我已经接受了一家新公司的 offer。

五月：
我现在在新公司负责数据平台项目。

如果系统把这三句话当作三个彼此独立的文本块，后续就很难判断：

• 用户现在是否还在找工作；
• “考虑换工作”是否已经失效；
• 新工作从什么时候开始；
• 当前负责什么项目。

2. 企业数据来自多个来源

真实企业 Agent 需要整合的不只是聊天记录，还包括：

• CRM 中的客户信息；
• 工单系统中的服务记录；
• 商品和订单数据；
• 项目管理系统中的任务状态；
• 人员和组织关系；
• 持续更新的业务事件。

这些数据既包含非结构化文本，也包含结构化字段。

普通 RAG 往往把所有内容都转成文本块，再进行向量检索。这会弱化数据中原本明确的结构和关系。

3. 事实存在有效期

在动态世界中，一条事实通常不是永远成立的。

例如：

Alice 在 Acme 公司工作。

这条事实可能只在 2022 年到 2024 年之间成立。

如果 Alice 后来去了另一家公司，系统需要同时知道：

当前状态：
Alice 在 Beta 公司工作。

历史状态：
Alice 曾经在 Acme 公司工作。

这正是 Zep 引入时序知识图的核心原因。

---

二、Zep、Graphiti 和知识图谱之间是什么关系？

这几个概念容易混淆，可以先简单区分。

1. Zep

Zep 是面向 AI Agent 的记忆层服务。

Agent 可以把对话和业务数据写入 Zep，也可以通过 Zep 的搜索接口召回相关记忆。

2. Graphiti

Graphiti 是 Zep 背后的核心知识图引擎。

它负责：

• 接收消息、文本和 JSON；
• 提取实体和事实；
• 进行实体消歧和事实去重；
• 提取时间信息；
• 维护关系的有效时间；
• 构建实体社区；
• 支持图搜索和混合检索。

因此，可以理解为：

Zep：
对外提供 Agent 记忆服务。

Graphiti：
负责构建、维护和检索动态时序知识图。

3. 和普通知识图谱的区别

普通知识图谱通常强调：

实体—关系—实体

例如：

Alice --WORKS_FOR--> Acme

Graphiti 在此基础上进一步记录：

• 这条关系什么时候被系统写入；
• 这条关系什么时候失效；
• 它在现实世界中什么时候成立；
• 它来自哪一条原始消息；
• 新信息是否推翻旧关系。

所以它不仅是一张实体关系图，还带有动态更新、来源追踪和时间建模能力。

---

三、Zep 方法总览

Zep 中的记忆由一张具有时间感知能力的动态知识图驱动。

论文将图表示为：

$$G=(N,E,\varphi )$$

其中：

• $N$ 表示节点集合；
• $E$ 表示边集合；
• $\varphi$ 表示边与两端节点之间的关联关系。

这张图并不是只有一种节点，而是由三个层级的子图组成：

1. 情景子图 Episode Subgraph
2. 语义实体子图 Semantic Entity Subgraph
3. 社区子图 Community Subgraph

可以把它们理解为三个不同抽象层次：

社区层：
高层主题和整体领域结构

语义实体层：
人物、地点、组织以及实体之间的事实关系

情景层：
原始消息、文本和 JSON 数据

三层结构的作用分别是：

子图	保存内容	主要作用
情景子图	原始消息、文本或 JSON	保留完整原始证据
语义实体子图	实体及其关系事实	组织可检索的结构化知识
社区子图	强连接实体簇及其摘要	提供高层主题和全局理解

这种分层结构同时保留了：

• 原始数据；
• 可组合的事实；
• 高层主题摘要。

---

四、情景子图：保存非损失的原始记忆

Zep 的图构建从 Episode 开始。

Episode 可以翻译为“情景”“事件片段”或“情节单元”。在这篇论文中，它指系统接收到的一条原始数据。

Episode 支持三种核心类型：

message
text
JSON

论文实验主要关注 message，也就是对话消息。

一条消息通常包含：

• 消息文本；
• 说话人；
• 消息发送时间；
• 与会话相关的元数据。

1. 为什么要保留 Episode？

很多知识图系统只保存从文本中抽取出来的实体和关系。

例如，原始对话是：

Alice：
我两周前从伦敦搬到了巴黎，因为我开始了一份新工作。

系统可能抽取出：

Alice --LIVES_IN--> Paris
Alice --STARTED--> New Job

但是，实体和关系抽取不可避免地可能遗漏细节。

因此，Zep 不会在抽取图结构后删除原始消息，而是把 Episode 作为非损失数据层保存下来。

这样做有两个好处：

• 如果抽取结果不足，可以回到原文重新分析；
• 检索出的事实可以追溯到原始消息，用于引用和解释。

2. Episode 和实体之间的双向索引

情景节点会通过边连接到从中提取出的实体和事实。

可以理解为：

原始消息
    ↓ 提取
实体与事实

实体或事实
    ↓ 追溯
原始消息

这种双向关系使系统既能从原始交互构建知识，也能从结构化知识回溯证据。

---

五、双时间模型：事件时间与系统时间

Zep 一个非常重要的设计是 Bi-temporal Model，即双时间模型。

系统同时维护两条时间线：

• $T$：现实世界中的事件时间；
• $T^{\prime }$：数据被写入 Zep 的事务时间。

1. 事件时间

事件时间表示：

这件事在现实世界中什么时候发生或成立？

例如，用户今天说：

我两周前开始了新工作。

虽然消息是今天发送的，但“开始新工作”发生在两周前。

2. 事务时间

事务时间表示：

Zep 在什么时候收到并记录了这条信息？

在上面的例子中，事务时间是今天。

因此，同一条事实可能有两类不同时间：

现实发生时间：
两周前

系统写入时间：
今天

3. 为什么需要两条时间线？

如果只记录消息进入系统的时间，就会错误地认为用户今天才开始新工作。

如果只记录现实事件时间，又无法回答：

• 系统什么时候得知这件事；
• 哪次写入改变了旧事实；
• 数据库中某条记录何时被创建或失效。

双时间模型既支持现实世界中的时间推理，也支持数据库审计和版本追踪。

---

六、语义实体子图：从原始消息到实体和事实

语义实体子图建立在情景子图之上。

它包含两类核心内容：

1. 实体节点；
2. 表示事实的语义边。

例如：

Alice --WORKS_FOR--> Acme
Alice --LIVES_IN--> Paris
Acme --LOCATED_IN--> London

其中：

• Alice、Acme 和 Paris 是实体；
• WORKS_FOR、LIVES_IN 和 LOCATED_IN 是关系事实。

---

七、实体提取与实体消歧

1. 实体提取

在处理当前消息时，系统不仅使用当前消息，还会加入最近 $n$ 条消息作为上下文。

论文中设置：

n = 4

也就是提供最近两个完整对话轮次。

这样做是为了处理：

• 代词指代；
• 省略表达；
• 同名实体；
• 依赖前文的实体描述。

例如：

用户：
我昨天见到了 Alice。

助手：
你们聊了什么？

用户：
她说自己已经搬到巴黎了。

如果只看最后一句，“她”指的是谁并不明确。

加入前文之后，系统才能把“她”解析为 Alice。

2. 自动提取说话人

在对话消息中，说话人会被自动提取为实体。

这是合理的，因为大量用户记忆都围绕说话人展开：

用户喜欢什么
用户在哪里工作
用户认识谁
用户过去经历了什么

3. 反思式补充

首次提取实体后，系统还会使用一种受 Reflexion 启发的反思步骤，检查是否遗漏重要实体。

这一过程的目标是：

• 提高实体覆盖率；
• 减少漏提取；
• 降低一次生成带来的随机错误。

4. 实体向量化和候选召回

每个实体名称会被编码为一个 1024 维向量。

随后，系统从已有图中同时使用：

• 余弦相似度搜索；
• 全文搜索。

这样可以找到可能指向同一对象的候选实体。

例如：

IBM
International Business Machines
这家公司

它们可能都指向同一个实体。

5. 使用 LLM 完成实体消歧

候选实体、当前消息和历史上下文会一起交给 LLM。

LLM 需要判断：

• 新实体是否已经存在；
• 如果存在，对应哪个节点；
• 是否需要更新实体名称和摘要。

论文中特别提到，完成实体解析之后，系统通过预先定义好的 Cypher 查询更新图，而不是让 LLM 自由生成数据库语句。

这样可以：

• 保证数据库模式一致；
• 减少语法错误；
• 降低 LLM 幻觉影响；
• 提高生产系统稳定性。

---

八、语义事实与关系去重

实体提取完成后，系统会从当前 Episode 中抽取实体之间的事实。

例如：

Alice 在 Acme 工作。

可以抽取为：

(Alice, WORKS_FOR, Acme)

但 Graphiti 的边不只是一个简单关系标签，还会保存更详细的事实描述。

例如：

关系类型：
WORKS_FOR

详细事实：
Alice started working for Acme in March 2024.

1. 多实体事实

同一个复杂事实可以在不同实体之间生成多条关系边。

这相当于通过多条边近似表示超边，从而支持包含多个实体的复杂事实。

2. 事实向量化

事实同样会生成 embedding，用于：

• 查找语义相似事实；
• 事实去重；
• 后续语义搜索。

3. 限定实体对进行去重

Zep 不会在整个知识图中搜索所有相似边，而是将候选范围限制在相同实体对之间。

例如，新事实是：

Alice --WORKS_FOR--> Acme

系统只会重点检查 Alice 和 Acme 之间已有的边，而不会因为关系文本相似，就错误地和 Bob、Beta 公司之间的关系合并。

这有两个好处：

• 减少错误去重；
• 缩小检索范围，降低计算成本。

---

九、时间提取与旧关系失效

时间建模是 Graphiti 和普通知识图引擎的重要区别之一。

每条事实边会保存四个时间字段：

• $t_{created}^{\prime }$：这条边何时被写入系统；
• $t_{expired}^{\prime }$：这条边何时在系统中被标记为失效；
• $t_{valid}$：事实从什么时候开始成立；
• $t_{invalid}$：事实从什么时候开始不再成立。

其中：

带撇号的时间：
事务时间 T'

不带撇号的时间：
现实事件时间 T

1. 绝对时间

例如：

Alan Turing was born on June 23, 1912.

系统可以直接提取：

t_valid = 1912-06-23

2. 相对时间

例如用户在 5 月 20 日说：

我两周前开始了新工作。

系统会结合消息的参考时间，计算：

t_valid ≈ 5 月 6 日

3. 新事实如何使旧事实失效？

假设图中已有：

Alice --LIVES_IN--> London
t_valid = 2022-01
t_invalid = null

后来系统收到：

Alice moved to Paris in March 2024.

新边为：

Alice --LIVES_IN--> Paris
t_valid = 2024-03

如果 LLM 判断两条关系在时间上构成冲突，系统会将旧边的失效时间设为新边的生效时间：

Alice --LIVES_IN--> London
t_valid = 2022-01
t_invalid = 2024-03

Alice --LIVES_IN--> Paris
t_valid = 2024-03
t_invalid = null

这样系统既保留了历史信息，也能判断当前有效状态。

4. 为什么不直接删除旧事实？

如果直接删除旧关系，系统将无法回答：

Alice 在搬到巴黎之前住在哪里？

通过标记关系有效区间，Zep 可以同时回答：

Alice 现在住在哪里？
Alice 2023 年住在哪里？
Alice 什么时候从伦敦搬到了巴黎？

这也是 Zep 在时间推理任务中表现较好的关键原因之一。

---

十、社区子图：从局部实体到高层主题

社区子图是 Zep 知识图的最高层。

它由语义实体子图中的强连接实体簇组成。

例如，大量实体和关系可能自然形成下面这些社区：

用户的工作经历
用户的家庭关系
某个企业客户及其项目
某项产品和相关订单
论文研究与实验安排

1. 社区节点保存什么？

每个社区节点包含：

• 社区摘要；
• 社区名称；
• 相关主题和关键词；
• 与成员实体之间的连接。

它提供的不是某一条具体事实，而是对一组相关实体的高层概括。

2. 标签传播算法

GraphRAG 使用 Leiden 算法进行社区检测。

Zep 则采用 Label Propagation，标签传播算法。

主要原因是标签传播更容易进行动态扩展。

当新实体加入图中时，系统可以查看邻居节点所属的社区，并将新节点分配给邻居中占多数的社区。

可以简单理解为：

一个新实体的大部分邻居属于“用户工作经历”社区
→ 将该实体加入“用户工作经历”社区

3. 动态更新与定期重建

动态加入新节点虽然效率较高，但随着时间推移，增量更新得到的社区结构会逐渐偏离一次完整运行标签传播算法的结果。

因此，Zep 的策略是：

平时：
增量更新社区，降低延迟和成本。

定期：
完整刷新社区，纠正长期累积偏差。

这是一种典型的生产系统权衡。

4. 社区摘要

社区摘要通过类似 map-reduce 的方式，从成员节点信息中逐步生成。

同时，系统还会生成包含关键主题词的社区名称，并对其进行向量化，从而支持社区级搜索。

---

十一、Zep 的记忆召回流程

Zep 的图搜索接口接收一个文本查询，并返回一段可直接提供给 Agent 的文本上下文。

可以表示为：

$$f(\alpha )=\beta$$

其中：

• $\alpha$ 表示用户查询；
• $\beta$ 表示最终构造出的记忆上下文。

整个过程分为三个阶段：

1. 搜索 Search；
2. 重排 Reranker；
3. 上下文构造 Constructor。

为了避免符号过于复杂，可以将完整流程简化表示为：

$$f(\alpha )=\chi (\rho (\phi (\alpha )))$$

其中：

• $\phi$：搜索候选节点和边；
• $\rho$：对候选结果进行重排；
• $\chi$：将结果整理成文本上下文。

直观来看：

问题
→ 找到可能相关的图节点和边
→ 按相关性重新排序
→ 转换成可放入 Prompt 的文本

---

十二、搜索：语义、关键词和图结构结合

Zep 实现了三种搜索方式。

1. 余弦语义搜索

语义搜索比较查询和图中内容的 embedding。

它适合处理词面不同但语义相似的情况。

例如：

问题：
用户现在从事什么职业？

事实：
Alice started working as a data engineer.

虽然“职业”和“data engineer”没有直接词汇重合，但语义检索可以建立联系。

2. BM25 全文搜索

BM25 更关注词汇匹配。

它适合：

• 人名；
• 公司名；
• 专有术语；
• 数字和产品名称；
• 需要精确匹配的关键词。

3. 图上的广度优先搜索

BFS 会从种子节点出发，沿图中的边扩展若干跳。

例如，问题与 Alice 有关，可以从 Alice 节点继续找到：

Alice
→ 工作的公司
→ 同事
→ 所在项目
→ 项目客户

BFS 捕捉的不是文本相似性，而是图结构中的上下文相似性。

4. 三种搜索分别解决什么问题？

搜索方法	主要捕捉的信息
BM25	词汇和关键词相似
余弦检索	语义相似
BFS	图结构和关系上下文相似

将三者组合之后，系统可以获得较高的候选召回率。

5. 不同图对象使用不同字段

Zep 会针对不同对象检索不同字段：

对象	主要搜索字段
语义事实边	fact
实体节点	entity name
社区节点	community name

这种设计说明，Zep 并不是把整张图简单转成同一种文本后统一搜索，而是针对不同抽象层采用不同入口。

---

十三、重排：从高召回走向高精度

搜索阶段的目标是尽量不遗漏候选，因此可能召回不少噪声。

重排阶段负责提高精度，把真正相关的结果放到前面。

Zep 支持多种重排方法。

1. Reciprocal Rank Fusion

RRF 用于融合多路检索结果。

例如，一条事实同时在：

• BM25 中排名较高；
• 向量检索中排名较高；
• BFS 结果中出现。

那么它的综合排名通常也会更高。

2. Maximal Marginal Relevance

MMR 在相关性和多样性之间进行平衡。

如果前几个结果内容高度重复，MMR 会适当降低重复项，把信息互补的候选加入最终结果。

3. Episode Mentions Reranker

这种图重排方式会考虑某个实体或事实在对话中被提及的次数。

被频繁讨论的信息更容易进入最终上下文。

这类似于人类记忆中的重复强化：

被多次提及的信息，通常更容易被记住和召回。

不过，提及次数多并不一定代表当前问题真正相关，因此它更适合作为辅助信号，而不是唯一排序标准。

4. Node Distance Reranker

节点距离重排根据候选节点与指定中心节点之间的图距离进行排序。

如果当前问题明确围绕某个用户、企业或项目展开，可以将其设为中心节点，优先返回附近的局部上下文。

5. Cross-Encoder 重排

Zep 还支持使用 cross-encoder 判断查询与候选结果之间的相关性。

Cross-encoder 会将查询和候选内容一起输入模型，通过交叉注意力直接计算相关分数。

它通常比独立 embedding 相似度更加准确，但计算成本也最高。

---

十四、上下文构造

重排完成后，系统需要把图中的节点和边重新转成 Agent 能够直接理解的文本。

上下文构造器会提取：

• 事实内容；
• 事实的有效时间范围；
• 实体名称；
• 实体摘要；
• 社区摘要。

例如，最终上下文可以组织为：

FACTS

Alice moved to Paris.
有效时间：2024-03 至今

Alice previously lived in London.
有效时间：2022-01 至 2024-03

ENTITIES

Alice：
A data engineer who currently lives in Paris.

这种结构同时向模型提供：

• 当前事实；
• 历史事实；
• 时间范围；
• 实体概览。

---

十五、一个简单例子：Zep 如何处理动态用户记忆？

假设用户和 Agent 进行过以下对话。

2023 年：
我现在住在北京，在一家互联网公司做产品经理。

2024 年 3 月：
我已经离开原来的公司，准备休息一段时间。

2024 年 8 月：
我搬到了上海，开始从事 AI 产品相关工作。

1. 情景层

系统保留三条原始消息，并记录各自的参考时间。

2. 实体层

系统可能提取实体：

用户
北京
上海
互联网公司
AI 产品工作

同时生成关系：

用户 --LIVES_IN--> 北京
用户 --WORKS_AS--> 产品经理

用户 --LEFT--> 原公司

用户 --LIVES_IN--> 上海
用户 --WORKS_IN--> AI 产品领域

3. 时间处理

旧关系会被补充失效时间：

用户 --LIVES_IN--> 北京
有效期：2023 至 2024-08

用户 --LIVES_IN--> 上海
有效期：2024-08 至今

4. 后续召回

如果用户问：

我现在住在哪里？

系统应优先返回：

上海

如果用户问：

我搬到上海以前住在哪里？

系统则可以利用历史关系回答：

北京

如果用户问：

我的职业经历发生了哪些变化？

系统可以整合多个时间段的信息，生成一条演变轨迹。

这说明 Zep 的价值不只是“记住事实”，还在于：

将事实组织成一个能够随时间演变的状态网络。

---

十六、实验设置

论文使用两个长期记忆 benchmark：

1. Deep Memory Retrieval；
2. LongMemEval。

1. 图构建与召回设置

对于两个实验，论文先通过 Zep API 把对话历史写入知识图。

随后，从图中召回最相关的：

• 事实边；
• 实体节点和摘要。

在 LongMemEval 的总体实验中，系统召回 20 条最相关的事实和实体信息，并将其整理成文本上下文。

DMR 部分则使用 Top-10 节点和边。

2. 模型选择

论文使用：

• BGE-M3：embedding 和 reranking；
• GPT-4o-mini-2024-07-18：知识图构建；
• GPT-4o-mini-2024-07-18：回答生成；
• GPT-4o-2024-11-20：回答生成；
• GPT-4-turbo-2024-04-09：用于和 MemGPT 的 DMR 结果直接比较。

需要注意：

图构建模型和最终回答模型并不一定是同一个模型。

这也是生产系统中的常见做法：使用成本相对较低的模型完成结构化处理，再使用更强模型完成最终推理。

---

十七、Deep Memory Retrieval 实验

DMR 是 MemGPT 论文采用的主要记忆评测任务。

它包含：

• 500 组多会话对话；
• 每组 5 个 session；
• 每个 session 最多 12 条消息；
• 每组对话包含一个记忆问答题。

论文 Table 1 给出了实验结果。

表源：Rasmussen et al., 2025，Table 1。

记忆方法	模型	准确率
Recursive Summarization	GPT-4-turbo	35.3%
Conversation Summaries	GPT-4-turbo	78.6%
MemGPT	GPT-4-turbo	93.4%
Full-conversation	GPT-4-turbo	94.4%
Zep	GPT-4-turbo	94.8%
Conversation Summaries	GPT-4o-mini	88.0%
Full-conversation	GPT-4o-mini	98.0%
Zep	GPT-4o-mini	98.2%

1. GPT-4-turbo 下的结果

Zep 达到：

94.8%

高于：

MemGPT：93.4%
完整对话：94.4%

2. GPT-4o-mini 下的结果

Zep 达到：

98.2%

完整对话为：

98.0%

两者差距很小。

3. 如何理解 DMR 结果？

从结果看，Zep 在 DMR 上取得了最高准确率。

但论文也主动指出，这个 benchmark 存在明显局限。

每组对话最多只有约 60 条消息，完全可以被现代大模型的上下文窗口容纳。

此外，问题主要是单轮事实召回，难以评估：

• 多跳记忆推理；
• 复杂时间变化；
• 知识更新；
• 长期用户偏好；
• 企业级长程交互。

完整上下文方法已经能够达到 98.0%，说明 DMR 对现代长上下文模型的区分度已经较弱。

因此，DMR 结果更适合说明：

Zep 至少没有因为知识图压缩和检索而明显损失关键信息。

但它不足以完整证明 Zep 的长期记忆能力。

---

十八、LongMemEval 实验

LongMemEval 比 DMR 更长、更复杂，也更接近企业级长期 Agent 场景。

论文使用的是 LongMemEval-S 数据集，其中每段对话平均约为：

115000 tokens

问题分为六类：

1. single-session-user；
2. single-session-assistant；
3. single-session-preference；
4. multi-session；
5. knowledge-update；
6. temporal-reasoning。

1. 为什么 LongMemEval 更有挑战？

它不只测试能否找到一句原始事实，还会测试：

• 多个 session 之间的信息整合；
• 用户偏好的识别；
• 已更新知识的判断；
• 时间顺序和时间范围；
• 用户与助手各自说过什么；
• 很长对话中的目标信息召回。

因此，它更适合评价动态长期记忆系统。

---

十九、LongMemEval 总体结果

论文 Table 2 给出了 Zep 和完整上下文方法的比较。

表源：Rasmussen et al., 2025，Table 2。

记忆方法	模型	准确率	延迟	平均上下文
Full-context	GPT-4o-mini	55.4%	31.3 s	115k
Zep	GPT-4o-mini	63.8%	3.20 s	1.6k
Full-context	GPT-4o	60.2%	28.9 s	115k
Zep	GPT-4o	71.2%	2.58 s	1.6k

1. GPT-4o-mini

完整上下文的准确率为：

55.4%

Zep 为：

63.8%

相对提升约 15.2%。

2. GPT-4o

完整上下文为：

60.2%

Zep 为：

71.2%

相对提升约 18.5%。

3. 上下文长度

完整上下文平均使用：

115000 tokens

Zep 只使用：

1600 tokens

也就是说，Zep 返回的上下文规模约为完整历史的：

1.4%

4. 延迟

GPT-4o-mini：

完整上下文：31.3 秒
Zep：3.20 秒

GPT-4o：

完整上下文：28.9 秒
Zep：2.58 秒

响应延迟减少约 90%。

5. 为什么检索后的结果反而高于完整上下文？

完整上下文虽然包含所有信息，但也包含大量无关内容。

模型需要自己完成：

• 长文本定位；
• 事实筛选；
• 新旧状态区分；
• 时间线推理；
• 多会话信息整合。

Zep 提前完成了结构化抽取和检索，只向模型提供相关事实、实体摘要和有效时间。

因此：

更多上下文
≠
更有效的上下文

这和 Mem0 论文中的结论比较一致：生产级记忆系统的价值，不只是把历史保存下来，而是为当前任务构造更小、更相关的上下文。

---

二十、不同问题类型分析

论文 Table 3 分析了六类问题。

表源：Rasmussen et al., 2025，Table 3。

1. 用户偏好问题

GPT-4o 下：

完整上下文：20.0%
Zep：56.7%

相对提升达到：

184%

这是提升最明显的类别。

用户偏好通常分散在长期对话的不同位置中。图结构可以把用户与偏好实体、事实和相关情景连接起来，因此比在 11.5 万 token 中直接搜索更加稳定。

2. 时间推理问题

GPT-4o-mini：

36.5% → 54.1%

GPT-4o：

45.1% → 62.4%

这说明 Graphiti 的时间字段和关系失效机制确实为时间推理提供了帮助。

3. 多会话问题

GPT-4o：

44.3% → 57.9%

Zep 可以通过实体和关系，把分散在不同 session 中的事实连接起来。

4. 知识更新问题

GPT-4o：

78.2% → 83.3%

这类问题需要判断：

• 旧信息是否已经失效；
• 新信息是否覆盖旧信息；
• 当前应该使用哪个状态。

Graphiti 的边失效和双时间建模与这一任务比较匹配。

5. Single-session-user

两个模型下都从：

81.4%

提升到：

92.9%

说明即使信息位于单个 session 中，结构化检索仍可能减少无关上下文干扰。

6. Single-session-assistant 是例外

在助手信息问题上，Zep 的结果下降：

GPT-4o-mini：

81.8% → 75.0%

GPT-4o：

94.6% → 80.4%

论文没有给出确定原因，只指出这一类别还需要进一步研究。

可能的解释包括：

• 图构建更偏向用户事实和实体关系；
• 助手生成内容没有被同等充分地抽取；
• 对话中助手陈述可能更长、更复杂；
• 部分信息在结构化过程中被压缩。

这部分属于基于实验现象的推测，不能直接当作论文结论。

---

二十一、Zep 的优势

1. 同时保存原始数据和结构化知识

Zep 不会在构建知识图之后丢弃原始对话，而是保留 Episode，并把实体和事实连接回来源。

这提高了：

• 信息可追溯性；
• 事实引用能力；
• 错误修正能力；
• 后续重新抽取的可能性。

2. 显式建模时间

相比普通向量数据库，Zep 能够表示：

• 当前事实；
• 历史事实；
• 事实有效期；
• 事实写入时间；
• 新旧关系之间的替代过程。

3. 支持动态更新

Graphiti 不是一次性从静态文档构建图，而是可以随着新消息和业务数据持续更新。

4. 多层记忆结构

Zep 同时维护：

原始情景
实体和事实
高层社区摘要

这使系统可以从不同粒度召回信息。

5. 混合搜索

它同时利用：

• BM25；
• 向量检索；
• 图遍历；
• 多种重排策略。

因此，召回不完全依赖单一 embedding 相似度。

6. 注重生产指标

论文不仅报告准确率，还报告：

• 上下文 token；
• 延迟；
• 图的动态更新；
• 社区增量维护；
• 数据库查询稳定性。

---

二十二、Zep 的局限性

1. 论文主要由 Zep 团队完成

Zep 既是论文提出的方法，也是作者所在公司的产品。

因此，实验结果属于方法开发团队的自评估。

这并不意味着实验不可信，但更理想的情况是由独立团队进一步复现和对比。

2. LongMemEval 主要和完整上下文比较

论文尝试在 LongMemEval 上测试 MemGPT，但由于 MemGPT 当时不支持直接导入已有消息历史，实验未能成功完成。

因此，LongMemEval 的主要对比对象是完整上下文，而不是大量其他长期记忆系统。

这限制了我们判断 Zep 相对 Mem0、A-Mem 等方法的直接优势。

3. 图构建依赖多个 LLM 步骤

Graphiti 需要完成：

• 实体提取；
• 反思补充；
• 实体消歧；
• 事实提取；
• 事实去重；
• 时间提取；
• 冲突判断；
• 社区摘要。

这些步骤都可能产生误差，也会带来构建成本。

论文重点报告了召回和回答延迟，但没有完整量化所有图构建阶段的 token 成本。

4. 知识图抽取错误可能持续传播

如果实体消歧错误，后续事实可能连接到错误节点。

如果关系抽取错误，图遍历和社区摘要也会受到影响。

结构化记忆的优点是清晰可解释，但错误一旦进入结构，也可能被后续系统重复利用。

5. 社区需要定期刷新

增量标签传播能够降低实时更新成本，但长期运行后，社区结果会逐渐偏离完整算法的输出。

因此，系统仍然需要周期性重建。

6. 还缺少结构化业务数据的专门评测

Zep 强调可以同时处理对话和企业结构化数据，但论文中的实验主要还是对话记忆。

现有 benchmark 尚未充分评估：

对话历史
+
CRM、订单和工单等结构化数据

之间的联合推理能力。

7. DMR 区分度有限

论文自己也指出，DMR 规模较小，主要是单事实检索，现代长上下文模型使用完整对话已经可以取得接近满分的结果。

---

二十三、未来方向

论文提出了几个后续方向。

1. 使用微调模型完成图抽取

当前图构建大量依赖通用 LLM。

未来可以训练专门的模型负责：

• 实体提取；
• 实体消歧；
• 事实抽取；
• 边关系判断；
• 时间抽取。

这可能同时提高准确率并降低成本。

2. 引入领域本体

当前许多 LLM 生成知识图的方法并不依赖正式 ontology。

但企业场景往往具有明确的数据模式，例如：

客户
订单
商品
销售人员
合同
工单
组织部门

加入领域本体后，可以约束：

• 允许出现哪些实体类型；
• 哪些关系可以连接哪些实体；
• 字段和事实应该如何验证。

这可能提高图结构的一致性和可靠性。

3. 结合更多 GraphRAG 方法

Zep 当前的社区结构受到 GraphRAG 启发，但检索流程与 GraphRAG 不同。

未来可以探索：

• 更复杂的社区检索；
• 局部和全局查询路由；
• 多跳路径规划；
• 图摘要与原始证据联合生成。

4. 构建更可靠的记忆 benchmark

论文认为，现有长期记忆 benchmark 数量少，而且不少任务仍然偏向 needle-in-a-haystack 式事实检索。

后续需要更真实的任务，例如：

• 客户服务；
• 长期用户关系维护；
• 企业工作流；
• 多来源业务信息整合；
• 状态变化和历史追踪。

5. 更完整地评价成本和可扩展性

未来的记忆系统评测不应该只看回答准确率，还需要报告：

• 写入 token 成本；
• 图构建时间；
• 存储规模；
• 在线检索延迟；
• 社区重建成本；
• 超长期运行下的图增长情况。

---

二十四、和 Mem0、GAM、A-Mem 的区别

方法	主要记忆表示	核心关注点
Mem0	自然语言事实与实体关系图	增量提取、增改删和生产级部署
A-Mem	动态链接的记忆卡片	记忆如何自进化和建立关联
GAM	主题图与事件演进图	写入隔离和语义事件驱动固化
Zep	双时间动态知识图	如何维护不断变化的实体、事实和历史关系

1. Zep 和 Mem0

两者都强调生产级 Agent 记忆，但基础表示不同。

Mem0 的核心流程是：

提取候选事实
→ 检索相似旧记忆
→ ADD / UPDATE / DELETE / NOOP

Zep 的核心流程则是：

保存原始 Episode
→ 提取实体和事实
→ 进行实体与事实消歧
→ 提取有效时间
→ 更新动态知识图
→ 混合搜索和图召回

Mem0 更像事实生命周期管理系统。

Zep 更像持续演化的时序关系数据库。

2. Zep 和 Mem0 的图增强版本

二者都使用实体关系图，并保留旧关系的历史状态。

Zep 更突出：

• 双时间模型；
• Episode 原始数据层；
• 实体社区层；
• BM25、向量和 BFS 的混合搜索；
• 多种图重排器。

3. Zep 和 GAM

GAM 同样使用层级图，但二者的层级含义不同。

GAM：

局部事件演进图
→ 语义边界触发
→ 全局主题关联网络

Zep：

原始 Episode
→ 实体与事实
→ 实体社区

GAM 更关心什么时候把临时对话固化为长期知识。

Zep 更关心如何持续维护动态实体关系及其有效时间。

4. Zep 和 A-Mem

A-Mem 使用类 Zettelkasten 的记忆卡片和动态链接。

Zep 则采用更明确的知识图数据模型，包括：

• 实体节点；
• 事实边；
• 时间范围；
• 原始来源；
• 高层社区。

因此，Zep 的结构更适合企业关系数据和时间状态管理。

---

二十五、我的理解和启发

这篇论文给我的最大启发是：

长期记忆不仅是“保存过去的信息”，还要保存信息如何随时间发生变化。

1. 一条记忆应该有有效时间

很多 Agent 记忆系统只为记忆保存一个创建时间：

created_at

但这并不等于事实本身的发生时间。

更完整的字段应该包括：

事件发生时间
事实开始有效时间
事实失效时间
系统写入时间
来源消息

2. 删除旧记忆不一定是最佳方案

当用户状态变化时，直接删除旧记忆虽然能避免冲突，但也会丢失历史。

对于时间敏感的事实，可以采用：

保留旧记忆
+
标记有效区间
+
新增当前状态

例如：

北京：2022—2024
上海：2024—至今

3. 原始证据和结构化事实应该同时保存

只保存原始对话，检索效率较低。

只保存结构化事实，又可能丢失细节或受到抽取错误影响。

更合理的是：

原始消息
↕
抽取事实和实体

两者之间保留可追溯链接。

4. 检索不应该只有向量相似度

Zep 的三路搜索很值得借鉴：

BM25：
处理关键词和实体名称。

Embedding：
处理语义相似表达。

图遍历：
处理关系上下文和多跳连接。

自己的 Agent 记忆系统也可以采用类似混合召回。

5. 需要区分召回率和精度

搜索阶段可以尽量多找候选，随后再使用：

• RRF；
• MMR；
• 图距离；
• cross-encoder。

进行重排。

这比单次向量 Top-K 更灵活。

6. 社区层适合生成高层用户画像

如果长期记忆图中形成了多个稳定社区，可以生成：

职业与学习
旅行偏好
家庭关系
长期项目
兴趣爱好

这些社区摘要可以作为高层用户画像，而具体事实和 Episode 则保留底层证据。

7. 可以如何改造自己的 Agent 项目？

结合 Zep 的设计，可以为自己的记忆系统增加以下能力：

1. 为每条原始消息保存 episode_id 和 reference_time；
2. 从消息中抽取实体和事实；
3. 记录事实来源；
4. 为动态事实增加 valid_at 和 invalid_at；
5. 新事实出现时，不直接删除旧事实，而是标记其失效；
6. 使用 BM25、向量和图邻居进行混合召回；
7. 使用 cross-encoder 对候选结果重排；
8. 将高频关联实体聚合为主题社区；
9. 定期刷新社区摘要和清理低价值节点。

如果和之前读过的方法结合，可以形成：

Mem0：
事实增改删。

A-Mem：
动态记忆链接。

LightMem：
轻量压缩与离线更新。

GAM：
写入隔离和主题固化。

Zep：
时间关系、来源追踪和图检索。

---

二十六、总结

本文提出了 Zep，一种由动态时序知识图驱动的 Agent 长期记忆服务。

Zep 的核心组件 Graphiti 将记忆组织为三个层次：

1. 情景子图
   保存原始消息、文本和 JSON 数据，并提供可追溯的非损失数据层。

2. 语义实体子图
   保存从 Episode 中提取的实体和事实关系，并完成实体消歧、事实去重和关系更新。

3. 社区子图
   将强连接实体聚合成高层主题社区，并生成摘要和可检索名称。

Zep 的关键特征是双时间模型。它同时记录：

• 事实在现实世界中的有效时间；
• 事实在系统中的创建和失效时间。

当新信息与旧关系发生冲突时，系统不会简单删除旧边，而是为旧关系设置失效时间，从而同时保留当前状态和历史演变。

在召回阶段，Zep 将：

• 余弦语义搜索；
• BM25 全文检索；
• 图上的广度优先搜索；
• RRF、MMR、图距离和 cross-encoder 重排；

组合起来，最终将事实、时间范围、实体摘要和社区信息构造成 Agent 可以直接使用的上下文。

实验结果表明：

• Zep 在 DMR 上达到 94.8% 和 98.2%；
• 在 LongMemEval 上，GPT-4o-mini 准确率从 55.4% 提升到 63.8%；
• GPT-4o 准确率从 60.2% 提升到 71.2%；
• 平均上下文由约 11.5 万 token 降到约 1600 token；
• 响应延迟减少约 90%；
• 在用户偏好、时间推理、多会话和知识更新任务中优势明显。

整体来看，Zep 的核心价值在于：

它不是把长期记忆看作一组静态文本，而是把记忆表示成一个包含当前状态、历史关系、时间范围和原始证据的动态世界模型。

对于需要长期维护用户关系、业务状态和复杂实体关系的 Agent 来说，这种时序知识图架构具有较强的工程参考价值。

---

参考资料

• Rasmussen P, Paliychuk P, Beauvais T, et al. Zep: A Temporal Knowledge Graph Architecture for Agent Memory. arXiv preprint, 2025.
• Graphiti 代码仓库：https://github.com/getzep/graphiti
• 实验代码仓库：https://github.com/getzep/zep-papers