近日,快手推荐模型团队提出了一个端到端生成式推荐系统OneRec,该系统采用Encoder-Decoder架构,引入了基于奖励机制的偏好对齐方法,借助强化学习增强模型效果,可在奖励模型引导下直接生成契合用户偏好的视频内容。通过极致的性能优化,OneRec在推荐模型FLOPs提升10倍的同时,大幅削减了通信和存储等运营成本近90%。目前,OneRec已在快手/快手极速版双端承接25%的线上流量,带动APP停留时长分别提升0.54%和1.24%。

图片

论文链接:https://arxiv.org/abs/2506.13695

当生成式架构重塑AI技术栈时,推荐系统却仍受困于模块化设计的“算力泥潭”——传统级联架构导致的算力碎片化、优化不一致等问题,限制了这一核心基础设施的创新步伐。为此,快手技术团队提出了端到端生成式推荐新范式「OneRec」。

【主要贡献】

1. 单阶段编码器-解码器生成框架:该框架巧妙利用Encoder 对用户全生命周期行为序列进行压缩处理,以此实现精准的兴趣建模,同时基于MoE架构的Decoder具备超大规模参数扩展能力,有力保障了短视频推荐的端到端精准生成。

2. 引入了基于奖励机制的偏好对齐方法:通过奖励反馈机制,并借助强化学习增强模型效果,模型能够敏锐捕捉到更为细粒度的用户偏好信息。为此,OneRec精心设计并搭建了一套多维度奖励系统,涵盖偏好奖励、格式奖励、工业场景奖励,全方位助力模型理解用户偏好。

3. 首个工业级端到端生成式推荐落地方案:本系统在快手主站/极速版双端短视频推荐主场景完成验证。为期一周、覆盖 5% 流量 的 A/B 测试表明,纯生成式模型 (OneRec) 仅通过强化学习对齐用户偏好,即达到与原复杂级联系统相当的效果。叠加奖励模型选择策略 (OneRec with RM Selection) 后,更实现了用户停留时长显著提升(主站 +0.54%,极速版 +1.24%),以及7日用户生命周期 (LT7) 增长(主站+0.05%,极速版+0.08%)的业务突破。

下图(左)展示了快手 / 快手极速版中 OneRec 与级联推荐架构的 Online 性能比较,图(中)展示了 OneRec 与 Linear、DLRM、SIM 的 FLOPs 比较,图(右)展示了 OneRec 与级联推荐架构的 OPEX 对比,以及和链路中计算复杂度最高的精排模型 SIM 的 MFU 对比。

图片

一、传统推荐系统框架的局限性

推荐系统是一种基于用户历史行为、物品属性以及上下文信息,通过模型算法来预测用户偏好并主动推送个性化信息的信息过滤技术。在个性化新闻推送、音乐推荐、视频推荐以及商品推荐等众多场景中,推荐系统都发挥着至关重要的作用。

传统推荐系统通常采用召回->粗排->精排的多层级联架构模式,以平衡系统时延和效果,然而在实际应用中,却面临着三大核心瓶颈:

其一:算力效率低下。以快手为例的分析显示,即使是在推荐系统中计算复杂度最高的精排模型(SIM),在旗舰版GPU上进行训练和推理时,其MFU分别仅为4.6%和11.2%。与之形成鲜明对比的是,大语言模型在H100上的MFU能够达到40%-50%的水平。

其二:目标函数相互冲突。平台需要同时优化用户、创作者和生态系统的数百个目标,这些目标在不同阶段相互掣肘,导致系统整体的一致性和效率持续恶化。

更严峻的是,技术代差逐渐拉大。随着AI技术的飞速发展,Scaling Law、强化学习等前沿技术不断涌现,并在众多领域取得了显著成效。然而,现有架构却难以将这些最新的AI技术成果有效吸纳。同时,由于架构的限制,推荐系统也难以充分利用先进计算硬件的能力。这使得推荐系统与主流AI技术的发展步伐逐渐脱节,技术代差日益拉大。

二、快手端到端生成式推荐系统OneRec

