Claude-Mem LoCoMo 评测 Phase 06：双指标结果分析、对比报告与可复现方法论

本文聚焦 claude-mem 仓库中 LoCoMo 评测流水线的最后一个阶段——Phase 06「结果分析与发布」（LOCOMO-EVAL-06.md）。读完本篇，你将理解如何用 F1 与 LLM-as-a-Judge 双指标把 claude-mem 的评测结果与 Mem0、Zep、OpenAI Memory 及全上下文上界进行横向对比，如何生成带 YAML front matter 的 findings 与 methodology 报告，以及如何用逐会话（per-conversation）分析定位评测中的异常模式。

Phase 06 在评测流水线中的定位

LoCoMo 评测被拆成 6 个阶段（Playbook 位于 .maestro/playbooks/Wizard-2026-02-22/2026-02-22-LoCoMo-Eval/）：

1. Phase 01（LOCOMO-EVAL-01.md）：搭建评测工程结构，下载 LoCoMo 数据集，构建「对话 → claude-mem observation」的摄入适配器，并完成 1 段对话的端到端验证；
2. Phase 02（LOCOMO-EVAL-02.md）：把全部 10 段对话通过 worker API 摄入为可搜索的记忆；
3. Phase 03（LOCOMO-EVAL-03.md）：构建 QA 回答管线——混合搜索取 top-10 observation、12K 字符上下文窗口、Opus 4.6 生成抽取式答案，全程记录延迟与 token 用量；
4. Phase 04（LOCOMO-EVAL-04.md）：实现双评分引擎——token 级 F1（对齐 LoCoMo 原论文）与 LLM-as-a-Judge 的 J 分数（对齐 Mem0 论文方法，每题 10 次独立评判）；
5. Phase 05（LOCOMO-EVAL-05.md）：带检查点的全量评测运行器，产出 eval-results-{时间戳}.json 结果文件；
6. Phase 06（本文）：读取最新结果文件，生成对比分析报告、findings 文档、methodology 文档与逐会话分析。

Phase 06 的产出是「可发布的数字」：用 J 分数与现代记忆系统对比（Mem0 66.88%、Zep 65.99%、OpenAI Memory 52.90%、全上下文上界 72.90%），用 F1 与历史基线做兼容性对照，并附延迟/token 效率指标以定位其生产可用性。

任务一：构建结果分析器 analyze-results.ts

Phase 06 的第一个任务是在 evals/locomo/scripts/analyze-results.ts 中构建结果分析器。注意：evals/ 目录属于评测工作区，未包含在当前仓库快照中（经全仓检索确认），以下模块路径以 Playbook 文档描述为准。

分析器的工作方式

按文档要求，分析器需要：

1. 从 evals/locomo/results/ 加载最近一次的评测结果文件（按文件名时间戳匹配 eval-results-*.json）；
2. 复用 evals/locomo/src/scoring/reporter.ts 中的报表模块（该模块在 Phase 04 中已实现，内置 F1/J 两套基线常量与三个表格格式化函数）；
3. 依次生成三张对比表，并计算与每个基线的 delta（+{X.X} / -{X.X} 个百分点，J 与 F1 都要算）；
4. 自动识别四个关键结论：最强类别（J 最高）、最弱类别（J 最低）、相对 Mem0 的最大 delta、相对全上下文上界的差距；
5. 将三张表和关键发现打印到控制台。

运行命令为：

bun evals/locomo/scripts/analyze-results.ts

J 分数对比表（主指标）

J 分数是与现代记忆系统对比的主指标。分析器输出的表格结构如下（基线数值来自 Mem0 论文 Table 2）：

