Sona：一个 Transformer 接管推荐全链路

Yandex Music 最近公布的 Sona，在一次在线 A/B 测试中用单个 Transformer 替代了生产推荐系统里的 15 多个候选生成器、预排序模型和最终排序模型。这不是把某个排序模型换成更大的模型，而是把一条成熟推荐流水线整体压缩成了一个端到端模型。

Sona 是面向音乐推荐的单模型生成式推荐系统，它直接读取用户按时间排列的原始行为历史，同时完成候选生成和排序。根据 Sona Technical Report，最终实验中，这个模型接管了原本由多级模型组成的生产级推荐级联，并在五项报告中的用户参与度指标上全部优于现有系统。

不过，事情还没有走到“传统推荐架构已经被淘汰”这一步。Sona 目前仍处于在线 A/B 测试阶段，尚未承载全量流量。它证明的是单模型推荐在一个成熟音乐产品中具备生产可行性，而不是证明所有推荐场景都应该立刻放弃多级架构。

传统推荐系统的问题，不只是模型数量太多

候选生成是从海量物品中快速筛出一个规模可控的候选集合；预排序是用较复杂但成本仍可控的模型进一步缩小候选集合；排序则是对最终候选进行精细打分。这三步共同构成了互联网产品中常见的推荐级联。

Yandex Music 原有的生产推荐系统包含 15 多个候选生成器，后面还连接着预排序和排序模型。不同生成器可能分别负责协同过滤、相似歌曲、热门内容、用户历史偏好、歌单关系和探索性推荐。它们再把候选结果交给下游模型，下游模型使用数百个特征进行判断。

这套系统的优点很明确：每个模块可以独立优化，故障边界清楚，工程团队也能针对不同信号设计专门的模型。但它的代价同样明显。不同候选生成器之间会重复计算，多个模型之间需要维护特征协议，候选合并和去重会引入额外逻辑，线上调参还经常需要同时修改多个环节。

更关键的问题是，级联架构会把信息分散在不同模型里。一个候选生成器可能知道用户最近听过哪些歌曲，另一个模型更擅长理解歌手关系，最终排序模型再结合设备、时间和上下文特征。每个环节只看到完整用户意图的一部分，系统最终效果取决于这些局部判断能否顺利拼接。

Sona 的思路是把这种分工交给一个更大的序列模型。它不再先问“哪些模块应该生成候选”，再问“候选之间如何排序”，而是直接根据用户的行为历史预测下一步最值得推荐的内容。

它到底替代了哪些组件

Sona 替代的是推荐级联中的候选生成、预排序和最终排序三个阶段，而不是简单替换其中某一个排序器。这个边界很重要，因为“一个模型取代多个模型”在推荐领域可能有两种完全不同的含义：一种是只合并若干相似模型，另一种是从输入到输出重做整条链路，Sona 属于后者。

| 推荐环节 | 原生产系统 | Sona 中的对应机制 | |---|---|---| | 候选生成 | 15 多个候选生成器，分别提供不同来源的内容 | 生成式 Decoder 根据行为历史生成候选 | | 预排序 | 独立预排序模型和特征管道 | 由同一个 Transformer 的内部表示完成 | | 最终排序 | 使用数百个手工和模型特征的排序模型 | Ranking Module 对候选进行统一排序 | | 用户输入 | 多个模型分别读取加工后的特征 | 直接读取按时间排列的原始事件历史 | | 训练方式 | 多阶段、分别训练 | 下一事件预测与 Teacher Ranker 蒸馏联合训练 |

Sona 由一个 Transformer 主干和两个输出模块组成：Decoder 负责生成推荐候选，Ranking Module 负责对候选进行排序。它不依赖传统意义上为每个下游模型单独设计的大量手工特征，而是让主干模型从用户原始行为序列中学习表示。

这里的“生成”并不等于让模型像聊天机器人一样生成歌曲名称。推荐系统中的生成式 Decoder 通常是在离散物品空间中预测下一个物品或物品序列。对于音乐产品来说，物品可以是歌曲、艺术家、专辑或其他可推荐实体。模型学习的是用户行为的转移规律，以及在当前上下文下哪些内容更可能被接受。

8192 条历史，为什么没有直接用全注意力

Transformer 的自注意力机制允许序列中的每个位置关注其他位置，但标准全注意力的计算和显存开销会随着序列长度近似平方增长。对长度为 8192 的用户行为历史直接做全注意力，计算成本会成为线上部署的主要障碍。

Sona 的输入历史最多包含 8192 条事件。这里的事件可以理解为用户播放、跳过、收藏或其他与内容交互相关的行为记录。模型没有简单截断旧历史，而是采用了一种名为 History Compression 的历史压缩结构，在保留较早行为可见性的同时降低推理成本。

