MemTrace：追踪和归因大语言模型内存系统中的错误 MemTrace: Tracing and Attributing Errors in Large Language Model Memory Systems
提出首个通过执行图自动诊断LLM内存系统错误的框架
前置知识
非参数化内存系统
一种大语言模型记忆管理架构，通过外部存储（如向量数据库、消息缓冲区）而非模型内部参数来维护长期记忆。典型系统包括RAG、长上下文、Mem0等。它们通过内存更新操作增量式地构建记忆状态，通过内存读取操作检索相关上下文。与参数化记忆不同，这些系统在对话过程中动态维护和更新记忆单元，但面临信息丢失、检索不匹配等可靠性问题。
论文研究的核心对象，所有错误归因方法都基于此类系统的执行图展开。理解内存更新、检索、删除等操作如何构建信息流是读懂本文的关键。
执行图
一种有向无环二部图G=(V,O,E)，其中V是变量节点集合，O是操作节点集合，E是边集合。变量代表执行过程中产生的具体产物（如原始消息、检索到的记忆单元、中间摘要、提示词等），操作代表计算步骤（如LLM推理、工具调用、检索、过滤、解析函数等）。边捕获变量和操作之间的信息流：每个操作接受输入变量集合In(o)，产生输出变量集合Out(o)。这种表示方式能够显式记录哪些操作消费、修改、覆盖或传播每个内存变量，从而追踪跨回合和会话的信息依赖。
MemTrace方法的核心数据结构，通过执行图将平面的执行日志转化为结构化的信息流表示，使得错误归因能够沿着依赖关系回溯到错误源头。
决定性错误集
给定失败的执行图G和正确答案a，决定性错误集是最小因果切割集，包含最早且最小的故障操作集合。它必须满足三个条件：集合中的每个操作在执行中都有故障；所有严格上游祖先集中的操作都功能正确；通过用正确对应物替换故障输出变量来构建修改后的执行图，可以挽救失败的执行。数学上定义为满足因果充分性条件的最小候选操作集合。在本文研究的顺序执行内存系统中，该集合退化为单元素集合。
错误归因的目标，将故障定位问题转化为在执行图中寻找最小因果切割集的图探索问题。本文假设其为单元素集合，符合所研究的顺序执行内存系统的特性。
LLM-as-a-Judge
一种使用另一个LLM作为裁判来评估模型输出质量的方法。在本文中，用于判断内存系统生成的答案是否正确：将预测答案与golden answer进行比较，由裁判模型（文中使用Claude Opus 4.5）给出二元判断。这种方法比人工标注更高效，但可能存在偏差（如对正确但过于冗长或不够具体的答案过于严格）。论文也发现存在LLM-as-a-Judge错误，即系统答案实际上可接受但自动裁判错误地标记为错误。
MemTraceBench构建过程中的关键评估方法，用于识别失败案例。理解其局限性（如标注错误、不精确问题带来的判断困难）对于正确解读实验结果很重要。
研究动机
现有LLM内存系统虽然支持长期推理和持续学习，但可靠性不足且难以调试。与无状态智能体不同，带记忆的智能体维护跨会话的持久状态，失败可能源自早期的记忆构建、更新或删除操作，并在后期检索或响应生成时才显现。例如，用户偏好可能最初被正确存储，但后来被错误的更新覆盖，导致与错误起源相距甚远的下游失败。现有内存基准（如LoCoMo、LongMemEval、RealMem）都是结果导向的，只能揭示系统是否成功存储、检索或使用相关信息，但无法揭示失败被引入和传播的因果路径。这暴露了LLM内存系统中的关键可追踪性缺口：失败是可观测的，但故障操作、其引入时间和传播路径仍然难以识别。
本文的目标是本文的目标是研究一个新问题：如何在非参数化内存系统中自动诊断失败。具体而言，提出一种框架将内存管道转换为可执行的内存演化图，实现对操作信息流的细粒度追踪；构建一个诊断基准MemTraceBench，包含来自四个代表性内存系统和三个公开数据集的人类标注的真实失败案例；引入自动归因方法，在执行图上迭代追踪操作子图以精确定位任何失败案例的根本原因；利用这些细粒度归因信号指导下游提示优化，建立自动纠正故障并提升端到端任务性能的闭环系统。
与已有工作不同的是，与之前诊断LLM智能体的工作相比，本文的独特切入点在于处理带长期非参数记忆的有状态智能体。先前工作主要关注在单任务实例内的短推理轨迹中定位故障，使用基于采样的信号、过程级监督或LLM检查中间轨迹。在有记忆的智能体中，失败可能在早期会话中引入，必须与大量不相关的交互历史区分开来。另一个关键区别是执行追踪的表示：本文不将执行轨迹视为相对较短的日志序列，而是构建统一的操作-变量图，显式记录变量如何被创建、修改、覆盖、传播并最终用于失败的预测。这种结构化表示使得归因能够沿着信息依赖跨回合和会话进行。
核心方法
MemTrace方法的核心思想是将内存系统执行暴露为统一的操作-变量图，通过系统无关的追踪工具包实现。具体包含三个阶段：首先使用smartcomment工具包对内存系统源代码进行插桩，记录执行过程中的变量、操作及其依赖关系，构建执行图；然后对于给定的失败案例（问题q、golden answer a和失败执行图G），MemTrace通过代理图探索定位决定性错误操作；最后利用归因信号指导提示优化，形成闭环系统。整体框架将错误归因转化为有向图上的搜索问题，通过混合检索确定起点、图遍历追踪信息流、工作上下文管理防止上下文爆炸。
核心创新点在于将内存系统的执行轨迹从平面的日志序列转化为结构化的执行图表示，并基于此进行细粒度的信息流追踪。与现有框架（如MLflow、Langfuse）的事件中心追踪不同，smartcomment记录变量间的依赖关系，使得可以追踪特定内存单元如何被创建、修改以及哪些早期变量因果贡献于下游失败。另一个关键创新是图探索策略与检索初始化的结合：使用混合检索（BM25稀疏检索加Qwen3-Embedding-4B稠密检索加RRF融合）从历史消息中识别最可能包含关键信息的源消息作为探索起点，然后按照依赖边从早期操作向晚期操作追踪，避免了大范围搜索。
方法步骤详情
方法包含三个主要模块。第一步是起点初始化：为减少初始分支因子，MemTrace使用混合检索识别最可能包含失败问题所需关键信息的源消息。具体地，通过将问题与golden answer拼接构建检索查询，对原始消息集同时执行稠密检索和稀疏检索，通过RRF融合两个排序列表，选择融合排名前一半的消息，与问题一起创建初始待探索列表。第二步是执行图探索：在每次迭代中，给定当前待探索列表，MemTrace选择时间戳最早的变量作为当前探索变量，检索直接涉及该变量的所有操作。对于每个操作，将操作级子图转换为文本表示（包括操作名称、类别、注释、输入输出变量和依赖关系），代理根据决定性错误标准判断每个检查的操作。如果操作局部正确，代理通过将操作子图的相关下游变量添加到列表中来跟随信息流。探索在代理识别出决定性错误操作或达到最大推理迭代次数时终止。第三步是工作上下文管理：执行图可能很大，跨越许多操作和长变量值。MemTrace明确管理代理的工作上下文，支持轻量级预览模式（省略具体变量值）、目标访问（分页和正则搜索）、操作子图的分页文本表示，以及上下文超过预定义安全阈值时的自动工作上下文摘要。这些工具级控制防止上下文突然扩展。
技术新颖性
技术新颖性体现在多个方面。首先提出了智能工具包smartcomment，结合了基于插桩追踪的灵活性和基于图追踪的溯源优势，允许开发者追踪任意Python变量并通过用户定义的可序列化表示，显式记录变量和操作之间的依赖关系，支持原地更新的版本化变量节点以恢复内存单元随时间的演化轨迹。其次是MemTrace的图探索策略，结合了结构化依赖追踪和检索初始化，使得代理能够从早期操作向晚期操作追踪关键信息的生命周期。对于弱结构化或退化为长链的执行图，引入了MemTrace-OBS变体，将每个操作级子图转换为文本操作块（移除依赖边和唯一变量标识符，保留输入输出变量、中间变量和操作属性），按时间戳排序并连接形成弱结构化操作日志，配备全局操作搜索工具（正则表达式查询）。最后实现了完整的闭环系统，将归因信号与提示优化解耦，使得优化只需针对参与故障操作的少量提示进行局部优化，避免了现有方法试图在整个因果链上推理、传播信号或重放整个内存管道的困难。
实验结果
在MemTraceBench上的实验表明，诊断内存系统中的失败仍然具有挑战性，但MemTrace能够成功恢复有意义的故障操作和错误类型。使用GPT-4.1 mini作为骨干模型时，MemTrace实现了36.46%的错误类型准确率和14.17%的故障操作识别准确率；使用GPT-5.4时，错误类型准确率提升至54.38%，故障操作识别准确率提升至38.13%。图探索相比基于搜索的探索在错误类型归因上表现更好，特别是对较小的LLM：GPT-4.1 mini上MemTrace将错误类型准确率从20.00%（MemTrace-OBS）提升至36.46%，增益达82.3%。这表明较小的模型从图探索的约束检查范围中受益，迫使代理从早期操作到晚期操作跟随信息流。操作识别准确率在所有设置中显著低于错误类型准确率，最佳整体操作识别准确率仅达到46.25%，这表明定位精确的故障操作比预测错误类型困难得多。不同内存系统表现出不同的性能模式：长上下文子集产生最低的错误类型准确率，MemTrace往往重复检查记忆状态是否包含目标源证据，经过几次跳转后可能会转向未探索的问题侧检索路径；RAG和EverMemOS相比Mem0在成本减少上更大，因为它们在触发索引或提取之前维护和更新消息缓冲区，使其执行图的局部结构类似于长上下文内存执行图。搜索操作探索大幅降低归因成本，特别是在弱结构化追踪上：在长上下文子集上仅使用MemTrace的15.25%token和27.94%运行时间。
查看结构化数据
| 任务 | 指标 | 本文 | 基线 | 提升 |
|---|---|---|---|---|
| 错误类型预测 | 错误类型准确率 (ETA) | 54.38% (GPT-5.4) | 53.75% (MemTrace-OBS, GPT-5.4) | +1.17% |
| 故障操作识别 | 操作识别准确率 (OIA) | 38.13% (GPT-5.4) | 46.25% (MemTrace-OBS, GPT-5.4) | -17.56% |
| 错误类型预测 (GPT-4.1 mini) | 错误类型准确率 (ETA) | 36.46% | 20.00% (MemTrace-OBS) | +82.3% |
| 端到端性能提升 | LLM-as-a-Judge分数 | +7.62% | Mem0默认配置 | 三轮优化后 |
| 归因成本 (长上下文) | 平均Token消耗 (千) | 4471.10 | 692.79 (MemTrace-OBS) | -84.50% |
局限与改进
论文承认了多个局限性。首先，MemTraceBench虽然涵盖了多个代表性内存系统和长期记忆基准，但其规模和多样性可以进一步扩展。未来基准可以包括更广泛形式的记忆，如任务记忆和多模态记忆。其次，当前的公式化和基准专注于决定性错误集为单元素的失败，这种设置在本文研究的内存系统失败中很常见，但不覆盖复杂智能系统中所有可能的失败。特别是调用多个子智能体然后聚合其输出的系统可能包含多个独立错误，它们共同导致最终失败。将smartcomment和MemTrace扩展到识别非单元素决定性错误集是未来工作的重要方向。第三，提出的归因方法仍有大幅改进空间。有前景的方向是将全局操作搜索与局部图探索结合，使代理能够快速定位相关区域，同时仍在结构化依赖邻域上进行推理。第四，虽然本文专注于非参数化内存系统，但记录执行图和执行代理失败归因的潜在思想更通用，将smartcomment和MemTrace应用于其他复合系统可以进一步测试基于图的自动诊断的通用性。
独立分析的弱点
独立分析的弱点包括：1) 操作识别准确率显著低于错误类型准确率，最佳操作识别准确率仅46.25%，表明定位精确故障操作仍很困难。这可能源于执行图的复杂性、错误传播路径的模糊性以及不同操作间故障的相似性。改进方向可以是引入更精细的依赖分析、结合概率推理或利用多轮验证机制。2) 归因成本较高，特别是MemTrace相比MemTrace-OBS需要更多token和运行时间。虽然图探索提供更好的准确性，但在大规模部署时可能成为瓶颈。改进方向包括优化上下文管理策略、引入增量式图探索或开发更高效的子图检索算法。3) 当前方法假设决定性错误集为单元素，限制了其对并发或异步执行系统的适用性。改进方向是扩展形式化和算法以处理多个独立错误的联合归因。4) smartcomment依赖于开发者的显式插桩，其质量取决于插桩覆盖和粒度。虽然这在AI辅助开发环境中成本降低，但完全自动化仍然具有挑战性。改进方向可以是开发半自动插桩工具或结合静态分析来建议插桩点。
未来方向
未来研究方向包括：1) 扩展MemTraceBench的规模和多样性，纳入任务记忆、多模态记忆等更广泛的记忆形式。2) 将smartcomment和MemTrace扩展到识别非单元素决定性错误集，以支持并发或异步执行的智能体系统。3) 改进归因方法，结合全局操作搜索与局部图探索，使代理能够快速定位相关区域同时保持结构化依赖推理。4) 将底层思想应用于其他复合系统（如动态任务规划、业务数据工作流），测试基于图的自动诊断的通用性。5) 改进smartcomment的自动化程度，结合静态分析或学习来自动识别需要追踪的关键操作和变量。6) 探索更高效的上下文管理和子图检索策略，在保持准确性的同时降低归因成本。7) 研究如何利用归因信号进行更全面的系统优化，不仅限于提示调整，还包括架构改进、检索策略优化等。
复现评估
论文承诺代码将在https://github.com/zjunlp/MemTrace发布（MIT许可证），使用开源内存系统（RAG、Mem0、EverMemOS）和公开数据集（LoCoMo、LongMemEval、RealMem）。实验使用标准化的骨干模型设置：内存构建模型和下游响应生成模型设置为GPT-4.1 mini，稠密检索使用Qwen3-Embedding-4B，EverMemOS的重排序器为Qwen3-Reranker-4B，裁判模型为Claude Opus 4.5以减少架构差异带来的评估偏差。上下文窗口设置为32k token，RAG采用在线分块策略（1200 token消息缓冲区），所有系统的检索记忆单元数量固定为10。归因实验使用GPT-4.1 mini和GPT-5.4作为骨干模型，工作上下文安全阈值为272,000 token，最大推理预算为200次迭代，温度固定为1，待探索列表大小为16。算力需求主要来自LLM推理成本，平均归因成本为1816.88千token（GPT-4.1 mini）或1875.49千token（GPT-5.4），端到端运行时间为4.82分钟或4.09分钟。标注过程需要五个具有LLM智能体和内存系统经验的标注者，使用交互式标注界面。总体而言，论文提供了相对完整的开源实现和详细的实验设置，复现难度中等，主要挑战在于LLM API访问和大规模执行图的处理。
论文图表
该图展示了MemTraceBench的额外数据分析。图(a)显示每个内存系统执行图日志的token分布：RAG约100万tokens，Mem0约200万tokens，Long-Context约500万tokens，EverMemOS约1000万tokens。更先进的系统接近1000万token。长上下文内存进一步增加日志大小，因为每个更新操作都记录更新前后的上下文窗口。图(b)显示标注者之间的成对不一致率，颜色越深表示不一致率越高。标注者表现出非平凡的不一致，成对不一致率范围从3%到46%。对于部分标注者对无法计算，因为他们标注的案例不重叠。这表明标注失败归因案例本质上是具有挑战性的，特别是对于Mem0和EverMemOS案例。
这个图对理解MemTraceBench的挑战和质量至关重要。图展示了执行日志的规模，解释了为什么直接用长上下文LLM进行端到端检查是困难的。图展示了标注任务的难度和标注者间的主观性，这有助于读者理解评估基准本身的局限性以及为什么需要自动归因方法。这也为解读实验结果和标注错误提供了背景。
该表格展示了Mem0的完整系统错误分析报告，由MemTrace归因结果自动生成。报告分析了Mem0在内存构建、维护、检索和下游问答中的失败模式，目标是理解为什么对话中可用的信息不能可靠地重现为正确的个性化回忆。报告指出四个反复出现的弱点：1) 内存更新可以通过重写时间基础、将重复但不同的事件合并为单条记录或剥离关系和溯源细节来破坏之前正确的事实；2) 事实提取可以阻止关键信息进入内存，特别是当决定性内容是相对日期、时间子句、负面偏好、简短评价短语、特定情绪、结构化计划或助手提供的列表时；3) 基于原始用户问题的检索往往偏向语义相邻或人员相关的记忆，而省略其措辞、实体标签、新近性、完整性或集合成员资格解决查询的确切记忆；4) 即使相关证据存在，回答模型也不一致地使用它来执行字面回忆、枚举所有合格项或保留必要的时间和状态区别。报告用红色粗体突出显示主要的反复失败机制。
这个表格对理解MemTrace的实际应用价值至关重要，它展示了如何将归因结果自动综合为可操作的洞察。读者可以看到MemTrace不仅能够定位故障操作，还能够聚合系统级错误模式，为系统改进提供具体方向。这证明了MemTrace作为诊断基础设施的实用性，即使归因不完美也能产生有意义的分析。