HaluMem：首个面向 Agent 记忆系统的操作级幻觉评测基准

想象这样一个场景：你的 AI 助手告诉你「上个月你和老板吵了一架」，但实际上那件事从未发生——对话照常进行，记忆凭空捏造。这类"记忆幻觉"（Memory Hallucination）正在成为大模型应用落地的最大隐患之一。随着 Mem0、MemOS、Zep、Memobase 等记忆系统大量接入 AI Agent，如何系统性地评测这些系统的幻觉程度就成了行业亟需解决的问题。MemTensor 团队发布的 HaluMem 正是为此而生。

背景：现有评测框架的根本缺陷

当前主流的记忆系统评测方案，普遍将记忆系统视为一个"黑箱"，仅通过端到端 QA 准确率来衡量好坏。这种做法有两个致命缺陷：

第一，幻觉评估不精确。 端到端 QA 只能告诉你「答对了」或「答错了」，但无法告诉你「错在哪里」——是记忆提取阶段就产生了幻觉，还是检索阶段出了问题？抑或是在记忆更新时发生了混乱？传统评测无法回答这个问题。

第二，操作步骤不透明。 记忆系统的工作流包含多个操作节点：提取（Extraction）、更新（Update）、检索（Retrieval）。每个节点都可能产生独立的幻觉。现有框架只测最终输出，掩盖了中间过程的隐患——就像只看考试成绩却不看平时作业，无法真正了解学生水平。

HaluMem 的核心创新，正是将记忆工作流拆解为三个原子操作，分别建立细粒度的幻觉评测标准。

核心设计：三大操作级评测任务

HaluMem 将记忆系统的工作流解构为三个基础操作，每个操作对应一种幻觉评测维度：

🧩 记忆提取（Memory Extraction）

评估系统能否从对话会话中准确地识别并存储事实信息，同时避免存储幻觉内容或无关信息。该任务同时衡量两个指标：

• 记忆完整性（Memory Recall）：参考记忆点被成功提取的比例
• 记忆准确性（Memory Accuracy）：提取的记忆与真实情况吻合的程度

🔄 记忆更新（Memory Update）

评估系统能否在新对话提供更新或矛盾信息时，正确修改或覆盖已有记忆，确保记忆库内部的一致性和时间连贯性。这个任务模拟的是现实中最容易出错的场景：用户更正了之前的说法，记忆系统是否跟进更新？

💬 记忆问答（Memory Question Answering）

评估系统整合多个记忆过程（提取→更新→检索）的端到端能力。给定对话历史，系统需要正确回答与用户长期记忆相关的问题。这是最接近真实使用场景的综合评测。

图1：HaluMem 与现有记忆系统评测框架的对比。传统方法只做端到端 QA，HaluMem 在操作级别进行细粒度评估。

技术架构：六阶段数据生成流水线

项目的数据生成流程设计精巧，共分 6 个阶段，通过精心设计的脚本流水线产出高质量评测数据：

阶段	脚本	核心功能
Stage 1	stage1_1~3	生成固定/动态用户画像、偏好数据
Stage 2	stage2_1~3	扩展动态数据、补全偏好、生成骨架
Stage 3	stage3_1~4	骨架扩展为行为轨迹、日常事件
Stage 4	stage4_1	从事件生成候选记忆点
Stage 5	stage5_1~2	生成对话、计算 token
Stage 6	stage6_1~3	生成问答对、汇总最终结果

配置高度参数化，核心配置在 config.json（23KB）中定义，涵盖了姓名、地点、教育程度、MBTI 人格、家人关系等丰富的模拟人格属性，支持生成多样化的长程记忆场景。

图2：HaluMem 整体评测框架。数据集基于真实人格画像生成对话，再由记忆系统处理后进行多维度评分。

评测工具包：支持 6 种主流记忆系统

项目 eval/ 目录提供了完整的评测工具包，支持对以下 6 种记忆系统进行统一评测：

适配器	系统	特点
eval_memzero.py	Mem0	默认版本
eval_memzero_graph.py	Mem0 Graph	图增强版本
eval_memos.py	MemOS	本地/在线部署
eval_memobase.py	Memobase	直连 PostgreSQL
eval_zep.py	Zep	异步设计，需分步执行
eval_supermemory.py	SuperMemory	第三方托管

评测流程分两步：首先运行对应记忆系统的评估脚本生成运行产物（提取记忆 + QA 结果），然后运行 evaluation.py 汇总评分。

图3：HaluMem 评测执行框架。支持本地部署和 API 接入两种模式。

技术栈与代码质量

项目采用 Python 3.11+，使用 Poetry 进行依赖管理，核心依赖包括：

• OpenAI SDK (openai ^1.109.0)：用于调用 GPT-4o 等大模型进行评测
• tiktoken：精确 token 计数，控制 API 成本
• tenacity：指数退避重试机制，保障 API 调用的稳定性
• pandas + pyarrow：高效处理结构化评测数据
• mem0ai / zep-cloud / memobase / supermemory：6 种记忆系统 SDK

代码结构采用模块化插件架构：每个记忆系统有独立的 eval_*.py 适配器，共享 eval_tools.py 中的评测函数和 llms.py 中的 LLM 调用封装。这种设计使得新增记忆系统适配器非常方便——只需实现统一的输入输出接口即可。

代码质量整体较高：有完整的类型提示（evaluation.py 中大量 typing 使用）、docstring 规范、重试机制完备、ProcessPoolExecutor 并行处理加速评测。

评分雷达图：直观呈现系统弱点

图4：HaluMem 评测结果雷达图，直观展示各记忆系统在多个评测维度上的表现差异。

部署方式与上手门槛

HaluMem 是一个纯研究型评测工具包，不提供 Docker 容器或 Web UI，部署需要一定动手能力：

1. 安装 Poetry 依赖：poetry install --with eval
2. 配置 .env 文件：填入 OpenAI API Key（必需）以及待测记忆系统的 API Key
3. 准备评测数据：从 HuggingFace 数据集 下载 data/ 目录
4. 运行评测脚本：python eval_memzero.py → python evaluation.py

硬件需求较低：无需 GPU，8GB 内存 + 2GB 磁盘即可。主要是 API 调用成本和数据下载量的问题。

特别值得注意的是：Zep 由于其纯异步设计，无法评测"记忆提取"任务；Memobase 缺少"获取对话记忆"的 API，需要直连 PostgreSQL 数据库。这些系统特定限制在 eval/README.md 中有详细说明，研究者需留意评测维度的覆盖范围差异。

局限性与行业意义

局限性：项目采用 CC BY-NC-ND 4.0 许可证，禁止商业使用，这对想要将 HaluMem 纳入商业 AI 产品评测流程的团队是硬性门槛。另外评测完全依赖 OpenAI API（或兼容 API），不支持本地开源模型直接评测，评测成本不可忽视。

行业意义：HaluMem 的价值在于将记忆系统的评测从"模糊的端到端准确率"推进到"透明的原子操作级幻觉分析"。这不仅有助于研究者在学术上理解不同记忆系统的弱点，更能指导工程师在生产环境中针对性地选择和优化记忆组件。数据集已开放下载（HuggingFace），研究社区可以复用。

随着 AI Agent 逐步成为 LLM 落地的主流形态，记忆系统的可靠性将成为决定 Agent 实际可用性的关键因素——HaluMem 填补的正是这一领域缺乏系统性评测基准的空白。