浙江大学与阿里巴巴联合提出的记忆系统故障溯源框架

这项由浙江大学与阿里巴巴集团联合开展的研究，于2026年5月以预印本形式发布在arXiv平台，论文编号为arXiv:2605.28732。研究提出了一套名为MemTrace的自动化故障归因框架，专门用于诊断大型语言模型记忆系统中的错误来源。

你有没有遇到过这样的烦恼：你告诉一个AI助手你的饮食偏好，过了几轮对话之后它却忘得一干二净，或者更糟糕的是，它给出了一个完全错误的回答。你知道有问题，但根本不知道问题出在哪里——是一开始它就没记住，还是中途被什么覆盖掉了，还是在回答问题时用错了记忆？这就像一个厨师端上来一道难吃的菜，你想知道是食材有问题、烹饪过程出了错，还是最后摆盘时搞砸了，却发现整个厨房对你完全保密。

这正是这篇论文试图解决的核心问题。现代AI助手越来越多地配备了"记忆系统"——这些系统负责在多次对话之间存储、更新、检索用户信息，让AI能够跨越时间记住你说过的事情。但这些系统出错的方式非常隐蔽，错误可能在很早很早的某次对话中悄悄埋下，直到很久很久以后才在你的问题答案里暴露出来。研究团队把这个问题称为"记忆系统中的可溯源性缺口"——错误看得见，但错在哪儿看不见。

为了打破这堵墙，研究团队做了三件事：建立了一个让记忆系统运行过程完全透明的框架，构建了一个包含160个真实失败案例的测试基准，并设计了一个能自动顺着信息流追查问题根源的智能探案系统。更值得关注的是，他们还把这套探案系统用于自动改进AI的提示词配置，最终让一个名为Mem0的记忆系统在问答测试中提升了7.62%的表现。

一、记忆系统为什么这么难调试

在理解这项研究之前，需要先弄清楚"AI记忆系统"到底是怎么工作的，以及它为何如此难以调试。

把AI的记忆系统比作一家图书馆的运作来理解最为恰当。每当用户说了什么，图书馆的工作人员（AI系统）就会决定：这句话要不要记下来存档？怎么分类？存在哪个书架？后来如果用户又说了相关的话，工作人员还要决定要不要更新那本档案，甚至删掉旧档案。当用户提问时，工作人员要去书架上找相关档案，然后根据档案内容来回答问题。

这个过程中，每一个环节都可能出错。工作人员可能在存档时漏掉了关键细节；可能在更新档案时把正确的旧信息覆盖了；可能在检索时找错了档案；也可能找到了正确档案但最终给出了错误答案。

与普通软件调试不同的是，这家图书馆的运营跨越很长时间。第一次对话时存进去的档案，可能在第一百次对话时才被翻出来使用。而且整个图书馆的运营记录——也就是系统日志——是一个平铺开来的流水账，既没有清晰标注哪条记录和哪条记录有关联，也没有标明信息是怎么从一个环节流向下一个环节的。这就像你手里有一本厚厚的流水账本，里面密密麻麻写着每天发生了什么，但你看不出来昨天存进去的某条信息是怎么经过层层处理最终变成今天那个错误答案的。

已有的记忆系统评估方法更是只看结果，不看过程——它们能告诉你系统答对了还是答错了，却无法告诉你错误是怎么发生的。这就像学生考试考了低分，你只知道分数不好，但不知道是审题错了、计算出错了、还是最后誊写答案时抄错了。

二、把图书馆的运作变成一张可以追查的地图

研究团队提出的核心解决思路，是把记忆系统的整个运行过程变成一张带有方向的关系图，他们把这张图叫做"执行图"（execution graph）。

执行图里有两种节点：一种是"变量节点"，代表系统在运行过程中产生的各种具体内容，比如用户说的那句话、提取出来的记忆条目、检索到的结果、生成的回答等等；另一种是"操作节点"，代表系统对这些内容执行的具体动作，比如"提取信息""更新记忆""检索记忆""生成答案"等等。这两种节点之间用带方向的箭头连接，箭头的方向表明了信息流动的方向——哪个内容经过哪个操作，变成了什么新内容。