面对这些挑战,快手团队提出端到端生成式推荐系统OneRec,其核心在于利用Encoder压缩用户全生命周期行为序列实现兴趣建模,同时基于MoE架构的Decoder实现超大规模参数扩展,确保短视频推荐的端到端精准生成。同时配合定制化强化学习框架和极致的训练/推理优化,使模型实现效果和效率的双赢。

目前,新系统在以下几个方面的效果显著:

  • 可以用远低于线上系统的成本,采用更大的模型,取得更好的推荐效果;

  • 在一定范围内,找到了推荐场景的scaling law;

  • 过去很难影响和优化推荐结果的RL技术在这个架构上体现出了非常高的潜力;

  • 目前该系统从训练到serving架构以及MFU水平都和LLM社区接近,LLM社区的很多技术可以很好地在这个系统上落地。

图片

2.1 OneRec模型框架

OneRec采用编码器-解码器架构(如下图),将推荐问题转化为序列生成任务,在训练过程中使用NTP (Next Token Prediction) 损失函数优化。

图片

2.1.1 语义分词器

面对快手平台上亿级别的视频内容,如何让模型"理解"每个视频成为关键挑战。OneRec首创了协同感知的多模态分词方案:

  • 多模态融合:同时处理视频的标题、标签、语音转文字、图像识别等多维信息;

  • 协同信号集成:不仅关注内容特征,更融入用户行为信息建模;

  • 分层语义编码:采用RQ-Kmeans技术,将每个视频转化为3层粗到细的语义ID

2.1.2 编码器-解码器

在训练阶段,OneRec通过编码器-解码器架构执行下一个token预测,进而实现对目标物品的更高效预测。该架构在不同阶段起到的作用分别如下:

  • 多尺度用户建模:编码阶段同时考虑用户静态特征、短期行为序列、有效观看序列和终身行为序列;

  • 专家混合解码器:解码阶段采用逐点生成策略,通过Mixture of Experts(MoE)架构提升模型容量和效率。

2.1.3 推荐系统中的Scaling Laws

参数规模实验是OneRec研究中的另一亮点,它试图回答一个fundamental的问题:推荐系统是否同样遵循大语言模型领域已被证实的Scaling Law?实验结果清晰地表明,随着模型参数量从0.015B到2.633B的递增,训练损失呈现出明显的下降趋势。

图片

技术报告中还介绍了包含Feature Scaling、Codebook Scaling和Infer Scaling等,极大地利用算力来提升推荐的精度。

2.2 RL偏好对齐

预训练模型虽然可以通过下一个token预测来拟合曝光物品的空间分布,但这些曝光物品来源于过去的传统推荐系统,这导致模型无法突破传统推荐系统的性能天花板。

传统推荐系统通常定义多个目标,如点击量、点赞数、评论数和观看时长,然后通过加权融合每个目标的预测值(xtr)将其组合成一个分数。然而,手动调整这些融合权重既缺乏准确性,又缺乏个性化,并且常常导致目标之间的优化冲突。

为了解决这一挑战,OneRec引入了基于奖励机制的偏好对齐方法,利用强化学习增强模型效果。通过奖励反馈机制,模型得以感知更为细粒度的用户偏好信息。为此,OneRec构建了一套综合性的奖励系统,包括如下:

  • 偏好奖励(Preference Reward)用于对齐用户偏好

  • 格式奖励(Format Reward)确保生成的token均为有效格式

  • 工业场景奖励(Industrial Reward)以满足各类业务场景的需求

图片

首先,什么样的视频应该被奖励呢?面对这一问题,OneRec提出采用偏好奖励模型,能基于用户特征,输出对不同目标预测值进行「个性化融合」后的偏好分数。过程中,利用该分数「P-Score」作为强化学习的奖励ri,并通过GRPO的改进版ECPO(Early-Clipped GRPO)进行优化。结果显示,相较于GRPO,ECPO对负优势(A<0)样本进行更严格的策略梯度截断,保留样本的同时防止梯度爆炸使训练更加稳定。

图片

OneRec在快手两个场景进行了强化学习的消融实验,线上结果显示:在不损失视频曝光量的情况下显著提升APP使用时长。

