MemTrace: Tracing and Attributing Errors in Large Language Model Memory Systems

论文阅读：MemTrace：面向大语言模型记忆系统的错误追踪与归因

论文标题：MemTrace: Tracing and Attributing Errors in Large Language Model Memory Systems
作者：Xinle Deng, Ruobin Zhong, Hujin Peng, Xiaoben Lu, Yanzhe Wu, Guang Li, Buqiang Xu, Yunzhi Yao, Jizhan Fang, Haoliang Cao, Junjie Guo, Yuan Yuan, Ziqing Ma, Yuanqiang Yu, Rui Hu, Baohua Dong, Hangcheng Zhu, Ningyu Zhang
发表位置：arXiv preprint，Ongoing work
arXiv 编号：2605.28732v1 [cs.CL]
提交时间：2026-05-27
原文链接：https://arxiv.org/abs/2605.28732
主题：LLM memory systems、failure attribution、execution graph、memory debugging
核心问题：当带长期记忆的大语言模型系统回答错误时，如何定位错误最早是在哪个记忆操作中产生，并解释它如何沿着记忆构建、更新、检索和回答流程传播到最终失败。

1. 论文要解决什么问题？

大语言模型的记忆系统让智能体不再只是一次性回答问题，而是可以跨多轮、跨会话保留用户信息、更新状态，并在未来任务中调用过去经验。这样的系统已经被用于个性化助手、代码智能体等场景。

但论文指出，记忆系统越复杂，越难回答一个关键调试问题：当一个 memory-augmented agent 最终回答失败时，错误到底从哪里开始？

在无状态 agent 中，错误通常局限在当前任务轨迹里，例如一次错误工具调用、一次错误检索或一个错误推理步骤。相比之下，记忆增强系统维护的是持续演化的状态。一次失败可能不是由当前问题直接造成，而是来自更早的记忆构建、记忆更新、记忆删除或检索过程。比如一个用户偏好最初被正确存储，但后来在更新中被覆盖或削弱，直到很久以后才在某个回答中暴露出来。

因此，普通线性日志不够用。线性日志只能说明操作发生的时间顺序，却难以说明一个记忆变量是怎样被创建、修改、覆盖、传播并最终进入失败回答的。已有记忆基准通常能判断系统是否存储、检索或使用了正确信息，但并不专门用于恢复失败的因果路径。

这篇论文提出的问题可以概括为：把记忆系统的执行过程转化为可追踪的信息流结构，并在失败样例中自动找到导致失败的关键操作。

2. 从线性日志到执行图：为什么需要新的表示？

论文的核心观察是，记忆系统中的错误不是单点文本错误，而是发生在一条动态信息流上。

一个记忆系统通常包含几类关键操作：

阶段 典型操作 可能出现的问题
记忆构建 从原始对话中抽取事实、生成记忆单元 关键信息没有被抽取
记忆更新 合并、覆盖、改写已有记忆 原本正确的信息被削弱或覆盖
记忆删除 删除旧记忆或低价值记忆 含有关键证据的记忆被移除
记忆检索 根据当前问题检索相关记忆 记忆库中有答案，但没有被取出
回答生成 使用检索结果生成最终回答 证据已经给到模型，但回答仍然错误

如果只看最终输入输出，很难知道失败属于哪一类。即使有日志，如果日志只是按时间排列，也很难恢复“哪个变量被哪个操作消费、产生、修改，并继续影响后续变量”。

因此，作者提出把记忆系统执行过程表示成一个operation-variable graph。图中有两类节点：

  1. 变量节点：表示执行中的具体产物，例如原始消息、抽取出的事实、记忆单元、检索结果、中间摘要、最终 prompt 等。
  2. 操作节点：表示对变量执行的计算步骤，例如 LLM 推理、工具调用、检索、过滤、解析、更新等。

边表示信息流：一个操作读取哪些变量，又产生哪些变量。这样，系统不再只是一串日志，而是一张能表达依赖关系的有向无环二分图。

image

【Figure 1。该图展示从执行记忆系统、构建 execution graph，到 MemTrace 在失败样例上逐步追踪并定位错误操作的整体框架。】

3. 形式化目标：定位“决定性错误操作”

论文把自动错误归因分成两步：

  1. 收集系统执行轨迹；
  2. 分析轨迹并定位失败源头。