History Compression 是一种通过分块注意力降低长序列推理成本的方法。Sona 将 8192 条历史拆成两个区间：较早的 6144 条事件，以及最近的 2048 条事件。

具体结构包括三个关键步骤：

1. 较早的 6144 条事件和最近的 2048 条事件分别形成两个历史块。
2. 两个历史块通过交叉注意力交换信息，并经过一层覆盖完整历史的自注意力。
3. 随后的 7 层 Transformer 只在最近的 2048 条事件上运行。

这种设计的直觉很像阅读用户的长期音乐履历和近期播放列表：长期历史决定用户稳定的品味，近期历史决定此刻的兴趣。系统不需要在每一层都让 8192 个事件互相直接通信，但又不能把旧历史完全丢掉。因此，Sona 先用跨块交互和一层全历史注意力把长期信息注入表示，后续计算重点放在最近行为上。

根据报告，这种历史压缩方案大致将推理成本降低了一半，同时保留了接近全注意力的效果。更重要的是，较早的 6144 条事件仍然对模型可见。它不是简单的“只看最近 2048 条”，而是用一次更昂贵但有限的全局交互，换取后续多层计算的明显缩减。

这也是 Sona 最有工程价值的部分之一。长上下文模型并不稀奇，真正困难的是把长上下文放进线上推荐的延迟和成本约束里。推荐系统面对的不是一次性离线推理，而是持续变化的用户请求、数百万级内容池和稳定的服务延迟要求。

没有数百个手工特征，模型靠什么学习

Sona 的训练目标包括下一事件预测和 Teacher Ranker 蒸馏。下一事件预测让模型学习用户行为序列中的自然转移规律，Teacher Ranker 蒸馏则把成熟排序模型积累的判断能力传递给新模型。

下一事件预测可以理解为推荐系统版本的“根据前文预测下一个词”。模型读取用户已经发生的行为，然后预测接下来可能播放或互动的内容。这个目标能够直接利用原始行为序列，避免把推荐任务完全拆解成点击率、播放完成率、收藏率等多个相互独立的子目标。

Teacher Ranker 是一个用于提供监督信号的教师排序模型。它不一定在线上继续作为最终组件运行，但可以把旧系统经过长期调优形成的排序偏好传递给 Sona。这样做解决了一个现实问题：只靠下一事件预测，模型可能更擅长复现用户已有行为，却不一定能立即复制成熟推荐系统对于质量、探索和业务约束的综合判断。

蒸馏的意义在于，Sona 并不是从零开始挑战原系统。它一方面从用户行为中学习，另一方面吸收原有 Teacher Ranker 的排序知识，最终再通过在线 A/B 测试验证单模型是否能在真实流量中胜出。

报告强调，Sona 不依赖传统推荐级联中的手工特征来完成最终排序。这里并不意味着任何结构化信息都不重要，而是意味着模型的核心决策不再需要依赖一套由不同团队分别维护的特征工程管道。这会减少特征定义、拼接、版本管理和线上离线一致性方面的工程负担。

五项参与度指标全部改善，但别忽略实验边界

Sona 在最终在线 A/B 测试中改善了报告中的五项用户参与度指标。这个结果说明，至少在 Yandex Music 的音乐推荐场景里，单模型统一建模并没有因为放弃多级候选生成而损失效果，反而取得了更好的整体表现。

但现有公开材料并没有在给定资料中列出这五项指标的具体绝对值和相对提升比例，因此不能把“全部改善”改写成未经证实的百分比。对于推荐系统而言，播放次数、播放时长、跳过率、收藏率和用户留存等指标的业务含义并不相同，单独看到某个百分比也无法判断实验是否真正具有长期价值。

| 已公开的实验信息 | 结论 | |---|---| | 实验环境 | Yandex Music 线上真实流量 A/B 测试 | | 替代范围 | 15 多个候选生成器、预排序和排序模型 | | 输入长度 | 最多 8192 条用户行为事件 | | 历史压缩 | 6144 条旧事件 + 2048 条近期事件 | | 后续局部计算 | 7 层仅处理最近 2048 条事件 | | 成本效果 | 推理成本大致降低一半，接近全注意力质量 | | 业务效果 | 报告中的五项参与度指标全部优于对照系统 | | 上线状态 | 尚未全量承载生产流量 |

尚未全量上线也不是一个小注脚。A/B 测试证明模型在实验流量上的平均效果，但全量部署还需要考虑长尾用户、冷启动、内容安全、版权状态、实时性、故障降级和流量分配等问题。多模型架构虽然复杂，却通常能够通过单模块降级来维持服务；单模型架构的优势是统一，风险也可能更集中。

