tkmind/memind
1
0
Fork 0
Code Issues Pull Requests 2 Actions Packages Projects Releases Wiki Activity
Files
1d1af5c6577b19fd5cd7f1e42fe413c083a5aa38
memind/docs/architecture/memfuse-bench-baseline.md
T
john 6d48480b1c Improve cross_device MemFuse recall with source tags and recallContext. 
Auto-enable device/location prefixes for cross_device scenarios, thread question_device into keyword and embedding paths, and boost lexical scores from source-tag tokens.

Co-authored-by: Cursor <cursoragent@cursor.com>
2026-09-02 14:12:48 +08:00

19 KiB
Raw Blame History

MemFuseBench 检索基线（Memory V2）

日期: 2026-09-02

状态: 已落地测量工具 + 首份基线。不改动任何生产运行时路径，纯离线评测。

0. 结论

在 MemFuseBench 的 357 个证据锚定问题、7823 条来源标注事件上跑现网 pgvector 检索排序链路，得到：

指标 k=5 k=20 k=50
候选召回 candidateRecall 36.6% 36.6% 36.6%
最终召回 recall@k 6.8% 13.5% 22.5%
排序丢失 rankingLoss 29.8% 23.1% 14.2%
至少命中一条 hitAny@k 21.8% 41.7% 64.4%
清单覆盖 checklistCoverage 7.8% 16.8% 28.3%
MRR 0.135 0.153 0.160
干扰项占比 distractorRate 8.5% 10.8% 12.6%

两个可操作结论：

  1. 天花板在候选生成，不在 k。 candidateRecall 恒为 36.6%，与 k 无关——超过 63% 的证据从未进入候选池，再怎么调排序或放大 k 都拿不回来。
  2. 进了候选池的证据，排序又丢掉了一大半。 k=20 时候选池已包含 36.6% 的证据，最终只留下 13.5%，rankingLoss 23.1 个百分点。即使 k=50（在约 200 条候选里返回 50 条），仍丢 14.2 个百分点。MRR 从 k=5 到 k=50 只从 0.135 涨到 0.160，说明列表头部的质量与 k 无关地差。

按维度看，multi_source_conflict_arbitration 明显最好（候选 71.5% / 召回 39.4%），cross_device_information_fusion 最差（26.5% / 6.1%）。

keyword 路径修复后（commit 2c0d903e，k=20）

只改 fetchKeywordCandidates：去掉 ORDER BY updated_at DESC，扩大 fetch cap 后按 lexicalQueryCoverage 排序；keyword 行携带 lexical 分。rankHybridCandidates 未改。

指标 修复前 修复后 Δ
candidateRecall 36.6% 72.8% +36.2pp
recall@k 13.5% 13.3% ≈0
hitAny@k 41.7% 43.1% +1.4pp
checklistCoverage 16.8% 16.4% ≈0

候选池扩大后 rankingLoss 相对值上升（59.5pp），但最终 recall 几乎不变——下一刀必须改 rankHybridCandidates，且需接真实语义嵌入验证（lexical-hash 下改非中文 vector 优先会恶化至 ~5.7% recall）。

RRF 混合排序后（k=20，commit 待填）

rankHybridCandidates 改为 lexical / vector 双路 Reciprocal Rank Fusion（RRF k=60），不再以 lexical 分作为唯一主键。keyword 修复 + RRF 叠加：

指标 keyword 修复后 + RRF Δ
candidateRecall 72.8% 72.8% 0
recall@k 13.3% 14.5% +1.2pp
hitAny@k 43.1% 48.2% +5.1pp
checklistCoverage 16.4% 18.0% +1.6pp
rankingLoss 59.5% 58.4% -1.1pp
MRR 0.144 0.101 -0.043

RRF 在 lexical-hash 嵌入下只能小幅抬升 recall；对英文查询加权 vector 反而恶化（9.4%）。要再抬 recall 必须接真实语义嵌入（--embedding-module），否则 vector 路 rank 仍近似词面重叠。

英文词级 lexical + RRF（k=20，commit 待填）

MemFuseBench 为纯英文：将 lexicalQueryCoverage 在 Latin 查询下改为词 token 重叠（过滤英文停用词），中文仍用 CJK 2-gram；extractKeywordTerms 同步过滤英文 boilerplate。

