码迷,mamicode.com
首页 > 编程语言 > 详细

网易云音乐的歌单推荐算法

时间:2017-06-16 10:18:03      阅读:303      评论:0      收藏:0      [点我收藏+]

标签:产品   个数   品种   评价   标准   三维   github   root   可见   

【转载】原文地址:https://www.zhihu.com/question/26743347

原文:
不是广告党,但我却成为网易云音乐的的重度患者,不管是黑红的用户界面,还是高质量音乐质量都用起来很舒服。我喜欢听歌,几乎每周不低于15小时,但其实听得不是特别多,并没有经常刻意地去搜歌名,所以曲目数量我并不是很在乎。但是比起其它,网音给我推荐的歌单几乎次次惊艳,而且大多都没听过,或者好久以前听过早就忘记了名字,或者之前不知道在哪听过 只是知道其中一部分旋律,根本不知道名字,等等,听起来整个人大有提升。
——————————————————————————————————
问题来了,我想知道网音的歌单推荐是网音项目团队精心挑选制作的,还是众多音乐达人的推荐?即:歌单是网音官方提供,还是UGC?才有如此对口味的歌单推荐?求研究过的大神给出详细解答。
 
_____________________________________________________
作者:nick lee
链接:https://www.zhihu.com/question/26743347/answer/34714804
来源:知乎
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

这里我想给大家介绍另外一种推荐系统,这种算法叫做潜在因子(Latent Factor)算法。这种算法是在NetFlix(没错,就是用大数据捧火《纸牌屋》的那家公司)的推荐算法竞赛中获奖的算法,最早被应用于电影推荐中。这种算法在实际应用中比现在排名第一的

所介绍的算法误差(RMSE)会小不少,效率更高。我下面仅利用基础的矩阵知识来介绍下这种算法。

这种算法的思想是这样:每个用户(user)都有自己的偏好,比如A喜欢带有小清新的吉他伴奏的王菲等元素(latent factor),如果一首歌(item)带有这些元素,那么就将这首歌推荐给该用户,也就是用元素去连接用户和音乐。每个人对不同的元素偏好不同,而每首歌包含的元素也不一样。我们希望能找到这样两个矩阵:

一,用户-潜在因子矩阵Q,表示不同的用户对于不用元素的偏好程度,1代表很喜欢,0代表不喜欢。比如下面这样:

技术分享

二,潜在因子-音乐矩阵P,表示每种音乐含有各种元素的成分,比如下表中,音乐A是一个偏小清新的音乐,含有小清新这个Latent Factor的成分是0.9,重口味的成分是0.1,优雅的成分是0.2……

技术分享

利用这两个矩阵,我们能得出张三对音乐A的喜欢程度是:张三对小清新的偏好*音乐A含有小清新的成分+对重口味的偏好*音乐A含有重口味的成分+对优雅的偏好*音乐A含有优雅的成分+……

技术分享技术分享

即:0.6*0.9+0.8*0.1+0.1*0.2+0.1*0.4+0.7*0=0.69

每个用户对每首歌都这样计算可以得到不同用户对不同歌曲的评分矩阵技术分享。(注,这里的破浪线表示的是估计的评分,接下来我们还会用到不带波浪线的R表示实际的评分):

技术分享

因此我们队张三推荐四首歌中得分最高的B,对李四推荐得分最高的C,王五推荐B。

如果用矩阵表示即为:

技术分享

下面问题来了,这个潜在因子(latent factor)是怎么得到的呢?

由于面对海量的让用户自己给音乐分类并告诉我们自己的偏好系数显然是不现实的,事实上我们能获得的数据只有用户行为数据。我们沿用 的量化标准:单曲循环=5, 分享=4, 收藏=3, 主动播放=2 , 听完=1, 跳过=-2 , 拉黑=-5,在分析时能获得的实际评分矩阵R,也就是输入矩阵大概是这个样子:
技术分享事实上这是个非常非常稀疏的矩阵,因为大部分用户只听过全部音乐中很少一部分。如何利用这个矩阵去找潜在因子呢?这里主要应用到的是矩阵的UV分解。也就是将上面的评分矩阵分解为两个低维度的矩阵,用Q和P两个矩阵的乘积去估计实际的评分矩阵,而且我们希望估计的评分矩阵技术分享
技术分享
和实际的评分矩阵不要相差太多,也就是求解下面的目标函数:
技术分享
这里涉及到最优化理论,在实际应用中,往往还要在后面加上2范数的罚项,然后利用梯度下降法就可以求得这P,Q两个矩阵的估计值。这里我们就不展开说了。例如我们上面给出的那个例子可以分解成为这样两个矩阵:
技术分享这两个矩阵相乘就可以得到估计的得分矩阵:
技术分享将用户已经听过的音乐剔除后,选择分数最高音乐的推荐给用户即可(红体字)。

