导读：本⽂主要是分享蜻蜓FM最近⼏年在推荐系统中的发展和演进，从离线推荐逐步过渡到实时推荐后，作者在实际开发⼯作中，⾯对⼀些痛点和难点时，是如何进⾏思考和解决的，如何更好的将⾃⼰的业务场景特点和算法模型进⾏结合，深度理解⽤户⾏为和业务场景，优化⽤户收听体验，以及提升流量分发效率所做出的努⼒和尝试，推动特征⼯程和算法模型的微服务化，特别是最近两年全公司算法相关业务开始逐步All In深度学习后，如何⼀步步打造出业内领先的推荐系统。

01

背景简介

1. 关于我们

蜻蜓FM——中国移动互联⽹⾳频的领跑者, 国内⾸家⾳频媒体平台，以敏锐独到的视⻆传播世界的声⾳业内⾸创PUGC专业主播⽣态，打造品质感的⾳频内容体系上架10年，突破4.5亿⽤户，⽣态流量⽉活跃⽤户量1.3亿。

2. 推荐业务场景

⽬前推荐场景分布⾸⻚feeds流，超级会员⻚猜你喜欢、频道⻚feeds流，我听⻚猜你喜欢等多种场景，涵盖专辑、节⽬、听单、直播间等多种形态。

推荐系统是帮助⽤户可以⾼效率的找到⾃⼰感兴趣的内容，在我们的推荐场景的定位是帮助⽤户更快更好的发现新的内容，⽽且保证千⼈千⾯，⽤户在平台在追的专辑回溯源头基本是发⽣在⾸⻚feeds, ⾸⻚feeds承接着平台绝大部分的流量，所以⾸⻚feeds推荐系统的好坏⾄关重要，蜻蜓FM推荐系统经过⼏年的⼯程和算法不断迭代和更新，推荐⾸⻚样式从固定模块推荐变为feeds流推荐，推荐效率逐渐完成了从天级别的离线推荐、到分钟级别的近实时推荐和ms级别的实时推荐的转变，召回策略也逐渐从常规个性化模型到深度召回模型进⾏转变，排序模型也从树模型替换为复杂的深度学习模型，并在线上取得了⼤幅的指标的提升。

什么是⼀个好的实时推荐系统，应该⾄少满⾜以下四点：

• 架构既能处理海量数据，⼜能及时响应⽤户交互；

• 快速迭代推荐策略、算法；

• 优雅降级，即使在服务出现问题的时候，也能推荐出个性化的结果；

• 及时、准确、全⾯的记录⽤户反馈。

我们整个推荐系统由主要有四个部分组成，包括offline层，Pipeline层、Online层，业务层，其中业务层包括多个推荐场景，其中⼤部分场景使⽤的是同⼀套推荐框架，如何快速⾼效地迁移部署到其他推荐场景，是我们需要考虑的问题，每层各司其职，如何保证各⾃任务的稳定性以及保证推荐系统的实时性是⾄关重要的。

• ⼀个是如何实时获取⽤户的实时兴趣⾮常关键，⽤户通过与app发⽣交互，产⽣⼀些播放、收藏、搜索点击等隐式⾏为，从算法的⻆度准确计算出⽤户的实时兴趣，及时推荐相关内容，满⾜⽤户需求，从⽽可以让⽤户停留在平台更多时间，产⽣沉浸式的体验；

• 第⼆个是要从架构上要满⾜实时性的性能要求，从⽤户触发推荐-召回-粗排-精排-重排，每个环节都需要保证短时间内在推荐链路⽣成推荐结果，以及保证架构的稳定性，特别是精排和重排环节，是最后展现内容给⽤户的环节，实时性必须保证在ms级别，⽽模型越好，往往模型越复杂，模型复杂，往往会带来线上性能压⼒，但是好的模型，线上提升指标是巨⼤的。

04

召回层回顾

