多场景建模是一项与业务紧密结合的算法优化工作，其核心在于思考如何处理多个业务场景之间的差异性和共性。

云音乐的核心场景包括每日推荐，每天更新 30 首歌曲，以列表形式呈现；还有流式推荐、实时更新，和每日推荐一样都是直接为用户推荐歌曲；此外还有歌单推荐，包括推荐歌单以及 MGC 歌单。

这些场景特点各异，旨在满足用户不同的个性化推荐需求。可以看到，在过去一段时间，这些场景一直由专人专项持续优化。这样做的优点是能使模型更贴合业务场景和特点，充分发挥模型效果，提升场景忠实用户的体验。

这种做法也存在弊端。其一，长期专人专项优化可能导致技术栈出现较大差异；其二，技术共享和共建节奏会被拖慢。

我们面临的挑战不仅是要承接越来越多新的场景，满足更多用户个性化音乐诉求并带来增量，同时还要思考如何更好地承接和持续优化这些新场景。

开展多场景工作的目标主要有两个：一是用一个模型服务所有推荐场景，取得更好的效果，联合建模用户在任意场景消费后产生的数据，精准建模用户真正感兴趣的底层兴趣表征；二是用一个模型服务所有场景，有效降低机器成本和人力成本，提升研发效率，促进技术共建达到更高水平。

第一个难点是双跷跷板问题，由多任务跷跷板和多场景跷跷板构成，两者耦合时平衡难度加大。另一个难点，可用西方故事“格力娅如何战胜大卫”来描述，即如何用一个通用的大模型打败每个场景专有的小模型，其中难点众多，将在后续介绍中详细阐述。

此次虽主要谈及算法层面的多场景建模，但更重要的是，在算法层面之外，我们对从数据层到场景层再到顶层任务的整个系统框架进行了统一构建，摒弃了原先零散、不统一、不规范的技术及相应数据等，在此基础上构建了统一的模型架构。

此架构与业界现有的多场景建模整体架构差异不大，但其中融入了音乐场景特有的业务特点以及我们的思考。例如，针对音乐推荐中老歌持续被消费这一强业务特点，我们做了很多长期多兴趣的表征，并与即时性交叉且进行动态更新。同时，我们希望将业务背后沉淀的音乐、公寓知识传递到更顶层，服务于水面之上的多个业务场景。

整体架构可以概述为三个关键词：自底向上、求同存异和去伪存真。求同存异是此次分享中最想强调的点，因为多场景工作更多是如何以最小代价固化沉淀真正有价值的共性部分，同时以快速敏捷的方式保留差异部分，两者有机结合才能完成多场景统一大模型的建设。

在参考了业界众多已有的多场景建模工作后，我们完成了整体架构的设计。对重要区域进行了分色块标记，方便理解。例如，底层有蓝色和黄色色块，总体遵循公私域分离设计结构。在公域部分，抽取多个场景共享的特征和表达，黄色部分则更多是场景特有的东西。可以看到图中有多个紫塔并联，每个紫塔代表一个场景特有的知识。在其之上是常见的 MMOE 架构，用于多个场景不同目标的多任务学习辅助。

公域更多表达的是业务场景共有的特性、用户公共的兴趣或其长短期兴趣中不变的部分。那么求同如何实现？这更多考验算法工程师面对零散业务特性和不同逻辑时，如何提取公约数。这里分享四个要点：一是通用的输入结构；二是特征的最大公约数；三是共享共建；四是轻量高效。共享共建和轻量高效可能基于团队文化，强制要求做到更好以服务大模型。在算法层面，更强调保留公共核心特征。这里也列举了一些核心点，比如通过消融实验找出并保留必要核心特征，能砍则砍，尽量减轻构建大模型前的负担。

