分享嘉宾：Moyan 腾讯音乐 高级算法研究员

编辑整理：吴祺尧

出品平台：DataFunTalk

导读： QQ音乐和全民K歌的各种技术需求驱动了多模态学习的研究。在总结归纳业务需求时，我们总结了MMatch，一系列模态匹配技术。提出多模态技术的想法很自然，因为不同模态之间的描述可以补充知识，进而更全面地刻画目标的全貌，并且建立一个更广泛的关系。我们的世界本身就是多模态的，会有视觉、听觉、文字等。在QQ音乐的场景下，虽然我们以音乐为中心，但是我们有其他模态的数据，如专辑的封面图、标签等，它们可以与音乐本身关联起来。

今天的介绍会围绕下面四点展开：

• “多模态+音乐”的需求盘点
• MMatch系列技术
• MMatch应用
• 未来计划

01 “多模态+音乐”的需求盘点

首先和大家分享下多模态学习以及QQ音乐对多模态的应用需求。

假如上图的图片没有任何先验知识，机器甚至有些眼神不好的观众会认为红框中的物品是山竹。但如果我们在图片上有一行文本描述与图片匹配，我们会迅速意识到红框这部分是猫爪。所以不同的模态对同一个实体的描述可以补充知识，刻画一个目标的全貌，并且建立更广泛的关系。猫爪和山竹在基本特征上有相似性，同时在文本上有共现性，因此本来没有任何关系的猫爪和山竹就通过图片和文本的描述建立了一种新的关系，进而能够提升检索的效果。

QQ音乐有很多除音乐外其他模态的数据。比如一首音乐在专辑中，其专辑的封面图就可以和音乐关联起来；如果有用户对音乐进行了评论，那么评论的文本可能是和音乐相关的，也可以被认为是音乐的另一个模态的表现；一首音乐可能和其他音乐组织起来形成一个歌单，那么歌单中的音乐具有相关性，我们可以认为其他音乐是对当前音乐的多模态关系的表述；有些音乐有视频，那么视频就是一种对音乐的视觉化描述。综上，我们可以看到在QQ音乐里有很多模态，它们的特点是围绕音乐而存在，也是我们多模态技术的重要特点。

所有的多模态检索都由具体的需求驱动。比如用户可能会根据一些热门歌曲或者自己喜欢的歌曲来检索相似歌曲。对于我们而言，面对庞大的曲库自然而然地会提出这样一个问题：“这种歌是哪种歌”。比如用户检索“芒种”，系统推荐“清明”或者“谷雨”、“惊蛰”，因为这些都是24节气，但显然这不是用户的真实意图。如果仅从流派或者语言等粗粒度的标签来进行匹配不能够满足音乐的相似性性质。一个简单的想法是将音乐进一步拆分为更多细粒度标签并进行预测，即根据更细粒度的标签进行音乐匹配。这种思路实际上是不可行的，因为需要大量标签模型的开发，并要处理无休止的各个模型预测结果的融合问题。所以我们需要对歌曲本身有一个很好的理解才能进行音乐匹配。

短视频现在非常火，自然地也会存在对一个具体视频做音乐匹配的需求，使得用户制作短视频的成本更低。一方面对于创作者来说，可以提升作品质量、降低制作成本；另一方面对于平台来说，内容的整体质量提升对平台的活跃性也有明显的提升。

我们还有对商家环境的音乐匹配的新业务。在不同的商家环境下，店主对于音乐的需求不同。比如超市希望音乐可以激发顾客的购物热情，餐厅希望使用音乐营造特殊的格调做氛围烘托，夜店希望顾客玩起来非常嗨来产生更大收益。

总结一下，QQ音乐使用的多模态学习以及其应用需求基本上都是以图片，或者视觉上的信息，以及文本上的信息，亦或是其他的音乐信息，对音乐进行检索。所以，应用是在搜索端以多模态为主，在被搜索端主要以音乐的形态进行呈现。

02 MMatch系列技术

基于上述需求，我们总结、归纳并抽象了需求的共同特点，做了一些针对性的技术开发，形成了自研的MMatch系列技术。

