文章总结： 腾讯TRS团队提出列表级生成式推荐框架HiGR，采用编码-规划-生成-对齐一体化范式解决推荐痛点。方案结合CRQ-VAE、HSD分层解码与ORPO算法，实现离线质量提升超10%与推理速度提升5倍以上。线上验证显示用户观看时长显著增长，提供了高性能可落地的推荐升级路径。 综合评分： 88 文章分类： 产品介绍,解决方案

推理速度提升5倍+：腾讯TRS团队首创列表级生成式推荐HiGR

原创

腾讯程序员 腾讯程序员

腾讯技术工程

2026年2月6日 17:36 中国香港

作者：李裕东 庞雲升 刘子健

导语

在信息流、短视频、电商等推荐场景中，用户真正感知的并非某一条内容的相关性，而是一整屏列表带来的「整体体验」。 为此，腾讯TRS团队在论文《HiGR: Efficient Generative Slate Recommendation via Hierarchical Planning and Multi-Objective Preference Alignment》中提出分层规划的端到端生成式推荐框架HiGR，将传统的级联推荐范式升级为「编码—规划—生成—对齐」的一体化新范式

• 先做列表级意图规划
• 再做物料级生成解码
• 最后通过列表级偏好对齐，直接面向隐式反馈优化整列质量

该方法已在真实业务场景验证了显著收益：

• 离线推荐质量相对 SOTA 提升超过 10%
• 推理速度提升 5 倍以上
• 线上小流量 A/B 实验验证：用户观看时长与消费深度均有显著增长

HiGR首创基于“编码—规划—生成—对齐”的列表级端到端生成式推荐一体化范式，为业务提供了一条高性能、可规模化落地的生成式推荐升级路径。

1. 为什么“列表级端到端”是下一代推荐的关键

传统的推荐系统通常采用级联架构（召回 -> 粗排 -> 精排 -> 重排），虽然这种漏斗式结构在基于CPU的计算效率上具有优势，但存在三个核心痛点：

• 目标不一致： 级联推荐架构下，召回、粗排、精排这些层的模型都在优化点对点（Pointwise）的准确率，而用户最终消费的是一个列表（Listwise），局部最优并不等于全局最优。
• 误差累积： 级联推荐架构下，上游模块的偏差会层层传递，导致重排阶段只能在有限且可能已经“偏航”的候选中进行微调。
• GPU算力利用不足： 如下图所示，单位成本下GPU计算性能每年在翻倍提升，未来确定性的趋势是GPU性能还会持续提升，而传统推荐模型的算力利用率（MFU）普遍偏低（大多不到1%）；相比之下，大语言模型领域已验证更高 MFU 的工程可达性，LLM的模型算力利用率（MFU）可以达到70%，推荐系统仍有显著“算力红利”空间。

因此，业界都在积极探索端到端生成式推荐范式（比如OneRec，OneRec-Think等），期望进一步突破推荐模型的天花板，但当前大多数生成式推荐的研究还是基于NTP (Next Token Prediction) 范式，即像语言模型一样逐个 Token 地预测物料，这种方式在推荐场景下面临两个挑战：

• 推理效率受限： 自回归逐Token生成在推荐场景中面临严峻的延迟瓶颈。以生成一个包含10个物料的推荐列表为例，若每个物料ID需要4个Token表示，则需要40步自回归解码，难以满足在线推荐的毫秒级响应要求。
• 缺乏全局规划： NTP范式本质上仍是Token级别的交叉熵损失，与用户对整个推荐列表的隐式反馈（如停留时长、滑动深度）之间存在Gap，难以直接优化列表级用户体验。

为了突破这些瓶颈，我们提出了分层规划的端到端生成式推荐框架HiGR，其核心思路是从“逐 Token 填充”转向“分层规划与整列对齐”，先在列表层做“意图规划”（Plan），再在物料层做“生成解码”（Generate），最后用“列表级偏好对齐”（Align）把整列质量直接对齐业务指标。

2. HiGR一体化框架：从“编码—规划—生成—对齐”闭环优化整列质量

如上图所示，HiGR 框架主要包含三个核心模块：

• 语义编码：提出 CRQ-VAE，解决前缀 ID 纠缠与残差坍塌 针对 RQ-VAE 存在的 ID 纠缠和残差坍塌的问题，CRQ-VAE 引入对比学习和全局量化约束：

• 前缀对比学习：设计 InfoNCE loss 强制前缀 ID 成为语义锚点，实现“前缀聚类，后缀区分”，确保分层规划器能准确捕捉意图

