Not All Is Lost: Repairing Lossy User Preference States of Personalization Encoders

全文依据：https://arxiv.org/html/2610.01270v1 。下文数值来自正文及附录；社区搜索应用建议属于结合默认业务场景的分析。

1. 问题与动机

推荐系统通常先将用户的逐步交互编码，再把历史压缩成一个面向任务的状态，排序头只能访问该状态。论文提出的具体问题是：某些有用证据可能仍保留在同一次前向计算产生的逐时间步表征中，却未在最终状态中充分表达。这种可恢复差距不等于信息完全消失，也不意味着编码器必须重训；需要实验区分状态修正的收益与任务头继续训练的收益。

作者因此建立冻结编码器与原任务头的控制实验。在 MovieLens 的 Mamba4Rec 上，原模型 MRR 为 29.29，头部微调后为 29.48，只训练修正器达到 33.25。这说明同一头部可以利用修正后的状态获得更多有效信号。相关工作中的时间兴趣模型主要改善历史编码过程，模型编辑与输出纠错则改变另一处接口。本文研究的是已经形成的偏好状态，插入位置在压缩之后、任务头之前。对已有稳定主干、重训成本较高的社区用户建模系统，这一问题具有直接意义。

2. 方法详解

一次冻结前向产生最终状态 z 和历史缓存 e_j。首先用两个可学习投影分别处理缓存与最终状态，把不同维度和语义的表征映射到共同空间，再得到每个历史位置相对当前状态的差值。不能直接相减原始坐标，因为宿主接口未必同构。修正算子分成读取方向、非负尺度和写入方向三个学习因子，形式为 UΛVᵀ；读取部分把共同空间差值压缩成 K 个修正模式。它只是类似奇异值分解的参数化，作者没有对原表征运行数值 SVD，列归一化也不保证各模式正交。

随后减去每个模式在整个历史前缀中的均值，去掉恒定激活。这个步骤也会消去共享状态偏移，因此后续状态门控与融合仍然重要。时间模块针对同一修正模式构造三种支持核：长期核按滞后指数衰减，近期核按相对滞后线性下降，事件核用带可学习强度的泊松形式强调局部峰值。三个核经过可学习混合后形成各时间步的候选修正；它们不是给用户行为贴上三种可解释兴趣标签，而是描述修正信号的时间支撑范围。

选择器按每个模式的激活绝对值排序，学习保留比例，并在前向使用硬掩码、反向使用直通近似。筛选粒度是“时间步×模式”，同一个交互中的一种模式可能保留，另一种被抑制。状态条件门控再调整当前状态需要的模式，写入矩阵把它们变为候选修正，带归一化权重的池化汇总历史位置。最后将原状态与修正拼接送入探测 MLP，通过 sigmoid 融合门控制残差增量；原状态始终保留为基底，修正结果交给原任务头。

训练目标含任务、位置来源和证据一致性三个损失族，外层系数固定为 0.5、0.2、0.3。推荐使用交叉熵，位置监督保留修正证据的时间来源，一致性分类与对比项保持证据与源交互的对应。默认状态及缓存接口各 768 维，共同空间 192 维，修正秩 128，最大历史长度 50，位置分桶数 8。Stage 2 使用 AdamW，学习率 2e-4、权重衰减 1e-4、梯度裁剪 1.0；MovieLens 和 Amazon 训练 10 个 epoch，新闻推荐和编码器生成设置训练 2 个。后续头部对齐再运行 2 个 epoch，修正器学习率降为 5e-5，任务接口为 2e-4。论文列出 A100、H100 和 RTX PRO 5000 类资源，但不能把跨设备绝对延迟用于比较，也不应补写未核实的统一 batch size。

3. 核心技术贡献

第一项贡献是把修正证据与已有状态建立相对关系，而不是再编码整段原始历史。缓存来自现有编码器计算，实验冻结两端，能够更清楚地定位接口压缩后的利用缺口。在四个数据集上，冻结头部修正的平均 MRR 增量分别为 2.66、2.29、1.96、2.19 点；头部微调只有 0.29、0.76、0.72、0.68 点。

第二项贡献是把低维修正模式与时间支撑联合建模。秩扫描中 K=128 在五种设置上均优于 32、64、192；128 维模式的平均学习坐标能量比为 96.46%，但这不是直接测得的领先特征空间能量，也不能据此宣称所有用户偏好天然低秩。不同宿主会压缩不同时间证据，修正时间核因此必须依赖宿主，而非照搬输入历史的兴趣分类。

第三项贡献是选择性写回与来源监督。较长前缀中筛选更稳定地带来收益，长度 50 时四个测试宿主均同时改善 MRR 与 nDCG@10。任务监督告诉模块是否有用，位置与一致性监督约束证据来自哪里和哪个交互，避免修正只是一个不受控制的自由增量。作者另比较前头部和后头部纠错，但明确指出实现损失与接口有所不同，因此不是只改变位置的完美隔离实验。

4. 实验结果分析

推荐任务固定为一个正例对 499 个采样负例，用户训练与测试划分不重叠；同一宿主的配对条件共享用户、历史前缀和候选集。下表均是论文展示的 0—100 尺度，单元格为 MRR / nDCG@10，不能解读成全量目录召回表现。

