GEO

Mastra如何通过LongMemEval实现80%的智能体记忆准确率?

2026/4/18
Mastra如何通过LongMemEval实现80%的智能体记忆准确率?

AI Summary (BLUF)

Mastra implemented the LongMemEval benchmark to improve agent memory, achieving 80% accuracy through iterative optimizations including tailored templates, smarter memory updates, and better formatting - demonstrating RAG's continued effectiveness for agent memory.

原文翻译: Mastra通过实施LongMemEval基准测试来改进智能体记忆,通过定制模板、更智能的内存更新和更好的格式化等迭代优化,实现了80%的准确率,证明了RAG在智能体记忆中的持续有效性。

在 Mastra,我们最近实施了 LongMemEval 基准测试,旨在显著提升长期记忆(语义召回)和工作记忆的性能。

在 Mastra,我们最近实施了 LongMemEval 基准测试,旨在显著提升长期记忆(语义召回)和工作记忆的性能。

通过我们推出的改进,我们达到了最先进的性能(80%),并实现了一系列优化,这些优化已被集成到内存的 vNext 版本中。

通过我们推出的改进,我们达到了最先进的性能(80%),并实现了一系列优化,这些优化已被集成到内存的 vNext 版本中。

同时,我们(意外地)花费了 8000 美元并消耗了数十亿个令牌来运行这个基准测试。

同时,我们(意外地)花费了 8000 美元并消耗了数十亿个令牌来运行这个基准测试。

让我们深入探讨。

让我们深入探讨。

背景故事

我们最近注意到 Mastra 内存缺少一个关键部分:大规模的系统性评估。

我们最近注意到 Mastra 内存缺少一个关键部分:大规模的系统性评估。

当我们将“工作记忆”功能从系统提示词移至用户消息时,警钟敲响了。这一改动看似合理,但我们后来发现这个“修复”带来了新的问题。

当我们将“工作记忆”功能从系统提示词移至用户消息时,警钟敲响了。这一改动看似合理,但我们后来发现这个“修复”带来了新的问题。

智能体有时会随机陷入循环,多次调用工具,或者更糟的是,它们会直接响应被注入的记忆,仿佛那是用户消息。

智能体有时会随机陷入循环,多次调用工具,或者更糟的是,它们会直接响应被注入的记忆,仿佛那是用户消息。

在推出更多修复之前,我们意识到需要一种方法来明确衡量新改动是否真正提高了记忆的准确性。

在推出更多修复之前,我们意识到需要一种方法来明确衡量新改动是否真正提高了记忆的准确性。

引入 LongMemEval

LongMemEval 是一个基准测试,旨在评估 AI 系统如何处理跨多个对话的长期记忆。

LongMemEval 是一个基准测试,旨在评估 AI 系统如何处理跨多个对话的长期记忆。

该基准数据集包含 500 个问题,每个问题关联着大约 50 个独特的对话,其中一个(或多个)对话包含了问题的答案。

该基准数据集包含 500 个问题,每个问题关联着大约 50 个独特的对话,其中一个(或多个)对话包含了问题的答案。

像 Zep 这样的其他公司已经发布了他们的 LongMemEval 结果。

像 Zep 这样的其他公司已经发布了他们的 LongMemEval 结果。

其中一家(Zep)甚至声称开发者应该“停止将 RAG 用于智能体记忆”(剧透:我们的结果恰恰相反)。事实上,我们使用通用框架得到的结果比他们的更好:80% 的准确率对比 72%。

其中一家(Zep)甚至声称开发者应该“停止将 RAG 用于智能体记忆”(剧透:我们的结果恰恰相反)。事实上,我们使用通用框架得到的结果比他们的更好:80% 的准确率对比 72%。

迭代 0:初始结果

回顾一下,Mastra 有两个主要的内存功能:工作记忆,用于记住用户的特征,如姓名、年龄和偏好;以及语义召回,这是一个基于 RAG 的功能,我们将聊天历史存储在向量数据库中,然后根据与用户查询的语义相似性检索消息。