• 全局量化损失：构造全局损失替代逐层累计损失，深层码本也能承载有效信息，保证语义 ID 表达的一致性

• 分层规划：提出 Hierarchical Slate Decoding（HSD）先“定大局”，再“填细节” 为了解决自回归生成的延迟问题并引入全局视野，HiGR 将生成过程解耦为两步：

• Layer 1：列表级意图规划（Corase-grained Slate Planner）：模型首先不直接预测具体的视频 ID，而是根据用户的交互历史，生成一个“列表意图蓝图”（Slate Intent）。

• Layer 2：物料级生成解码（Fine-grained Item Generator）：在确定的“列表意图蓝图”指导下，模型并行地填充具体的物料语义 ID。

• 列表级偏好对齐（Listwise Preference Alignment）：用隐式反馈“直接优化整列体验” 为了突破预训练“只能拟合分布，无法区分优劣”的局限，同时解决当前强化学习工业落地瓶颈，HiGR 采用了 ORPO 算法：

• 免参考模型：结合 SFT 和 Odds Ratio 损失，在单模型架构下实现偏好对齐，大幅降低显存占用和训练延时

• 三元目标样本构造：通过构造针对性样本对，同步优化保序性、真兴趣和列表多样性

2.1语义编码：CRQ‑VAE 如何解决“语义ID纠缠”并让前缀可控

在生成式推荐中，我们物品ID化（tokenization）的质量直接决定了后续生成模型的上限。传统的RQ-VAE模型虽然能降低词表大小，但在工业落地中暴露出了“前缀语义纠缠”与“残差坍塌”的两大核心问题，导致生成模型难以精准把控推荐意图。

2.1.1 痛点深入：为什么传统的Semantic ID不好用？

• ID纠缠 在标准RQ-VAE中，量化仅由重构误差驱动。这导致生成的Codebook缺乏语义拓扑结构——前缀相同不一定代表类别相同，而前缀不同的物品却可能非常相似。对于分层规划器来说，如果ID不具有明确的语义聚类特性，它就无法准确地规划出高层的“意图”。
• 残差坍塌 随着量化层数迭代，后续层级的残差向量往往趋近于零，导致深层码本实际上不承载信息，退化为噪声，浪费了编码容量。

2.1.2 核心方法：基于对比学习的残差量化编解码器（CRQ-VAE）

我们引入对比学习和全局量化约束，强制让语义ID的前缀成为可靠的语义锚点。

• 前缀对比约束 我们在量化器中的前D-1层引入InfoNCE loss，选择语义相似的item或共现率高的item作为正样本，选择批次内其他随机样本作为负样本。让前缀ID负责“聚类”，将相似物品拉到同一个ID前缀下；让最后一层ID负责“区分”，保持对具体物品的细粒度辨识能力。完美契合我们的“先规划，后生成”的分层策略。
• 全局量化损失 不同于传统逐层累计的量化损失，我们针对量化器前后的编码向量和量化重构向量构造全局损失，有效抵抗了残差消失现象，迫使深层码本必须承载有效信息，显著提升了ID的表达一致性。

2.2分层解码：HSD 如何先“规划”列表偏好再“生成”具体内容

2.2.1 痛点深入：“平铺”式的解码器为什么不是列表推荐的最优解？

• 推理耗时长 在推理耗时极为敏感的推荐场景，传统的“平铺”式解码器，即把SID作为token，逐SID地生成列表难以满足耗时要求，因为推理长度为M的列表需要推理M*N次（一个item由N位SID表示），使得传统“平铺”式解码器几乎不可能在实际场景中落地。
• 难以建模item内和item间的关系 推荐场景中的SID token序列不同于语言模型中语义token序列，其有着明确的边界以及层级关系，如下图所示：假设3位SID构成一个item（；），则和有着明确的边界，即属于第一个item，属于第二个item；位于item的第一位，代表着对item更粗粒度的刻画，位于item的第二位，代表对item较细粒度的刻画。传统的“平铺式”解码器更适合建模没有明显边界和层级关系的文本语义token，但却难以捕获推荐场景中item内和item间SID的联系。

2.2.2 核心方案：基于分层解码的先规划，再生成方案

如图所示，基于分层解码的列表推荐方案将列表级偏好规划与具体的item SID序列生成相解耦，通过先规划，再生成的方式逐步生成列表序列。 具体来说，我们首先采用了一个较重的多层Transformer架构作为Coarse-grained Slate Planner，用于从item的粒度规划列表内用户对每个item的偏好，得到一个用户偏好embedding序列，经过投影映射后，每个item的偏好embedding作为较轻量的Fine-grained Item Generator的起始输入，替换常用的BOS token，指导该item生成具体的SID序列。

