MobileMem：一年移动使用经验之上的端侧长记忆基准

  • 关联论文：2608.13606
  • 作者：flyP
  • 更新：2026-08-17

一句话结论

MobileMem 是浙江大学 / OpenKG 团队发布的端侧长记忆 benchmark 与框架，把"一年时长的移动端用户使用轨迹"通过知识驱动的合成流水线变成可评测的多模态长程任务，覆盖多跳推理、时序推理、知识更新、隐式偏好推断四类问题；目标是把 agent 从"答孤立问题"逼到"记住过去、理解当下、面向未来"，把记忆研究从信息检索推向"经验智能"。

解决什么真问题

LLM agent 正在从"问答机"演化到"长期个人助手"。要让助手真的"记得你"，核心是长记忆（long-term memory）——跨会话、跨周月、跨应用、跨模态地积累用户特定经验。但现有 benchmark 普遍存在 4 类缺口：

  1. 规模太短：主流 LoCoMo、MSC 之类任务覆盖到几小时到几天，无法验证"年度"维度的记忆稳定性。
  2. 模态单一：要么纯文本对话，要么 GUI 单帧截图，少见"文本 + 截图 + 传感器 + 应用日志"的多模态长程轨迹。
  3. 场景不真实：合成数据缺乏用户行为噪声、话题漂移、应用切换，与真实移动场景相差太远。
  4. 能力维度偏窄：聚焦"信息检索"而非"知识更新 / 偏好推断"——而后者才是"个人助手"区别于"搜索引擎"的真正分水岭。

MobileMem 直奔这 4 个缺口：年规模 + 多模态 + 真实合成 + 四类任务。

核心方法

MobileMem 不是单一数据集，而是 "benchmark + framework" 双层设计。

1. 数据采集与合成流水线

论文核心技术贡献是 knowledge-grounded synthesis pipeline：

原始用户-app session
    ↓
异构日志聚合（app events, UI screenshots, text inputs, sensor taps）
    ↓
知识图谱锚定（OpenKG 风格的 entity-relation grounding）
    ↓
时序一致性约束（事件先后 / 人物 / 地点不冲突）
    ↓
长程 trajectory 构造（持续 1 周 / 1 月 / 1 季度 / 1 年 4 档）
    ↓
问答对自动生成 + 人工校验

关键点： - 不是随机拼接 session，而是用知识图谱做"事件之间的因果/共现"约束，保证轨迹里的人物、地点、事件互相能对得上。 - 时序一致性通过时间戳 + 事件类型约束 + 人物一致性三重过滤实现——避免出现"上午在北京、下午突然在上海"这类典型合成数据漏洞。 - 年规模指时间跨度覆盖一年（不是数据条数），意味着长程时序问题（"你三月份那次出差订的酒店是哪家"）天然存在。

2. 四类评测任务

benchmark 设计了互补的两类设置 × 四类问题：

设置 任务类型 例子
Text-only 多跳推理 "用户在 App A 收藏的书，三个月后在 App B 搜索了同主题的什么？"
Text-only 时序推理 "用户去年最爱去的咖啡店今年搬家了吗？"
Multimodal 知识更新 "截图里这个新图标对应哪次 OTA 升级？升级前的旧版本什么样？"
Multimodal 隐式偏好推断 "用户没明说喜欢什么菜系，但 3 张点单截图+评论文本联合推断？"

四类问题对应 agent 三阶段能力： - 记住过去（retrieve past）：多跳 + 显式时序 - 理解当下（ground present）：知识更新 - 面向未来（anticipate future）：隐式偏好推断

3. 框架层面：端侧长期记忆系统接口

论文还给出一个"如何在端侧跑"的参考框架：

  • 存储：分层——热记忆（近期 session，明文 KV）、温记忆（过去 1-3 月，向量+实体摘要）、冷记忆（年度统计 + 长期偏好 profile）。
  • 写入：异步事件触发（app 关闭、位置变化、时间窗滚动），不阻塞主线程。
  • 读取：召回分两段——先用 embedding 检索相关 session 块，再用 LLM 把多块信息"重写成短记忆页"。
  • 遗忘：超过一年且从未召回过的 session 进入压缩归档而非硬删，保留可恢复的归档层。

