ARTICLE DETAIL

资讯详情

深耕网站视觉设计与运营推广的一线实战洞察。

MemPalace 检索基准全解析:零 LLM 的 LongMemEval 96.6% R@5 与端到端复现指南

MemPalace 检索基准全解析:零 LLM 的 LongMemEval 96.6% R@5 与端到端复现指南 MemPalace 检索基准全解析零 LLM 的 LongMemEval 96.6% R5 与端到端复现指南【免费下载链接】mempalaceThe best-benchmarked open-source AI memory system. And its free.项目地址: https://gitcode.com/GitHub_Trending/me/mempalaceMemPalace 在仓库内固化了一套可复现的检索召回retrieval recall基准无需任何 LLM 参与、只做原文存储 向量搜索的基线即可在 LongMemEval 全量 500 题上拿到96.6% R5加入关键词/时间/偏好加权与可选重排后最高达到 98.4%held-out 干净集乃至 99.2%。本文以官方基准精选页为骨架结合仓库内基准脚本逐项解读这些数字的含义、指标边界、为什么不发布跨系统对比表并给出可在本仓库中一步步执行、逐题审计的完整复现流程。本文所有结论均来自仓库内文档与脚本主线依据是 website/reference/benchmarks.md本文主题文档完整的实验演进史hybrid v1→v4、palace 模式、LoCoMo 架构迭代与方法论审计见 benchmarks/BENCHMARKS.md逐条复现命令的速查版在 benchmarks/README.md。核心发现最简基线胜过抽取式记忆主流 AI 记忆系统普遍假设必须用 LLM 决定记什么Mem0 用 LLM 抽取事实、Mastra 用 GPT-5-mini 观察会话、Supermemory 用 LLM 做 agentic 检索。而 MemPalace 的原始基线raw baseline只做一件事——把原文verbatim session text原样存入向量库用向量库默认嵌入搜索不抽取、不摘要、无 LLM就在 LongMemEval 上复现出96.6% R5。该结果的论证逻辑在于信息不损失当 LLM 抽取user prefers PostgreSQL并丢弃原始对话时它同时丢掉了为什么、考虑过的替代方案、讨论过的权衡。原始文本优质嵌入之所以是比想象中强得多的基线正因为它没有丢信息这也是抽取式路线与原文检索路线最根本的分野对应评测脚本即 benchmarks/longmemeval_bench.py 中的build_palace_and_retrieve()将每个 session 的 user turns 拼接为单文档后整段collection.add。需要强调本页所有头条数字均为检索召回retrieval recall——标注的正确 session 是否出现在 top-K 检索结果中而非端到端 QA 正确率。两者不是一回事系统可以检索全中而 QA 答得很差也可以反之。LongMemEval从 96.6% 基线到 98.4% 干净集LongMemEval 是当前 AI 记忆领域的标准评测每个问题对应约 53 个候选 session共 500 题。MemPalace 页面公布三档数字全量 500 题模式R5是否需要 LLMCost/queryRaw —— 对逐字 session 做向量搜索96.6%无$0Hybrid v4 —— 关键词/时间/偏好加权无 LLM98.6%无$0Hybrid v4 LLM rerankminimax-m2.7 via Ollama99.2%任意有能力的模型$0 本地 / 云端另计Held-out 集450 题开发 hybrid_v4 期间从未使用模式R5R10NDCG10Hybrid v498.4%99.8%0.938页面给出了一个重要的方法论提醒全量 500 题分数更高但它包含 hybrid_v4 三处针对性修复引号短语加权、人名加权、怀旧句式识别开发时所针对的那 50 道 dev 题——这在 benchmarks/BENCHMARKS.md 中被直白地称为 teaching to the test对着考题教学。因此当只需引用 hybrid 管线单一 R5 数字时held-out 的 98.4% 才是干净、可泛化的数字。开发/评测切分由仓库中的 benchmarks/lme_split_50_450.json 固化seed4250 dev / 450 held-out评测脚本用--dev-only/--held-out两个开关约束迭代污染详见后文 CLI 参数。Raw 96.6% 的分类型拆解题型R5题数Knowledge update99.0%78Multi-session98.5%133Temporal reasoning96.2%133Single-session user95.7%70Single-session preference93.3%30Single-session assistant92.9%56两个最弱类型恰好指向了后续改进的两条路径可在 benchmarks/BENCHMARKS.md 中核对完整演进assistant 类问题靠同时索引 assistant 轮次修复源码build_palace_and_retrieve_full注释明确说明 assistant 回复含确认过的事实preference 类问题靠 hybrid v3 的 16 条偏好抽取正则PREF_PATTERNS从I prefer X、I usually do Y等真实表达中生成User has mentioned: ...合成文档拉近语义鸿沟。LoCoMo诚实的 60.3% 与 hybrid v5 的 88.9%LoCoMo 含 1,986 道题分布在 10 段长对话上每段 19–32 个 session模式R10是否需要 LLMSession无重排top-1060.3%无Hybrid v5关键词 谓词加权top-1088.9%无页面对此明确拒绝发布100% R10式头条原因很值得细读早期草稿里的 100% 使用了top_k50而每段对话的 session 数只有 19–32——也就是说 top-k 已经超过候选总数检索阶段在构造上就会返回该对话的全部 session。此时测的已不是检索而是 LLM 对整段对话的阅读理解。因此 LoCoMo 诚实的检索召回数字就是 top-10 行。这段自曝也可见于 benchmarks/BENCHMARKS.md 的 LoCoMo 100% — a separate caveat 一节。从 benchmarks/locomo_bench.py 源码可看到 hybrid v5 的实际加权实现fused dist * (1.0 - 0.50 * pred_overlap)之后再叠引号短语 60% 与词形名词 20% 的距离缩减。其关键改进是从关键词重叠评分中剔除人名——LoCoMo 中双方说话者名字出现在每个 session若纳入关键词加权会给所有 session 均等信号剔除后谓词关键词research、career才真正发挥作用。其它基准ConvoMem 与 MemBenchConvoMemSalesforce5 类 × 每类 50 项 250 项样本MemPalace raw 检索平均召回92.9%。最强类型 Assistant Facts 100%、User Facts 98%最弱 Preferences 86%。页面同时说明完整 Salesforce 数据集约 75K 项头条数字来自评测脚本所设计的 250 项样本。运行入口为 benchmarks/convomem_bench.py六个可用类别为user_evidence、assistant_facts_evidence、changing_evidence、abstention_evidence、preference_evidence、implicit_connection_evidence。MemBenchACL 20258,500 项全主题MemPalace hybrid top-5整体 80.3% R5。最强类型aggregative 99.3%、comparative 98.4%、lowlevel_rec 99.8%最弱类型noisy 43.4%设计上就是干扰密集题、conditional 57.3%。这两类弱项与 verbatim 存储的设计边界一致当噪声在嵌入层面与信号无法区分时检索会退化而纯推理类题仅靠检索本就不够。运行入口为 benchmarks/membench_bench.py需 MemBench FirstAgent 数据目录--top-k默认 5。为什么不发布跨系统对比表页面明确解释历史版本曾把 MemPalace 的 R5 与其他项目端到端 QA 准确率并列在同一张 LongMemEval 表格里而这两者是不同指标、不可比——100% 检索召回的系统 QA 准确率可能只有 40%反之亦然。要做公平对比正确做法是要么用本仓库公开的检索召回数与评测脚本在同一指标下跑要么就采用对方发布方公开的指标口径各自对比并以其发布材料为准Mastra 发布的是 GPT-5-mini 下的二元 QA 准确率Mem0 发布的 LoCoMo 指标是端到端 QA 准确率而非检索召回Supermemory 的 ASMR 数字为 QA 准确率且作者明确将其定义为实验性 proof-of-concept。换言之指标口径不对齐的榜单没有意义这正是本文不输出第三方外部链接、只陈述口径差异的原因。端到端复现指南基准脚本的确定性来自三个方面可参见 benchmarks/BENCHMARKS.md 与 benchmarks/README.md固定数据集、ChromaDB 确定性嵌入、脚本内无随机性——同一数据 同一脚本 同一切分种子 → 同一分数。1. 环境准备# 仓库内开发依赖安装二选一 uv sync --extra dev # 或: pip install -e .[dev]复现需要公开学术数据集文件LongMemEval 的longmemeval_s_cleaned.json、LoCoMo 的locomo10.json、MemBench 的 FirstAgent 目录、ConvoMem 由脚本自动获取以下命令假设数据文件已按各自数据集官方发布页下载/克隆到本机。数据仅在下载阶段需要联网评测过程本身无 API Key、无 GPU磁盘占用约 300MBLongMemEval单次全量约 5 分钟。2. LongMemEval —— raw 基线96.6%# 先把 longmemeval_s_cleaned.json 下载/放置到 /tmp/longmemeval_s_cleaned.json python benchmarks/longmemeval_bench.py /tmp/longmemeval_s_cleaned.json预期输出raw 全量 500Recall5: 0.966、Recall10: 0.982、NDCG10: 0.889。3. LongMemEval —— hybrid v4 held-out98.4%python benchmarks/longmemeval_bench.py /tmp/longmemeval_s_cleaned.json \ --mode hybrid_v4 --held-out --split-file benchmarks/lme_split_50_450.json4. LongMemEval —— hybrid v4 LLM rerank99.2%# 任意 OpenAI 兼容端点均可ollama 后端默认指向 http://localhost:11434 python benchmarks/longmemeval_bench.py /tmp/longmemeval_s_cleaned.json \ --mode hybrid_v4 --llm-rerank \ --llm-backend ollama --llm-model your-model-tag5. LoCoMo —— session top-1060.3%与其它模式python benchmarks/locomo_bench.py /tmp/locomo/data/locomo10.json \ --granularity session --top-k 10 # session top-10: 60.3% python benchmarks/locomo_bench.py /tmp/locomo/data/locomo10.json \ --granularity dialog --top-k 10 # dialog 更难的基线: 48.0% python benchmarks/locomo_bench.py /tmp/locomo/data/locomo10.json \ --granularity session --mode hybrid --top-k 10 # hybrid v5: 88.9%6. 评测脚本 CLI 速查可验证参数来自 benchmarks/longmemeval_bench.py 与 benchmarks/locomo_bench.py 的 argparse 定义--granularity session|turn/--granularity session|dialog文档切分粒度session 为整段会话单文档turn 按轮。--modeLongMemEval 支持raw|aaak|rooms|hybrid|hybrid_v2|hybrid_v3|hybrid_v4|palace|diary|fullLoCoMo 支持raw|aaak|hybrid|rooms|palace。--limit N只跑前 N 题/前 N 段对话做冒烟测试如 LongMemEval--limit 20。--hybrid-weight 0.30关键词重叠加权的融合系数文档注明全量 500 题上调 0.30 与 0.40 在噪声范围内等价可探索 0.10–0.60。--embed-model default|bge-base|bge-large|nomic|mxbai默认all-MiniLM-L6-v2ChromaDB 内置bge-large BAAI/bge-large-en-v1.51024 维约 1.3GB需pip install fastembednomic768 维约 274MB。--llm-rerank--llm-backend anthropic|ollama--llm-model--llm-base-url可选重排。anthropic 后端读ANTHROPIC_API_KEY或--llm-keyollama 后端走 OpenAI 兼容/v1/chat/completions无需 Anthropic key。--split-file/--create-split/--dev-only/--held-out50/450 训练评测切分的创建与使用--create-split首次生成切分seed42--dev-only可反复迭代调参--held-out只在最终发布时跑一次。输出文件未指定时自动命名到benchmarks/results_*下如results_mempal_{mode}_{granularity}_{时间戳}.jsonl。7. 结果逐题审计每条评测记录都带逐题明细而非只有聚合值。仓库中已固化了多份结果文件可直接核对raw 结果见 benchmarks/results_mempal_raw_session_20260414_1629.jsonlhybrid v4 held-out 见 benchmarks/results_mempal_hybrid_v4_held_out_session_20260414_1634.jsonl加 LLM 重排的两份 benchmarks/results_mempal_hybrid_v4_llmrerank_session_20260414_1654.jsonl 与 benchmarks/results_mempal_hybrid_v4_llmrerank_session_20260414_1659.jsonlLoCoMo raw/hybrid 见 benchmarks/results_locomo_raw_session_top10_20260414_1634.json 与 benchmarks/results_locomo_hybrid_session_top10_20260414_1649.jsonConvoMem 见 benchmarks/results_convomem_raw_top10_20260414_1649.jsonMemBench 见 benchmarks/results_membench_hybrid_all_movie_top5_20260414_1656.json。每个 JSONL/JSON 均含每道问题、每条被检索出的语料 id 与每项得分可核对到单题。量化边界这些数字能说明什么把上面的事实放到一起可以给读者一个诚实的能力边界清单免费离线可用raw 96.6% 无需任何 API Key——索引进、检索、打分全程无 LLM、无 GPU依赖仅chromadb。LLM 重排是可选增强而非必需品98.6%→99.2% 的提升来自关键词/时间/偏好加权已含在 hybrid v4再加 LLM 重排才到更高档从 benchmarks/BENCHMARKS.md 的演进看Haiku 级模型做重排约 $0.001/题量级。指标是检索召回不是 QA 正确率本仓库各脚本的compute_retrieval_recall/evaluate_retrieval只回答证据是否进 top-K端到端问答还需要另行接 LLM 生成与打分。top-k 语义必须与候选规模对齐LoCoMo 的教训说明top_k一旦超过每对话 session 上限召回在构造上即饱和无法再衡量检索质量。干净数字与调参数字要分开引用引用 hybrid 管线时用 held-out 98.4%benchmarks/lme_split_50_450.json 定义切分raw 96.6% 全程无启发式、无调参本身即为干净基线。若要探索更完整的历史hybrid v1→v4 每步 1.2pp→0.6pp 的得分推进、palace/diary 两种并行架构、bge-large 等未来干净实验的规划与 bge-large/nomic 等嵌入替代方案建议直接阅读 benchmarks/BENCHMARKS.md若需在自有硬件上按最小命令集快速起跑benchmarks/README.md 是更浓缩的速查入口。【免费下载链接】mempalaceThe best-benchmarked open-source AI memory system. And its free.项目地址: https://gitcode.com/GitHub_Trending/me/mempalace创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
返回列表