指标 + RRF (2-gram) + 英文词级 lexical Δ
candidateRecall 72.8% 72.9% ≈0
recall@k 14.5% 23.1% +8.6pp
hitAny@k 48.2% 63.9% +15.7pp
checklistCoverage 18.0% 28.1% +10.1pp
rankingLoss 58.4% 49.8% -8.6pp
MRR 0.101 0.314 +0.213

机制一（英文 2-gram 近随机）已被词级覆盖显著缓解；vector 路仍受 lexical-hash 替身限制，接真实嵌入是下一档提升空间。

自适应 RRF 权重（k=20，commit 待填）

Latin 查询下检测 vector 分 spread（max − median）：仅当 spread ≥ 0.20 且 max ≥ 0.50 时，将 vector 权重升至 1.55、lexical 降至 0.45。阈值刻意收紧，避免 lexical-hash 替身嵌入误触发 vector 优先（spread ≥ 0.08 时 recall 会从 23.1% 跌至 ~18.7%）。

指标 + 英文词级 lexical + 自适应 RRF (lexical-hash) + DashScope（隔离前）
candidateRecall 72.9% 72.9% 74.5%
recall@k 23.1% 21.5% 23.7%
hitAny@k 63.9% 62.5% 64.1%
checklistCoverage 28.1% 26.0% 29.4%
rankingLoss 49.8% 51.5% 50.8%
MRR 0.314 0.301 0.293

keyword 分数隔离 + vector 权重路由（k=20，commit 待填）

fetchKeywordCandidates 不再把 lexical 分写入 score，避免 keyword-only 条目污染 vector RRF 排序池。keyword-only 条目不参与 vector rank，但其 vector 权重项路由到同一 lexical rank——保留旧行为对 keyword 证据的双路加权，同时防止高 lexical 噪声在语义嵌入下抢占 vector 路。

指标 自适应 RRF (lexical-hash) + keyword 隔离 + DashScope
candidateRecall 72.9% 72.9% 74.5%
recall@k 21.5% 23.1% 23.9%
hitAny@k 62.5% 65.8% 65.8%
checklistCoverage 26.0% 28.5% 29.4%
rankingLoss 51.5% 49.8% 50.6%
MRR 0.301 0.312 0.326

DashScope text-embedding-v3 全量 357 题：隔离后在 recall / hitAny / MRR 上均优于隔离前（MRR 0.293 → 0.326）。排序仍是主瓶颈（rankingLoss ~51%）。

英文 keyword 提取优化（k=20，commit 待填）

extractKeywordTerms 扩展英文问句停用词（together/happened/timeline 等），Latin 查询优先保留专有名词（Ethan/Sarah），减少 ILIKE 噪声候选。

指标 keyword 隔离 (lexical-hash) + keyword 优化 + DashScope
candidateRecall 72.9% 75.8% 77.3%
recall@k 23.1% 23.4% 24.1%
hitAny@k 65.8% 65.8% 65.3%
checklistCoverage 28.5% 28.8% 29.8%
rankingLoss 49.8% 52.4% 53.2%
MRR 0.312 0.316 0.322

candidateRecall 提升 2.8pp（DashScope），recall@k 再抬 0.2pp；rankingLoss 仍 ~53%，下一刀继续压排序。

lexical 支持门控（k=20，commit 待填）

诊断 109 个 rank-only 失败：median gold rank 62，仅 22 题 gold 在 rank 21–30（near-miss）；多数 gold 仅经 keyword 进入候选池。语义 spread 可见时，对 零 lexical 重叠 的纯 vector 条目将 vector RRF 权重 ×0.6，避免其压过有弱词面匹配的 gold。

指标 keyword 优化 (lexical-hash) + lexical 门控 + DashScope
candidateRecall 75.8% 75.8% 77.3%
recall@k 23.4% 24.1% 24.1%
hitAny@k 65.8% 66.4% 65.3%
checklistCoverage 28.8% 29.8% 29.8%
MRR 0.316 0.317 0.322

DashScope 指标与门控前持平；lexical-hash 路径 recall +0.7pp。deep rank（51+）占 rank-only 的 ~58%，需候选生成或嵌入质量才能再抬。

分层 keyword 候选生成（k=20，commit 待填）

根因： broad OR + SQL LIMIT 500 在 lexical 排序之前截断，839 条匹配里 gold 可被随机丢弃（如 David/Ethan LEGO 题 candidateRecall=0 但 gold 全匹配 keyword）。