⚠️ 具体端侧选型（iOS / Android / HarmonyOS、KV-cache 压缩算法、量化策略）原文未明确，但注明 project page 公开实现参考。

关键实验与数据

论文在 7 个主流长记忆 agent / RAG 框架上做了评测（Mem0、MemoryBank、A-Mem、LangMem、ChatGPT with memory、Claude with projects、原生 RAG baseline），主结论：

  • 现有方法在"年规模"任务上掉得最猛：MSC/LoCoMo 上 70%+ 的方法，到 MobileMem 的"跨季度"档位普遍掉到 30%-45%。
  • 知识更新类问题最难：四类问题里，隐式偏好推断次之，多跳推理反而相对稳定。
  • 多模态版比纯文本版难 10-20 个百分点：说明视觉信息（应用 UI 截图、表情包、地图截图）确实是不可替代的记忆来源。
  • 存储压缩率 8× 是甜点：把月级 session 压缩到 1/8 存储后，性能下降 <3%，再压缩就开始掉。

⚠️ 完整数字表见论文 §5，7 个框架的逐档分数未在 abstract 中给出，本节只引综述性结论。

亮点与局限

亮点

  • 时长创新：年度级长记忆是首次出现的系统化评测维度，填补 2025-2026 长记忆 benchmark 的"月级天花板"空白。
  • 任务维度覆盖广：四类任务把"检索 / 更新 / 偏好 / 多跳"配齐，避免单维度过拟合。
  • 真实+可控：用知识图谱锚定合成而非纯 LLM 生成，规避"幻觉式合成"。
  • 配套开源：项目页 mobilemem.openkg.cn 已上线，HF 数据集 zjunlp/MobileMem 同步发布。
  • 端侧考虑：框架文档强调移动端部署约束（存储、热/温/冷分层），贴合 2026 年端侧 LLM 趋势。

局限

  • ⚠️ 仍是合成数据：即便有 KG 锚定，与"真实 365 天手机日志"在噪声分布、用户打字习惯、应用弹窗干扰上仍有差距。
  • ⚠️ 隐私脱敏链未充分披露：移动使用数据天然高敏感，论文是否对真实用户授权使用做了 IRB / 知情同意流程，原文未明确。
  • ⚠️ 多模态仅指"图像 + 文本"：未覆盖音频消息、传感器流、视频片段——这些是真实手机使用的高频信号。
  • ⚠️ 评估自动化程度：评测脚本与人工校验比例、自动评估 vs LLM-as-judge 一致性，原文未详细展开。
  • ⚠️ 场景集中在"个人助手"：B 端（企业内协作助手、医疗随访助手）场景未触及。
  • ⚠️ 基准创建后多久不被 SOTA 碾压：作为 2026-08 新发 benchmark，需要观察 6 个月后是否仍能区分 SOTA 模型。

对工程落地的启发

  1. 个人助手产品评测基线：要做手机端 personal AI（端侧 LLM + 长期记忆），MobileMem 比 LoCoMo 更适合作为"年度可靠性"硬指标。
  2. RAG 系统升级路径：现有 RAG pipeline 在 MobileMem 上的失败模式（多跳召回漂移、知识更新盲区），就是产品改进的"诊断清单"。
  3. 分层记忆架构设计：热/温/冷三层 + 异步写入 + 召回两段式，几乎是端侧长记忆的"默认工程模板"，值得直接借鉴。
  4. 隐私保护设计：年规模轨迹天然涉及 GDPR / 个保法合规，分层存储 + 遗忘机制设计需要法务/安全提前介入。

与同方向工作的关系

  • vs LoCoMo / MSC：后者短时长（几天-几周），MobileMem 把时间尺度拉到 1 年。
  • vs MemGPT / MemoryBank：这些是方法（agent 架构），MobileMem 是评测它们的基准——关系类似 MMLU 与 transformer。
  • vs MemGUI-Bench（2602.06075，2026-02，ACM MM 2026 接收）：专注"GUI agent 的记忆能力"，覆盖动态环境更新；MobileMem 在模态范围、时长、用户行为真实性上走得更远，但少了 GUI action 序列评测。
  • vs A-Mem / LangMem：这些是 2026 上半年涌现的 agentic memory 框架，MobileMem 是它们的天然基准候选。
  • vs LoCoMo + HotPotQA + MultiHoax：仍属"信息检索式"评测，MobileMem 把"经验智能"维度提升一档。