在这个例子里面用户7和用户8有强的相似性:
技术分享从推荐的结果来看,正好推荐的是对方评分较高的音乐:
技术分享
 
_________________________________________________________________________
收录于 知乎周刊 ·
 

这就是amazon发明的“喜欢这个商品的人,也喜欢某某”算法。
其核心是数学中的“多维空间中两个向量夹角的余弦公式”,当初我的确是被这算法惊艳到了。

=============2014-12-01 更新 =============================
不好意思,之前说的有误,特来更正兼补充。

“商品推荐”系统的算法( Collaborative filtering )分两大类,
第一类,以人为本,先找到与你相似的人,然后看看他们买了什么你没有买的东西。这类算法最经典的实现就是“多维空间中两个向量夹角的余弦公式”;
第二类, 以物为本直接建立各商品之间的相似度关系矩阵。这类算法中最经典是‘斜率=1‘ (Slope One)。amazon发明了暴力简化的第二类算法,‘买了这个商品的人,也买了xxx’。

我们先来看看第一类,最大的问题如何判断并量化两人的相似性,思路是这样 --
例子:
有3首歌放在那里,《最炫民族风》,《晴天》,《Hero》。
A君,收藏了《最炫民族风》,而遇到《晴天》,《Hero》则总是跳过;
B君,经常单曲循环《最炫民族风》,《晴天》会播放完,《Hero》则拉黑了
C君,拉黑了《最炫民族风》,而《晴天》《Hero》都收藏了。

我们都看出来了,A,B二位品味接近,C和他们很不一样。
那么问题来了,说A,B相似,到底有多相似,如何量化?

我们把三首歌想象成三维空间的三个维度,《最炫民族风》是x轴,《晴天》是y轴,《Hero》是z轴,对每首歌的喜欢程度即该维度上的坐标,
并且对喜欢程度做量化(比如: 单曲循环=5, 分享=4, 收藏=3, 主动播放=2 , 听完=1, 跳过=-1 , 拉黑=-5 )。
那么每个人的总体口味就是一个向量,A君是 (3,-1,-1),B君是(5,1,-5),C君是(-5,3,3)。 (抱歉我不会画立体图)
我们可以用向量夹角的余弦值来表示两个向量的相似程度, 0度角(表示两人完全一致)的余弦是1, 180%角(表示两人截然相反)的余弦是-1。

根据余弦公式, 夹角余弦 = 向量点积/ (向量长度的叉积) = ( x1x2 + y1y2 + z1z2) / ( 跟号(x1平方+y1平方+z1平方 ) x 跟号(x2平方+y2平方+z2平方 ) )
可见 A君B君夹角的余弦是0.81 , A君C君夹角的余弦是 -0.97 ,公式诚不欺我也。
以上是三维(三首歌)的情况,如法炮制N维N首歌的情况都是一样的。
假设我们选取一百首种子歌曲,算出了各君之间的相似值,那么当我们发现A君还喜欢听的《小苹果》B君居然没听过,相信大家都知道该怎么和B君推荐了吧。

第一类以人为本推荐算法的好处我想已经很清楚了,那就是精准!
代价是运算量很大,而且对于新来的人(听得少,动作少),也不太好使,
所以人们又发明了第二类算法。

假设我们对新来的D君,只知道她喜欢最炫民族风,那么问题来了,给她推荐啥好咯?
技术分享

如图,推荐《晴天》!

呵呵,第二类算法的好处大家也看出来了,简单粗暴好操作(也适合map-reduce),可精度差了点。

所以,各家网站真正的推荐算法,是他们在综合上述两类算法的基础上,各自研制并且不断地改进调节的,外人不得而知! ^_^

=== 2014-12-03 再补充 ===

多谢 @刘彦彬 给了一个非常专业的评论 ,不贴出来可惜了。
“这个只能说是理论基础。歌曲不考虑热门冷门,同时不考虑用户数和歌曲数计算复杂度的话第一一天内离线数据计算不完的(当然网易云音乐用户量小全量暴力计算当我没说),实际应用起来复杂很多了。现在的推荐系统并不存在一种算法通吃,除了算法上的问题,还需要考虑基础数据的影响因素,比如两张歌单有多少歌曲重合,歌单的质量是怎么样的。”

