MemoCRS 到 FuseRec：对话推荐里的长期历史，开始分给 memory 和 RL planner 两条路

背景

补完 PURE / TETUP / LLM-TUP 之后，我原本已经把“长期用户状态”先理解成一条比较自然的路线：

1. 历史行为或评论先被压成 profile
2. profile 再被维护、分时域或部署到线上
3. 下游推荐系统消费这个压缩过的状态对象

但这一轮往 memory-based user modeling / conversational recommendation 继续补检后，我发现对话推荐里已经长出了另一种更系统化的分叉。

这次真正值得补进 Story Lab 的，不是又多了两篇论文名字，而是 长期历史到底由谁持有、谁来消费 这个系统边界，开始显式分裂了。

我这轮重点核了两个入口：

1. MemoCRS: Memory-enhanced Sequential Conversational Recommender Systems with Large Language Models
2. Fusing Sequential Recommender and Ad-hoc Planner for Multi-Faceted Preference Understanding in Conversational Recommendation

它们给出的答案并不一样。

核心判断

对话推荐里的长期历史，已经至少分成两种 carrier

MemoCRS 的做法是：

把长期历史放进 LLM-side memory

论文摘要与 CIKM 2024 的 DBLP 条目都能回溯到同一个核心结构：

1. user-specific memory
2. general memory

其中 user-specific memory 更像个体级长期偏好存储，论文摘要明确写它由 entity-based memory bank 实现，用来细化偏好、检索相关历史，并减少历史会话里的冗余和噪声。

general memory 则不是另一份个人画像，而更像共享的 collaborative knowledge 和 reasoning guidelines，重点是给冷启动用户补 shared knowledge。

也就是说，MemoCRS 不是简单回答“历史要不要保留”。

它回答的是：

长期历史可以由 LLM 侧的记忆系统直接持有，而且 memory 至少还分个体记忆和共享记忆两层。

而 FuseRec 则反过来。

它没有把长期历史继续往 LLM memory 里塞，而是明确写成：

1. SRS 负责处理 long-term historical interactions
2. ad-hoc Planner 负责学习 conversation strategies
3. 额外的 CRS module 再把 sequential pattern 和当前对话上下文融合起来

这意味着另一条公开路线已经很清楚了：

长期历史留在 SRS backbone，策略学习交给 RL planner

所以如果 Story Lab 还只记录 profile / memory / planner 这些名字，而不单独记“长期历史到底归谁”，就会把这两条方法错写成同一种“长期偏好建模”。

MemoCRS 说明 memory 不等于 profile，它还可能是共享知识层

MemoCRS 最值得单独记住的一点，不是“它有 memory”。

更关键的是，它把 memory 明确拆成了两种 ownership：

1. 面向单个用户的 user-specific memory
2. 不属于某个用户、但可以跨用户复用的 general memory

这个区别很重要。

因为此前 Story Lab 里已经补过的很多 profile constructor 路线，更像是在回答：

1. 怎样把单个用户压成一个更好的 state carrier
2. 这个 carrier 最终是 text、embedding 还是 collaborative ID

但 MemoCRS 的 general memory 显然不是这个逻辑。

它更接近：

shared collaborative prior / shared reasoning prior

这说明对话推荐里的“长期状态”并不总是单一的 user profile。

它也可能天然分成两层：

1. per-user memory
2. shared memory

这比“画像更长了”更重要，因为它直接改变了系统角色边界。

FuseRec 让 LLM-RL 协同推荐 变得更模块化了

如果说 MemoCRS 更像把长期历史交给记忆系统，那么 FuseRec 补出的其实是另一种更贴近 LLM-RL 协同推荐 的公开结构。

FuseRec 的官方摘要把分工写得很直白：

1. 任意 SRS 都可以通过接入 ad-hoc Planner 变成 conversational recommender
2. Planner 处理对话策略
3. CRS module 处理 sequential history 和实时对话信息的融合
4. 训练侧再配一套 stratified GenAI-based user simulator

而且这个 planner 不是只会一种动作。

官方摘要明确列了四种 action：

1. Chitchat
2. Semantic Q
3. Attribute Q
4. Recommend

再往前一步，训练方式也不是普通监督学习，而是：

curriculum RL based on user difficulty levels

这件事对 Story Lab 很重要，因为它说明对话推荐里的 RL 不一定非要优化 end-to-end recommender 本体。

它也可以被放在一个更明确的策略层：

1. 长期偏好理解交给 SRS
2. 实时问题选择交给 planner
3. 用户反馈动态由 simulator 提供训练环境

换句话说，FuseRec 给出的不是“又一个 CRS 模型”，而是：

SRS backbone + planner RL + user simulator

这正好把 LLM-RL 协同推荐 从端到端生成主线外，又补出一条更模块化的公开路径。

这两条线合起来，逼着我们再加一列 history carrier / history owner

目前 Story Lab 已经在补：

1. profile constructor
2. agent scaffold
3. simulator
4. evaluator

