dsh-mneme 兴趣漂移（Interest Drift）方向调研与思路分享

[heptaspirit]

#17 中有关兴趣漂移算法一些思考个人研究和思考

一、算法方向概览

方向	成熟度	核心思想	与 mneme 的相关点
间隔重复 / 遗忘曲线（FSRS）	★★★ 长期验证	R/S/D 三变量 + 幂律遗忘曲线	衰减函数形态直接可参考；有 Node 生态实现
差分衰减分层（FadeMem 等）	★ 新论文	长期层慢衰减 / 短期层快衰减	对应 mneme 的 type 分层
多信号加权召回（Generative Agents）	★★ 业界基准	Recency × Importance × Relevance	三信号融合公式
时间衰减排名（IR/推荐）	★★★ 成熟	行为按新旧加权	排序层加乘子
概念漂移检测（DDM/ADWIN 等）	★★ 成熟方法	检测关注点切换	兴趣切换检测
Weibull 衰减 + 新鲜度阈值（SSGM）	★ 新论文	更灵活衰减形态 + 低热度归档	归档策略参考

笔者最初因熟悉 FSRS 而优先推荐它，但具体形态请以开发者调研情况和设计方向为准——上表各方向各有适用面，且不强求单一路线。

---

二、各方向要点

1. 间隔重复 / 遗忘曲线模型（FSRS 系列）

FSRS（Free Spaced Repetition Scheduler）是墨墨背单词 DHP 模型的开放实现，多年迭代、多语言实现（含 TypeScript 的 ts-fsrs），有大规模用户数据验证。

核心三变量：

• R（Retrievability）：当前可提取性（回忆概率）
• S（Stability）：稳定性，R = 90% 时的间隔天数
• D（Difficulty）：难度，∈ [1, 10]

遗忘曲线（FSRS-4 起，幂律形态）：

R(t, S) = (1 + factor · t/S)^(−w₂₀)
factor = 0.9^(−1/w₂₀) − 1    # 保证 t = S 时 R = 0.9

稳定性更新（FSRS-6，依赖 4 级评分 G = again/hard/good/easy）：

S′(S, G) = S · e^(w₁₇ · (G − 3 + w₁₈) · S^(−w₁₉))

特性：稳定化衰减（S 越高增幅越低）、间隔效应（R 越低成功复习后 S 增幅越大）、21 参数可训练（fsrs-optimizer）。

与 mneme 场景的差异：FSRS 面向"复习调度"（何时复习），mneme 没有复习概念，只有隐式访问事件（检索命中 / 注入）。若借鉴需把"命中"映射为隐式评分，或仅借用衰减函数形态。

2. 近两年相关研究（参考，均未大规模验证）

研究	时间	核心思想	可参考点
FadeMem	2026-01	差分衰减：长期层慢衰减 / 短期层快衰减，宣称优于 Mem0 且省 45% 存储	分层思想对应 mneme 的 type
SSGM	2026-03	Weibull 衰减 w(Δτ) = exp(−(Δτ/η)^κ) + 统一新鲜度阈值 θfresh 归档低热度；记忆四类失败模式	归档策略参考
TiMem	2026-01	时间记忆树四层组织（raw → session 摘要 → episode 摘要 → persona），按调度向上巩固	分层巩固 / 热度上移
Generative Agents	2023	经典召回公式 Score = w₁·Recency + w₂·Importance + w₃·Relevance	三信号融合
Adaptive Budgeted Forgetting	2026-04	带上下文预算的自适应遗忘，低于阈值剪枝以维持预算	存储预算控制
MaRS / Forgetful but Faithful	2025-12	类型化 + 溯源节点 + 到期策略（expiry policy），面向隐私合规的目标化删除	到期策略
概念漂移建模综述	2025	DDM / EDDM / HDDM / ADWIN / Page-Hinkley；区分长期漂移 vs 短期波动	兴趣切换检测

3. 时间衰减排名（信息检索 / 推荐系统，成熟）

• 指数 / 对数 / 线性 / 分段衰减在搜索排序与推荐中的成熟应用（recency ranking、时间加权协同过滤）。
• 在线学习遗忘因子 / EWMA：S ← λ·S + Δ，增量更新实现简单。

---

三、与 mneme 现有架构结合的可能思路

3.1 type 体系的衰减角色（一种可能的映射）