给定一个非参数化记忆系统，它处理历史轨迹、回答问题，并得到预测答案。如果预测答案与标准答案不一致，就得到一个失败执行图。

论文关心的不是随便找一个看起来有问题的操作，而是要找一个更严格的对象：Decisive Error Set，即决定性错误集合。

直观理解是：

  • 这个集合里的操作本身是错误的；
  • 它之前的上游操作是正确的；
  • 如果把这个错误操作的输出替换成正确版本，并假设下游操作理想执行，那么失败可以被修复；
  • 这个集合还要满足最小性，不能再删掉其中任何一个操作。

在论文当前的 benchmark 设定中，作者主要关注决定性错误集合只包含单个操作的情况，也就是定位一个最早的关键错误操作。这与许多记忆系统失败相匹配，也让标注和自动归因任务更可控。

4. MemTraceBench：面向记忆系统错误归因的诊断基准

由于此前缺少专门评估“记忆系统错误归因”的数据集，作者构建了 MemTraceBench。

它不是只记录问题、答案和系统输出，而是为失败样例提供更细粒度信息，包括：

  • 问题；
  • 标准答案；
  • 完整执行轨迹；
  • 错误类型标注；
  • 出错操作的唯一标识符；
  • 人类解释。

4.1 数据来源与系统选择

MemTraceBench 使用了三个公开问答数据来源：

数据集 用途
LoCoMo 长程对话记忆评测
LongMemEval 长程记忆评测
RealMem 更真实、更开放的记忆问答场景

作者选择了四类代表性记忆系统：

系统 特点
Long-Context 直接把长上下文提供给模型
RAG 从外部存储中检索相关内容
Mem0 包含记忆抽取、更新、检索等机制
EverMemOS 更复杂的记忆操作系统式架构

4.2 smartcomment：用于收集执行图的轻量追踪工具

论文指出，不同记忆系统的代码结构和数据结构差异很大，很难强行改造成统一抽象。为此，作者开发了一个轻量追踪包 smartcomment。

它的作用是让开发者在关键操作处添加追踪语句，从而记录：

  • 操作；
  • 变量；
  • 变量之间的依赖关系；
  • 变量的版本变化；
  • 操作和变量的语义注释。

作者使用 smartcomment 对四种记忆系统进行插桩，运行采样轨迹，收集到 1,514 个不同错误。之后，五名来自作者团队的标注者参与标注，最终形成 160 个系统相关失败案例。

5. 错误类型：记忆系统失败发生在哪个生命周期阶段？

论文在附录中定义了七类错误。前两类主要与数据和评测有关，后五类对应记忆系统本身的信息流生命周期。

错误类型 含义
Annotation Error 数据集提供的源证据不足以支持参考答案，或参考答案本身与证据不一致
LLM-as-a-Judge Error 系统回答实际上可以接受，但自动评测器错误地判为失败
Extraction Error 关键信息在记忆构建阶段没有被写入任何记忆单元
Update Error 记忆单元原本包含关键信息，但后续更新操作移除或削弱了这些信息
Deletion Error 含有关键信息的记忆被显式删除
Retrieval Error 记忆库中存在所需信息，但检索流程没有把它放入最终上下文
Response Error 检索上下文已经包含必要证据，但最终 LLM 仍生成错误答案

这个分类的价值在于，它不是简单地说“模型答错了”，而是把失败映射到记忆系统的信息生命周期中：信息是没有进入记忆、进入后被破坏、存在但没取出，还是取出后没被正确使用。

6. MemTrace 方法：把错误归因看成图探索问题

MemTrace 的核心思想是：不要一次性把整张执行图塞给模型，而是让一个 agent 沿着信息流逐步探索局部子图。

整体过程包含三个模块：

  1. 初始化起点；
  2. 执行图探索；
  3. 工作上下文管理。

image

【Figure 2。该图展示 MemTrace 从初始变量出发，逐步检查局部操作子图，最终在第三次迭代中定位错误操作的示例流程。】

6.1 初始化起点：用问题和标准答案找源消息

最朴素的方式是把问题和所有历史原始消息都放进待探索列表。但长程记忆轨迹可能跨很多会话，直接这么做会导致搜索空间过大。

