速读
智能体记忆的挑战与Zep的创新
智能体(AI Agents)在复杂任务中面临记忆瓶颈。传统基于大型语言模型(LLM)的智能体受限于上下文窗口,难以有效整合长期对话历史和动态数据,限制了表现并易产生幻觉。Zep 是一种创新知识图谱架构,通过其核心组件 Graphiti,赋能智能体强大的记忆能力,应对动态信息环境。它解决了现有RAG方法难以处理时序信息和跨会话推理的难题,为企业级应用提供了更可靠的记忆支持。
实现方法:Graphiti——时序感知知识图谱引擎
Graphiti 通过多层次知识图谱构建、时序信息的动态管理和高效的检索机制实现智能体记忆。
- 多层次知识图谱构建:
- 情节子图: 原始数据(对话消息)作为情节节点,包含文本和时间戳。
- 语义实体子图: 从情节节点提取实体(人名、地点、产品等)作为语义实体节点。
- 社区子图: 聚合同一主题的实体节点,形成社区节点。
- 这种层次化结构提升可扩展性,使智能体更有效地理解信息。
- 时序信息动态管理:
- 双时间模型: 记录事件时序(Timeline T)和数据摄入时序(Timeline T'),处理绝对/相对时间信息。
- 动态更新: 实时更新知识图谱,处理时间冲突。
- Graphiti 的时序感知能力确保信息准确性和时效性。
- 高效检索机制:
- 多方法融合: 结合余弦相似性搜索、全文搜索和广度优先搜索,快速准确地找到相关上下文。
企业级应用:完整示例流程
场景:企业客户支持智能体
用户输入:
用户通过聊天界面发送消息:“你好,我上个月购买的HP LaserJet Pro MFP M28w打印机出现了问题,打印出来的文件有重影。我之前已经联系过技术支持,他们告诉我重启打印机可以解决问题,但我试过了,还是不行。”
1. 情节节点摄入:
Graphiti将用户的最新消息作为新的情节节点摄入知识图谱,并附带当前时间戳(例如,2024年2月20日 10:30 AM)。同时,系统检索与“打印机问题”相关的历史对话情节。
2. 实体和关系提取:
- 实体提取:
- 打印机型号:HP LaserJet Pro MFP M28w
- 购买日期:2024年1月10日
- 问题描述:打印文件有重影
- 之前联系时间:2024年1月15日
- 之前解决方案:重启打印机
- 关系提取:
[用户] 购买 [打印机]
[打印机] 存在 [打印文件有重影] 问题
[重启打印机] 是 [尝试过的解决方案]
3. 社区检测:
系统将“HP LaserJet Pro MFP M28w”打印机相关的所有实体和关系聚合成一个社区,以便进行更高效的检索。
4. 动态更新信息:
Graphiti 检查是否有需要更新的信息。 由于用户反映重启打印机未能解决问题,系统将更新 [重启打印机] 的 [解决方案状态]
为 [未解决]
。
5. 检索相关上下文:
系统使用多种检索方法查找:
- 全文搜索:检索包含 "打印机", "重影", "HP LaserJet Pro MFP M28w" 等关键词的历史对话。
- 余弦相似性搜索:查找描述类似打印问题的对话,例如 “打印输出模糊”, “打印颜色失真” 等。
- 广度优先搜索:从
[HP LaserJet Pro MFP M28w]
社区出发,查找与该打印机型号相关的所有常见问题和推荐解决方案。
6. 生成响应:
智能体根据检索到的上下文信息,生成以下响应:
“您好!感谢您的反馈。 了解到您购买的HP LaserJet Pro MFP M28w打印机打印文件出现重影,并且之前尝试过重启打印机,但问题仍然存在。为了更好地解决您的问题,建议您尝试以下步骤:
- 检查墨盒: 确保墨盒安装正确且墨水量充足。
- 清洁打印头: 打印头堵塞可能导致重影,请尝试清洁打印头(具体步骤请参考打印机说明书)。
- 更新驱动: 请前往HP官网下载并安装最新的打印机驱动程序。
如果您尝试以上步骤后问题仍然存在,请提供以下信息,以便我们进一步排查:
- 您使用的操作系统版本?
- 重影问题出现在所有文档还是特定文档?
感谢您的配合!”
7. 知识更新:
如果用户通过更换墨盒解决了问题,智能体会记录 [更换墨盒]
为解决 [打印文件有重影] 问题
的有效解决方案,并更新相关实体和关系的时间戳,以便后续参考。
实验结果与未来展望
Zep 在 LongMemEval 评测中,相比 baseline,使用 gpt-4o 模型时准确率提升了 18.5%,响应延迟降低了 90%。 实验结果证明Zep在记忆准确性、动态更新能力、高效检索、可扩展性等方面具有显著优势。
未来研究方向包括:
- 模型微调:优化知识提取的准确性和效率。
- 领域本体集成:增强对特定领域的理解和推理能力。
- 新基准测试开发:推动记忆系统的发展。
相关项目:Graphiti:动态知识图谱构建和查询工具(具有时间感知的长记忆方案)
摘要
我们介绍了Zep,这是一种新型的智能体记忆层服务,在深度记忆检索(DMR)基准测试中,其性能优于当前最先进的系统MemGPT。此外,Zep在比DMR更全面、更具挑战性的评估中表现出色,这些评估更好地反映了现实世界中的企业用例。尽管现有的基于大型语言模型(LLM)的检索增强生成(RAG)框架仅限于静态文档检索,但企业应用需要从包括持续对话和业务数据在内的多种来源动态集成知识。Zep通过其核心组件Graphiti解决了这一根本限制,Graphiti是一个时序感知知识图谱引擎,它动态地综合了非结构化的对话数据和结构化的业务数据,同时保持了历史关系。在MemGPT团队建立的DMR基准测试中,Zep展示了其卓越的性能(94.8% 对比 93.4%)。除了DMR之外,Zep的能力在更复杂的LongMemEval基准测试中得到了进一步验证,该基准测试通过复杂的时序推理任务更好地反映了企业用例。在这项评估中,Zep在准确性上提高了高达18.5%,同时与基线实现相比,响应延迟减少了90%。这些结果在企业关键任务(如跨会话信息综合和长期上下文维护)中尤为显著,展示了Zep在现实世界应用中的有效性。
1. 引言
近年来,基于Transformer的大型语言模型(LLM)对工业和研究界的影响引起了广泛关注[1]。LLM的一个主要应用是开发基于聊天的智能体。然而,这些智能体的能力受到LLM上下文窗口、有效上下文利用以及在预训练期间获得的知识限制。因此,需要额外的上下文来提供域外(OOD)知识并减少幻觉。
检索增强生成(RAG)已成为LLM应用中的一个关键兴趣领域。RAG利用过去五十年中开创的信息检索(IR)技术[2],为LLM提供必要的领域知识。
当前使用RAG的方法主要集中在广泛的领域知识和相对静态的语料库上,即添加到语料库中的文档内容很少改变。为了使智能体在我们的日常生活中普及,自主解决从琐碎到高度复杂的问题,它们将需要访问一个不断发展的、庞大的数据语料库,这些数据来自用户与智能体的交互,以及相关的业务和世界数据。我们认为,赋予智能体这种广泛而动态的“记忆”是实现这一愿景的关键组成部分,并且我们认为当前的RAG方法不适合这一未来。由于整个对话历史、业务数据集和其他特定领域的内容无法有效地适应LLM的上下文窗口,因此需要为智能体记忆开发新的方法。在LLM驱动的智能体中添加记忆并不是一个新想法——这个概念之前在MemGPT[3]中已经探索过。
最近,知识图谱(KG)被用来增强RAG架构,以解决传统IR技术的许多缺点[4]。在本文中,我们介绍了Zep[5],这是一个由Graphiti[6]驱动的记忆层服务,Graphiti是一个动态的、时序感知知识图谱引擎。Zep摄取并综合了非结构化的消息数据和结构化的业务数据。Graphiti KG引擎以非丢失的方式动态更新知识图谱,保留了事实和关系的时间线,包括它们的有效期。这种方法使得知识图谱能够代表一个复杂、不断发展的世界。
由于Zep是一个生产系统,我们非常重视其记忆检索机制的准确性、延迟和可扩展性。我们使用两个现有的基准测试来评估这些机制的有效性:MemGPT[3]的深度记忆检索任务(DMR)以及LongMemEval基准测试[7]。
2. 知识图谱构建
在Zep中,记忆由一个时序感知动态知识图谱 G = (N,E,ϕ)
提供支持,其中 N 表示节点,E 表示边,ϕ:E→N×N 表示一个形式化的关联函数。这个图谱包含三个层次化的子图:情节子图、语义实体子图和社区子图。• 情节子图 Ge
:情节节点(情节),ni ∈Ne
,包含原始输入数据,形式为消息、文本或JSON。情节作为一个非丢失的数据存储,从中提取语义实体和关系。情节边,ei∈Ee⊆ϕ∗(Ne×Ns) ,将情节与其引用的语义实体连接起来。• 语义实体子图 Gs
:语义实体子图建立在情节子图之上。实体节点(实体),ni∈Ns
,代表从情节中提取并与现有图谱实体解析的实体。实体边(语义边),ei ∈ Es ⊆ ϕ∗(Ns × Ns) ,代表从情节中提取的实体之间的关系。• 社区子图 Gc
:社区子图构成了Zep知识图谱的最高层。社区节点(社区),ni∈Nc
,代表强连接的实体集群。社区包含这些集群的高级摘要,并代表了 Gs 结构的更全面、相互关联的视图。社区边,ei∈Ec⊆ϕ∗(Nc×Nˉs) ,将社区与其实体成员连接起来。原始情节数据和派生语义实体信息的双重存储反映了人类记忆的心理模型。这些模型区分了代表不同事件的情节记忆和捕捉概念之间关联及其含义的语义记忆[8]。这种方法使得使用Zep的LLM智能体能够发展出更复杂、更细腻的记忆结构,更好地与我们对人类记忆系统的理解相一致。知识图谱为表示这些记忆结构提供了一个有效的媒介,我们实现的不同的情节和语义子图借鉴了AriGraph[9]中的类似方法。
我们使用社区节点来表示高级结构和领域概念,建立在GraphRAG[4]的工作基础上,使得对领域的更全面的全局理解成为可能。由此产生的分层组织——从情节到事实到实体到社区——扩展了现有的分层RAG策略[10][11]。
2.1 情节
Zep的图谱构建从摄取称为情节的原始数据单元开始。情节可以是三种核心类型之一:消息、文本或JSON。虽然每种类型在图谱构建过程中都需要特定的处理,但本文侧重于消息类型,因为我们的实验集中在对话记忆上。在我们的上下文中,一条消息包括相对较短的文本(几条消息可以适应LLM的上下文窗口)以及产生话语的关联参与者。
每条消息都包括一个参考时间戳 tref
,指示消息发送的时间。这种时间信息使Zep能够准确识别并提取消息内容中提到的相对或部分日期(例如,“下周四”、“两周后”或“去年夏天”)。Zep实现了一个双时间模型,其中时间线 T 代表事件的时序排序,时间线 T′ 代表Zep数据摄取的时序事务。虽然 T′ 时间线服务于数据库审计的传统目的,但 T 时间线提供了一个额外的维度,用于模拟对话数据和记忆的动态性。这种双时间方法代表了LLM知识图谱构建中的一个新颖进展,并且是Zep与以前的基于图的RAG提案相比的独特能力的基础。情节边 Ee
将情节与其提取的实体节点连接起来。情节及其派生的语义边维护双向索引,跟踪边与其源情节之间的关系。这种设计通过实现前向和后向遍历,加强了Graphiti情节子图的无损性质:语义工件可以追溯到它们的来源以进行引用或引用,而情节可以快速检索其相关实体和事实。虽然这些连接在本论文的实验中并未直接检查,但它们将在未来的工作中进行探索。2.2 语义实体和事实
2.2.1 实体
实体提取代表了情节处理的初始阶段。在摄取过程中,系统处理当前消息内容和最后 n
条消息,以提供命名实体识别的上下文。对于本文和Zep的一般实现,n=4 ,提供了两个完整的对话回合以进行上下文评估。鉴于我们专注于消息处理,说话者自动被提取为一个实体。在初始实体提取之后,我们采用了一种受反思[12]启发的反射技术,以最小化幻觉并增强提取覆盖范围。该系统还从情节中提取实体摘要,以促进后续的实体解析和检索操作。在提取之后,系统将每个实体名称嵌入到1024维向量空间中。这种嵌入使得通过余弦相似性搜索现有图谱实体节点来检索相似节点成为可能。该系统还在现有实体名称和摘要上执行单独的全文搜索,以识别额外的候选节点。这些候选节点与情节上下文一起,然后通过LLM使用我们的实体解析提示进行处理。当系统识别出重复实体时,它会生成一个更新的名称和摘要。
在实体提取和解析之后,系统使用预定义的Cypher查询将数据整合到知识图谱中。我们选择了这种方法而不是LLM生成的数据库查询,以确保一致的架构格式并减少产生幻觉的可能性。
在附录中提供了用于图谱构建的选定提示。
2.2.2 事实
对于每个包含其关键谓词的事实。同样,同一个事实可以在不同实体之间多次提取,使Graphiti能够通过实现超边来模拟复杂的多实体事实。
在提取之后,系统为事实生成嵌入,为图谱集成做准备。该系统通过类似于实体解析的过程执行边去重。混合搜索相关的边被限制在与新边相同的实体对之间存在的边。这种限制不仅防止了不同实体之间类似边的错误组合,而且通过将搜索空间限制在与特定实体对相关的边的子集上,显著降低了去重的计算复杂度。
2.2.3 时间提取和边失效
与其它知识图谱引擎相比,Graphiti的一个关键区别特征是它能够通过时间提取和边失效过程来管理动态信息更新。
该系统使用 tref
从情节上下文中提取关于事实的时间信息。这使得准确提取和日期时间表示绝对时间戳(例如,“艾伦·图灵出生于1912年6月23日”)和相对时间戳(例如,“我两周前开始了我新的工作”)成为可能。与我们的一致性建模方法一致,该系统跟踪四个时间戳:t′ 创建和 t′ 到期 ∈T′ 监控何时在系统中创建或失效事实,而 tvalid 和 tinvalid∈T 跟踪事实成立的时间范围。这些时间数据点与其它事实信息一起存储在边上。新边的引入可以使数据库中的现有边失效。该系统采用LLM将新边与语义相关的现有边进行比较,以识别潜在的矛盾。当系统识别出时间上的冲突矛盾时,它通过将 tinvalid
设置为失效边的 tvalid 来使受影响的边失效。根据事务时间线 T′ ,Graphiti在确定边失效时始终优先考虑新信息。这种全面的方法使得数据能够随着对话的演变动态地添加到Graphiti中,同时保持当前的关系状态和随时间演变的关系的历史记录。
2.3 社区
在建立了情节和语义子图之后,系统通过社区检测构建社区子图。虽然我们的社区检测方法建立在GraphRAG[4]中描述的技术基础上,但我们采用了标签传播算法[13]而不是莱顿算法[14]。这种选择受到标签传播的简单动态扩展的影响,使得系统能够在新数据进入图谱时,保持准确的社区表示更长的时间,推迟了完全社区刷新的需要。
动态扩展实现了标签传播中单个递归步骤的逻辑。当系统向图谱中添加新的实体节点 ni ∈ Ns
时,它会调查邻近节点的社区。系统将新节点分配给其多数邻居持有的社区,然后相应地更新社区摘要和图谱。虽然这种动态更新使得数据流入系统时社区扩展效率高,但结果社区逐渐偏离完整标签传播运行所生成的社区。因此,定期的社区刷新仍然是必要的。然而,这种动态更新策略提供了一个实用的启发式方法,显著减少了延迟和LLM推理成本。遵循[4],我们的社区节点包含通过迭代的map-reduce风格的成员节点摘要。然而,我们的检索方法与GraphRAG的map-reduce方法[4]大相径庭。为了支持我们的检索方法,我们生成了包含社区摘要中的关键术语和相关主题的社区名称。这些名称被嵌入并存储,以启用余弦相似性搜索。
3. 记忆检索
Zep中的记忆检索系统提供了强大、复杂且高度可配置的功能。总体而言,Zep图搜索API实现了一个函数 f:S→S
,它接受一个文本字符串查询 α∈S 作为输入,并返回一个文本字符串上下文 β∈S 作为输出。输出 β 包含格式化数据,这些数据来自节点和边,是LLM智能体生成对查询 α 的准确响应所需的。过程 f(α)→β 包括三个不同的步骤:• 搜索 (φ)
:该过程首先识别可能包含相关信息的候选节点和边。虽然Zep采用了多种不同的搜索方法,但整体搜索函数可以表示为 φ:S→Esn−×Nsnˉ×.Ncn 。因此,φ 将查询转换为包含语义边、实体节点和社区节点列表的3元组——这三种图类型包含相关的文本信息。• 重排序器 (ρ)
:第二步对搜索结果进行重新排序。重排序器函数或模型接受一个搜索结果列表,并生成这些结果的重新排序版本:ρ:φ(α),…→Esn×Nsn×Ncn 。• 构建器 (χ)
:最后一步,构建器将相关节点和边转换为文本上下文:χ:Esn×Nsn×Ncn→S 。对于每个 ei∈Es ,χ 返回事实和 tvalid ,tinvalid 字段;对于每个 ni∈Ns ,返回名称和摘要字段;以及对于每个 ni∈Nc ,返回摘要字段。有了这些定义,我们可以将 f
表示为这三个组件的组合:f(α) = χ(ρ(φ(α)))=β 。示例上下文字符串模板:
事实和实体 代表与当前对话相关的上下文。 这些是最相关的事实及其有效日期范围。 如果该事实是关于一个事件,那么该事件发生在此期间。 格式:事实(日期范围:从 - 到) <事实> {事实} </事实> 这些是最相关的实体 实体名称:实体摘要 <实体> {实体} </实体>
3.1 搜索
Zep实现了三种搜索功能:余弦语义相似性搜索 (φcos)
、Okapi BM25全文搜索 (φbm25) 和广度优先搜索 (φbfs) 。前两种功能利用了Neo4j对Lucene的实现[15][16]。每种搜索功能在识别相关文档方面提供了不同的能力,并且它们一起在重新排序之前提供了候选结果的全面覆盖。搜索字段在三个对象类型之间有所不同:对于 Es ,我们搜索事实字段;对于 Ns ,搜索实体名称;对于 Nc ,搜索社区名称,其中包括社区中涵盖的相关关键词和短语。虽然是独立开发的,但我们的社区搜索方法与LightRAG[17]的高级关键搜索方法相平行。将LightRAG的方法与Graphiti等基于图的系统相结合,为未来的研究提供了一个有希望的方向。虽然余弦相似性和全文搜索方法在RAG[18]中已经确立,但知识图谱上的广度优先搜索在RAG领域获得的关注有限,在基于图的RAG系统(如AriGraph[9]和Distill-SynthKG[19])中有显著的例外。在Graphiti中,广度优先搜索通过识别 n
跳内的额外节点和边来增强初始搜索结果。此外,φbfs 可以接受节点作为搜索参数,从而对搜索功能提供更大的控制。当使用最近的剧集作为广度优先搜索的种子时,此功能证明特别有价值,允许系统将最近提到的实体和关系纳入检索到的上下文。这三种搜索方法各自针对相似性的不同方面:全文搜索识别单词相似性,余弦相似性捕捉语义相似性,而广度优先搜索揭示了上下文相似性——在图中更近的节点和边出现在更相似的对话上下文中。这种多方面的候选结果识别方法最大限度地提高了发现最佳上下文的可能性。
3.2 重排序器
虽然初始搜索方法旨在实现高召回率,但重排序器通过优先考虑最相关的结果来提高精确度。Zep支持现有的重排序方法,如互易排名融合(RRF)[20]和最大边际相关性(MMR)[21]。此外,Zep实现了一个基于图的剧集提及重排序器,该重排序器根据实体或事实在对话中提及的频率来优先考虑结果,使得经常引用的信息更容易访问。该系统还包括一个节点距离重排序器,根据其与指定中心节点的距离重新排序结果,提供定位到知识图谱特定区域的上下文。该系统最复杂的重排序能力采用交叉编码器——通过使用交叉注意力将节点和边与查询进行评估的LLM生成相关性分数,尽管这种方法会产生最高的计算成本。
4. 实验
本节分析了使用基于LLM记忆的基准测试进行的两个实验。第一个评估采用[3]中开发的深度记忆检索(DMR)任务,该任务使用“超越金鱼记忆:长期开放域对话”[22]中引入的多会话聊天数据集的500个对话子集。第二个评估利用“LongMemEval:对聊天助手在长期交互记忆上的基准测试”[7]中的LongMemEval基准测试。具体来说,我们使用LongMemEval ⋅
数据集,该数据集提供了平均长度为115,000个token的广泛对话上下文。对于这两个实验,我们通过Zep的API将对话历史整合到Zep知识图谱中。然后,我们使用第3节中描述的技术检索20个最相关的边(事实)和实体节点(实体摘要)。系统将此数据重新格式化为上下文字符串,与Zep的记忆API提供的功能相匹配。
虽然这些实验展示了Graphiti的关键检索能力,但它们代表了系统完整搜索功能的一个子集。这种专注的范围使得与现有基准测试的清晰比较成为可能,同时保留了探索知识图谱的额外能力以备将来工作。
4.1 模型的选择
我们的实验实现采用BAAI的BGE-m3模型进行重排序和嵌入任务[23][24]。对于图谱构建和响应生成,我们使用gpt-4o-mini-2024-07-18进行图谱构建,并使用gpt-4o-mini-2024-07-18和gpt-4o-2024-11-20进行聊天智能体生成对提供的上下文的响应。
为了确保与MemGPT的DMR结果直接可比,我们也使用gpt-4-turbo-2024-04-09进行了DMR评估。
实验笔记本将通过我们的GitHub仓库公开发布,并在附录中包含相关的实验提示。
表1:深度记忆检索
记忆 | 模型 | 分数 |
---|---|---|
递归摘要 | 对话摘要 | MemGPT† |
Zep | 对话摘要 | gpt-4-turbo |
全对话 | Zep | gpt-4o-mini |
† 结果在[3]中报告。
4.2 深度记忆检索(DMR)
深度记忆检索评估由[3]引入,包括500个多会话对话,每个对话包含5个聊天会话,每个会话最多12条消息。每条对话包括一个用于记忆评估的问答对。MemGPT框架[3]目前以93.4%的准确率领先性能指标,使用gpt-4-turbo,比递归摘要的35.3%的基线有显著提高。
为了建立比较基线,我们实现了两种常见的LLM记忆方法:全对话上下文和会话摘要。使用gpt-4-turbo,全对话基线达到了94.4%的准确率,略高于MemGPT报告的结果,而会话摘要基线达到了78.6%。当使用gpt-4o-mini时,这两种方法都显示出改进的性能:全对话为98.0%,会话摘要为88.0%。由于在其发表的工作中缺乏足够的方法细节,我们无法使用gpt-4o-mini重现MemGPT的结果。
然后,我们通过摄取对话并使用其搜索功能来检索前10个最相关的节点和边来评估Zep的性能。LLM法官将智能体的响应与提供的正确答案进行比较。Zep在使用gpt-4-turbo时达到了94.8%的准确率,使用gpt-4o-mini时达到了98.2%,显示出对MemGPT和相应的全对话基线的边际改进。然而,这些结果必须放在上下文中:每条对话只包含60条消息,很容易适应当前的LLM上下文窗口。
DMR评估的局限性不仅仅在于其规模小。我们的分析揭示了该基准测试设计上的重大弱点。该评估完全依赖于单回合、事实检索问题,无法评估复杂的记忆理解。许多问题包含模糊的措辞,引用了像“最喜爱的放松饮料”或“奇怪的爱好”这样的概念,这些概念在对话中并未明确地这样描述。最关键的是,数据集对LLM智能体的现实企业用例表现不佳。使用现代LLM的简单全上下文方法取得的较高性能进一步凸显了该基准测试在评估记忆系统方面的不足。
这一不足在[7]中的发现中进一步强调,该发现表明,随着对话长度的增加,LLM在LongMemEval基准测试上的性能迅速下降。LongMemEval数据集[7]通过提供更长、更连贯的对话,更好地反映了企业场景,以及更多样化的评估问题,解决了这些缺点。
4.3 LongMemEval(LME)
我们使用LongMemEvals数据集评估了Zep,该数据集提供了代表现实世界企业应用中LLM智能体的对话和问题。LongMemEvals数据集对现有的LLM和商业记忆解决方案[7]提出了重大挑战,对话的平均长度约为115,000个token。这个长度虽然相当大,但仍然在当前前沿模型的上下文窗口内,使我们能够建立有意义的基线来评估Zep的性能。
数据集包含了六种不同的问题类型:单会话用户、单会话助手、单会话偏好、多会话、知识更新和时序推理。这些类别在数据集中并非均匀分布;有关详细信息,我们建议读者参阅[7]。
我们在2024年12月至2025年1月期间进行了所有实验。我们在马萨诸塞州波士顿的住宅地点使用消费类笔记本电脑连接到Zep的服务,该服务托管在AWS us-west-2中。这种分布式架构在评估Zep的性能时引入了额外的网络延迟,尽管在我们的基线评估中不存在这种延迟。
对于答案评估,我们使用GPT-4o,并提供了[7]中提供的特定于问题的提示,这些提示已证明与人类评估者高度相关。
4.3.1 LongMemEval和MemGPT
为了在Zep和当前最先进的MemGPT系统[3]之间建立比较基准,我们尝试使用LongMemEval数据集评估MemGPT。鉴于当前MemGPT框架不支持直接摄取现有的消息历史,我们通过将对话消息添加到档案历史中实施了解决方案。然而,我们无法使用这种方法实现成功的问答。我们期待看到其他研究团队对这一基准测试的评估,因为比较性能数据将有益于LLM记忆系统更广泛的发展。
4.3.2 LongMemEval结果
Zep在与基线相比,在准确性和延迟方面都表现出显著改进。使用gpt-4o-mini,Zep比基线提高了15.2%的准确性,而gpt-4o提高了18.5%。减少的提示大小也导致与基线实现相比,延迟成本显著降低。
表2:LongMemEvals
记忆 | 模型 | 分数 | 延迟 | 延迟 IQR | 平均上下文 Tokens |
---|---|---|---|---|---|
全上下文 | 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 |
全上下文 | 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的gpt-4o-mini在六种类别中的四种中表现出改进,其中在复杂的问类型中改进最大:单会话偏好、多会话和时序推理。当使用gpt-4o时,Zep在知识更新类别中进一步展示了改进的性能,突出了其与更强大的模型配合使用时更有效。然而,可能需要额外的开发来提高不太强大的模型对Zep的时间数据的理解。
表3:LongMemEvals问题类型分解
问题类型 | 模型 | 全上下文 | Zep | 增量 |
---|---|---|---|---|
单会话偏好 | gpt-4o-mini | 30.0% | 53.3% | 77.7%↑ |
单会话助手 | gpt-4o-mini | 81.8% | 75.0% | 90'6%↑ |
时序推理 | gpt-4o-mini | 36.5% | 54.1% | 48.2%↑ |
多会话 | gpt-4o-mini | 40.6% | 47.4% | 16.7%↑ |
知识更新 | gpt-4o-mini | 76.9% | 74.4% | 3.36%↓ |
单会话用户 | gpt-4o-mini | 81.4% | 92.9% | 14.1%↑ |
单会话偏好 | gpt-4o | 20.0% | 56.7% | 184%↑ |
单会话助手 | gpt-4o | 94.6% | 80.4% | 17.7%↓ |
时序推理 | gpt-4o | 45.1% | 62.4% | 38.4%↑ |
多会话 | gpt-4o | 44.3% | 57.9% | 30.7%↑ |
知识更新 | gpt-4o | 78.2% | 83.3% | 6.52%↑ |
单会话用户 | gpt-4o | 81.4% | 92.9% | 14.1%↑ |
这些结果证明了Zep能够在模型规模上提高性能,与更强大的模型配合使用时,在复杂和细腻的问题类型上观察到最显著的改进。延迟改进尤为显著,Zep将响应时间减少了大约90%,同时保持了更高的准确性。
单会话助手问题的性能下降——gpt-4o为17.7%,gpt-4o-mini为9.06%——代表了Zep在其他方面的一致改进中的一个显著例外,这表明需要进一步的研究和工程工作。
5. 结论
我们已经介绍了Zep,这是一种基于图的LLM记忆方法,它结合了语义和情节记忆以及实体和社区摘要。我们的评估表明,Zep在现有的记忆基准测试中达到了最先进的性能,同时减少了token成本,并在显著降低延迟的情况下运行。
虽然Graphiti和Zep取得的成果令人印象深刻,但可能只是基于图的记忆系统的初步进展。多条研究途径可以建立在这两个框架之上,包括将其他GraphRAG方法整合到Zep范式中,以及我们工作的新颖扩展。
研究已经证明了在GraphRAG范式中针对LLM实体和边提取进行微调模型的价值,提高了准确性,同时减少了成本和延迟[19][25]。类似地,针对Graphiti提示的微调模型可能会增强知识提取,特别是对于复杂的对话。此外,尽管当前关于LLM生成的知识图谱的研究主要在没有正式本体的情况下运行[9][4][17][19][26],特定领域的本体具有重大潜力。图本体,在预LLM知识图谱工作中是基础,值得在Graphiti框架中进一步探索。
我们对合适的记忆基准测试的搜索揭示了有限的选择,现有的基准测试通常缺乏稳健性和复杂性,通常默认为简单的寻针式事实检索问题[3]。该领域需要额外的记忆基准测试,特别是那些反映客户体验任务等商业应用,以有效地评估和区分记忆方法。值得注意的是,现有的基准测试不足以评估Zep处理和综合对话历史与结构化业务数据的能力。虽然Zep专注于LLM记忆,但其传统的RAG能力应与[17]、[27]和[28]中的既定基准测试进行评估。
当前关于LLM记忆和RAG系统的文献中,尚未充分解决生产系统的可扩展性,包括成本和延迟。我们包括了检索机制的延迟基准测试,以开始解决这一差距,遵循LightRAG的作者在优先考虑这些指标方面的例子。
6. 附录
6.1 图谱构建提示
6.1.1 实体提取
{当前_消息} </当前消息> 根据以上对话,从“当前消息”中提取明确或隐含提及的实体节点: 准则: 1.始终提取说话者/演员作为第一个节点。说话者是每行对话中冒号前的部分。 2.提取“当前消息”中提及的其他重要实体、概念或演员。 3.不要为关系或动作创建节点。 4.不要为时间信息(如日期、时间或年份)创建节点(这些将在稍后添加到边缘)。 5.在节点命名时尽可能明确,使用全名。 6.不要仅提取提及的实体
6.1.2 实体解析
<之前的消息> {之前的消息} </之前的消息> <当前消息> {当前消息} </当前消息> <现有节点> {现有节点} </现有节点> 给定上述的现有节点、消息和之前的消息。确定从对话中提取的新节点是否是现有节点中的重复实体。 <新节点> {新节点} </新节点> 任务: 1. 如果新节点与现有节点中的任何节点表示相同的实体,则在响应中返回“is_duplicate: true”。否则,返回“is_duplicate: false”。 2. 如果 is_duplicate 为 true,则在响应中同时返回现有节点的 uuid。 3. 如果 is_duplicate 为 true,则返回节点的最完整的全名。 指南: 1. 使用节点的名称和摘要来确定实体是否重复,重复节点可能具有不同的名称。
6.1.3 事实提取
<之前的消息> {之前的消息} </之前的消息> <当前消息> {当前消息} </当前消息> <实体> {实体} </实体> 给定上述消息和实体,从当前消息中提取所有与列出的实体相关的要素。 指南: 1. 仅提取所提供的实体之间的事实。 2. 每个事实应表示两个不同节点之间的清晰关系。 3. relation_type 应该是对事实的简洁、全大写描述(例如,LOVES、IS_FRIENDS_WITH、 WORKS_FOR)。 4. 提供包含所有相关信息的更详细的事实。 5. 考虑关系的时间方面(如果相关)。
6.1.4 事实解析
给定以下上下文,判断 "新边" 是否表示 "现有边" 列表中任何一条边所表达的相同信息。 <现有边> {existing_edges} </现有边> <新边> {new_edge} </新边> 任务: 如果 "新边" 表示与 "现有边" 中任何一条边相同的事实信息,则在响应中返回 'is_duplicate: true'。 否则,返回 'is_duplicate: false'。 如果 is_duplicate 为 true,则还在响应中返回现有边的 uuid。 指南: 事实信息不需要完全相同才能判定为重复,它们只需要表达相同的信息即可。
6.1.5 时间提取
<先前消息> {先前的消息} </先前消息> <当前消息> {当前消息} </当前消息> <参考时间戳> {参考时间戳} </参考时间戳> <事实> {事实} </事实> 重要提示:仅在提供的事实中包含时间信息时才提取时间信息,否则忽略提及的时间。 如果仅提到了相对时间(例如“10年前”、“2分钟前”),请尽力基于提供的参考时间戳确定具体日期。 如果关系不是跨越性的,但仍然可以确定日期,则仅设置 `valid_at`。 定义: - valid_at:该事实描述的关系变为真实或被建立的日期和时间。 - invalid_at:该事实描述的关系不再真实或结束的日期和时间。 任务: 分析对话并确定事实中是否包含日期信息。仅在日期明确与关系的建立或变更相关时才进行设置。 指南: 1. 使用 ISO 8601 格式(YYYY-MM-DDTHH:MM:SS.SSSSSSZ)表示日期时间。 2. 计算 `valid_at` 和 `invalid_at` 时,以参考时间戳作为当前时间。 3. 如果事实使用现在时态,则使用参考时间戳作为 `valid_at` 日期。 4. 如果没有找到能确立或更改关系的时间信息,则将字段设为 null。 5. 不得 从相关事件推断日期,仅使用直接用于确立或更改关系的日期。 6. 如果提及的相对时间直接与关系相关,则基于参考时间戳计算实际日期时间。 7. 如果只提到了日期但未指定时间,则默认使用 00:00:00(午夜)。 8. 如果仅提到了年份,则使用该年 1月1日 00:00:00。 9. 始终包括时区偏移量(如果未指定具体时区,则使用 Z 表示 UTC)。