type	原生语义	可能的衰减角色
preference	用户稳定偏好，每轮注入	近乎免疫衰减（身份级记忆）
decision	记录过的决策	近乎免疫衰减（决策 = 闭合的选择）
project	项目状态、上下文	慢衰减 + 命中强化（活跃项目保持热度）
history	会话事件记录，原生不注入	快衰减（本就该被遗忘）
summary	autoDream 巩固产物	继承参与合并记忆的热度（合并是热度转移）
pattern	sleep 模式发现产物	中速衰减（模式会过时）

实现可为一个常量映射表（如 TYPE_DECAY = { preference: ∞, decision: ∞, project: 90, summary: 30, pattern: 30, history: 7 }，单位为半衰期天数），无需为每种 type 写独立逻辑。

3.2 两个维度正交

• importance（写入时）：该不该记 → 决定保留基线（是否归档）
• heat（检索时）：现在重不重要 → 决定排序偏移

3.3 原生机制的可能用途（基于 v0.6.0 源码观察）

原生机制	可能的用途
recall_runs 表	现成的"访问事件"数据源（检索场景已全量落库，含 query/candidates/score）
last_accessed_at + touch 逻辑	衰减的 Δt 输入；目前主要用于 sleep 降级，未接入检索/注入排序
sleep 维护流程	热度批处理衰减（避免每次检索实时算）
注入路径（INJECT_TYPES）	现有注入优先级可保持不变，heat 仅作用于同 type 内排序
autoDream 合并	合并时热度转移给 summary / pattern
archived 机制	低热度 + 低 importance 记忆归档（复用现有字段）

3.4 现状观察（非指摘，供权衡）

1. 访问信号（last_accessed_at）目前主要服务 sleep 的分层降级，与检索/注入排序未打通——接入排序层即是最小起步。
2. sleep 降级当前为时间硬阈值（30/90 天），未区分 type 与 importance——若引入热度模型，可考虑"热度 + 重要性 + type"联合判定，避免高价值记忆被一刀切。
3. recall_runs 审计表已记录每次检索场景，是免费可得的隐式反馈数据源——"高频召回却从未被使用"可作为负信号候选（需谨慎，见第五节第 1 条）。

---

四、落地方向（宏观，供参考）

1. 先接已有信号：把访问信号接入检索/注入排序（零或低成本增量，默认可关闭，行为不变）。
2. 连续热度替代硬阈值：引入连续 heat 值（命中抬升 + 批处理衰减），排序、降级、归档共用同一信号。
3. type 差异化衰减：一张半衰期常量表驱动三处（衰减、免疫、排序半衰期）。
4. 合并时热度转移：autoDream / pattern 巩固产物继承源记忆热度，避免"巩固即失活"。
5. 远期（独立评估）：recall_runs 隐式反馈统计；兴趣切换（概念漂移）轻量检测。

---

五、值得注意的点（非结论，仅提示）

1. 隐式信号 vs 显式评分：命中 ≠ 用户明确反馈，近似映射可能引入噪音；且"越常被注入越靠前、越靠前越被注入"存在正反馈循环风险——排序权重宜保守起步。
2. 参数语义：FSRS 默认参数面向学习场景，若用于"话题热度"语义需重新标定（或初期用简化参数）。
3. 幂律长尾：幂律衰减较慢，旧记忆可能长期残留——是否配合归档阈值。
4. 与 autoDream 交互：低热度记忆在合并 / 巩固中的处理策略。
5. 不必引入完整 FSRS：mneme 无"复习"事件，21 参数可训练模型可能是过度工程——可只借"稳定化衰减"思想（访问越多的记忆衰减越慢），或纯借幂律曲线形态。

---

六、参考文献（出处完整，供查阅）

FSRS / 间隔重复：

1. FSRS 官方仓库：https://github.com/open-spaced-repetition/free-spaced-repetition-scheduler
2. FSRS 算法完整推导（The Algorithm, awesome-fsrs wiki）：https://github.com/open-spaced-repetition/awesome-fsrs/wiki/The-Algorithm
3. ts-fsrs（TypeScript 实现）：https://github.com/open-spaced-repetition/ts-fsrs
4. fsrs-optimizer（参数拟合）：https://github.com/open-spaced-repetition/fsrs-optimizer
5. 墨墨 DHP 模型论文（ACM SIGKDD 2022）：https://www.maimemo.com/paper/
6. 墨墨记忆算法介绍：https://memodocs.maimemo.com/docs/algorithm-intro/
7. 墨墨整理的经典文献（Ebbinghaus 等）：https://memodocs.maimemo.com/docs/classics
8. Wozniak DSR 三组件模型（SuperMemo Guru）：https://supermemo.guru/wiki/Three_component_model_of_memory