但 MemoCRS 和 FuseRec 放在一起后，一个此前还没显式记录的维度已经很难绕开：

history carrier / history owner

至少在对话推荐和 interactive recommendation 里，当前公开路线已经能看到三种不同承载方式：

1. LLM-side memory bank
2. SRS backbone
3. experience bank / retriever

这三种 carrier 并不只是实现细节差异。

它们分别对应不同的系统假设：

1. 长期历史应该被 LLM 直接读取和重写
2. 长期历史应该留在传统 sequential recommender 里，由 planner 只做动作层策略
3. 长期历史应该被抽成可检索经验，而不是固定 profile 或固定 state vector

如果不把这列加进去，后面再把 MemoCRS / CRAVE / FuseRec / SAPIENT / ECPO 压到同一张表时，方法图会再次变粗。

MemoCRS 和 FuseRec 也说明“历史建模”与“策略优化”正在被拆开

另一层更细的变化是：

公开世界里，long-term history modeling 和 dialog policy optimization 已经不再总是绑在一起。

MemoCRS 更偏前者。

它重点处理的是：

1. 历史会话冗余与噪声
2. 个体记忆与共享记忆
3. 冷启动用户补知识

而 FuseRec 则明显更偏后者。

它的主问题是：

1. 怎样让 planner 依据用户反应切换问题类型
2. 怎样在不同偏好清晰度用户上学到稳定策略
3. 怎样用更真实的 simulator 环境训练 CRS policy

这意味着对话推荐里的长期历史问题，不该再只写成一句模糊的话：

模型利用历史对话理解用户偏好

更准确的写法至少要拆成两问：

1. 历史由谁保存
2. 策略由谁优化

当前公开边界仍偏弱，不能写成“已开源工作流”

这轮我也专门核了两条线的公开边界。

更稳的事实是：

1. MemoCRS 可通过 arXiv、DBLP 与 CIKM 2024 DOI 回溯到正式论文
2. FuseRec 可通过 Seoul National University 的官方 publication 页回溯到 Information Fusion 127 (2026) 与 DOI 10.1016/j.inffus.2025.103735
3. 但按论文全标题和关键词检索 GitHub API，截至 2026-03-21，都还没有看到稳定官方仓

因此这两条线当前更适合分别记成：

1. conference paper
2. journal paper

而不是“已有公开代码底盘”。

这里还要特别注意 MemoCRS 的中文传播层。

智源社区那篇导航页在“其它亮点”里写到“论文开源了代码”，但本轮我没有通过官方仓链接或 GitHub API 找到能独立复核的稳定仓库。

所以这个说法目前最多只能当作传播层表述，不能当开源边界证据。

中文传播层刚起步，xhslink 仍然缺位

这轮中文检索里，MemoCRS 至少还能回溯到智源社区这类较稳定的导航页。

但 FuseRec 的中文传播层明显更弱。

继续补做：

1. FuseRec 推荐 中文
2. site:xiaohongshu.com FuseRec 推荐
3. xhslink FuseRec 推荐
4. 对应的 MemoCRS 检索

截至 2026-03-21，稳定结果仍然主要是英文论文页、学校 publication 页和噪声页，没有拿到可复用的高价值 xhslink。

所以这一轮仍然应以论文、DBLP、官方 publication 页和 GitHub API 为主。

证据与来源

• MemoCRS: Memory-enhanced Sequential Conversational Recommender Systems with Large Language Models：摘要明确写出 user-specific memory + general memory、entity-based memory bank、redundancy/noise 与 cold-start 这组核心设计。
• DBLP API 检索：可回溯到 MemoCRS 已以 CIKM 2024 论文出现，页码 2585-2595，DOI 10.1145/3627673.3679599。
• MemoCRS - 智源社区论文：较稳定的中文导航层入口，能帮助记录这条线已进入中文可见层；但页面里的“开源代码”表述当前不能替代官方仓核验。
• Fusing Sequential Recommender and Ad-hoc Planner for Multi-Faceted Preference Understanding in Conversational Recommendation：Seoul National University 官方 publication 页直接给出 Information Fusion 127 (2026)、DOI 10.1016/j.inffus.2025.103735 与完整摘要，明确写出 SRS + ad-hoc planner + CRS module + stratified user simulator + curriculum RL。
• DBLP API 检索：可回溯到 FuseRec 已以 Information Fusion 期刊论文出现，卷 127、文章号 103735。
• GitHub API 检索：按 MemoCRS、FuseRec 及其全标题和关键词检索，截至 2026-03-21 仍未看到稳定官方仓。

下一步

• 把 MemoCRS / CRAVE / FuseRec / SAPIENT / ECPO 压到同一张 CRS scaffold 观察表里，新增 history carrier / history owner 一列。
• 在这张表里继续区分 per-user memory / shared memory / experience bank / SRS backbone 四种历史承载方式。
• 继续补 xhslink 和稳定中文机制稿；若后续出现 MemoCRS 或 FuseRec 的官方仓，再单独修正它们的公开边界。