召回率99.95%仍错37题，Membase找到证据却读错
Membase 是给 AI 代理用的记忆系统。对话、文档、任务执行记录，它都收进来，整理成能长期调用的记忆，让 AI 在后续对话里找回关键细节。三个长期对话回忆基准上，准确率分别是：LoCoMo 93.12%、LongMemEval_S 92.60%、DMR 92.20%。三个基准的规模是 1540 道题、500 道题和 500 组多轮对话。
内部按情景、语义、程序三种功能组织记忆。形成记忆时保存上下文和来源；新证据到达时会修订旧事实，但不抹掉历史，只给被取代的观察标上失效时间和替代引用；回答之前先积累证据。底层用 SQLite 存放原始记录、记忆和全文索引，FAISS 做向量索引。两套存储不共享事务，记录和索引的一致性需要显式恢复程序。观察器用八条消息的窗口切分对话，相邻窗口重叠两条。检索把词法命中和向量命中合并排序，用倒数排名融合。
这些分数说明记忆环节本身的水平已经相当高。剩下能出错的地方集中在三个动作上：压缩时压掉了什么、时间戳标成了哪一天、证据到了面前有没有读懂。
压缩是第一处。DMR 的 39 个错误来自叙述压缩时省略细节，比如保留了一个人的工作单位，却丢掉具体职位。细节一旦从所有叙述文本里缺失，检索再多的叙述也补不回来。
时间标注是第二处。LoCoMo 上，只给阅读器叙事上下文时准确率 93.12%；把观察文本也放进去，掉到 91.56%。时间类问题上差距更大：91.6% 对 82.9%。记录把一部分差异归因于附加在提取事实上的日期戳。一条事实标上会话日期，就可能被读成“那天发生的事”，哪怕原对话讲的是更早的事件。把观察文本加进上下文，等于给同一事实加了另一种表示，也就多了一个误解它的机会。这个对比考察的是检索上下文中的时间解释，并没有直接测试事实有效性间隔机制。
阅读是第三处。LongMemEval_S 完整运行中，检索召回率 99.95%，99.8% 的问题包含全部黄金会话，但 37 个错误答案发生在阅读阶段——证据就在上下文里，被读错了。阅读器可能把提议中的行动当成已完成的行动，或者把时间间隔算错。找到相关会话本身，并不能解决这些操作。
换一个阅读器，结果不统一
默认配置里，提取、决策和阅读用 gpt-4.1-mini，判断用 gpt-4o-mini，嵌入用 text-embedding-3-small。把阅读器从 gpt-4.1-mini 换成 gpt-5.5，在 LoCoMo 上准确率从 93.12% 变成 93.18%，42 个答案变好、41 个变差。同样的更换放到 LongMemEval 的 100 题固定存储样本上，准确率从 83.0% 拉到 96.0%。同一个动作在两个负载上效果完全不同，不能用来建立架构层面对任一模型的偏好。LongMemEval_S 的完整成绩用的是 gpt-5.5 阅读器。面对这种差异，合理的做法是在预期工作负载上先诊断答案失败，再决定算力投给检索还是生成。
延迟、上下文和没测的部分
搜索延迟中位数在三个数据集上是 1.67、2.53、1.13 秒；总延迟中位数 8.30、14.7、3.21 秒；平均渲染上下文 6562、8970、1602 tokens。
一个容易绕晕的点：记录里跑的是强调情景叙述和迭代检索的配置，产品默认走观察加单遍混合检索，两条路径并不执行同一套检索算法。检索不是一次查完——决策器接收原始问题、之前选中的核心证据和新候选，保留有用的记忆，对没解决的方面提出后续查询。连续两轮没有进展，循环就停了。每轮搜索都可能补上缺失证据，但也会消耗模型调用、扩大阅读器要检查的内容，当前记录没有隔离每一轮的边际收益。多等的那几秒换来的，不一定是更准的答案。报告的时间是工作量观察，不是服务保证。
记录里的实验只覆盖对话回忆。情景记忆的上下文保真度、语义记忆的知识准确性和随时间修订、程序记忆向新任务的迁移，都还没有被验证。三个基准触及了这部分空间，但没有分别建立三种能力。新的程序实验需要下游执行结果，而不是检索到的相似度分数。能记住一场对话说过什么，不等于能学会做一件新事。
文档里还有一些对开发者要紧的细节。系统缺一个统一的时间模型和跨记忆功能的自动编排；引擎没有直接尊重配置里的 Observer 和 Linker 字段，而是从 not_no_llm 派生它们的启用；摄取适配器按 30 秒间隔从会话日期构造消息时间戳，保留顺序但不保留原始消息时间；所有者过滤不是完整的租户授权；模型和嵌入调用可以走外部服务，内置本地嵌入提供者没有实现，本地持久化和 --no-llm 标记不构成完全本地计算。
与公开数字并排
在 LoCoMo 上，93.12% 与外部研究里 EverMemOS/MemoryOS 的 93.05% 只差 0.07 个百分点，这个接近既不表明优越性，也不表明等价性。DMR 上，Zep 的 98.2% 和全对话的 98.0% 用 GPT-4o-mini，Membase 的 92.20% 低于这两个分数；同一篇论文里 Zep 的 94.8% 和 MemGPT 的 93.4% 用 GPT-4-turbo，MemGPT 的值引自更早的工作，不能重新标注成 GPT-4o-mini 结果。
两边跑法也不一样。外部研究端到端运行 EverMemOS 和 MemoryOS，对其他系统用官方内存 API，并把 GPT-4o-mini 和两个辅助判断器的结果做了平均；Membase 单独使用 GPT-4o-mini。运行彼此分离、协议没有完全对齐，差距不能归给单一组件。
评估记录取自 2026 年 9 月 18 日到 21 日，修订版本 c7766de，没有重跑。Membase 集成了 EverOS 派生的组件，记录在 NOTICE 里。基准代码公开在 GitHub 仓库 unibaseio/membase-bench。三个准确率只属于那个时点、那套配置，代码留给了任何想自己验证的人。