近两年研究：

9. FadeMem：arXiv:2601.18642（2026-01）→ https://arxiv.org/abs/2601.18642
10. SSGM（Stability and Safety Governed Memory）：arXiv:2603.11768（2026-03）→ https://arxiv.org/abs/2603.11768
11. TiMem（Temporal Memory Tree）：arXiv:2601.02845（2026-01）→ https://arxiv.org/abs/2601.02845
12. Adaptive Budgeted Forgetting（Fofadiya & Tiwari）：arXiv:2604.02280（2026-04）→ https://arxiv.org/abs/2604.02280
13. MaRS / Forgetful but Faithful（Alqithami）：arXiv:2512.12856（2025-12）→ https://arxiv.org/abs/2512.12856
14. Generative Agents（Park et al., 2023）：arXiv:2304.03442 → https://arxiv.org/abs/2304.03442

综述 / 综述类：

15. Agent Memory Consolidation 综述（Zylos, 2026-06）：https://zylos.ai/research/2026-06-08-agent-memory-consolidation-selective-retention-forgetting
16. 概念漂移与推荐系统（ACM, 2025）：https://dlnext.acm.org/doi/10.1145/3707693
17. LLM 推荐系统综述（arXiv:2507.21117）：https://arxiv.org/abs/2507.21117
18. 信任衰减与概念漂移适应（IEEE, 2025）：https://ieeexplore.ieee.org/document/11050419
19. 时间记忆与衰减（Dakera 工程博客）：https://dakera.ai/blog/temporal-memory-ai-agents

注：9–13 的 arXiv 编号来自检索结果引用，链接按 arXiv 标准格式给出，若编号有出入以 arXiv 检索为准。

[modusensus]

感谢在 #17 之后做了这么系统的跟进调研，质量很高，帮我省了大量时间。

基于这篇内容，v0.7.0 的设计方向可以直接定下来：

1. TYPE_DECAY 常量映射表 → 采纳，作为 heat 模型的第一层约束
2. recall_runs 隐式反馈接入排序 → 采纳，零成本增量，默认关闭
3. 连续 heat 替代 30/90 天硬阈值 → 采纳，v0.7.0 核心改动
4. 不引入完整 FSRS，只借「稳定化衰减」思想 → 采纳，避免过度工程
5. 「正反馈循环风险」→ 写入设计约束，排序权重保守起步

关于 FSRS 的 21 参数：确实过度工程。mneme 没有「复习」事件，只有隐式访问。v0.7.0 会用简化版幂律衰减 + type 差异化半衰期，参数固定不可训练，先跑起来再看数据。

时间线：目前 v0.6.x 在做笔记化记忆库（Wiki-Link + Tag + 目录视图），预计 8 月底收线。v0.7.0 的 RFC 会在那之后启动，届时会把 #21 这篇作为技术背景文档直接引用。

如果你愿意，这篇内容可以归档进 docs/ 目录（署名 + 链接回 #21），作为 v0.7.0 的参考输入。或者等 RFC 草稿出来后 @ 你 review。两种方式都可以，看你方便。

再次感谢，这篇对项目帮助很大。

[heptaspirit]

@modusensus
谢谢认可，很高兴这些整理信息能帮上忙。

归档进 docs/ 这个方式我觉得很好，就把这篇调研笔记作为 v0.7.0 的参考输入放着吧，署名和链接回 #21 都没问题。

RFC 草稿出来之后也欢迎 @ 我 review，我想看到它在实现层面怎么落地，有需要补充真实使用场景的地方我也可以提供。

此外我这次收集信息时，额外调研了一下现有的 Agent Memory 系统，整理了一些资料（包括图谱增强、数据积累前提这些后续调研的内容）此处一起附上，希望能对项目后续的开发给到一些帮助。
notes-memory-enhancement-research.md

[Anans-Ivresse]

@heptaspirit 归档完成 ✅

已将你的调研笔记归档到 docs/AGENT_MEMORY_RESEARCH.md（带署名 + 回链本讨论帖），作为 v0.7.0 规划参考输入。另外也向你发出了仓库 collaborator 邀请，欢迎之后直接参与 PR 共建。