从底层上看，我们有很多模态，包括图像、文本、音频标签、视频标签等，但是模态维度还是较粗。在模态之上，我们构建了“数据域”的概念。比如对于文本，它可以被分为一般文本和歌词。一般文本是评论等可以通过通用NLP技术进行解决，而歌词因为追求押韵，会有不同的文本数据特性。所以我们会通过精确的数据建模，使内容理解对不同数据域的数据存在不同的数据理解，这部分基本上会以embedding或者标签为主。在这里面会掺杂一些简单的多模态匹配，比如我们对通用的音频的embedding建设会参考音乐本身内容，也会参考其附带的歌词的理解，使其变得更加完整。基于单模态的内容理解我们可以做一些匹配模型。这些模型可能会和业务相关，同时也会保持一定的通用性，综合利用了单模态的内容理解的结果。最后，一个或者多个匹配模型可以支撑具体的应用。举例来说，QQ音乐商家版会在内容分发上进行优化，比如歌单生成、运营提效等。

1. MMatch图文配乐

我们的第一项技术叫做图文配乐。我们的思路是做基于语义池的匹配。我们会从音乐的图片信息、文本信息还有meta信息中抽取语义构建语义池。语义池里包含具体的语义，但是可能和音乐没有直接关系。基于语义池，我们可以通过匹配引擎从曲库中寻找相似歌曲。值得注意的是，匹配引擎并不是执行一个搜索的操作，而是一个基于内容推断的过程，从音乐和歌词本身推断音乐所附带的语义信息，进而将其与语义池进行匹配。

2. MMatch音乐匹配

音乐匹配的思路类似于语义匹配，但是我们会把音乐相关的标签描述收集起来，比如配器、歌手音色、流派、语言。同样，我们通过音乐本身的内容（歌词、音频）去预测音乐描述。在多达几百个标签的多标签学习的任务上，我们将音乐对应的embedding抽取出来进行向量库的建立。对于一个新的歌曲，我们同样可以取出embedding，通过向量相似度的衡量方法把听感相似的歌单给抽取出来。我们可以看到MMatch技术强调以音频为出发点，这是和我们具体的需求有强相关性的。我们要求MMatch技术对新歌和冷歌都生效，不能够依赖用户的交互行为和UGC。

3. AI标签技术

我们对AI标签技术也做了流程的优化。与之前不一样的是，我们会去曲库上基于图文匹配的技术构建数据集，并抽取通用的embedding，这个embedding可以被作为软标签来使用。在需要硬标签的场景下，我们会建立一个简单的、轻量级的分类器，通过标记一些重要性较高的样本与编辑人员做快速交互，进而调整数据集来完成整个迭代流程。最后，分类器输出的结果就可以作为硬标签，即具有明确语义的标签数据。整个AI标签技术能够带来非常大的效率提升。

4. MMatch视频配乐

最后是MMatch视频配乐的应用。视频是一个多模态的事物，它包含歌词、音乐和视频。我们的想法是对不同模态的信息进行单独的建模，在embedding层面进行融合操作，针对一个目标做端到端的推理。在这里我们选择歌曲高质量MV作为target进行训练，保证音画同步。

03 MMatch应用

接下来介绍一下MMatch在具体业务中的应用，看看我们是怎么找到业务的切入点，将具体的技术应用到业务上。

我们一个比较新的业务叫做QQ音乐商家版。传统上，音乐app主要是做一个向C端分发音乐的平台，就比如大家打开QQ音乐听歌。在这里开拓了另外一个新场景，就是在商家端的音乐平台，它被称为“公播”，属于B端消费。我们的核心功能需要为商家提供包含店铺管理、门店个性化适配、歌单定期更新等服务。我们预估商家公播市场规模大概有百亿左右，涉及的流量有万亿左右。万亿流量是单个app所无法触及的量级，所以这是一个非常庞大的可以被分配的流量。