回顾一下,Mastra 有两个主要的内存功能:工作记忆,用于记住用户的特征,如姓名、年龄和偏好;以及语义召回,这是一个基于 RAG 的功能,我们将聊天历史存储在向量数据库中,然后根据与用户查询的语义相似性检索消息。

使用这些功能的初始结果……令人失望:

使用这些功能的初始结果……令人失望:

  • 工作记忆:20% 准确率 (Working memory alone: 20% accuracy)
  • 语义召回:65% 准确率 (Semantic recall: 65% accuracy)
  • 组合使用:67% 准确率 (Combined: 67% accuracy)

迭代 1:定制化模板

在思考这个问题时,我们意识到工作记忆的设计初衷是跟踪特定于应用程序的信息。在我们的基准测试中,我们使用的是通用工作记忆模板——这并非该功能的设计使用方式。我需要知道:通用模板是否是长期工作记忆表现如此糟糕的原因?

在思考这个问题时,我们意识到工作记忆的设计初衷是跟踪特定于应用程序的信息。在我们的基准测试中,我们使用的是通用工作记忆模板——这并非该功能的设计使用方式。我需要知道:通用模板是否是长期工作记忆表现如此糟糕的原因?

为了测试这一点,我们在列表中增加了两个新的基准测试配置:

为了测试这一点,我们在列表中增加了两个新的基准测试配置:

  1. 定制化工作记忆 - 为每个基准问题定制的模板 (Working Memory Tailored - Custom templates for each benchmark question)
  2. 组合定制化 - 语义召回 + 使用定制模板的工作记忆 (Combined Tailored - Semantic recall + working memory with custom templates)

我们编写了一个脚本,为基准测试中的每种问题类型生成定制模板,将问题(而非答案)输入 LLM,并要求它输出一个用于跟踪此类信息的模板。我们的意图是模拟开发者为其特定用例(例如,一个被告知要跟踪食物摄入、锻炼偏好等的健身助手)精心设计模板。

我们编写了一个脚本,为基准测试中的每种问题类型生成定制模板,将问题(而非答案)输入 LLM,并要求它输出一个用于跟踪此类信息的模板。我们的意图是模拟开发者为其特定用例(例如,一个被告知要跟踪食物摄入、锻炼偏好等的健身助手)精心设计模板。

结果:“定制化”工作记忆将得分从 20% 提高到了 35%。进步!

结果:“定制化”工作记忆将得分从 20% 提高到了 35%。进步!

迭代 2:更智能的内存更新(vNext 工具)

这个结果仍然不够好。我们设计工作记忆是为了短期回忆,但在我看来,它在长期回忆方面得分如此之低似乎仍然不对。

这个结果仍然不够好。我们设计工作记忆是为了短期回忆,但在我看来,它在长期回忆方面得分如此之低似乎仍然不对。

当将基准数据摄取到 Mastra 内存时,每个对话都按从最旧到最新的顺序依次处理。这使得智能体能够在每个新对话进展并建立在之前对话的基础上时,逐步构建工作记忆,模拟现实世界中会发生的情况。

当将基准数据摄取到 Mastra 内存时,每个对话都按从最旧到最新的顺序依次处理。这使得智能体能够在每个新对话进展并建立在之前对话的基础上时,逐步构建工作记忆,模拟现实世界中会发生的情况。

我惊讶地发现,当一个对话与之前的对话走向完全不同时,智能体会认为存储的工作记忆不再相关。

我惊讶地发现,当一个对话与之前的对话走向完全不同时,智能体会认为存储的工作记忆不再相关。

为了简单起见,我们设计的工作记忆工具在智能体每次想要添加新信息时,都会替换整个工作记忆数据。在手动测试中它工作正常,但当它需要处理跨越数千条消息的多个对话时,这为 LLM 设置了失败的陷阱。

为了简单起见,我们设计的工作记忆工具在智能体每次想要添加新信息时,都会替换整个工作记忆数据。在手动测试中它工作正常,但当它需要处理跨越数千条消息的多个对话时,这为 LLM 设置了失败的陷阱。