在传统的实时推荐系统中，存在着⼀个级联结构，在我们的推荐场景下包括专辑池、召回、精排、重排四个模块，他们像是⼀个漏⽃⼀样不断筛选出⽤户感兴趣的专辑，其中召回模块是⽐较重要的⼀个模块，它是通过⼀些算法策略从⼗万量级的专辑池筛选出数百量级的⽤户感兴趣的专辑投⼊到精排进⾏排序，通过减⼩专辑的量级，从⽽减轻线上排序服务性能的压⼒。

召回层⼀般有多路召回融合⽽成，需要同时兼顾热度、覆盖度、相关度和新鲜度，还需要基于对业务的理解，获取⽤户的⻓短期的兴趣，按照演变过程分为常规个性化召回策略和深度个性化召回策略，常规个性化召回策略是指通⽤的，模型较为简单的，可以通过并⾏化计算得到结果的策略，⽽深度个性化召回策略需要借助深度学习复杂模型和GPU平台，以及浅层神经⽹络、GNN, Attention, GraphEmbedding，⽂本语义等模型框架，获取到的模型化Embedding结果的策略，这些策略相⽐传统的个性化策略来说，具有更强的表征能⼒和泛化能⼒。蜻蜓FM推荐系统通过最近两年的迭代，逐渐从常规的CF、ALS等召回策略逐步过渡到EGES、SRGNN，DSSM等深度召回模型框架，不但极⼤地丰富了我们的召回来源，⽽且也从多个维度更好挖掘出⽤户的兴趣。

我们之前的召回⽅案路线是根据⽤户的⻓短期兴趣、热度、标签等开发多路召回策略，根据各个召回策略在线上的表现优劣分为不同的优先级，然后以集合（topK）为建模⽬标，按照优先级进⾏多路召回的融合，这种⽅法的优点是速度快、算⼒⼩，缺点也很明显，从10万量级到数百量级，这样的筛选漏⽃过⼤，带来的信息损失也⽐较⼤，⽽且我们所有融合的策略都是基于⼀些⼈⼯经验进⾏主导，从⽽会导致召回的准确率的不⾜。

难点和挑战：

如何提升召回阶段的准确率⼀直是⼀个难点，也是我们需要解决的问题。

05

粗排层回顾

⾯对召回阶段的挑战，这边我们的解决思路是在召回模块和精排模块添加⼀个名叫粗排的模块，我们的⽬的是通过模型代替⼈⼯经验进⾏筛选，从⽽带来准确率提升，粗排模块我们采⽤的是根据DSSM深度学习模型进⾏改进的双塔模型，其中它的⽹络特点是整个⽹络结构是由⽤户塔和物品塔组成，每个塔都有各⾃输⼊特征和⽹络结构，然后通过最后⼀层输出固定维度的embedding向量，然后进⾏内积计算，在线上部署时，我们可以将相对静态的专辑embedding向量异步写⼊到向量索引库⾥，通过线上实时获取相对动态的⽤户embedding向量，然后从专辑向量索引库中召回topK的相关专辑列表。

它的优点有很多：

• ⽤户塔和专辑塔结构是解耦的，他们在最后进⾏内积计算之前没有模型结构的交叉；

• ⽽且内积计算相关算⼒较⼩，部署线上后，性能得到保证；

• 我们可以添加⾃定义⽹络结构，增强泛化能⼒；

• 也可以通过加⼊⽤户实时⾏为序列特征，获取⽤户的实时兴趣；

• 也可以获得⼀定程度的排序能⼒，因为训练的时候使⽤了部分曝光未播放的样本，从⽽具有⼀定程度的排序能⼒，表达能⼒强。

线上收益：

模型部署到我们⾸⻚feeds个性推荐后，带来了⽐较⼤的指标提升，其中⼀级指标，包括⽤户⼈均收听提升了5.44%，有效UV-PTR提升了 3.26%，⼆级指标包括⼈均点击次数、ItemCTR，会员专辑UV-PTR、PV-PTR也带来了不同程度的提升。

难点和挑战：

双塔模型的解耦的模型特点导致了它⽆法更好地使⽤⽤户和物品的交叉特征，从⽽限制了它的泛化和表达能⼒，接下来计划尝试的解决⽅案有：

• 借鉴模型蒸馏的思想，将精排的模型训练时产⽣的预测结果部分代⼊到双塔训练过程中，将精排模型良好的泛化能⼒迁移到双塔；