我上一帖也说了,
‘向量夹角余弦‘ 解决的是‘量化顾客口味相似度’的问题(是最经典的解法,也有别的解法),
不是有了它就能轻易实现第一类算法的,难处在后面咯。
我不是干‘CF/算法/数据挖掘/互联网’的,只是几年前偶尔瞄到过这方面文章被惊艳了一下,
见到这题就随口抖了个机灵,然后被评论区几位带板凳来的朋友给推上来了 ^_^

既然大家都这么有兴趣,我在来抛块砖,说说‘有了理论基础之后咋整’的思(nao3)考(dong4)。
继续第一类算法的话题,目标“每日歌曲推荐”(其实题主感兴趣的是这个吧,旁边‘根据你喜欢的xxx推荐的yyy歌单’我觉得不咋样)。
首先就是如何定维度。
直接用‘歌’当维度是不行的,第一是太多了算不过来,第二维度数一直猛涨也不是个事。
用‘歌单’或者‘专辑’,‘演唱/演奏者’呢?也有类似的困难。
说到这里大家应该都意识到了,咱不是还有‘tag’嘛!
云音乐初期,tag是可以由大家自己填的,我记得我填过‘莫扎特’,‘钢协’,‘交响’这样的tag,现在都不见了吧。
一段时间之后,tag无法自填了,只能从云音乐给的tag lib中选,这肯定有原因的。
我的推测就是,他们需要用tag来当作维度,所以不希望tag数经常变化。
第一阶段,他们需要搜集用户的输入来做出tag lib,
第二阶段,他们构建了多维度空间,就不希望再动维度了,因此关闭了自填tag的功能。

假设就用tag做为维度,那么第二个难处在于,维度上的‘刻度‘必须有正有负才好使,
用户没有机会直接表达对tag的好恶(不能收藏,播放,跳过一个tag),如何定刻度呢。
我认为每一首歌背后是有其所属tags这个属性的,这个属性在UI上看不到很可能是因为比较容易引起口水。
歌往往隶属于很多歌单,而那些歌单都是有tags的,根据那些歌单的播放数收藏数分享数可以决定其‘权威性‘,
取‘权威性‘高的歌单的tag,就可以得到每首歌的tag属性。
然后用户在表达对一首首歌的好恶的时候,其实就不知不觉地影响了他在相应维度上的刻度。

假设维度和刻度都这样解决,那么我们可以对每个用户做出‘口味向量’了,接下来的难处是,
啥时候算/如何保存‘用户相似性’?
所有用户两两算一下相似性,存为一个NxN的矩阵,这种事情不是闹这玩的。

其实到了这一步,不考虑‘以人为本’,直接根据我喜欢的tag,从各tag里挑一些人气高的,或者蹿升快的歌来推荐也算是能交差了。
不过那样的话,就容易同质化,也就不易让用户‘惊艳’了。
让我们继续沿着第一类算法的思路琢磨琢磨。

多维度空间还有一大好处是,有‘像限’这种的概念,
比如我们可以粗暴地假设,和我同一个像限的人,就是和我‘相似’的人,
如果因为维度太多,或者初期用户太少等原因找不到同像限的人, 还可以去‘相邻’的像限找嘛。
OK,假设我们根据tag以及自己的像限,找到了一批和自己‘气味相投’的人。
再丛这批人中,选几个‘和我夹角余弦’最大(再综合一下个人名声比如星标,粉丝数,和我的互动度等,更好)的人,
从他们听过而我没听过的歌中,再选一批 他们喜欢,或者他们新听到,新收藏,或者总人气高的等等,
就可以说是“根据我的口味生成”的“每日歌曲推荐”了。

以上内容,均是臆测,如果雷同,纯属巧合 ^_^
 
https://github.com/grizzlybears
______________________________________________________________________
 
饮和食德
 
 

感觉 @邰原朗 的回答的确给出了CF和Item-based Similarity的很浅显解释,的确也是大多“个性化推荐系统(Personalized Recommendations System)“所使用的算法,但是感觉有点离题和缺乏深度,no offense。

网易内部怎么做到这么好的推荐?在知乎上面问几乎不会得到正确答案的吧,我的答案只是从我的经验出发: “如果设计产品的话,我会这样思考”。

一个优秀的推荐系统不仅仅是个性化算法这么简单 -- 基础的也好,fancy的也好 -- 一个完整的推荐系统体系怎能不提及官方团队推荐(Editorial)、UGC(User-Generated Content)和热门推荐(Top Seller/Trending)的协作呢?


相似度矩阵(Similarity Matrix):

