memorybench
统一评测框架,评估 AI 记忆系统在多轮对话中的检索与记忆能力
加载项目详情…
本应用为开源项目,仅供学习研究,请遵守其开源协议。
统一评测框架,评估 AI 记忆系统在多轮对话中的检索与记忆能力
加载项目详情…
本应用为开源项目,仅供学习研究,请遵守其开源协议。
想象一下:你正在和一位 AI 助手聊天,过程中聊到了三个月前你们讨论过的一个技术细节。当话题再次触及那个方向时,这位助手能否准确回忆起三个月前的结论,还是彻底「失忆」了?——这就是 MemoryBench 想要回答的问题。
AI 记忆系统(Memory Layer)是近年来快速崛起的基础设施层。从 Mem0、Zep 到 Supermemory,众多团队都在构建「让 AI 记住对话历史」的服务。但问题来了:这些记忆系统的实际表现究竟谁更好?
supermemoryai 团队在开发 Supermemory 的过程中,发现了行业评测的三个致命问题:
第一,评测框架搭建成本太高。 每换一个基准测试数据集,就要重新写一套数据导入、检索接口、评分逻辑的代码,工作量远超实际评测本身。
第二,评测标准不统一。 有的项目用准确率,有的用召回率,有的用自定义评分,跨项目横向对比几乎不可能。
第三,评测过程不可复现。 没有 checkpoint、没有标准化报告,调试成本高,而且结果难以验证。
MemoryBench 正是为解决这三个问题而生的:它提供一套统一的评测框架,把任何记忆提供者(Provider)和任何基准数据集(Benchmark)自由组合,用同一套流程跑完,再用同一个评分标准输出结果。
MemoryBench 的设计哲学用一句话概括:「记忆提供者 ↔ 评测管道 ↔ 评判模型」三者完全解耦。
┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│ Benchmarks │ │ Providers │ │ Judges │
│ (LoCoMo, │ │ (Supermem, │ │ (GPT-4o, │
│ LongMem..) │ │ Mem0, Zep) │ │ Claude..) │
└──────┬──────┘ └──────┬──────┘ └──────┬──────┘
└──────────────────┼──────────────────┘
▼
┌───────────────────────┐
│ MemoryBench │
└───────────┬───────────┘
▼
┌────────┬─────────┬────────┬──────────┬────────┐
│ Ingest │ Indexing│ Search │ Answer │Evaluate│
└────────┴─────────┴────────┴──────────┴────────┘
Benchmarks(基准数据集):目前内置了三个对话记忆评测集——LoCoMo、LongMemEval、ConvMem,分别覆盖长程对话、多跳推理和对话状态追踪等场景。开发者还可以通过 src/benchmarks/ 接口扩展自定义数据集。
Providers(记忆提供者):内置支持 Supermemory、Mem0、Zep 三家主流记忆 API,以及一个本地文件系统 Provider(RAG 基准对比用)。通过 src/providers/ 接口可以接入任意兼容的记忆系统。
Judges(评判模型):评测结果由大模型(GPT-4o、Claude、 Gemini 等)评判,通过对比生成答案与真实标签,给出准确率评分。这一层同样通过 src/judges/ 接口完全可扩展。
整个评测管道分为六个阶段,每个阶段独立 checkpoint,失败后可从上次断点恢复:Ingest → Indexing → Search → Answer → Evaluate → Report。
MemoryBench 提出的核心指标是 MemScore,它由三个维度组成,用 / 分隔:
accuracy% / latencyMs / contextTokens
MemoryBench 故意不把这些维度压缩成单一数字。supermemoryai 团队认为,将质量、延迟和成本混为一个「综合分」会掩盖关键信息。比如,一个检索极快但准确率一般的系统,和一个慢但精确的系统,合成一个分数后反而无法帮助决策。MemScore 让开发者可以针对自己的业务场景做权衡。
MemoryBench 不仅有命令行工具,还内置了一个基于 Next.js 的 Web UI。通过 bun run src/index.ts serve 启动后,可以实时查看:Runs 列表及进度、各 Provider 在不同 Benchmark 上的准确率对比柱状图、失败的问答对详情,以及多 Provider 并排横向对比(Compare)功能。
Web UI 的核心组件包括:accuracy-bar-chart.tsx(柱状图对比)、benchmark-results.tsx(结果展示)、data-table.tsx(表格展示)和 phase-progress.tsx(各阶段进度),整体使用 Tailwind CSS 样式。
从 package.json 可以看出项目的技术选型:
tsconfig.json 配置严格模式)@ai-sdk/* 系列(@ai-sdk/openai、@ai-sdk/anthropic、@ai-sdk/google),通过统一的 AI SDK 接口调用 GPT-4o、Claude、Gemini 等模型,保持 Judge 扩展性ui/ 目录)、Tailwind CSS、Radix UI 组件库src/server/ 包含 Express/Fastify 类 Web 服务、数据库路由、WebSocket(实时推送评测进度)架构层面,项目采用模块化插件架构:Provider、Benchmark、Judge 三者各自独立注册到索引文件,通过统一的接口类型(src/types/ 中的 TypeScript 类型定义)约束,形成可插拔的扩展体系。
安装:
git clone https://github.com/supermemoryai/memorybench
cd memorybench
bun install
cp .env.example .env.local
# 编辑 .env.local,填入需要的 API Key
跑一次完整评测:
bun run src/index.ts run -p supermemory -b locomo
对比多个 Provider:
bun run src/index.ts compare -p supermemory,mem0,zep -b locomo -s 5
启动 Web UI:
bun run src/index.ts serve
环境依赖方面,项目不支持 Docker,但通过 Bun 安装几乎零配置。硬件需求极低——整个框架只负责编排 API 调用,不做本地推理(评判模型和记忆 API 均为远程服务),因此对 GPU 和内存几乎无要求。唯一的前置条件是获取相关 API Key。
MemoryBench 评测的是「记忆 + 检索」环节,而非完整 AI 系统的端到端表现。评判模型(Judge)本身的偏好会引入偏差——GPT-4o 和 Claude 对同一问题的评判标准可能存在差异。此外,评测结果高度依赖 API 服务的实时状态(延迟数据受网络影响),同一 Benchmark 的结果在不同时间运行可能略有波动。
MemoryBench 的出现标志着 AI 记忆系统领域从「各说各话」走向「同台竞技」。在此之前,每家记忆服务都引用自己内部的评测数据,缺乏横向对比的公信力。有了 MemoryBench,开发者可以一键跑出同一套题目下多个 Provider 的表现,数据更具可比性。
同时,项目采用 MIT 开源许可证,框架本身完全透明,任何人都可以 fork 并添加新的 Provider 或 Benchmark,推动评测生态的持续扩展。
从技术趋势看,Agent 记忆化(让 AI Agent 拥有持久记忆)是 2025-2026 年的热门方向。MemoryBench 作为这一方向的底层基础设施,填补了「记忆系统评测」的工具空白,值得关注 AI 应用层开发的读者持续跟踪。

项目速览