推荐系统在音乐领域的应用研究

龙远婷 王屯屯

（1.平塘民族中学 贵州省平塘县 558300 2.黔南民族师范学院计算机与信息学院 贵州省都匀市 558000）

由于互联网和智能终端设备的飞速发展，各种各样的信息充斥着社会的每一个角落，人们无时无刻地被各个信息包围，于是人们需要高质量的推荐系统来为他们定制个性化的信息[1]。

此外，随着我国数字版权的不断发展，大部分热门音乐必须开通会员才能进行消费，对于非会员用户，找到合适的音乐变得更加困难[2]。基于此，越来越多的研究者将自己的研究重点放在了音乐推荐，并提出了不同的推荐算法。

王子茹等通过对比基于内容的协同过滤算法，基于聚类的协同过滤算法以及基于密度的协同过滤算法，发现引入用户的信任度可以提升模型的可扩展性，并且后两种算法更适合高维数据集[3]。

文献[4]认为，传统的协同过滤等推荐算法不能很好地适应用户的现代化的个性化需求，通过分别抽取用户端和电影端的各种特征，设计出多层神经网络模型，更好地对用户和电影特征进行了更为深度的交互，从而实现基于神经网络的电影推荐。王松涛[5]提出基于项目流行度演化网络的序列推荐算法，解决了循环神经网络中相邻用户的强依赖关系，从而避免了错误依赖的建立，提高了推荐准确度。文献[6]将消费者对商品的类型偏好和商品类型之间的关联程度建模，并计算商品间的相似性，预测用户对候选商品的打分，最后同时用ACNN 和基于商品类型偏好进行TOPN 推荐。

学术界的研究者提出了很多有效的推荐算法，但是需要工业界的工程师将这些算法应用到具体的服务中提供给用户，才能实现这些算法的价值，否则就只能停留在理论阶段。基于此，本文综合考虑学术界的推荐算法和工业界的软件开发，设计出音乐推荐框架，不但可以帮助学术界的研究者更好地清楚算法设计的方向，更能指导工业界的工程师去进行实际开发。

1 系统设计与实现

1.1 总体设计

完整的音乐推荐架构需要包含如图1所示七个部分：输入，ETL，多路召回，排序，过滤，线上更新和输出。

图1：系统架构图

1.2 输入和输出

任何推荐系统都离不开数据的支持。将用户的各种行为信息送到推荐系统，该系统根据每个用户的个性化动作和信息进行分析处理，得到其音乐推荐结果，并在用户端进行呈现。大部分用户行为是隐性的，用户本身无感知，必须对音乐的播放行为，系统可以分析该用户对该音乐的播放进度来判断对该音乐的偏好程度。

对于非音乐类APP 企业，无法获取用户的各种音乐消费行为和音乐的各种特征，需要通过爬虫技术去获取，但是很多网站采取了反爬虫策略，导致爬取到的数据规模较小，因此只能下载有限的公开数据集，效果不理想。

1.3 ETL

用户的信息杂乱无章且规模庞大，需要经过ETL 处理才可以被用于推荐。我国人口规模较大，对于使用人数较多的音乐APP，每天都会有上亿用户产生各种各样的动作行为，因此需要先对这些信息进行清洗、转化等操作，形成干净且规范化的数据格式送入到负责推荐算法的工作人员进行处理。例如，一个用户某天播放了100 首音乐，并且发生了多次“进度拖放”或者“暂定”“刷新”等操作，并且并不是看到的所有音乐该用户都会播放，因此会有更多的音乐被曝光。对于每一个行为，都会有一条记录存在服务器中，如果不对这些信息预先进行处理，单纯一个用户在一个月就会产生大量行为记录，当用户规模较大时，将会产生数据灾难，因此需要通过ETL技术，将多条数据进行清洗和聚合等操作。

ETL 主要包括三个步骤：抽取，转换和加载。抽取是指从源数据库获得数据的过程，具体内容如图2所示。

首先根据需求说明文档确定系统中需要的业务字段，并确定最基本的元数据来源。业务字段经过关联后，送入到原始中转模块进行处理。元数据经过一定的规则，送到字段管理模块，并和关联后的数据一起送入到中转站。该中转站会把全量数据经过全量处理后，送入到“待清洗数据”模块，等待下一流程。中转站的数据经过增量抽取后，同样作为待清洗数据。