• 拓宽双塔模型的宽度，当前的双塔模型是由多层的MLP组成，可以在同⼀层上⾯添加DCN，Self-attention等具有⾼阶特征交叉能⼒的模型结构，由单塔的MLP变为多塔，并在最后⼀层设置动态权重，从⽽达到增加泛化和表达能⼒的⽬的。

06

排序层回顾

上线基于DeepFM的深度学习排序模型：

最近两年我们的线上排序主⼒模型⼀直是Xgboost模型，它具有特征⼯程简单，效果优秀，⽀持并⾏训练，跨语⾔跨平台部署的优点，我们在Xgboost的基础上，迭代了⼏版，在线上指标也取得了很⼤提升，但是呢，随着特征维度变得越来越⼤，模型也变得越来越复杂，以及随着我们推荐场景的不断丰富，需要在线预测的地⽅越来越多，在线预测的性能压⼒变得越来越⼤，性能优化的成本与我们线上获得的收益不再是成正⽐的关系，线上性能越来越成为我们的瓶颈，这时我们急需⼀种新的模型框架进⾏替代。

新模型替换XGboost同样⾯临着不同的困难与挑战：

• 新的模型框架意味着之前开发xg所积累的经验不再可⽤，需要从头进⾏数据基础设施建设，意味着成本问题；

• 这同样也意味着⻛险，因为XG模型迭代了多个版本，⽬前效果也达到了相对最优，新模型可能有达不到⽬前效果的⻛险；

• 在保证效果的同时，同样还需要满⾜严苛的线上性能要求，也就是效果与性能之间需要进⾏trade-off。

通过⼀段时间的调研，我们决定采⽤deepFM深度学习排序模型，它是2017年华为诺亚⽅⾈实验室和哈⼯⼤共同推出的算法模型，⽬前已经成功应⽤在各⼤⼀线互联⽹的推荐系统中，业界有⽐较多的成熟经验参考，deepFM整个算法框架主要分为两个部分组成，其中FM部分可以理解为⼀个浅层的神经⽹络层，它具有⼀定特征交叉的能⼒，它使模型具有⼀定的记忆能⼒，DNN部分可以使特征进⾏更⾼维度的交叉，这使得模型具有⼀定的泛化能⼒，不但可以⼀定程度减⼩⼈⼯特征挖掘的⼯作量，⽽且这两部分的Embedding⽹络层是共享的，这就⼤⼤减⼩了模型的复杂度，它更擅⻓处理⼤规模的ID类稀疏特征，像我们⼏⼗万个的专辑ID，其实也可以作为⼀种特征加⼊模型中进⾏训练，这些都是deepFM⽐xgboost有优势的地⽅。⽽且我们也同时做了其他⽅⾯的优化的尝试：

• 重新定制了多种适配deepFM的特征库；

• 我们前期利⽤Spark Streaming实时计算框架开发定制了多种实时动态序列特征，可以更好的捕获⽤户的实时兴趣；

• 我们把特征⼯程和预测服务做成了统⼀的API接⼝供外部调⽤，并部署到我们的容器云平台；

• 在上线前，我们多次进⾏代码优化，模型结构的简化，在保证训练效果的同时，尽量减⼩模型复杂度，同时我们还在线下多次进⾏的线上真实场景的模拟压测，我们平均rt时间控制在30ms左右，基本满⾜我们的性能要求。

线上收益：

我们把新模型部署在了多个推荐场景，其中⾸⻚feeds的个性推荐场景，⼀级指标⽤户收听时⻓提升10.94%，有效UV-PTR提升9.26%，有效收听ItemPTR提升7.83%，其中⼆级指标也得到很⼤提升。

同时我们也把deepFM部署在⾸⻚的投放场景和频道⻚的推荐场景，可以看到上线前和上线后的指标的提升幅度都很⼤。

07

节⽬推荐上线

为了探索推荐系统更多的可能性，我们进⾏了节⽬推荐第⼀期的探索，⽬的是挖掘触发推荐时进⾏节⽬⾼效率召回的⽅式，包括节⽬对节⽬，节⽬对专辑，专辑对节⽬的相互影响和发现。

