Zep: A Temporal Knowledge Graph Architecture for Agent Memory

论文阅读：Zep——面向 Agent Memory 的时序知识图谱架构

论文标题：Zep: A Temporal Knowledge Graph Architecture for Agent Memory
作者：Preston Rasmussen, Pavlo Paliychuk, Travis Beauvais, Jack Ryan, Daniel Chalef
作者机构：Zep AI
发表位置：arXiv 预印本
arXiv 编号：2501.13956
提交时间：2025 年 1 月 20 日
原文链接：https://arxiv.org/abs/2501.13956
PDF：https://arxiv.org/pdf/2501.13956
Graphiti：https://github.com/getzep/graphiti
主题：Agent Memory、Temporal Knowledge Graph、GraphRAG、Long-term Memory
核心问题：如何让 Agent 在持续增长、不断发生变化的长期交互数据中，以较低的上下文成本维护、更新并检索带有时间信息的长期记忆？

1. Introduction：为什么普通 RAG 不够用？

LLM Agent 的一个基本限制是上下文窗口。

即使模型支持很长的 Context，也不意味着 Agent 可以无限地把：

历史对话；
用户信息；
企业业务数据；
世界知识；
不断产生的新事件；

全部塞进 Prompt。

传统 RAG 的典型工作方式是：

文档
  ↓
切块
  ↓
Embedding
  ↓
向量数据库
  ↓
根据 Query 检索相关文本
  ↓
放入 LLM Context

这种方法非常适合相对静态的知识库。

问题在于，Agent Memory 面对的数据不是静态文档，而是一个持续变化的世界。

例如用户可能先说：

我在 A 公司工作。

几个月之后又说：

我已经离开 A 公司，现在加入 B 公司了。

如果把两条信息都作为普通文本放进向量数据库，那么数据库只知道：

用户 —— 工作于 —— A 公司
用户 —— 工作于 —— B 公司

但真正需要表示的是：

用户 —— 工作于 —— A 公司
有效时间：过去某段时间

用户 —— 工作于 —— B 公司
有效时间：从某个时间点开始至今

也就是说，Memory 不仅需要回答：

“有哪些事实？”

还要回答：

“这个事实什么时候成立？”

以及：

“这个事实现在还成立吗？”

论文因此认为，面向长期运行的 Agent，需要一种能够表示动态关系和关系历史的 Memory。

Zep 给出的答案是：

Temporal Knowledge Graph（时序知识图谱）。

Zep 本身是一个 Agent Memory 服务，而其核心知识图谱引擎叫作 Graphiti。

Graphiti 可以同时处理：

非结构化对话数据；
结构化业务数据；

并在知识发生变化时动态更新图，同时保留历史事实，而不是简单覆盖旧信息。

2. Knowledge Graph Construction：如何构建 Memory Graph？

Zep 的 Memory 是一个动态时序知识图谱。

论文将整个图划分为三个层次：

层级	原文名称	保存什么
第一层	Episode Subgraph	原始消息、文本、JSON
第二层	Semantic Entity Subgraph	实体以及实体之间的事实关系
第三层	Community Subgraph	高度关联实体形成的社区及其摘要

因此可以将其整体理解为：

原始 Episode
    ↓
实体 + Fact
    ↓
Entity Graph
    ↓
Community

其中 Episode 保留原始信息，Entity / Fact 提供结构化语义，Community 则进一步提供更高层次的概括。

论文将这种组织方式描述为：

Episodes → Facts → Entities → Communities

这与只保存文本 Chunk 的传统 RAG 有明显区别。

2.1 三层 Memory Graph

2.1.1 Episode Subgraph：保存原始经历

Episode 是 Graphiti 最底层的数据单位。

Episode 可以有三种类型：

Message；
Text；
JSON。

由于本文实验主要研究 Conversation Memory，因此论文重点讨论的是 Message。

一个 Message 大致包含：

speaker + message content + timestamp

例如：

Alice:
I started my new job two weeks ago.

Episode 的一个重要作用是：

保留原始数据。

Graphiti 并不会在将对话转换成实体和关系之后就丢掉原始消息。

因此可以把 Episode 层理解成一个 non-lossy data store，即无损的原始记忆层。

Entity 和 Fact 都可以反向追溯到产生它们的 Episode。

这使得：

Fact
 ↓
找到来源 Episode
 ↓
得到原始对话

成为可能。

反过来，也可以从 Episode 找到其中提取出的实体和 Fact。

论文指出，这种双向索引未来可以用于 Citation、Quotation 等场景，不过这些能力并没有在本文实验中进一步评估。

2.2 为什么需要 Episode 和 Semantic Memory 两层？

论文将这种设计与人类记忆中的：

Episodic Memory（情景记忆）
Semantic Memory（语义记忆）

联系起来。

Episode 保存的是具体发生过的事情。

例如：

2025-01-10：
Alice 说她开始在 Google 工作。

Semantic Memory 则把其中的意义抽取出来：

Alice —— WORKS_FOR —— Google

因此：

Episode
=
具体发生过什么

Semantic Entity / Fact
=
这些经历意味着什么

这样既保留原始信息，又获得方便检索和推理的结构化表示。

3. Temporal Modeling：Zep 的关键——双时间模型

Graphiti 和普通 Knowledge Graph 的一个关键区别是时间。

每一条 Message 都包含一个 Reference Timestamp：

t_ref

也就是这条消息发生的时间。

这个时间很重要，因为自然语言经常出现：