转换步骤主要包括数据的清洗和转换两方面内容。如图3所示，待清洗的数据中存在缺失数据，需要经过“数据补缺”模块，利用某种填充算法（例如取均值，中位数），将缺失的部分进行填充，保证数据的完整性。此外，待清洗数据中还存在无效的数据，需要经过数据替换处理。例如，某个字段在所有记录中基本保持不变，说明信息增益比较小，在算法中起到的作用不大，可以考虑对其进行删除或者替换操作。根据上述两个步骤后，就可以得到干净的业务数据，并将其送入“干净的中转站”进行处理。这样的数据还不能保证样本数据的可靠性，还需经过一定的清洗规则，将数据中的部分数据进行清洗，得到规范化的数据，最后将规范化处理以后的数据，根据算法研究人员需要的目标格式，进行转化，方能得到最终的有效数据。

图3：ETL 的数据清洗过程

数据的转化过程如图4所示，清洗后的有效数据首先需要根据需求说明文档进行拆分，得到各种拆分后的数据表；系统中经常需要经过大规模的复杂计算，所需计算量较大，计算所需时间较长，所以需要在正式使用这些算法产生的数据前，要提前对其进行计算，并将计算结果进行保存；目前主要采用分布式存储框架，而该存储框架中耗时最多的操作是shuffle，而经常引起系统shuffle 操作的表之间的JOIN 关联，因此很多时候系统会提前将后续可能用到的表进行关联并进行存储，方便后续操作直接读取，而不用当场进行复杂的关联操作。经过上述三个步骤后，根据不同的业务目标，对数据进行匹配，并发送给相应的业务模块。

图4：ETL 的数据转换过程

加载步骤根据前面抽取过程中数据抽取方式的不同，对目标进行不同操作。例如，当前面对数据进行全量抽取时，对目标表进行替换动作，而当前面对数据进行增量抽取时，需要对目标表进行插入操作。

1.4 多路召回

所谓的“多路召回”策略，就是指采用不同的策略、特征或简单模型，分别召回一部分候选集，然后把候选集混合在一起供后续排序模型使用，可以明显的看出，“多路召回策略”是在“计算速度”和“召回率”之间进行权衡的结果。其中，各种简单策略保证候选集的快速召回，从不同角度设计的策略保证召回率接近理想的状态，不至于损伤排序效果。

召回是指为用户生成初步的推荐列表，而多路召回是根据不同推荐策略或算法产生不同的推荐结果，比较常见的推荐算法有：基于用户的协同过滤算法，基于音乐的协同过滤算法，基于图的算法，基于聚类的算法，基于音乐多媒体信息的推荐算法和基于业务逻辑的推荐等。

基于用户的协同过滤算法，先为目标用户找到与其相似的候选用户，然后从候选用户中筛选出目标用户未消费过的音乐进行推荐，并且根据目标用户与候选用户的相似程度，和候选用户对目标音乐的喜爱程度进行打分，按照分数进行降序推荐；基于音乐的协同过滤算法，根据目标用户历史喜欢过的音乐，找到与历史音乐相似的其他音乐进行推荐，并根据目标用户对历史音乐的喜欢程度，以及历史音乐与候选音乐的相似程度进行打分，按照分数降序推荐；基于图的推荐算法，分别把用户和音乐作为二部图上下两部分，利用随机游走等算法，计算图中两个节点的相关系数，按照相关度降序排序；基于聚类的推荐算法，提取音乐的特征，构建特征向量，在N 维空间中每首音乐都可以被看做一个点，每个簇内的音乐可以被当做一个类型的音乐进行推荐；基于音乐多媒体信息的推荐算法，通过提取用户历史音乐的多媒体信息，比如音轨、音色以及节拍等信息，分别找到与这些多媒体信息相似的音乐进行推荐；基于业务逻辑的推荐算法，需要从消费者角度出发，根据实际的业务场景进行推荐，例如，用户A 刚关注了歌手B，从某种程度上认为该用户喜欢该歌手，可以把歌手B 的高质量音乐推送给用户A。

1.5 排序

每种召回策略都会为用户生成一个推荐列表，因此需要排序算法将这些召回池内的音乐进行统一排序。融合排序方式如图5所示，每个召回池都有不同的权重，等所有召回池准备就绪后，一起送入到多路召回的融合模块进行集中处理，最终经过排序等操作后，得到排好序的音乐推荐列表。

图5：多路召回和排序模块

具体排序算法如下所示：