这张图和普通的日志有一个本质区别。普通日志是一条时间线上的流水账，告诉你"先发生了A，再发生了B，再发生了C"，但并不告诉你A和C之间有没有关系。而执行图则明确标出了信息的流向：当初用户说的那句话，经过"提取"操作变成了记忆条目X，记忆条目X后来被"更新"操作修改成了记忆条目X'，当用户提问时，X'经过"检索"操作进入了上下文，最终"生成答案"操作根据这个上下文产出了那个错误答案。这样一来，你就能清晰地看见这个错误答案背后的完整信息传递路径。

为了能自动构建这张图，研究团队还开发了一个轻量级的代码追踪工具包，取名为smartcomment。开发者只需要在记忆系统的源代码中插入少量标注语句，就能在系统运行时自动记录下每个操作的输入变量、输出变量以及它们之间的依赖关系。这个工具的设计哲学是"灵活插入，不需要重写"——不用把整个记忆系统改造成某种特定的框架，只需要在关键位置插几行标注代码，执行图就会自动生成。

研究团队还对"故障"给出了一个严格的数学定义。对于一个答错的案例，他们想要找到的是"决定性错误集合"——满足三个条件的最小操作集合：第一，集合里的每个操作本身确实执行错了；第二，集合里所有操作的"上游"操作（也就是更早发生的、为这些操作提供输入的操作）都是正常的；第三，如果把这个集合里出错操作的错误输出替换成正确的，那么原本答错的问题就会被答对。换句话说，这个集合是"最早的、最小的、一旦修复就能解决问题的操作组合"。在实际的记忆系统中，由于所有操作都是按顺序进行的，这个集合往往只包含一个操作——那个"第一个出错的操作"。

三、测试基准：给故障溯源系统准备考题

光有方法还不够，还需要有真实的测试案例来验证方法好不好用。研究团队为此构建了一个专门的测试基准，命名为MemTraceBench，并以MIT开源许可证发布。

他们从三个公开的长期记忆评测数据集中收集了问答对：LoCoMo数据集模拟长时间多轮对话；LongMemEval数据集包含每个轨迹一个问题的较长对话记录；RealMem数据集则更接近真实场景，问题穿插在对话过程中，金标准答案就是助手的下一条回复。

四个不同类型的记忆系统被纳入测试范围，代表了目前主流的记忆实现方案。长上下文记忆是最简单的方案，把所有历史对话直接保留在输入文本中，不做任何提取或压缩。RAG（检索增强生成）系统把历史信息分块存入数据库，回答问题时再检索相关内容。Mem0是一个更复杂的系统，支持记忆的增加、更新和删除，通过大语言模型来决定如何管理记忆条目。EverMemOS则是最复杂的一种，包含多轮检索、充分性判断和查询重组等复杂流程。

在收集测试案例的过程中，研究团队给每个记忆系统的源代码插入了smartcomment追踪代码，然后在采样的对话轨迹上运行这些系统，总共收集到了1514个不同的错误案例。随后，五位来自作者团队的标注人员对这些案例进行仔细审查，排除掉标注本身有问题或者自动评判器误判的案例，最终筛选出160个真正由记忆系统自身引起的失败案例。每个案例都配有问题、金标准答案、完整的执行记录，以及人工标注的错误类型、出错操作编号和失败原因说明。

研究团队还为这些错误建立了一个分类体系，把故障分成七种类型。标注错误和自动评判器错误属于"问题不在记忆系统本身"的情况。在真正的记忆系统故障中，提取错误指的是关键信息从一开始就没能被记录进记忆库；更新错误指的是信息存进去之后，某次更新操作把正确内容覆盖或破坏掉了；删除错误指的是记忆库里有正确信息，但被删掉了；检索错误指的是正确信息仍在库中，但检索时没找到；回答错误指的是检索到了正确信息，但最终生成的答案还是错了。

标注这160个案例并不容易。由于每个执行图平均包含2262个节点和3613条边，直接阅读几乎是不可能的任务。研究团队因此开发了一个交互式标注界面，让标注人员能够点击浏览、前向追踪和后向追踪信息流。即便如此，标注人员之间的分歧率仍然从3%到46%不等，充分说明了这项任务本身的难度。

四、MemTrace：顺着信息流追查罪魁祸首

有了执行图，接下来的问题是：如何自动找出那个"第一个出错的操作"？

