ai-memory LongMemEval-S 检索基准全解析zero-llm 基线、评分口径与复现指南【免费下载链接】ai-memorySolution for long term memory for agent coding CLIs and to facilitate handoff between different agent vendors项目地址: https://gitcode.com/GitHub_Trending/ai/ai-memory导读本文以 ai-memory 仓库发布的 docs/benchmarks/longmemeval-s-2026-09-01.md 为骨架完整解读这份检索质量基线报告它记录的是 ai-memory 在 2.0 检索重构之前、纯确定性zero-llm模式下的 LongMemEval-Sv1检索成绩。读完本文你将掌握该基准的 slice 划分与每项指标的确切含义、hitk 与 recallk 在会话级评分的实现差异、数据从注入hook 回放到查询MCP memory_query再到打分的完整链路以及如何在本地用仓库自带的ai-memory-eval工具复现这份数字并通过同一套 harness 对比 FTS 与本地 embedding 两条检索路径的差距。一、这份基准报告记录了什么docs/benchmarks/longmemeval-s-2026-09-01.md是 ai-memory 检索质量的公开基线之一报告头部完整保留了四项溯源信息溯源字段值含义commit496e419ff60ece21e1c7dfc76a960c92043e75c8跑分时检出的代码版本保证数字可回溯datasetlongmemeval_ssha25608d8dad4be43ee20…LongMemEval-S v1 数据集及其校验和modezero-llm完全离线确定性模式无任何 LLM 参与hardwareAMD Ryzen 9 7950X3D32 线程运行环境questions scored47030 个 abstention 题除外计分题量与排除规则这份报告属于三份同日2026-09-01基准中的最早期基线。对照 docs/benchmarks/README.md 中的 Baselines 表可以看到完整的演进脉络datemodeoverall hit5对应报告2026-09-01zero-llmpre-2.0 FTS0.617longmemeval-s-2026-09-01.md2026-09-01zero-llm、stopword-filtered FTS0.668longmemeval-s-2026-09-01-fts.md2026-09-01local embeddings2.0 默认0.823longmemeval-s-2026-09-01-local.md也就是说这份文档是 2.0 检索重构的起点基线floor它测量的不是带 embedding 的混合检索而是 FTS5 entity/graph 的纯确定性检索栈。二、逐项解读 470 道题的切片成绩报告按 LongMemEval 官方的 question type 切成 6 个 slice全部成绩如下slicenhit1hit3hit5hit10recall1recall3recall5recall10knowledge-update720.5280.6530.7080.8060.2640.4510.4930.604multi-session1210.3880.5040.5700.6690.1680.2900.3330.448overall4700.4490.5660.6170.7130.2970.4300.4720.570single-session-assistant560.6960.7500.8040.8750.6960.7500.8040.875single-session-preference300.3670.5670.6000.7330.3670.5670.6000.733single-session-user640.4060.4530.4840.5470.4060.4530.4840.547temporal-reasoning1270.3940.5510.5980.7090.1900.3640.4100.507解读这份表需要注意三点slice 规模差异temporal-reasoning127 题和multi-session121 题是最大的两个分类也是纯 FTS 模式下相对最弱的两个——前者考验时间推理后者要求跨多个会话召回证据recall1 分别只有 0.190 和 0.168说明第一个返回结果就命中全部证据会话在这两类题上极难。hitk 与 recallk 的差距multi-session的 hit10 为 0.669 但 recall10 仅 0.448temporal-reasoning的 hit10 为 0.709 但 recall10 仅 0.507。差距大说明能找到至少一个证据会话与找全所有证据会话之间仍有明显鸿沟——这正是多会话问题的本质难点。single-session 系列single-session-assistant表现最好hit1 已达 0.696hit10 达 0.875且其 hitk 与 recallk 完全相同——因为单会话题只有一个证据会话命中即满分、未命中即零分。三、指标口径hitk 与 recallk 的准确定义报告末尾的 Notes 明确了两套指标的定义这是理解一切成绩的前提hitk 任意一个证据会话出现在 top k 中即大多数记忆系统对外发布的 Recallkrecallk 找到的证据会话数占该题全部证据会话数的比例对多会话题更严格会话归属session attribution来自sessions/id.md页面与原始 observation 命中无法归属到会话的页面永不参与计分捕获是生产形态的excerpt 被限制在 2 KB 隐私边界内。3.1 评分器的源码实现在 score.rs 中可以精确看到这两套指标如何落地let top: HashSetuuid::Uuid ranked_sessions.iter().take(k).collect(); let found evidence.iter().filter(|e| top.contains(e)).count(); hit_at.insert(k, if found 0 { 1.0 } else { 0.0 }); recall_at.insert(k, found as f64 / evidence.len() as f64);关键实现细节会话去重检索结果先按会话折叠同一会话的多个 chunk 只占据一个排名槽位。score.rs中duplicate_session_chunks_fill_one_slot_not_three测试验证了这一点——3 个噪声会话 chunk 只能占 rank 0随后出现的证据会话即命中 hit2。abstention 题排除没有证据会话的题目既不参与 hitk 也不参与 recallkscore_question中 evidence 为空时 recallk 记 0但这类题在进入评分前已被剔除见retrieval/mod.rs的questions.retain(|q| !q.is_abstention())。聚合方式aggregate按 question_type 与 overall 分组对每题成绩做宏平均macro-average。控制测试random_sessions_score_zero测试保证随机检索结果计零分——评分器不会给任意命中以错误加分。3.2 不可归属页面的处理query.rs中session_uuid_from_path只把sessions/uuid.md路径解析为会话 UUID其余页面如gotchas/build.md归属为Noneunattributed_pages_never_score测试验证了这些命中不会得分。这意味着报告度量的是会话级召回而非页面级检索质量。四、zero-llm 模式的完整评测链路这份报告的数字不是理论推演而是由仓库自带的 evals 工具通过真实服务栈端到端跑出来的。评测链路共四步没有任何环节被 mock4.1 启动真实服务子进程retrieval/mod.rs中的EvalServer::launch会在一个全新的临时数据目录上启动真实的ai-memory serve子进程。zero-llm 模式意味着无 consolidation LLM无 embedder无 reranker完全确定性与离线可复现。该模式的等价生产配置是embedding_provider none见 config.default.toml 中关于 2.0 默认 embedding 与显式 opt-out 的注释或任何模型无法加载的主机。4.2 通过 /hook/batch 回放 haystack每道题对应一个私有项目lme-question_id其 ~50 个会话的 haystack 通过POST /hook/batch按生产 hook 节奏回放见 ingest.rssession-start → (user-prompt-submit stop) × 每轮对话 → session-end其中stop事件携带 opt-in 的助手摘要_ai_memory_assistant.excerptcapture_assistant1。回放忠实继承生产捕获的两条约束excerpt 上限 ~2 KB客户端cap_excerpt在 UTF-8 字符边界截断服务器端同样限流——证据若深埋在单个超长 turn 中索引确实够不到这是被度量的系统本身的一部分而非 harness 伪影会话日期前缀每个 turn 文本前注入[session date: …]补偿重放历史缺少真实时间戳的问题官方 LongMemEval harness 同样把时间戳暴露给检索器。注入还有一层健壮性保障ingest_question会重试被服务器限流跳过的 batch item直到全部接受——静默丢失 haystack 数据会直接污染基准因此这种失败被设计为硬失败而非软跳过。4.3 通过 MCP memory_query 查询查询走的是真实 MCP Streamable-HTTP 接口tools/call memory_query见 query.rs与真实 Agent 完全同一条路径并显式传入workspacelongmemeval与projectlme-id做作用域隔离。响应同时解析结构化页面命中hits与原始 observation 命中raw_hits并按编译页面优先、原始命中随后的顺序扁平化pages_rank_before_raw_hits_and_order_is_preserved测试保障。4.4 会话级打分与报告打分在 score.rs 完成之后report.rs输出带完整溯源commit、数据集 sha、硬件、逐题分数的report.{json,md}落盘到evals/runs/timestamp-retrieval/。发布基线时只需把 markdown 复制进docs/benchmarks/——本系列三份报告正是这样产生的。五、如何复现这份基准5.1 准备与运行按照 evals/README.md 与 docs/benchmarks/README.md复现命令如下# 1. 构建被测服务端ai-memory-cli 的 release 二进制 cargo build --release -p ai-memory-cli # 2. 下载数据集并跑完整 500 题278 MB校验和固定上游漂移会响亮报错 cargo run --release -p ai-memory-eval -- retrieval --fetch # 3. 快速冒烟前 10 题用于迭代 cargo run -p ai-memory-eval -- retrieval --sample 10retrieval子命令支持的参数见RetrievalArgs包括参数默认值说明--datasetevals/datasets/longmemeval_s.json数据集路径--fetch关缺失时先下载--server-bintarget/release/ai-memory被测服务端二进制--sample N无只跑前 N 题确定性前缀--ks 1,3,5,101,3,5,10hitk / recallk 的截断点--concurrency8并发题数--outevals/runs输出根目录--embeddings none\|localnonenone zero-llmlocal 进程内 all-MiniLM-L6-v25.2 复现三种模式本报告的 zero-llmpre-2.0 FTS--embeddings none在当时的 commit 上运行即 0.617 基线stopword-filtered FTS对 bare-query 的 FTS OR-join 去掉停用词后重跑hit5 提升至 0.6685.1 点hit1 提升 0.449 → 0.5348.5 点对应 longmemeval-s-2026-09-01-fts.mdlocal embeddings2.0 默认--embeddings local进程内 all-MiniLM-L6-v2384 维嵌入器模型首次使用时拉取约 87 MB 到evals/models/校验和锁定整体 hit5 达 0.823。5.3 诚实数字的边界README 明确给出可比性说明外部可比口径agentmemory 0.967 R5hybrid reranking、doobidoo/mcp-memory-service 0.804 R5 均为 embedding-based 检索在原始聊天日志上的成绩本项目对外可比的口径是 hit5。不可忽略的成本本流水线额外承担了生产形态捕获的开销2 KB excerpt 隐私边界因此长 turn 深处的证据确实在索引可达范围之外——基准度量的是交付的系统而不是理想化的检索器。回归门槛Roadmap 2-6 项会重跑此基准任何使某个 slice 明显下降的改动都被视为需要修复的回归而非可发布的注记。六、从 0.617 到 0.823两份姊妹报告串起 2.0 检索升级路径将三份报告并排阅读可以看到 2.0 检索重构在同一个 harness 上实测的两次跃迁停用词过滤zero-llm 内部把 bare-query FTS OR-join 中的停用词剔除overall hit5 从 0.617 升至 0.668hit1 从 0.449 升至 0.534——一次零模型成本、完全确定性的改进本地 embedding 混合检索进程内 all-MiniLM-L6-v2 嵌入器正确 masked-mean pooling与 FTS5 entity graph 融合overall hit5 进一步升至 0.823recall5 达 0.680。注意 docs/benchmarks/README.md 特别指出仅 pooling 修复一项就值约 6.6 个点对比 padded-attention 实现且是被 calibration 测试捕获的——这解释了为什么仓库强调每个中间数字都在该改动落地前于同一 harness 上实测。从 slice 视角看local embedding 对multi-session和knowledge-update的提升最为显著hit5 分别 0.570 → 0.876、0.708 → 0.903说明向量检索对跨会话、知识更新类问题的增益最大。七、延伸阅读与关键证据路径基准总览与可比性说明docs/benchmarks/README.md另外两份同日基准longmemeval-s-2026-09-01-fts.mdstopword-filtered FTS、longmemeval-s-2026-09-01-local.mdlocal embeddings评测 harness 使用手册含完整命令行示例evals/README.md评测入口与参数定义evals/src/main.rs、evals/src/retrieval/mod.rs会话级评分器及全部单元测试evals/src/retrieval/score.rshook 回放注入生产节奏、2 KB excerpt、日期前缀evals/src/retrieval/ingest.rsMCP 查询与页面归属evals/src/retrieval/query.rs2.0 默认 embedding 配置说明crates/ai-memory-cli/templates/config.default.tomlunset 进程内 all-MiniLM-L6-v2384 维embedding_provider none即回到本文 zero-llm 的确定性检索栈本地嵌入的详细设计docs/local-embeddings.md【免费下载链接】ai-memorySolution for long term memory for agent coding CLIs and to facilitate handoff between different agent vendors项目地址: https://gitcode.com/GitHub_Trending/ai/ai-memory创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
