推荐系统的未来:OneRec如何用端到端生成模型颠覆传统架构
OneRec:生成式推荐模型如何重塑下一代推荐系统架构
推荐系统正站在技术革新的十字路口。传统多阶段排序架构在经历十余年迭代后,其性能天花板已清晰可见——级联模块间的优化割裂、计算冗余与反馈延迟,成为制约效果突破的深层瓶颈。而大语言模型(LLM)技术的爆发式发展,为推荐领域提供了全新的解题思路:能否用单一生成式模型替代传统级联架构,实现端到端的智能推荐?快手团队提出的OneRec框架给出了肯定答案。这套创新架构不仅将工业级推荐模型的参数量提升10倍,更以仅传统系统1/10的运营成本,实现了核心业务指标1.6%的显著提升。本文将深入解析OneRec如何通过三大技术突破重构推荐系统的智能边界。
1. 传统推荐架构的困境与生成式范式的崛起
现代推荐系统通常采用"召回-粗排-精排-重排"的级联架构,这种设计在深度学习时代初期确实提升了效果,但随着模型复杂度增长,其固有缺陷日益凸显:
计算效率的沙漏现象
级联架构中每个阶段独立优化,导致整体算力利用率(MFU)普遍低于5%。以快手实践为例,传统系统在数据加载、特征工程和多模块流水线上的计算损耗,使得实际用于有效建模的算力不足采购总量的1/20。这种碎片化计算模式,与LLM领域高达40%的MFU形成鲜明对比。
效果优化的天花板效应
多阶段系统存在严重的"短板效应"——召回阶段的质量上限直接制约后续环节的表现。更关键的是,模块间的优化目标往往存在冲突:召回追求覆盖率,排序侧重精准度,最终需要复杂的人工调参来平衡。这种割裂使得系统难以实现全局最优。
工程维护的雪球成本
当系统需要新增业务目标(如内容多样性、创作者生态保护)时,传统做法是在特定阶段"打补丁"。长期积累导致系统复杂度呈指数增长,美团推荐系统团队2024年的报告显示,其核心排序模块的代码量已超过200万行,维护成本远超新建系统。
生成式推荐的核心突破在于架构简化与计算重构。OneRec通过端到端模型直接生成推荐列表,其技术优势体现在三个维度:
- 计算密度提升:MoE架构实现参数高效扩展,1B参数模型的实际激活参数仅250M
- 目标一致性保障:通过DPO实现多目标直接优化,避免人工加权偏差
- 系统响应敏捷:新增业务目标只需调整reward设计,迭代周期从天级缩短至小时级
表:传统推荐与生成式推荐的关键指标对比
| 维度 | 传统级联架构 | OneRec生成式架构 |
|---|---|---|
| 算力利用率 | <5% | 23.7%(训练) |
| 模块延迟 | 50-80ms(累计) | 28ms(端到端) |
| 参数规模 | 16M-250M(激活) | 1B-8B(稀疏激活) |
| 业务迭代周期 | 1-2周 | 4-8小时 |
2. OneRec的核心技术架构解析
2.1 语义ID体系:推荐对象的"语言化"编码
传统推荐依赖item ID的one-hot编码,这种离散表示面临两大挑战:千万级ID导致embedding表臃肿;新item冷启动困难。OneRec创新性地引入分层语义ID解决方案:
# 语义ID生成流程示例(基于RQ-Kmeans)
def generate_semantic_id(item_features):
residuals = item_features
semantic_ids = []
for level in range(3): # 三级量化
centroids = kmeans_train(level_residuals)
idx = find_nearest_centroid(residuals, centroids)
semantic_ids.append(idx)
residuals -= centroids[idx]
return semantic_ids
该方案通过三级残差量化,将每个视频映射为3个token组成的语义ID序列。关键技术突破包括:
- 多模态对齐表征:融合视频封面、ASR文本、抽帧图像等原始特征,通过Q-Former压缩为512维稠密向量
- 协同信号注入:使用用户行为共现数据优化表征空间,确保语义相似的视频在向量空间中邻近
- 动态平衡聚类:采用改进的K-means算法,保证各层级码本利用率达100%,避免传统RQ-VAE的"码本坍塌"
实验数据显示,这套语义ID体系使新视频的冷启动效率提升47%,同时在千万级视频库上实现98.3%的ID映射成功率。
2.2 MoE架构设计:模型容量的智能扩展
为平衡计算成本与模型效果,OneRec采用稀疏混合专家(Mixture of Experts)架构。其核心创新在于:
- 动态路由机制:每个输入token自动选择top-2专家网络,实现条件计算
- 负载均衡优化:引入loss-free平衡策略,避免专家利用率两极分化
- 层级扩展模式:在Decoder层间隔插入MoE模块,逐步扩大模型容量
表:不同规模OneRec模型的配置与性能
| 模型类型 | 参数量 | 激活参数 | 训练FLOPs | 离线AUC提升 |
|---|---|---|---|---|
| OneRec-0.5B | 535M | 210M | 3.2e18 | +1.2% |
| OneRec-1B | 1.1B | 380M | 7.8e18 | +2.7% |
| OneRec-8B | 8.4B | 1.2B | 5.6e19 | +4.5% |
实际部署中,1B参数的MoE模型相比同规模稠密模型,在保持计算量不变的情况下,关键指标观看时长提升2.3倍。
2.3 迭代偏好对齐:从静态预测到动态优化
传统推荐模型依赖离线训练的静态参数,难以适应用户偏好的实时变化。OneRec创新性地引入三阶段训练范式:
- 基础预训练:基于历史行为数据学习用户兴趣模式
- 奖励建模:构建多目标融合的P-Score预测器
- 强化学习对齐:通过ECPO算法实现在线微调
# ECPO(Early Clipped GRPO)算法核心逻辑
def ecpo_loss(policy_logits, ref_logits, rewards, clip_ratio=0.2):
ratios = exp(policy_logits - ref_logits)
clipped_ratios = clip(ratios, 1-clip_ratio, 1+clip_ratio)
advantages = (rewards - rewards.mean()) / (rewards.std() + 1e-8)
# 早期截断负优势
mask = (advantages < 0).float()
loss = -mean(min(ratios, clipped_ratios)*advantages*(1-mask) +
ratios*advantages*mask)
return loss
这种设计带来三重收益:
- 在线A/B测试显示,偏好对齐使人均观看时长提升6.56%
- 格式奖励机制将合法生成率从50%提升至95%
- 业务约束响应速度从天级缩短至小时级
3. 工业级部署的实战优化
3.1 训练基础设施创新
为支撑千亿参数模型的高效训练,快手设计了异构计算架构:
- Embedding加速层:采用GPU Parameter Server架构,减少90%的通信开销
- 流水线优化:将数据预处理、特征工程与模型计算解耦,实现端到端流水线
- 混合精度策略:对稀疏参数使用FP32,稠密计算使用BF16,平衡精度与效率
实际部署中,90台服务器(每台8×H100)的集群可支持8B模型训练,MFU达到23.7%,较传统架构提升4倍。
3.2 推理性能突破
在线服务面临的核心挑战是:如何在20ms内完成512个候选的生成。OneRec的解决方案包括:
- 语义ID缓存:预计算视频语义ID,节省60%解码时间
- 动态批处理:根据请求延迟敏感度自动调整batch size
- 算子融合:将cross-attention与MoE路由合并为单一CUDA kernel
表:推理优化效果对比(1B模型)
| 优化阶段 | 单请求延迟 | 吞吐量(QPS) | GPU利用率 |
|---|---|---|---|
| 原始实现 | 45ms | 2,100 | 31% |
| +缓存优化 | 32ms | 3,800 | 48% |
| +动态批处理 | 25ms | 5,600 | 65% |
| +算子融合 | 19ms | 7,200 | 82% |
4. 未来演进方向
尽管OneRec已取得显著成效,生成式推荐仍面临多个开放性问题:
冷启动的语义鸿沟
新视频的语义ID依赖内容特征,但用户偏好往往与表面内容无关。正在探索的方案包括:
- 引入用户反馈的实时编码器
- 构建跨模态的对比学习框架
长尾推荐的多样性挑战
当前beam search策略倾向于头部内容。实验中的改进方向:
- 基于熵正则化的采样策略
- 分阶段生成:先确定类别再选择具体内容
与LLM的深度融合
OneRec-Think项目已实现文本与行为的联合训练,但存在两大瓶颈:
- 多模态对齐损失导致推荐精度下降约3%
- 推理成本增加5-8倍
实际部署中,我们采用混合策略:95%流量走纯行为模型,5%流量体验增强版多模态推荐。这种"双轨制"既保证核心指标,又持续积累改进数据。
更多推荐



所有评论(0)