MemTrace 的做法是使用混合检索来缩小起点范围：

  1. 把问题和标准答案拼接成检索 query；
  2. 对历史原始消息同时执行稠密检索和稀疏检索；
  3. 使用 Reciprocal Rank Fusion 融合两个排序列表；
  4. 选出最相关的一部分消息，与当前问题一起形成初始待探索列表。

这样，agent 一开始就更可能站在与失败问题相关的信息源附近，而不是在完整历史中盲目搜索。

6.2 图探索：按时间优先沿信息流向下追踪

MemTrace 维护一个有界的待探索列表。列表中的元素是变量节点，并按照变量插入执行图的时间排序，时间更早的变量优先级更高。这一设计使 agent 更倾向于先检查较早发生的操作，从而找到更早的错误来源。

在每次迭代中，MemTrace 会：

  1. 从待探索列表中取出时间最早的变量；
  2. 找出所有直接涉及该变量的操作；
  3. 把每个操作对应的局部子图转成文本表示；
  4. 让 agent 判断这个操作是否满足“决定性错误”的条件；
  5. 如果当前操作没有错，就沿着信息流把相关下游变量加入待探索列表；
  6. 直到找到目标错误操作，或达到最大推理步数。

这里的关键不是简单搜索关键词，而是沿着变量和操作之间的依赖关系移动。这样可以追踪关键信息从原始消息到记忆单元、再到检索结果和最终回答的生命周期。

6.3 工作上下文管理：避免执行图过大

记忆系统的执行图可能非常大，变量值也可能很长。MemTrace 因此提供了几种上下文控制方式：

  • 对操作子图使用轻量预览模式，默认省略具体变量值；
  • 让 agent 只在需要时检查相关变量；
  • 对大变量支持分页和正则搜索；
  • 对操作子图文本表示也支持分页；
  • 当工作上下文超过安全阈值时，自动做上下文摘要。

这部分设计的目标是让 agent 能处理大型执行轨迹，而不是被完整日志或完整图结构淹没。

6.4 MemTrace-OBS：基于操作搜索的对照方法

论文还提出了一个对照方法 MemTrace-OBS。它不是沿图依赖逐步移动，而是把操作内容拼接成弱结构化日志，并给 agent 一个全局操作搜索工具。agent 可以使用正则表达式搜索相关操作块。

这个方法的优势是成本更低，尤其适合图结构不强、类似长上下文更新的轨迹。但它也更容易跳到某些关键词附近，而不是严格沿信息流推断错误传播路径。

7. 实验设置

论文使用两个 agent backbone：

  • GPT-4.1 mini；
  • GPT-5.4。

主要评估指标包括：

指标 含义
ETA Error Type Accuracy，错误类型预测准确率
OIA Operation Identification Accuracy，错误操作识别准确率
Tokens 每个错误案例归因所需平均 token 成本，单位为千 token
Time 每个错误案例端到端运行时间，单位为分钟

实验在四种记忆系统上分别评估，并报告整体结果。

8. 主要实验结果

8.1 图探索提升错误类型归因，尤其有利于较小模型

论文 Table 1 显示，在 GPT-4.1 mini 上，MemTrace 的整体 ETA 从 MemTrace-OBS 的 20.00% 提升到 36.46%。这说明对于较小模型，受约束的图探索可以帮助它沿信息流逐步检查，而不是被全局关键词搜索误导。

部分主结果如下：

Backbone Method Long-Context ETA RAG ETA Mem0 ETA EverMemOS ETA Overall ETA Overall OIA
GPT-4.1 mini MemTrace-OBS 9.17 25.83 33.33 11.67 20.00 9.38
GPT-4.1 mini MemTrace 20.83 41.67 35.83 47.50 36.46 14.17
GPT-5.4 MemTrace-OBS 7.50 87.50 60.00 60.00 53.75 46.25
GPT-5.4 MemTrace 20.00 72.50 70.00 55.00 54.38 38.13

一个重要现象是：OIA 明显低于 ETA。也就是说，判断“错在哪一类”比精确定位“哪个操作错了”容易得多。即使最好整体 OIA 也只有 46.25%，说明操作级错误定位仍然很难。

8.2 搜索式探索成本更低

Table 2 显示，MemTrace-OBS 的平均 token 成本和运行时间通常更低。原因是它不需要沿图逐步展开，而是直接用全局搜索定位操作块。