研究团队提出的MemTrace方法，把这个问题变成了一个"带地图的探案任务"。在这张地图上，每个节点都是一条具体的信息（比如某段对话、某条记忆、某个检索结果），每条箭头都代表一次操作。探案的目标是：从已知的"案发现场"（答错的问题）出发，顺着箭头方向往上游追溯，找到那个最早犯下错误的操作。

整个探案过程分为三个模块。第一步是确定探查起点。如果从整个对话历史的第一条消息开始逐一检查，工作量会非常庞大，尤其当对话历史包含数百条消息时。MemTrace采用了混合检索策略来缩小范围：把失败问题和正确答案拼在一起作为检索查询，同时用稀疏检索（关键词匹配）和密集检索（语义相似度匹配）两种方式，从所有历史消息中找出最可能含有关键信息来源的那几条消息。两种检索结果通过一种叫做"倒数排名融合"的方法合并排序，选出最靠前的若干条作为探查起点。实验表明，在LoCoMo和LongMemEval这两个数据集上，即便是最弱的检索方法也能达到70%以上的召回率，说明用正确答案来检索来源消息是非常有效的策略。

第二步是在执行图上逐步探查。MemTrace维护一个带优先级的"待探查变量列表"，时间戳越早的变量优先级越高——这确保了探查是从早到晚进行的，符合"找最早出错的操作"这个目标。每次从列表中取出一个最早的变量，查看所有与这个变量相关的操作（无论是以它作为输入还是以它作为输出的操作），把每个操作及其局部信息子图转换成文本描述，交给一个大语言模型来判断：这个操作有没有出错？如果操作正常，就把这个操作产生的下游变量加入待探查列表，继续往后追；如果发现操作出了问题，就停下来，这个操作就是找到的故障点。这种"只看局部子图"的设计非常关键——因为完整的执行图可能有几百万个词的文本量，全部塞进大语言模型的上下文根本行不通，而局部子图只包含当前关注的操作和它直接相关的变量，规模可控得多。

第三步是管理工作记忆。为了防止随着探查深入、上下文越来越长，研究团队加入了几个实用的控制机制：支持"预览模式"，先只看操作名称和结构，不看具体变量内容；对长内容支持分页浏览和正则表达式搜索；当上下文超过预设的安全阈值时，自动对已探查内容做摘要压缩，腾出空间给新的探查步骤。

研究团队还设计了一个更轻量的变体，叫做MemTrace-OBS。这个变体不走"沿箭头一步一步追踪"的路线，而是把整个执行图压缩成一个按时间排序的"操作日志文本"，然后给模型提供一个全局搜索工具，让模型可以用正则表达式直接搜索感兴趣的操作片段。这种方式牺牲了严格的依赖关系追踪，但大幅降低了处理成本，特别适合那些执行图结构比较松散（比如长上下文记忆系统）的场景。

五、探案效果如何？实验结果揭晓

研究团队用两个大语言模型作为探案的"推理引擎"来测试MemTrace的表现：一个是较小的GPT-4.1 mini，另一个是更强大的GPT-5.4。

在错误类型预测准确率方面，MemTrace在两个模型上都表现出最好的整体表现。对GPT-4.1 mini来说，MemTrace的整体准确率达到了36.46%，远好于MemTrace-OBS的20%。这个差距揭示了一个有趣现象：较小的模型在没有图结构约束时，容易"走捷径"——直接从正确答案里提取关键词，跳到检索或回答相关的操作附近去搜索，如果找到了相关词就断定是提取环节的问题，而不是顺着信息流从早到晚仔细检查。图结构的约束强迫模型按照信息流的顺序从上游往下游探查，反而让它不容易走弯路。对GPT-5.4来说，两种方法的整体准确率相近（54.38% vs 53.75%），说明更强大的模型有能力在没有严格结构约束的情况下也做出较好的判断。

在具体操作识别准确率方面，所有配置下的表现都显著低于错误类型准确率，最好的成绩是GPT-5.4+MemTrace-OBS组合达到的46.25%。这说明确定"问题出在哪一类步骤"比确定"具体是哪一步操作出了问题"要容易得多。长上下文记忆系统的案例是最难处理的，因为这类系统的执行图结构非常类似一条长链，缺乏清晰的分支结构，模型在追踪过程中容易反复检查同一类操作，最后迷失方向。

