小红书精读：ReuseGR: Offline–Online Decoupled Generative Retrieval via Adaptive Prefix Reuse

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一起看。

原文：AlphaXiv