QQ 音乐推荐系统算法架构实践
分享嘉宾：Kalen QQ音乐
编辑整理：吴祺尧
出品平台：DataFunTalk
导读： QQ音乐在过去一年多的时间里有大量新的推荐功能上线，包括有声书推荐、AI歌单、快听播客、社区推荐等数十个新推荐功能。与此同时，QQ音乐中推荐的播放次数和DAU上涨迅速，从2020年至今推荐核心指标已经接近翻倍，导致请求量和数据量增大，给推荐和相关服务带来较大压力。在这样的背景下，QQ音乐在过去一段时间对推荐算法架构进行了一系列探索和实践，在这里和大家分享。
01 QQ音乐推荐架构挑战
QQ音乐整体的推荐架构面临着几个问题。首先，推荐的入口和功能的需求众多，当各个业务方搭建自己的推荐功能的时候存在大量重复建设。其次，站内的app的流量比较分散，使得入口算法优化的ROI较低。此外，因为我们的业务场景多样化，物品类型包括歌曲、视频、直播以及图文动态等, 推荐形式包括feeds流、横滑模块、电台模式、沉浸式的视频等。针对这些挑战，在推荐架构方面我们主要面临和亟需解决的问题如下:
- 在面临多类型，多场景，多终端的复杂业务下如何提升推荐功能上线落地的迭代效率?
- 如何在保证架构和组件复用能力的同时确保业务方灵活的业务需求?
- 如何在数据量和请求量快速增长的环境下满足对架构的升级需求，提供稳定服务?
团队的工作主要是从模型与平台, 数据服务架构, 推荐召回架构等多个方面着手解决上述问题.
02 模型与平台
首先介绍对召回服务和排序服务中的机器学习模型的相关支持。在推荐服务当中，召回和排序是最基础的步骤，而其中比较重要的部分就包括所使用的机器学习模型。这里我们主要依赖于TME自研的机器学习平台Cube Studio。平台目前已在Github开源，有兴趣使用和共建的同学可以关注 https://github.com/tencentmusic/cube-studio。机器学习平台的一个重要定位是帮助算法、数据部门快速便捷地上线机器学习模型，降低模型的使用门槛，同时提供强大的计算能力，做到分布式训练。
TME Cube Studio是基于Kubeflow云原生机器学习平台进行二次开发，对所使用组件进行了封装，做到开箱即用。此外，我们还添加了更多应用层的功能来支持不同的业务，模型的pipeline的构建相对来说也比较简单。平台还支持可视化的建模，支持包括像VSCode或者jupyter进行交互式开发，引入了NNI框架进行AutoML模型参数自动调优，并且支持模型自助部署、热加载、多版本管理、例行更新等功能。此外，我们还支持了很多模型算法库，沉淀召回和排序的经典模型。机器学习平台的底层资源云原生化，通过Kubernetes进行环境资源隔离并可实现弹性压缩，同时平台使用VGPU进行资源虚拟化隔离，提升资源的有效利用率。
在推荐算法的机器学习模型生产的过程中，通常包括问题抽象、数据收集、数据清洗、数据分析、特征工程、模型训练、模型评估、模型部署等步骤，平台在进行相关建设的时候将这些具体步骤抽象化插件。在抽象的过程中，我们着重关注三个方面的要求。首先，我们想要使得使用门槛尽量低，业务方可以在不编写代码或者只有少量代码的情况下快速上线一个模型，并且利用平台的AutoML服务进行自动调参，大大降低工程师的工作量。第二，我们希望平台能做到灵活开发，可以帮助用户快速定制开发与集成工作，并希望能满足他们搭建特殊模型的需求。第三，平台能提供强大的计算能力，便捷地支持分布式计算，通过标准化的方式提供对外计算服务。
在提升业务上线的效率方面，平台内部预制了各种各样的算法、数据以及分布式计算插件。针对推荐领域，我们支持了常用的树模型以及如MIND、YoutubeNet、DIN、PLE等深度模型。另外，平台也支持业务方通过制作镜像的方式定制插件并安装在平台上。除了推荐之外，平台还内置了生存分析、音频识别等组件，并将它们提供给QQ音乐内部其他业务方使用。除了通过插件基于业务方标准化支持以外，平台也兼顾业务方灵活定制模型的需求。通过平台对外提供的分布式上下文管理器，业务方只需要通过简单的配置选择单机或者分布式的训练，以及所需要的对应资源，就可以通过创建Notebook自定义模型的输入输出，并自定义模型的结构。除此之外，平台集成了多机多卡，具备分布式训练的能力，并将这部分功能进行封装。用户在启动模型训练之后，平台就会从队列里读取工作项。我们使用较为频繁的是Tensorflow, 启动的是TFJob, 平台根据TFJob配置的信息运行Parameter server或者all-reduce的分布式训练方法。除此之外，我们在效率上做了一定的优化, 包括引入了Kube-batch批量调度组件优化训练集群的调度，通过让用户调节亲和度，优化整个训练集群的负载均衡。
03 数据服务架构
QQ音乐使用的数据服务平台包括用户画像、用户资产、特征平台、元数据平台等，它们主要是由平台和支持的业务功能进行区分，囊括的服务信息包括用户信息、物品信息、行为信息、统计信息、黑名单等。数据的生产服务主要依赖Spark、Kafka、MongoDB、Redis等组件。
首先看一下数据服务架构的内容架构。从内容的角度上来看，我们数据平台的基础信息主要依赖于物品信息，包括歌手、流派、语种、话题等。它涉及到的物品比较多样，包括歌曲、视频和图文。用户信息包括自然属性、偏好属性、消费画像等。在这些基础信息之上，通过用户与物品在QQ音乐内部的交互记录，结合时间戳、场景、设备等上下文信息，我们对数据进行了变换、聚合与汇总，最终沉淀成多个维度的排名信息、趋势信息、统计信息和行为信息。例如我们可以得到用户对各个业务的偏好，还有歌曲的点击率等等。我们会将这些信息录入各个数据平台并对外提供服务。
从数据处理架构来看，我们采用的是经典的Lambda架构，会根据不同的需求生成数据的Batch View以及Real Time View。Batch View主要将离线的数据通过Spark、Hive等工具进行处理生成。而Real Time View则是将实时上报的消息队列通过Flink，Spark Streaming等工具生成。通过Batch Views生成的数据灵活性较高，吞吐量较大，而Real Time View则能够带来更多的实时数据反馈。最后我们将Batch View和Real Time View的数据进行合并，根据数据功能和样式存放到服务层的不同平台，包括画像平台、标签平台等，从而对外提供服务。对于数据平台的存储选型，我们通过权衡数据量、延时、读写量以及成本等因素进行选型，使用的存储包括MongoDB，ElasticSearch，Hbase，Redis等比较经典的数据库。
接下来我们来介绍一下针对数据服务中的优化经验。在原来的计算模型中，用户画像每天需要处理百亿级别的流程，高峰时期对我们的存储和计算造成了较大压力，从而引发了较多慢查询、慢写入以及尖刺。为了缓解这些情况,在Flink处理用户流水时，我们添加了一个聚合层，通过设置秒级的时间窗口，以用户ID为粒度进行聚合与数据加工再写入存储层，可以大大降低TPS.另外, 针对数据进行压缩也很重要，包括使用protobuf序列化和Gzip压缩的手段, 极大地压缩单条数据的大小，大幅度减少了读写的数据量。在计算过程中，遇到核数较多的大任务时，我们可以适当地将多个算子组成一个算子链，这样可以使得算子链下的所有task都会在同一个线程中执行，减少了数据序列化反序列化次数以及不必要的数据交换，同时减少了上下文切换的次数, 从而带来数据处理吞吐量的提升。
04 推荐召回架构
接下来介绍一下召回服务方面的优化工作。
在QQ音乐使用的召回算法分为两大类：基于内容的召回, 基于模型的召回。基于内容的召回使用画像、标签、年龄、属性等直接进行内容匹配，基于模型的召回主要包括协同过滤、向量表示、图结构等方法。
我们推荐召回架构在音乐产品复杂的情况下需要针对多种内容、多种算法引入召回路径。但是接入新路径的开发成本相对较高，代码逻辑重复杂乱，维护以及排查比较困难。在这种挑战下，我们希望通过对召回结构整体做系统重构，对召回进行升级，降低业务接入召回路径的成本。
针对召回架构的系统重构，我们先后尝试了两种方案。一种是将召回路径进行公共逻辑的底层抽象，设计成通用的召回路径模板，业务方直接通过填充数据去实现一个新的召回。这一方案的优点是抽象简单，各个召回路径比较独立。但是当业务增加召回多样性的时候，召回路径依然会不断膨胀，管理维护困难。之后我们迁移至第二种方案，其主要是将召回的流程抽象为有向无环图的计算方式。具体地，我们将路径中每一个计算步骤，如拉取画像数据、向量召回等，抽象成一个算子作为有向无环图中的一些节点。业务方可以通过配置图的方式来配置新的召回路径，做到算子插件化的使用。这种方案的优点是抽象的粒度更加细致，重用起来更加方便，维护成本更低。
上图是整体的召回设计的架构图。业务方可以加载召回服务算法和策略的基本配置，我们的召回服务就会按照配置进行召回算法的加载。之后，DAG的调度引擎就按照设计的有向无环图算子执行包括召回候选、过滤、粗排、截断、归并等不同步骤。召回的离线部分涉及模型的训练以及评估，这些步骤主要依赖于标签检索服务、向量检索服务以及机器学习平台这几个模块。另外，我们的召回服务支持模调监控和熔断限流等，同时它也支持运营通过配置池子进行兜底容灾，覆盖QQ音乐内部比较重要的几个入口。
通过对召回架构的整体改造，我们在多个新的功能点位，包括MOO App，AI歌单，曲风推荐等，都能够进行新功能的快速上线。我们在旧的入口也非常容易做一些改造，因为我们可以使用少量代码就可以进行内容切换实验，带来的效果提升也非常明显。
05 总结
除了上述工作之外，QQ音乐推荐团队还在进一步完善推荐入口上线的全流程，完善推荐引擎项目的产品化，进一步加速业务方的落地，有效地降低成本。此外，之前的工作重心主要在于提升效率，之后需要同时关注质量的提升，即我们想要上线新的推荐功能时使用的算法是SOTA的。最后，作为一个推荐算法架构团队，我们需要与业务方进行更多的沟通和交流，将架构的优化与业务的提升紧密绑定，防止团队做一些无用功，同时业务方最终也没有能够使用我们优化的功能去提升他们业务上的关键指标。
以上来自QQ音乐数据科学中心和基础架构部多位同学的工作，由Kalen Chen整理。目前有推荐系统和数据挖掘相关的正式岗位和实习岗位若干, 有兴趣的同学请发简历至：