图片

其次,在OneRec中,词表空间远大于全部视频数量,这会导致在推理阶段生成的语义ID序列可能无法映射回真实视频ID,即非法生成。OneRec指出强化学习虽然能提升效果,但由于「挤压效应」会导致模型输出的合法性显著下降,不仅推理成本变大且不利于推荐的多样性。

挤压效应:负向优势的梯度会将大部分的概率质量挤压到当前模型的最优输出o*,大部分合法输出的概率被抹平。

图片

针对这个问题,OneRec提出「以暴制暴」,用强化学习的方法解决强化学习的问题,引入格式奖励(Format Reward)鼓励合法的输出以缓解挤压效应。OneRec对两种合法样本的挑选方法进行了实验,并观察到非常有趣的结论:

  • 从生成样本中挑选概率最大的k个:生成样本的总体合法性先上升后衰减,所挑选样本的合法性很快收敛到100%

  • 从生成样本中随机挑选k个:生成样本的总体合法性和所挑选样本的合法性同时上升,未出现衰减。

图片

这些现象表明,如果用概率最大的k个样本训练,模型会很快捕捉到奖励的内在机制,从而引发「Rward Hacking」现象。该实验不仅验证了格式奖励的有效性,而且表明奖励的准确定义十分重要。

除了以上提到的用户偏好奖励和格式奖励,OneRec还引入了工业场景奖励,以满足特殊工业需求,如营销号的打压、冷启视频和长尾视频的分发等。

2.3 性能优化

从衡量算力效率的核心指标MFU(模型浮点运算利用率)来说,传统推荐排序模型长期深陷"个位数魔咒",主要有两方面的原因:

  • 一是业务迭代积累的历史包袱,如快手精排模型算子数量高达15000+个,复杂结构导致无法像LLM那样进行深度优化;

  • 二是成本与延迟约束下的规模瓶颈,致使单个算子计算密度低下,显存带宽成为性能天花板,GPU算力利用率长期低于10%。

而OneRec的生成式架构带来破局性变革:通过采用类LLM的encoder-decoder架构精简组件,将关键算子数量压缩92%至1,200个,配合更大模型规模提升计算密度;同时通过重构推荐链路释放延迟压力,使训练/推理MFU分别飙升至23.7%和28.6%,较传统方案实现3-5倍提升,首次让推荐系统达到与主流AI模型比肩的算力效能水平。 

除了模型结构的天然优势,团队还针对 OneRec 特性在训练和推理框架层面进行了深度定制优化。

2.3.1 系统深度优化

除了模型结构的天然优势,我们还针对 OneRec 特性在训练和推理框架层面进行了深度定制优化。

训练优化
  • 计算压缩:针对同一请求下的多条曝光样本(如一次下发 6 个视频,平均 5 条曝光),这些样本共享用户和 context 特征。我们按请求 ID 分组,避免在 context 序列上重复执行 ffn 计算。同时,利用变长 flash attention,有效避免重复的 kv 访存操作,进一步提升 attention 的计算密度。

  • Embedding 加速优化:针对单样本需训练 1000 万以上 Embedding 参数的挑战,我们自研了 SKAI 系统,实现了 Embedding 训练全流程在 GPU 上完成,避免 GPU/CPU 同步中断;通过统一 GPU 内存管理(UGMMU)大幅减少 kernel 数量;采用时间加权 LFU 智能缓存算法充分利用数据的时间局部性,并通过 Embedding 预取流水线将参数传输与模型计算重叠,有效隐藏传输延迟,整体大幅提升了 Embedding 训练效率。

  • 高效并行训练:采用数据并行 + ZERO1 + 梯度累计的训练策略。选择 ZERO1 是因为模型 Dense 参数较小,单 GPU 可容纳完整模型参数和梯度,在 interleaving 多个 macro batch 时能够减少数据并行组的同步开销。

  • 混合精度与编译优化:绝大部分 op 使用 BFloat16 进行运算,对全图进行编译优化,通过计算图优化和 kernel fusion 减少计算开销。

推理优化