其中Score(Uk,Mij,t)表示t时刻用户Uk对音乐Mij的打分；式中第一部分Score(Ri)表示召回池Ri的权重，该值需要根据具体业务进行配置；式中第二部分Sim(Uk,Mij)表示用户Uk与音乐Mij的相似度，该值可以通过机器学习的CTR 学习得到，也可以简单地通过余弦相似度等相似度评价指标获得；公式最后一部分表示时间衰减函数，发表时间越新的音乐，应该得到较高的推荐分数，其中T 表示当前时间，t 表示音乐发表时间，λ 表示衰减系数。当用户经常看到发布时间比较新的音乐时，会更加认为系统能够及时地将最新音乐推荐给自己，提高用户对系统的新颖度，满意度以及系统黏性，所以在设计排序算法时，给距离现在时间T 较为接近的音乐较高的分数。需要特别注意的是，不同的召回池的权重，应当由具体业务和某种学习算法结合起来，才能达到最好的效果，其中用到最多的简单线性学习算法为逻辑回归。

1.6 过滤

经过上述步骤后，基本得到了用户所需的个性化音乐，但是这部分音乐并不能直接分发给用户，还需经过过滤步骤。需要过滤的音乐大致分为以下三个部分：已经消费过的历史音乐；同一歌手的多首音乐（推荐结果中的高相似音乐）；由于版权等原因无法上线的音乐。

对于用户已经消费过的音乐，一般要对其进行过滤（曝光过滤），因为一般认为音乐的推荐是为其推荐没有听过的音乐，这样可以增加用户对系统的新鲜度。此外，对于“同一首音乐”的认定，可以有不同程度的限制水平，例如同一个歌手在不同时间演唱的同一首音乐，有时也会被认定为不同的音乐；对于同一歌手的音乐，在一次曝光中，一般不建议重复出现太多首，否则会很容易使得用户变得审美疲劳。

历史音乐曝光过滤过程中最重要的是定义目标用户的历史曝光序列，比如跨场景、跨天等，而高相似度音乐过滤过程中如何定义item 的相似度、跨场景、跨session 的高相似度去重都是值得细细探究和深挖的点，将在后续进行深入研究。

在过滤的最后一步，需要检查推荐音乐是否包含未授权音乐，或者歌词中含有不正当言论，或者歌手存在违法乱纪等情况，必须对这些音乐进行下架或者永久封禁等操作。

1.7 线上更新

随着计算机算力的不断提高，基本可以实现音乐的在线更新，但是线上仍然无法完成较为复杂算法的运行，所以需要进行音乐的线上更新。当推荐算法复杂度较高时，需要经过线下的长时间运行才能得到推荐结果。目前应用较多的线上线下发送根据为Kafka，可以将线下的数据流当成生产者Producer，线上的服务器称为消费者Consumer，两者通过相同的主题Topic 进行交互。

从图6 中可知，producer 就是生产者，是数据的入口。注意看图中的红色箭头，Producer 在写入数据的时候永远的找leader，不会直接将数据写入follower。生产者数量为M，也就是有线下有M 个用户的音乐从线下产生；同理，消费者数量为N，可知线上需要更新的用户数量为N；较为复杂的是中间的kafka 集群部分，一个集群由多个Broker 服务器组成，每个Broker 服务器上存放多个主题Topic 的多个分区，并且有些分区为Leader，有些为Follower。在集群管理中，为防止某个服务器异常影响整个集群的使用，通常会设置Leader 和Follower 这两种角色，由Zookeeper 等工具选举产生，并且只有一个Leader，可以有多个Follower。正在工作的被称为Leader，其他的Follower 处于随时待命状态，要不断地与Leader 进行信息交互，保证当Leader 出现异常，并且自己被选举为新的Leader 时，能够立刻正常工作，不影响集群的正常使用。

图6：利用kafka 进行更新

为提高用户对内容更新的满意度，一般在凌晨开始进行数据的发送，等到用户第二天打开音乐APP，看到更新后的结果，很大概率上认为此次更新结果较上次有较大的不同，提高对系统的满意度。

2 实验

当音乐推荐系统针对不同用户生成新的音乐推荐列表出来后，需要对推荐结果进行评估，方能知晓该推荐算法是否有效，以及是否应该进行线上更新。实验方法一般分为线下实验和线上实验，线上实验是指直接以线上用户为对象进行的实验，当某个用户长期被作为实验对象，并且接收到糟糕的推荐结果，该用户会认为该系统无法满足其需求，可能会放弃使用该系统，为避免该情况的发生，一般在进行线上实验前，先进行线下实验进行初步的评估，保证该实验不会对线上用户造成较大伤害后，方能进行线上实验。

2.1 线下实验