在成本方面，MemTrace-OBS有明显优势。在长上下文记忆的测试案例中，MemTrace-OBS只消耗了MemTrace所用词符数量的15.25%和运行时间的27.94%。这个成本优势在结构松散的执行图上体现得最为明显，而在结构紧密的Mem0执行图上则相对较小。尽管MemTrace的成本更高，但研究团队指出，与人类专家手动排查相比，两种自动化方法都要快得多、便宜得多。

研究团队还测试了加入额外辅助信息对表现的影响。当把与问题相关的原始证据消息作为起点加入探查时，具体操作识别准确率显著提升，同时还降低了成本，因为起点更准确就意味着探查路径更短。当在任务提示中加入记忆系统流程的概要描述时，具体操作识别准确率也有所提升，但会增加一些词符消耗。两者同时加入时，效果最好，成本也比没有辅助信息时更低。

六、失败案例揭示的系统性规律

通过对160个标注案例的分布分析，研究团队发现不同记忆系统的失败模式存在显著差异，这本身就是一个非常有价值的发现。

RAG系统因为直接存储原始内容不做提取处理，所以完全没有"提取错误"，但检索错误占了很大比例。Mem0因为支持记忆更新和删除，错误模式最为多样，更新错误、提取错误、检索错误都有出现。删除错误几乎没有出现，因为在当前的测试数据集中，删除操作在Mem0的所有操作中只占约1%。EverMemOS的提取错误极少，原因在于它的提取模块更加健壮，能跨越不同类型的对话场景工作，对时间信息的处理也更好；但它的检索错误有一部分来自最终的重排序模块，这个模块有时会把正确的记忆条目排到前10名之外。所有系统都存在回答错误，说明即便检索到了正确内容，最终生成答案这一环节仍然是一个开放性挑战。

在数据标注质量的分析中，研究团队发现三个数据集都不同程度地存在标注错误。有的问题所附带的证据材料根本不足以支撑金标准答案（比如，证据里只提到了5次约翰赢得比赛，但金标准答案却是6次）；有的问题本身的描述引入了证据中根本没有提及的前提条件。RealMem数据集因为问答形式更开放，标注主观性更强，标注错误也更多。这些发现提醒我们：在长期记忆评测数据集上标注细粒度的故障信息，本身就是一件非常困难的事。

七、把探案成果用来自动改进记忆系统

发现故障在哪里，只是解决问题的第一步。研究团队更进一步，把故障定位的结果用来自动改进记忆系统本身。

他们的思路是：记忆系统严重依赖人工编写的提示词，修改提示词是改善系统表现最直接的手段。但现有的自动提示词优化方法在长期记忆场景下全都遇到了麻烦——反思式优化方法需要把整个对话历史塞进优化器的上下文，而长期记忆场景的对话历史动辄超过上下文窗口；候选方案评估法需要反复运行整个记忆流程来打分，成本极高；文本反向传播法需要把改进信号沿着整条因果链从末端一路传回起点，但因果链太长、信号传递过程中损耗严重。

MemTrace提供了一种绕过这些困难的方式。一旦定位到了那个出错的操作，提示词优化就变成了一个"局部小问题"：只需要针对那个操作涉及的那几条提示词，收集失败案例、总结失败规律、改写提示词。不需要处理整条因果链，不需要把整个对话历史塞进上下文，也不需要反复运行整个流水线。

研究团队用Mem0作为目标系统、LoCoMo数据集作为测试场景，实现了这套闭环优化流程。他们从数据集中随机挑选了3个用户的对话轨迹作为优化集，对Mem0的三类提示词进行优化：负责在建立记忆时提取关键信息的提示词，负责决定是否更新已有记忆的提示词，以及负责根据检索到的记忆生成最终答案的提示词。经过三轮优化，Mem0在剩余7个用户的测试集上的表现从基线提升了7.62%。

这个结果有一个值得关注的背景：MemTrace在这个实验中的操作识别准确率是72.5%，也就是说有将近三成的时候MemTrace并没有找到真正出错的那个操作。但即便如此，这套不完美的故障定位机制提供的信号，仍然足以为提示词优化提供有效的方向，最终产生了实质性的性能提升。这说明在实际应用中，探案工具不需要百分之百准确，只要能提供足够好的参考信息就能发挥价值。