OneRec 在推理阶段采用大 beam size(通常为 512)来提升生成式推荐的多样性和覆盖率。面对如此大规模的并行生成需求,我们从计算复用、算子优化、系统调度等多个维度进行了深度优化:

  • 计算复用优化: OneRec 针对大规模并行生成需求,通过多种计算复用手段大幅提升效率:首先,同一用户请求下 encoder 侧特征在所有 beam 上完全一致,因此 encoder 只需前向计算一次,避免了重复计算;其次,decoder 生成过程中 cross attention 的 key/value 在所有 beam 间共享,显著降低显存占用和算力消耗;同时,decoder 内部采用 KV cache 机制,缓存历史步骤的 key/value,进一步减少重复计算。

  • 算子级优化: OneRec 推理阶段全面采用 Float16 混合精度计算,显著提升了计算速度并降低了显存占用。同时,针对 MoE、Attention、BeamSearch 等核心算子,进行了深度 kernel 融合和手工优化,有效减少了 GPU kernel 启动和内存访问次数,全面提升了算子计算效率和整体吞吐能力。

  • 系统调度优化: OneRec 通过动态 Batching 策略,根据当前系统负载和请求延迟实时调整 batch 的大小,尽可能提升每个 batch 的并发度。这种方式能够有效减少单次请求的平均访存带宽消耗,进一步提升整体计算效率和系统吞吐。

通过以上系统性的优化策略,OneRec 在性能方面取得了显著提升。在算力利用率方面,训练和推理的 MFU 分别达到了 23.7% 和 28.8%,相比传统推荐模型的 4.6% 和 11.2% 有了大幅改善。运营成本降低至传统方案的 10.6%,实现了接近 90% 的成本节约。

2.4 Online实验效果

OneRec在快手主站/极速双端app的短视频推荐主场景上均进行了严格实验。通过为期一周5%流量的AB测试,纯生成式模型(OneRec)仅凭RL对齐用户偏好即达到原有复杂推荐系统同等效果,而叠加奖励模型选择策略(OneRec with RM Selection)后更实现停留时长提升0.54%/1.24%、7日用户生命周期(LT7)增长0.05%/0.08%的显著突破——须知在快手体系中,0.1%停留时长或0.01% LT7提升即具统计显著性。

更值得关注的是,模型在点赞、关注、评论等所有交互指标上均取得正向收益(如下表),证明其能规避多任务系统的"跷跷板效应"实现全局最优。该系统目前已经在短视频推荐主场景承担25%的QPS。

图片

除了短视频推荐的消费场景之外,OneRec在快手本地生活服务场景同样表现惊艳:AB对比实验表明该方案推动GMV暴涨21.01%、订单量提升17.89%、购买用户数增长18.58%,其中新客获取效率更实现23.02%的显著提升。

目前,该业务线已实现100%流量全量切换。值得注意的是,全量上线后的指标增长幅度较实验阶段进一步扩大,充分验证了OneRec在不同业务场景的泛化能力。

三、总结和展望

OneRec通过创新的生成式架构重构推荐系统的技术范式。与此同时经过极致的工程优化,在效果与效率双重维度上实现全面超越。当然,新系统还有很多地方未完善,报告中仍指出了三个待突破的方向:

  • 推理能力:Infer阶段step的scaling up能力尚不明显,这预示着OneRec还不具备很强的推理能力;

  • 多模态桥接:构建用户行为模态与LLM/VLM的原生融合架构,借鉴VLM中的跨模态对齐技术,实现用户行为序列、视频内容与语义空间的统一学习,成为一个原生全模态的模型;

  • 完备的Reward System:目前Reward System的设计还比较初级。在OneRec端到端的架构下,Reward System既能影响在线结果也能影响离线训练,我们期望利用该能力引导模型更好地理解用户偏好和业务需求,提供更优的推荐体验。

可以预见,随着AI能力的持续融入,OneRec将释放出更强大的能力,在更广泛的推荐应用场景中创造更大的业务价值。

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。
如若转载,请注明出处:http://www.pswp.cn/news/910041.shtml
繁体地址,请注明出处:http://hk.pswp.cn/news/910041.shtml
英文地址,请注明出处:http://en.pswp.cn/news/910041.shtml