v0.7.0 RFC 草稿出来后我会第一时间 @ 你 review，期待继续合作！🚀

[heptaspirit]

@modusensus 我注意到 v0.7.0 的 heat 模型已经用上了，幂律衰减 + TYPE_DECAY、updated_at 语义修正、sleep 双保护降级都符合预期，尤其是 recall_runs 把"被召回"和"被注入"两档分开记账，这个数据前提铺得很有远见。

顺着这个数据前提，我注意到一个目前缺失的环节，所以想提一个增强方向：给 heat 补一个"间隔效应"（spacing effect）。核心动机来自一个实际使用中的边际场景（FSRS 中也应用了这套逻辑），可能不成熟，发出来讨论。

一、两个观察

观察 1：当前 touch 是无差别的"时钟归零"。

看了 service.js 的 touchRecalled：任何被检索召回或被注入的记忆，last_accessed_at 一律刷到 now，heat 线性回 1.0。机制上不区分：

• 一条偶然被命中的冷记忆（可能只是关键词沾边），和
• 一条用户主动修改过、明确认可的记忆，

得到的刷新是完全一样的。而我们参考的 FSRS 这类间隔复习算法的核心恰恰相反：成功召回事件的"含金量"取决于它有多接近遗忘——间隔越久、越冷的记忆被真正消费，其稳定性增益应该越大（间隔效应）；反过来，偶然命中不该有增益。

观察 2：recall_runs 记了账，但还没有消费端。

全库搜下来，recall_runs 目前只有写入（store.js INSERT）和 90 天滚动清理，没有任何代码读它来影响 heat。injected:false/true 两档标记也是纯审计。这正好留了一个自然的扩展点——数据基础已经就位，缺的只是消费逻辑。

二、边际场景（想到的触发点）

1. 偶然命中一次冷记忆：比如我搜了个关键词，它沾边被捞出来了，我扫了一眼没用它。这次命中不该让它的热度有任何实质提升——它可能只是恰好碰巧。
2. 连续命中几次同一冷记忆：如果它在不同的时间点（跨会话）被反复命中，哪怕每次都不是强消费，我倾向于认为"这条记忆对当前工作有持续价值"——值得把热度抬起来，让它在注入排序里更靠前。

一句话：单次偶然命中无关紧要，连续命中才有价值信号。

三、提案：heat = 原衰减曲线 + 独立尖峰（boost）

不改变现有 H = 1/(1+λ·ΔtHours)^α 的衰减语义，叠加一个独立衰减的 boost 分量：

H_final = min(1, decay(H) + spike)
spike   = w(信号档位) × min(streak, N) × g(冷却时长) × e^(−β·t_since_boost)

四个分量分别回答"这次命中值多少"：

① 信号分档 w(信号)——把"被检索"和"被消费"分开：

信号	来源	权重	含义
弱	memory_search 命中	0.1	只是被检索到，可能是偶然
中	注入上下文（injected）	0.2	系统判断相关才注入
强	memory_update（用户主动修改）	0.6	最接近"消费并认可"的现有信号
负	memory_archive / forget / delete	清 boost、streak 归零	用户否定

现状下 touchRecalled 对所有命中无差别 touch（searchByEntity/searchByAttr 甚至不看分数），这本身就是第一个该改的点：低分候选不应触发 touch，或至少权重趋近于零。

② streak 连续命中累积——回应边际场景 2。命中时若距上次命中 > cooldown（跨会话才算独立），streak += 1；同会话内重复命中只算 1 次；min(streak, N) 封顶。第一次弱信号命中时 w×streak 极小（0.1×1），几乎无增益——偶然命中不刷热度；第 2、3 次累积放大，连续命中才显著抬升。

③ 冷却时长 g(Δt)——间隔效应的直接落地。g = min(Δt_days / D, 1)，距上次访问越久，这次命中的含金量越高。冷记忆 + 强信号命中时 g 拉满，尖峰可短暂超过 1.0，随后按半衰期回落——但衰减起点比原来高（对应 FSRS 的 stability 提升）。

④ 半衰期 e^(−βt)——boost 独立于主衰减曲线，半衰期较短（默认 24h），保证尖峰是"短时"的，不会长期扭曲热度排序。

四、参数与区间锁