next Thursday
two weeks ago
last summer
three months later

如果没有消息本身的时间，就无法把这些相对时间转换成真正的日期。

3.1 两条时间轴

Graphiti 使用了一个 Bi-temporal Model（双时间模型）。

它维护两个不同的时间维度：

T  = 现实世界中的事件时间
T' = 数据进入 Zep 系统的事务时间

也就是说，要区分：

一件事情什么时候是真的？

以及：

系统什么时候知道这件事情？

这两个时间可能完全不同。

例如：

2025-01-01：
Alice 加入了 Company A

2025-03-01：
Alice 才告诉 Agent：
“我两个月前加入了 Company A。”

那么：

事实有效时间：
2025-01-01

Zep 获得这个事实的时间：
2025-03-01

两者不是同一个概念。

3.2 Fact 上的四个时间字段

Graphiti 为 Fact Edge 维护四类时间信息：

t'_created
t'_expired

t_valid
t_invalid

可以理解成：

时间	含义
`t'_created`	这条 Fact 什么时候被写入 Graphiti
`t'_expired`	这条 Fact 什么时候在数据库事务层被废止
`t_valid`	这条事实在现实世界什么时候开始成立
`t_invalid`	这条事实在现实世界什么时候不再成立

因此一条关系不是简单的：

Alice -- WORKS_FOR --> Google

而更接近：

Alice -- WORKS_FOR --> Google

valid_at: ...
invalid_at: ...

这使得 Graphiti 不只是记录“当前状态”，同时能够记录：

关系如何随时间演化。

4. Semantic Entities and Facts

Episode 进入系统之后，需要被转换成实体和关系。

整个过程可以概括为：

Episode
  ↓
Entity Extraction
  ↓
Entity Resolution
  ↓
Fact Extraction
  ↓
Fact Resolution
  ↓
Temporal Extraction
  ↓
Edge Invalidation
  ↓
写入 Knowledge Graph

这部分是 Graphiti 构建长期记忆的核心。

4.1 Entity Extraction：从消息中抽取实体

Graphiti 首先从当前 Message 中提取实体。

不过模型并不是只看当前消息。

论文中实际使用的是：

当前消息 + 前 n 条消息

其中：

n = 4

即提供前两个完整 Conversation Turn 作为上下文。

例如：

User:
I recently moved to Seattle.

Assistant:
How do you like it?

User:
The weather takes some getting used to.

如果只分析最后一句：

The weather takes some getting used to.

就很难知道这里讨论的是 Seattle。

因此 Entity Extraction 需要一定的局部 Conversation Context。

4.2 Speaker 本身也是 Entity

在 Message 类型的 Episode 中，Graphiti 会自动把 Speaker 提取为实体。

例如：

Alice:
I recently joined Google.

至少应该产生：

Alice
Google

论文附录中的 Prompt 明确规定：

Speaker / Actor 必须作为第一个 Entity 提取。

同时要求：

提取重要实体、概念和 Actor；
不要把 Relationship / Action 本身创建成 Node；
不要把日期、时间和年份创建成 Node；
尽可能使用完整明确的实体名称。

时间信息之后会被附加在 Edge 上。

4.3 Reflection：再次检查实体抽取

初次 Entity Extraction 后，Graphiti 还使用了一种受到 Reflexion 启发的 Reflection 过程。

目的包括：

减少遗漏；
降低 Hallucination；
提高 Entity Extraction Coverage。

也就是说，实体抽取不是单次 LLM 输出后立即结束，而是会额外进行检查。

同时系统还会为 Entity 生成 Summary，用于后续：

Entity Resolution；
Retrieval。

5. Entity Resolution：判断两个名字是不是同一个实体

长期对话中，同一个实体很容易以不同名字出现。

例如：

Robert Downey Jr.
Robert
RDJ
Tony Stark actor

如果每次都创建一个新 Node，Knowledge Graph 会迅速出现大量重复实体。

因此 Graphiti 在 Entity Extraction 之后还要执行：

Entity Resolution（实体消歧 / 实体解析）。

5.1 先生成 Embedding

系统首先把 Entity Name 转换成：

1024-dimensional embedding

然后在已有 Entity Node 中执行 Cosine Similarity Search。

除此之外，还会对：

Entity Name；
Entity Summary；

进行 Full-text Search。

因此候选实体来自两条检索路径：

Embedding Similarity
+
Full-text Search

5.2 再让 LLM 判断是不是同一个 Entity

检索得到 Candidate Nodes 后，Graphiti 将：

New Entity
Existing Candidate Entities
Episode Context

一起交给 LLM。

LLM 判断：

is_duplicate = true / false

如果是重复实体，还需要返回已有实体的 UUID，并生成一个更加完整的 Entity Name 和 Summary。

所以整体不是：

Embedding 相似
→ 直接 Merge

而是：

Embedding + Full-text
       ↓
召回候选 Entity
       ↓
LLM Entity Resolution
       ↓
决定是否 Merge

Embedding 负责缩小搜索空间，LLM 负责最终的语义判断。

5.3 为什么不用 LLM 自己生成 Cypher？

完成 Entity Resolution 后，系统需要真正把数据写入图数据库。

Graphiti 使用的是：

预定义 Cypher Query。

而不是让 LLM 动态生成 Cypher。

论文给出的理由主要有两个：

保证数据库 Schema 一致；
减少 LLM Hallucination 导致错误 Query 的风险。

