音频表征大模型在QQ音乐歌曲冷启的应用与探索

说明: 前阵子受DataFun邀请, 上周六在DataFunSummit #2024推荐系统架构峰会上做了关于 音频表征大模型在QQ音乐歌曲冷启的应用与探索 的分享, 这里对笔者在峰会上分享的材料进行整理, 由于准备时间仓促, 加之部分工作还在持续探索之中, 材料难免有错误和不当之处，敬请各位读者谅解和批评指正。

1. 问题与背景介绍

本文介绍的内容是接着天琴实验室的江益靓同学前面所介绍的音频表征大模型的议题, 介绍下音频表征在我们QQ音乐推荐冷启场景中的一些应用和探索, 首先是问题与背景介绍。

1.1 背景介绍

这里介绍下我们QQ音乐平台音乐推荐当前的内容现状, 和其它像短视频推荐、笔记推荐的场景类似, 我们的音乐平台也是面临着新冷内容长期分发不足的问题。

音乐虽然制作的门槛比较高, 但是, 我们平台每天其实也是有着大量新歌发布的, 同时, 我们歌曲的生命周期又非常长的, 很多"经典老歌"也是持续会被消费, 很多冷门的老歌也是值得被挖掘, 比如下面图里, 我们数据分析发现有不少优质的长尾歌曲还是十几年前的歌曲。我们的推荐系统也是希望能挖掘并分发更多优质的长尾歌曲, 来改善我们的推荐生态, 让我们推荐系统能有更多新鲜血液的补充, 避免推荐系统越推越热门, 越推越单一。

对于这些新冷内容, 我们会有一些流量抓手来帮助这些新冷内容的分发, 比如, 一方面我们会通过歌曲投放链路, 给这些新冷歌曲去匹配合适的人群进行投放, 另一方面我们也会在歌曲推荐的各个链路环节, 去扶持我们新冷内容的分发。这两种方式也是我们本次分享关于音频表征落地的主要场景。

但是新冷内容的分发并不是一件容易的事情。

1.2 问题介绍

我们的推荐系统目前主要还是基于ID的, 是由用户行为来驱动的, 但是新冷内容缺乏历史行为交互,它们的ID Embed是欠学习的。

我们希望可以通过强大的音频表征的能力, 来改善我们当前推荐系统新冷内容ID Embed欠学习的问题。通过音频表征，一方面可以给推荐提供更加全面、更准确的内容理解能力, 另一方面,它也能帮助我们的推荐系统, 比如我们的猜你喜欢, 每日30首, 在这些推荐点位可以去分发更多的新冷歌曲, 缓解马太效应，改善我们的推荐生态。

1.3 应用落地难点

这里说下我们思考的动机。从内容来说,音频是音乐的第1属性,但从推荐系统来说,我们的ID Embedding是起主导作用的, 这两个是有非常大的差异的, 我们希望, 可以在音频表征与ID Embedding之间架起一座桥梁, 跨越这里的鸿沟, 缓解我们新冷内容的分发不足的问题。

音频表征在推荐系统落地的难点主要有两个: 一方面是语义空间和推荐行为空间不一致的问题, 比如右图中, 两首我个人认为语种和音乐风格完全不一样的歌曲,它们在推荐行为空间上可能是非常接近的, 另一方面,为了刻画更通用更全面的内容理解能力, 音频表征的维度一般都很大,远大于我们推荐系统ID Embed通常的维度大小,无认是做数据上报还是模型训练,成本都是非常的高。

因此,要在推荐应用的话,一方面需要降维, 过滤掉对推荐来说可能没有什么用的信息，另一方面,需要通过映射让我们的音频表征去对齐我们的推荐行为空间。

这里的映射和降维,根据微调的数据可以大致分成三类,第一类是基于内容的视角,直接输出分类型标签或特征给推荐去使用, 这也是当前最常见的一种方式, 第二类是I2I的视角,也就是使用Item与Item的共现数据去微调，第三类是U2I的视角，也就是使用(User,Item)的交互数据去微调。这里的第二、第三种是需要依赖我们推荐数据进行微调的, 也是我们这次分享重点介绍的内容。首先我们先看下最常见的第1种。

1.4 常见使用方式

关于音频表征的使用,可能最直接的方式是把音频表征直接Concat起来,或者做下PCA降维后直接Concat起来, 但实际上, 这种直接Concat音频表征我们也做过不少的尝试, 但是发现基本上是没什么用, 甚至还会因为引入一些噪声带来指标的负向, 原因前面也介绍过,主要还是空间不一致的问题。

所以, 一种退而求其次的方式是，把它转化成标签化的分类型特征来给推荐使用，这里对于表征的处理完全是基于内容本身的, 与用户的行为数据无关。这种方式虽然也是有效的, 但我们觉得它的能力还是比较有限。关于这一部分, 我们不做详细展开。接下来还是重点介绍基于I2I共现数据和U2I交互数据进行微调的方式。

2 基于I2I共现数据微调