mneme 是 agent 场景，命中密度远高于间隔复习，默认值按"频繁使用"定：

参数	默认	区间	理由
heatHitCooldownHours	4h	[2h, 72h]	下限 2h 防同会话刷 streak；上限 72h 给低频用户留余地
heatBoostHalfLifeHours	24h	[6h, 168h]	短于 6h 尖峰形同虚设；长于 7 天就不是"短时尖峰"了
heatMaxStreak	3	[1, 5]	3 次足够确认价值，防高频用户顶到失真
heatColdBoostDays	30	[7, 90]	30 天大致对应"明显变凉"的感知线
heatSignalWeights	0.1/0.2/0.6	[0,1]，强制 update ≥ search	防止权重配反导致信号逻辑混乱

区间锁沿用 heat.js resolveConfig 的校验风格，但用 clamp（越界压到边界）而非非法回退默认，行为更可预测：

const RANGES = Object.freeze({
  heatHitCooldownHours:   { min: 2,   max: 72,  dflt: 4 },
  heatBoostHalfLifeHours: { min: 6,   max: 168, dflt: 24 },
  heatMaxStreak:          { min: 1,   max: 5,   dflt: 3 },
  heatColdBoostDays:      { min: 7,   max: 90,  dflt: 30 },
});

五、落地路径（按侵入度排序）

1. 纯逻辑改动（无 schema 变更）：touchRecalled 按来源分档 + streak 计数放 metadata JSON + 低分候选不 touch。不依赖新数据，recall_runs 现有记账就能跑。
2. 加 boost 字段：memories 表加 heat_boost + boosted_at（或进 metadata），computeHeat 尾部叠加 spike——这一步才支持冲过 1.0 的尖峰。
3. 可选：面板加"认可"（或者类似的意思，用户表达需要强化这条记忆）按钮（复用 v0.6.7 删除按钮的思路），提供显式强信号来源。

测试点大概是：heat 纯函数（boost 叠加、clamp 区间）、touch 分档（三种信号权重）、streak 跨会话判定（cooldown 边界）、负面信号清 boost、sleep 降级与新 heat 联动（sleepHeatThreshold 语义不变）。

---

以上是一个方向性提案，不是需求清单。尤其"用 update 当强信号"这个选择——它只是现有接口里最接近"消费"的代理，真正的认可信号（如果有更合适的交互）欢迎指正。

[modusensus]

@heptaspirit 这条提案含金量很高，我对着 v0.7.0 源码逐条核过，你观察的两点都属实：

1. touch 无差别：touchRecalled 对所有命中一视同仁刷 last_accessed_at，searchByEntity/searchByAttr 直接 touch、不看候选分数——"偶然命中"和"主动修改"拿到完全相同的时钟归零。

2. recall_runs 只有记账没有消费端：目前只有写入 + 90 天滚动清理，没有任何路径读它影响 heat。

数据基础（recall_runs 的 candidates 已含 score/source）就位了，缺的正是你提议的消费逻辑。方向值得做，几个具体点：

① 信号分档我认同，但"update 当强信号"有个坑：得区分用户主动 update 和 autoDream/sleep 的系统性 consolidate update（merge/conflict 裁决落地也是一次 update，不该算"用户消费"，否则巩固流程会给自己打强信号）。好在 memories.source 字段现成（dream 侧写 source:"dream"），按 source 分 user/system 判定是通的。

② "低分候选不 touch"是关键前置，但现状 searchByEntity/searchByAttr 不产出分数（直接 slice topK 返回），要先把这两个路径打通置信度输出，才谈得上"低于阈值不 touch"。这个改造量不小，值得单独排。

③ streak 跨会话判定依赖会话边界——目前 touch 层拿不到 session 上下文，敲定前保持"cooldown 内只算 1 次"的保守策略即可。

④ 区间锁用 clamp 而非非法回退默认——同意，更可预测，heat.js resolveConfig 按这个风格改。

关于落地：建议先做阶段一（纯逻辑、零 schema）：touch 分档 + 低分不 touch + streak 进 metadata，recall_runs 现有数据就能跑。boost 尖峰字段（阶段二）和面板"认可"按钮（阶段三）等阶段一跑出真实数据再标定。

排期我确认后回复你——目前 v0.7.x 收尾、v0.8 图谱增强排 9 月末，具体插进哪个版本我确认后 @ 你。