Yandex Sona：单个Transformer取代15+推荐组件的工程实践

Yandex Music的研究团队公布了一项颇具野心的推荐系统实验：用单个Transformer模型，取代了生产环境中15个以上的候选生成器、预排序模型以及排序模型。这个名为Sona的模型在A/B测试中跑出了正向结果，为生成式推荐系统落地提供了新的参考样本。

从多组件管道到单一模型

传统推荐系统通常是一条复杂的流水线。以Yandex Music为例，其生产环境拥有15个以上的候选生成器（candidate generators），这些生成器向预排序（pre-ranking）和排序（ranking）模型输送数百个特征，层层筛选后才得出最终推荐结果。这种架构的优点是各组件职责清晰、可独立优化，但维护成本高、组件间协调复杂。

LLM的兴起改变了这一思路。团队指出，大语言模型证明了单个端到端模型能够接管原本由多个专用组件分担的工作，而生成式推荐（generative recommender）已经把这套方法论带入了生产环境。Sona正是在音乐推荐场景下对"单模型推荐"的一次完整探索——用一个Transformer消化掉整条流水线。

需要明确的是，Sona目前尚未全量上线，仍处于实验验证阶段，但其A/B测试结果已经足够引起业内关注。

History Compression：长序列建模的成本权衡

Sona的核心能力之一是能够读取多达8,192个用户行为事件。对如此长的序列做全注意力（full attention）计算代价高昂，这是长序列建模绕不开的性能瓶颈。

团队为此设计了称为"History Compression"（历史压缩）的机制，大致将推理成本降低了一半。具体做法是把用户历史切分为两段：较早的6,144个事件和最近的2,048个事件。

两段历史如何交互

这两个数据块之间通过两种方式交换信息：一是交叉注意力（cross-attention），二是一层覆盖完整历史的自注意力（self-attention）层。完成信息交换后，后续的7层Transformer堆栈只在最近的2,048个事件上运行。

这种设计的巧妙之处在于，它在大幅削减计算量的同时，保留了全注意力的大部分质量表现——较早的历史事件依然对解码器（decoder）和排序模块（Ranking Module）可见。换句话说，模型没有因为压缩而"遗忘"用户的长期偏好。论文的Table 7.7给出了全注意力与History Compression的完整消融实验对比。

编码器复用与候选生成流程

Sona在架构上还有一个关键的效率优化：解码器和排序模块读取的是同一份编码器（encoder）输出，因此每个请求只需运行一次编码器。这避免了重复计算，是支撑单模型方案在生产环境可行的重要工程细节。

候选项的生成走的是束搜索（beam search）路径，产出形式为语义ID（Semantic IDs），随后立即进行打分。整个"召回—排序"的过程被整合进了同一个模型的前向传播中，取代了过去需要多个独立系统串联的复杂管道。

语义ID（Semantic IDs）是生成式推荐系统中的核心表示方法，值得专门解释。与传统推荐系统直接使用物品的原始ID（如歌曲数据库主键）不同，语义ID是通过层次化量化（如RQ-VAE，残差量化变分自编码器）将物品的内容特征或协同过滤嵌入压缩为一组离散的码字序列。例如，一首歌曲可能被编码为[42, 17, 8]这样的token序列，这些token能够捕捉物品之间的语义相似性——内容相近的歌曲会拥有共享前缀。这一设计使得Transformer可以像生成文本一样"生成"推荐物品，束搜索则在这个离散token空间中高效探索候选集。语义ID方案的关键优势在于，模型能够泛化到训练中出现频率较低的长尾物品，因为它们与热门物品共享部分码字，而非依赖高频曝光才能学到有效表示。

A/B测试结果与待解问题

Sona的最终A/B测试在Yandex Music的智能音箱场景下进行，持续7天，每个实验组覆盖15%的用户。结果相当亮眼：

• 活跃用户数（Active Users）提升 +4.53%
• 总收听时长（Total Listening Time）提升 +6.30%

两项指标相对生产环境对照组均达到 p < 0.01 的显著性水平。对于一个意图替换整条成熟流水线的新架构而言，能在核心业务指标上取得这样的正向收益，说明单模型路线确实具备实战竞争力。

目录覆盖率的隐忧

结果并非完美。团队坦承，Sona的目录覆盖率（catalog coverage）低于现有生产技术栈。这意味着模型可能倾向于推荐热门内容，而对长尾曲目的触达不足——这是推荐系统中探索与利用平衡的经典难题。团队表示正在调查覆盖率下降的原因。

目前一项长期A/B测试正在进行中，这将进一步检验Sona在更长时间维度上的稳定性和实际价值。

目录覆盖率（catalog coverage）是衡量推荐系统多样性的重要指标，定义为系统实际推荐过的独立物品数量占全量可推荐物品的比例。覆盖率低意味着推荐流量高度集中于少数热门内容，形成所谓的"马太效应"——流行的越来越流行，长尾内容几乎得不到曝光机会。对音乐平台而言，这不仅影响用户发现新内容的体验，也直接损害平台与独立艺人、小众厂牌的商业关系。生成式模型在这一维度天然存在劣势：训练数据中高频物品的语义ID被更充分地优化，模型在束搜索时倾向于选择概率更高的热门路径。缓解这一问题的常见手段包括在解码阶段引入多样性惩罚项、对长尾物品的语义ID进行上采样训练，以及在排序阶段显式加入覆盖率约束，但这些方法往往与点击率等即时指标存在取舍。

对推荐系统工程的启示

Sona案例的意义不仅在于指标提升，更在于它验证了一条可能的技术演进路径：用生成式单模型统一传统推荐流水线。这与LLM时代"用一个大模型替代多个专用模型"的整体趋势一脉相承。

对工程团队而言，单模型方案意味着更低的系统维护复杂度和更一致的优化目标，但也带来了新的挑战——如何在长序列建模中控制推理成本、如何保证内容覆盖的多样性。History Compression和编码器复用展示了在成本可控前提下落地长序列生成式推荐的可行工程手段。

这项工作的完整细节已在arXiv论文（arxiv.org/abs/2608.11015）中公开，感兴趣的读者可查阅Table 7.7等消融实验获取更多技术细节。