因此 LLM 的职责主要是：

理解内容
抽取 Entity / Fact
进行 Resolution
判断 Temporal 信息

而具体数据库操作仍然由固定程序逻辑完成。

6. Facts：关系本身也是 Memory

有了 Entity 后，Graphiti 从 Message 中继续提取 Entity 之间的 Fact。

例如：

Alice:
I started working at OpenAI last month.

可能得到：

Entity:
Alice
OpenAI

Fact:
Alice WORKS_FOR OpenAI

论文附录要求，每个 Fact：

必须发生在两个不同 Entity 之间；
Relation Type 应为简洁的大写描述；
同时保存更加详细的 Fact 文本；
在必要时考虑 Relationship 的时间信息。

例如：

relation_type:
WORKS_FOR

fact:
Alice started working at OpenAI.

6.1 一个复杂 Fact 可以涉及多个实体

论文指出，同一个 Fact 可以被提取到不同 Entity Pair 之间。

这样可以近似表达复杂的 Multi-entity Fact。

作者将这种实现描述为一种对 Hyper-edge（超边） 的实现方式。

因此 Graphiti 的 Fact 并不仅限于最简单的：

A -- relation --> B

还能够通过多个关联 Edge 表达涉及多个实体的复杂事件。

7. Fact Resolution：关系也需要去重

和 Entity 一样，Fact 也可能重复出现。

例如用户多次说：

I work at OpenAI.

I currently work for OpenAI.

OpenAI is my employer.

这些句子的文字不同，但表达的是相同 Fact。

所以 Graphiti 也执行：

Edge Deduplication / Fact Resolution。

7.1 先限制到相同 Entity Pair

这里有一个很重要的工程设计。

系统并不会把新 Fact 与整个图中的所有 Fact 比较。

而是先限制：

只搜索连接相同 Entity Pair 的 Existing Edges。

例如新的 Fact 是：

Alice → OpenAI

那么只需要在：

Alice ↔ OpenAI

已有的 Edges 中进行搜索。

这样既可以防止：

语义相似但属于不同 Entity 的 Edge

被错误合并，也显著降低了搜索空间。

然后再由 LLM 判断：

New Edge 与 Existing Edge
是否表达相同的事实？

如果相同，就进行 Deduplication。

8. Temporal Extraction：从自然语言中抽取事实有效时间

Graphiti 接下来会从 Fact 中提取时间。

输入包括：

Previous Messages
Current Message
Reference Timestamp
Fact

例如：

Reference Timestamp:
2025-03-15

Message:
I started working at OpenAI two weeks ago.

系统应该根据 Reference Timestamp 将：

two weeks ago

解析成具体时间。

附录中的 Prompt 明确要求：

相对时间根据 Reference Timestamp 计算；
输出 ISO 8601；
如果只有日期，没有具体时刻，则使用 00:00:00；
如果只知道年份，则使用当年 1 月 1 日；
如果事实使用现在时，可以使用 Reference Timestamp 作为 valid_at；
只有时间确实属于当前 Fact 时才应抽取；
不应从相关事件中随意推断 Fact 的日期。

因此 Temporal Extraction 并不是单纯识别文本中有没有日期，而是判断：

这个时间是不是当前 Relationship 本身的有效时间？

9. Edge Invalidation：新记忆如何修改旧记忆？

这是 Graphiti 最关键的设计之一。

假设已有：

Alice -- WORKS_FOR --> Company A

后来用户说：

I left Company A and joined Company B.

传统知识图谱如果直接加入：

Alice -- WORKS_FOR --> Company B

就会变成：

Alice -- WORKS_FOR --> Company A
Alice -- WORKS_FOR --> Company B

从图本身无法知道哪个才是当前状态。

Graphiti 会检查：

New Edge
vs
Semantically Related Existing Edges

并使用 LLM 判断它们是否冲突。

如果存在时间上重叠的矛盾关系，旧 Edge 会被 Invalidate（失效）。

例如：

Alice WORKS_FOR Company A
valid: 2023-01-01
invalid: 2025-01-01

Alice WORKS_FOR Company B
valid: 2025-01-01
invalid: null

Graphiti 并不会删除：

Alice 曾经在 Company A 工作

而只是明确：

这个事实已经不再成立。

这样就同时保留了：

Current State；
Historical State。

对于长期 Agent Memory，这比简单覆盖旧事实更重要，因为历史状态本身仍可能在未来被查询。

10. Community Subgraph：在 Entity Graph 上建立更高层语义

当 Episode 和 Semantic Entity Graph 建立之后，Graphiti 进一步建立：

Community Subgraph（社区子图）。

Community 是由一组紧密连接的 Entity 构成的 Cluster。

例如一个大型长期 Memory Graph 可能自然形成：

工作相关实体
家庭相关实体
旅游相关实体
研究相关实体
某个项目相关实体

Community Node 保存这个 Cluster 的高层 Summary。

于是：

Entity / Fact

解决局部细粒度知识，

而：

Community

负责表达更高层次的主题和结构。

10.1 为什么不用 GraphRAG 的 Leiden？

Graphiti 的 Community Detection 基于 GraphRAG 的思路，但算法上存在区别。

GraphRAG 使用：

Leiden Algorithm

Graphiti 使用：

Label Propagation

论文选择 Label Propagation 的主要原因是：

它更容易动态扩展。

Agent Memory 是持续更新的。

如果每增加一个 Entity 都重新对整个 Knowledge Graph 做完整 Community Detection，成本很高。