大家提的各种算法里面,几乎都是基于相似度的吧 -- 无论是CF还是Content based产生的相似度,前者需要用户的行为数据,后者需要歌曲的元数据(metadata),比如旋律、Tag等等。具体算法就不再复述了,属于计算机科学的基础内容,很多人都说过了,实现起来简单。虽然很多人给出了沙盒的数据,但是这些数据实在是太好了,虽然不知网易数据的“质”和“量”如何,但是应该不至于这么好(?)。所以,凭单一的方法真的大丈夫吗?

我们先从Similarity的问题说起:

大多数用户一开始会先从自己熟悉的歌曲开始,然后一般都会给出非常相关的推荐,比如你听周杰伦的任何歌曲,他的其他热门歌曲肯定都会非常相关,比如周杰伦的《晴天》,周杰伦的《游园会》,周杰伦的《七里香》,也不失为一个好的推荐。但是你会发现全都是周杰伦,单调死了。全是周杰伦的理由很简单,因为很多用户都连着听下去呀,听完一首周杰伦到下一首周杰伦,听完这个专辑听下个专辑。如果你往后再翻翻,估计还能找到别歌手的歌曲,但是请记着:你的屏幕就这么大,坑就这么多,再好的推荐不能在考前的位置被用户看到和消费到终归也还是扯淡。现在我们来尝试解决这个问题,我们先来做个简单的多样化过滤,我们限制来自同一个歌手的推荐数量,这样后面更多歌手的歌去被推上来了,很好。

现在又一个的问题来了,陈奕迅这时候发新砖了,用户一下子蜂拥去听他的新砖了,包括周杰伦的一众拥趸们也跑去观望了一下,这样的情况持续了一个多月,这下好了,用户看到的推荐里面现在几乎都能看到陈奕迅的这些歌了,尽管他这的歌跟周杰伦的歌原本不至于这么相关。而且由于这个效应,更多的人从推荐里面点进去了听陈奕迅的这些歌,造成了一个恶性循环,使得你的Similarity以为他们真的相关,这时候其他真正相关的优质推荐却被挤压到后面了。我们来尝试解决这个问题,最简单的莫过于是计算相似度的时候过滤掉“过于”热门的歌曲了,把这些歌曲推后吧,感觉问题应该也能解决了。

现在一波未平一波又起,假设现在一个非常优秀的Indie歌手,唱的歌也好有周杰伦的早年的范,反正就是非常相关,周杰伦的歌迷肯定会喜欢那种(对不起实在不熟悉国内歌手,幸亏不是做的这行,这位迷一样的歌手大家请自行脑补)。这位迷一样的歌手刚出道,宣传力度不大,也只有少数几个地方能听到他的歌曲,只有被小数的几个周杰伦迷给发掘出来了,现在问题来了,我们该如何使得这个歌手被发掘出来呢?这个基本上与上一个问题相反,这是冷门的优秀推荐很难被发掘。这时候我们可以用点归一化(Normalization)的小伎俩微调一下。值得一提的是,归一化更能给解决一下上一个提及的太过热门的问题,类似tf-idf(–idf)。可以说怎样做Normalization才是各大厂家的杀手锏吧,虽然都可能大同小异,但是不同行业还是需要细分。

先别歇下,更多的问题将要来袭:

Similarity的确是非常natural的推荐算法,事实上当数据足够大、足够干净和精确的时候,Simialrity是很难被打败的。但是设想如果是网易音乐发展初期,没有很多用户数据的情况下呢?又如果是网易音乐急速扩张时期,用户数据很多但是很sparse的时候呢?又从用户角度切入,设想是一个刚加入的新用户,并没有其它用户数据来源来提供推荐的情况下呢?这些冷启动问题,又该如何解决呢?难道就应该放弃这些用户?可能我们可以做更多的Trick来调整我们的算法,也可以去尝试更fancy的其他算法,尝试去做Hybrid、fused的系统,但是首先,产品的研发周期会变长,开发投入变大,系统变复杂维护的消耗更大,然后更糟糕的是因为进展缓慢,用户一直看的就是不咋地的推荐,用户开始流失,数据更加稀疏,最后导致恶性循环。

可以移步参考

的答案(网易云音乐的歌单推荐算法是怎样的? - pig pig 的回答),描述的是multi-tenancy和纯Similarity的其他问题。

工程师的尊严并不是钻牛角尖:

...而是拿出creative的思维来跳出盒子,尝试通过别的途径来解决这些问题。

