大多数生产环境的推荐系统都是级联结构。候选生成器将结果输入预排序器，预排序器再将结果输入基于数百个工程特征构建的重量级排序器。Yandex 的 Sona 技术报告 描述了一种不同的设计。Sona 是一个生成式 AI 模型，它将候选生成和排序整合到一个系统中，取代了推荐流程中通常使用的多个阶段。Yandex 在其智能音箱上进行了为期七天的线上生产实验来测试该模型。在一次线上 A/B 测试中，它用一个部署的 transformer 取代了超过 15 个候选生成器、预排序阶段和排序阶段。
Sona 解决什么问题？
级联结构将一个决策拆分到多个独立训练的模型中。每个阶段优化自己的目标，而排序器只能看到上游阶段放行的内容。Yandex 在 Yandex Music 界面上的旧技术栈消耗了数百个特征，包括来自 Argus（Yandex 早期的推荐 transformer）的信号。Sona 将候选生成和排序围绕同一个共享用户表征来构建。编码器在每个请求中读取一次收听历史。解码器生成候选。排序模块（Ranking Module）基于同一组编码器状态对候选打分。任何组件都不使用人工工程特征。输入是记录的事件字段（曲目 ID、艺术家 ID、时长、点赞、播放时间、界面标志）以及学习到的语义 ID（Semantic ID）。
在 Yandex 智能音箱上，播放可以在用户尚未选择艺术家、流派或心情的情况下开始。研究团队将此称为纯推荐场景。
Sona 的架构如何运作
1. 语义分词器
遵循 Rajput 等人的 Semantic ID 公式，每首曲目变成一个由 3 个离散码组成的元组。一个冻结的多模态 LLM 读取前 90 秒的梅尔频谱图以及标题、艺术家和标签。它以仅预填充（prefill-only）模式运行。然后一个 4 层的细化 transformer 利用协同曲目对上的 InfoNCE 将这些特征与收听行为对齐。残差 K-means 将结果量化为 3 个各含 32,000 个条目的码本。这超过了 CLMR 音频基线：Recall@1000 从 0.8111 提升到 0.8524。
2. 带历史压缩的编码器
Sona 关注 8,192 个过去的事件。在该长度上进行完整注意力计算代价高昂，因此编码器不均匀地分配深度。最近的 2,048 个事件使用 7 层自注意力堆栈。较旧的事件仅通过交叉注意力和 1 个全历史层。论文报告称，这以约一半的推理成本保留了完整注意力的大部分质量。
3. 解码器和排序模块
一个 2 层解码器通过宽度为 1,024 的受限束搜索生成 Semantic ID 元组。一个目录 trie 阻止无效前缀。每个元组扩展为共享它的所有曲目。由四个交叉注意力层组成的排序模块随后针对共享的编码器记忆对这些曲目打分。
训练：一个从不部署的教师模型
排序模块从一个冻结的教师排序器（Teacher Ranker）学习。教师是一个 0.6B 参数的 transformer，同样不使用人工工程特征。它在 2 个阶段中基于一年的互动事件进行训练：先进行下一项预测预训练，然后进行多头排序微调。移除预训练使加权成对准确率从 0.6215 下降到 0.6153。
团队将其蒸馏方法称为 Rollout Distillation。在训练期间，当前的解码器生成束搜索候选。教师对它们以及记录的曝光进行打分。排序模块以平均绝对误差对这些分数进行回归。联合损失为 L = L_NTP + L_rollout + L_impression。两个损失都会更新共享的编码器。在服务时，教师被移除。
训练保持在线。事件在 15 分钟的窗口内聚合为会话，馈送到 GPU 训练器，新权重每 10 分钟到达一次服务端。端到端延迟中位数为 45 分钟，p99 为 60 分钟。服务运行在 NVIDIA Triton Inference Server 上，使用 CUDA graphs，达到 41% 的模型 FLOPs 利用率。
结果：真实流量上的线上 A/B 测试
最终实验在每个分组中随机选取的 15% 用户上运行了 7 天。以下每一项变化均具有统计显著性，且相对于生产对照组：
- 活跃用户 （主要指标）：+4.53%
- 总收听时长: +6.30%
- 点赞: +11.42%
- “重复”命令: +17.99%
- 深度参与用户: +7.37%
这些提升叠加在早期部署中保留的改进之上。在活跃用户指标上，Sona 的提升是该界面上 Argus 此前带来的 +1.93% 增量的 2.35 倍。
Sona vs OneRec vs HSTU：功能对比
Sona 并不是第一个投入生产使用的端到端生成式推荐系统。快手的 OneRec 已经在服务一个单一的编码器-解码器模型。Meta 的 HSTU Generative Recommenders 在 2024 年将推荐重新定义为对用户行为序列的序列转导。Sona 所结合的是完整的级联替换、无手工特征，以及经过在线验证的蒸馏排序器。
| 特性 | Sona（Yandex） | OneRec（快手） | HSTU GR（Meta） |
| 领域 | 音乐流媒体 | 短视频 | 大型互联网平台，多个界面 |
| 单一服务模型替代级联 | 是，在 A/B 测试中 | 是，约占总 QPS 的 25% | 否，被报道为推荐模型的一种新架构 |
| 用户输入 | 仅使用已记录的事件字段，无手工特征 | “多尺度特征工程”通道，包括 uid、年龄、性别 | 用户行为序列（序列转导） |
| 物品输出 | 3 级语义 ID，3 x 32,000 | 通过 RQ-Kmeans 生成的 3 级语义 ID | 物品 ID |
| 排序信号 | 由冻结的 0.6B Teacher Ranker 生成 | 使用 P-Score 奖励模型的强化学习（ECPO） | HSTU 排序模型 |
| 强化学习 | 否，完全监督 | 是（ECPO） | 未报告 |
| 已报告规模 | 8,192事件历史，0.6B教师模型 | 是先前排序模型FLOPs的10倍 | 1.5万亿参数 |
| 线上收益报告 | +4.53%活跃用户、+6.30%收听时长、+11.42%点赞 | +0.54%和+1.24%应用停留时长 | 线上A/B测试中提升12.4% |
| 公开代码或权重 | 无 | 报告中未提及 | 有,GitHub |
来源: Sona, OneRec, HSTU。各线上收益来自不同平台和指标,因此不可直接比较。
关键要点
- Sona 用 1 个服务模型取代了 15 个以上的生成器、预排序和排序。
- 无人工设计特征:仅使用日志事件和习得的语义ID(Semantic ID)。
- 一个0.6B的教师模型训练排序器,随后不参与线上服务。
- A/B测试:活跃用户提升4.53%,是Argus此前提升的2.35倍。
- 无法对外部署:无代码或权重,未在全量流量上运行。
常见问题
什么是Yandex Sona?
Sona是一个生成式AI模型,它在单一系统内结合了候选生成与排序。Yandex在其智能音箱上进行了一场为期七天的线上生产实验,用Sona为测试组取代了现有多阶段推荐流水线。
Sona与OneRec有何不同?
OneRec使用工程化的用户特征通路以及基于奖励模型的强化学习。Sona仅使用日志事件字段,并从一个冻结的教师模型蒸馏排序能力。
请查看 论文 了解完整细节。