因此 Graphiti 使用增量更新。

10.2 新 Entity 如何加入 Community？

当新的 Entity Node 加入 Graph 时：

New Entity
   ↓
查看 Neighbor Nodes
   ↓
统计 Neighbor 所属 Community
   ↓
选择数量最多的 Community
   ↓
加入该 Community
   ↓
更新 Community Summary

这相当于执行一次局部 Label Propagation。

这样不需要每次重新计算整个 Graph。

10.3 代价：Community 会逐渐漂移

这种增量方法并不完美。

随着越来越多 Node 被增量加入：

动态更新得到的 Community

会逐渐偏离：

从头完整运行 Label Propagation

得到的 Community。

因此 Graphiti 仍然需要：

Periodic Community Refresh。

也就是偶尔重新进行完整 Community Detection。

论文将这个设计视为一种工程上的折中：

频繁全量更新
→ 更准确
→ 延迟和成本高

局部动态更新
→ 快
→ 长期会产生漂移

局部更新 + 周期性 Refresh
→ 在两者之间折中

10.4 Community Summary

Community Node 会保存其成员实体的高级 Summary。

这里使用与 GraphRAG 类似的：

Iterative Map-Reduce-style Summarization。

除此之外，还会根据 Community Summary 生成 Community Name。

Community Name 中包含：

Key Terms；
Relevant Subjects。

随后对 Community Name 进行 Embedding。

这样 Community 本身也可以参与向量检索。

11. Memory Retrieval：Memory 写进去之后怎么找出来？

知识图谱只是存储结构。

真正给 Agent 使用时，还需要回答：

给定当前 Query，到底应该从 Graph 中拿哪些信息放进 Context？

Zep 将 Retrieval Pipeline 分成三个阶段：

Query
  ↓
Search
  ↓
Reranker
  ↓
Constructor
  ↓
Context
  ↓
LLM

论文形式化表示为：

f(query) = Constructor(Reranker(Search(query)))

也就是：

Search → Rerank → Context Construction

12. Search：三种检索机制

Zep 同时使用三种 Search：

Search	作用
Cosine Similarity	找语义相似内容
BM25 Full-text Search	找词面相似内容
Breadth-first Search	找图结构上邻近的内容

作者希望三种检索分别捕获不同形式的“相关性”。

12.1 Cosine Similarity：语义相关

Embedding Search 用于寻找：

语义上类似

的 Entity、Fact 或 Community。

即使 Query 与 Memory 使用了不同词汇，只要语义接近，也有机会召回。

12.2 BM25：词面相关

BM25 Full-text Search 更关注：

关键词是否重合

Embedding Search 与 BM25 形成互补。

例如一些：

人名；
产品名；
公司名；
专有名词；

使用 Exact / Lexical Match 往往非常重要。

12.3 BFS：图结构相关

第三种 Search 是：

Breadth-First Search（广度优先搜索）。

它利用 Knowledge Graph 本身的结构。

基本思想是：

如果两个 Node / Edge 在图上距离很近，它们很可能处于相似的 Conversation Context 中。

因此可以先找到一个重要 Entity，再向其周围扩展 n-hop。

例如：

Query
 ↓
找到 Alice
 ↓
BFS
 ↓
Alice 的工作
Alice 的同事
Alice 所在项目
Alice 最近相关事件

这是一种传统向量数据库没有的 Contextual Similarity。

12.4 最近 Episode 也可以成为 BFS Seed

论文特别提到，BFS 可以接受 Node 作为 Seed。

因此可以把：

Recent Episodes 中出现的 Entity

作为 BFS 起点。

这使 Retrieval 不仅依赖当前 Query，还能利用最近 Conversation State。

例如用户刚刚讨论：

Project Phoenix

下一句问：

Who was responsible for the deployment?

Query 本身未必出现 Project Phoenix。

但最近 Episode 可以把：

Project Phoenix

相关 Node 作为 BFS Seed，从而检索其附近关系。

12.5 三种 Search 的互补关系

作者总结三类相似性为：

BM25
→ Word Similarity

Cosine Similarity
→ Semantic Similarity

BFS
→ Contextual / Graph Similarity

三者共同用于 Candidate Generation。

这一阶段优先考虑的是：

Recall。

即尽量不要漏掉真正有用的信息。

13. Reranker：从高 Recall 变成高 Precision

Search 找到大量候选结果之后，再进入 Reranking。

Zep 支持多种 Reranker。

包括：

Reciprocal Rank Fusion（RRF）；
Maximal Marginal Relevance（MMR）；
Episode Mentions Reranker；
Node Distance Reranker；
Cross-encoder Reranker。

13.1 RRF 和 MMR

RRF 用于融合来自多个 Retriever 的排序结果。

例如：

BM25 Ranking
Embedding Ranking
BFS Ranking
       ↓
      RRF
       ↓
Unified Ranking

MMR 则进一步考虑：

Relevant
+
Diversity

避免 Top-K 中充满高度重复的内容。

13.2 Episode Mentions Reranker

这是一个利用 Graph 结构和 Conversation History 的 Reranker。

如果某个 Entity / Fact 在大量 Episode 中反复被提及，那么它的重要程度更高。

因此可以根据：

Mention Frequency

对结果重新排序。

简单来说：

长期对话中反复出现的 Memory
→ 更容易被检索回来

13.3 Node Distance Reranker

系统还可以指定一个 Centroid Node。