基于此思考，我们进行了多次迭代，并及时基于 AB 测试分析以验证公域架构设计的有效性。将用户按活跃等级分为 0 - 10 级共 11 个档次，0 级用户最不活跃，10 级最活跃。从图中可以看出，横轴是各人群对应的提升幅度，0 - 3 级提升幅度明显最大。此数据旨在论证，通过良好的公域结构设计，能有效表达并沉淀用户特征，使低活用户受益更多。

公域工作相对基础，而私域则较为复杂。私域的核心点在于保留每个场景最特殊、最有价值的部分特征，强调参数隔离、梯度隔离，每个塔相互不干扰，输入特征完全不同。这些特征来源于每个场景特有的特性挖掘，例如某业务场景的封面特征或流式场景基于用户实时反馈产生的信号等。

为应对私有场景差异大的问题，设计了 SEN 场景私有网络这一通用逻辑，便于接入新场景和合并老场景时提高复用率和整体迭代效率。求同存异中的求同主要是针对公域网络设计，而存异则是针对私域网络设计，主要体现在：一是私有场景的私有特征是不对齐的；二是某些私有特征很重要但易过拟合；三是存在分布漂移问题。我们参考了 Transformer 类的一些设计，进行组合，来解决这些问题。

接着是双跷跷板问题中的多任务跷跷板，下图中列举了几个核心场景及其面临的任务。

基于场景特有任务，我们设计了 task master 逻辑。对于有任务的场景保留梯度，对于无任务的场景通过 subgradient 方式停止梯度，避免影响对应 SEN 网络的学习。这保证了多场景、多梯度之间，场景与场景、任务与任务以及场景对应特有任务之间尽可能隔离。

在音乐推荐场景中，用户行为序列特别是长期行为序列非常重要，引入 LSTM 加 session 切分提取用户长期兴趣特征曾带来显著提升，但此特征和对应的网络结构对模型消耗大。在迭代多场景、多任务统一大模型时，我们找到了一个相对更轻量化的方式，即层次 attention 网络。

从数据对比来看，虽然层次 attention 在某个核心指标上有轻微负向，但从全局来看是一种权衡，牺牲局部小收益换取未来全局更大的收益，提升了整体的迭代效率。

模型上线后效果显著，核心推荐场景红心率提升 10% 以上，众多小场景核心指标提升 15% 以上，直接带动次留相对提升 1%。模型还落地到网易集团其他业务，新客绝对值提升 0.2%，次留绝对值提升 0.2%。同时，模型上线后替换了原有的零散和不统一的技术栈，整体效率也有所提升，并节省了资源消耗。

在现有整体模型统一的基础上，我们希望将模型进一步复杂化，服务于网易云音乐更多业务线，不仅限于音乐推荐，还包括播客、直播等，以各种合作的形式发挥模型最大效果。

Q1：新模型可以加入新的域和任务吗？

A1：可以，场景的私域网络 SEN 中，一个网络对应一个场景，新增场景只需在私有网络增加对应的塔，较为灵活。

Q2：里面迭代 5 次是指一周推选 5 次吗？

A2：并非如此，是指离线完整训练模型尝试新方向，离线训练效率提升使得迭代速度加快。

Q3：统一模型较大，多人在模型上迭代是否会有冲突或效率降低？

A3：目前的做法是预先区分好迭代方向，不同同学负责重叠度最低的方向，且因同学负责业务不同，重叠性进一步降低。虽干扰减少，但也存在问题，如因他人工作提升加入新点，个人收益可能不如单独 AB 时多。此时强调增量 AB，大量 DIFF 比较。这是当前实践，仍在思考提升合作效率的方法。

Q4：拆分私域特征的必要性如何看待？

A4：私域特征复用度低，多为场景特有且重要，建议不混用到公域侧，实践中混用效果不理想。

Q5：多场景样本是否复用？

A5：是的，所有场景样本合在一起训练，若不优化离线训练效率，训练耗时会大幅增加。

Q6：层次 attention 是将长短序融合再和短序融合吗？

A6：是的，先对长序做 attention，再和短序做 attention。

Q7：公域特征为何对不活跃用户提升大？