Backbone Method Overall Tokens Overall Time
GPT-4.1 mini MemTrace-OBS 859.17 2.41
GPT-4.1 mini MemTrace 1816.88 4.82
GPT-5.4 MemTrace-OBS 298.72 0.80
GPT-5.4 MemTrace 1875.49 4.09

这说明两种方法存在取舍：

  • MemTrace 更结构化，更适合沿信息流解释错误传播；
  • MemTrace-OBS 成本更低，在弱结构化轨迹上尤其高效；
  • 但搜索式方法可能因为关键词跳转而误判错误类型。

9. 进一步分析：错误分布揭示不同记忆系统的瓶颈

论文 Figure 3 对 MemTraceBench 中的错误分布进行了分析。

image

【Figure 3。该图展示数据集中系统相关错误、标注错误、LLM-as-a-Judge 错误的比例，以及不同记忆系统上的错误类型分布。】

作者得到几个观察：

9.1 自动评测错误较少，但数据标注本身并不容易

论文发现，当 LLM judge 判定有错误时，其判定通常是可靠的。少量分歧主要来自评测器过于严格，例如把基本正确但过长或不够具体的回答判错。

同时，长程记忆 benchmark 的高质量标注本身很难。错误可能来自问题不够精确、源证据不足，或者标准答案与支持证据不一致。RealMem 中的问题和参考答案更开放，因此标注主观性更强。

9.2 不同记忆系统有不同瓶颈

论文指出，不同系统的失败模式差异明显：

  • RAG 没有 extraction error，因为它没有抽取模块；
  • Mem0 和 EverMemOS 都依赖抽取；
  • EverMemOS 的抽取错误较少，说明其抽取模块在论文实验中更稳健；
  • Mem0、EverMemOS 和 RAG 都会出现检索错误，部分原因是实验只取 top-10 记忆单元；
  • Long-Context 按设计不做检索，因此没有 retrieval error；
  • 论文没有观察到 deletion error，可能因为只有 Mem0 支持删除，而且当前 benchmark 很少测试删除行为；
  • 所有系统都有 response error，说明即使相关记忆已经被取出，如何有效使用它们生成正确答案仍然是问题。

10. 额外信息能提升归因效果

在真实开发中，调试者往往有两类额外信息：

  1. 对记忆系统 pipeline 的高层理解；
  2. evaluation set 提供的源证据。

论文测试了把这两类信息加入 MemTrace 的效果。实验排除了 Long-Context 子集，因为该设置与其他记忆系统差异较大。

Table 3 的结果显示：

Backbone Method ETA OIA Tokens Time
GPT-4.1 mini MemTrace 41.67 17.50 932.14 4.07
GPT-4.1 mini + Source Evidence 40.55 27.22 575.69 1.14
GPT-4.1 mini + Prior Knowledge 46.39 23.89 947.32 3.69
GPT-4.1 mini + Both 45.83 29.44 521.80 1.43
GPT-5.4 MemTrace 65.83 44.17 1659.04 3.74
GPT-5.4 + Source Evidence 69.17 54.17 1036.69 2.41
GPT-5.4 + Prior Knowledge 64.17 45.83 1837.41 4.94
GPT-5.4 + Both 70.00 58.33 1475.29 3.06

结果说明，源证据能提供更准确的起点，从而提升 OIA 并降低成本；系统先验知识也能提升 OIA，但会增加 token 成本。两者结合时，整体归因表现最好。

11. 应用一：生成记忆系统诊断报告

除了逐个案例定位错误，MemTrace 还能把操作级归因结果聚合成诊断报告，帮助开发者看到系统在哪些组件上容易失败。

论文把这种分析应用到 Mem0 和 EverMemOS：

  • 对 Mem0，报告发现抽取模块倾向于保留高层用户信息，但会丢失细粒度细节；还发现更新阶段存在时间戳重新分配问题，即内容不变但时间被修改。
  • 对 EverMemOS，报告没有观察到主要抽取错误，但在 response stage 中出现聚合和计数失败；同时定位到若干检索组件问题，包括 reranker、sufficiency checker 和 query reformulation module。

这说明执行图级归因不仅能回答“这个 case 为什么错”，也能帮助开发者总结“这个系统整体在哪些 pipeline 组件上容易错”。

12. 应用二：用错误归因指导自动优化

论文进一步把 MemTrace 用于自动优化记忆系统。

