生成式推荐技术报告解读：蒸馏上限与Reward定义之辩

一、背景：推荐系统正在经历“生成式”范式迁移

近两年，大语言模型的成功让整个算法领域开始重新审视“端到端”的价值。传统推荐系统采用多级漏斗架构：召回从百万级物料中筛出数千候选，粗排压缩到数百，精排精打细算，重排做最后调整。这种架构在工程上稳健可靠，但天花板也很明显：各级模块优化目标不一致、信息逐级损耗、整链路难以联合优化。

生成式推荐提供了另一种思路：用一个统一的大模型直接“生成”最终推荐结果——给定用户上下文，模型以自回归方式产出候选序列与对应打分，实现”one model for all”。近期某头部内容平台公开了相关的技术报告，业界讨论的亮点集中在三个方面：

1. 架构设计：将推荐问题转化为序列生成问题，候选产生与打分在同一个模型内完成；
2. Reward 建模：定义了个性化融合的组合得分作为优化目标；
3. 强化学习：引入 RL 框架对生成结果进行端到端调优。

这些亮点报告本身写得很清楚，读者可以直接从报告中获取细节。本文更想讨论的是几个报告没有明说、但可能更重要的判断。

二、一个关键假设：生成式模型可能是在对精排做“线上蒸馏”

报告中用于监督信号与强化学习 reward 的 P-score，并非从真实用户反馈中直接学习得到，而是来自线上精排模型的输出——本质上是拟合精排模型中各指标（如 CTR、长播率）的组合得分。

由此可以推出一个重要判断：这类生成式方案，实际上是在对精排模型进行“线上蒸馏”。理由有三：

• 监督信号同源：student（生成式模型）学习的目标就是 teacher（精排模型）的打分结果；
• 知识边界一致：reward 完全依赖精排输出，其知识上限被 teacher 卡死；
• scaling law 得到解释：正因为是蒸馏任务，“模型越大、蒸馏越充分”才成立，训练曲线才会呈现出类似大模型的规模收益。

但蒸馏任务的宿命是：student 的性能以 teacher 为上限。一旦生成式模型把精排模型的知识“吸干”，继续堆参数的边际收益会迅速衰减。换句话说，这套方案的 scaling 曲线大概率存在一个“对齐精排”的拐点；越过拐点之后，天花板不再由模型参数决定，而由 teacher 的能力决定。

这引出一个尖锐的问题：生成式推荐究竟是一次“范式革命”，还是一次“工程上更优雅的精排复刻”？如果 reward 始终锚定精排输出，答案恐怕更接近后者。

三、对 Reward 定义的质疑：指标组合是否等价于用户价值？

报告定义了个性化加权的融合得分，把多个行为预估分做加权组合。但从优化目标看，本质上仍是在优化最终组合得分，以及各 label 的 AUC（CTR、长播率等离线指标）。

这里存在一个值得警惕的缝隙：我们真正想优化的“用户价值”，是否能够被这些指标的组合完全刻画？

• 指标是代理，不是本体。CTR 高不代表用户满意，长播率高也可能来自标题党或情绪化内容；
• 组合权重靠经验。多个 pXTR 之间的权重大多由人工设定并通过 AB 实验微调，缺乏对“价值”的第一性定义；
• 偏差层层累积。位置偏差、曝光偏差、流行度偏差都会污染 pXTR 本身，直接拿来组合，等于把偏差也写进了 reward。

可能的改进方向至少有三类：其一，在 pXTR 上做去偏（de-bias），让基础预估分更接近真实偏好；其二，引入更个性化的价值定义，让不同人群的 reward 结构差异化；其三，从“即时行为指标”走向“长期价值”，例如以多日留存、长期消费深度作为终极目标，再反推中间指标的最优组合。

四、推荐系统的核心命题：如何定义 Reward / 用户价值

