企业官网建设流程全解析

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

【免费下载链接】mempalaceThe best-benchmarked open-source AI memory system. And it's free.项目地址: https://gitcode.com/GitHub_Trending/me/mempalace

MemPalace 在仓库内固化了一套可复现的检索召回（retrieval recall）基准：无需任何 LLM 参与、只做"原文存储 + 向量搜索"的基线即可在 LongMemEval 全量 500 题上拿到96.6% R@5，加入关键词/时间/偏好加权与可选重排后最高达到 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% R@5。

该结果的论证逻辑在于信息不损失：当 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 题：

Held-out 集（450 题，开发 hybrid_v4 期间从未使用）：

页面给出了一个重要的方法论提醒：全量 500 题分数更高，但它包含 hybrid_v4 三处针对性修复（引号短语加权、人名加权、怀旧句式识别）开发时所针对的那 50 道 "dev" 题——这在 benchmarks/BENCHMARKS.md 中被直白地称为 "teaching to the test"（对着考题教学）。因此当只需引用 hybrid 管线单一 R@5 数字时，held-out 的 98.4% 才是干净、可泛化的数字。开发/评测切分由仓库中的 benchmarks/lme_split_50_450.json 固化（seed=42，50 dev / 450 held-out），评测脚本用--dev-only/--held-out两个开关约束迭代污染（详见后文 CLI 参数）。

Raw 96.6% 的分类型拆解

两个最弱类型恰好指向了后续改进的两条路径（可在 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）：

页面对此明确拒绝发布"100% R@10"式头条，原因很值得细读：早期草稿里的 100% 使用了top_k=50，而每段对话的 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 与 MemBench

ConvoMem（Salesforce；5 类 × 每类 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。

MemBench（ACL 2025；8,500 项，全主题）：MemPalace hybrid top-5整体 80.3% R@5。最强类型：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 的 R@5 与其他项目"端到端 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，磁盘占用约 300MB（LongMemEval），单次全量约 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 全量 500）：Recall@5: 0.966、Recall@10: 0.982、NDCG@10: 0.889。

3. LongMemEval —— hybrid v4 held-out（98.4%）

python benchmarks/longmemeval_bench.py /tmp/longmemeval_s_cleaned.json \ --mode hybrid_v4 --held-out --split-file benchmarks/lme_split_50_450.json

4. LongMemEval —— hybrid v4 + LLM rerank（99.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-tag>

5. LoCoMo —— session top-10（60.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 按轮。
• --mode：LongMemEval 支持raw|aaak|rooms|hybrid|hybrid_v2|hybrid_v3|hybrid_v4|palace|diary|full；LoCoMo 支持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-v2（ChromaDB 内置）；bge-large= BAAI/bge-large-en-v1.5（1024 维，约 1.3GB，需pip install fastembed）；nomic768 维约 274MB。
• --llm-rerank+--llm-backend anthropic|ollama+--llm-model+--llm-base-url：可选重排。anthropic 后端读ANTHROPIC_API_KEY或--llm-key；ollama 后端走 OpenAI 兼容/v1/chat/completions，无需 Anthropic key。
• --split-file/--create-split/--dev-only/--held-out：50/450 训练评测切分的创建与使用；--create-split首次生成切分（seed=42），--dev-only可反复迭代调参，--held-out只在最终发布时跑一次。
• 输出文件未指定时自动命名到benchmarks/results_*下，如results_mempal_{mode}_{granularity}_{时间戳}.jsonl。

7. 结果逐题审计

每条评测记录都带逐题明细，而非只有聚合值。仓库中已固化了多份结果文件可直接核对：raw 结果见 benchmarks/results_mempal_raw_session_20260414_1629.jsonl，hybrid 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.jsonl，LoCoMo raw/hybrid 见 benchmarks/results_locomo_raw_session_top10_20260414_1634.json 与 benchmarks/results_locomo_hybrid_session_top10_20260414_1649.json，ConvoMem 见 benchmarks/results_convomem_raw_top10_20260414_1649.json，MemBench 见 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 it's free.项目地址: https://gitcode.com/GitHub_Trending/me/mempalace