给Agent记忆系统泼一盆冷水：长时程多目标干扰下，所有主流方案平均只有27.9%
核心摘要
如果你也在做长时程的智能体或者长记忆系统，可能会有一个体感——在你自己造的 demo 里跑得挺好，一上真实场景就开始翻车。MINTEval 这篇论文很硬地把这个体感量化了：他们把"信息会反复修订、互相冲突、互相覆盖"这件事当作一类显式的评测维度，造了一个跨四个领域、15.6k 道题、上下文平均 138.8k token、最长 1.8M token 的基准，然后把当前最能打的 7 套系统（Full Context、RAG、HippoRAG、MemAgent、AtomMem、Mem-α、SimpleMem）按在这个基准上拷打。
结论很扎心：平均准确率只有 27.9 个点，最强的 MemAgent 也只到 33.4 个点。更关键的是，作者把错误拆成"取证失败"和"答错"两个阶段，发现 41.7 个百分点的损失发生在检索/记忆构建阶段，而不是答题阶段。也就是说，瓶颈不在大模型不够聪明，而在记忆系统压根没把该留的东西留下。
这不是又一个长上下文 benchmark，它精准地戳中了"记忆系统在动态信息流里到底能不能用"这个被现有评测严重低估的问题。值得长记忆方向的同学认真读。
论文信息
| 项 | 内容 |
|---|---|
| 标题 | MINTEval: Evaluating Memory under Multi-Target Interference in Long-Horizon Agent Systems |
| 作者 | Hyunji Lee, Justin Chih-Yao Chen, Joykirat Singh, Zaid Khan, Elias Stengel-Eskin, Mohit Bansal |
| 机构 | UNC Chapel Hill；The University of Texas at Austin |
| arXiv | 2605.18565v2（2026 年 5 月） |
| 代码 | https://github.com/amy-hyunji/MINTEval |
一、为什么要再造一个记忆基准？现有的不够用吗
说实话，我刚看到这篇论文的标题时第一反应是"长记忆 benchmark 不是已经一堆了吗，LoCoMo、LongMemEval、MemoryAgentBench、Mem-α、StoryBench、OAKS……还要再来一个？"
读完前两节，我觉得作者抓住了一个被现有评测集体忽略的点——干扰（interference）。
什么叫干扰？这是认知心理学里几十年前就研究过的现象，分两种：
- 前摄干扰（proactive interference）：旧记忆影响新信息的存储和提取。"你以前学过的法语单词总会在你学西班牙语的时候冒出来。"
- 后摄干扰（retroactive interference）：新信息覆盖或扰乱旧记忆。"换了新手机号一段时间后，原来的号你就背不出来了。"
放到 LLM Agent 上是什么样子？想想这些场景：
- 一个 GitHub 仓库，你 commit 了 200 次，函数签名改过、文件移过、API 重命名过。用户问你"上一版的接口长啥样？"
- 一篇维基百科条目，被反复修订几百次，事实被加进来又被删掉、被改写、又被恢复。读者问你"在 2020 年的版本里，这栋楼写的是几层？"
- 你和一个对话 Agent 聊了三个月，期间你的居住城市、饮食偏好、家庭成员都变过。它需要回答"你大概在第三次搬家之后住在哪？"
这些场景的共同特点是：信息不是简单累积，而是在不断修订、覆盖、冲突。但作者一一翻看现有 benchmark 后发现：
| Benchmark | 输入互相依赖 | 干扰密集 | 多领域 | 多目标聚合 | 长距离回看 |
|---|---|---|---|---|---|
| MemoryAgentBench | ✗ | ✗ | ✓ | ✓ | ✗ |
| Mem-α | ✗ | ✗ | ✓ | ✗ | ✗ |
| LoCoMo | ✓ | ✗ | ✗ | ✓ | ✗ |
| LongMemEval | ✓ | ✗ | ✗ | ✓ | ✗ |
| BEAM | ✓ | ✗ | ✗ | ✓ | ✗ |
| StoryBench | ✓ | ✗ | ✗ | ✗ | ✗ |
| OAKS | ✓ | ✗ | ✗ | ✓ | ✗ |
| MINTEval | ✓ | ✓ | ✓ | ✓ | ✓ |
注意 OAKS 是最接近 MINTEval 的一个工作（同样有自然发生的干扰），但 OAKS 一个样本里平均只有 4.7 次干扰更新；MINTEval 平均是 86 次。一个量级的差距。
更狠的是另一个被作者明确点出的盲区——长距离回看（long-range lookback）。绝大多数现有 benchmark 都默认问的是"现在状态"，但真实业务里你常常需要问"两版之前的样子"。这个能力被系统性地避开了。
我自己的工程经验也对得上：用过的几款长记忆方案，在"问最新偏好"上都能糊弄过去，但只要问"上上次你说的那个东西是啥"，就基本歇菜。
所以 MINTEval 的定位不是"再来一个长上下文 benchmark"，而是第一个把动态修订/冲突/回看明确当成一等公民来评测的基准。
二、MINTEval 长什么样：四个领域、五种问题
图1：左侧是四个领域（state tracking、对话、GitHub commits、Wikipedia revisions）和五个问题类别；中间这一格是干扰的核心——"Mariah Carey 的 8th 冠军单曲" 被后来改成了 "7th"，事实自相冲突；右侧画出当前三类系统的典型失败：Full Context 太贵且超窗口，RAG 在冲突信息上检索错源，记忆 Agent 只盯最近一次改动而忽略历史。
四个领域：覆盖不同的演化模式
作者选的四个领域不是随便挑的，每一个对应一种典型的"信息演化模式"：
| 领域 | 数据源 | 演化方式 | 特点 |
|---|---|---|---|
| 状态追踪（bAbI） | 经典 bAbI 任务 | 覆盖式（overwrite） | 短而结构化的事实，状态被局部改写 |
| 多轮对话（HorizonBench） | 长程个性化对话 | 隐式偏好演变 | 用户偏好通过自然语言慢慢变化 |
| 维基修订（Wiki Revisions） | 真实维基百科修订历史 | 编辑式 | 事实被加、改、撤、改回来 |
| 代码演化（Git Commits） | 真实 GitHub 仓库提交历史 | 跨文件耦合修改 | 函数签名、API 命名跨文件演化 |
我特别喜欢 Wiki Revisions 和 Git Commits 这两个域的选择。它们不是合成数据，而是真实存在的、研究者每天都在用的"动态信息流"，比生造一些场景要可信得多。
五种问题：把"什么叫记忆好"拆开了问
问题分两大类：
单目标回忆：从长上下文里精准定位一条信息。 - Simple：当前最新状态是什么？（考的是抗前摄干扰——别被旧的搞糊涂） - History（lookback 风格）：之前某个版本的状态是什么？（考的是抗后摄干扰——别被新的覆盖掉）
多目标聚合：找到多条相关信息，再做推理。 - Ordering：把事件按时间排序 - Counting：在一系列更新中数次数（如"专辑被几个不同的制作人挂过名"） - Multihop：跨更新做桥接推理（如"第 5 集的标题在第 4 集第三次改名前是什么"）
这五个类别拆得真的挺漂亮的——它把"长记忆能力"从一个模糊的总分，拆成了五个可以分别诊断的子能力。
数据规模
总共 15.6k 道 QA：
| 领域 | 会话数 | 题数 | 平均 depth（更新次数） | 平均 token 数 |
|---|---|---|---|---|
| bAbI | 99 | 5.7k | 42 | 0.3k |
| HorizonBench | 100 | 6.9k | 142 | 274k |
| Wiki Revisions | 196 | 1.5k | 99 | 195k |
| Git Commits | 200 | 1.6k | 61 | 86k |
平均一个上下文 138.8k token，最长达到 1.8M token——比 GPT-4o、Claude 的上下文窗口还要长得多。这个量级在现有长记忆 benchmark 里基本是顶级。
题目生成方式分两种。bAbI 和 HorizonBench 走模板填充（结构化事实/元数据 → 模板 → 题），保证答案的 ground truth 严格可验证。Wiki Revisions 和 Git Commits 因为有复杂的修订元数据（revision_ids、timestamp、editor、comment），用 Gemini-3.1-Pro 基于完整修订历史去生成题。然后人工抽检 20%（每个 session 五种题型各抽一道），95.6% 通过——这个数字说明合成题的质量是站得住脚的。
三、被拷打的七套系统
作者评测的是当前这一波长记忆方案的代表：
- Full Context：把全部上下文塞进窗口（baseline）
- RAG：稠密向量检索 top-5
- HippoRAG（2025）：图结构 RAG，建图捕捉文档间关系
- MemAgent（2025）：基于 Qwen2.5-14B 的 RL 训练记忆系统，构建 query 相关的记忆表征
- AtomMem（2026）：把记忆操作显式拆成 CRUD 原子操作（Create/Read/Update/Delete），用 SFT+GRPO 训出来
- Mem-α（2025）：把记忆分成 core / semantic / episodic 三层，RL 训练
- SimpleMem（2026）：当前 SOTA，三阶段管线（语义压缩 → 在线合并 → 意图感知检索）
answering agent 默认是 Qwen3.6-35B-A3B，向量模型用 Qwen3-Embedding-4B；同时还测了用 Gemini-3.1-Flash-Lite + Gemini-Embedding-001 的高配组合。评测指标是 Exact Match。
四、主结果：所有人都被按在地上摩擦
直接看主表（Qwen3.6-35B-A3B 作为答题模型）：
| 任务类别 | Full | RAG | HippoRAG | AtomMem | Mem-α | MemAgent |
|---|---|---|---|---|---|---|
| bAbI Simple | 57.4 | 66.7 | 70.0 | 65.2 | 82.6 | 85.7 |
| bAbI History | 16.1 | 16.7 | 33.3 | 36.3 | 44.9 | 36.0 |
| bAbI Ordering | 22.0 | 37.5 | 50.0 | 58.1 | 64.7 | 59.0 |
| bAbI Counting | 40.5 | 80.0 | 80.0 | 43.8 | 70.4 | 24.3 |
| bAbI Multihop | 30.8 | 40.0 | 41.7 | 30.7 | 61.0 | 51.7 |
| Wiki Simple | 23.3 | 36.7 | 37.9 | 16.9 | 49.9 | 54.2 |
| Wiki History | 14.5 | 30.2 | 31.1 | 15.7 | 20.6 | 28.8 |
| Wiki Ordering | 10.9 | 6.9 | 4.1 | 2.4 | 13.5 | 38.3 |
| Wiki Counting | 22.2 | 15.9 | 19.1 | 14.3 | 25.0 | 36.5 |
| Wiki Multihop | 11.2 | 26.8 | 27.1 | 16.2 | 17.3 | 23.7 |
| Git Simple | 82.0 | 81.5 | 81.9 | 40.8 | 71.7 | 82.3 |
| Git History | 27.1 | 30.1 | 30.6 | 19.0 | 4.8 | 24.0 |
| Git Ordering | 17.7 | 40.6 | 44.5 | 13.8 | 17.0 | 55.9 |
| Git Counting | 21.1 | 38.9 | 14.1 | 24.7 | 18.8 | 51.6 |
| Git Multihop | 13.1 | 12.8 | 39.6 | 27.3 | 8.5 | 34.7 |
| HorizonBench Simple | 11.3 | 11.6 | 12.1 | 4.4 | 7.5 | 7.5 |
| HB History | 9.9 | 10.3 | 10.9 | 2.4 | 5.8 | 3.8 |
| HB Ordering | 3.5 | 4.2 | 3.9 | 1.0 | 0.4 | 6.7 |
| HB Counting | 0.8 | 2.8 | 4.2 | 2.9 | 1.6 | 1.8 |
| HB Multihop | 11.9 | 29.7 | 33.9 | 30.0 | 24.0 | 28.1 |
| 总平均 | 21.0 | 29.5 | 32.3 | 22.1 | 28.0 | 33.4 |
我盯这张表看了好一会儿。几个观察：
1）整体水平极低。 6 个系统平均 27.7%，最强的 MemAgent 只有 33.4%。这意味着当前所有主流长记忆方案在动态干扰场景下基本都不及格。
2）跨域泛化崩盘。 同一个 MemAgent，在 bAbI Simple 上能做到 85.7%，到 HorizonBench Simple 直接掉到 7.5%——80 个点的落差。HorizonBench 的题目本身就难（多轮对话里偏好的演化是隐式表达的，不像 bAbI 那么显式），但即便是相对最强的 HippoRAG 在 HorizonBench Simple 上也只有 12.1%。
3）单一冠军不存在。 没有任何一个方法能在所有领域+所有题型上都领先。MemAgent 在 ordering/counting 上很强（query-specific 的记忆构建有用），但 counting 在 bAbI 上居然只有 24.3%，被 RAG 的 80.0% 完爆——这种现象级的反差，作者很坦白地把它放出来。
4）同一题型，不同领域差距巨大。 Simple 题平均 47.5%，History 题平均 21.0%，多目标聚合平均 26.5%。长距离回看是公认的难——这正是作者强调的"现有评测严重低估"的能力。
看到这张表的时候我有一个直观感受：当前长记忆这套技术栈距离"在真实业务场景里能稳定用"还有相当一段距离。把它当成 demo 跑跑可以，当成产品上线就要小心了。
SOTA 的 SimpleMem 也救不了场
作者还专门测了一组：用 SOTA 的 SimpleMem 配上 Gemini-3.1-Flash-Lite 当答题模型 + Gemini-Embedding-001 当向量模型——也就是最贵的、最好的组合。
结果：平均 30.3 EM。
顺便说一下 SimpleMem 这套在 LoCoMo（一个对话记忆 benchmark）上是当前最强的方案。但在 MINTEval 上它的核心问题暴露了——它的记忆压缩太激进。LoCoMo 平均上下文 109 字符，事实之间几乎独立；MINTEval 平均 184k 字符，事实之间高度互相依赖、互相修订。激进压缩在前者是优化，在后者是直接把溯源信息（provenance）和历史细节扔掉。
这件事挺有意思：一个方法在某个 benchmark 上 SOTA，不代表它的范式是对的，可能只是对那个 benchmark 的特定假设过拟合了。
五、错在哪？分阶段做一次"尸检"
这是我觉得这篇论文最值钱的一节。作者没有止于"这些系统不行"，而是把失败拆成两个阶段：
- 检索/记忆构建失败（取证就没拿到）
- 答题失败（证据在手，但答错）
图2：四个系统（RAG / HippoRAG / AtomMem / MemAgent）的错误分阶段拆解。柱子总高 100% 是"完美系统的上限"。绿色实心 = 记忆/检索结果中包含答题所需证据的比例；蓝色实心 = 最终答对的比例。两条斜线分别表示记忆构建阶段和答题阶段的损失。
具体数字：
- 检索/记忆构建阶段平均损失 41.7 个百分点——只有 58.3% 的样本，记忆里压根包含正确证据
- 答题阶段额外损失 25.2 个百分点——证据在记忆里，但答题模型没用对
这个拆解戳破了一层窗户纸：
当前记忆系统的瓶颈不在大模型不够聪明，而在记忆系统压根没把该留的东西留下。
而且作者还做了一个很关键的对照：
- Full Context 设置下，把答题模型从 Qwen3.6-35B-A3B 换成 Gemini-3.1-Flash-Lite，整体涨了 55.7 个点——说明答题模型本身的强弱是有用的
- 一旦加了记忆/检索系统，再换答题模型只能涨 1.7 个点——记忆系统决定了下限，答题模型基本失去了发挥空间
这就是要害。 你花再多钱换更强的答题模型，只要前面的记忆环节把证据丢了，下游就是巧妇难为无米之炊。要做长记忆，先把记忆构建做对，再谈答题。
六、距离越远越糟，但时间戳能救命
图3：横轴是回看距离（要查询的状态距离当前有多少次更新），纵轴是准确率。Full Context 起点高但跌得最猛——窗口能装下时它最强，越远越无力。RAG/HippoRAG 中等。两个 memory agent 起点不高但下滑相对平缓——它们用累积式记忆把时间结构编码进去了，对远距离更鲁棒。
这张图说明两件事：
- 所有方法都怕远。距离越远，准确率单调下降。
- 但下降斜率不一样。Full Context 和 RAG 下降最猛——它们没有显式的时间结构，远的事实就跟近的事实搅在一起。memory agent（尤其是 MemAgent）下降相对平缓，因为它把时间顺序累积在记忆里。
更有意思的是作者还做了一个"温度计"实验——在事实和问题里显式加上时间戳/日期会怎样？
附录数据是这样的（Wiki Revisions 上 Full Context 和 RAG 在最远 lookback 距离的退化幅度）：
| 不加时间戳 | 加时间戳 | |
|---|---|---|
| Full Context 退化 | 13.22 | 5.48 |
| RAG 退化 | 31.43 | 10.45 |
RAG 加了时间戳之后，退化幅度从 31.43 降到 10.45——几乎砍掉了三分之二。
这个发现挺反直觉但又挺合理：干扰之所以毁灭性，是因为相似的事实没法区分；只要给它们打上不同的时间标签，互相干扰立刻减弱。这个 insight 对工程落地很重要——很多时候你不需要换一个全新的记忆系统，只要在数据流里把时间戳明确地保留下来、暴露给 retriever，就能拿到不小的提升。
七、噪声实验：RAG 最怕"领域内噪声"
图4：横轴是噪声句子数量（0/1/3/5），纵轴是准确率。两种噪声：OOD 来自小说语料（风格结构不同）、ID 跟 bAbI 同样的"主谓宾"简洁结构。橙色 BaseRAG 在 OOD 上崩得最狠，蓝色 Full 和绿色 MemAlpha 相对稳。
这个实验很有意思。直觉上你会觉得 OOD（风格完全不同的噪声）应该好处理才对——它跟原本的事实差异那么大，应该一眼就能识别出来啊？
但 RAG 的结果是反过来的。OOD 噪声让 RAG 崩盘，因为：
RAG 的 retriever 是基于 embedding 的语义相似度。OOD 风格的噪声句子虽然内容无关，但有时候 embedding 上反而离 query 更近（语义空间的几何不直观），结果 retriever 把噪声当成了答案证据。
而对 Full Context 和 Mem-α 来说，OOD 噪声反而更容易被忽略——直接读全文的话，风格突兀的句子很容易被识别为不相关。
附录里还有一个补充观察：ID 噪声对 Counting 和 History 的伤害远大于对 Simple 的伤害——因为这两类任务本来就需要多目标聚合或时序追踪，多塞几条相似的事实进去，模型就更容易数错或定位错。
这个发现对做检索系统的同学有直接启示：不要只看 retriever 在 clean 数据上的 recall，要测它在 ID-style noise 干扰下的鲁棒性。BABILong 这个工作（2024）也是用类似思路在测，但 MINTEval 把它扩到了更复杂的多领域多题型。
八、记忆操作的暗病：所有人都在"加"，不会"改"和"删"
这是另一个让我皱眉的发现。
AtomMem 和 Mem-α 都把记忆管理拆成三种操作：插入（Insert）、修改（Modify）、删除（Delete）。听起来很合理对吧？CRUD 经典套路。
但作者统计了实际操作分布：
| 插入占比 | 修改+删除占比 | |
|---|---|---|
| AtomMem | 87.6 个点 | 12.4 个点 |
| Mem-α | 65.9 个点 | 34.1 个点 |
看到 87.6% 这个数我愣了一下。这哪是 CRUD，这就是个 append-only log。
为什么会这样？作者给的解释挺到位：
- 修订往往是隐式表达。"该 API 不再支持 v1.2.30 之前的输入格式"——这是一次修改，但模型识别不出"诶这其实是在改之前那条记忆"。它默认就 insert 一条新记忆。
- 操作粒度太粗。两个系统都倾向于在 chunk 级别操作而不是 fact 级别，结果细微差异被忽略，整块当新东西塞进去。
后果是显而易见的——记忆里堆满了冗余、互相冲突的旧版本，越长越混乱。
这个发现让我想起之前一些工业实践里的"长记忆退化"问题：随着对话变长，模型对用户的画像越来越糊，因为新旧偏好都在记忆里，找不到准确的最新状态。MINTEval 给这个体感找到了量化证据——记忆系统天然 bias 到 insert，没有有效的 modify/delete 机制。
chunk size 的影响
图5：chunk size 越大（一次处理的内容越多 = 记忆更新次数越少），整体准确率越高。Simple 几乎不受影响（它只关心最新状态）；其他四类都明显受益于大 chunk。
这个图也很反直觉。你可能以为 chunk 越小、更新越频繁，记忆越精细，应该越好？
实际是反过来——更新次数越多，意外覆盖、误删的风险越高，记忆一致性越难维持。
这个发现跟前面的"insert 偏置"是呼应的：既然每次 modify 都不靠谱，那就尽量少做几次操作，每次操作消化更多内容。
九、批判性审视：MINTEval 真的没问题吗
到这儿要泼自己一点冷水，不能只跟着论文的结论走。我读完后留下的几个怀疑：
1）合成题的"难度"是不是过度集中在某些表达上？ Wiki Revisions 和 Git Commits 的问题是 Gemini-3.1-Pro 生成的。虽然作者做了 20% 的人工校验、95.6% 通过，但人工校验主要是验证"问题自然+答案正确"，没法验证"难度分布是不是被生成模型的偏置带歪了"。我会担心生成模型偏好出某种类型的题（比如更喜欢出"对比版本差异"的 multihop），导致评测结果在某个维度被放大。
2）EM 作为指标有点严苛。 论文用的是 Exact Match。对于 bAbI 这种结构化输出还行，但对于 Wiki Revisions 的开放式回答，EM 可能严重低估了模型的真实理解能力——模型可能答对了语义但表达不一致就 0 分。HorizonBench 走了 multiple-choice，但其他三个域基本是 EM。我觉得作者应该补一个 LLM-as-judge 的评估作为参考——尤其是当几乎所有方法都在 30% 以下时，EM 和真实理解之间的相关性可能会被噪声淹没。
3）answering agent 的选择有没有偏向？ 默认用 Qwen3.6-35B-A3B 这个相对小一点的模型作为答题模型，会不会让 Full Context 的上限被人为压低？作者也确实测了 Gemini-3.1-Flash-Lite 在 Full Context 下涨了 55.7 个点，但主表里没有用更强的模型来"压住下限"，可能让"所有方法都很差"这个结论显得更扎眼。
4）SOTA 系统的失败可能是配置问题。 SimpleMem 在 LoCoMo 上是 SOTA，在 MINTEval 上崩盘——作者归因为"激进压缩"。但 SimpleMem 的压缩程度其实是可调的，作者用的应该是默认配置。如果给 SimpleMem 一个"低压缩+保留 provenance"的配置，分数可能会好不少。这一点附录 C.6 有讨论，但主表里直接拿默认配置打可能对 SimpleMem 略不公平。
但即便有这些质疑，核心结论我是认的：
- 干扰场景下当前所有主流长记忆方案都还很弱
- 瓶颈在记忆构建/检索，不在答题模型
- 记忆操作严重偏向 insert，缺乏有效的 modify/delete
这三个发现就足够让 MINTEval 成为这个方向的下一个必跑 benchmark。
十、对工程实践的启示
如果你也在做长记忆系统，这篇论文给我留下几个直接可以试的点：
1）把时间戳作为一等公民。 Wiki Revisions 上加时间戳让 RAG 的退化幅度从 31.43 降到 10.45。这是几乎免费的优化——只要在数据流里别把时间信息扔掉，retriever 就能拿到显著收益。如果你的系统现在还把 chunk 当成无序文档塞 vector DB，加时间戳是最快的 ROI。
2）减少记忆更新的频率。 chunk size 越大、操作越少，反而越好。这跟很多人直觉相反，但作者的数据是清楚的：减少不必要的 modify/delete 操作，保留信息完整性，比追求"实时同步"更重要。
3）显式区分新增与修改。 当前的 CRUD 训练范式让 insert 占了 87.6%，修改和删除几乎成了摆设。如果你在训练自己的记忆 agent，要在数据合成阶段就强行造出大量"这是修改不是新增"的样本，并设计明确的奖励让模型学会区分。
4）retriever 要测 ID 噪声鲁棒性。 OOD 噪声反而是简单情况，ID-style noise（同领域但内容无关）才是真正的杀手。在你自己的评测里加几条这种噪声，retriever 的弱点会立刻暴露。
5）不要被 LoCoMo / 对话 benchmark 上的 SOTA 蒙蔽。 SimpleMem 在 LoCoMo 上 SOTA，在 MINTEval 上直接崩盘——它的"激进压缩"假设在静态对话里成立，在动态修订里不成立。评测场景的假设决定了方法的有效边界。
十一、一句话总结
MINTEval 不是又一个"长上下文 benchmark"，它是第一个把"信息会变、会冲突、会被回看"明确当成一等公民来评测的基准。它告诉我们：
当前长记忆方案在静态、独立信息的世界里看起来还行，但一进入"信息会演化"的真实世界，所有人平均只剩 27.9 个点——而且瓶颈不在大模型，而在记忆构建本身。
这个方向上还有很多事情可以做：怎么让记忆系统真正学会 modify 和 delete？怎么把时间结构显式编码进 retriever？怎么在长程对话里识别"这是偏好变化不是矛盾陈述"？
如果你在做长程 Agent、个人助手、或者任何涉及"用户/世界状态会随时间变化"的产品，这篇论文以及它的代码（github.com/amy-hyunji/MINTEval）值得你 fork 下来跑一跑——你大概率会发现自己引以为豪的方案在上面也没那么能打。
但这不是坏事。诚实的 benchmark 才能催生诚实的进步。
觉得有启发的话，欢迎点赞、在看、转发。跟进最新AI前沿，关注我