通过分层，用一个统一的Coarse-grained Slate Planner来规划整个列表内各item的偏好，再对每个item用Fine-grained Item Generator来生成，实现了规划和生成的解耦，对列表内待解码的某个SID token，其不仅能参考该item内已生成的前缀SID序列，还能参考该列表内已生成的完整前序item表示，提升了模型对item内和item间的建模能力。

相比传统的“平铺”式解码器将整个列表的SID序列都经过一个重量级的Transformer架构，分层解码只需将抽象后的item偏好序列经过较重的Transformer层，而将item解码成SID序列时采用了轻量级的Transformer架构，减少了推理耗时。 此外，在推理时，beam search只在每个item内累积logits概率，而不在整个列表累积，进一步降低了推理耗时。

2.3列表级偏好对齐：ORPO 如何用隐式反馈“直接优化整列体验”

监督微调（SFT）只能让模型学会拟合历史曝光分布，即像传统推荐系统那样推荐，但无法学会“什么是更好的推荐”。为了让模型真正理解用户的隐式偏好，我们需要引入偏好对齐技术。

2.3.1 痛点深入：为什么不用最经典的DPO和最火的GRPO？

在生成式推荐的工业级落地中，直接照搬LLM领域的对齐算法面临显著的效率收益瓶颈：

• DPO（Direct Preference Optimization）

• 机制痛点：DPO的损失包含一项

  

  这意味着训练过程中，必须始终加载冻结参数的参考模型进行同步推理。

• 工业阻碍：推荐模型的参数量虽然不如LLM巨大，但是数据量极大。参考模型的存在导致显存占用翻倍，训练吞吐量减半。在小时级更新的推荐业务中，这种训练延时是不可接受的。

• GRPO（Group Relative Policy Optimization）

• 机制痛点：Deepseek提出的强化学习方法GRPO，通过对同一prompt采样G组输出，计算组内相对优势，从而省去了critic model。其核心假设是环境能对每一次采样给予即时、准确的反馈。

• 工业阻碍：GRPO在数据、代码任务中有效，是因为有明确的答案检查器。但在推荐场景中，离线训练无法实时把生成的G个推荐列表推给用户，在没有高保真用户模拟器的情况下，GRPO很难直接应用于离线推理策略学习。此外，列表序列推理是token-by-token生成的，生成G组完整列表极其耗时，会导致训练时长爆炸。

2.3.2 核心方案：列表级的多目标ORPO（Odds Ratio Reference Optimization）偏好对齐

1.损失函数设计：

将传统的监督微调损失和Odds Ratio损失结合

• 直观理解：SFT负责让模型学习传统推荐的，而Odds Ratio损失让优势列表的生成赔率显著高于劣质列表。
• 工程收益：这种单模型、单向传播的架构，训练速度与普通SFT几乎持平，显存占用大大降低。

三元目标”样本构造策略： 为了解决推荐系统既要准、又要好、还要多样的复杂需求，我们在构造偏好对时采用了特殊的正负采样策略：

• 正样本：用户真实观看且高停留时长的序列，按照反馈强度重排

• 负样本：

• Ranking Fidelity（保序性）：将重排样本随机打乱顺序。让模型学会“把好东西率先推出来”

• Genuine Interest（真兴趣）：替换为用户曝光未点击或负反馈的物品。让模型学会剔除“标题党”和无效曝光

• Slate Diversity（列表多样性）：取正样本中第一个物品作为锚点，后续全部填充与锚点相似的top-k物品。让模型学会惩罚“信息茧房”，主动追求多样性

3.实验效果与线上收益

为了验证HiGR在工业级场景下的有效性，我们进行了严格的离线评估和线上A/B测试，以下所有实验数据来自PCG实际内容推荐场景。

3.1 离线评估

上表展示了HiGR在离线评估中的效果，与传统列表推荐方法和判别式模型相比，HiGR体现了生成式推荐模型的优越性，大幅优于传统模型；与最近提出的经典生成式推荐模型相比，得益于HiGR针对列表推荐的独特优化，HiGR也取得了更好的效果。

3.2 线上A/B测试收益

我们将HiGR部署到实际场景的推荐系统中进行A/B实验，与当前的基线模型相比，在播放vv，播放时长和观看时长上均取得了正向显著收益，进一步证明HiGR的有效性。

3.3 Scaling Law实验

图：HiGR模型在收敛loss和NDCG度量指标上的扩展性