然后根据 Candidate 与这个 Node 的图距离重新排序：

离 Centroid 更近
→ Ranking 更高

这样可以让 Retrieval 聚焦在 Knowledge Graph 的某个局部区域。

13.4 Cross-encoder

最复杂的方式是 Cross-encoder。

模型直接联合考虑：

Query + Candidate

并产生 Relevance Score。

这种方式通常具有较强的语义判断能力，但论文也指出：

计算成本最高。

因此 Graphiti 的 Retrieval 并不是固定的单一 Search Pipeline，而是一个可以按需求组合不同 Search 和 Reranking 策略的系统。

14. Constructor：把 Graph 重新变成 LLM 能读的 Context

完成 Search 和 Reranking 后，Graph 结构本身还不能直接作为普通 Chat Model 的 Prompt。

因此最后还有：

Constructor。

Constructor 将筛选出的：

Fact Edge；
Entity Node；
Community Node；

转换成文本。

Fact 包括：

Fact
Valid Date
Invalid Date

Entity 包括：

Entity Name
Entity Summary

Community 则主要提供：

Community Summary

最终生成类似：

FACTS

Alice works at OpenAI
(Date range: 2025-01-01 - present)

...

ENTITIES

Alice:
...

OpenAI:
...

这样的 Context，再提供给 LLM。

因此完整 Memory Pipeline 是：

Conversation
    ↓
Episode
    ↓
Entity / Fact Extraction
    ↓
Entity / Fact Resolution
    ↓
Temporal Processing
    ↓
Knowledge Graph
    ↓
Search
    ↓
Rerank
    ↓
Context Constructor
    ↓
LLM Response

15. Experiments

论文使用两个 Agent Memory Benchmark：

Deep Memory Retrieval（DMR）
LongMemEval

作者特别强调，Zep 是 Production System，因此除了 Accuracy，也关注：

Latency；
Context Size；
Scalability。

16. 模型配置

实验中的模型配置如下。

Embedding 和 Reranking

使用：

BGE-M3

完成 Embedding 和 Reranking。

Knowledge Graph Construction

使用：

gpt-4o-mini-2024-07-18

完成 Graph Construction。

也就是说，前面介绍的：

Entity Extraction；
Entity Resolution；
Fact Extraction；
Temporal Extraction；

等 LLM-based Graph Construction 操作主要使用 GPT-4o-mini。

最终回答生成

使用：

gpt-4o-mini-2024-07-18
gpt-4o-2024-11-20

为了与 MemGPT 原始 DMR 结果进行直接比较，还额外使用：

gpt-4-turbo-2024-04-09

17. Deep Memory Retrieval（DMR）

DMR 来自 MemGPT 的评测设置。

数据包含：

500 个 Multi-session Conversation

每个 Conversation：

5 个 Chat Session

每个 Session：

最多 12 条 Message

因此一个 Conversation 最多大约：

60 条 Message

每个 Conversation 对应一个 Memory Question / Answer Pair。

17.1 DMR 实验结果

论文 Table 1 的结果如下：

Memory Method	Model	Score
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%

其中 MemGPT 和 Recursive Summarization 的 GPT-4-Turbo 数据直接引用自 MemGPT 论文。

Zep：

GPT-4-Turbo:
94.8%

GPT-4o-mini:
98.2%

均略微超过 Full-conversation。

17.2 DMR 使用 LLM Judge

DMR 中，作者使用 LLM Judge：

Agent Response
+
Golden Answer
       ↓
    LLM Judge
       ↓
Correct / Incorrect

因此这里报告的 Accuracy 并不是完全由 Exact Match 计算出来的，而包含 LLM-based Evaluation。

17.3 作者自己认为 DMR 不够有挑战性

论文没有把 94.8% 对 93.4% 的提升无限放大。

相反，作者专门讨论了 DMR 本身的问题。

最明显的一点是：

一个 Conversation 只有大约 60 条 Message

这些内容完全能够放进现代 LLM 的 Context Window。

实际结果也验证了这一点：

Full-context + GPT-4o-mini
=
98.0%

而：

Zep + GPT-4o-mini
=
98.2%

差距只有 0.2 个百分点。

因此 DMR 很难真正测试：

当长期 Memory 远远超过 Context Window 或模型有效 Context 能力时，Memory System 是否仍然有效？

17.4 DMR 的其他问题

作者还指出：

DMR 基本都是：

Single-turn Fact Retrieval

缺少复杂 Memory Understanding。

部分 Question 还带有较强的模糊描述，例如：

favorite drink to relax with
weird hobby

但 Conversation 中并不一定明确使用这些标签。

更重要的是，作者认为 DMR 与现实 Enterprise Agent 所面临的：

长时间跨度；
多 Session；
Knowledge Update；
Temporal Reasoning；

差距较大。

因此论文把更主要的实验关注放到了 LongMemEval。

18. LongMemEval

LongMemEval 提供显著更长的 Conversation。

论文使用的是：

LongMemEval_s

平均 Context 长度约：

115,000 Tokens

虽然 115K Token 仍然能够放入部分 Frontier Model 的 Context Window，但已经足够构成有意义的 Full-context Baseline。

LongMemEval 包含六类问题：

Question Type	含义
single-session-user	单 Session 中关于用户的信息
single-session-assistant	单 Session 中关于 Assistant 输出的信息
single-session-preference	用户偏好
multi-session	跨 Session 信息整合
knowledge-update	信息发生更新
temporal-reasoning	时间推理

