推荐算法日报 · 2026-09-11

总览

今天这三篇清一色是工业界的活儿，阿里国际、淘系加计算所、华为各占一篇，读完的整体感觉是没有那种让人拍大腿的新范式，但工程味都很足，真正值得看的是它们怎么把「业务目标」和「系统自己的历史」塞进模型里。主线其实就两条，一条是让模型直接对齐商业结果而不是对齐相关性，SAM-D2Q 把电商搜索的文档扩展做成多模态加 GRPO 偏好对齐，里面有个很关键的观察——布尔检索下对已有词做 TF 重加权毫无意义，扩展器的价值只在于带来新词，所以整篇围着信息增益转，但坑也在这儿，它涨的几乎全是商业价值分而不是相关性分，本质是在对齐「能带货的新词」。另一条是生成式推荐开始给系统自己记一笔账，LoopMemGR 那个「不对称记忆」的提法确实戳中了真问题：行为日志只记用户、不记系统推荐过什么、用户反馈如何，于是下一轮又从零重建偏好、反复推同一批东西，三视角读记忆加 16 个 experience token 的工程处理也挺细，不过它离线涨幅大得有点可疑，经验日志里存的正是上一轮曝光，曝光泄漏和近重复这块没洗干净，我看的时候是打问号的。华为那篇多任务依赖图相对规矩，可学习动态拓扑加渐进 mask 解深漏斗信号衰减，思路干净、线上也有 A/B 支撑，但因果结构仍是人工先验，图结构和 APM 的增益归因没拆清楚，属于可借鉴但惊喜有限的那类。今天的读法很明确：优先啃 SAM-D2Q 和 LoopMemGR，前者看它怎么把商业 reward 和安全门设计成真能上线的样子，后者重点盯记忆读写不对称背后的回音室风险，第三篇扫一眼方法图就够了。

论文列表

1. SAM-D2Q: Aligning Multimodal Doc2Query with Search Demand and Conversion for E-commerce

• 论文链接：AlphaXiv
• 更新时间：2026-09-04 10:09 UTC
• 机构：Alibaba International Digital Commerce Group
• 工业优先级：强
• 备注：Accepted by CIKM2026 Oral Full Paper

电商搜索扩词，GMV涨3.38%🔍

各位算法同学们，电商搜索里扩写得更“语义相关”，不一定更赚钱。这篇把 Doc2Query 从纯文本、只优化相关性，改成多模态并直接对齐GMV和支付，AliExpress 线上 A/B 给出 GMV +3.38%、Pay Count +2.27%。

📄 SAM-D2Q: Aligning Multimodal Doc2Query with Search Demand and Conversion for E-commerce

🔧 先重构任务：布尔倒排下重复标题已有词没边际收益，Stage 1 用信息增益约束，只拿标题未覆盖的 query-item 对做词汇扩展。

🧩 Stage 2 做 CPV 引导的多模态反事实增强：mask 文本里的视觉属性词但保留商品图，逼模型从图片补回颜色、版型等属性，缓解短标题和长尾商品漏召回。

⚙️ Stage 3 用 GRPO 做偏好对齐，奖励同时考虑语义、商业和视觉信号，让生成词更贴近搜索需求和转化价值。

📊 离线实验里，检索效果超过传统 Doc2Query，说明多模态扩展比纯文本扩写更适配电商布尔召回。

📈 线上部署在 AliExpress 生产搜索，走离线索引，不做在线模型推理；A/B 里 GMV +3.38%，Pay Count +2.27%。

✅ 它强调扩展词要同时满足召回增益、视觉 grounding 和商业效用，这是和网页搜索 Doc2Query 最大的区别。

总结感想：做电商搜索、Query 扩写或稀疏召回的同学可以重点看三段式训练和 GRPO 奖励设计。要盯新词召回增量、索引膨胀、GMV 和 Pay Count，并和纯文本 Doc2Query 对比。坑在于反事实 mask 依赖 CPV 属性质量，日志噪声会被 RL 放大，离线索引更新还要算倒排成本。

2. LoopMemGR: From Behavior Logs to Evolving Memory for Generative Recommendation

• 论文链接：AlphaXiv
• 更新时间：2026-09-09 07:42 UTC
• 机构：Alibaba Group，Institute of Computing Technology, Chinese Academy of Sciences
• 工业优先级：强

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

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

📄 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 比；坑在于写入质量依赖反馈回流是否及时，曝光延迟或埋点缺失会让记忆带噪，而且多一条日志链路，工程成本不低。另外正文里没给具体数值，别信二手转述的百分比。

3. Personalized Task Dependency Graphs for Mitigating Signal Erosion in Multi-Task Recommendation

• 论文链接：AlphaXiv
• 更新时间：2026-09-04 08:23 UTC
• 机构：Huawei Technologies Co., Ltd.，Huawei Technologies
• 工业优先级：未标注
• 备注：Accepted at CIKM 2026

多任务推荐信号衰减，华为用图重连

各位算法同学们，多任务推荐里有个反直觉的现象：转化链路拉得越长、层级越深，深漏斗任务的信号反而被前面几层磨得越弱。华为这篇 CIKM’26 的工作就是冲着这个“信号侵蚀”去的，思路是把固定的转化漏斗换成一张每个物品都能自己重连的依赖图。

📄 Personalized Task Dependency Graphs for Mitigating Signal Erosion in Multi-Task Recommendation

🔧 不再假设所有样本共用一套依赖强度。物品侧用低秩分解 Z_L·Z_R 生成邻接矩阵，参数量只有 O(T×q)，再拿 user 和 scenario 特征生成一个 bias 去调制，得到实例级的动态图。

🧩 硬因果掩码加 GCN 传播。Click→Pay 这种物理顺序不能破，但中间冗余节点可以被“短路”，靠自适应捷径绕开逐层传递带来的累积衰减。

⚙️ APM 自适应渐进掩码。按每个任务的标签正例率决定 mask 比例，稀疏任务保留更多独占参数，密集任务多共享，再配 warm-up；用结构方式解梯度冲突，而不是在 loss 上做加权博弈。

📊 KuaiRand1K 上 6 个任务平均 AUC 0.9081，MMoE 是 0.8949；稀疏转化任务最高提升 1.45%。

📈 工业数据集 7 个任务平均 AUC 从 PMTR 的 0.8818 提到 0.8878，最难的那个任务从 0.8745 到 0.8872。

✅ 线上 A/B：CVR +1.2%，eCPM +1.9%，密集任务（比如 Task 4）基本持平没掉点。

总结：如果你的场景里任务正例率横跨好几个数量级、深漏斗任务一直被上游稀释，这套东西可以拿来试，重点盯深漏斗任务的 AUC 和线上 eCPM 是否同向。坑在于因果掩码的拓扑得按自己业务定，任务间本来就弱相关的场景收益会明显缩水；论文只有 5 页，低秩的秩数 q 和 mask 上下限怎么调，得自己补实验。