Sona 对推荐工程的真正启发

Sona 最值得关注的地方，不是“Transformer 又赢了”，而是推荐系统的模块边界正在重新定义。过去的拆分往往是由计算资源、数据管道和模型能力共同决定的；当序列模型足够强、线上推理成本能够被压缩后，原先必须拆开的候选生成和排序可能重新合并。

第一，候选生成和排序不一定要由两个完全不同的优化目标驱动。传统架构把候选生成看成召回问题，把排序看成精排问题，但用户最终关心的是推荐结果是否有价值。只要一个模型能同时管理候选空间和结果质量，分阶段优化就不再是唯一方案。

第二，模型数量减少可能比单点准确率提升更有价值。一个模型替代 15 多个候选生成器，并不只意味着少部署一些服务，还可能减少特征同步、模型版本协作、候选去重和线上监控的复杂度。推荐系统的总成本包括训练成本、推理成本、研发成本和故障成本，Sona 主要触及了后面几项。

第三，历史压缩可能成为长行为序列推荐的关键技术。音乐、短视频、电商和资讯产品都积累了很长的用户行为历史，但并非每个历史事件都需要在每一层保持同等强度的交互。Sona 的方案说明，长期兴趣和短期意图可以采用不同的计算预算。

第四，Teacher Ranker 仍然重要。单模型并不等于完全抛弃旧系统。Sona 使用蒸馏把成熟排序器的知识迁移到新模型，说明工业系统的演进更可能是“用新架构吸收旧系统经验”，而不是一夜之间清空过去的模型和特征。

它还没有证明什么

Sona 尚未证明单 Transformer 能够在所有推荐场景替代多级级联。音乐推荐的物品空间、用户行为密度和反馈频率，与招聘、电商、广告或本地生活并不相同。音乐产品的播放事件天然形成较长序列，这给序列模型提供了丰富训练信号；低频、高客单价场景未必拥有同样条件。

它也没有证明手工特征彻底失去价值。成熟推荐系统中的特征通常承载库存、价格、商业约束、内容审核和实时业务状态，这些信息不一定都能从用户历史中推断出来。Sona 的成果更准确的表述是：在 Yandex Music 的这个实验范围内，原本由数百个特征驱动的推荐级联可以被一个端到端模型有效替代。

此外，降低约一半推理成本并不等于总成本必然减半。单模型可能需要更大的训练集、更复杂的离线评估和更高的模型更新成本。真正的工程账本还要包括训练 GPU、数据处理、模型发布、监控和故障恢复。

判断：推荐系统会变成更少的模型，但不会变成没有系统

Sona 释放出的信号很清楚：当一个 Transformer 能够读取长行为历史、同时完成候选生成和排序，并通过历史压缩满足线上成本约束时，传统推荐级联中的大量模块就不再是不可替代的基础设施。

但这场变化的终点不是“所有推荐都只剩一个模型”。更可能的结果是，核心个性化决策逐步集中到少数更强的序列模型中，外围仍保留内容过滤、业务规则、实时状态、实验分流和安全审核等系统组件。模型会变少，系统不会消失。

对推荐团队来说，Sona 提供了一个值得复现实验的方向：先把用户行为历史、候选生成和排序目标放进统一序列建模框架，再用蒸馏继承旧系统的能力，最后用历史压缩解决长上下文推理成本。真正的门槛不在于把 Transformer 堆得更大，而在于证明单模型在真实流量、真实延迟和真实故障条件下仍然比级联系统更划算。

截至 2026 年 10 月 5 日，Sona 的结论应当被理解为一次强有力的生产实验，而不是推荐架构的终局答案。它已经证明：在音乐推荐中，一个设计得当的 Transformer 可以在 A/B 测试里接管 15 多个候选生成器以及后续预排序、排序环节，并且同时改善核心参与度指标。下一步要看的，是它能否从实验流量走向全量生产，以及这套方法能否迁移到行为更稀疏、约束更多的推荐场景。

参考来源

• Reddit：Sona: one transformer replaced our 15+ candidate generators, pre-ranker and ranker in an A/B test：Yandex Music 相关团队发布的项目介绍与技术讨论入口，包含在线实验、历史压缩和生产替换范围等信息。
• Sona Technical Report，arXiv:2608.11015v2：Sona 的技术报告，系统介绍单模型生成式推荐架构、Decoder、Ranking Module、训练目标和在线 A/B 实验。受本文参考链接域名限制，正文不附 arXiv 外链。