其中后几种尤其接近 Zep 设计所针对的问题。

19. LongMemEval 的评测方式

LongMemEval 的回答评价同样使用 LLM Judge。

论文使用：

GPT-4o

配合 LongMemEval 原论文针对不同 Question Type 提供的 Evaluation Prompt。

作者指出，这套评测方式在 LongMemEval 工作中表现出与人工评价较高的相关性。

实验时间为：

2024 年 12 月 - 2025 年 1 月

Zep Service 部署在：

AWS us-west-2

测试客户端则位于 Boston 的普通 Consumer Laptop。

因此 Zep 的 Latency 结果实际上还包含网络访问远程服务产生的额外延迟，而 Full-context Baseline 不包含这部分网络延迟。

20. 为什么 LongMemEval 没有 MemGPT 结果？

作者原本希望直接比较：

Zep vs MemGPT

但 MemGPT 当时的 Framework 不支持直接导入已经存在的 Message History。

作者尝试把 Conversation Message 加入 MemGPT 的 Archival History 作为 workaround，但没有成功得到可用的 Question Response。

因此：

LongMemEval 中实际上没有 MemGPT 的有效实验结果。

最终主要比较的是：

Zep
vs
Full-context

这一点在理解论文 LongMemEval 的结果时很重要。

21. LongMemEval 总体结果

论文 Table 2 如下：

Memory	Model	Score	Latency	Latency IQR	Avg Context Tokens
Full-context	GPT-4o-mini	55.4%	31.3 s	8.76 s	115k
Zep	GPT-4o-mini	63.8%	3.20 s	1.31 s	1.6k
Full-context	GPT-4o	60.2%	28.9 s	6.01 s	115k
Zep	GPT-4o	71.2%	2.58 s	0.684 s	1.6k

这里呈现出了 Zep 相比 DMR 更明显的优势。

GPT-4o-mini：

55.4%
→
63.8%

GPT-4o：

60.2%
→
71.2%

论文将其分别描述为：

15.2% relative improvement
18.5% relative improvement

22. Context 从 115K 降到约 1.6K Tokens

除了 Accuracy，另一个非常明显的差异是 Context Size。

Full-context：

115k Tokens

Zep：

约 1.6k Tokens

因此 Zep 并不是让最终 LLM 阅读整个 Conversation。

而是：

115K Conversation History
        ↓
Graph Memory
        ↓
Search + Reranking
        ↓
只取真正相关 Entity / Fact
        ↓
约 1.6K Token Context
        ↓
LLM

这解释了论文中的 Latency 差距。

GPT-4o：

Full-context:
28.9 s

Zep:
2.58 s

GPT-4o-mini：

Full-context:
31.3 s

Zep:
3.20 s

作者总结为：

Response Latency 大约降低 90%。

23. 按问题类型拆分结果

论文进一步给出了各 Question Type 的结果。

Question Type	Model	Full-context	Zep	Relative Delta
single-session-preference	GPT-4o-mini	30.0%	53.3%	+77.7%
single-session-assistant	GPT-4o-mini	81.8%	75.0%	-9.06%
temporal-reasoning	GPT-4o-mini	36.5%	54.1%	+48.2%
multi-session	GPT-4o-mini	40.6%	47.4%	+16.7%
knowledge-update	GPT-4o-mini	76.9%	74.4%	-3.36%
single-session-user	GPT-4o-mini	81.4%	92.9%	+14.1%
single-session-preference	GPT-4o	20.0%	56.7%	+184%
single-session-assistant	GPT-4o	94.6%	80.4%	-17.7%
temporal-reasoning	GPT-4o	45.1%	62.4%	+38.4%
multi-session	GPT-4o	44.3%	57.9%	+30.7%
knowledge-update	GPT-4o	78.2%	83.3%	+6.52%
single-session-user	GPT-4o	81.4%	92.9%	+14.1%

几个结果尤其值得关注。

23.1 Temporal Reasoning

GPT-4o：

45.1%
→
62.4%

GPT-4o-mini：

36.5%
→
54.1%

这是和 Graphiti 的 Temporal Design 最直接相关的一类任务。

因为 Graphiti 并非单纯保存：

Entity + Fact

而是显式维护：

Fact
+
valid_at
+
invalid_at

并处理 Fact Invalidation，因此长期时间关系已经在 Memory Construction 阶段被结构化。

23.2 Multi-session

GPT-4o：

44.3%
→
57.9%

GPT-4o-mini：

40.6%
→
47.4%

这一类问题要求从多个 Session 中整合信息。

这正是长期 Agent Memory 与普通单轮 RAG 的主要差异之一。

23.3 Knowledge Update

GPT-4o：

78.2%
→
83.3%

但 GPT-4o-mini：

76.9%
→
74.4%

反而稍有下降。

论文据此提出，更弱的模型可能还不能充分理解 Zep 提供的 Temporal Data，而更强的模型能够更好地利用这些结构化时间信息。

24. 并不是所有类型都变好

Zep 最明显的失败案例是：

single-session-assistant

GPT-4o：

Full-context: 94.6%
Zep:         80.4%

下降：

17.7%

GPT-4o-mini：

81.8%
→
75.0%

下降约：

9.06%

因此论文并没有声称 Graph Memory 对所有问题类型都优于 Full-context。

作者明确表示：

这一类别仍然需要进一步 Research 和 Engineering Work。

25. Zep 的核心设计可以如何概括？