要达到万亿流量和百亿市场并不容易，其中最基本的问题是需要解决商家不同的个性化内容需求。首先，我们必须有能力对他们进行个性化的音乐适配；第二，这个过程必须是很高效的。我们面对的潜在客户数量巨大，所以不可能人工覆盖个性化服务。而目前解决个性化需求的方案也有两类：第一类，平台提供一个包含100或200种类型的歌单，商家从中进行挑选，但这样的话无法真正满足个性化需求；第二类，平台雇佣一个非常庞大的专家团队，针对店铺的具体情况进行定制，虽然这么做满足了个性化需求，但是效率极低、成本昂贵，且无法做到快速响应。这样一个鱼与熊掌不可兼得的任务，MMatch可以给出一个较好的解决方案。

在介绍MMatch方案之前，我们先看一下QQ音乐商家版遇到的具体挑战，因为这是使用MMatch技术的出发点。

第一个是合规问题，虽然QQ音乐的曲库非常大，但是公播所涉及的版权情况比较特殊，整体上来看我们的公播音乐的合规曲库占整个曲库的比例非常小。类似的，我们的公播曲库存在严重的头部问题。QQ音乐的曲库虽然也存在头部问题，但是头部曲目足够多，满足一般的分发任务。但是对于公播，其本身曲库很小，再加上头部问题，使得从绝对数量上来看头部的曲目较少。所以这对应着公播曲目可用内容稀缺的问题。

第二个问题是商家需求的模糊性。商家有时候会有很模糊的描述，比如他也没有描述自己店铺所公播的歌曲内容的想法，但是他会告诉我们他的店铺长什么样子，他的装修风格是什么样的，大家对他的店铺评价是什么。这种商家希望我们基于这些诸如店铺环境的要素来帮助他们适配一个合适的音乐。总而言之，需求的表达非常模糊，属于只可意会不可言传的类型。既然这种无法使用语言描述的概念无法言传，那么我们就让商家使用自己的“意”来找到适合自己店铺的个性化内容。

我们针对上述情况提出了两个不同的解决方案。首先，如果商家有一个“种子歌单”，即他对自己需要的歌曲是有想法的，但是有的歌曲不一定合规，那么我们可以使用MMatch音乐空间相似搜索技术（即匹配技术）把歌曲的特征抽取出来，进而在歌曲库中寻找与歌曲具有相似特征的合规歌曲，最后达到歌单匹配的结果。另一种情况，商家只有对店铺环境的描述，或者给出了店铺的环境图片，那么我们使用MMatch图文匹配技术，通过语义池从合规歌曲中直接找到目标歌单。

但上述两个方法基本上不太可能一招奏效，主要原因是歌曲的相似标准因人而异、因需求而异。比如我有一个种子歌单，然后告诉你需要类似的音乐，但我们无法准确定义什么是类似的音乐。它们之间可能因为是同一个歌手演唱的，也有可能是因为音乐风格相似。这就导致歌曲相似的标准本身就带有歧义性。另一方面原因，我们去做环境匹配的时候，由于匹配的整个过程是无法与商家在音乐体验上有交流，所以我们需要针对商家的满意度来对歌单进行微调。总结来说，我们第一步的推送不一定是商家最满意的内容，那么解决方案是让商家自己把意图展现得更加好，我们通过MMatch得到目标歌单，然后再基于目标歌单与商家进行交互与评判。那么当商家在目标歌单上做了选择以后，我们会知道商家所谓的“相似”的真实意图。通过意图分析技术，我们就可以自动调节匹配参数，最终达到一个让商家不用言传自己的“意”而通过这样一个循环迭代的流程来拿到自己想要的曲目。

上图是一个结果实例。这个店铺的装修风格是古色古香的，我们通过匹配和调优得到top10的推荐歌曲。从名字上来看这些歌曲和环境还是比较匹配的。整体上我们的匹配率达到了91%左右。