如若内容造成侵权/违法违规/事实不符,请联系英文站点网进行投诉反馈email:809451989@qq.com,一经查实,立即删除!

相关文章

flex布局 项目属性

<!DOCTYPE html> <html> <head> <meta charset"utf-8"> <title>flex布局 项目属性</title> <link href"css/k.css" rel"stylesheet" /> </head> <bod…

SpringBoot扩展——应用Web Service!

应用Web Service Web Service是一个SOA&#xff08;面向服务的编程&#xff09;架构&#xff0c;这种架构不依赖于语言&#xff0c;不依赖于平台&#xff0c;可以在不同的语言之间相互调用&#xff0c;通过Internet实现基于HTTP的网络应用间的交互调用。Web Service是一个可以…

EasyExcel学习笔记

EasyExcel学习 一、EasyExcel简介 一、EasyExcel是什么 EasyExcel是一个基于Java的简单、省内存的读写Excel的阿里开源项目。在尽可能节约内存的情况下支持读写百M的Excel。 官网&#xff1a;https://easyexcel.opensource.alibaba.com/ 学习Easyexcel前需要了解导入和导出…

day4课程

1整体认识和路由配置 2二级分类面包屑导航实现 3基础商品列表渲染 4列表筛选功能实现 5列表无限加载功能实现 6定制路由滚动行为 7详情页整体认识和路由配置 8详情页基础数据渲染 9详情页基础组件封装和数据渲染 10适配不同title和数据列表 11小图切换大图 12滑块跟随鼠标移动 …

kubeadm worker节点加入master失败

文章目录 1、操作2、问题现象3、问题原因4、问题解决4.1、重新生成token4.2、重新生成hash值 5、验证 1、操作 执行以下命令&#xff0c;让worker节点加入到master节点 kubeadm join 103.123.222.241:6443 --token vxe3v1.wzpnks8v1vbbtsu0 --discovery-token-ca-cert-hash s…

二十二、【用户管理与权限 - 篇四】后端权限定义:模型与 API 实现

【用户管理与权限 - 篇四】后端权限定义:模型与 API 实现 前言准备工作第一部分:设计并创建 `Permission` 模型第二部分:更新 `Role` 模型以关联 `Permission`第三部分:生成并应用数据库迁移第四部分:创建 Serializers第五部分:创建 ViewSets第六部分:注册 API 路由第七…

猜数字小游戏微信流量主小程序开源

这个智力小游戏采用了数字华容道的玩法&#xff0c;玩家需要通过移动数字方块&#xff0c;将数字按顺序排列完成游戏。代码严格遵循微信小程序的目录结构&#xff0c;包含以下部分&#xff1a; 完整的小程序配置文件&#xff08;app.js、app.json、app.wxss&#xff09; 游戏页…

探秘阿里云EBS存储:云计算的存储基石

一、引言 在云计算时代&#xff0c;数据如同企业的生命线&#xff0c;数据存储的重要性不言而喻。随着企业数字化转型的加速&#xff0c;海量数据的存储与高效管理成为亟待解决的问题。云存储以其卓越的灵活性、可扩展性和成本效益&#xff0c;逐渐成为众多企业的首选方案。在…

音视频之H.264的可伸缩编码SVC

系列文章&#xff1a; 1、音视频之视频压缩技术及数字视频综述 2、音视频之视频压缩编码的基本原理 3、音视频之H.264/AVC编码器原理 4、音视频之H.264的句法和语义 5、音视频之H.264/AVC解码器的原理和实现 6、音视频之H.264视频编码传输及其在移动通信中的应用 7、音视…

Anaconda安装env,yml一直卡在Solving environment:不动

如果在使用conda env creat -f env.yml时候&#xff0c;anaconda一直卡住&#xff0c;如下 可以尝试下面操作。 conda config --set solver libmamba # 使用libmamba引擎&#xff08;Conda≥22.11&#xff09; conda env create -f env.yaml # 重新尝试

榕壹云婚恋相亲系统:ThinkPHP+UniApp打造高效婚配平台