非参数化记忆系统往往包含大量手写 prompt。直接做自动 prompt optimization 很难，因为多会话执行轨迹很长，优化器难以同时处理完整轨迹、长因果链和系统重放。

论文的做法是把“信用分配”和“prompt 改写”解耦：

  1. smartcomment 记录运行时执行图；
  2. MemTrace 在执行图上定位最早的决定性错误操作；
  3. 一旦定位到错误操作，优化问题就变成局部问题：只需要优化参与这个操作的小集合 prompt；
  4. 不需要把完整轨迹放进优化器上下文，也不需要重放整条记忆 pipeline。

image

【Figure 4。该图展示 MemTrace 如何参与 Mem0 自动优化闭环，以及三轮优化后的性能提升。】

论文在 Mem0 + LoCoMo 上评估该闭环优化流程，使用 LLM-as-a-judge score 作为指标。作者随机抽取三个用户作为训练集，其余七个用户作为测试集。三轮优化后，Mem0 在 held-out test split 上提升 7.62%。值得注意的是，这一提升是在 MemTrace 并不完美的情况下实现的：论文报告此处操作识别准确率为 72.5%。这说明即使归因不完全准确，图结构归因也能为实际 prompt tuning 提供可用信号。

13. 相关工作位置

论文把自己放在两个方向之间：

  1. LLM 记忆系统：这些工作让模型能够跨会话抽取、更新、遗忘和维护记忆，但也引入了复杂执行管线。
  2. LLM agent 诊断：已有方法多关注单个任务实例中的短推理轨迹，例如判断哪一步推理或工具调用出错。

MemTrace 的不同点在于，它关注的是有长期状态的记忆系统。失败可能来自更早会话，并且必须从大量无关历史交互中区分出来。因此，论文强调执行图和变量依赖，而不只是当前任务轨迹中的线性步骤。

14. 论文指出的局限性

论文把这项工作定位为自动诊断非参数化记忆系统的初步探索，并指出几个开放方向：

  1. Benchmark 规模和多样性仍可扩展
    MemTraceBench 覆盖了多个代表性记忆系统和长程记忆 benchmark，但仍可以纳入更多类型的记忆，例如任务记忆和多模态记忆。

  2. 当前主要关注单个决定性错误操作
    论文当前的形式化和 benchmark 聚焦于决定性错误集合为单个操作的情况。更复杂的 agent 系统可能存在多个独立错误共同导致失败，尤其是多子 agent 并行执行再聚合结果的系统。

  3. 归因方法还有提升空间
    论文认为一个有前景的方向是结合全局操作搜索和局部图探索：先快速定位相关区域，再在结构化依赖邻域中推理。

  4. 方法可能推广到其他复合系统，但仍需验证
    虽然论文聚焦非参数化记忆系统，但记录执行图并进行 agentic failure attribution 的思想更通用。未来可以测试 smartcomment 和 MemTrace 在动态任务规划、业务数据工作流等其他有复杂状态演化的系统中的适用性。

15. 总结

这篇论文研究的是一个很实际但此前较少被系统化处理的问题：长期记忆系统出错时，如何自动追踪错误源头。

它的主要贡献包括：

  1. 把记忆系统失败归因定义为执行图上的错误追踪问题；
  2. 用 operation-variable graph 表示记忆变量和操作之间的信息流；
  3. 构建 MemTraceBench，包含 160 个系统相关失败案例及人类错误归因标注；
  4. 提出 MemTrace，用 agent 沿执行图局部探索，定位错误类型和错误操作；
  5. 展示错误归因信号可以用于诊断报告和自动 prompt 优化。

从论文结果看，精确定位错误操作仍然困难，OIA 明显低于 ETA，说明“知道错在哪一类”和“知道具体哪一步错了”之间还有较大差距。但论文展示了一条清晰路径：把记忆系统从黑盒输入输出，转化为可追踪、可解释、可干预的信息流图。对于越来越复杂的长期记忆 agent，这类诊断机制可能会成为系统开发和维护中的基础工具。

参考

  • Xinle Deng et al. MemTrace: Tracing and Attributing Errors in Large Language Model Memory Systems. arXiv:2605.28732v1, 2026.
  • 原文链接：https://arxiv.org/abs/2605.28732
posted @ 2026-06-18 10:09  YourF4u1t  阅读(21)  评论(1)    收藏  举报