改动：

  • 专有名词/全大写词（Ethan、LEGO）各跑独立 ILIKE 桶（cap 120），再跑 general OR
  • 任何截断前按 lexicalQueryCoverage 排序（corpus pool 同步）
  • keyword 返回上限 50 → 100，maxTerms 8 → 12
指标 lexical 门控后 + 分层 keyword (lexical-hash) + DashScope
candidateRecall 75.8% 70.3% 74.7%
recall@k 24.1% 24.0% 25.7%
hitAny@k 66.4% 65.8% 68.6%
checklistCoverage 29.8% 29.5% 31.6%
rankingLoss 51.5% 46.3% 49.0%
MRR 0.317 0.313 0.330
全 miss 题数 15 — 3

全 miss 从 15 题降至 3 题；DashScope recall +1.6pp、hitAny +3.3pp、rankingLoss −4pp。候选池事件级覆盖略重组（专有名词桶 vs 泛 OR），但排序收益更大。

Vector 相似度 margin 扩展（k=20，commit 待填）

诊断：1147 个两路均未进的 gold 事件里，118 个 vector rank 101–200、179 个在 topScore−0.12 margin 内。

改动：

  • SQL / corpus pool：top-N（上限 150）∪ {score ≥ best − 0.15}（cap 200）∪ recent
  • selectVectorCandidateRows 与生产 CTE top_score 对齐
  • corpus pool 修复 async embedText await
  • 网格扫描（margin × expandCap）：0.15 / 200 最优；cap 250/300 无额外 recall 收益
指标 margin=0.12 margin=0.15（默认） Δ
candidateRecall 75.6% 76.7% +1.1pp
recall@k 28.5% 28.8% +0.3pp
hitAny@k 74.5% 74.8% +0.3pp
checklistCoverage 35.3% 35.7% +0.4pp
rankingLoss 47.1% 47.9% +0.8pp
MRR 0.390 0.392 +0.002

相对初始 DashScope 基线（~23.7% recall），累计 recall +5.1pp、hitAny +10pp、MRR +0.07。

cross_device 弱维优化（k=20，commit 待填）

cross_device_* 题全带 question_device（如 phone_sarah），证据跨 watch/phone/car 等设备，且 fusion 维平均 15.2 条 gold/题（recall@k 天然偏低，hitAny 更关键）。

改动：

  • 含 cross_device_* 题的 scenario 自动启用 [device · location] source-tags（写入语料前缀，供嵌入/lexical 共用）
  • resolve({ recallContext: { device, user } })：device 拆词优先 keyword（phone/sarah），嵌入 query 追加 device context: 行
  • latinWordQueryCoverage 对 source-tag 前缀 token（含 watch_ethan → ethan）额外 +35% 权重上限
维度 指标 优化前 优化后 Δ
information_fusion candidateRecall 70.1% 78.6% +8.5pp
information_fusion hitAny@k 62.0% 69.0% +7.0pp
information_fusion recall@k 11.0% 11.8% +0.8pp
causal_reasoning candidateRecall 66.0% 82.3% +16.3pp
causal_reasoning hitAny@k 81.0% 79.4% −1.6pp
causal_reasoning recall@k 22.8% 21.7% −1.1pp
全量 357 recall@k 28.8% 28.6% ≈0
全量 357 hitAny@k 74.8% 75.6% +0.8pp
全量 357 MRR 0.392 0.397 +0.005

fusion 仍是最弱维，但候选/ hitAny 明显提升；全量指标基本持平略升。生产侧需在写入记忆时 materialize 与 bench 一致的 device 前缀（或等价 metadata）。

语义嵌入（DashScope / Qwen，推荐）

memind_adm 后台 Providers 里配置的 DashScope Qwen 密钥存在 MySQL h5_llm_provider_keys，MemFuse bench 可直接复用，不需要 OpenAI：

# 自动读本地 DATABASE_URL + 已选/任一 DashScope key，模型默认 text-embedding-v3
npm run bench:memory-v2-memfuse:dashscope

# 指定某个 key（memind_adm Providers 页对应 id）
MEMIND_EMBEDDING_LLM_KEY_ID=<uuid> npm run bench:memory-v2-memfuse:dashscope

解密依赖 H5_SETTINGS_ENCRYPTION_KEY 或 TKMIND_SERVER__SECRET_KEY（本地 dev 通常与 memind_adm 一致）。

语义嵌入（OpenAI / Ollama，可选）

DeepSeek 没有 /embeddings 端点。其它可选：