QQ音乐商家版除了它的百亿市场以外，还具有很大的宣发价值。对于QQ音乐平台，宣发一首优秀的热歌价值巨大，比如热度会带来运营收益、财务收益以及生态收益，进而我们可以反哺上游制作方，让音乐人创作更好地作品同时收入更多，进而使平台的影响力继续得到提升。在宣发推广中QQ音乐商家版有很多玩法，比方说我们可以使用站内投放、站外二创、社区运营等模式。这里面最核心的要素是流量，因为有些音乐人的作品很不错，要是可以成功推广出去一定很火，但是我们就是需要一些流量才能把歌曲真正推出去。

但是，公播的流量使用十分敏感。举个例子，我们如果给一个豪华酒店推了一首土嗨神曲，大家可能就是一脸问号。所以如果我们推送的歌曲和商家的情况并不相符的话，就会带来反面效果，大家会觉得这首歌还不如不播放，无法达到我们宣传歌曲的初衷。

对此我们设计了一套基于MMatch的解决方案。在投放歌曲的时候，我们会先做授权和确权，保证我们投放的歌曲是合规的。在合规的基础上，我们会设置投放目标，它并不是对所有的商家都生效，而是会去收集所有商家现在播放的歌曲是什么，以及播放歌曲的风格是什么样子，并且基于此通过MMatch匹配来对待投放曲目进行标记。如果一首歌曲和一个商家不是特别合适，那么我们就不会投放它。通过这一流程，我们可以选择适合商家的曲目生成一个投放池，随后生成具体的投放任务。后续流程还有店铺上报、内容监控的模块，最后投放结束。整个流程的核心是MMatch的歌曲匹配，它保证了我要插入的投放歌曲和原来商家的播放曲目风格是很相似的，从而达到无感直推的目标。所谓无感直推就是当一首歌曲被我们通过公共渠道推送出去以后，商家和在场的听众其实感觉不到有一首歌曲被插入进来，整个体验是非常流畅的。另一方面，从需求角度出发，我们要推送的歌曲基本上都是冷门歌曲或者新歌，那么整个流程就需要是基于内容的而不是参考用户的行为特性，所以MMatch这种基于内容的匹配方案适用于上述需求场景。

上图展示了MMatch歌曲音乐embedding空间的可视化结果。通过可视化，我们可以发现从乐器、曲风等角度，音乐的embedding聚类效果都比较好，这就给我们很大信心来使用音乐embedding相似性解决歌曲匹配问题。

我们与musicnn在MSD-18w的数据集上进行了对比实验，我们的MMatch有了2.33%的提升。当我们使用内部数据集进行实验时，我们的模型效果提升更明显。并且，我们观察到随着标签的数目越多，MMatch相对于musicnn的性能会有更大的优势。在具体的计算上，我们针对特征抽取和在线推理都做了很大的优化，整体上耗时只有musicnn的五分之一左右。

客观的匹配结果对于应用研究比较有用，但是这不是我们最终参考的价值，我们需要对业务具体的体验负责。所以我们做了大规模的主观听侧实验。具体地，我们将歌曲给音乐专家，让它们真实体验歌曲匹配的情况，让它们判断MMatch给出的结果是否是他们理解中的歌曲匹配。

我们第一轮有24轮1200首歌曲，有六位专家进行不交叉的人工评测。他们根据自己的主观感觉进行匹配来决定两首歌曲是否相似。这一轮测试我们达到了88.67%的匹配率。第二轮实验中引入了交叉验证，有20轮334首歌曲，请了三位音乐专家对内容进行三轮评测。最终整体上MMatch达到了91%的听侧匹配率。通过这样的大规模主观验证，我们对将MMatch进行歌曲相似度匹配推到更多应用场景的前景非常有信心。

在上述基础之上，我们需要进一步指导MMatch可以在哪些场景下得到应用。比如在运营这里，平台中存在头部问题。基本上，搜索、推荐、运营分发的内容都是突出的头部内容，而尾部内容（85%的歌曲）都没有机会得到播放。所以尾部内容的分发难度非常大，而且分发的数量也非常少。但是我们不可以不推头部歌曲，因为它们是用户体验的核心点，不推它们会极大影响核心运营数据，例如DAU等，最终也会影响到用户的体验。但是我们也不可以只推头部歌曲，因为我们需要解决的问题是让优质的歌曲和艺人得到出头机会。要想让这些没有资源但是优秀的歌曲和艺人出头的话，我们必须对他们进行一些相对的资源倾斜。与此同时，一些用户会偏向探索性歌曲体验，如果不推头部或者只推头部歌曲，在这类用户中使用体验不佳。