System	Overall J	Single-hop	Multi-hop	Temporal	Open-domain
Full-context	72.90	—	—	—	—
Claude-Mem (Opus 4.6)	{J±std}	{J±s}	{J±s}	{J±s}	{J±s}
Mem0ᵍ	68.44	65.71	47.19	58.13	75.71
Mem0	66.88	67.13	51.15	55.51	72.93
Zep	65.99	61.70	41.35	49.31	76.60
RAG (best, k=2)	60.97	—	—	—	—
LangMem	58.10	62.23	47.92	23.43	71.12
OpenAI Memory	52.90	63.79	42.92	21.71	62.29
A-Mem	48.38	39.79	18.85	49.91	54.05

文档特别标注了一个可比性陷阱：Letta 报告的 74.0% 使用的是不同的 "accuracy" 指标，不是 J 分数，因此不可直接对比，只能作为脚注出现。这一点是跨系统基准对比中容易被忽略的细节。

F1 对比表（次指标，用于历史追溯）

F1 表用于与 LoCoMo 原论文（ACL 2024）时代基线做纵向对照：

System	Single-hop F1	Multi-hop F1	Temporal F1	Open-domain F1
Claude-Mem (Opus 4.6)	{F1}	{F1}	{F1}	{F1}
Mem0	38.72	28.64	48.93	47.65
Mem0ᵍ	38.09	24.32	51.55	49.27
Zep	35.74	19.37	42.00	49.56
Human				(87.9 overall)

延迟与效率对比表

第三张表衡量生产就绪度，与 Mem0 论文 Table 3 公布的延迟/token 数据对比：

System	Search p50	Search p95	Total p50	Total p95	Tokens/Query
Claude-Mem	{ms}	{ms}	{ms}	{ms}	{N}
Mem0	148ms	200ms	708ms	1,440ms	1,764
Mem0ᵍ	476ms	657ms	1,091ms	2,590ms	3,616
Zep	513ms	778ms	1,292ms	2,926ms	3,911
Full-context	—	—	9,870ms	17,117ms	26,031

这些延迟与 token 数据并非凭空而来——它们在 Phase 03 的 QA 管线中就被逐题采集：searcher.ts 从 worker 客户端的带计时 search 方法拿到 search_latency_ms，answerer.ts 记录 answer_latency_ms 并从 API 响应的 usage 字段提取 input_tokens / output_tokens，最终以 LatencyStats（search/answer/total 的 p50、p95）汇总进 EvalReport（数据结构定义见 LOCOMO-EVAL-01.md 中 QAResult、LatencyStats、EvalReport 的接口说明）。Phase 03 的 conv-26 原型实测给出了量级参考：平均搜索延迟 1165ms、平均回答延迟 2032ms、约 455 tokens/题。

为什么是「双指标」

文档给出的理由值得展开：

• Token 级 F1：规范化 → Porter 词干提取 → 多重集 token 交集 → 精度/召回/F1。这是 LoCoMo 原论文（Maharana et al., ACL 2024）的评分方式，用来对齐历史基线；
• LLM-as-a-Judge（J 分数）：用 Claude Sonnet 4.6 从事实准确性、完整性、相关性、上下文恰当性四个维度对「预测答案 vs 标准答案」打 0–100 分，每题 10 次独立评判，报告均值 ± 标准差，与 Mem0/Zep/OpenAI Memory 的对比口径一致；
• 取舍依据：LoCoMo-Plus（arXiv 2602.10715v1）指出 F1 存在已知的长度偏差；J 分数已成为记忆系统横向对比的现代标准。双指标并存兼顾向后兼容与现代可比性。

一个值得注意的设计：评判模型（Sonnet 4.6）与答题模型（Opus 4.6）故意不同，以避免自评判偏差。

任务二：生成 findings.md 结果报告

第二个任务是生成 evals/locomo/results/findings.md，要求带 YAML front matter：

---
type: report
title: "LoCoMo Eval Results: Claude-Mem Persistent Memory"
created: 2026-02-22
tags:
  - locomo
  - eval
  - benchmark
  - memory
  - claude-mem
related:
  - "[[Methodology]]"
---

正文按以下章节组织，每章的内容要求都很具体：

