摘要
我们介绍了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】中已经探索过。
最近,知识图谱(KGs)被用来增强RAG架构,以解决传统IR技术的许多缺点【4】。在本文中,我们介绍了Zep【5】,这是一种由Graphiti【6】提供支持的内存层服务,Graphiti是一个动态的、具有时间感知能力的知识图谱引擎。Zep摄取并综合非结构化的消息数据和结构化的业务数据。Graphiti KG引擎以非丢失的方式动态更新知识图谱中的新信息,维护事实和关系的时间线,包括它们的有效期。这种方法使得知识图谱能够代表一个复杂、不断演变的世界。
由于Zep是一个生产系统,我们非常重视其记忆检索机制的准确性、延迟和可扩展性。我们使用两个现有的基准测试来评估这些机制的有效性:MemGPT【3】中的深度记忆检索任务(DMR)以及LongMemEval基准测试【7】。
2. 知识图谱构建
在Zep中,记忆由一个具有时间感知能力的动态知识图谱 ℊ = (𝓃, ℯ, φ) 提供支持,其中 𝓃 代表节点,ℯ 代表边,φ:ℯ→𝓃×𝓃 代表一个形式化的关联函数。这个图谱包括三个层次化的子图:情节子图、语义实体子图和社区子图。
2.1 情节
Zep的图谱构建从摄取称为情节的原始数据单元开始。情节可以是三种核心类型之一:消息、文本或JSON。尽管每种类型在图谱构建过程中需要特定的处理,但本文重点关注消息类型,因为我们的实验集中在对话记忆上。在我们的上下文中,一条消息包括相对简短的文本(几条消息可以适应LLM的上下文窗口)以及产生该话语的关联参与者。
每条消息都包含一个参考时间戳 tref,指示消息发送的时间。这种时间信息使Zep能够准确识别并提取消息内容中提到的相对或部分日期(例如,“下周四”、“两周后”或“去年夏天”)。Zep实现了一个双时间模型,其中时间线 T 代表事件的时序顺序,时间线 T′ 代表Zep数据摄取的时序顺序。虽然 T′ 时间线服务于数据库审计的传统目的,但 T 时间线提供了一个额外的维度,用于模拟对话数据和记忆的动态特性。这种双时间方法代表了LLM知识图谱构建中的一个新颖进展,并且是Zep与以前的基于图的RAG提案相比的独特能力的基础。
情节边 ℯe 将情节与其提取的实体节点连接起来。情节及其派生的语义边维护双向索引,跟踪边与其源情节之间的关系。这种设计通过实现前向和后向遍历,加强了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】而不是Leiden算法【14】。这种选择受到标签传播的简单动态扩展的影响,该扩展使系统能够在新数据进入图谱时更长时间地保持准确的社区表示,推迟了完全社区刷新的需要。
动态扩展实现了标签传播中单个递归步骤的逻辑。当系统向图谱中添加一个新的实体节点 ni ∈Ns 时,它会调查邻近节点的社区。系统将新节点分配给其多数邻居持有的社区,然后相应地更新社区摘要和图谱。虽然这种动态更新使得社区随着数据流入系统而高效扩展,但由此产生的社区逐渐偏离了通过完整标签传播运行生成的社区。因此,定期的社区刷新仍然是必要的。然而,这种动态更新策略提供了一个实用的启发式方法,显著降低了延迟和LLM推理成本。
继【4】之后,我们的社区节点包含通过迭代的map-reduce风格的成员节点摘要派生的摘要。然而,我们的检索方法与GraphRAG的map-reduce方法【4】大相径庭。为了支持我们的检索方法,我们生成了包含社区摘要中的关键术语和相关主题的社区名称。这些名称被嵌入并存储,以实现余弦相似性搜索。
3. 记忆检索
Zep的记忆检索系统提供了强大、复杂且高度可配置的功能。总体而言,Zep图搜索API实现了一个函数 f:S→S,它接受一个文本字符串查询 α∈S 作为输入,并返回一个文本字符串上下文 β∈S 作为输出。输出 β 包含格式化数据,这些数据来自节点和边,LLM智能体需要这些数据来生成对查询 α 的准确响应。过程 f(α)→β 包括三个不同的步骤:
• 搜索 (φ):该过程首先识别可能包含相关信息的后选节点和边。虽然Zep采用了多种不同的搜索方法,但总体搜索功能可以表示为 φ:S→ℰsn-×𝒩sn.×𝒩cn。因此,φ 将查询转换为一个包含语义边、实体节点和社区节点列表的3元组——这三种图类型包含相关的文本信息。
• 重排序器 (ρ):第二步是对搜索结果进行重新排序。重排序器函数或模型接受一个搜索结果列表,并生成这些结果的重新排序版本:ρ:φ(α),…→ℰsn×𝒩sn×𝒩cn。
• 构建器 (χ):最后一步,构建器将相关节点和边转换为文本上下文:χ:ℰsn×𝒩sn×𝒩cn→S。对于每个 ei∈ℰs,χ 返回事实和 tvalid, tinvalid 字段;对于每个 ni∈𝒩s,返回名称和摘要字段;对于每个 ni∈𝒩c,返回摘要字段。
有了这些定义,我们可以将 f 表示为这三个组件的组合:f(α) = χ(ρ(φ(α))) = β。
样本上下文字符串模板:
FACTS 和 ENTITIES 表示与当前对话相关的上下文信息。
以下是最相关的事实及其有效日期范围。如果该事实与某个事件相关,则表示该事件发生在这个时间范围内。
格式:FACT(日期范围:from - to)
<FACTS>
{facts}
</FACTS>
以下是最相关的实体
ENTITY_NAME:实体简介
<ENTITIES>
{entities}
</ENTITIES>
3.1 搜索
Zep实现了三种搜索功能:余弦语义相似性搜索 (φcos),Okapi BM25全文搜索 (φbm25}) 和广度优先搜索 (φbfs)。前两种功能利用了Neo4j对Lucene【15】【16】的实现。每种搜索功能在识别相关文档方面提供了不同的能力,并且它们共同在重新排序之前提供了全面的候选结果覆盖。搜索字段在不同对象类型之间有所不同:对于 𝒜s,我们搜索事实字段;对于 𝒩s,搜索实体名称;对于 𝒩c,搜索社区名称,其中包括社区中涵盖的相关关键词和短语。虽然我们的社区搜索方法独立开发,但它与LightRAG【17】的高层关键搜索方法并行。将LightRAG的方法与Graphiti等基于图的系统相结合,为未来的研究提供了一个有前途的方向。
虽然余弦相似性和全文搜索方法在RAG【18】中已经确立,但知识图谱上的广度优先搜索在RAG领域获得的关注有限,在基于图的RAG系统中如AriGraph【9】和Distill-SynthKG【19】有显著的例外。在Graphiti中,广度优先搜索通过识别 n 跳内的额外节点和边来增强初始搜索结果。此外,φbfs 可以接受节点作为搜索参数,允许对搜索功能进行更精细的控制。当使用最近的剧集作为广度优先搜索的种子时,此功能证明特别有价值,允许系统将最近提到的实体和关系合并到检索的上下文中。
这三种搜索方法各自针对相似性的不同方面:全文搜索识别单词相似性,余弦相似性捕捉语义相似性,广度优先搜索揭示上下文相似性——图谱中更近的节点和边出现在更相似的对话上下文中。这种多方面的候选结果识别方法最大限度地提高了发现最佳上下文的可能性。
3.2 重排序器
虽然初始搜索方法旨在实现高召回率,但重排序器通过优先考虑最相关的结果来提高精确度。Zep支持现有的重排序方法,如互易等级融合(RRF)【20】和最大边际相关性(MMR)【21】。此外,Zep实现了一个基于图的剧集提及重排序器,它根据实体或事实提及的频率对结果进行优先排序,使得经常引用的信息更容易访问。该系统还包括一个节点距离重排序器,它根据结果与指定中心节点的距离对结果进行重新排序,提供定位到知识图谱特定区域的内容。该系统最复杂的重排序能力采用交叉编码器——通过使用交叉注意力评估节点和边与查询的相关性生成相关性分数的LLMs,尽管这种方法会产生最高的计算成本。
4. 实验
本节分析了使用基于LLM记忆的基准测试进行的两个实验。第一个评估采用【3】中开发的深度记忆检索(DMR)任务,该任务使用了在“超越金鱼记忆:长期开放域对话”【22】中引入的多会话聊天数据集的500个对话子集。第二个评估使用了【7】中的LongMemEval基准测试。具体来说,我们使用了LongMemEval ċ 数据集,它提供了平均长度为115,000个标记的广泛对话上下文。
对于这两个实验,我们通过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? 全对话 | gpt-4-turbo gpt-4-turbo gpt-4-turbo gpt-4-turbo | 35.3% 78.6% 93.4% 94.4% |
Zep 对话摘要 | gpt-4-turbo gpt-4o-mini | 94.8% |
全对话 Zep | gpt-4o-mini gpt-4o-mini | 88.0% 98.0% 98.2% |
† 结果在【3】中报告。
4.2 深度记忆检索(DMR)
深度记忆检索评估由【3】引入,包括500个多会话对话,每个对话包含5个聊天会话,每个会话最多12条消息。每个对话包括一个用于记忆评估的问题/答案对。MemGPT框架【3】目前以93.4%的准确率领先于性能指标,比递归摘要实现的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个标记。这个长度虽然相当大,但仍在当前前沿模型的上下文窗口内,使我们能够建立有意义的基线来评估Zep的性能。
数据集包含了六种不同的问题类型:单会话用户、单会话助手、单会话偏好、多会话、知识更新和时序推理。这些类别在数据集中的分布并不均匀;有关详细信息,我们建议读者参阅【7】。
我们在2024年12月至2025年1月期间进行了所有实验。我们使用位于马萨诸塞州波士顿的住宅地点的消费类笔记本电脑进行测试,连接到在AWS us-west-2托管的Zep服务。这种分布式架构在评估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 | 平均上下文标记 |
全上下文 | 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-40 | 60.2% | 28.9 s | 6.01 s | 115k |
Zep | gpt-40 | 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-40 | 20.0% | 56.7% | 184%↑ |
单会话助手 | gpt-40 | 94.6% | 80.4% | 17.7%↓ |
时序推理 | gpt-40 | 45.1% | 62.4% | 38.4%个 |
多会话 | gpt-40 | 44.3% | 57.9% | 30.7%↑ |
知识更新 | gpt-40 | 78.2% | 83.3% | 6.52%↑ |
单会话用户 | gpt-40 | 81.4% | 92.9% | 14.1%↑ |
这些结果证明了Zep能够提高跨模型规模的表现,与更有能力的模型配合使用时,在复杂和细腻的问题类型中观察到的改进最为显著。延迟改进尤为显著,Zep将响应时间减少了大约90%,同时保持了更高的准确性。
单会话助手问题的表现下降——gpt-4o下降了17.7%,gpt-4o-mini下降了9.06%——代表了Zep在其他方面的一致改进中的一个显著例外,并表明需要进一步的研究和工程工作。
5. 结论
我们已经介绍了Zep,这是一种基于图的LLM记忆方法,它结合了语义和情节记忆以及实体和社区摘要。我们的评估表明,Zep在现有的记忆基准测试中达到了最先进的性能,同时减少了标记成本,并在显著降低的延迟下运行。
虽然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 实体提取
<之前的消息>
{previous_messages}
</之前的消息>
<当前消息>
{current_message}
</当前消息>
根据上述对话内容,从当前消息(CURRENT MESSAGE)中提取明确或隐含提到的实体节点:
指导原则:
1. 始终将说话者/行动者提取为第一个节点。说话者是每行对话中冒号前的部分。
2. 提取当前消息中提到的其他重要实体、概念或行动者。
3. 不要为关系或行为创建节点。
4. 不要为时间信息(如日期、时间或年份)创建节点(这些信息将在后续作为边添加)。
5. 节点名称尽量具体,使用全称。
6. 不要提取仅在前文中提到的实体。
6.1.2 实体解析
<之前的消息>
{previous_messages}
</之前的消息>
<当前消息>
{current_message}
</当前消息>
<已有节点>
{existing_nodes}
</已有节点>
根据上述已有节点(EXISTING NODES)、消息(MESSAGE)以及之前的消息(PREVIOUS MESSAGES),判断从对话中提取出的新节点(NEW NODE)是否是已有节点中的重复实体。
<新节点>
{new_node}
</新节点>
任务:
1. 如果新节点与已有节点中任意一个代表的是同一个实体,请在回复中返回 `is_duplicate: true`。
否则,返回 `is_duplicate: false`。
2. 如果返回为 is_duplicate: true,还需在回复中返回重复节点的 uuid。
3. 如果返回为 is_duplicate: true,请返回该节点最完整的全名作为名称。
指导原则:
1. 请结合节点的名称和摘要来判断是否为重复实体。重复节点的名称可能不同。
6.1.3 事实提取
<PREVIOUS MESSAGES>
{previous_messages}
</PREVIOUS MESSAGES>
<CURRENT MESSAGE>
{current_message}
</CURRENT MESSAGE>
<ENTITIES>
{entities}
</ENTITIES>
根据以上的消息(MESSAGES)和实体(ENTITIES),从当前消息(CURRENT MESSAGE)中提取所有与列出的实体有关的事实信息。
指南:
1. 仅提取出现在所提供实体之间的事实。
2. 每条事实应代表两个**不同节点**之间的明确关系。
3. relation_type 应为简洁、全大写的关系描述(例如:LOVES、IS_FRIENDS_WITH、WORKS_FOR)。
4. 提供包含所有相关信息的更详细事实描述。
5. 如有必要,考虑关系中的时间要素。
6.1.4 事实解析
根据以下上下文,判断 New Edge 是否与 Existing Edges 列表中的任意一条边表示相同的信息。
<EXISTING EDGES>
{existing_edges}
</EXISTING EDGES>
<NEW EDGE>
{new_edge}
</NEW EDGE>
任务:
1. 如果 New Edge 表达的信息与 Existing Edges 中任意一条边的事实信息相同,请在回复中返回 `is_duplicate: true`;否则返回 `is_duplicate: false`。
2. 如果 `is_duplicate` 为 true,还需在回复中返回该现有边的 uuid。
指导原则:
1. 即使事实信息不完全一致,只要表达的是相同的信息,即可视为重复。
6.1.5 时间提取
<先前消息>
{previous_messages}
</先前消息>
<当前消息>
{current_message}
</当前消息>
<参考时间戳>
{reference_timestamp}
</参考时间戳>
<事实>
{fact}
</事实>
重要提示:仅当时间信息是所提供事实的一部分时才提取时间,否则请忽略提到的时间。
请根据提供的参考时间戳尽可能确定确切日期(例如 “10 年前”“2 分钟前” 这样的相对时间也要换算为确切时间)。
如果关系并非是持续性的,但仍能确定日期,请仅设置 valid_at 字段。
定义:
- valid_at:描述该事实所代表关系首次成立或变为真实的日期时间。
- invalid_at:描述该事实所代表关系不再成立或终止的日期时间。
任务:
分析对话内容,判断是否有与该关系事实相关的日期信息。仅当日期明确涉及关系的建立或变化时才填写。
指南:
1. 使用 ISO 8601 格式(YYYY-MM-DDTHH:MM:SS.SSSSSSZ)表示日期时间。
2. 判断时使用参考时间戳作为当前时间。
3. 如果事实是以现在时表述的,则使用参考时间戳作为 valid_at 日期。
4. 如果没有用于建立或更改关系的时间信息,请将字段留空(null)。
5. 不要根据相关事件推测日期。只使用直接用于建立或更改关系的日期。
6. 如果提到的相对时间与关系直接相关,请根据参考时间戳计算出实际日期时间。
7. 如果只提到了日期而没有具体时间,默认时间为当日 00:00:00(午夜)。
8. 如果只提到了年份,默认时间为该年 1 月 1 日的 00:00:00。
9. 始终包含时区偏移(若未提及具体时区,请使用 Z 表示 UTC)。
参考:
https://arxiv.org/pdf/2501.13956