引言 在数字化浪潮下,婚恋相亲行业正加速向线上迁移。榕壹云公司基于市场需求与技术积累,开发一款功能完备、技术开源的婚恋相亲小程序系统,为单身人士提供高效、安全的婚恋平台。本文将围绕系统背景、客户定位、核心技术、功能模块及优势场景展开详细解析,助力开发者与技…

查询docker-compose 部署的milvus 请求日志

在 Docker Compose 部署的 Milvus 中,日志默认存储在各个服务的容器内。以下是定位和查询日志的方法: 1. 查看实时日志 使用 docker-compose logs 命令查看实时日志: bash # 查看所有服务的日志 docker-compose logs -f# 仅查看 Milvus 服务日志(服务名以 docker-compos…

Rsync实操

Rsync实操 一.rsync命令 #类似于cp[rootuser2 ~]# rsync info.sh root192.168.168.130:/rootroot192.168.168.130s password: [rootuser1 ~]# lsanaconda-ks.cfg ceph-release-1-1.el7.noarch.rpm info.sh 二、使用rsync备份push方式 服务器&#xff1a;server 192.168.168…

Java常见八股-(6.算法+实施篇)

Java常见八股-&#xff08;1.Java基础篇&#xff09; Java常见八股-&#xff08;2.Java高级篇&#xff09; Java常见八股-&#xff08;3.MySQL篇&#xff09; Java常见八股-&#xff08;4.前端篇&#xff09; Java常见八股-&#xff08;5.框架篇&#xff09; 目录 一、算…

阿里云部署的SMTP服务器安全攻防实录:深度解析攻击、防护与加固

阿里云部署的SMTP服务器安全攻防实录&#xff1a;深度解析攻击、防护与加固 一次针对云上SMTP服务的持续攻击事件&#xff0c;揭示了邮件中继服务面临的多重安全挑战。本文将深入剖析攻击手法、防护策略与系统性加固方案。 某企业在阿里云上部署的Postfix SMTP服务器近期遭遇…

HTTP与HTTPS深度解析:从明文传输到安全通信的演进之路

引言 在互联网的早期&#xff0c;HTTP&#xff08;超文本传输协议&#xff09;作为Web通信的基石&#xff0c;凭借简单高效的特性推动了万维网的爆发式增长。但随着互联网从“信息共享”向“价值交互”演进&#xff0c;HTTP的明文传输特性逐渐暴露致命缺陷——用户的每一次点击…

渗透实战:绕过沙箱机制的反射型XSS

Lab 24&#xff1a;利用 xss 绕过 csrf 防御 依然是留言板的问题可以执行<h1>标签 进入修改邮箱的界面&#xff0c;修改抓包 这里构造修改邮箱的代码 <script> var req new XMLHttpRequest(); req.onload handleResponse; req.open(get,/my-account,true); req…

K8S篇之利用deployment实现滚动平滑升级

一、更新策略 在 Kubernetes (K8s) 中,滚动平滑升级(Rolling Update)是一种无缝更新部署的方式,允许你在不中断服务的情况下逐步更新应用程序。这是 Kubernetes 默认的 Deployment 更新策略,它会按照指定的步幅逐步替换 Pods,确保在新版本的应用程序没有完全替换旧版本的…

【Dify 案例】【MCP实战】【一】【前置配置】

MCP(Model Context Protocol,模型上下文协议) ,2024年11月底,由Anthropic 推出的一种开放标准。旨在为大语言模型(LLM)提供统一的、标准化方式与外部数据源和工具之间进行通信。 MCP 作为一种标准化协议,极大地简化了大语言模型与外部世界的交互方式,使开发者能够以统…

2025高考志愿填报张雪峰资料合集

2025高考志愿填报课程&#xff0c;张雪峰专业指导&#xff01;包含61节课&#xff0c;93个专业详解&#xff0c;总计1500分钟视频。 独家各省资料包&#xff01;新旧高考政策全覆盖&#xff0c;适合高三家长和考生。内容整理自互联网&#xff0c;无偿分享&#xff0c;如有侵权&…