• Executive Summary（执行摘要）：一段话给出 headline J 分数、与 Mem0（66.88%）和全上下文上界（72.90%）的对比、核心结论；同时提及 F1 结果及 claude-mem 在整个版图中的排名位置；
• J-Score Results（主指标）：完整 J 分数对比表，并分析 claude-mem 相对 Mem0、Zep、全上下文的位置；
• F1 Results（次指标）：F1 对比表，注明该指标保留是为了完整性，但按 LoCoMo-Plus 的说法存在长度偏差；
• Latency & Efficiency：延迟对比表，对照 Mem0 公布数字分析 claude-mem 的生产就绪度；
• Per-Category Analysis（逐类别分析）：对 4 个计分类别各给出 J 与 F1 分数、解读、与该类别最强竞品的对比、什么有效/什么无效；
• Key Architectural Insights（架构洞察）：文档预设了四条架构层面的对比论点，这些正好可以用仓库源码印证：
  • claude-mem 用 Sonnet 4.6 做 observation 压缩（对应 Mem0 的 GPT-4o-mini 逐消息事实抽取）；
  • 混合搜索（FTS5 + Chroma 向量） 对应 Mem0 的纯向量检索。从仓库源码结构看，这一架构是真实落地的：SessionSearch.ts 基于 SQLite FTS5 做全文检索，ChromaSync.ts 与 ChromaMcpManager.ts 负责 Chroma 向量端的同步与生命周期管理，SearchManager.ts 则把它们组合成 worker 侧的统一搜索入口；
  • 工具调用（tool-use）模式与 Letta 的论点一致：agent 工具调用 > 纯检索机制；
  • 每个 session 一条 observation 对应 Mem0 的逐消息事实抽取——这是两者记忆粒度的根本差异；
• Limitations（局限性）：单轮 QA 结果（10 轮 J 分数可提供置信区间）、特定模型版本、对抗类被排除、潜在混杂因素、未做认知记忆测试（LoCoMo-Plus）；
• Future Work：LoCoMo-Plus 认知记忆评测、带标准答案的对抗类、多答题模型对比、记忆构建成本分析；
• Raw Numbers：完整的逐类别原始表，含 F1 与 J 各自的 count、mean、min、max、std。

任务三：生成 methodology.md 方法论文档

methodology.md 的 front matter 为：

---
type: report
title: "LoCoMo Eval Methodology: Claude-Mem"
created: 2026-02-22
tags:
  - locomo
  - methodology
  - eval
  - claude-mem
related:
  - "[[LoCoMo-Eval-Results]]"
---

各章节的要点：

• Benchmark：LoCoMo 概览——10 段对话（每段约 600 轮对话、约 26K tokens），4 个计分的 QA 类别（single-hop、multi-hop、temporal、open-domain），对抗类按 Mem0 的方法论排除（无 ground truth）。引用 Maharana et al., ACL 2024；
• Scoring Methodology：即上文展开的双指标细节（F1 的规范化/词干/多重集交集流程，J 分数的四维评判、0–100 分、10 次独立运行、均值±标准差）及取舍理由；
• Memory System Under Test：claude-mem 架构链路——Claude Code hooks → worker API → Sonnet 4.6 observation 压缩 → SQLite FTS5 全文搜索 + Chroma 向量嵌入。与 Mem0 的关键差异在于：claude-mem 把整个会话压缩成一条 observation，而不是逐消息抽取事实。这条链路的仓库侧印证可见 SearchManager.ts 的搜索编排与 SearchManager.md 中对 worker 搜索体系的说明；
• Ingestion Pipeline：LoCoMo 会话如何被转换为工具执行——把对话转录格式化为 Read 工具的 tool_response（[Session N — date] 头 + 逐轮发言），由 Sonnet 4.6 处理后存为含 facts、narratives、concepts 的结构化 observation（转换格式定义在 LOCOMO-EVAL-01.md 的 adapter 规范中）；
• QA Pipeline：每题流程——混合搜索取 top-10 observation（按会话项目 scope 隔离）→ 用 observation 标题/facts/narratives 拼上下文（12K 字符预算，按 observation 边界截断而非句中截断）→ Opus 4.6 生成抽取式答案（temperature 0、max_tokens 256、类别专属提示）→ F1 即时打分，J 分数在独立 pass 中打分；
• Baseline Sources：J 分数基线来自 Mem0 论文（arXiv 2504.19413，ECAI 已接收，Table 2）；F1 基线同时来自 Mem0 论文（Table 1）与 LoCoMo 原论文；延迟基线来自 Mem0 论文（Table 3）。注意口径差异：Mem0 基线用 GPT-4o-mini，本系统用 Claude Sonnet 4.6（压缩）+ Opus 4.6（答题）；
• Models：Sonnet 4.6（claude-sonnet-4-6）负责记忆压缩与评判，Opus 4.6（claude-opus-4-6）负责 QA 答题；
• Reproducibility：列出全部参数——搜索 limit（10）、上下文窗口（12K 字符）、QA temperature（0）、QA max_tokens（256）、judge temperature（0.5）、judge max_tokens（256）、judge runs（10）、调用间隔延迟。并提示 EasyLocomo 项目可作为复现 LoCoMo 评测的参考框架。