十二个代表性宿主的冻结头部修正全部改善两项指标，但联合对齐不是统一有益：SASRec 从冻结修正的 29.57 / 40.08 降至 28.49 / 35.18，虽然仍高于原宿主。这是应保留 Stage 2 最优 checkpoint 并独立比较后续阶段的具体理由。Amazon 的低基线与很大的对齐增量，也提醒读者区分冻结修正与重新适配任务头各自承担的贡献。

消融中，Mamba4Rec 去掉时间分辨后 MRR 为 28.43，低于未修正的 29.29；完整时间处理达到 34.26。长期、近期、事件三视图联合在十二个受控设置中胜过最佳单视图的比例为 11/12。人为把证据放在不同时间位置时，最优修正时间视图仅在 6/12 设置符合简单复制输入时间模式的预测，说明宿主压缩方式会改变可恢复证据。选择器的作用随历史长度增强，但不能推出任意更长历史都会继续改善。

统计证据覆盖范围也需区分：OpenCLIP、SigLIP2 和 PENS EBNR 有三随机种子结果，其余扩展宿主主要是点估计。置信区间采用一万次用户级 bootstrap，避免把同一用户多个前缀当成独立样本。MovieLens 约 1.5 万测试实例，新闻数据各约 2 万，Amazon 约 2 千。尚没有社区搜索线上 CTR 或留存实验。

进一步看实验控制，用户不重叠并不等于真正的无历史冷启动。测试用户在预测时仍有观察到的历史前缀，因此这里验证的是新用户身份下的历史利用，不能据此声称解决完全没有行为的新注册用户问题。同样，编码器冻结说明主干参数没有更新，却不代表系统从头到尾没有学习；修正投影、监督头和融合模块都需要训练数据与验证集，业务上线时要把这些新增参数当作完整的模型版本管理。

作者区分了表示可获得性与下游使用能力。一个缓存信号可以在数学或诊断意义上存在，但若任务头对该方向不敏感，直接把信号加回去也不一定提升排序。因此门控、写入方向和头部对齐不是等价组件：读取用于识别证据，时间核决定证据在当前端点是否有效，写入则必须把信息投向任务头能使用的空间。工业消融应依次核对这三个环节，而不是只看一个总分提升后就认定所有缓存都应保留。

对社区短文本而言，还应分别观察搜索触发后的短期意图与较长期浏览偏好是否冲突。论文中时间支持并非显式意图标签，若要作用户解释，应另外建立可审计的交互归因，不能把一个事件核激活直接描述为真实用户兴趣的发生时间。上线监控也应覆盖重度用户、轻度用户与负反馈较多的用户，确认修正不是单纯放大高频点击。

成本评估需要保留不同量纲：算术工作反映执行多少浮点操作，测得延迟反映具体实现与设备，缓存驻留反映在线路径需要保存哪些产物。三者不能互相替代。缓存若原先在主干前向结束后立即释放，新增修正会延长其生命周期，服务批量和并发会改变峰值显存。这是本业务实施时应单独测量的变量，论文给出的参数内存比例不足以回答该问题。

5. 局限与未来方向

作者明确指出，宿主处理历史之前已经丢弃的证据不在修复路径内。缓存窗口以外的信息不能凭修正器恢复，修正也不能绕过主干本身的表征缺陷。编码器宿主的参数估算内存增加 31%—36%，测得延迟增加 38%—44%；参数内存不含缓存和中间激活，不能代替设备峰值内存。

TG-ReDial 的行为标签需要从推荐、接受拒绝与话题转移推断，TextCNN 出现混合结果，限制了跨接口普遍有效的主张。提示条件 LLM 的证据接口也与编码器不同，需要分别编码交互并插入连续前缀，不能把“不重编码历史”的宿主优势直接推广到所有 LLM 设置。作者将紧缓存预算与下游如何更好利用修正状态作为未来方向。结合实验协议看，采样候选评测与只有部分设置多种子，是工业落地前还需补充的验证范围。

6. 工业实践意义

社区 UGC 搜索可以在已有用户序列编码器之后加入小规模离线试验，固定主干与 CTR 或排序头，分别比较原系统、继续训练头部和缓存修正。这种设计能够判断问题究竟在已有状态还是任务头适配，先避免把主干重训当成默认答案。数据需保留点击、跳过、负反馈的实际来源，并防止目标内容进入历史缓存造成泄漏。

首轮建议从明确可访问中间序列状态的宿主开始，采用同一用户切分和同一候选集，记录 nDCG、CTR 校准以及长短历史分层效果。只有离线增量稳定后，才讨论头部联合对齐与线上小流量实验。修正器不是免费插入：Mamba4Rec 的原计算约 0.75 GFLOPs/query，修正另加 0.18；论文中 40% 的延迟增加超过约 16.96% 的对齐 MRR 相对增益，因此需要实际测 P99、吞吐和峰值显存。

可借鉴的最小设计包括现有缓存、相对状态投影、时间核和选择性残差；但是否裁减组件应由本业务消融决定。对于延迟紧张的社区搜索，可优先探索离线更新用户状态或只对高价值请求启用修正，这属于应用推断，论文未证明其线上效果。最终决策应围绕 nDCG 与 CTR 的增益是否足以支付缓存、训练与服务成本。