当算法研究员设计好推荐算法后，需要自己去编写代码去验证想法是否与预期符合。最为快速的线下实验方法为，拿到最为熟悉的几个人推荐结果，分析这些推荐结果与他们平时的口味是否相符，如果不符合，说明推荐算法效果较差，需要终止实验。如图7所示，张三之前喜欢“我是中国人”和“爱拼才会赢”这两首音乐，前者表示该用户喜欢“爱国”类音乐，后者表示“闽南语”或者“粤语”类音乐，并分别给出9.5 分和5.6 分（满分10 分）的评价，该评价由系统根据用户对不同音乐的不同行为自动打分得到，行为包括：播放次数，播放进度，是否下载，是否收藏，取消收藏等。如果推荐算法为张三推荐的音乐为“我爱你中国”和“酒干倘卖无”，说明推荐结果比较准确；反之，如果推荐系统得到的音乐为“数鸭子”和“朝阳沟”，说明推荐效果不理想。因为推荐结果中前者表示“儿歌”类音乐，“朝阳沟”表示“豫剧”类音乐。

图7：推荐结果分析

如果发现利用最新算法得到的推荐结果初步来看较为满意，就可以进行下一步离线实验：计算相似度。

将音乐推荐列表中所有用户的推荐结果与该用户历史消费音乐进行相似度对比，如果相似度比较高，证明推荐的音乐与用户历史喜欢音乐比较相似，是同一种口味和风格的音乐，可以进行下一步线上实验，否则取消该对比实验。相似度打分Score 定义如下：

其中U 表示候选用户集合，m 表示某个用户历史喜欢音乐个数，n 表示音乐推荐长度，Score(u,Mi)表示用户u 对历史喜欢音乐Mi的打分，Sim(Mj,Mi)表示推荐音乐Mj与历史喜欢音乐Mi的相似度。系统需要定义某个分数阈值S，当某个算法的Score 大于该阈值时，说明该推荐算法效果较为理想，可以进行线上实验，是否必须对该算法进行修改后方能继续下一步操作。该相似度阈值也不是越大越好，因为当Score 特别大时，表明推荐的音乐与用户历史喜欢音乐过于类似，使得用户新颖度较低，导致系统中的用户长期被同一类型的音乐覆盖，无法探索新的音乐口味。

2.2 线上实验

进行线上实验首先要确定实验对象。应该选取最能代表大多数用户的对象进行实验，这样的实验才更加具有说服力，因此实验对象应当具备足够的随机性。此外，线上对比实验对实验对象的活跃度有一定要求，即实验对象在系统中的活跃度不能过高，也不能过低。一般对实验的观察期为几个小时或者一天，如果实验对象过于不活跃，可能导致实验期间该用户没有使用该系统，无法对其结果进行统计观察；此外，实验对象的活跃度不宜太高，这些用户对系统的容忍度和信任度较高，导致这些这些用户对效果一般的推荐结果进行较为积极的回应。

多臂老虎机是一种随实验进程动态分配流量的实验，比A/B 实验更有效率。它通过不时观察各变体的表现，而动态调整各变体流量比例，增加表现好的变体的流量，同时减少表现差的变体的流量，而不用等到实验结束。但这类实验需要两个重要条件：评估目标是单一的OEC（多指标需融合为单指标），且该OEC 在流量重新分配时能够被很好地测量（比如点击率）。此外，这类实验还存在一点风险性，即将原本处于“差”变体中的流量按不同比例分配到其他表现较好的变体中时可能会有潜在偏差（但我个人认为，即使是静态流量，偏差也无法避免）。

选取好实验对象后，应当选取数量相等的类似用户作为对照组。注意不能将其他所有用户作为对照组，因为这些用户的行为习惯与实验对象可能不同，而且同一时间可能有多个实验在同时进行。分别统计实验组和对照组的各项KPI 指标，并将这些结果以可视化的形式进行展示，可以帮助决策者更加准确地判断推荐算法的效果，并进行后续的决策。

需要注意的是，现有的数据结果并不能说明一切，有可能指标定义不合理，或者其他流程出现问题，需要决策者综合进行考虑。算法研究人员主要负责设计推荐算法，并用代码去生成推荐结果并进行简单的线下验证，至于实验结果是否真实有效，还需PUSH 到线上进行分析。然而线上推送、音乐过滤等流程由其他工作人员完成，可能由于这些步骤的失误，导致实验结果不理想。

3 结语

本文针对学术界与工业界由于信息不对称导致的算法应用效果不理想问题，提出了推荐算法在音乐系统中的应用框架。该框架包含从数据的处理分析，到音乐的多路召回以及对这些音乐进行统一排序，最终到音乐的过滤和融合，系统介绍了如何去开发出一个完整的音乐推荐系统，以及各种不同的推荐算法在音乐系统中的实施方案。该框架可以帮助学术界科研人员更好地去开发出较为前沿的推荐算法，也可以帮助工业界和教育相关工作人员更好地去理解和应用各种算法到音乐系统。