八、自动生成系统诊断报告

除了用于优化，研究团队还展示了MemTrace在生成系统诊断报告方面的能力。通过把多个失败案例的故障定位结果汇总，再交给大语言模型进行归纳总结，可以自动生成一份针对整个记忆系统的详细分析报告，指出系统在哪类操作上集中失败、失败的规律是什么。

针对Mem0的诊断报告揭示了几个具体问题：提取模块倾向于只记录高层次的用户信息，丢掉细节；更新操作有时会在保留内容的同时错误地修改时间戳；检索模块在回答需要枚举多条信息的问题时表现差，因为它只返回和单条查询最相似的记忆，而不能保证覆盖所有相关条目。针对EverMemOS的诊断报告则发现：提取环节问题不大，但聚合和计数类问题在回答阶段频繁出现；检索流程中的重排序器、充分性检查器和查询重组模块都有各自特定的失败模式。这种"定位到具体流水线组件"的细粒度诊断，对于开发者改进系统来说是非常实用的参考。

这项研究也坦诚地承认了几个尚待解决的问题。目前的MemTraceBench规模还比较有限，未来可以扩展到更多记忆系统类型（比如任务记忆和多模态记忆）。当前的框架假设每个失败案例只有一个根本原因，但在更复杂的多智能体系统中，可能存在多个独立错误共同导致最终失败的情况，这种场景下如何扩展MemTrace是未来的重要方向。此外，图结构探查和全局操作搜索各有优劣，如何把两者结合起来——先快速定位感兴趣的区域，再在局部进行精细的依赖关系分析——也是一个有潜力的改进方向。

说到底，这项研究解决的是一个"看不见的问题"：AI记忆系统出了错，但谁也不知道错在哪。研究团队用一张精心设计的信息流地图，让整个记忆系统的运作从黑箱变成了透明的操作链条，再加上一个能顺着这条链条自动追查故障的智能探案工具，让原本需要专家花大量时间手动排查的工作，变得可以自动化、可以系统化地进行。7.62%的性能提升只是一个数字，背后更值得关注的是：这套框架提供了一种全新的思路，来应对AI系统越来越复杂、越来越难以调试这个普遍性的挑战。对于那些正在构建或使用AI记忆系统的开发者而言，这套工具的价值在于它能把模糊的"系统表现不好"变成具体的"第37个操作的提取逻辑有问题"，从而让改进工作有迹可循。有兴趣深入了解的读者可以通过论文编号arXiv:2605.28732查阅原始论文，代码也将在GitHub的zjunlp/MemTrace仓库开放。

Q&A

Q1：MemTrace的故障溯源准确率有多高？

A：MemTrace在错误类型预测上的准确率，使用GPT-5.4时整体达到54.38%，使用GPT-4.1 mini时达到36.46%。在更难的具体操作识别任务上，最好成绩是GPT-5.4+MemTrace-OBS组合的46.25%。这意味着系统还有较大提升空间，但即便是不完美的72.5%操作识别准确率，也能为Mem0的提示词优化提供有效信号，带来7.62%的实际性能提升。

Q2：MemTraceBench测试基准是如何构建的？

A：研究团队从LoCoMo、LongMemEval、RealMem三个公开数据集中采集问答对，在长上下文记忆、RAG、Mem0、EverMemOS四个记忆系统上运行，通过代码插桩工具smartcomment收集执行图，共获得1514个错误案例。五位标注人员经过三轮标注流程，最终筛选出160个真正由记忆系统引起的失败案例，每个案例都配有错误类型、出错操作编号和自然语言解释。

Q3：smartcomment工具和现有的日志追踪框架有什么本质区别？

A：现有的追踪框架主要是"事件中心"的，记录函数调用和输入输出，但不把变量之间的依赖关系作为一等公民来管理。smartcomment的核心区别在于它明确记录变量间的依赖边，让开发者能追踪一个记忆条目是如何被创建、被哪个操作修改、流向了哪个下游步骤。它不需要重写记忆系统代码，只需在关键位置插入少量标注语句，同时支持变量版本化，能还原记忆条目随时间演化的完整轨迹。