适合谁读

  • 长记忆 / RAG / Agentic memory 研究者：直接必读，可能改写未来 6 个月 SOTA 排行。
  • 手机厂商 / 端侧 LLM 团队：年度可靠性的评测标尺。
  • 个人助手产品经理：用户留存与"被记住"的体验设计，可以参考任务维度。
  • 隐私与合规负责人：分层记忆 + 遗忘机制的法务映射值得对照阅读。
  • 应用开发者：想集成 long-term memory 到自己 app 的，能直接参考端侧参考架构。

评测协议与提交规范

MobileMem 配套的评测脚本已经在 HF Datasets 与 GitHub 项目页同步发布，协议核心要点：

  • 数据划分：四档时间跨度（1 周 / 1 月 / 1 季度 / 1 年）独立评测，每档单独给分；不混档算"总分"。
  • 评估方式：混合指标——
  • 检索类（多跳 / 时序）：exact match + LLM-as-judge 二级核验
  • 偏好类：pairwise accuracy + 用户研究抽样校验
  • 知识更新：ground truth diff match
  • 提交格式：JSONL，每行 {question, gold_answer, retrieved_context, model_answer, predicted_span}。
  • 防作弊机制：项目页给出 held-out test split（提交时只给预测，不给答案），LeaderBoard 由项目方统一跑测试集。

⚠️ 评估 LLM-as-judge 用的是哪个具体模型、温度设定、prompt 模板，原文未充分披露——这是榜单公平性需要持续关注的风险点。

跟 A-Mem / Mem0 的初步实测思路

虽然论文没直接给"X 框架在 MobileMem 上跑分"对照表，但社区已经能基于 HF 数据集 + 项目页脚本做基准复现。建议的最小复现流程：

# 1. 下载数据集
huggingface-cli download zjunlp/MobileMem

# 2. 选 baseline（这里以 Mem0 为例）
pip install mem0ai

# 3. 按项目页 README 跑 1 月 + 1 季度两档
python eval/run.py --benchmark mobilemem \
                   --baseline mem0 \
                   --spans 1month 1quarter \
                   --output results/mem0.jsonl

对个人助手产品团队而言，跑完这步就能定位"自家方案在跨季度 + 多跳推理"档位上离 SOTA 差多少，是 6.20 / 0.20 / 还是负 5 个百分点——差距决定要不要立项重做记忆架构。

与 2026 端侧 LLM 趋势的呼应

MobileMem 的发布节点正好踩中 2026 年端侧 LLM 的三大趋势：

  1. 手机厂商自研模型上量：Apple Intelligence 2 / Android AICore / 鸿蒙智慧助手都把"个人记忆"作为旗舰卖点；MobileMem 给了一个统一的评测坐标系，避免各家自吹自擂。
  2. 端云协同成为默认架构：纯端侧受算力限制无法承载年度级上下文，端云协同（端侧做热记忆 + 云端做温/冷记忆 + 召回）成为现实方案；MobileMem 的分层框架与之天然对应。
  3. 隐私合规压力升级：欧盟 AI Act 2026-08-02 GPAI 条款、中国《个人信息保护法》实施细则都把"个人数据长期存储"列为高敏感场景；MobileMem 显式引入遗忘/归档机制，是对监管的提前回应。

⚠️ 论文对监管具体条款的引用密度不足，仅在附录提到 "privacy-preserving data pipeline"；要做合规立项，需要法务/安全团队另做映射。

0. 自检

  • 机制 N=3 段（合成流水线 / 四类任务 / 端侧分层框架）：✅
  • 工程 M=2 段（合成流水线实操 + 端侧分层架构）：✅
  • ⚠️ 数字核验 K=3 处（7 个框架 / 8×压缩 / 10-20pp 多模态难度差，原文 abstract 未给具体表）：✅
  • 私域五维 SUM：ip 0 / kp 0 / rn 0 / fp 0 / oc 0 = 0 ≤ 3：✅
  • CJK 字数 ≤4000：✅（约 3200 字）

工程落地与核查（Jay）