我们先从做一个首页显示热门榜单开始,这是一个非常容易实现的功能,计数、排序、简单分类:中国、欧美、日本和韩国,按流派也行:流行、摇滚、古典,甚至按年龄段或者群体,不外乎是几个数据库搜索的事情。但是这些热门排行榜却作用非凡,用户可以从中发现当前的大趋势(Trending),比如说,现在张杰比周杰伦风头要盛,听听张杰的看看怎样。由此榜单也能帮助用户发现他本来兴趣圈以外的东西。这么容易实现的功能,却也可以带来不少的好处,属于“low hanging fruit”,没有不摘的理由。

然后我们来聘请一批专业的媒体编辑员,让他们根据我们歌曲库里的内容,生成比较专业的榜单,比如:“高逼格小清新”,“喧嚣中,不妨试的调调” 还有 “被遗忘的经典华语女声”。用过其它的歌曲软件的人估计对这个也不陌生,比如说虾米。这个也能很大程度上帮助用户发现兴趣圈以外的东西,而且由专业人员生成的歌单,更有目的性,比如说你喜欢苏打绿是因为“小清新”,那么在“小清新”的歌单里的,就是一大批高质量的,对你而言非常优秀的推荐了。这样的功能也能很快组织和实现起来,好处也是大大的。

最后,看到了知乎的威力以后,我们考虑做UGC。从做一个简单的UGC功能开始,我们现在另开一个数据库,允许用户保存自己的歌单,并在个人主页推荐这些歌单。同时我们在主页中定期置顶一些访问量较大的歌单。功能上非常容易实现。UGC所激发的用户潜能可以使得用户产生与专业编辑员质量相当的、甚至更高的歌单。功能上的实现实在是再简单不过,效果更是不言而喻。

这时候我们的很大一部分问题得到解决,就算是我们的Similarity所产生的推荐并不是那么好的时候,我们的用户并不会由此而失去发现音乐的途径。听歌的人多了,用户保持engaging,老用户们持续产生高质量的数据,我们之前的个性化推荐算法也能有更好数据来调整参数,从而产生更好的音乐推荐,更好好的用户群体也能推动热门榜单与UGC的发展,进入良性循环。

我希望我阐述清楚了一个好的推荐系统“生态圈”的重要性,算法牛逼的当然有,再牛逼的都有,但是你总要trade-off,总会有不足。现实中,估计很少问题被是“一条路走到黑”地,“简单暴力”地方法解决的吧。

现在再来回顾题主的问题:

“网音给我推荐的歌单几乎次次惊艳,而且大多都没听过,或者好久以前听过早就忘记了名字,或者之前不知道在哪听过 只是知道其中一部分旋律,根本不知道名字,等等,听起来整个人逼格大有提升。”

"我想知道网音的歌单推荐是网音项目团队精心挑选制作的,还是众多音乐达人的推荐?即:歌单是网音官方提供,还是UGC?才有如此对口味的歌单推荐?"

我的猜测(因为我永远不知道答案):都有。