节⽬召回：

针对节⽬推荐的特点，⽬前我们已经开发了以下⼏种召回策略：

• 基于GraphEmbedding的EGES向量相似召回策略：针对⼀般的Word2vec的embedding⽅法⽆法对⽤户顺播节⽬序列准确获取节⽬向量，以及新上线的节⽬⽆法获取embedding的冷启动问题，采取了基于EGES的图的embedding训练⽅法，在节⽬ID的基础上，获取类别ID、tagID等多维度的Side-Information，通过DeepWalk的随机游⾛采样⽅法以及Skip-gram的模型训练⽅法，准确⾼效获取节⽬的embedding结果，在缓解新节⽬上线的冷启动以及中⻓尾节⽬的覆盖度问题上，效果有了很⼤提升。

• 基于Bert的语义相似召回策略（覆盖节⽬3万左右，可作为补充策略）：基于业界先进的Bert⾃然语⾔预训练模型，提取各个节⽬标题的⽂本向量，借助近似近邻搜索框架faiss，为每个节⽬标题匹配最相似的topK的相关节⽬，利⽤⽂本多分类的下游任务进⾏微调，使提取的节⽬标题语义向量更加准确，使效果进⼀步提升。

• 基于⼆级分类的热播节⽬召回策略（时间窗⼝2周）, 兼顾热度和时间衰减。

• 追更策略：作为每⽇强插策略与当前节⽬召回进⾏融合, 通过计算出⽤户有追更状态的专辑，向⽤户推荐新上线的节⽬。

线上收益：

同时线上我们进⾏了专辑和节⽬的不同形式的穿插，以及如何⾼效过滤, 节⽬推荐样式的AB实验, 最终取得了第⼀阶段不错的收益，其中专辑+节⽬的整体收益中，⼀级指标包括⼈均收听时⻓提升了5%、有效收听UVPTR提升了7%，其他指标均得到了⼤幅度的提升。

改进⽅向：

当前专辑召回和节⽬召回都是各⾃独⽴构建同构图，最终⽣成Embedding向量，后⾯会考虑将专辑和节⽬表征到同⼀个向量空间，⽤Metapath2vec的⽅法共同构成异构图，基于元路径指导图上节点的游⾛，采样出序列后，经过skip-gram⽣成Metapath语义下的表征，最后对表征做⼀个融合，得到节点的最终表征。

节⽬排序上线MMoE：

最近我们通过分析发现，⽤户的⼈均收听时⻓，专辑完播率，收藏专辑次数和⽤户留存率成正相关的关系，这些隐式⾏为在⼀定程度上影响着⽤户的留存，我们⽬前的建模是单⽬标的预测，⽬标是通过直接提升PTR，来间接提升⽤户收听时⻓，这⾥有个问题就是假如只关注专辑是否播放，那么⽤户播放后，可能会发现不喜欢或者专辑质量差，觉得体验太差，⽤户可能流失，也有可能⽤户很喜欢，愿意加⼊收藏，等有时间接着听，间接增加⽤户粘性和回访率，所以我们在提⾼PTR的同时，还需要提升专辑的收藏转化率，这不但可以增加留存，还可以间接的推荐⾼质量的专辑给⽤户，提升⽤户体验。

同样的这也适⽤于节⽬排序，⼆期我们开发了基于MMOE的多⽬标排序，其中以是否播放和是否完播作为我们的前期的预测⽬标，MMOE 相⽐ESMM这种基于Shared-bottom的模型，不同任务的gating networks可以学习到不同的组合experts的模式，捕捉到不同任务的相关性和区别，可以减⼩受到任务差异和数据分布带来的影响，所以MMoE作为我们⾸选的多⽬标排序模型。

这边我们选择了三个Expert⽹络，可以看到不同Label对于不同的Expert的依赖程度是不⼀样的，⽬前来看，两个task通过Gate⽹络，分别获取了对不同expert⽹络的权重，其中Label1对expert2的依赖更⼤，Label2对expert1的依赖更⼤。

线上收益：