如上图所示，模型的收敛损失值随参数量呈现显著的幂律下降趋势；离线指标NDCG@5同样呈现出对数线性增长的趋势。并且斜率保持稳定，没有出现边际效应递减的瓶颈。证明HiGR具有可扩展性，性能收益符合预期。

4. HiGR一体化落地方案

4.1服务架构

#

如上图所示，HiGR模型部署在TRS的TGR服务，集成了画像、实时序列、模型推理、向量检索等一整套推荐基础服务，具有以下核心亮点： 1）支持并行化特征抽：支持万量级的序列特征抽取，可实现提升2倍以上速度提升。 2）跨场景实时序列融合：支持跨场景的用户实时行为融合与压缩。 3）高性能模型推理：基于无量3.0框架，相比原生框架可实现10倍以上加速。 4）高性能近线计算：支持基于 LLM 的“快/慢思考”两种计算模式（规划中）

4.2推理加速

为进一步降低训练和推理成本，我们还从多个角度对HiGR进行了系统性的工程优化，包括采用大语言模型中常用的加速手段，如Flash Attention，KV Cache等。此外，我们在实际落地中发现Beam Search仍是耗时最多的几个环节之一，因此我们也优化了Beam Search的整个流程，以及优化了整体的代码实现，减少不必要的重复计算和优化耗时操作，综合所有的优化手段，将推理速度提高了5倍以上。

1）Flash Attention：LLM中常见的加速手段：通过分块计算，极大减少了 GPU 显存（HBM）与片上高速缓存（SRAM）之间的数据读写次数（IO），从而突破显存带宽瓶颈，显著提升长序列推理的计算速度，在HiGR落地中加速效果明显。 2）KV Cache：通过缓存历史 Token 的 Key 和 Value 状态，使得模型在自回归生成新 Token 时无需重复计算前文所有 Token 的参数，避免了部分冗余计算，降低解码阶段的延迟。但由于推荐场景中的序列长度远不及LLM中的序列长度，推理加速效果不如flash attention明显。 3）Memory Beam：利用GPU的GEMM并行计算能力，优化beam search的实现流程，避免了当beam width很大时，需要将序列复制beam width份输入到模型中带来的额外巨大计算量，在HiGR落地中加速效果明显。 4）其他工程优化：优化具体代码实现中的不合理实现，避免重复计算，优化耗时操作。

4.3如何接入HiGR方案

目前提供两种接入方式： 1）全链路托管模式，提供一站式服务。     适用场景：业务方希望快速获得生成式推荐能力，减少开发成本。     接入方式：业务方仅需按规范提供离线数据表，并通过 API 调用 TGR 在线推    理服务即可获取推荐结果。 2）模块化组件接入，仅接入HiGR模型训练和推理、特征服务或实时序列服务。     适用场景：业务方已有成熟的推荐链路，仅需增强生成式推荐能力。     接入方式：支持按需接入 HiGR 核心组件，包括模型训练与推理算子、特征    抽取服务或实时序列服务，通过插件化方式融入现有架构。

5. 总结与展望

HiGR 针对传统级联推荐架构中目标割裂，以及现有生成式推荐推理延迟高、缺乏全局规划等痛点，提出了一套 “编码—规划—生成—对齐” 的完整解决方案：

• CRQ-VAE：提升语义 ID 的可控性与一致性；
• HSD：通过“先规划，后生成”的分层解码，降低在线延迟并增强列表建模；
• ORPO：用隐式反馈实现列表级偏好对齐，在不引入参考模型的前提下兼顾训练效率与效果。

该方案不仅在离线指标和小流量实验上取得了显著收益，还配合Flash Attention、Memory Beam等系统工程优化实现了5倍+推理加速，验证了其在工业级高并发场景落地的可行性。

HiGR只是我们在生成式推荐探索落地的开端，我们正在积极探索“快慢思考”推理、全域通用的推荐基础模型、对话式推荐等方向，未来会基于 LLM 推理能力进一步提升推荐效果的天花板。

招聘信息

腾讯TRS团队正在招聘「生成式推荐」方向研究实习生。 如果你对推荐系统、生成式模型、LLM 与排序/召回结合等方向感兴趣，欢迎投递简历，具体方式如下：

• 扫描下面二维码登陆join.qq.com

• 项目选择：日常实习生或应届实习生

• 岗位选择：技术研究-推荐算法方向

• 意向部门选择：PCG技术线-大数据平台方向

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：腾讯技术工程 腾讯程序员 腾讯程序员《推理速度提升5倍+：腾讯TRS团队首创列表级生成式推荐HiGR》