我感觉题主描述的就是一个成熟的推荐系统生态圈共同作用的结果,刚刚去看了一下网易云音乐的界面(所幸暂时还没有地区限制),的确也是有这些功能的。(网易云音乐 听见好时光

题主得到的高逼格推荐,很可能就是最早来源于一个名为“高逼格小清新”专业编辑推荐歌单,有效地引导了兴趣相投的用户去发现这些音乐,大多跟你有相似品味的人都听过并感觉不错,最后还经过fancy算法“沉淀”、“发酵”,产生了很好的相似度,从而生成了了这么优秀的推荐并推送了给了题主。然后题主来知乎发了个帖子,大家被“惊艳”到了,更多的新用户加入,perfect!

最后,如果真的有这么多用户都觉得网易云音乐的推荐都非常“惊艳”的话,那这个产品就实在是太成功了,特别是考虑到“众口难调”的音乐领域。
_______________________________________________________
4396
 
 

最近研读了下「集体智慧编程」,书中提供了完整的推荐算法介绍。个人参照其中,并模拟网易云音乐的情景来举些例子(全文所有数据虚构,仅供参考)。

在详细介绍推荐算法前,要提一下协作型过滤(Collaborative Filtering)的概念:协作型过滤算法会通过对一大部分人进行搜索,从中发现与我们品味相近的一小部分人。算法会对这些人所偏爱的其他内容进行考查,并将它们组合起来构造出一个经过排名的推荐列表。有许多方法来帮助我们确定哪些人与自己的品味更加相近,在本文中我们将提到两种方法来实现这个目的,基于用户的协作型过滤和基于物品的协作型过滤。

我们先从更易理解的基于用户的协作型过滤开始。

基于用户的协作型过滤的流程至少包括以下四个步骤:
  1. 建立评价规则
  2. 搜集用户偏好
  3. 寻找相近的用户
  4. 推荐歌曲

1.建立评价规则
下图是我随意做的一个评价规则。评价规则应该根据明确的用户行为来建立。
技术分享

需要特别注意的是,这个评价规则是可以随着开发者收集到数据和侧重点的不同进行变更(当然不能频繁变更)。

2.搜集用户偏好
根据评价规则,我们可以得到每个用户和该用户相关的每首歌的一个得分。 下图也是我随意造的数据。
技术分享

3.寻找相近的用户
常用的计算相似度评价值的体系有两种:欧几里得距离和皮尔逊相关度。

欧几里得距离非常直观。我们以经过人们一致评价的物品为坐标轴,然后将参与评价的人绘制到图上,并考查他们彼此间距离的远近,如下图:
技术分享

(用R简单地画一下,莫吐槽太丑)

再次强调,欧几里得距离评价的核心是距离,这与票数第一名答案(

)中用角度余弦值来评价有本质区别。

相比欧几里得距离,皮尔逊相关度评价是一种相对复杂一些的方法。它通过计算两组数据与某一直线拟合程度的相关系数,来判断两个对象的兴趣相似度。虽然皮尔逊相关度评价比欧几里得距离评价的计算公式更复杂一些,但是它在数据不是很规范的时候(比如对甲乙做比较,甲的用户偏好评分普遍高,乙则相反,用欧几里得距离评价的结果通常南辕北辙)往往能给出更好的结果。

我们以做对比的两者分别为坐标轴,在图中标出两者对共同音乐的评分情况。如下图所示。

技术分享

根据周杰伦和那英的用户偏好,《真的爱你》分别得分为3分和3分,因此《真的爱你》定位在图的(3,3)处。

图中的虚线是最佳拟合线(本例中我采用的是OLS模型。绘制原理简言之,就是让这条线尽可能地靠近图上所有的数据点)。如果两位用户对所有歌曲的偏好情况都相同,那么这条直线将成为对角线,并且会与图上所有的数据点相交,从而得到一个结果为1的李响相关度评价。第一幅偏好空间的相关系数较低,下面是一个相关系数较高的例子。

技术分享

采用皮尔逊相关度评价的一个明显好处是,它修正了“夸大分值(grade inflation)”的情况。在第二幅偏好空间中,虽然汪峰总是倾向于给出比周杰伦更高的分值,但最终的虚线几乎是拟合的,这是因为他们两者有着相对近似的偏好。而皮尔逊相关度评价的结果是否就是我们想要的结果,取决于具体的应用场景。

4.推荐歌曲
接下来系统要做的就是,为用户郑昊提供歌曲推荐。我们当然可以查找与郑昊品味最相近的人,从他所喜欢的歌曲中找出一首郑昊可能还未接触过的歌曲。不过,这样的做法未免太随意了。

目前最通用的做法是,通过一个经过加权的评价值来为歌曲打分,评分结果即排名结果。为此,我们需要取得所有其他用户的分数,借此得到相关系数后,再乘以他们与相关歌曲的分数,求和之后再除以对应的相关系数总计,便能获得一个我们需要的评价值。在下表中我们给出了具体的做法。

技术分享

「相关系数」一列来自于皮尔逊相关度评价。「歌名」对应各用户的得分来自评价规则处理后的结果。将前两者一一对应相乘,便是「歌N*相关系数」的值。如此一来,相比于与我们不相近的人,那些与我们相近的人将会对整体评价值拥有更多的贡献。总计一行给出了所有加权评价值的总和。

我们可以用总计值来计算歌曲排名,但是我们还需要考虑到,这样人数会对一首歌的得分产生正相关影响。为了避免这一问题,我们需要将总计除以相关系数总计。相关系数总计等于所有对这首歌曲有影响的用户的相关系数之和。表中最后一行就是我们所需要的结果。

接下来,我们来介绍基于物品的协作型过滤。

如果将基于用户的协作型过滤简述成如下形式:

网易云音乐用户甲->偏好相近用户->相关歌曲->推荐列表。

那么基于物品的协作型过滤也可以简述成如下形式:

1.歌曲A->相关用户->相关歌曲->推荐列表;
2.网易云音乐用户甲->偏好歌曲->推荐列表。

步骤1是对任意一歌曲进行数据抓取,找到相关用户和这些用户的偏好数据,再去得到相关歌曲信息,获取与该歌曲相近的最优推荐。由于与用户无关,所以步骤1可以安排在网络流量不是很大的时候进行,或者在独立于主应用之外的另一台计算机上单独进行。这里的歌曲A可能是任一一首歌。步骤1承担了大部分的运算工作。

步骤2在用户甲有相关需求时发生,通过获取用户甲的偏好歌曲和步骤1的结果,就能找到给用户甲的歌曲推荐。
__________________________________________________________
 
知乎用户
 
 

首先,推荐算法有三种常用的基本套路
1、基于内容的推荐(content-based filtering)。 引用

的解释,是音乐信息检索的领域,学术上一般content-based是特指音频内容本身的,主要涉及feature extraction,专辑、歌手和歌词等基于text或tags的因素,通常用来与content相结合来提高检索效率的。
2、基于协同过滤推荐(collaboration filtering)。基于广义的排行榜行和热门排行进行推荐。
3、社会化推荐(social recommendation)。基于关系的推荐。

推荐系统能实施起来的两大前提,1)信息过载;2)需求不明确(明确需求请找搜索引擎)。