在⾸⻚feeds上线⼀个⽉后，在专辑+节⽬的全局流量的⼀级指标中，包括UV-PTR和⼈均播放时⻓提升在3%左右。

改进⽅向：

• MMoE的⼀期特征中，⽬前只添加了30多维的特征，后期会挖掘更多的⾼效特征，包括交叉特征、序列特征等。

• MMoE的⽹络结构中底层使⽤的简单的Embedding层concat的形式，后期会尝试参考DIN，DeepFM对现有的⽹络结构进⾏升级改造并融合Attention，FM的⽹络结构，增强泛化能⼒。

• 当前⽬标是包括是否播放，是否完播的两个⽬标，后期会融⼊是否收藏、评论、下载等多个⽬标。

• 后期会尝试使⽤PLE的多⽬标排序的新模型，相⽐MMoE的优点是消除了task tower network和其他任务的task-specific experts的联系，可以使得不同类型的experts进⾏各⾃更专注的学习，不互相⼲扰。

• MMOE离线训练时，各task之间的loss的收敛速度和⼤⼩可能不同，⽐如分类问题和回归问题，需要有机制可以在训练时动态调整各loss的权重，⽐如GradNorm。

• MMOE部署上线时，各task的预测分值需要分别乘以对应的权重，获得最终分值之后进⾏排序，⽬前有加法融合和乘法融合两种⽅法，当前我们使⽤的是加法融合，也可以通过⻉叶斯优化的⽅法进⾏最优权重的寻找。

08

重排层回顾

排序模型⼀般是按照point-wise的⽅式进⾏训练，很容易造成相似内容扎堆的现象，考虑到提升⽤户体验和内容多样性，我们也同时尝试了⼏种提升多样性的⽅法和策略：

1. 动态刷新

⽬前feeds个性化推荐结果，在⽤户没有产⽣触发推荐⾏为的时候，理论上⽤户的整个推荐结果是不会产⽣变化的，从数据来看，大部分⽤户停留在前3⻚，所以⽤户在触发推荐之前，多次触达⾸⻚，看到的内容可能是⼀样的，这时推荐多样性就会大打折扣，简单粗暴的对曝光过的专辑进⾏过滤，可能会过滤⼀些产⽣⽆效曝光的专辑，⽽且过滤⼒度过⼤，还会造成没有优质专辑可推的局⾯。

我们的⽬的是保证⽤户没有触发推荐的期间，每次打开⾸⻚feeds，推荐结果都有⼀些变化，⼀定程度解决内容多样性的问题。

在重排层加⼊动态刷新机制，在召回集基本不变的前提下，优先考虑在集合内部的排序上进⾏动态调整，也就是在排序打分的基础上除以⼀个降权系数weight，曝光次数较多的专辑，重排时后移，引⼊时间衰减，近期曝光的专辑更快后移，远期曝光的专辑回归到正常序列。

2. MMR

MMR是⼀种近似的贪⼼算法，全称是最⼤边缘相关模型（Maximal Marginal Relevance），第⼀个Sim代表是某个专辑的rank score，第⼆个Sim代表该专辑与⽣成的结果集中专辑的相似度，λ越⼤，越接近原始的排序结果，λ越⼩，越强调多样性。

同时，我们在计算结果和⼯程效率上也做了部分优化，⼀个是mmr是基于多轮迭代的策略，候选集个数越多，计算量越⼤，所以我们只选择rank score在固定topK的候选集进⾏了mmr的计算，做了计算效率和多样性效果的trade-off，还有⼀个是为了突出⽤户兴趣的实时性，我们对个别候选集进⾏了乘以rate系数的加权操作，将部分候选集进⾏多样性打散后可以排在最前⾯。

3. DPP

⾏列式点过程(Determinantal Point Process, DPP),  是⼀种基于⾏列式点过程的提升推荐多样性的算法，并使⽤贪⼼算法推理最优的⾏列式点过程，并利⽤Cholesky加速⾏列式点过程的推理，我们使⽤已计算好的word2vec的16维的embedding向量进⾏核矩阵的构建，并做了部分⼯程上的优化。

线上收益：