我们希望通过推荐的一些歌曲与歌曲的共现数据, 来帮助我们去学习音频表征的降维和映射, 并把它应用在我们的推荐系统中。

2.1 如何融入I2I共现信号-MPE表征

为了把用户行为的一些I2I共现信号融入到音频表征的编码之中,我们提出了音乐偏好表征的训练方式,下门简称MPE。 它的思想也是非常直接，就是输入三元组，歌曲1和歌曲2都是用户喜欢的歌曲，歌曲3是随机采样的歌曲，然后使用Triplet loss进行训练, 最后输出40维的embedding，同时实现音频表征的映射和降维,把我们I2I共现信号直接融入到编码环节。

这种方式比较依赖于我们I2I共现数据的构造, 会上也有同学问到关于如何构造数据的细节, 这里展开说下。

我们会从用户自身的收藏行为序列中, 采样出用户同时喜欢的两首歌曲, 歌曲1和歌曲2作为Pair对, 然后呢, 基于我们海量的用户行为, 我们会有大量的这种Pair对, 然后我们会对基础的频次限制, 只保留满足一定频次限制的Pair对。同时为了避免这里最终的Pair对太过偏向热门, 我们会对热门歌曲依据它的热度进行做降采样, 同时呢, 我们对于随机采样的负样本这里, 我们也会人为地做一些过滤, 比如过滤掉与歌曲1和歌曲2同歌手的歌曲。这里需要说明的是, I2I共现数据有非常多可实现的方式, 比较依赖于对业务的理解, 比如也可以基于推荐本身I2I召回的数据来构造, 我们的方式也不一定是最高效的。

在得到MPE表征后,我们可以怎么去使用呢,接下来介绍几个具体应用的例子。

2.2 MPE表征的应用

在这个例子里,我们将MPE表征用在了我们歌曲投放的I2I2U链路上。

对于新歌, 我们会基于MPE向量构建索引, 去做向量检索, 并增加相同语种的约束, 去召回得到TopK个mpe相似的歌曲, 然后实时获取收藏过这些相似歌曲的用户, 把这些用户写到Redis，线上呢, 直接请求Redis进行投放。我们也对比了没有使用I2I共现数据进行微调的AE表征, 效果也是有显著的提升, 这个也是我们现在效率最高的一条投放链路。

此外，我们也把MPE表征直接用在推荐的I2I召回环节。 比如,我们在左边这个图的AutoPlay推荐场景里, 这个场景是基于用户的上下文歌曲来进行推荐, 我们使用MPE Embed去召回长尾歌曲,显著提升长尾歌曲的播放份额。右边的图是在全民K歌的AI歌声推荐场景, 这里做帮助用户做AI歌声合成的场景, 用户通过上传自己的声音, 可以选择喜欢的歌曲, 我们通过AI的技术基于用户的声音来帮用户合成相应的歌曲。我们基于这个场景的行为数据再次微调了MPE表征, 通过使用这再次微调后的MPE Embed做召回, 显著提升了用户点击和卖歌收入。

2.3 如何对齐ID Embed-MPE相似IDs

这里, 先抛出一个问题, 我们基于用户行为数据微调出来的MPE表征能和推荐系统的ID Embed直接Concat起来使用吗?

虽然我们的MPE表征是使用用户行为数据微调的, 但它同样还是不适合与ID Embed直接Concat起来去使用, 原因同样也是因为它们的表征空间不一致的问题, 我们MPE Embedding是I2I共现数据训练的，而我们ID Embed通常是U2I交互数据训练的。

为了让这里的表征实现对齐,我们基于MPE表征，构建出了MPE相似的歌曲IDs，具体地,我们会从推荐热门歌曲里,去查找与该歌曲似的同语种的热门歌曲，把它们的歌曲ID当做序列特征来使用, 使用时可以用Mean Pooling或Transformer做聚合。这样构造出来的相似Item的特征，我们在多个场景都有了具体的应用。

2.4 MPE相似IDs的应用

在这个例子里, 我们将MPE相似Item用在了我们投放U2I匹配环节。

这个模型是双塔结构,与其它双塔模型不一样的是,我们在Loss上同时融合了InfoNCE和转置的InfoNCE, 以更加契合我们的投放场景，同时,我们也扩展了很多泛化性的特征，比如前面介绍的MPE相似歌曲ID特征, 以及实时收藏/完播该歌曲的一些种子用户, 也包括一些像前面最开始提到的音频标签类的特征。

推荐这里,举两个比较有代表性的例子。

左边这个是基于VAE的双塔模型, 它专门用来召回一些长尾的歌曲, 在这路召回里, 我们将MPE相似歌曲ID作为Item侧的额外的SideInfo使用。这路召回也是在各个推荐点位都上线实验, 在长尾歌曲分发上有着不错的线上收益。

