BM25 与向量检索的实测口径，来自 ReMe 的 500 问基准

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读文件、切块、写 metadataBM25 建索引摄入时词项统计随文件量线性增长向量化只在启用 embedding 后每条切片一次 embedding 调用检索每次reme_searchBM25 查询 可选向量查询 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默认 5min_score传负数会被归零正常情况就留 0。坑四 · Journal 只列最新五千个文件现象。在 Journal 里翻不到三个月前的一条记忆以为文件丢了。原因。Journal 是浏览入口列表上限是最新 5000 个文件。它不是全量索引也不是搜索。解决。找旧内容用reme_search或者直接在文件系统里按路径找——记忆本来就是 Markdowngrep也能用。这一点是文件形态记忆的实际好处。坑五 · 把 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 自动整理数据来源于插件详情页。