因此,我们为 updateWorkingMemory 工具开发了一个更细粒度的 API,要求提供 updateReason 以及一个可选的 searchString 以进行更有针对性的更新。

因此,我们为 updateWorkingMemory 工具开发了一个更细粒度的 API,要求提供 updateReason 以及一个可选的 searchString 以进行更有针对性的更新。

此外,我们为智能体提供了更精细的指令,只允许在工作记忆不跨越多个对话时进行整体替换。如果智能体试图从之前的对话中移除“不相关”的信息,系统会返回一条消息,解释它只能澄清现有记忆或添加新记忆,并且新数据已被追加。

此外,我们为智能体提供了更精细的指令,只允许在工作记忆不跨越多个对话时进行整体替换。如果智能体试图从之前的对话中移除“不相关”的信息,系统会返回一条消息,解释它只能澄清现有记忆或添加新记忆,并且新数据已被追加。

// 旧方法 - 每次完全替换
updateWorkingMemory({ newMemory: "User likes hiking" });

// vNext 方法 - 上下文感知的更新
updateWorkingMemory({
  newMemory: "User likes hiking",
  updateReason: "append-new-memory", // 或 "clarify-existing-memory" 或 "replace-irrelevant-memory"
  // searchString: "hobbies", // 可选,用于针对性更新
});

结果:使用定制模板的工作记忆达到了 57.34%,与语义召回结合时达到了 72%!

结果:使用定制模板的工作记忆达到了 57.34%,与语义召回结合时达到了 72%!

我们将其作为 vnext 内存发布,您可以在最新的 Mastra 版本中通过以下方式使用:

我们将其作为 vnext 内存发布,您可以在最新的 Mastra 版本中通过以下方式使用:

import { Memory } from "@mastra/memory";

const memory = new Memory({
  provider: myProvider,
  options: {
    lastMessages: 10,
    workingMemory: {
      enabled: true,
      template: `Track user preferences, habits, and key personal details.
Remember: name, occupation, hobbies, dietary preferences, workout routines.`,
      version: "vnext", // 启用改进/实验性工具
    },
  },
});

迭代 3:时间处理是难题

此时,我们与 Zep(在特定内存配置下)持平——这是一个相当不错的结果。然而,在最后一次检查数据时,我们意识到一个特定类别 temporal-reasoning 的得分异常低。

此时,我们与 Zep(在特定内存配置下)持平——这是一个相当不错的结果。然而,在最后一次检查数据时,我们意识到一个特定类别 temporal-reasoning 的得分异常低。

我们开始阅读准备好的数据、问题和答案,发现了两个与时间相关的意外行为:

我们开始阅读准备好的数据、问题和答案,发现了两个与时间相关的意外行为:

  1. 所有消息都以当前时间戳而非基准数据中的原始日期插入内存 (All messages were being inserted in memory with current timestamps instead of their original dates from the benchmark data)
  2. 智能体认为“今天”实际上是我们运行基准测试的时间,而不是使用 LongMemEval 中的 question_date 字段 (The agent thought "today" was actually when we ran the benchmark rather than using the question_date field from LongMemEval)

修复方法包括更正时间戳,以及将问题日期添加到系统提示词中:Today's date is ${question_date}.

修复方法包括更正时间戳,以及将问题日期添加到系统提示词中:Today's date is ${question_date}.

修复这些问题后,组合定制化配置的准确率提升到了 74%。

修复这些问题后,组合定制化配置的准确率提升到了 74%。

迭代 4:更好的格式化带来突破

现在我们非常想知道:如果这个改进如此容易发现/修复,也许还有其他我们忽视的问题。我们的分数还能更高吗?

现在我们非常想知道:如果这个改进如此容易发现/修复,也许还有其他我们忽视的问题。我们的分数还能更高吗?

我们查看了一些失败的基准问题,其中答案在上下文中,LLM 本应知道答案,然后我们开始审视数据结构。

我们查看了一些失败的基准问题,其中答案在上下文中,LLM 本应知道答案,然后我们开始审视数据结构。

被召回的消息以按日期排序的扁平列表形式呈现给 LLM,没有额外的注释上下文。