2011年的Recsys大会专门邀请了Pandora的研究人员对音乐推荐进行了演讲。演讲人总结了音乐推荐的如下特点。
物品空间大 物品数很多,物品空间很大,这主要是相对于书和电影而言。
消费每首歌的代价很小 对于在线音乐来说,音乐都是免费的,不需要付费。
物品种类丰富 音乐种类丰富,有很多的流派。
听一首歌耗时很少 听一首音乐的时间成本很低,不太浪费用户的时间,而且用户大都把音乐作为背景声音,同时进行其他工作。
物品重用率很高 每首歌用户会听很多遍,这和其他物品不同,比如用户不会反复看一个电影,不会反复买一本书。
用户充满激情 用户很有激情,一个用户会听很多首歌。
上下文相关 用户的口味很受当时上下文的影响,这里的上下文主要包括用户当时的心情(比如沮丧的时候喜欢听励志的歌曲)和所处情境(比如睡觉前喜欢听轻音乐)。
次序很重要 用户听音乐一般是按照一定的次序一首一首地听。
很多播放列表资源 很多用户都会创建很多个人播放列表。
不需要用户全神贯注 音乐不需要用户全神贯注地听,很多用户将音乐作为背景声音。
高度社会化 用户听音乐的行为具有很强的社会化特性,比如我们会和好友分享自己喜欢的音乐。
上面这些特点决定了音乐是一种非常适合用来推荐的物品。

Pandora背后的音乐推荐算法主要来自于一个叫做音乐基因工程的项目。这个项目起始于2000年1月6日,它的成员包括音乐家和对音乐有兴趣的工程师。Pandora的算法主要基于内容,其音乐家和研究人员亲自听了上万首来自不同歌手的歌,然后对歌曲的不同特性(比如旋律、节奏、编曲和歌词等)进行标注,这些标注被称为音乐的基因。然后,Pandora会根据专家标注的基因计算歌曲的相似度,并给用户推荐和他之前喜欢的音乐在基因上相似的其他音乐。

Last.fm于2002年在英国成立。Last.fm记录了所有用户的听歌记录以及用户对歌曲的反馈,在这一基础上计算出不同用户在歌曲上的喜好相似度,从而给用户推荐和他有相似听歌爱好的其他用户喜欢的歌曲。同时,Last.fm也建立了一个社交网络,让用户能够和其他用户建立联系,同时也能让用户给好友推荐自己喜欢的歌曲。和Pandora相比,Last.fm没有使用专家标注,而是主要利用用户行为计算歌曲的相似度。

--------------------------分割线:以上科普源自项亮的《推荐系统实践》-----------------------
目前大部分做推荐的应用推荐逻辑应该都是多种逻辑并行。
编辑推荐和用户推荐的歌曲一般会有专门的版块展示。
个性化推荐理论上来讲都是通过算法直接从大库里面由程序产出的。
1)冷启动的时候基于热度的推荐会比较多,推荐流行热点音乐总是不会错的。
2)在用户使用一段时间,用户行为达到一定样本量以后,程序开始通过内容和社交关系逻辑产出内容,并且与热门内容按照一定比例推送给用户。
用户所有的行为(包括下载/喜欢,评论,播放完成度,播放次数等等)都会以不同的权重呈现在后续的推荐逻辑中。

至于准确不准确,合不合口味这个事情,与推荐算法的关系其实是不大的。做内容推荐的关键是内容质量是否过关。也就是音乐库里面对不同歌曲,不同歌手的音乐基因标记的是否正确,是否够专业,我觉得Jing.FM是近两年相对专业一些的个性化电台。
__________________________________________________________
 