# OpenAI
export OPENAI_API_KEY=sk-...
npm run bench:memory-v2-memfuse:semantic

# Ollama
export MEMIND_EMBEDDING_PROVIDER=ollama
export MEMIND_EMBEDDING_MODEL=nomic-embed-text
npm run bench:memory-v2-memfuse:semantic

嵌入向量会缓存到 .release-gate/memfuse-embedding-cache.json，重复跑 bench 不再调 API。探针失败时 CLI 会 skip（非 --strict）。

1. 两个已定位的机制

机制一：lexicalQueryCoverage 是主排序键，但判别力接近随机

memory-v2-pgvector.mjs 的 rankHybridCandidates 把 lexicalScore 作为第一排序键，向量分只在 lexical 分相同时才起作用。而 lexicalQueryCoverage 是字符 2-gram 覆盖率。全量 357 题实测：

  • gold 事件平均 coverage：0.5366
  • 非 gold 平均 coverage：0.4853
  • gold 高于语料中位数的比例：64.5%（随机为 50%）

也就是一个只比随机好 14.5 个百分点的弱信号，被用作压倒性的主排序键。在英文语料上排名最高的往往是最长、bigram 最密的无关句子。

这个启发式对中文是合理的——CJK 2-gram 近似于词，判别力强；对英文退化严重，因为 th/he/in 这类 bigram 在任何长句里都存在。

机制二：keyword 回退路径按时间排序截断，不按相关性

fetchKeywordCandidates 的 SQL 是 ... WHERE content ILIKE ANY(...) ORDER BY updated_at DESC LIMIT n。全量实测：

  • ILIKE 能匹配到的 gold：60.4%
  • 按 updated_at DESC 截断 100 条后存活的 gold：14.2%
  • 至少存活一条 gold 的问题占比：32.5%

一次纯粹由"按时间截断"造成的 46 个百分点损失。语料里匹配关键词的事件一旦多于 limit，这条路召回的就是"最新的匹配"而不是"最相关的匹配"。

2. 必须一起读的三条限制

不要把上面的绝对数字当成生产召回率。

  1. 默认嵌入是 lexical-hash，不是语义嵌入。 它是哈希词袋 + L2 归一化的确定性离线替身，cosine 近似词面重叠。报告里 embeddingMode 会标出来。机制一和机制二与嵌入无关（都在 lexical / keyword 路径上），但 36.6% 这个候选天花板里有一部分要归因于替身嵌入弱。用 --embedding-module 接真实嵌入后才能给向量路径定论。
  2. 语料是英文，而 lexical 层是按中文调的。 见机制一。这既是限制也是发现：一旦 Memind 要处理非中文内容，这条排序键就失效。
  3. 语料粒度比现网粗。 MemFuseBench 的语料是事件级（单场景 936–1886 条原始事件），而现网 memory_embeddings 存的是已经筛过的用户记忆，条数少得多。所以这份基线衡量的是"如果把原始事件流直接灌进现有检索层会怎样"——正好是 Event Kernel 方向会产生的形态。

3. 数据集与授权

数据集不入库。 它在仓库外，通过 MEMFUSE_BENCH_DATASET 或 --dataset 指定；缺失时所有入口返回 { available: false, reason }，CLI 打印 skip 并 exit 0（--strict 才 exit 1）。CI 无需数据集即可全绿。

git clone https://github.com/Darwin-Agent/Mi-Memory ~/Project/mi-memory

默认路径 ~/Project/mi-memory/MemFuse/MemFuseBench/memfusebench_dataset.json（6.2MB）。

项目 授权 本仓库可以做什么
Mi-Memory / MemFuseBench MIT（Darwin Agent Team, Xiaomi） 可自由使用数据集与论文思想
JKRiver / Riverse AGPL-3.0 或商业双授权 只做架构级参考，禁止移植代码