拉长视角看，推荐系统的历次架构演进，本质上都是对“reward 定义”的逼近，可以拆成上下两层：

• 上游 pretrain：关注如何准确估计基础行为——完播率、点赞率、长播率等，解决“估得准”的问题；
• 下游组合：关注如何把这些基础指标组合成整体目标，最终优化用户时长或长期价值（如 7 日长期价值 LT7），解决“合得对”的问题。

“估得准”近年来进步显著，多任务学习、长序列建模、大规模预训练持续抬高了 pXTR 的精度；但“合得对”基本还停留在人工加权加在线实验的阶段。而恰恰是组合方式的科学性，决定了推荐系统的上限与用户体验的真正提升空间——组合错 10%，前面所有模块的努力都会被放大成更大的体验损耗。

用一个简化的伪代码描述当前典型做法：

# 示意：当前典型的 reward 组合方式（伪代码）
reward = (
    w_ctr   * p_ctr      # 点击率分
  + w_eff  * p_eff       # 有效观看分
  + w_like * p_like      # 互动分
  + w_long * p_long      # 长播分
)
# w 的确定依赖人工经验 + 在线 AB 调优
# 隐含问题：真实的"用户价值"是否恰好是这些项的线性组合？

五、与 LLM 成功路径的对比：为什么 RLHF 在推荐里没那么灵

把视线投向大语言模型，可以更清楚地看到差距。LLM 的关键突破来自 Instruction Tuning 与 RLHF，而 RLHF 之所以成立，有两个常被忽视的前提：

1. reward 模型的规模与主模型基本相当——reward 模型本身就是一个大模型，有能力对任意输出给出细粒度的质量判断；
2. reward 的定义足够明确——人类偏好数据直接标定了“什么是好答案”，语义清晰、覆盖面广。

反观推荐系统：reward 通常只是一个轻量输出头的产物，规模远小于主模型；reward 的定义依赖既有业务指标的组合，缺乏对“用户价值”的深度、明确刻画。后果是：主模型再大，也只是在更卖力地拟合一个“小而模糊”的目标。

因此，如果生成式推荐想真正复刻 LLM 的路径，关键动作可能不是把主模型堆得更大，而是把 reward 体系做大做实：构建规模与主模型相当、基于大规模真实用户反馈（而非精排打分）训练的 reward 模型，让 reward 本身具备 scaling 能力。这或许是下一代推荐系统最值得投入的方向。

六、工程落地：分阶段推进的务实建议

结合上述分析，给正在或计划落地生成式推荐的团队几条建议：

1. 阶段一：对齐基线。先以蒸馏精排为目标，验证生成式架构在工程效率上的收益（一次推理替代多级漏斗），确保体验不掉点；
2. 阶段二：扩展监督源。逐步引入精排之外的信号——长期留存实验数据、满意度反馈、去偏后的行为序列，松动 teacher 的知识边界；
3. 阶段三：reward 独立化。让 reward 模型脱离对精排输出的依赖，成为独立训练、独立迭代的模块，并为 reward 质量建立离线评测标准（如与长期指标的因果一致性）。

基建层面，大模型与强化学习组合训练对算力和工程链路的要求很高：需要高吞吐的分布式训练框架支撑主模型与 reward 模型并行迭代，需要低延迟在线推理服务承接大模型打分，也需要完善的日志与监控告警体系保障实验闭环。自建压力较大的团队，可以借助公有云提供的容器平台与 GPU 算力（例如百度智能云的通用算力与容器服务）来降低试错成本、加速迭代节奏。

七、结语

这份生成式推荐技术报告的最大价值，未必是给出一个终点答案，而是把行业推到了一个必须直面的命题前：当模型架构的 scaling 已经启动，reward 的 scaling 是否准备好了？架构决定下限，reward 决定上限。在追赶模型规模的路上，如何更科学地定义用户价值、构建规模对等的 reward 体系，才是决定生成式推荐能走多远的真正胜负手。