被召回的消息以按日期排序的扁平列表形式呈现给 LLM,没有额外的注释上下文。

希望我们能帮助 LLM 更好地进行时间推理,我们将语义召回的消息格式重构为:

希望我们能帮助 LLM 更好地进行时间推理,我们将语义召回的消息格式重构为:

  1. 按“年、月、日”分组消息 (Group recalled messages by "Year, Month, Day")
  2. 为每条消息添加时间标签(例如,“下午 2:19”)(Add time labels to each message (e.g., "2:19 PM"))
  3. 澄清每条消息是来自当前对话还是来自之前独立的对话 (Clarify if each message was from the current conversation or from a previous, separate conversation)

那么发生了什么?

那么发生了什么?

结果:RAG 依然非常有效

通过改进的格式化和语义召回的不同 topK 值:

通过改进的格式化和语义召回的不同 topK 值:

  • topK 2: 63.41% (默认设置) (topK 2: 63.41% (default setting))
  • topK 5: 73.98% (topK 5: 73.98%)
  • topK 10: 78.59% (topK 10: 78.59%)
  • topK 20: 80% (topK 20: 80%)

我们仅凭语义召回RAG)就达到了 80% 的准确率——比 Zep 声称 RAG 不适用于智能体记忆的基准高出 8 个百分点!即使在较低的 topK 5 设置下,我们的结果仍然更高,并且是报告的最佳结果之一。

我们仅凭语义召回RAG)就达到了 80% 的准确率——比 Zep 声称 RAG 不适用于智能体记忆的基准高出 8 个百分点!即使在较低的 topK 5 设置下,我们的结果仍然更高,并且是报告的最佳结果之一。

📊 最终基准测试结果

语义召回

配置 知识更新 多会话 单会话-助手 单会话-偏好 单会话-用户 时间推理 整体准确率
topK 2 52.6% 27.1% 96.4% 73.3% 95.7% 35.3% 63.41%
topK 5 75.6% 55.6% 100.0% 56.7% 94.3% 61.7% 73.98%
topK 10 85.9% 71.4% 100.0% 50.0% 94.3% 61.7% 78.59%
topK 20 数据未完全提供 数据未完全提供 数据未完全提供 数据未完全提供 数据未完全提供 数据未完全提供 80.00%

数据集:longmemeval_s | 模型:gpt-4o

数据集:longmemeval_s | 模型:gpt-4o

常见问题(FAQ)

Mastra如何通过LongMemEval基准测试提升智能体记忆性能?

Mastra通过实施LongMemEval基准测试,采用迭代优化策略,包括定制模板、智能内存更新和优化格式化,最终实现了80%的准确率,证明了RAG在智能体记忆中的有效性。

LongMemEval基准测试中,Mastra的迭代优化具体包括哪些步骤?

优化包括:迭代1定制化模板(从20%提升至35%准确率)、迭代2引入vNext工具实现更智能的内存更新、迭代4通过更好的格式化实现突破,最终达到80%的准确率。

Mastra的RAG方法在智能体记忆方面相比其他方案有何优势?

Mastra使用基于RAG语义召回工作记忆组合,在LongMemEval测试中达到80%准确率,优于Zep的72%,反驳了“停止将RAG用于智能体记忆”的观点,展示了RAG的持续有效性。

← 返回文章列表
分享到:微博

版权与免责声明:本文仅用于信息分享与交流,不构成任何形式的法律、投资、医疗或其他专业建议,也不构成对任何结果的承诺或保证。

文中提及的商标、品牌、Logo、产品名称及相关图片/素材,其权利归各自合法权利人所有。本站内容可能基于公开资料整理,亦可能使用 AI 辅助生成或润色;我们尽力确保准确与合规,但不保证完整性、时效性与适用性,请读者自行甄别并以官方信息为准。

若本文内容或素材涉嫌侵权、隐私不当或存在错误,请相关权利人/当事人联系本站,我们将及时核实并采取删除、修正或下架等处理措施。 也请勿在评论或联系信息中提交身份证号、手机号、住址等个人敏感信息。