把前面所有模块合起来，Zep 并不是简单做：

Conversation
↓
Embedding
↓
Vector DB

而是把长期 Memory 拆成：

                   ┌──────────────┐
                   │ Raw Episodes │
                   └──────┬───────┘
                          ↓
                 Entity Extraction
                          ↓
                  Entity Resolution
                          ↓
                   Fact Extraction
                          ↓
                   Fact Resolution
                          ↓
               Temporal Extraction
                          ↓
                  Edge Invalidation
                          ↓
              ┌────────────────────┐
              │ Semantic Entity KG │
              └──────────┬─────────┘
                         ↓
                Community Detection
                         ↓
                Community Summary

Query 到来后：

Query
  ↓
BM25 + Embedding + BFS
  ↓
Candidate Memory
  ↓
RRF / MMR / Graph Reranker / Cross-encoder
  ↓
Relevant Facts + Entities + Communities
  ↓
Context Constructor
  ↓
Compact Context
  ↓
LLM

因此真正重要的不是单独某一种 Retrieval Algorithm，而是：

把持续变化的 Conversation 转换成一个能够保留原始 Episode、结构化 Fact、Fact 有效时间和历史状态的动态 Knowledge Graph。

26. Graphiti 与普通 GraphRAG 的主要区别

论文在多个地方借鉴了 GraphRAG，但其目标并不完全相同。

传统 GraphRAG 更多处理：

已有文档集合
↓
构建图
↓
利用 Graph Structure 改善 Retrieval

Zep / Graphiti 更关注：

不断到来的 Conversation / Business Data
↓
持续更新 Knowledge Graph
↓
处理重复 Entity
↓
处理重复 Fact
↓
处理 Fact 冲突
↓
维护 Fact Validity
↓
保存 Historical State

因此核心问题从：

“如何从一个 Knowledge Graph 中检索？”

进一步变成：

“如何让这个 Knowledge Graph 本身随着现实世界持续演化？”

这也是论文把 Temporal 放在标题中的原因。

27. 论文中的实现细节总结

整个 Graph Construction Pipeline 中，LLM 承担了大量语义判断工作。

步骤	主要机制
Entity Extraction	LLM
Reflection	LLM
Candidate Entity Retrieval	Embedding + Full-text Search
Entity Resolution	LLM
Fact Extraction	LLM
Candidate Edge Retrieval	Hybrid Search
Fact Resolution	LLM
Temporal Extraction	LLM
Contradiction / Invalidation 判断	LLM
写入数据库	Predefined Cypher
Community Detection	Label Propagation
Community Summary	LLM Summarization
Memory Search	BM25 + Cosine + BFS
Reranking	RRF / MMR / Graph-based / Cross-encoder
Context Construction	Programmatic Formatting

因此 Graphiti 既不是：

纯 Knowledge Graph Algorithm

也不是：

让 LLM 自己维护一段 Memory Text

而是一个组合系统：

LLM Semantic Extraction
+
Embedding Retrieval
+
Full-text Retrieval
+
Graph Algorithm
+
Graph Database
+
Temporal Data Model
+
Reranking

28. 一个需要注意的实验描述细节

论文 Section 4 的通用实验描述中写道，会检索：

20 个最相关的 Edge 和 Entity Node

但在 Section 4.2 的 DMR 具体描述中，又写道：

retrieve the top 10 most relevant nodes and edges

因此原文在通用实验设置与 DMR 子章节的 Top-K 描述上存在差异。

能够明确确认的是：

Section 4 通用描述：Top-20；
DMR 子章节：Top-10。

论文没有进一步解释这两个数字之间的关系。

29. 论文明确指出的局限性

论文虽然没有单独设置 Limitations Section，但正文和 Conclusion 中给出了多项限制。

29.1 DMR Benchmark 太简单

DMR：

Conversation 太短；
Full-context 本身已经接近满分；
主要测试 Single-turn Fact Retrieval；
部分问题描述模糊；
很难代表现实 Enterprise Agent Memory。

因此它已经不足以有效区分现代 Memory System。

29.2 LongMemEval 中没有成功得到 MemGPT 对照

作者尝试运行 MemGPT，但没有成功。

因此 LongMemEval 的核心实验实际上是：

Zep vs Full-context

而不是：

Zep vs MemGPT

29.3 部分 Question Type 性能下降

尤其：

single-session-assistant

Zep 显著低于 Full-context。

说明压缩成结构化 Graph Memory 并不会在所有信息类型上都优于保留完整原文。

29.4 Graphiti 的全部 Retrieval 能力没有完整评估

论文明确指出，实验只测试了 Graphiti Search Functionality 的一个子集。

例如 Episode 与 Semantic Artifact 之间的双向追溯能力，并没有在本文实验中直接验证。

29.5 当前 Benchmark 无法评估结构化业务数据

Zep 的设计目标之一是同时融合：

Conversation History
+
Structured Business Data

但作者指出，现有 Benchmark 没有真正评价这种能力。

所以本文实验主要验证的是：

Conversation Memory。

并没有完整覆盖 Zep 所声称的整个 Enterprise Memory 使用场景。

29.6 Community 的动态更新会产生漂移

Graphiti 使用增量 Label Propagation 降低实时更新成本。

但随着时间增长：

Incrementally Updated Community

会逐渐偏离完整重新计算得到的 Community。

因此仍然需要：

Periodic Community Refresh

30. 论文提出的未来方向