这看起来又是一个鱼与熊掌的问题，但我们的MMatch也有一个解决方案。我们的想法是使用MMatch去推送一些合适的中尾部歌曲，这样既不影响用户体验，又能增加尾部内容的流量。我们使用了与传统搜索推荐领域不一样的实践方案。在用户输入搜索词后，我们通过MMatch可以迅速找到与搜索词相似的歌曲进行返回，形成一条播放。目前这一模型已经在搜索端全量上线，大家可以自己体验一下。使用这个方案以后，我们在没有影响用户体验的情况下，有效播放率提升了10%。在推荐侧我们也上线了类似的逻辑，在你播放一首歌曲的时候，我们会使用MMatch进行歌曲匹配，找到相似的歌曲，然后通过精排操作来提高你下一首可以听到中长尾，但听感上具有一致性的歌曲的概率。在推荐端，我们不但没有降低用户体验，反而在用户对歌曲的完播率上提升了1.35%，在歌曲分发上也得到了改善。所谓歌曲分发，就是降低了头部歌曲的份额。

在标签运营中，我们知道其实很多核心资产标签可以支持算法研发、为搜索/推荐做内容分发、为内容制作和运营上快速召回一些目标内容、帮助建立用户画像和知识图谱。但是流派、情绪、场景的标签种类可能有成百上千个，而绝大多数的中长尾的歌曲是没有标签的。想要完成标签的全覆盖，提升中长尾歌曲被推出去的概率，我们需要依赖AI的自动标签技术。我们发现开发这样的技术非常耗时耗力，并且未来重复开发工作比较大。不仅如此，多个标签模型轮询计算的话，计算消耗比较大。

MMatch的快速分类方案如上图所示。和之前相比，我们现在从MMatch的特征开始进行训练。之前我们需要训练一个深度模型做AI标签识别，而现在基于特征输入，只要训练一个轻度分类器就可以完成同样的任务。以前从零开始的模型需要从随机初始化开始慢慢训练提升识别准确率，而现在一开始就可能有90分的识别表现，甚至直接可以拿来使用。此外，传统方案需要调整所有的训练环节，包括超参数、模型的结构等，而现在使用MMatch只需要调整数据或者不用调整就可以达到一个比较好的效果。之前我们有全量验证-迭代的逻辑，而现在我们通过重点case分析进行快速标签验证和迭代即可。整体看来，MMatch给我们带来了训练效率的显著提升。

在推理侧，由于之前的AI标签模型都是重量型模型，所以在对歌曲标签进行推理的时候，我们不得不使用多台机器，并且将不同模型放在不同机器上，占用了很大的计算开销。现在，使用MMatch，由于所有特征都是通用的，我们可以在一台机器上装载很多小模型，所以推理效率也有很大提升。现在，通过我们MMatch标签流程，三到五天就可以完成一个新的标签的开发和上线。在短时间内，根据业务需求，我们快速开发了十几个流派和很多主题以及MIR，所有标签的准确率都达到了90%以上。我们找了业内一些开源的数据集进行了对比，实验发现我们的标签系统略胜于业内的最高水平，在内部数据集上我们得到的性能提升非常大。当然这是因为我们的系统都是以内部的真实业务需求为导向的。

我们平台中有一个功能叫做跑步电台，它的基本原理如上图所示。首先它通过手机的陀螺仪等设备检测用户在跑步的时候的步频，然后通过歌曲池做BPM计算，达到一个与步频匹配的效果。这会让用户感觉跑步的每一步都踩在节拍的点上，使得用户的跑步体验得到提升。这里的问题在于标签筛选。编辑需要人工确定歌曲池，很难做到高频的更新。现在，我们依靠模型，通过MMatch标签流程开发了一个“宜跑模型”。我们在曲库里使用模型抓取适合跑步的歌曲，然后通过PDM技术从候选歌曲中选择优质的歌曲。这一步的目的是为了保证用户听到的歌曲是适合发布的内容，且歌曲是好听的。此外，它还匹配了用户跑步的状态，使得用户得到一个良好的使用体验。通过这样的流程优化，我们提升了34%的完播率，降低了41%的切歌率，并且人均时长上涨了48.4%。

