# 2507.05257_MemoryAgentBench: Evaluating Memory in LLM Agents via Incremental Multi-Turn Interactions * 首页: * PDF: * 引用: 2(2025-08-10) * 组织: 1UC San Diego * GitHub: * HuggingFace: ## 总结 记忆Agent应具备的四种互补能力，是衡量记忆代理性能的核心指标 1. **准确检索**（AR, Accurate Retrieval） 2. **测试时学习**（TTL, Test-Time Learning） 3. **长程理解**（LRU, Long-Range Understanding） 4. **冲突解决**（CR, Conflict Resolution） * 涉及到模型编辑、知识遗忘 贡献 * 数据集 * 新增两个数据集： * EventQA：用于评估准确检索能力。 * FactConsolidation：用于评估冲突解决能力。 * 主要是合成数据 * 语言: 英文 * Framework：提供统一的评估框架 数据集 * AR评测 * RULER-QA * NIAH-MQ * ∞Bench-En.QA * LongMemEval * EventQA(自建) * TTL 评测 * Multi-Class Classification * **数据构造**： * 从不同类别中各抽取几千条句子样本。 * 每种类型的样本都对应一个数字标签（label）。 * 按固定格式组织： ``` {sentence} \n Label: {label} \n ``` * 把所有句子拼成一个**超长的上下文**（long context）。 * 再**打乱顺序**，防止同一类的样本集中在一起（减少位置偏差）。 * **任务要求**： 给模型一个新的输入内容（可能是其中的一句话），模型需要**查找长上下文中的相关信息**并判断它属于哪个类别。 * **评估指标**：**平均准确率（Average Accuracy）**，即预测标签和真实标签的匹配程度。 * Recommendation * 电影推荐对话数据集。 * **数据处理**： * 把原始数据集中很多关于电影推荐的短对话拼接起来。 * 去掉重复对话。 * 形成一个包含 **上千条推荐实例** 的长上下文。 * **任务要求**： 给定一个对话，模型需要 **基于上下文** 推荐 20 部电影。 * **评估指标**： * **Recall@5** = 推荐的前 5 部电影中，与真实答案（ground truth）重合的比例。 * 例如真实答案有 5 部电影，模型的 top-5 里有 3 部是正确的，那么 Recall@5 = 3/5 = 60%。 * LRU 评测 * ∞Bench * 评估指标** * 这个有点特别，不是直接用 F1 分数，而是先检查文本的“流畅度” * 具体步骤: * **Fluency score**（流畅度得分）： * 如果流畅 → 1 * 如果不流畅 → 0 * 用 LLM 来评测是否流畅 * **F1 score**：用于衡量摘要内容与参考摘要的重合程度（通常是词/短语级别）。 * 然后，他们把这两个分数做**点积（dot product）**： * **这样做的意义** * 如果摘要不流畅（fluency = 0），哪怕 F1 很高，最终得分也是 0 → **保证结果既要准确又要通顺**。 * 如果流畅（fluency = 1），那最终分数就是 F1 → **保留了内容重合度的衡量**。 * CR 评测 * MQUAKE * 一个包含 **反事实编辑对（counterfactual edit pairs）** 的数据集 * 反事实编辑对：同一事实的两种不同版本，一个是过时/错误的信息，一个是更新/正确的信息 * 评估任务类型 * SingleHop Editing: 只需要一次推理（单步更新）就能得到答案 * Multi-Hop Editing: 需要多次推理（可能多个事实链）才能得到正确答案 * 评估指标 * 在这些任务中，模型的输出大多是信息实体（如时间、地点、数字、专有名词）。 * 因此，评估时用的是 SubEM（Substring Exact Match）： * SubEM 会检查模型生成的输出中是否包含正确答案的子串， * 这种评估方式比严格的完全匹配（Exact Match）更宽松一些。 ## From Deepseek ### 核心问题 大型语言模型（LLM）智能体（agents）的现有评测基准主要关注推理、规划和执行能力，而另一个关键组件——**记忆能力**（包括信息的记忆、更新和检索）因缺乏针对性评测基准而被忽视。论文将具备记忆机制的智能体称为**记忆智能体（memory agents）**，并指出其四大核心能力： 1. **准确检索**（Accurate Retrieval） 2. **测试时学习**（Test-Time Learning） 3. **长程理解**（Long-Range Understanding） 4. **冲突解决**（Conflict Resolution） 现有数据集要么受限于上下文长度，要么仅针对静态长文本（如书籍问答），无法反映记忆智能体在**多轮交互中逐步积累信息**的动态特性，且未全面覆盖上述四项能力。 ### 研究贡献 1. **提出新评测基准MemoryAgentBench**： - 整合重构的现有数据集与新构建的数据集，系统覆盖四项记忆能力。 - 设计增量式多轮交互任务，模拟真实场景中信息的动态更新与检索。 2. **全面评估现有记忆智能体**： - 测试范围包括：简单上下文窗口模型、检索增强生成（RAG）系统、带外部记忆模块的高级智能体，以及工具集成型智能体。 - 实验结果表明，当前方法均未能完全掌握四项能力，尤其在冲突解决和长程理解上表现不足。 3. **推动研究方向**： - 强调需要开发更全面的记忆机制（如动态更新、冲突消解），以提升LLM智能体的长期交互性能。 ### 意义 该研究填补了LLM智能体记忆能力评测的空白，为未来优化记忆机制（如外部存储、知识更新策略）提供了标准化测试框架，对实现更复杂的自主智能体具有重要意义。 ## Abstract 本研究关注的是**大型语言模型（LLM）智能体**的**记忆能力**。目前，关于LLM智能体的评估基准（benchmark）主要集中在**推理、规划与执行能力**，而另一个关键组成部分——**记忆机制**（包括智能体如何**记忆、更新和检索长期信息**）由于缺乏相关基准，评估不足。 本文将具备记忆机制的智能体称为**memory agents（记忆智能体）**。 ### 核心贡献 作者提出了记忆智能体的**四个核心能力**，重点强调如下： 1. **准确检索（Accurate Retrieval）**：智能体需能够从记忆中准确检索相关信息。 2. **测试时学习（Test-time Learning）**：在测试过程中动态学习并更新记忆内容。 3. **长距离理解（Long-range Understanding）**：理解并整合来自长序列或多次交互的信息。 4. **冲突解决（Conflict Resolution）**：在存在矛盾或不一致信息时，做出合理判断。 ### 现有数据集的不足 当前的数据集存在两个主要问题： - **上下文长度受限**：许多数据集无法处理长序列信息。 - **静态场景为主**：如基于书籍的问答任务，不适用于**交互式、多轮对话**的记忆智能体，后者需要**逐步积累信息**。 此外，**没有现有基准能全面覆盖上述四个记忆能力**。 ### 提出的新基准：MemoryAgentBench 因此，作者提出了一个新的基准——**MemoryAgentBench**，专门设计用于评估记忆智能体。该基准包含： - **已有数据集的重构版本** - **新增构建的数据集** 目标是**系统性地、更具挑战性地测试记忆智能体的质量**。 ### 实验分析 作者对多种记忆智能体进行了测试，包括： - 基于上下文的简单系统 - 增强生成的检索系统（RAG） - 具有外部记忆模块和工具集成的先进系统 实验结果显示：**当前方法在四个记忆能力上均未达到理想水平**，说明需要进一步研究**更全面的记忆机制**，以提升LLM智能体的整体表现。 ## 1 Introduction 本章节主要介绍了研究的背景、当前研究的不足、提出的问题以及本文的主要贡献。内容结构如下： --- ### 1.1 大语言模型代理（LLM Agents）的进展 当前的大语言模型代理已经从最初的聊天机器人发展为能够完成端到端任务的系统。这些系统可以编写软件、控制浏览器，甚至处理多模态输入。像Manus、OWL、OpenHands、Codex等框架在任务解决方面表现出色，尤其在GAIA和SWE-Bench等代理基准测试中取得了最先进的成果。 **重点**：尽管这些代理在推理能力（如规划、工具使用、代码生成）方面得到了充分验证，但关于**记忆能力**（如抽象、存储、更新、检索）的研究仍较为缺乏。 --- ### 1.2 记忆代理（Memory Agents）与现有研究的不足 近年来，研究者提出了多种记忆架构，包括： - **参数化记忆系统**（如 MemoryLLM、SELF-PARAM、M+） - **商业化的记忆解决方案**（如 MemGPT、Mem0、Cognee、Zep） 这些系统采用不同的策略进行信息的存储与检索，但目前缺乏统一的基准来**系统性地评估记忆代理的性能**。 **重点**：本文将**配备了记忆机制的代理称为“Memory Agents”**，其中重点研究使用**文本历史和外部数据库**的代理。相比之下，参数化记忆系统更多停留在学术研究阶段，而商业化系统通常更强大，但往往闭源。 --- ### 1.3 记忆代理的四大核心能力 本文提出了**记忆代理应具备的四种互补能力**，每种能力都对记忆系统的有效性至关重要： 1. **准确检索（Accurate Retrieval）** 能够根据查询提取正确的片段。包括单跳或多跳检索。 2. **部署时学习（Test-Time Learning）** 在部署过程中能够学习新行为或新技能，而无需额外训练。 3. **长期理解（Long-Range Understanding）** 能够处理长文本（≥100k tokens），并回答需要全局理解的问题。 4. **冲突解决（Conflict Resolution）** 当面对矛盾信息时，能够修订、覆盖或删除先前存储的内容。这与模型编辑和知识遗忘任务相关。 **重点**：这四种能力是衡量记忆代理性能的核心指标。 --- ### 1.4 现有记忆评估数据集的局限性 目前已有多个评估语言模型记忆能力的数据集，但它们存在以下问题： - **早期数据集**（如 LOCOMO、LooGLE、LongBench）文本长度较短（约10k~20k tokens），已不足以挑战当前模型。 - **较新的数据集**（如 NovelQA、NOCHA、Loong、∞-Bench）虽然文本更长（约100k~200k tokens），但**主要用于评估长上下文语言模型**，而非记忆代理。 - **根本原因**：**记忆与长上下文存在本质区别**。记忆是对过去信息的压缩和提炼，而非简单存储所有内容。记忆代理通常**逐步处理输入、抽象信息、生成新推理、学习新规则**。因此，一次性提供全部上下文的数据集不适用于评估记忆代理。 **重点**：近期提出的 LongMemEval 虽然通过合成对话逐步注入记忆，但仍存在**主题多样性不足**和**交互模式不真实**的问题。 --- ### 1.5 本文提出的解决方案：MemoryAgentBench 为解决上述问题，本文提出了一个**统一的评估框架 MemoryAgentBench**，专门用于评估记忆代理的多种记忆机制。具体包括： - **数据集**： - 重用并分割现有长上下文数据集，模拟多轮交互。 - 新增两个数据集： - **EventQA**：用于评估**准确检索**能力。 - **FactConsolidation**：用于评估**冲突解决**能力。 - **评估对象**：涵盖： - 当代商业记忆代理（如 Mem0、MemGPT） - 长上下文代理 - RAG（检索增强生成）代理 - **研究目标**： - 探讨长上下文和RAG技术在记忆代理中的迁移效果。 - 比较商业内存代理在不同能力测试下的表现。 **重点**：通过统一的评估协议，MemoryAgentBench 能够在多种代理架构和数据集上提供**对四种核心记忆能力的综合评估**。 --- ### 1.6 本文贡献总结 1. **数据集**：重构现有数据集并创建两个新数据集，构建覆盖四种记忆能力的全面基准。 2. **框架**：提出统一的评估框架，并开源代码和数据集，以促进研究的复现与扩展。 3. **实证研究**：实现多种简单的记忆代理系统，引入商业代理，并在提出的基准上评估其性能。实验结果显示，现有记忆代理在某些任务上表现良好，但在其他方面仍面临显著挑战。 **总结**：本文填补了记忆代理评估的空白，为研究和工业界提供了首个系统性评估记忆能力的基准工具。 ## 2 Related Work ### 2.1 Benchmarks with Long Input 本节回顾了长上下文评估基准的相关研究。早期的长上下文基准包括 **LongBench** 和 **LooGLE**，其平均输入长度分别为约 20k 和 24k tokens。近期的基准（如 **∞-Bench**、**HELMET**、**RULER**、**NOCHA**、**NoLiMa** 和 **LongBench V2**）已将上下文长度扩展到超过 100k tokens，主要用于评估长上下文模型的性能。然而，尽管这些基准具有较大的规模，**它们并未设计用于评估记忆代理（memory agents）**，也没有前人研究将这些基准用于该目的。 最近，**LOCOMO** 和 **LongMemEval** 专为评估记忆代理而设计。尽管这是一项有前景的方向，但 **LOCOMO 的对话长度仍然较短（约 9k tokens）**，而 **LongMemEval 使用的对话是合成生成的，主题多样性有限**，因此对话不够真实，可能无法代表现实场景中的记忆使用案例。 **重点总结：** - 现有长上下文基准主要用于评估模型，而非记忆代理； - 专门用于记忆代理的基准仍处于早期阶段，存在长度或真实性方面的局限。 --- ### 2.2 Agents with Memory Mechanisms 近期，研究者对具备记忆机制的智能体（memory agents）越来越感兴趣。随着大语言模型（LLMs）处理长上下文能力的提升（如支持 100K～1M tokens），**直接在上下文中存储信息成为一种简单有效的记忆方式**。但这种方式受限于上下文长度的硬性上限，一旦超出则需丢弃早期信息。 与此同时，**RAG（Retrieval-Augmented Generation）** 仍然是处理长上下文的主要范式。RAG 通过从历史上下文中检索相关信息并提供给 LLM，突破了上下文长度的限制。例如，OpenAI 的记忆功能结合了用户偏好追踪与基于检索的方法。 **RAG 方法可分为三类：** 1. **简单 RAG**：基于字符串匹配技术（如 TF-IDF、BM25、BMX），非神经网络，依赖文本相似度。 2. **基于嵌入的 RAG**：使用神经网络（如 BERT、NV-Embed-v2）生成文本的密集向量表示，提升检索性能。 3. **结构增强型 RAG**：引入图结构、树结构等，如 **GraphRAG、RAPTOR、HippoRAG-V2、Cognee、Zep 和 Mem0**。其中，**Mem0 还提供了基于图增强的变体 Mem0g**，融合结构化事实知识。 尽管 RAG 方法有效，但在处理**模糊查询、多跳推理和长程理解**方面仍存在挑战。当问题需要**从整个对话会话或长技能编码输入中整合知识时**，RAG 依赖的 top-k 检索机制可能无法获取所需信息。 为解决这些问题，**Agent Memory Agents**（记忆代理）引入了**迭代决策驱动的框架**。这些代理通过**多次检索与推理循环**来处理查询，而非依赖一次性检索。代表性工作包括 **MemGPT、Self-RAG 和 Auto-RAG**。这种设计特别适合解决模糊或多步骤的查询。然而，这些方法仍受限于 RAG 的固有局限，即**无法完全理解或学习那些无法通过检索获取的长程上下文信息**。 **重点总结：** - 当前记忆机制主要包括直接上下文存储和 RAG 两类； - RAG 有多种形式，但面临模糊查询、多跳推理等挑战； - Agent Memory Agents 通过迭代推理提升效果，但仍受限于 RAG 本身的能力边界。 --- **章节总结：** “2 Related Work” 部分系统回顾了长上下文评估基准和记忆代理的研究现状。虽然已有大量工作致力于长上下文建模和信息检索，但**缺乏专门用于评估记忆代理的高质量基准**，且**现有 RAG 方法在处理复杂任务时仍存在局限性**。本文后续的工作可能正是针对这些问题提出改进方案。 ## 3 MemoryAgentBench 这篇论文的 **3 MemoryAgentBench** 部分主要围绕对“记忆代理”（Memory Agents）的评估展开，分别从**评估维度**、**数据集构建**、**代理类型分类**和**数据集与代理的标准化格式**四个方面进行详细说明。以下是对该章节内容的总结： --- ### 3.1 评估维度（Aspects of the Evaluation） 本节定义了评估记忆代理的四个关键维度，每个维度都有明确的定义和其在实际中的意义： #### ✅ 准确检索（Accurate Retrieval, AR） - **核心定义**：代理能否从长对话历史中准确提取所需信息。 - **应用场景**：类似于 Needle-in-a-Haystack（NIAH）任务，但将“长文本”扩展为“长对话”。 - **重要性**：在长对话中，关键信息可能分散在多个对话轮次中，AR 能力是代理进行回答的基础。 - **与 CR 的区别**：AR 强调信息的提取和保留，而 CR 则关注信息的更新与冲突解决。 #### ✅ 测试时学习（Test-Time Learning, TTL） - **核心定义**：代理能否在对话过程中通过少量示例学习新任务。 - **应用场景**：类似 In-Context Learning（ICL），但将“提示”替换为“对话历史”。 - **重要性**：这是代理适应新任务、自我进化的关键能力，模拟真实世界中用户逐步提供信息的场景。 #### ✅ 长程理解（Long-Range Understanding, LRU） - **核心定义**：代理能否对长文本进行抽象理解和总结，而不仅仅是记忆细节。 - **应用场景**：如对小说的整体概括能力（例如“总结《哈利·波特》的主要经历”）。 - **重要性**：体现代理对信息的整体把握和推理能力，而非单纯的记忆。 #### ✅ 冲突解决（Conflict Resolution, CR） - **核心定义**：代理能否识别和处理对话中出现的矛盾信息。 - **应用场景**：用户提供新信息时，代理要能更新旧记忆，排除错误或过时信息。 - **与 AR 的区别**：AR 保留所有相关信息，CR 则需舍弃旧信息以保持一致性和最新性。 - **重要性**：这是代理保持知识一致性和现实对齐的关键能力。 --- ### 3.2 数据集准备（Dataset Preparation） ![](https://img.zhaoweiguo.com/uPic/2025/08/fiKQla.jpg) Table 1: Datasets categorized by the specific aspects of evaluation. 本节详细介绍了为上述四个评估维度构建和采用的数据集，分为四类： #### ✅ 准确检索（AR）相关数据集 - **RULER-QA**：单/多答案抽取任务。 - **NIAH-MQ**：多查询任务，要求从长文中提取多个不同值。 - **∞Bench-En.QA**：基于整本书的问答，使用虚构角色名避免预训练污染。 - **LongMemEval**：评估长对话历史中的信息抽取。 - **EventQA（原创）**：要求代理在长叙事中回忆并推理事件顺序。 #### ✅ 测试时学习（TTL）相关数据集 - **分类任务**：BANKING-77、CLINC-150、TREC-Coarse/Fine、NLU。 - **推荐任务**：Redial（电影推荐对话数据集）。 #### ✅ 长程理解（LRU）相关数据集 - **∞Bench-Sum（En.Sum）**：要求代理对小说进行1000-1200字的摘要。 #### ✅ 冲突解决（CR）相关数据集 - **FactConsolidation（原创）**：使用 MQUAKE 的反事实编辑对，创建不同长度的冲突语境。 - **任务类型**： - **SH（Single-Hop）**：直接事实回忆。 - **MH（Multi-Hop）**：需要推理多个事实之间的关系。 --- ### 3.3 记忆代理的分类（Categories of Memory Agents） 本节介绍了三种主要的记忆代理类型，分别代表不同的记忆处理策略： #### ✅ **长上下文代理（Long-Context Agents）** - **策略**：依赖模型的长上下文窗口（如128K~1M tokens），采用 FIFO（先进先出）方式维护上下文。 - **特点**：简单直接，但受限于模型的上下文长度。 #### ✅ **RAG 代理（Retrieval-Augmented Generation Agents）** - **策略**：将历史信息存储于外部记忆池，按需检索。 - **变体**： - **简单 RAG**：基于关键词或规则检索。 - **嵌入式 RAG**：使用向量相似度检索。 - **结构增强 RAG**：构建知识图谱或事件链进行推理。 #### ✅ **代理式记忆代理（Agentic Memory Agents）** - **策略**：模拟人类记忆过程，通过循环推理、更新记忆进行任务处理。 - **特点**：更灵活，但实现复杂度较高。 --- ### 3.4 数据集与代理的标准化格式（Datasets and Agents Formulation） 本节规定了数据集和代理的统一处理格式，以确保评估的一致性和可扩展性： #### ✅ 数据集格式 - **结构化表示**：`[c1, c2, ..., cn]` 为对话历史块，`[q1, q2, ..., qm]` 为问题，`[a1, a2, ..., am]` 为答案。 - **设计思路**：一个上下文块可以对应多个问题，提高资源利用率。 - **示例**：一个长对话可配对多个问题，便于多次测试模型记忆能力。 #### ✅ 代理处理流程 - **输入处理**：逐块接收对话内容，逐步更新内存。 - **输出处理**：在接收全部块后，回答相关问题。 --- ### 总结 本节 **MemoryAgentBench** 是对记忆代理评估的完整框架，涵盖 **评估维度、数据集构建、代理类型分类、数据标准化** 四个方面。其重点在于： - **四大评估维度**（AR、TTL、LRU、CR）定义清晰，并在实际任务中体现其意义； - **数据集**覆盖广泛，既有经典任务再利用，也有原创任务增强挑战性； - **代理分类**反映了当前主流策略，从简单到复杂，适合不同层次的模型评估； - **标准化格式**确保了数据与模型处理的一致性，便于比较和扩展。 整体而言，本节为评估记忆代理提供了系统性、可扩展性强的基准框架。 ## 4 Experiments ### 4.1 Experimental Setup 本节介绍了实验的基本设置，包括使用的**数据集**、**评估指标**和**模型类别**。 - 数据集被分为四大类（AR、TTL、LRU、CR），详细的统计信息见表1（Table 1）。 - 评估指标见表5（Table 5），并附有更多数据集细节。 - **模型类别**包括三类： - *Long-Context Agents*（长上下文模型，如GPT-4o、Gemini） - *RAG agents*（检索增强生成模型）进一步细分为： - *Simple RAG Agents*（如BM25） - *Embedding-based RAG Agents*（如Contriever、Text-Embed-3、NV-Embed-v2） - *Structure-Augmented RAG Agents*（如RAPTOR、GraphRAG、HippoRAG-v2） - *Agentic Memory Agents*（记忆代理模型，如Mem0、Cognee、MemGPT） - **Chunk size（文本切片大小）**： - RULER-QA、NIAH-MQ、LME(S\*)、CR任务使用512的切片大小。 - 其他任务使用4096的切片大小。 - Mem0和Cognee统一使用4096，以减少计算开销。 - **GPT-4o-mini** 被选为主干模型进行评估。 --- ### 4.2 Overall Performance Comparison 本节对不同模型在多个基准任务上的性能进行了比较，重点总结如下： #### (1) RAG模型在**精准检索任务**（AR）中表现优越 - 多数RAG模型比GPT-4o-mini表现更好，因为它们擅长提取关键文本片段用于回答问题。 - 以NV-Embed-v2表现最佳（83.0%）。 #### (2) **长上下文模型**在**测试时学习**（TTL）和**长期理解**（LRU）任务中表现最佳 - GPT-4.1-mini在TTL（94.8%）和LRU（89.4%）中表现突出。 - 这表明RAG模型和记忆代理模型在处理长期记忆和全局理解方面存在局限。 #### (3) **冲突解决任务**（CR）对所有模型来说都极具挑战性 - 多跳（Multi-Hop）任务几乎无法完成（最高仅6%）。 - 仅长上下文模型在单跳（Single-Hop）任务中表现尚可（如GPT-4o为60.0%）。 - 说明当前所有记忆机制在处理冲突信息时仍存在根本性缺陷。 #### (4) **商业记忆代理模型**（MemGPT、Mem0）表现有限 - 问题主要体现在： 1. **记忆存储不足**：如Mem0仅提取事实性知识，丢失大量上下文。 2. **检索能力有限**：Mem0单次检索，类似传统RAG；MemGPT虽支持多轮检索，但缺乏结构化信息。 3. **嵌入方法在复杂任务中表现差**：如NIAH-MQ中无法准确定位“信息针”的问题。 --- ### 4.3 Ablation Study 本节从四个维度对模型进行了消融实验： 1. **输入切片大小（Input Chunk Size）** 2. **检索TopK数量** 3. **数据集验证** 4. **计算延迟（Computational Latency）** 详细结果见附录C。 --- ### 4.4 Ablation Study on Input Chunk Size 本节分析了**切片大小对模型性能的影响**： - **RULER-QA任务**中： - BM25性能基本不依赖切片大小。 - 基于嵌入的方法（如MemGPT）在小切片下表现更好，因为更细粒度有助于提升检索相关性。 - **∞\infty∞Bench-Sum任务**中： - 小切片导致性能下降，因为丢失了太多上下文，影响了摘要质量。 - **结论**： - 小切片+多检索次数有助于AR任务。 - 但不利于LRU任务，因为RAG类模型难以整合大范围上下文。 --- #### 4.4.1 Ablation Study on Retrieval TopK - 增加检索数量（TopK）普遍提升性能。 - 但当切片大小为4096、TopK=10时，输入已接近40k token，模型容量受限，无法进一步增加TopK。 - 详细结果见表11（Table 11）。 --- #### 4.4.2 Validation of Dataset FactConsolidation - 因该数据集上所有模型表现极差，作者采用更强的推理模型 **o4-mini** 验证数据集质量。 - 结果表明： - 即使使用更强模型，在**多跳任务**上的准确率仍非常低（最高为14%）。 - 说明该数据集具有高度挑战性，并非模型性能不足的问题。 --- #### 4.4.3 Analysis of Computational Latency - 分析了**记忆构建（M.C.）**和**查询执行（Q.E.）**的耗时。 - 所有测试在四张L40 GPU和AMD EPYC 7713 CPU的服务器上运行。 - **关键发现**： - **小切片（512）显著增加记忆构建时间**，尤其是对于结构化记忆模型（如HippoRAG-v2、Mem0）。 - **Mem0和Cognee在记忆构建阶段资源消耗极高**，可能限制其在实际应用中的部署。 --- ### 总结 本章系统评估了多种记忆类大语言模型在不同任务中的性能，重点分析了RAG方法、长上下文模型和记忆代理模型的优劣势。结果显示： - RAG模型在精准检索上表现优异； - 长上下文模型在长期理解和测试学习任务中表现最佳； - 冲突解决任务对所有现有方法都是难题； - 商业记忆代理模型存在显著性能瓶颈，尤其在处理复杂记忆任务时。 此外，实验还揭示了切片大小、检索次数和计算成本对模型性能的重要影响，为未来研究提供了方向。 ## 5 Conclusion and Future Work 在本文中，作者介绍了 **MemoryAgentBench**，这是一个统一的基准测试，旨在从四个核心能力方面评估“记忆代理”的表现：**精确检索、测试时学习、长程理解、冲突解决**。与以往主要关注技能执行或长上下文推理的基准不同，**MemoryAgentBench 特别填补了评估代理如何在多轮交互中存储、更新和使用长期信息的空白**。 为了构建这个基准，作者不仅重构了现有数据集，还提出了两个新数据集：**EventQA** 和 **FactConsolidation**，这两个数据集专门用于强调以往工作中常被忽视的记忆行为。作者在一致的评估协议下，对一系列代理进行了评估，包括长上下文模型、基于 RAG 的系统和商业记忆代理。**实验结果表明，尽管已有进展，但当前的记忆代理在面对需要动态记忆更新和长程一致性的任务时，仍存在显著限制。** 本文的一个限制是：**MemoryAgentBench 使用的数据集主要是合成数据，可能无法完全反映真实用户对话的特点。** 作为未来的工作方向，作者计划收集和整理更多**贴近现实的、真实世界的数据集**，这些数据集将与四个核心能力对齐，以进一步丰富和多样化该基准，为记忆代理提供更全面的评估支持。 ## Appendix A Details of Dataset 本节详细介绍了用于评估大型语言模型代理（LLM agents）四项核心能力（Accurate Retrieval, Test-time Learning, Long-Range Understanding, Conflict Resolution）所使用的数据集，包括数据集的构建方式、评估指标、平均上下文长度以及简要描述。详细信息见 **表5**。 --- ### **A.1 Accurate Retrieval (AR)** 用于评估模型在**长上下文**中**准确检索**特定信息的能力。 #### （1）**RULER-QA** - 来源：[[15]] - 特点：包含多个合成上下文（长度3K~200K+ tokens） - 构建方式：选取100个短上下文问题，收集所有相关文档，去重、打乱并拼接为197K或421K tokens的长上下文，确保包含正确答案片段 - 评估指标：**SubEM（Substring Exact Match）**，用于判断预测答案是否与真实答案完全匹配（适用于短实体答案） #### （2）**NIAH-MQ** - 上下文长度：448K tokens - 包含400个查询，分布在100个组中 - 构建方式：打乱查询及其对应的数字顺序，防止集群分布 - 评估指标：**平均召回率（Recall）**，判断是否成功检索到正确数字 #### （3）**∞Bench-En.QA** - 来源：[[53]] - 任务：小说QA，人物名被替换以增强真实感 - 评估指标：**ROUGE F1**，适用于实体名称类答案 #### （4）**LongMemEval** - 任务类型：基于对话的QA - 构建方式：拼接多个历史对话片段，生成355K tokens的长对话历史 - 评估方式：使用**GPT-4o模型**评估回答是否满足要求，计算**满意回答比例**作为指标 #### （5）**EventQA（自建数据集）** - 来源：5本超过390K tokens的小说，使用SpaCy提取101个关键人物事件 - 构建方式：为每个事件构建6选1的多选题，干扰项由模型生成 - 输入格式：给出最多5个前序事件，预测正确后续事件 - 评估指标：**平均准确率（Accuracy）** ### **A.2 Test-time Learning (TTL)** 评估模型在**长上下文学习**中的能力，分为两类任务： #### （1）**Multi-Class Classification (MCC)** - 构建方式：使用数千条不同类别的句子，拼接为长上下文 - 任务：根据上下文分类输入句子 - 评估指标：**平均准确率（Accuracy）** #### （2）**Recommendation（Recom）** - 构建方式：合并多个电影推荐对话，生成1000+推荐实例的长上下文 - 任务：根据对话推荐20部电影 - 评估指标：**Recall@5**，衡量推荐前5部电影与真实结果的重合度 --- ### **A.3 Long-Range Understanding (LRU)** 评估模型对**长距离上下文**的理解能力： - 任务：小说摘要（En.Sum），来自 **∞∞∞Bench** [[53]] - 评估方式：使用 **GPT-4o** 评估摘要文本的流畅性（0或1）和F1得分的点积作为最终评价指标 --- ### **A.4 Conflict Resolution (CR)** 评估模型在面对**冲突事实**时的处理能力： - 数据来源：**MQUAKE** [[54]] - 构建方式：将旧信息（干扰句）和新信息（正确句）按编号顺序拼接为长上下文 - 任务：判断正确事实 - 评估指标：**SubEM**，适用于实体类答案 --- ### 总结 本附录详细介绍了用于评估LLM代理在四种核心能力（AR, TTL, LRU, CR）下的多个数据集，涵盖了从问答、分类到摘要和冲突解决等多种任务。数据集的**长度从几十K到百万级token**，用于测试模型在不同场景下的长上下文处理能力。其中部分数据集为**自建**（如EventQA、FactConsolidation），突显了实验设计的灵活性和针对性。 ## Appendix B Prompts 本节介绍了在实验中使用的一些示例提示词（Prompts），用于指导LLM代理如何处理长上下文输入、构建记忆以及进行检索与生成。 --- ### B.1 记忆构建指令（Instructions for Memory Construction） 当处理长上下文输入时，文中将内容分割成指定大小的块（chunk），并将这些块输入代理（agent）作为“记忆”。代理可以根据查询内容从记忆中提取相关信息，以帮助执行任务。这种分块方法有助于组织和管理大量上下文信息，提高检索和推理的效率。 图4展示了用于构建记忆的提示词示例，针对不同任务使用不同指令： - **LongMemEval**：记忆用户与助手之间的对话。 - **Movie Recommendation**：记忆用户与推荐系统之间的对话。 - **Fact Consolidation**：记忆一组事实。 - **其他任务**：记忆指定内容。 > **总结**：本节核心在于介绍如何通过提示词将长上下文分块并输入代理中，从而构建“记忆”，为后续任务提供上下文支持。 --- ### B.2 长上下文代理指令（Instructions for Long-Context Agents） 图5展示了适用于不同数据集的代理提示词。这些提示词根据任务类型进行调整，部分基于已有研究的工作（如[15]和[48]）。 示例提示词包括： - **RULER-QA**：基于记忆文档回答问题。 - **RULER-NIAH-MQ**：记忆特殊数字并回答相关问题。 - **∞∞Bench-QA**：基于上下文简洁回答问题。 - **LongMemEval**：基于历史对话回答当前问题。 - **EventQA**：根据书摘内容预测后续事件。 - **Label Matching**（如BANKING77）：将上下文映射为数字标签。 - **Movie Recommendation**：基于历史对话推荐电影。 - **∞∞Bench-Sum**：生成约1000-1200字的摘要。 - **Fact Consolidation**：解决事实冲突，使用最新信息回答。 > **总结**：本节展示了“长上下文代理”在不同任务中的具体提示词形式，强调了如何引导代理在记忆基础上进行推理、问答和任务完成。重点任务如摘要生成（∞∞Bench-Sum）和事实整合（Fact Consolidation）被详细说明。 --- ### B.3 RAG 代理指令（Instructions for RAG Agents） 图6展示了基于RAG（Retrieval-Augmented Generation）代理的提示词，这些代理在检索记忆后完成任务。大多数任务使用``作为检索查询，但部分任务如**RULER-NIAH-MQ**和**∞∞Bench-Sum**使用完整查询作为检索内容。 提示词形式与长上下文代理类似，但强调了“从记忆中检索”： - **RULER-QA**：基于检索到的上下文回答问题。 - **RULER-NIAH-MQ**：寻找记忆中的特殊数字。 - **∞∞Bench-Sum**：基于检索内容生成摘要。 - **Fact Consolidation**：解决检索到的事实冲突。 > **总结**：本节展示了如何通过RAG代理实现“检索+生成”的任务处理方式。重点在于不同的任务如何引导代理从记忆中提取信息并生成答案。对于MemGPT方法，还在提示词中加入了“Search Archival Memory”。 --- ### 表6：不同代理在AR（Answer Retrieval）任务上的总体性能比较 该表对比了不同类型代理在不同任务下的表现。所有RAG代理和商业化内存代理均以GPT-4o-mini为骨干模型。突出对比了以下代理： - **Long-Context Agents**（如GPT-4o、GPT-4o-mini等） - **Simple RAG Agents**（如BM25） - **Embedding RAG Agents**（如Contriever、Text-Embed） - **Structure-Augmented RAG Agents**（如RAPTOR、GraphRAG） - **Agentic Memory Agents**（如MemGPT、Self-RAG） > **总结**：表6展示了各代理在不同任务上的性能表现，GPT-4o和Gemini-2.0-Flash在多数任务中表现较好。BM25在部分任务上表现优异，而一些结构增强型RAG代理（如RAPTOR）整体表现一般。 --- ### 表7：不同代理在TTL、LRU和CR任务上的总体性能比较 表7进一步比较了代理在其他任务（如分类、推荐、摘要生成等）中的表现。GPT-4o、Claude-3.7-Sonnet等在多数任务中表现良好，而MemGPT在部分任务中也表现不俗。 > **总结**：表7提供了对不同代理在多种任务类型上的全面性能评估，补充了表6的覆盖范围，帮助理解代理在不同应用场景下的优劣。 --- ### 总体总结 本附录详细介绍了用于实验中的提示词设计，包括： 1. **如何构建记忆**（B.1）：通过分块处理上下文并输入到代理中。 2. **长上下文代理的提示词设计**（B.2）：针对不同任务，提供结构化的问答、摘要、推理等指令。 3. **RAG代理的提示词设计**（B.3）：强调检索与生成结合，任务形式与长上下文代理类似，但更注重检索部分。 4. **性能比较表**：通过两个表格（表6和表7）展示了不同代理在多种任务和数据集上的表现，为模型选择提供了参考。 > **重点内容**：B.2和B.3的提示词设计是全文核心，展示了如何通过不同的提示词引导LLM代理完成不同任务。表6和表7通过实验结果验证了这些提示词的实际效果。 ## Appendix C Detailed Experimental Results ### C.1 AR 任务的详细结果 在表 [7](https://arxiv.org/html/2507.05257v1#A2.T7) 中，我们展示了每个代理在不同数据集上的详细结果。 对于 **AR（答案检索）任务**，使用了 **Simple RAG Agents** 并配备如 **BM25** 这样的检索器，其性能显著优于基础模型 **GPT-4o-mini**。这是因为 **GPT-4o-mini** 的上下文长度限制为 128K，限制了其一次性处理信息的能力。相比之下，**Embedding RAG Agents** 的整体性能优于 **Structure-Augmented RAG Agents** 和 **Agentic Memory Agents**。这种优势主要归因于 **Embedding RAG Agents** 使用了**稠密检索**，能够从记忆中提取更长的上下文信息，从而更好地支持任务需求。 --- ### C.2 TTL、LRU 和 CR 任务的详细结果 在表 [7](https://arxiv.org/html/2507.05257v1#A2.T7) 中，我们给出了 **TTL、LRU 和 CR 任务** 的详细结果。 对于这三类任务，基于 **RAG 的代理** 通常表现不如其对应的 **GPT-4o-mini** 基础模型。这揭示了 **RAG 方法** 的某些固有局限性。例如： - 在 **TTL 任务** 中，RAG 方法常难以准确检索与输入高度相关的上下文。 - 在 **LRU 任务** 中，RAG 方法在处理长上下文时存在理解困难。 - 在 **CR 任务（特别是多跳任务）** 中，有效处理需要强大的推理和信息提取能力，这在当前的代理中仍较为欠缺。 --- ### C.3 消融实验的详细结果 在本节中，我们介绍了对不同 **chunk 大小、检索数量、上下文长度和计算延迟** 的消融实验结果。 #### 不同 chunk 大小的影响（表 8 和 表 9） - **chunk 大小** 对性能有显著影响。例如，在合成文本数据集（如 **RULER-QA**）中，使用较小的 chunk 大小（如 512）有助于 **RAG Agents** 和 **Agentic Memory Agents** 提高测试性能。 - 然而，在连续文本数据集（如 **∞∞Bench-QA**）中，如果检索数量 **k** 保持不变，减小 chunk 大小并不会提升性能。 #### 不同 TopK 检索数量的影响（表 10） - 对于 **AR 系列任务**，增加检索数量 **TopK** 可以显著提升性能。 - 对于 **TTL 系列任务**，TopK 增加带来的性能提升较小。 #### 不同上下文长度的影响（表 11） - 对于 **AR 系列任务**，即使在较小的上下文长度（如 50K token）下，**Long-Context Agents** 的性能也相对较好。但随着上下文长度增加，性能下降。 - 相比之下，**RAG Agents（如 Mem0 和 Cognee）** 的性能通常低于其基础模型 GPT-4o-mini，即使在较小的上下文长度下也是如此。 #### 计算延迟（表 12 和 表 13） - 小 chunk 大小（如 512）通常会导致较高的计算延迟。例如，**Cognee** 在 chunk 为 512 时的计算延迟是 chunk 为 4096 时的 8 到 10 倍。 - **RAG-based Agents** 的计算延迟主要分为两部分：**Memory Construction（记忆构建）** 和 **Query Execution（查询执行）**。 #### 最大输出 token 限制（表 14） - 不同任务对输出 token 的限制不同。例如： - **∞∞Bench-Sum** 最大为 1200 token； - **∞∞Bench-QA** 最大为 10 token； - **Movie Recommendation** 最大为 300 token。 --- ### 总结 通过本节的详细实验结果，我们可以看到： - **Embedding RAG Agents** 在 AR 任务中表现较好，因其利用了更高效的上下文提取能力； - **RAG Agents 在 TTL、LRU 和 CR 任务中表现不佳**，暴露出其在复杂上下文处理和推理方面的不足； - **chunk 大小和 TopK 检索数量** 对性能和延迟有显著影响，需根据任务特性进行调整； - **计算延迟** 是 RAG 方法的另一个关键问题，尤其是在使用小 chunk 大小时； - 不同任务的 **输出长度限制** 也需在模型设计时考虑。 ## Appendix D Experimental Settings ### D.1 最大输出 token 数 为每个任务提供了 token 数量的限制，详见表 14（参考：https://arxiv.org/html/2507.05257v1#A3.T14 "表 14"）。 这部分内容较为简略，仅说明设置了一个 token 上限，具体数值在表中给出。 ### D.2 RAG 代理的设置 在结构增强型 RAG 代理和代理记忆代理中，大多数方法使用了 OpenAI 的嵌入模型，如 Text-Embed-3-Small。而对于 HippoRAG-v2 方法，我们沿用了 Gutiérrez 等人的实验设置，采用 NV-Embed-v2 模型进行嵌入处理。 我们实现了三种开源的记忆代理系统： 1. **Mem0**：在记忆整合阶段，使用 `memory.add()` 函数将上下文块的内容添加到代理的记忆库中。在查询阶段，使用 `memory.search()` 函数检索相关记忆，并将其整合到查询中，再由 GPT-4o-mini 模型处理任务。 2. **MemGPT**：在记忆整合阶段使用 `insert_passage()` 函数将长上下文块注入到归档记忆结构中。在查询阶段使用 `send_message()` 函数处理请求，生成基于归档信息的响应。 3. **Cognee**：使用 `cognee.add()` 和 `cognee.cognify()` 函数在记忆整合阶段构建记忆图。在查询阶段使用 `cognee.search()` 函数从记忆图中检索与输入查询相关的上下文信息。 **重点内容：** 这部分详细介绍了三种记忆代理的实现方式和处理流程，是实验设置的核心内容之一。 ### D.3 分块大小的设置 我们在不同任务中采用了不同的分块大小（chunk size）： - 对于 AR 和 CR 任务中使用的合成上下文，采用了较小的分块大小（512）。 - 对于基于连续文本的任务，如 ∞Bench 和 EventQA，使用了较大的分块大小（4096）。 - 对于 MCC、Recom 和 LME(S) 等任务，考虑到任务特性和计算成本，也选择了较大的分块大小（4096）。 - 对于处理时间较长的 Mem0 和 Cognee 两种记忆构建方法，我们在所有数据集中统一使用了 4096 的分块大小。 | 分块大小 | 512 | 4096 | | --- | --- | --- | | 数据集 | RULER-QA, NIAH-MQ | ∞Bench-QA, ∞Bench-Sum | | | FactCon-SH, FactCon-MH | MCC, Recom | | | LME(S) | EventQA, LME(S) | **表 15：不同数据集的分块大小选择** **重点内容：** 分块大小的选择直接影响模型处理能力和计算效率，因此是实验设置中一个关键参数。该表格清晰地展示了不同任务和数据集下的分块配置策略。 --- **总结：** 附录 D 主要介绍了实验中使用的各种设置，包括最大输出 token 数、RAG 代理的实现方式、以及不同任务所采用的分块大小。其中，RAG 代理的设置和分块大小的选择是实验设计的重点内容，直接影响模型的性能和效率。