经过⼀段时间的ABtest，我们发现加权的MMR线上效果最好，它可以保证在其他转化指标不下降的情况下，提升多样性指标包括⼈均曝光⼀级类⽬、⼆级类⽬个数，均提升在10%以上。

改进点：

接下来会考虑使⽤list-wise的思路，从整体推荐列表的物品顺序的⻆度进⾏考虑，融合当前物品上下⽂信息，也就是列表其他物品的特征信息，利⽤RNN或者Transformer对每个输⼊对应位置经过特征融合，按照新预测的得分重新对物品排序，从⽽获得整体列表的最⼤收益。

09

推动特征⼯程与算法模型的微服务化

在通常的算法开发⼯作中，需要我们有快速迭代，快速试错的能⼒，然⽽在以往的我们模型开发部署的过程中，我们经常会遇到部署效率的问题，原因是我们线上⼀般会同时部署多个模型多个版本进⾏ABtest，每开发⼀个新的排序模型，后端同学都需要把离线的特征拼接环节在线上进⾏复现⼀遍，其中我们的离线训练是scala语⾔开发，线上是go语⾔开发，在这种跨语⾔跨平台的场景下，特征拼接极易出现线上线下不⼀致的问题，出现问题需要⼈⼯review逐步排查，费事费⼒不说，定位问题也⽐较困难，同时迁移部署到其他推荐场景时，还要徒增重复代码，不但部署效率⼤⼤减低，⽽且还增加了出现问题的概率和隐患。

同样的，解决这个问题会遇到⼀些困难和挑战：

• 如何省去⼈⼯⽐对特征拼接结果的过程，并保证特征⼯程线上线下⼀致性；

• 如何进⾏特征⼯程和模型的多版本部署、多模型扩展和热加载；

• 如何可以提升部署效率、快速迁移部署到其他推荐场景。

解决⽅案：

• ⾸先我们进⾏了特征⼯程配置化处理，我们把每个版本的对应特征处理的配置⽂件存⼊到redis中，并分别制定stg和prd流程，⽅便stg线下测试后，线上部署prd环境；

• 通过配置中⼼实现多场景、多版本、多模型的统⼀部署和管理，通过配置中⼼可以控制读取不同类型不同版本的模型⽂件路径，读取对应版本的特征⼯程配置⽂件，⽅便进⾏⼀键部署和版本回退；

• 将多特征数据来源读取、特征在线拼接、模型预测服务封装成统⼀的API接⼝，统⼀⽤scala的语⾔框架实现，从⽽保证了离线训练特征拼接和线上特征拼接的⼀致性；

• 将这个服务框架开发成端到端的微服务框架，部署到容器云平台进⾏统⼀管理，⽅便多场景迁移部署，后端通过发送deviceID，recallSet，modelType以及modelVersion就可以很⽅便的获取⽤户最后的专辑推荐列表。

线上收益：

• 线上部署模型效率值的提升，5个工作日缩短至半个工作日；

• 模型从离线训练到部署上线周期，数月缩短至数周；

• 提高模型快速迭代、快速试错的能力；

• ‍‍整‍个框架已在上海算法平台进行推广，现已成功应用在推荐、搜索的多个推荐场景。

10

总结和展望

蜻蜓FM作为国内⾳频内容领域top级别的产品，推荐系统始终扮演着重要⻆⾊，我们也始终关注着推荐领域相关算法的前沿动态，并结合我们对于业务的深刻理解，从算法和⼯程⻆度出发，不断进⾏摸索和实践，并且取得了不错的效果, 希望能给相关从业的同学以思考和启发，同时也让我们挖掘出很多改进的点，接下来我们也会从如何保证推荐系统的实时性、提⾼推荐内容的多样性，保证推荐内容质量、以及提升⽤户对推荐内容的满意度，提升⽤户留存等⼏个⽅向出发，不断完善我们推荐系统和内容⽣态，以期为⽤户带来更好的收听体验。

在文末分享、点赞、在看，给个3连击呗~

分享嘉宾：

活动推荐：

社群推荐：

关于我们：

🧐分享、点赞、在看，给个3连击呗！👇