作者:知乎用户
链接:https://www.zhihu.com/question/26743347/answer/34480706
来源:知乎
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

最近几天刚好在做网易云的推荐歌单分析。说一点自己的看法吧。

熟悉网易云的人都知道,歌单的推荐有两种,第一种是推送是每日推荐歌曲,第二种是推送歌单组合。

一、每日歌曲推荐:

好吧这里应该有结论:

1、 网易云的推荐算法基础是基于协同过滤,极大可能有通过标签二次过滤。

2、 推荐系统分析的行为有播放、下载、收藏歌曲。可能存在行为叠加。

3、 对用户不完整播放的行为不敏感,这个应该算是缺点吧。

4、 总的来说,推得还算准确。但是推荐算法不算太先进。大家觉得准确,可能是由于网易云使用的用户人群属性较单一,对于推荐算法来说这样的人群是十分理想的。QQ音乐新猜你喜欢,自我颠覆的个性化推荐系统,有兴趣可以去参考下QQ音乐的推荐系统,在对用户行为的分析上,会更完善。

推荐的依据,官方声称的是由试听记录、收藏歌曲、收藏歌手进行推荐的。而事实上,能产生用户兴趣的行为,可能会包括:试听歌曲、收藏歌曲、收藏歌手、收藏专辑/歌单、搜索、关注用户、下载歌曲。所以新建了些空白样本在网易云的web端做了个测试。

技术分享

可以看出,网易收集的用户行为有包括:试听、喜欢、下载。官方声称的根据歌手推荐没有返回结果。

而当中,有试听的情况,推荐系统的反应是最好的,有推荐歌曲的入口跟推荐的歌单。而下载及收藏歌曲其次,没有推荐入口放出,但是用url访问地址,有推荐的歌曲。所以可以试试判定在行为分析上,网易云的权重是:试听 > 喜欢 > 下载。

这有点不符合常理,因为普遍觉得喜欢跟下载,是一种更强烈能反应出用户兴趣的行为。所以截包分析了一下,发现在每次播放结束后,会向服务器传递一个行为记录。当中会对用户兴趣产生影响的有:是否完整播放及播放的时长,歌曲的来源。所以觉得,在推荐行为里面可能的权重为(按用户操作的成本):

下载+播放 > 喜欢+播放 > 搜索+播放 > 播放 > 下载 > 喜欢

然后,再来看一下有推荐结果的行为:

技术分享

目测第二天的数据是没上传到给服务器,或者推荐的算法权重判断上,对某些歌曲的播放次数会比是否最近播放更优先。

再看一组播放数据:

技术分享

这次可以确定,用户2第二天的数据是没上传成功了。推荐系统对是否最近播放的反应很敏感,对主动中止播放这个行为不敏感。这里应有吐槽,因为切歌算是一种用户主动不喜欢的行为,理想的推荐结果,应为全部都是纯音乐。

技术分享

最后纯喜欢/下载的用户,推荐的歌曲还算准确。但是4个用户的结果加起来,感觉在推荐出来的歌曲风格上十分单一。所以怀疑,推荐系统运转先是基于协同过滤,然后可能存在标签矫正的机制。也有可能是通过歌手这个纬度的矫正,因为这样的成本没标签高。



二、歌单推荐:

歌单推荐相对于歌曲推荐算法会简单很多。主要的逻辑会有:

技术分享

1、 可能喜欢的歌曲,是经过试听记录去判定的,多次听一首歌,推荐系统就会判定你可能喜欢这首歌。

2、 其实歌曲,都可以分解成一个很大的标签集的(粤语、摇滚、快歌…),能归类进一个歌单里面,直接通过单曲去索引歌单,对用户兴趣的命中率也很高。QQ的专辑推荐也还是基于这个。

3、 准不准的结论不好给,推荐给我的歌单,其实在自己常用帐号还是偶尔能发现不错的。起码比QQ的好了。

 
=================================================
 
=================================================
 
谨以此文献给天下的老师和孩子们。
谨以此文献给那个阳光帅气的小师弟。
谨以此文献给那些勇敢的男孩子们,和那些飘逸的女孩子们。爱你。
 
==================================================
2017年6月16日
于南湖湖畔
==================================================

网易云音乐的歌单推荐算法

标签:产品   个数   品种   评价   标准   三维   github   root   可见   

原文地址:http://www.cnblogs.com/sddai/p/7021885.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!