BM25 与向量检索的实测口径，来自 ReMe 的 500 问基准
聊记忆插件的检索质量，最容易变成「我感觉挺准」。ReMe 至少给了可复核的数字：LongMemEval cleaned-s 的 500 个问题上 89.4%，BEAM 在 100K 上下文 66.1%、1M 上下文 65.0%，π-Bench 五人格的 PROC 得分 0.580。这篇不吹分，只拆这些数字是怎么来的、你本机跑起来会差在哪。想先看同类插件清单，见 完整插件清单与汉化避坑指南。
三个数字各自在测什么
LongMemEval 测的是跨会话检索：记忆分散在多轮历史里，提问需要把几处信息拼起来。cleaned-s 是它的清洗子集，500 个问题，89.4% 是 agentic 搜索-读取工作流的得分——也就是允许模型先搜、再读、再答，不是一次向量召回定胜负。
BEAM 测的是长上下文下的记忆任务，十类任务，100K 上下文 20 个案例 / 400 个问题得 66.1%，1M 上下文 35 个案例 / 700 个问题得 65.0%。两个规模差一个数量级，分数只掉 1.1 个百分点，说明它的检索路径不是把全量内容塞进上下文。
π-Bench 的 PROC 测的是主动处理隐藏意图：澄清、跨会话偏好与约定、任务依赖、欠指定请求。0.580 这个数在仓库给出的同测试模型配置下比 NanoBot 高 2.4%。这是一个相对值，不要读成「58% 正确率」。
三组数字都是仓库公布的参考跑分，模型、提示词、数据集与判分细节写在各自文档里，不是第三方盲测。
检索在本地是怎么走的
默认只有两条路：BM25 关键词，加 wikilink 邻域扩展。搜索返回的是带行号区间的片段加上有界的邻居，不是整篇文档。
这个设计直接影响体感：问「周报是周几、什么格式」，命中的可能是daily/2026-09-11/xxx.md的第 12–28 行，加上它链到的一个 digest 节点。上下文里进的是几百字，不是一篇三千字的日记。
启用 embedding 之后，向量结果与 BM25 用RRF（倒数排名融合）合并。RRF 的好处是不需要调权重：两路各按排名给分，再相加。代价是融合后的排序不再能解释成「相似度」，你没法说「这条 0.82 分」。
性能开销落在哪几处
| 环节 | 什么时候发生 | 开销来源 |
|---|---|---|
| 摄入与切分 | 后台 watcher 发现daily/、digest/有新 Markdown | 读文件、切块、写 metadata |
| BM25 建索引 | 摄入时 | 词项统计，随文件量线性增长 |
| 向量化 | 只在启用 embedding 后 | 每条切片一次 embedding 调用 |
| 检索 | 每次reme_search | BM25 查询 + 可选向量查询 + wikilink 扩展 |
| 整合 | 每日auto_dream | 一次模型调用，默认最多五个单元 |
真正会让人觉得「变慢」的是向量化那一步：它把本地文件操作变成了对外部 API 的批量调用。BM25 建索引是纯本地的，量级完全不是一个层次。
插件侧还有两个超时兜底：requestTimeoutMs默认 10000 毫秒，backgroundTimeoutMs默认 3600000 毫秒。前者是单次检索的墙钟上限，后者是后台采集与整合的预算。检索慢就先调前者，别去调后者。
坑一 · 以为默认就有语义检索
现象。用一个和原文措辞完全不同的说法去问，什么都搜不到；换成原文里的词，立刻就命中。
原因。embedding 默认是关闭的，默认链路只有 BM25 加 wikilink。BM25 是词项匹配，同义改写的召回天然弱。
解决。要语义检索得改三处：reme/config/default.yaml里打开components.as_embedding与components.embedding_store，再把components.file_store.default.embedding_store从空串改成default，另外配好 embedding 的 Key。改完重新摄入（不是只 reindex），向量才有内容。
坑二 · 没配模型就期待自动采集出内容
现象。聊了一整天，Journal 里空空；reme_search能查到手写进去的节点，但对话内容一条都没进。
原因。auto_memory与auto_dream都要调模型。LLM_API_KEY缺失时，能用的只有文件操作、BM25 检索、wikilink 遍历和读兴趣主题——这是插件文档写明的降级范围。
解决。检查.env里的LLM_API_KEY与LLM_BASE_URL是否被服务进程读到，然后看 Status → Auto Memory 的队列是否在跑。注意聊天完成与记忆落盘是异步的，刚聊完就去看，任务大概率还在 Queued。
坑三 · 空查询被直接拒绝
现象。传了空字符串或只有空格的query，工具返回失败，而不是返回全量结果。
原因。query为空按失败关闭处理（fail closed）。这是刻意的：空查询返回全库既无意义，也会把上下文塞满。
解决。让 Agent 用具体的自然语言问句。另外两个参数别乱填：limit范围 1–50，默认取searchLimit（默认 5）；min_score传负数会被归零，正常情况就留 0。
坑四 · Journal 只列最新五千个文件
现象。在 Journal 里翻不到三个月前的一条记忆，以为文件丢了。
原因。Journal 是浏览入口，列表上限是最新 5000 个文件。它不是全量索引，也不是搜索。
解决。找旧内容用reme_search，或者直接在文件系统里按路径找——记忆本来就是 Markdown，grep也能用。这一点是文件形态记忆的实际好处。
坑五 · 把 reindex 当成补索引
现象。新写了一篇笔记，跑reme reindex，然后还是搜不到。
原因。reme reindex只做一件事：从已摄入的切片重建 BM25 与向量。它不读新文件。新文件靠后台 watcher 摄入。
解决。确认 watcher 在跑；要强制补，用reme auto_index这条路径触发摄入，再重建索引。索引坏了用reindex，内容没进来用摄入。
一次可复现的自测怎么做
- 写入三条互相矛盾的事实（例如「周报周五」和「周报周一」）；
- 用不含原始措辞的同义问句查一次，记录返回的路径与行号；
- 打开 embedding 再查一次，比较排序差异；
- 关掉
LLM_API_KEY再查一次，确认检索仍可用但采集停摆。
四步下来，你对「默认能力」和「开满能力」的差距会有具体感受，比看分数可靠。
总结
ReMe 的分数来自允许「先搜再读」的 agentic 工作流，不是单次向量召回；本地默认只有 BM25，语义检索需要显式开启。想对照其他记忆与工具类插件的中文说明，见 完整插件清单与汉化避坑指南。
适合与不适合
适合：正在评估记忆插件检索质量、需要可复核数字的人；想把本地 BM25 升级到混合检索的人；关心「记忆检索到底吃掉多少上下文」的人。
不适合：期待装完就有语义检索的人；不愿意配 embedding Key 与改 YAML 的人；把仓库参考跑分当成第三方评测的人。
标签：ReMe、DeepSeek Harness、检索性能、BM25、向量检索
本文由 DeepSeek Harness Hub 自动整理，数据来源于插件详情页。