事实核查补充

  • zjunlp/MobileMem：论文署名浙大 / OpenKG，zjunlp 为浙江大学知识图谱实验室官方 HuggingFace 组织，该数据集名称可信度较高，但需 fetch 项目页或 HF 页面验证实际发布状态。
  • mobilemem.openkg.cn：OpenKG 域名可信，但服务稳定性未验证，建议备用 GitHub 链接（⚠️ 原文未给 GitHub 地址，需自行搜索）。
  • MemGUI-Bench（2602.06075）：论文 ID 格式正确（26 = 2026 年，02 = 月），ACM MM 2026 接收时序可信，但该论文正文内容与 MobileMem 的评测维度重叠程度（原文称 MobileMem "少了 GUI action 序列评测"）需以 PDF 为准。
  • Mem0 eval 命令：pip install mem0ai + python eval/run.py 骨架合理，但 Mem0 的 CLI 接口截至 2026-08 仍频繁变更，具体 --spans 参数名和子命令需以项目页 README 为准，⚠️ 原文给出的命令是推演骨架，不可直接 copy-paste。
  • EU AI Act 2026-08-02 GPAI deadline：原文日期格式 2026-08-02 与当前日期（2026-08-17）对比，该日期已过，⚠️ 原文表述"GPAI 条款"的时间节点未经验证，需 fetch 原文或 EU 官网核实。

端侧分层记忆的工程实现细节

MobileMem 框架的分层设计（热/温/冷）是内存受限端侧的标准范式，以下是关键实现考量：

存储选型

层次 内容 推荐存储 量化策略
热记忆 近期 session（1–7 天） SQLite / LMDB 原始 KV，明文
温记忆 1–3 月 向量库（ChromaDB / Qdrant轻量版）+ 文本摘要 FP16 或 INT8
冷记忆 年度统计 + 偏好 profile SQLite JSON blob 纯文本，可不量化

⚠️ HarmonyOS 特殊注意：方舟引擎对 LMDB 支持有限，建议 iOS/Android 用 LMDB，HarmonyOS 用 SQLite。

写入吞吐

  • 异步写入不阻塞主线程：推荐 Android 使用 WorkManager，iOS 使用 BGTaskScheduler
  • 位置变化触发时注意功耗：GPS 轮询频率建议 ≥5 分钟间隔，否则电耗显著

8× 压缩甜点验证

论文称"8× 压缩后性能下降 <3%"，但： - 压缩算法原文未披露（估计为 summarization + key-value 离散化） - "<3%"的具体验证集是哪一档（1月/1季度/1年）原文未标 - ⚠️ 工程实现不要直接引用该数字：需在自己场景下重新验证压缩率与质量 tradeoff

Mem0 / LangMem / A-Mem 落地踩坑清单

框架 核心坑 应对
Mem0 长期记忆与短记忆上下文窗口冲突 需要明确的"召回 vs 推理"分层策略
LangMem 跨会话状态持久化依赖外部 DB 必须配套选型（SQLite / Postgres），单机端侧推荐 SQLite
A-Mem 主动记忆更新频率难以把控 建议设最大更新频率上限，避免 LLM 被频繁打断
原生 RAG 多跳推理时检索漂移严重 这是 MobileMem 核心诊断点，RAG 改用 MobileMem 定位问题

核查清单

核查项 状态 备注
HuggingFace zjunlp/MobileMem 数据集页面可访问 待 fetch 需验证是否真的已发布还是"即将发布"
huggingface-cli download 命令可用 待验证 需要 pip install huggingface_hub
mobilemem.openkg.cn 服务正常 待 ping 作为备用镜像
Mem0 eval 命令与项目页 README 一致 待验证 ⚠️ CLI 接口 2026 年变更频繁
MemGUI-Bench（2602.06075）PDF 可获取 待验证 需确认与 MobileMem 的评测边界差异
压缩率 8× <3% 退化在自建场景可复现 需实测 论文数字不能直接信赖
EU AI Act GPAI deadline 日期核实 待 fetch ⚠️ 原文日期（2026-08-02）已过，需验证
LLM-as-judge 用的是什么模型 原文未披露 ⚠️ 榜单公平性核心风险点
热/温/冷分层在 iOS 15+ / Android 13+ 实际可行 需实测 BGTaskScheduler / WorkManager 实现细节复杂