作者在 Conclusion 中提出了多个后续方向。

30.1 为 Graph Construction 训练专用模型

目前大量步骤依赖通用 LLM，例如：

Entity Extraction；
Edge Extraction；
Resolution。

作者指出，已有研究表明 Fine-tuned Model 可以提高 Knowledge Graph Extraction 的：

Accuracy；
Cost Efficiency；
Latency。

因此未来可以针对 Graphiti 的 Prompt 和任务训练专门模型。

30.2 引入 Domain-specific Ontology

目前很多 LLM-generated Knowledge Graph，包括 Graphiti，都没有强制使用正式 Ontology。

作者认为：

Domain-specific Ontology（领域本体）

可能是值得进一步探索的方向。

例如在医疗领域，可以提前规定：

Patient
Disease
Medication
Doctor
Treatment

以及允许的 Relation Type。

这样可能增强 Knowledge Graph 的结构一致性。

30.3 更好的 Agent Memory Benchmark

作者认为现有 Memory Benchmark 数量有限，而且大量任务仍停留在：

Needle-in-a-haystack Fact Retrieval

未来需要更接近真实业务的评测，例如：

Customer Experience；
Cross-session Reasoning；
Dynamic Knowledge Update；
Conversation + Structured Business Data；
Long-term User Modeling。

30.4 与其他 GraphRAG 方法进一步结合

Graphiti 已经借鉴：

GraphRAG；
AriGraph；
Hierarchical RAG；

但作者认为还可以继续将其他 GraphRAG Retrieval Strategy 集成进 Zep。

例如论文专门提到，Graphiti 的 Community Key Search 与 LightRAG 的 High-level Key Retrieval 存在相似之处，将这些方法进一步结合是一个潜在方向。

30.5 更系统地评测 Cost、Latency 和 Scalability

作者认为 Memory / RAG 研究通常过于关注 Accuracy，而对 Production System 中同样关键的：

Latency
Cost
Scalability

讨论不足。

本文加入了 Retrieval Latency Benchmark，但作者认为未来还需要更加系统的 Production-level Evaluation。

31. 总结

Zep 的核心思路并不是简单地：

“使用 Knowledge Graph 做 Agent Memory。”

真正的重点在于：

使用一个能够持续更新并显式维护时间有效性的 Knowledge Graph 作为 Agent 的长期 Memory。

Graphiti 将 Memory 分成三层：

Episode
↓
Entity / Fact
↓
Community

Episode 保存原始经历，保证信息不因结构化抽取而完全丢失；

Entity 和 Fact 将 Conversation 转换成结构化 Semantic Memory；

Community 在更高层总结强关联实体。

而 Temporal Modeling 又进一步为 Fact 增加：

valid_at
invalid_at
created_at
expired_at

使系统不仅知道：

什么是真的

还能够知道：

什么时候是真的
什么时候不再是真的
系统什么时候知道这件事

当新信息与旧事实发生冲突时，Graphiti 不简单删除过去，而是通过 Edge Invalidation 维护事实的历史有效区间。

Retrieval 阶段则组合：

BM25
+
Embedding Search
+
Graph BFS
+
Reranking

最后只把少量相关 Fact、Entity 和时间信息重新构造成 LLM Context。

实验上，DMR 中 Zep 的提升较小，而且作者自己认为该 Benchmark 已经过于简单：

GPT-4o-mini:

Full-context  98.0%
Zep           98.2%

更明显的结果来自 LongMemEval。

在平均约 115K Token 的长期 Conversation 中：

GPT-4o:

Full-context:
60.2%
28.9 s
115k context tokens

Zep:
71.2%
2.58 s
1.6k context tokens

因此 Zep 展示出的主要优势并不只是“把更多历史保存下来”，而是：

把长期历史
→ 转换成动态、结构化、带时间有效性的 Memory
→ 检索真正相关的少量信息
→ 再交给 LLM

与此同时，论文也显示这种 Graph Memory 并非无条件优于 Full-context：例如 single-session-assistant 类问题中性能明显下降；LongMemEval 也没有成功获得 MemGPT 的可比实验结果。

因此这篇工作的核心落点可以概括为：

将传统偏静态的 GraphRAG 扩展为面向长期 Agent 的动态 Temporal Knowledge Graph Memory，并通过实体解析、事实去重、时间抽取、关系失效和多路图检索，使 Memory 能够随着持续交互不断演化。

参考

Preston Rasmussen, Pavlo Paliychuk, Travis Beauvais, Jack Ryan, Daniel Chalef. Zep: A Temporal Knowledge Graph Architecture for Agent Memory. arXiv:2501.13956, 2025.
https://arxiv.org/abs/2501.13956
Zep. Graphiti: Temporal Knowledge Graphs for Agentic Applications.
https://github.com/getzep/graphiti
Charles Packer et al. MemGPT: Towards LLMs as Operating Systems. 2024.
Darren Edge et al. From Local to Global: A Graph RAG Approach to Query-Focused Summarization. 2024.
Di Wu et al. LongMemEval: Benchmarking Chat Assistants on Long-Term Interactive Memory. 2024.
Petr Anokhin et al. AriGraph: Learning Knowledge Graph World Models with Episodic Memory for LLM Agents. 2024.
Zirui Guo et al. LightRAG: Simple and Fast Retrieval-Augmented Generation. 2024.

posted @ 2026-09-15 16:15 YourF4u1t 阅读(25) 评论(0) 收藏举报

刷新页面返回顶部