右边这个是在我们的重排阶段对长尾歌曲进行个性化倾斜扶持,这里长尾歌曲会使用相似的歌曲ID直接替换原来的欠学习的ID Embedding,线上呢, 也只对长尾Item进行推理, 最终会输出个性化的倾斜分数, 然后再使用乘法公式进行融合做个性化的倾斜, 这里在长尾歌曲分发上也拿到了非常不错的线上收益。

3 基于U2I交互数据微调

接下来,介绍下,我们如何基于U2I交互数据进行音频表征微调的探索。

3.1 不同表征映射方式的对比

首先, 先对I2I共现数据微调和U2I共现数据微调的方式做下对比。

I2I共现数据微调和U2I交互数据微调这两种范式最大的差异是, 我们U2I交互数据是远远大于I2I共现数据的, 这里的数据量大体现在两个方面, 一方面是U2I本身样本数要大很多, 另一方面是User侧的用户行为序列也需要处理相应的映射降维处理。整体上U2I交互数据大概会比I2I共现数据大2~3个数量级, 所以基于U2I交互数据微调的范式需要更加侧重于如何进行高效的训练。

3.2 如何融入U2I交互信号

为了使音频表征能够融合U2I交互信号,我们做了两个步骤处理。

第1步是将离线的预训练高维音频表征导入到模型侧的Sparse Embedding Lookup Table。这么做的好处是, 我们可以不用依赖数据上报, 也不用做样本拼接, 可以直接复用现有的推荐样本。

导入可以有两种方式,如果工程能力支持,直接HDFS导入, 这种是最直接的了。如果工程能力不支持,那么, 可以单独训练一个模型, 通过最小二乘的loss, 这种情况下, 我们的梯度就是残差, 然后, 使用学习率等于1, 动量设置为0的SGD优化器, 一个Epoch就能无损更新成离线表征了。这个模型训练的成本非常小, 训练完后, 其它模型再去继承这个模型sparse参数就可以了。推荐模型的各种模型参数继承的能力应该也是很多公司都具备的一种能力了。

然后第2步呢, 是在所有使用ID Embed的地方, 包含Item侧以及用户的行为序列, 都加上一个表征映射的Encoder, 这个Encoder的输入就是前面的预训练高维音频表征, 而输出是一个跟ID Embedding同样维度大小的表征, 再把这个编码后的表征当作ID Embedding, 去进行后续深度模型的训练, 这个训练过程是端到端的, 也就是Encoder和后续的深度模型是一起训练的。这里需要提一下, 由于加了个Encoder, 这里的训练速度肯定会慢很多，而且模型大小也会大很多, 所以这里很有必要去做一些学习目标以及模型上的简化, 去加速训练过程。笔者自己在做了简化后的精排模型去训练这个模型, 速度也是比正常的精排模型要慢上5~10倍, 模型大小也是因为高维Embedding的使用, 大了数倍。

会上有同学提问这里的Encoder要使用什么结构, 我们是使用了最简单的MLP做映射处理的, 和常规训练双塔时的Item塔结构类似, 并不需要太过复杂的网络和模型。

3.3 如何使用Encoder表征

前面使用大规模的U2I交互数据进行预训练Encoder后, 在使用时, 我们会把这个Encoder拎出来, 单独用它来做表征映射编码。

基于这种Encoder编码后得到的音频表征, 我们发现, 把它用来初始化Id Embedding是一个比较有效的方法, 我们做了一些实验，结论还比较有意思, 也比较符合我们的认知:

第1点结论是, 在将大模型的表征用在推荐时, 非常有必要做下推荐任务的微调, 相信这里有做类似事情的同学都深有体会。

第2点结论是, 使用U2I交互数据微调的方式要比使用I2I共现数据微调的方式结果要好, 说明了U2I交互微调方式出来的音频表征与ID Embedding更兼容。

第3个结论是, 将编码后的音频表征直接用来初始化是比较实用有效的, 可以无痛兼容基于ID的模型。

3.4 模型更新流程

这里介绍下模型例行更新的一些流程。

前面的Encoder在经过充分的预训练后, 不需要每天例行更新, 只需要一段时间更新一次就行, 所以虽然前面带Encoder的模型训练起来很重, 但也是完全可以介绍的。线上模型在模型例行更新前做下ID Embed的融合就可以了, 将那些模型没见过的新的Item做下初始化, 模型已经见过的已经学习过的ID Embedding就不去动它。这里的融合也是非常轻量级的, 既可以工程支持实现, 也可以使用前面提到的SGD优化器的方式实现, 融合成本相比正常训练模型的成本, 几乎忽略不计, 只是会让这里模型更新的链路看起来变长一些而已。

4 总结与展望

最后是总结与展望。

4.1 总结与规划

这里做下前面介绍内容做下总结。

本次分享,主要介绍了一些在我们QQ音乐推荐的冷启问题上, 可快速落地音频表征的通用解决方案。具体地，我们基于微调映射过程中所使用的数据来源,详细介绍3类方法, 基于内容本身进行处理, 基于I2I共现数据微调，基于U2I交互数据微调。