推荐算法日报 · 2026-11-09
总览
今天这批清单不长，主线却很集中：生成式召回到底怎么在线上用得起大模型。这篇把「候选规划」和「个性化补全」强行拆成离线 7B 加在线 0.5B 两段，是今天唯一一篇真在工程约束下做减法的活，不是单纯刷离线指标。它最让我服气的地方是数字站得住：query 级 HR@100 跟全在线 7B 基本打平，还快 2.36 倍；14 天线上 A/B 也是正向的，虽然 CTR +0.93% 这种幅度只能说方向对、谈不上惊艳。更难得的是它没藏短板：缓存命中率低到 20.97% 时收益基本被吃掉，深度预测精确命中只有 68.91%，再加上七B规划器、蒸馏、强化学习精调和单独兜底这一长串链路，维护成本肉眼可见，这些都在表里写着，读的时候心里要有数。我个人最想把 ReuseCut 和 BudgetCut 那两段拿出来细看：前者用 Wilson 下界造标签，后者在固定 32 个 branch 预算下把「挑分支」当成集合选择而不是按分数 top-k，这个视角比模型本身更有迁移价值。今天优先看这篇，重点抠它的标签构造和 set-dependent 建模。
论文列表
1. ReuseGR: Offline–Online Decoupled Generative Retrieval via Adaptive Prefix Reuse
- 论文链接：AlphaXiv
- 更新时间：2026-11-03 03:51 UTC
- 机构：Xidian University，Alibaba International Digital Commerce Group
- 工业优先级：未标注
7B规划0.5B执行，延迟降38.9%
各位算法同学们，先抛个数字：同一个query的候选SID，被不同用户一遍遍重复解码——ReuseGR把这件事拆成“7B离线规划、0.5B在线补全”，在线平均延迟从117ms降到71.45ms，HR@100还小涨了一点。重复query越多的系统，这笔账越划算。
📄 ReuseGR: Offline–Online Decoupled Generative Retrieval via Adaptive Prefix Reuse
🔧 生成过程被拆成两段：7B离线规划器只按query生成SID前缀集合，同一query的所有请求共享；0.5B在线模型拿当前请求的历史去选前缀、补后缀，个性化部分全部留在线。
🧩 ReuseCut不搞一刀切：它用历史目标覆盖率给每个query预测该缓存几层。切得深省解码步数但候选子树变窄，切得浅把选择权留给历史条件生成，这个边界得按query算。
⚙️ Path KD把7B的后缀打分知识按路径蒸馏给0.5B；BudgetCut在固定分支预算下学“哪些分支进最终top100”，先用OPD按边际召回增益初始化策略，再用GRPO按整组分支的召回精调，规划器和打分器保持冻结。
📊 工业搜索广告数据（约200万query-item、338万item）：HR@100达85.82%，比全在线0.5B高3.83个百分点，平均在线延迟降38.9%。
📈 对全在线7B，HR@100基本持平，在线延迟低57.7%。
✅ 深度匹配本身有效：与同深度分布的随机打乱相比，HR@100高3.17个点；同等前缀数下，query级前缀平均覆盖78.62%的目标SID，均匀两层只有74.18%。
✅ 带真实请求历史补全时，5.67%的行能召回query-only 7B top100里没有的点击SID。
✅ 14天用户级线上A/B对0.5B基线：CTR相对+0.93%，RPM相对+1.05%。
总结感想：做生成式检索、query重复率高的搜索或广告系统可以看，尤其是解码成本限制大模型上线的情况。但有两个前提必须盯：一是“前缀已准备好”的命中率，冷miss得靠0.5B端到端兜底，命中率一低，延迟收益直接打对折；二是ReuseCut的深度标签来自历史覆盖率，新query和新item分布漂移时要重训。评估别只看均值延迟，P99、缓存构建与失效成本要和HR@100一起看。