A7：音乐场景众多，但用户通常只用一两个功能，多场景建模能覆盖全推荐域样本，改变用户底层表达，对类似用户冷启更好，不再只适配单点场景特性。

Q8：新场景私域增量，私域训练后公域那块的场景综合所有的，如果新场景上来是直接全量训练还是增量训练？

A8：新场景上来直接全量训练，因补充新样本存在差异性，直接增量训练可能不稳定。

Q9：全量样本更新是全冷启还是热启？

Q10：上了一个私域塔，公域塔上层模型都得微调，如何影响对其他任务的评估？

A10：上了新私域塔通常直接做 AB，当前推荐域用一个实验评估，新增私域塔未观测到对其他场景的负向影响，因新增多为小场景，核心场景通常非新增量带来。

Q11：对于私域特征混用不好的效果如何看待？

A11：因差异性大，如同猪饲料给牛吃会生病。

Q12：不同场景正负样本的定义是否有差异？

A12：有差异，样本分布差异大，做实验时观测到部分场景样本量大会对其他场景产生负向影响，通过离线多次采样迭代找出较好混合比例以表征全场景用户。

Q13：不同场景量级差异大吗？

A13：较大，做采样会有信息丢失，但会保留能共同建模且对整体有收益的部分。

Q14：Loss 上有什么考虑？

A14：多任务层因 task master 设计影响较小，多场景层通过独立每个场景的子塔设计保证样本隔离。

Q15：对于 list、wise、pointwise 这些不同样本的 loss 设计，这种框架怎么设计？

A15：目前主要是 pointwise 框架，listwise 逻辑更倾向于在 pointwise 基础上做二次偏序校正，用于多任务层的偏序表达。

Q16：跨场景建模后，各场景的推荐会趋同吗？

A16：目前未出现此现象，底层召回有差异，且不同场景激活的子塔参数分布差异大。

Q17：不同场景的样本反馈延迟会不同吗？

A17：会，实时场景较快，日更场景较慢，统一做统一时间的批量处理。

Q18：上层和输出塔有分场景设计的必要吗？

A18：视业务而定，若业务中某场景某任务非常重要且对其他场景影响可控，可单独设计输出塔，目前无统一方法论。

Q19：有歌曲和视频，能做多长期建模吗？

A19：目前主要在歌曲域做多场景建模，歌曲和视频差异大，跨域建模方案更复杂。

Q20：长层次 attention 只是处理短序列吗？

A20：不是，长短序列一起处理，短序列可视为 target，长序列视为序列。

Q21：提到统一实验，如果两个体量相当的私域一个涨一个跌，如何评估？

A21：先看总量，再看私域场景涨跌情况，总量最重要。

Q22：Task mask 如何解决场景和任务之间的耦合？

A22：A 场景有 A 任务，B 场景无 A 任务，构建样本时混合 A、B 场景样本，训练 B 场景时 mask 掉 A 任务的梯度。

Q23：长序列和短序列多长？

A23：长序列有上万的长期序列和几百的中长期兴趣序列。

Q24：层次 attention 可以再讲解一下吗？

A24：短序列做 target attention 的 target，长序列做序列。

Q25：如果场景量级不同，采样大场景会丢失信息吗？如何平衡？

A25：会丢失部分信息，取决于丢失部分对整体的影响，保留能共同建模且有益的部分。

Q26：上层网络的分场景设计的思路

A26：受前辈 star 工作影响，设计理念相同，分公域和私域专家，私域为场景私有网络 SEN，每个场景有独有网络，公域设计基于用户层面的共同兴趣表达，而非场景层面。

Q27：关于任务在不同场景中转化率分布不同，用同一输出塔可能导致问题，是否有必要为每个场景的任务分别拆出输出。

A27：通过私域场景独立塔保持信息偏置，保证小场景 COPC 稳定，且梯度隔离可保证 COPC 准确，公域梯度回传基于用户公共兴趣不受场景转化率影响。