claude-mem LoCoMo 评测实践双评分引擎Token 级 F1 LLM-as-a-Judge的设计与实现【免费下载链接】claude-memPersistent Context Across Sessions for Every Agent – Captures everything your agent does during sessions, compresses it with AI, and injects relevant context back into future sessions. Works with Claude Code, OpenClaw, Codex, Gemini, Hermes, Copilot, OpenCode More项目地址: https://gitcode.com/GitHub_Trending/cl/claude-mem本文以 claude-mem 仓库中 LoCoMo 评测项目的 Phase 04 阶段文档为主体完整拆解其双评分引擎的设计如何用标准化的 Token 级 F1 指标与原 LoCoMo 论文基线对齐如何用 LLM-as-a-JudgeJ-score与 Mem0 等现代记忆系统可比以及评分聚合、基线对比报表和配套测试策略的具体实现。读完后你将掌握可复用的评测打分方法论——从文本归一化管道、多集合词元交集的 F1 计算到多次判分取均值±标准差的统计设计。1. 背景为什么需要双指标评分claude-mem 的 LoCoMo 评测工作目录为.maestro/playbooks/Wizard-2026-02-22/2026-02-22-LoCoMo-Eval/是一套对持久记忆系统的系统性基准测试分六个阶段推进数据摄取Phase 01、数据集加载Phase 02、QA 回答管道Phase 03、双评分引擎Phase 04、完整评测运行器Phase 05、结果分析与发布Phase 06。Phase 04 是本篇的主体它解决一个核心问题两套历史悠久的评分体系不可互相替代必须同时实现。Token 级 F1沿用原 LoCoMo 论文ACL 2024的评分方式用于与历史基线LoCoMo 原论文及 Mem0 论文中的 F1 表对比LLM-as-a-JudgeJ-score沿用 Mem0 论文arXiv 2504.19413ECAI 已接收的方法用于与现代记忆系统对比——Mem066.88%、Mem0g68.44%、Zep65.99%、全上下文上限full-context72.90%。J-score 判分器刻意选用 Claude Sonnet 4.6模型 IDclaude-sonnet-4-6与回答器使用的 Opus 4.6claude-opus-4-6不同模型以避免自己判自己的偏差self-judging bias每题进行 10 次独立判分以获得统计显著性与 Mem0 的统计口径保持一致。完整方法学记录见同目录的 LOCOMO-EVAL-06.md 中规划的methodology.md其明确写道F1 存在已知的长度偏差LoCoMo-Plus, arXiv 2602.10715v1J-score 是现代记忆系统对比的标准做法。双指标同时提供向后兼容性与现代可比性。适用前提说明本文的评分实现细节模块路径、函数签名、参数均以 Phase 04 阶段文档中定义的规格为准评测代码位于独立的evals/locomo/工作目录未包含在当前仓库主目录的源码树中因此下文的实现引用均指向阶段文档中的规划路径。2. Token 级 F1 评分模块evals/locomo/src/scoring/f1.tsF1 模块的核心思想是把预测答案与标准答案当作两个词元多重集multiset计算交集相对各自规模的比例再合成 F1。模块定义并导出以下四个函数供测试使用。2.1 归一化管道normalizeAnswernormalizeAnswer(text: string)实现抽取式 QA 基准测试的标准归一化流程顺序固定转小写移除冠词a、an、the移除所有标点仅保留字母数字与空格将连续空白折叠为单个空格修剪首尾空白。2.2 Porter 词干提取porterStemporterStem(word: string)要求实现一个最小化 Porter 词干提取器——至少覆盖 Step 1a/1b/1c复数、-ed、-ing、-ness。文档同时给出了一个务实的替代方案检查 LoCoMo 官方仓库规划中的data/locomo-repo/是否自带 Python 评分脚本若有则严格匹配其归一化管道以保证与论文数字对比的公平性。这一点体现了基准测试的可比性原则——自己的归一化细节差异足以造成分数不可比。2.3 分词与 F1 计算tokenize/computeTokenF1tokenize(normalizedText: string)按空白切分对每个词元应用 Porter 词干提取。computeTokenF1(predicted: string, groundTruth: string)是核心打分函数完整计算步骤对两个字符串执行归一化对两个字符串执行分词含词干提取计算词元重叠common 预测词元与标准答案词元的交集——必须使用多集合交集multiset intersection即按每个词元出现次数计数例如the the the对the只能取到 1 个thePrecision |common| / |predicted_tokens|预测为空时取 0Recall |common| / |ground_truth_tokens|标准答案为空白取 0;F1 2 * P * R / (P R)当P R 0时取 0特殊情形归一化后双方都是空串时F1 1.0都没说话视为一致。多集合交集这一细节直接决定了重复词的处理行为是 F1 测试集中专门用the the thevsthe验证的点。3. LLM-as-a-Judge 评分模块evals/locomo/src/scoring/judge.tsJ-score 模块基于 Anthropic SDKPhase 03 已安装anthropic-ai/sdk由三个部分组成。3.1 判分提示词判分系统提示词Judge system prompt指示 Claude Sonnet 4.6 扮演公正的评估者在 0–100 分制上给预测答案打分评估维度与 Mem0 的判分标准一致共四个维度事实准确性Factual accuracy预测答案基于标准答案是否事实正确完整性Completeness是否覆盖标准答案中的关键信息相关性Relevance回答是否与所问问题相关语境恰当性Contextual appropriateness回答是否扎根于对话上下文。判分用户提示词buildJudgePrompt(question, groundTruth, predictedAnswer, category)同时包含问题、标准答案、预测答案附带类别标签category label让判分器按类别施加不同标准——例如时序temporal类问题需要精确的日期/顺序匹配要求结构化输出JSON 对象{score: 0-100, explanation: 1-2 句理由}。3.2 单次判分judgeAnswerjudgeAnswer(question, groundTruth, predictedAnswer, category)的关键 API 参数与容错策略参数/行为取值设计意图modelclaude-sonnet-4-6与回答器Opus 4.6不同模型避免自判偏差max_tokens256只需输出短 JSONtemperature0.5保留判分器跨次运行的方差以估计波动同时维持合理一致性——Mem0 报告 10 次运行的标准差为 ±0.15 至 ±0.75返回值JudgeResultscore 0–100explanation 字符串—容错处理按三级降级解析 JSON 响应提取 score 与 explanation → 若 JSON 解析失败尝试从纯文本中抽取数字分 → 仍失败则返回 score -1 并附带错误说明。-1是判分失败的哨兵值供聚合阶段过滤。3.3 多次判分聚合judgeAnswerMultipleRunsjudgeAnswerMultipleRuns(question, groundTruth, predictedAnswer, category, numRuns)默认执行 10 次numRuns可配并行执行用Promise.all按每批 3 个的节奏并发平衡速度与速率限制过滤掉所有 score -1 的失败运行对成功运行计算均值mean score、标准差std dev、个体分数数组返回JudgeAggregation{ mean_score, std_dev, run_count, individual_scores }若成功运行少于 5 次记录警告——这通常意味着系统性的判分失败如 API 持续错误而非随机波动。这个10 次采样 均值±标准差的设计正是 J-score 能跨系统横向比较的统计基础Mem0、Zep 等基线数字本身就是同样口径的均值。4. 结果聚合与双指标报表evals/locomo/src/scoring/reporter.ts报表模块从evals/locomo/src/types.ts导入类型职责是把逐题结果聚合为可按类别对比的指标。4.1 聚合函数函数语义scoreResultsF1(results)对每条{predicted_answer, ground_truth, category}应用computeTokenF1产出填充了f1_score的QAResult数组aggregateF1ByCategory(results)按类别分组返回每个类别的{mean_f1, count, min_f1, max_f1}映射computeOverallF1(results)宏平均macro average所有题目 F1 之和 ÷ 总题数aggregateJudgeByCategory(results)按类别分组对每题的mean_score再求均值返回{mean_j, pooled_std_dev, count}computeOverallJudge(results)每题均值 J 分的宏平均附合并标准差pooled standard deviation4.2 F1 基线F1_BASELINES来自原 LoCoMo 论文与 Mem0 论文用于历史对比F1_BASELINES { Human: { overall: 87.9 }, Mem0: { overall: null, single_hop: 38.72, multi_hop: 28.64, temporal: 48.93, open_domain: 47.65 }, Mem0g: { overall: null, single_hop: 38.09, multi_hop: 24.32, temporal: 51.55, open_domain: 49.27 }, Zep: { overall: null, single_hop: 35.74, multi_hop: 19.37, temporal: 42.00, open_domain: 49.56 }, LangMem: { overall: null, single_hop: 35.51, multi_hop: 26.04, temporal: 30.75, open_domain: 40.91 }, OpenAI Memory: { overall: null, single_hop: 34.30, multi_hop: 20.09, temporal: 14.04, open_domain: 39.31 }, A-Mem: { overall: null, single_hop: 20.76, multi_hop: 9.22, temporal: 35.40, open_domain: 33.34 }, GPT-3.5-turbo-16K: { overall: 37.8 }, RAG-observations (original paper): { overall: 41.4 }, GPT-4-turbo: { overall: 32.1 } }4.3 J-score 基线J_BASELINES来自 Mem0 论文arXiv 2504.19413不含对抗类adversarial该类在 Mem0 口径下无标准答案J_BASELINES { Full-context: { overall: 72.90 }, Mem0g: { overall: 68.44, single_hop: 65.71, multi_hop: 47.19, temporal: 58.13, open_domain: 75.71 }, Mem0: { overall: 66.88, single_hop: 67.13, multi_hop: 51.15, temporal: 55.51, open_domain: 72.93 }, Zep: { overall: 65.99, single_hop: 61.70, multi_hop: 41.35, temporal: 49.31, open_domain: 76.60 }, RAG (best, k2 256-tok): { overall: 60.97 }, LangMem: { overall: 58.10, single_hop: 62.23, multi_hop: 47.92, temporal: 23.43, open_domain: 71.12 }, OpenAI Memory: { overall: 52.90, single_hop: 63.79, multi_hop: 42.92, temporal: 21.71, open_domain: 62.29 }, A-Mem: { overall: 48.38, single_hop: 39.79, multi_hop: 18.85, temporal: 49.91, open_domain: 54.05 } }文档同时给出一条重要边界说明Letta 报告的 74.0% accuracy 使用了不同的评分方法非 LLM-as-a-Judge不可直接比较只作为脚注出现。这是基线对齐时的典型陷阱——同名指标未必同口径。4.4 对比表格生成formatF1ComparisonTable(evalResults, f1Baselines)生成 claude-mem F1 对全部 F1 基线的 markdown 表按类别 总体formatJudgeComparisonTable(evalResults, jBaselines)J 分对比表按类别 总体附 ±标准差formatLatencyComparisonTable(latencyStats)延迟/Token 对比表Mem0 公布的参照数字为 search p50 0.148s、search p95 0.200s、total p50 0.708s、total p95 1.440s、1,764 tokens/queryformatFullReport(evalResults)汇总完整 markdown 报告——三张对比表 按类别拆解 top-5/bottom-5 题目错误分析 延迟与 Token 汇总。5. 评分模块的测试策略Phase 04 要求为两套评分各写一份测试文件并给出了可验证的具体断言值这是保证评测工具本身可信的关键一环。5.1 F1 测试evals/locomo/tests/f1-scoring.test.ts覆盖用例与设计意图精确匹配the cat satvsthe cat sat→ F1 1.0部分匹配the big cat satvsthe cat sat→ 验证词元重叠被正确反映完全不匹配dogvscat→ F1 0.0归一化The Cat!vsthe cat→ F1 1.0大小写 标点被消解冠词移除a big dogvsbig dog→ F1 1.0词干提取running quicklyvsruns quick→ 词干化后 F1 应非零边界预测为空、标准答案非空 → 0.0双方均空 → 1.0多集合行为the the thevsthe→ 验证按出现次数计数的 precision/recall聚合正确性mock 3 条 single-hopF1 0.8/0.6/1.0 2 条 multi-hop0.5/0.7数据验证类别均值computeOverallF1与期望的加权平均一致。5.2 Judge 测试evals/locomo/tests/judge-scoring.test.tsbuildJudgePrompt输出必须包含问题、标准答案、预测答案、类别四项mock Anthropic SDK验证judgeAnswer调用参数model 为claude-sonnet-4-6、temperature 0.5、max_tokens 256——参数级断言防止配置漂移JSON 解析失败路径mock 一个格式错误的响应验证返回 score -1judgeAnswerMultipleRuns聚合mock 10 次返回[70, 72, 68, 71, 73, 69, 70, 72, 71, 70]→ 验证 mean ≈ 70.6、std ≈ 1.5失败运行过滤mock 10 次中有 2 次返回 -1 → 聚合只使用 8 次成功运行并触发警告。阶段文档记录的验收结果为F1 评分测试 25/25 通过Judge 评分测试 14/14 通过全量测试套件 119/119 通过0 失败运行命令为bun test evals/locomo/tests/f1-scoring.test.ts与bun test evals/locomo/tests/judge-scoring.test.ts。6. 在原型结果上的双指标打分score-prototype.tsPhase 04 的落地环节是在 Phase 03 的 QA 原型输出上跑双评分脚本为evals/locomo/scripts/score-prototype.ts从evals/locomo/results/qa-prototype-results.json加载原型结果据 LOCOMO-EVAL-03.md 记载conv-26 对话的 20 题——10 条 temporal、8 条 single-hop、2 条 multi-hop平均搜索延迟 1165ms、平均回答延迟 2032ms、约 455 tokens/题F1 打分对每题应用scoreResultsF1打印按类别 F1 拆解与总体 F1——纯本地计算无 API 调用J 打分每题调用judgeAnswerMultipleRuns10 次。对约 20 题的原型即约 200 次判分 API 调用批间加 200ms 延迟以规避速率限制输出三张对比表F1 对基线、J 分对基线、原型运行的延迟汇总输出中注明口径Prototype only~20 题来自 1 个对话。完整评测在 Phase 05 执行。运行命令bun evals/locomo/scripts/score-prototype.ts。这一原型先行、全量后置的节奏是整个评测工程的重要模式Phase 04 只在 20 题上验证双评分链路端到端可用把昂贵的大规模判分推迟到 Phase 05 的带检查点运行器LOCOMO-EVAL-05.md——那里 J 打分被拆成独立 pass与 QA pass 分开 checkpoint使得先落盘 QA 结果、再单独重跑判分成为可能。7. 小结这套双评分引擎的方法学价值Phase 04 的双评分引擎有三个可迁移的设计决策值得注意指标双轨、口径对齐F1 服务历史可比性J-score 服务现代可比性每个指标都锁定一个参考实现的口径LoCoMo 原论文 / Mem0 论文并在基线表中显式标注不可比项Letta判分器与被评系统解耦不同模型判分Sonnet 判 Opus 的产出 多次采样10 次 失败哨兵值-1过滤 低置信度警告成功运行 5 次共同构成对 LLM 判分噪声的防御评测工具本身被测试归一化、词干化、多集合计数、参数传递、解析降级、聚合数学全部有可断言的单元用例验收 39 个评分用例、全量 119 个用例通过避免评测器 bug 污染基准结论。对于要在仓库内复现这套流程的读者建议的查阅路径是以 .maestro/playbooks/Wizard-2026-02-22/2026-02-22-LoCoMo-Eval/LOCOMO-EVAL-04.md 为评分实现规格书用 LOCOMO-EVAL-03 对照回答管道、用 LOCOMO-EVAL-05/06 对照运行器与最终报告结构。需要说明的限制完整评测运行依赖ANTHROPIC_API_KEYQA 用 Opus 4.6、判分用 Sonnet 4.6且评测工作目录evals/locomo/及数据集data/locomo-repo/不属于本仓库主源码树本文所述实现细节均以阶段文档的规格与验收记录为依据。【免费下载链接】claude-memPersistent Context Across Sessions for Every Agent – Captures everything your agent does during sessions, compresses it with AI, and injects relevant context back into future sessions. Works with Claude Code, OpenClaw, Codex, Gemini, Hermes, Copilot, OpenCode More项目地址: https://gitcode.com/GitHub_Trending/cl/claude-mem创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 claude-mem LoCoMo 评测实践：双评分引擎（Token 级 F1 + LLM-as-a-Judge）的设计与实现
claude-mem LoCoMo 评测实践双评分引擎Token 级 F1 LLM-as-a-Judge的设计与实现【免费下载链接】claude-memPersistent Context Across Sessions for Every Agent – Captures everything your agent does during sessions, compresses it with AI, and injects relevant context back into future sessions. Works with Claude Code, OpenClaw, Codex, Gemini, Hermes, Copilot, OpenCode More项目地址: https://gitcode.com/GitHub_Trending/cl/claude-mem本文以 claude-mem 仓库中 LoCoMo 评测项目的 Phase 04 阶段文档为主体完整拆解其双评分引擎的设计如何用标准化的 Token 级 F1 指标与原 LoCoMo 论文基线对齐如何用 LLM-as-a-JudgeJ-score与 Mem0 等现代记忆系统可比以及评分聚合、基线对比报表和配套测试策略的具体实现。读完后你将掌握可复用的评测打分方法论——从文本归一化管道、多集合词元交集的 F1 计算到多次判分取均值±标准差的统计设计。1. 背景为什么需要双指标评分claude-mem 的 LoCoMo 评测工作目录为.maestro/playbooks/Wizard-2026-02-22/2026-02-22-LoCoMo-Eval/是一套对持久记忆系统的系统性基准测试分六个阶段推进数据摄取Phase 01、数据集加载Phase 02、QA 回答管道Phase 03、双评分引擎Phase 04、完整评测运行器Phase 05、结果分析与发布Phase 06。Phase 04 是本篇的主体它解决一个核心问题两套历史悠久的评分体系不可互相替代必须同时实现。Token 级 F1沿用原 LoCoMo 论文ACL 2024的评分方式用于与历史基线LoCoMo 原论文及 Mem0 论文中的 F1 表对比LLM-as-a-JudgeJ-score沿用 Mem0 论文arXiv 2504.19413ECAI 已接收的方法用于与现代记忆系统对比——Mem066.88%、Mem0g68.44%、Zep65.99%、全上下文上限full-context72.90%。J-score 判分器刻意选用 Claude Sonnet 4.6模型 IDclaude-sonnet-4-6与回答器使用的 Opus 4.6claude-opus-4-6不同模型以避免自己判自己的偏差self-judging bias每题进行 10 次独立判分以获得统计显著性与 Mem0 的统计口径保持一致。完整方法学记录见同目录的 LOCOMO-EVAL-06.md 中规划的methodology.md其明确写道F1 存在已知的长度偏差LoCoMo-Plus, arXiv 2602.10715v1J-score 是现代记忆系统对比的标准做法。双指标同时提供向后兼容性与现代可比性。适用前提说明本文的评分实现细节模块路径、函数签名、参数均以 Phase 04 阶段文档中定义的规格为准评测代码位于独立的evals/locomo/工作目录未包含在当前仓库主目录的源码树中因此下文的实现引用均指向阶段文档中的规划路径。2. Token 级 F1 评分模块evals/locomo/src/scoring/f1.tsF1 模块的核心思想是把预测答案与标准答案当作两个词元多重集multiset计算交集相对各自规模的比例再合成 F1。模块定义并导出以下四个函数供测试使用。2.1 归一化管道normalizeAnswernormalizeAnswer(text: string)实现抽取式 QA 基准测试的标准归一化流程顺序固定转小写移除冠词a、an、the移除所有标点仅保留字母数字与空格将连续空白折叠为单个空格修剪首尾空白。2.2 Porter 词干提取porterStemporterStem(word: string)要求实现一个最小化 Porter 词干提取器——至少覆盖 Step 1a/1b/1c复数、-ed、-ing、-ness。文档同时给出了一个务实的替代方案检查 LoCoMo 官方仓库规划中的data/locomo-repo/是否自带 Python 评分脚本若有则严格匹配其归一化管道以保证与论文数字对比的公平性。这一点体现了基准测试的可比性原则——自己的归一化细节差异足以造成分数不可比。2.3 分词与 F1 计算tokenize/computeTokenF1tokenize(normalizedText: string)按空白切分对每个词元应用 Porter 词干提取。computeTokenF1(predicted: string, groundTruth: string)是核心打分函数完整计算步骤对两个字符串执行归一化对两个字符串执行分词含词干提取计算词元重叠common 预测词元与标准答案词元的交集——必须使用多集合交集multiset intersection即按每个词元出现次数计数例如the the the对the只能取到 1 个thePrecision |common| / |predicted_tokens|预测为空时取 0Recall |common| / |ground_truth_tokens|标准答案为空白取 0;F1 2 * P * R / (P R)当P R 0时取 0特殊情形归一化后双方都是空串时F1 1.0都没说话视为一致。多集合交集这一细节直接决定了重复词的处理行为是 F1 测试集中专门用the the thevsthe验证的点。3. LLM-as-a-Judge 评分模块evals/locomo/src/scoring/judge.tsJ-score 模块基于 Anthropic SDKPhase 03 已安装anthropic-ai/sdk由三个部分组成。3.1 判分提示词判分系统提示词Judge system prompt指示 Claude Sonnet 4.6 扮演公正的评估者在 0–100 分制上给预测答案打分评估维度与 Mem0 的判分标准一致共四个维度事实准确性Factual accuracy预测答案基于标准答案是否事实正确完整性Completeness是否覆盖标准答案中的关键信息相关性Relevance回答是否与所问问题相关语境恰当性Contextual appropriateness回答是否扎根于对话上下文。判分用户提示词buildJudgePrompt(question, groundTruth, predictedAnswer, category)同时包含问题、标准答案、预测答案附带类别标签category label让判分器按类别施加不同标准——例如时序temporal类问题需要精确的日期/顺序匹配要求结构化输出JSON 对象{score: 0-100, explanation: 1-2 句理由}。3.2 单次判分judgeAnswerjudgeAnswer(question, groundTruth, predictedAnswer, category)的关键 API 参数与容错策略参数/行为取值设计意图modelclaude-sonnet-4-6与回答器Opus 4.6不同模型避免自判偏差max_tokens256只需输出短 JSONtemperature0.5保留判分器跨次运行的方差以估计波动同时维持合理一致性——Mem0 报告 10 次运行的标准差为 ±0.15 至 ±0.75返回值JudgeResultscore 0–100explanation 字符串—容错处理按三级降级解析 JSON 响应提取 score 与 explanation → 若 JSON 解析失败尝试从纯文本中抽取数字分 → 仍失败则返回 score -1 并附带错误说明。-1是判分失败的哨兵值供聚合阶段过滤。3.3 多次判分聚合judgeAnswerMultipleRunsjudgeAnswerMultipleRuns(question, groundTruth, predictedAnswer, category, numRuns)默认执行 10 次numRuns可配并行执行用Promise.all按每批 3 个的节奏并发平衡速度与速率限制过滤掉所有 score -1 的失败运行对成功运行计算均值mean score、标准差std dev、个体分数数组返回JudgeAggregation{ mean_score, std_dev, run_count, individual_scores }若成功运行少于 5 次记录警告——这通常意味着系统性的判分失败如 API 持续错误而非随机波动。这个10 次采样 均值±标准差的设计正是 J-score 能跨系统横向比较的统计基础Mem0、Zep 等基线数字本身就是同样口径的均值。4. 结果聚合与双指标报表evals/locomo/src/scoring/reporter.ts报表模块从evals/locomo/src/types.ts导入类型职责是把逐题结果聚合为可按类别对比的指标。4.1 聚合函数函数语义scoreResultsF1(results)对每条{predicted_answer, ground_truth, category}应用computeTokenF1产出填充了f1_score的QAResult数组aggregateF1ByCategory(results)按类别分组返回每个类别的{mean_f1, count, min_f1, max_f1}映射computeOverallF1(results)宏平均macro average所有题目 F1 之和 ÷ 总题数aggregateJudgeByCategory(results)按类别分组对每题的mean_score再求均值返回{mean_j, pooled_std_dev, count}computeOverallJudge(results)每题均值 J 分的宏平均附合并标准差pooled standard deviation4.2 F1 基线F1_BASELINES来自原 LoCoMo 论文与 Mem0 论文用于历史对比F1_BASELINES { Human: { overall: 87.9 }, Mem0: { overall: null, single_hop: 38.72, multi_hop: 28.64, temporal: 48.93, open_domain: 47.65 }, Mem0g: { overall: null, single_hop: 38.09, multi_hop: 24.32, temporal: 51.55, open_domain: 49.27 }, Zep: { overall: null, single_hop: 35.74, multi_hop: 19.37, temporal: 42.00, open_domain: 49.56 }, LangMem: { overall: null, single_hop: 35.51, multi_hop: 26.04, temporal: 30.75, open_domain: 40.91 }, OpenAI Memory: { overall: null, single_hop: 34.30, multi_hop: 20.09, temporal: 14.04, open_domain: 39.31 }, A-Mem: { overall: null, single_hop: 20.76, multi_hop: 9.22, temporal: 35.40, open_domain: 33.34 }, GPT-3.5-turbo-16K: { overall: 37.8 }, RAG-observations (original paper): { overall: 41.4 }, GPT-4-turbo: { overall: 32.1 } }4.3 J-score 基线J_BASELINES来自 Mem0 论文arXiv 2504.19413不含对抗类adversarial该类在 Mem0 口径下无标准答案J_BASELINES { Full-context: { overall: 72.90 }, Mem0g: { overall: 68.44, single_hop: 65.71, multi_hop: 47.19, temporal: 58.13, open_domain: 75.71 }, Mem0: { overall: 66.88, single_hop: 67.13, multi_hop: 51.15, temporal: 55.51, open_domain: 72.93 }, Zep: { overall: 65.99, single_hop: 61.70, multi_hop: 41.35, temporal: 49.31, open_domain: 76.60 }, RAG (best, k2 256-tok): { overall: 60.97 }, LangMem: { overall: 58.10, single_hop: 62.23, multi_hop: 47.92, temporal: 23.43, open_domain: 71.12 }, OpenAI Memory: { overall: 52.90, single_hop: 63.79, multi_hop: 42.92, temporal: 21.71, open_domain: 62.29 }, A-Mem: { overall: 48.38, single_hop: 39.79, multi_hop: 18.85, temporal: 49.91, open_domain: 54.05 } }文档同时给出一条重要边界说明Letta 报告的 74.0% accuracy 使用了不同的评分方法非 LLM-as-a-Judge不可直接比较只作为脚注出现。这是基线对齐时的典型陷阱——同名指标未必同口径。4.4 对比表格生成formatF1ComparisonTable(evalResults, f1Baselines)生成 claude-mem F1 对全部 F1 基线的 markdown 表按类别 总体formatJudgeComparisonTable(evalResults, jBaselines)J 分对比表按类别 总体附 ±标准差formatLatencyComparisonTable(latencyStats)延迟/Token 对比表Mem0 公布的参照数字为 search p50 0.148s、search p95 0.200s、total p50 0.708s、total p95 1.440s、1,764 tokens/queryformatFullReport(evalResults)汇总完整 markdown 报告——三张对比表 按类别拆解 top-5/bottom-5 题目错误分析 延迟与 Token 汇总。5. 评分模块的测试策略Phase 04 要求为两套评分各写一份测试文件并给出了可验证的具体断言值这是保证评测工具本身可信的关键一环。5.1 F1 测试evals/locomo/tests/f1-scoring.test.ts覆盖用例与设计意图精确匹配the cat satvsthe cat sat→ F1 1.0部分匹配the big cat satvsthe cat sat→ 验证词元重叠被正确反映完全不匹配dogvscat→ F1 0.0归一化The Cat!vsthe cat→ F1 1.0大小写 标点被消解冠词移除a big dogvsbig dog→ F1 1.0词干提取running quicklyvsruns quick→ 词干化后 F1 应非零边界预测为空、标准答案非空 → 0.0双方均空 → 1.0多集合行为the the thevsthe→ 验证按出现次数计数的 precision/recall聚合正确性mock 3 条 single-hopF1 0.8/0.6/1.0 2 条 multi-hop0.5/0.7数据验证类别均值computeOverallF1与期望的加权平均一致。5.2 Judge 测试evals/locomo/tests/judge-scoring.test.tsbuildJudgePrompt输出必须包含问题、标准答案、预测答案、类别四项mock Anthropic SDK验证judgeAnswer调用参数model 为claude-sonnet-4-6、temperature 0.5、max_tokens 256——参数级断言防止配置漂移JSON 解析失败路径mock 一个格式错误的响应验证返回 score -1judgeAnswerMultipleRuns聚合mock 10 次返回[70, 72, 68, 71, 73, 69, 70, 72, 71, 70]→ 验证 mean ≈ 70.6、std ≈ 1.5失败运行过滤mock 10 次中有 2 次返回 -1 → 聚合只使用 8 次成功运行并触发警告。阶段文档记录的验收结果为F1 评分测试 25/25 通过Judge 评分测试 14/14 通过全量测试套件 119/119 通过0 失败运行命令为bun test evals/locomo/tests/f1-scoring.test.ts与bun test evals/locomo/tests/judge-scoring.test.ts。6. 在原型结果上的双指标打分score-prototype.tsPhase 04 的落地环节是在 Phase 03 的 QA 原型输出上跑双评分脚本为evals/locomo/scripts/score-prototype.ts从evals/locomo/results/qa-prototype-results.json加载原型结果据 LOCOMO-EVAL-03.md 记载conv-26 对话的 20 题——10 条 temporal、8 条 single-hop、2 条 multi-hop平均搜索延迟 1165ms、平均回答延迟 2032ms、约 455 tokens/题F1 打分对每题应用scoreResultsF1打印按类别 F1 拆解与总体 F1——纯本地计算无 API 调用J 打分每题调用judgeAnswerMultipleRuns10 次。对约 20 题的原型即约 200 次判分 API 调用批间加 200ms 延迟以规避速率限制输出三张对比表F1 对基线、J 分对基线、原型运行的延迟汇总输出中注明口径Prototype only~20 题来自 1 个对话。完整评测在 Phase 05 执行。运行命令bun evals/locomo/scripts/score-prototype.ts。这一原型先行、全量后置的节奏是整个评测工程的重要模式Phase 04 只在 20 题上验证双评分链路端到端可用把昂贵的大规模判分推迟到 Phase 05 的带检查点运行器LOCOMO-EVAL-05.md——那里 J 打分被拆成独立 pass与 QA pass 分开 checkpoint使得先落盘 QA 结果、再单独重跑判分成为可能。7. 小结这套双评分引擎的方法学价值Phase 04 的双评分引擎有三个可迁移的设计决策值得注意指标双轨、口径对齐F1 服务历史可比性J-score 服务现代可比性每个指标都锁定一个参考实现的口径LoCoMo 原论文 / Mem0 论文并在基线表中显式标注不可比项Letta判分器与被评系统解耦不同模型判分Sonnet 判 Opus 的产出 多次采样10 次 失败哨兵值-1过滤 低置信度警告成功运行 5 次共同构成对 LLM 判分噪声的防御评测工具本身被测试归一化、词干化、多集合计数、参数传递、解析降级、聚合数学全部有可断言的单元用例验收 39 个评分用例、全量 119 个用例通过避免评测器 bug 污染基准结论。对于要在仓库内复现这套流程的读者建议的查阅路径是以 .maestro/playbooks/Wizard-2026-02-22/2026-02-22-LoCoMo-Eval/LOCOMO-EVAL-04.md 为评分实现规格书用 LOCOMO-EVAL-03 对照回答管道、用 LOCOMO-EVAL-05/06 对照运行器与最终报告结构。需要说明的限制完整评测运行依赖ANTHROPIC_API_KEYQA 用 Opus 4.6、判分用 Sonnet 4.6且评测工作目录evals/locomo/及数据集data/locomo-repo/不属于本仓库主源码树本文所述实现细节均以阶段文档的规格与验收记录为依据。【免费下载链接】claude-memPersistent Context Across Sessions for Every Agent – Captures everything your agent does during sessions, compresses it with AI, and injects relevant context back into future sessions. Works with Claude Code, OpenClaw, Codex, Gemini, Hermes, Copilot, OpenCode More项目地址: https://gitcode.com/GitHub_Trending/cl/claude-mem创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考