其中「每会话一个隔离项目」的做法贯穿始终：Phase 01 的 adapter 为每段对话生成独立项目名 locomo-eval-{sample_id} 与确定性会话 ID locomo-{sampleId}-s{sessionId}，保证 QA 阶段搜索不会跨对话串味。这一项目隔离机制与 claude-mem 主代码库的项目级记忆隔离思路一致（参见 project-filter.ts 对项目的过滤逻辑）。

任务四：逐会话分析 per-conversation-analysis.ts

最后一个任务是 evals/locomo/scripts/per-conversation-analysis.ts：

1. 加载评测结果并按 sample_id 分组；
2. 对 10 段对话各计算：该对话的总 J 与 F1、每个出现过的类别的 J 与 F1、题目数量、已存 observation 数（向 claude-mem 查询）、每题平均使用的 observation 数（搜索相关性均值）、该对话的平均搜索延迟与回答延迟；
3. 按 J 分数从高到低对 10 段对话排名（最易 → 最难）；
4. 识别异常模式：某些对话主题是否更难？更长的对话表现更好还是更差？observation 数量与得分是否相关？
5. 将排名表打印到控制台，并把逐会话小节追加到 findings.md 末尾。

运行命令：

bun evals/locomo/scripts/per-conversation-analysis.ts

这一步的价值在于把「一个总分」拆解为可诊断的粒度：如果某段对话 J 显著偏低，可以回溯是该对话摄入的 observation 数偏少（Phase 02 曾出现 272 条 observation 仅 2 条持久化的数据丢失问题，最终通过直写 SQLite + FTS5 绕过 worker 解决，见 LOCOMO-EVAL-05.md 的 RESOLVED 记录），还是搜索召回质量差，抑或答题提示在特定类别上失效。

小结

Phase 06 的产物（对比表 + findings + methodology + 逐会话分析）构成了这套评测的可发布闭环：

• 指标层面：J 分数作为主指标对齐 Mem0 等现代系统口径，F1 作为次指标保留历史可比性，延迟/token 指标支撑生产就绪度定位；
• 报告层面：front matter + 固定章节结构使结果文档与方法论文档可长期归档、交叉引用（related 字段互链）；
• 工程层面：所有结论都能追溯回 Phase 01–05 的具体实现——worker API 摄入、12K 上下文预算、双评分模块、检查点运行器，且双指标、双模型（答题/评判分离）、类别提示等设计都对应了基准对比中已知的偏差来源。

对想要复现此类记忆系统评测的开发者，可直接从 LOCOMO-EVAL-01.md 到 LOCOMO-EVAL-06.md 的六份 Playbook 入手，它们完整记录了从数据集加载到发布报告的每一步命令与验收标准。