不知道大家有没有关注过你手里的APP，那么它在不停升级中变得越来越懂你，越来越知道你的喜好，举例先：网易云音乐的推荐、今日头条的新闻推荐，他们都是你使用越长时间使用频率越多对你兴趣越准确的判断从而推荐给你符合你心理预期的东西。
那么作为一名设计者这个问题是时候拿出来说说了，不能归于技术类问题，作为交互设计师也有很大一部分需要参与产品架构设计，所以今天我们查了很多资料以飨阅者。
首先资料来源于高质量的讨论社区知乎，我在上面看到一个关于网易云阅读的推荐讨论，http://www.zhihu.com/question/26743347
对于网易云阅读的推荐核心算法就是来源于‘多维空间的两个向量夹角的余弦公式’
那么问题来了 什么是‘多维空间的两个向量夹角的余弦公式’？作为数学渣渣的我怎么才能简单理解其中的核心而不用给我看一堆的数据公式。
核心的公式只有这一个： 夹角余弦 = 向量点积/ (向量长度的叉积) = ( x1x2 + y1y2 + z1z2) / ( 跟号(x1平方+y1平方+z1平方 ) x 跟号(x2平方+y2平方+z2平方 ) ) OH No 我已经晕了。。。
下面是知乎的大神答案
“商品推荐”系统的算法( 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以及自己的像限，找到了一批和自己‘气味相投’的人。
再丛这批人中，选几个‘和我夹角余弦’最大(再综合一下个人名声比如星标，粉丝数，和我的互动度等，更好)的人，
从他们听过而我没听过的歌中，再选一批 他们喜欢，或者他们新听到，新收藏，或者总人气高的等等，
就可以说是“根据我的口味生成”的“每日歌曲推荐”了。
而另外还有一种推荐算法也是来自知乎大神的评论
这里我想给大家介绍另外一种推荐系统，这种算法叫做潜在因子（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有强的相似性：
从推荐的结果来看，正好推荐的是对方评分较高的音乐：
不同的声音
感觉 @邰原朗 的回答的确给出了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(http://en.wikipedia.org/wiki/Tf–idf)。可以说怎样做Normalization才是各大厂家的杀手锏吧，虽然都可能大同小异，但是不同行业还是需要细分。
先别歇下，更多的问题将要来袭:
Similarity的确是非常natural的推荐算法，事实上当数据足够大、足够干净和精确的时候，Simialrity是很难被打败的。但是设想如果是网易音乐发展初期，没有很多用户数据的情况下呢？又如果是网易音乐急速扩张时期，用户数据很多但是很sparse的时候呢？又从用户角度切入，设想是一个刚加入的新用户，并没有其它用户数据来源来提供推荐的情况下呢？这些冷启动问题，又该如何解决呢？难道就应该放弃这些用户？可能我们可以做更多的Trick来调整我们的算法，也可以去尝试更fancy的其他算法，尝试去做Hybrid、fused的系统，但是首先，产品的研发周期会变长，开发投入变大，系统变复杂维护的消耗更大，然后更糟糕的是因为进展缓慢，用户一直看的就是不咋地的推荐，用户开始流失，数据更加稀疏，最后导致恶性循环。
可以移步参考 @pig pig 的答案（网易云音乐的歌单推荐算法是怎样的？ - pig pig 的回答），描述的是multi-tenancy和纯Similarity的其他问题。
工程师的尊严并不是钻牛角尖:
...而是拿出creative的思维来跳出盒子，尝试通过别的途径来解决这些问题。
我们先从做一个首页显示热门榜单开始，这是一个非常容易实现的功能，计数、排序、简单分类：中国、欧美、日本和韩国，按流派也行：流行、摇滚、古典，甚至按年龄段或者群体，不外乎是几个数据库搜索的事情。但是这些热门排行榜却作用非凡，用户可以从中发现当前的大趋势（Trending），比如说，现在张杰比周杰伦风头要盛，听听张杰的看看怎样。由此榜单也能帮助用户发现他本来兴趣圈以外的东西。这么容易实现的功能，却也可以带来不少的好处，属于“low hanging fruit”，没有不摘的理由。
然后我们来聘请一批专业的媒体编辑员，让他们根据我们歌曲库里的内容，生成比较专业的榜单，比如：“高逼格小清新”，“喧嚣中，不妨试的调调” 还有 “被遗忘的经典华语女声”。用过其它的歌曲软件的人估计对这个也不陌生，比如说虾米。这个也能很大程度上帮助用户发现兴趣圈以外的东西，而且由专业人员生成的歌单，更有目的性，比如说你喜欢苏打绿是因为“小清新”，那么在“小清新”的歌单里的，就是一大批高质量的，对你而言非常优秀的推荐了。这样的功能也能很快组织和实现起来，好处也是大大的。
最后，看到了知乎的威力以后，我们考虑做UGC。从做一个简单的UGC功能开始，我们现在另开一个数据库，允许用户保存自己的歌单，并在个人主页推荐这些歌单。同时我们在主页中定期置顶一些访问量较大的歌单。功能上非常容易实现。UGC所激发的用户潜能可以使得用户产生与专业编辑员质量相当的、甚至更高的歌单。功能上的实现实在是再简单不过，效果更是不言而喻。
这时候我们的很大一部分问题得到解决，就算是我们的Similarity所产生的推荐并不是那么好的时候，我们的用户并不会由此而失去发现音乐的途径。听歌的人多了，用户保持engaging，老用户们持续产生高质量的数据，我们之前的个性化推荐算法也能有更好数据来调整参数，从而产生更好的音乐推荐，更好好的用户群体也能推动热门榜单与UGC的发展，进入良性循环。
我希望我阐述清楚了一个好的推荐系统“生态圈”的重要性，算法牛逼的当然有，再牛逼的都有，但是你总要trade-off，总会有不足。现实中，估计很少问题被是“一条路走到黑”地，“简单暴力”地方法解决的吧。
现在再来回顾题主的问题：
“网音给我推荐的歌单几乎次次惊艳，而且大多都没听过，或者好久以前听过早就忘记了名字，或者之前不知道在哪听过 只是知道其中一部分旋律，根本不知道名字，等等，听起来整个人逼格大有提升。”
"我想知道网音的歌单推荐是网音项目团队精心挑选制作的，还是众多音乐达人的推荐？即：歌单是网音官方提供，还是UGC？才有如此对口味的歌单推荐？"
我的猜测(因为我永远不知道答案)是：都有。
我感觉题主描述的就是一个成熟的推荐系统生态圈共同作用的结果，刚刚去看了一下网易云音乐的界面（所幸暂时还没有地区限制），的确也是有这些功能的。（网易云音乐 听见好时光）
题主得到的高逼格推荐，很可能就是最早来源于一个名为“高逼格小清新”专业编辑推荐歌单，有效地引导了兴趣相投的用户去发现这些音乐，大多跟你有相似品味的人都听过并感觉不错，最后还经过fancy算法“沉淀”、“发酵”，产生了很好的相似度，从而生成了了这么优秀的推荐并推送了给了题主。然后题主来知乎发了个帖子，大家被“惊艳”到了，更多的新用户加入，perfect！
最后，如果真的有这么多用户都觉得网易云音乐的推荐都非常“惊艳”的话，那这个产品就实在是太成功了，特别是考虑到“众口难调”的音乐领域。
总结：在阅读了这么多的推荐系统算法的原理之后，对于‘多维空间的两个向量夹角的余弦公式’有了更全面的认识，接下来更多的交互设计需要懂得这个公式并想法设法运用到自家的项目上，交互设计也需要懂点技术不然又被产品狗笑话了。