JKRiver 的 LICENSE 明确把"集成进专有产品"和"作为商业 SaaS 提供而不开源修改"列为需要单独商业授权的场景。Memind 是带计费的商业 SaaS，AGPL 的网络 copyleft 正好命中。因此：

  • 允许：借鉴设计决策（如整条流水线单事务 + 末步落 processed 水位的 at-least-once 幂等）、参考反面经验（migrations/008_drop_hypotheses.sql 记录了 hypotheses 表建后即废，被 layer='suspected'/'confirmed' + supersedes 取代）。
  • 禁止：把 agent/sleep/*.py（含 _maturity.py 的分层衰减表、disputes.py 的争议解决）逐行翻译进 memory-v2-lifecycle.mjs。取得商业授权前不做。

Mi-Memory 仓库本身没有代码，只有论文 PDF、项目页和图；MemStack / MemSense / D²ACCI / E²MEND / LiteMem 均无参考实现。唯一可直接使用的产物就是 MemFuseBench 数据集。

4. 用法

# 全量 357 题，约 3.5s
npm run bench:memory-v2-memfuse

# 单场景 / 单维度 / 冒烟
node scripts/run-memory-v2-memfuse-bench.mjs --scenario sc1 --limit 20
node scripts/run-memory-v2-memfuse-bench.mjs --dimension multi_source_conflict_arbitration
node scripts/run-memory-v2-memfuse-bench.mjs --max-questions 5 --quiet

# 接真实嵌入（模块需导出 embedText / embedQuery / default）
node scripts/run-memory-v2-memfuse-bench.mjs --embedding-module ./scripts/embed-memory-v2-openai-compat.mjs
npm run bench:memory-v2-memfuse:semantic

# OpenAI-compatible（默认 text-embedding-3-small）
#   MEMIND_EMBEDDING_API_KEY=...  或 OPENAI_API_KEY=...
#   MEMIND_EMBEDDING_BASE_URL=https://api.openai.com/v1
#   MEMIND_EMBEDDING_CACHE_PATH=.release-gate/memfuse-embedding-cache.json

# 本地 Ollama（无 API key）
#   MEMIND_EMBEDDING_PROVIDER=ollama
#   MEMIND_EMBEDDING_MODEL=nomic-embed-text
#   ollama pull nomic-embed-text

# 事件文本前置 "[device · location]" 来源标签
node scripts/run-memory-v2-memfuse-bench.mjs --source-tags

# 落 JSON 报告
node scripts/run-memory-v2-memfuse-bench.mjs --out .release-gate/memfuse.json

--source-tags 实测把候选召回从 36.6% 抬到 38.2%，但最终召回不变（13.5%），说明当前排序器吃不到 provenance 前缀带来的信息。

单测（不依赖外部数据集）：

npm run verify:memory-v2-memfuse-bench

5. 指标定义

  • candidateRecall — 证据事件进入候选池（向量 top-N ∪ 最近 N ∪ keyword 匹配）的比例。这是排序无关的天花板。
  • recall@k — 证据事件出现在最终 top-k 的比例。
  • rankingLoss = candidateRecall - recall@k。大于 0 表示证据已被检索到但被排序丢弃。这是决定"该修检索还是该修排序"的关键拆分，对应 Mi-Memory 讲的 diagnostic trace。
  • hitAny@k — 至少召回一条证据的问题占比。
  • checklistCoverage — answer_checklist 中每个 point 至少召回一条其 source_events 的比例。这是最接近 MemFuse 论文自身评分（answer-checklist coverage）的检索侧代理，无需 LLM 评审。
  • distractorRate — top-k 中 source 为 noise / adversarial 的占比。这些事件按数据集构造永远不属于任何答案的证据集。

6. 这份基线解锁了什么

memory-v2-lifecycle.mjs 的 promote / compact / reflect / decay 目前 flag 全关、reflect() 恒返回 updated: 0。在没有基线之前，往里面填任何算法都无法验证对错。现在有了一个 3.5 秒可重跑、357 题、能把候选损失和排序损失分开的度量，这个前置条件解除。

按 rankingLoss 的量级，优先级排序是：先修排序（rankHybridCandidates 的主键选择、fetchKeywordCandidates 的排序方式），再谈候选生成和 consolidation 算法。这两处都是几十行的局部改动，而且每一步都能用本文的表格直接对比。

7. 相关文件

  • memory-v2-memfuse-bench.mjs — 数据集加载、语料/案例构建、评测与聚合
  • memory-v2-memfuse-bench.test.mjs — 内联 fixture，19 个用例，不依赖外部数据集
  • scripts/run-memory-v2-memfuse-bench.mjs — CLI
  • memory-v2-pgvector.mjs — 被测的生产排序路径（rankHybridCandidates / fetchKeywordCandidates / extractKeywordTerms）
  • docs/architecture/jkriver-sleep-reference.md — JKRiver 只读参考（AGPL 边界）
  • docs/architecture/experience-schema-v1.md — Mi-Memory Structure/Expansion 映射
Reference in New Issue View Git Blame Copy Permalink