小红书精读：LoopMemGR: From Behavior Logs to Evolving Memory for Generative Recommendation

推荐系统的记忆盲区，这篇补上了🧠

各位算法同学们：推荐系统记得用户点过什么，却不太记得自己推过什么——这篇要补的就是这个洞。

📄 LoopMemGR: From Behavior Logs to Evolving Memory for Generative Recommendation（阿里 + 中科院计算所）

🔧 它点出一个被默认忽略的不对称：行为日志只记用户真实动作，而每轮请求里系统自己下了什么决策、用户给没给反馈，做完就丢，下一轮再从头从行为序列重建偏好。于是“推过但没反应”“已经探索过的兴趣区”这些信号没法跨请求复用。

🧩 做法是在行为日志之外再维护一条 recommendation experience log，记录推荐—反馈轨迹；请求结束后新推荐结果被总结写入，用户反馈进行为日志，且只在第 t+1 轮起可见，保持因果顺序，不会泄漏回产生它的那次请求。

⚙️ 难点在预算：经验日志随请求无限增长，而一个 item 本身就要拆成多个 Semantic ID，直接拼进上下文会爆。Tri-View Memory Reader 把它压成固定 M 个 experience token（M ≪ N）：recency 抓短期动态，frequency 汇总反复出现的推荐模式，global 用跨用户共享的可学习 query，在个人经验稀疏时抽可迁移规律。读取算子是余弦 cross-attention 加门控、带幅值上限的残差更新，防止长而杂的日志把 base query 冲掉。

📊 实验覆盖工业淘宝数据集和公开 Amazon 数据集。

📈 三组消融分别验证闭环积累、多视角抽取、固定预算压缩，对应摘要里那句结论。

✅ 上下文侧固定 M 个 token，输入长度不随请求数增长，这是相比朴素拼接最实际的收益。

总结感想：思路比结构更值得借鉴——把系统侧决策当成一等状态来存，并用固定 token 预算兜住长度。要盯的是长会话与探索场景下的重复曝光率，以及上下文长度–效果曲线，和纯 history-as-context 的 baseline 比；坑在于写入质量依赖反馈回流是否及时，曝光延迟或埋点缺失会让记忆带噪，而且多一条日志链路，工程成本不低。另外正文里没给具体数值，别信二手转述的百分比。

原文：AlphaXiv