多场景多义务一致建模在网易云音乐的算法通常

多场景建模是一项与业务严密结合的算法优化上班，其外围在于思索如何处置多个业务场景之间的差同性和特性。

云音乐的外围场景包含每日介绍，每天降级 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 准确，公域梯度回传基于用户公共兴味不受场景转化率影响。