在运营侧，我们会对一些高优的内容进行打标分发。之前我们使用人工方式效率非常低。引入MMatch以后，编辑不再需要对所有高优内容进行打标分发，而是标记少量样本，通过MMatch歌曲匹配进行召回与批量标记，再去做验证分发。这样的话他的工作从打标签变成了验证标签，使得工作效率得到了巨大提升。在验证分发阶段，如果标签本身具有固化价值，我们就可以将其加入MMatch自动标签，为以后的场景进行服务。经过分析验证，我们通过上述流程后又七成标签的准确率达到了95%，全部标签的准确率达到了87.5%。

最后，我们会使用MMatch进行视觉配乐。这类技术我们还在快速迭代中，上图展示了我们的初步结果。与我们模型进行对比的是VM-NET。通过客观对比，我们相较于VM-NET在各项指标上有了一定提升，但是我们的提升空间还很大。

04 未来计划

最后分享一下基于MMatch技术，在未来有哪些新鲜应用可以尝试。虽然我们的技术还在快速迭代和开发，但是我们可以有一些新的玩法来给予用户新鲜的使用体验。

第一个想法是将QQ音乐商家版的交互识别逻辑引入平台推荐系统中。我们目前的推荐基于当前歌曲，但我们可以尝试通过加入一些可编辑标签组，让用户定制推荐内容，即用户可以指定哪些标签的歌曲可以给我推荐，而不要基于另一些标签推荐一些歌曲。通过上述流程就可以达到定制推荐的效果。

另外一个未来玩法是基于MMatch歌曲匹配技术对杂乱的歌单内部进行重排序。排序可以将歌曲分成不同的组别，在听歌的时候按照情感相似性连续顺滑地进行过渡。简单来说，我们可以通过基于MMatch的重排序达到顺滑模式的效果。相信这个功能对歌单比较杂乱，又希望听感有序地听歌的人是一个福音。希望我们能够把顺滑模式落地，和大家尽快见面。

从根本上来说，MMatch的最终目标是让有才华的音乐人发光。我们希望把这些好听的歌曲通过短视频、商场的公播、运动的时候、阅读文章的时候或者玩游戏的时候进行播放，把它们很合适地分发到不同的场景，从而提升好歌曲被推火的概率。希望MMatch和PDM一起，为上游有才华的音乐人服务，让他们能够更好地创作出优秀的作品。

05 精彩问答

Q：合规的歌曲但质量不够的歌曲是不是不能进行公播？

A：质量不够的歌曲不能进行公播，因为当内容或者某方面质量无法达到客户预期，将它们播出来会对整个产品的体验有比较大的伤害。这就是为什么我们需要将MMatch和PDM技术结合起来。我们需要在庞大的曲库里把合规且质量达标的内容抽取出来，这要求我们具备自动化的能力。在此基础之上，我们再使用MMatch将内容分发出去。

Q：图文匹配是不是可以理解为按照标签匹配图文和音乐？

A：可能这是业界尝试的一种思路，当然我们的研发过程中也会去参考这样的思路。但其实我们初步试验下来发现效果不能满足要求。因为如果我们完全把多模态的特征映射到语义标签上，从表达层面上来讲信息会有很大的缺失，所以做关联的时候准确度就会有比较大的影响。所以我们大致思路是希望通过embedding自我学习、构建的方式把多模态特征映射到同一向量空间里。标签在这个过程中的作用更多是作为额外的先验来引入，比如我们可以把它作为多任务学习的辅助任务，或者在目标上做一些引流等等。

Q：有没有一些关键的论文可供参考？

A：其实刚刚我们也提到了一些baseline，比如音乐匹配中musicnn这一模型。