網易雲音樂的歌單推薦演算法是怎樣的？
不是廣告黨，但我卻成為網易雲音樂的的重度患者，不管是黑紅的用戶界面，還是高質量音樂質量都用起來很舒服。我喜歡聽歌，幾乎每周不低於15小時，但其實聽得不是特別多，並沒有經常刻意地去搜歌名，所以曲目數量我並不是很在乎。但是比起其它，網音給我推薦的歌單幾乎次次驚艷，而且大多都沒聽過，或者好久以前聽過早就忘記了名字，或者之前不知道在哪聽過 只是知道其中一部分旋律，根本不知道名字，等等，聽起來整個人大有提升。
——————————————————————————————————
問題來了，我想知道網音的歌單推薦是網音項目團隊精心挑選製作的，還是眾多音樂達人的推薦？即：歌單是網音官方提供，還是UGC？才有如此對口味的歌單推薦？求研究過的大神給出詳細解答。
這裡我想給大家介紹另外一種推薦系統，這種演算法叫做潛在因子（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君推薦了吧。
第一類以人為本推薦演算法的好處我想已經很清楚了，那就是精準！
代價是運算量很大，而且對於新來的人(聽得少，動作少)，也不太好使，
所以人們又發明了第二類演算法。
如圖，推薦《晴天》！
呵呵，第二類演算法的好處大家也看出來了，簡單粗暴好操作(也適合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以及自己的像限，找到了一批和自己『氣味相投』的人。
再叢這批人中，選幾個『和我夾角餘弦』最大(再綜合一下個人名聲比如星標，粉絲數，和我的互動度等，更好)的人，
從他們聽過而我沒聽過的歌中，再選一批 他們喜歡，或者他們新聽到，新收藏，或者總人氣高的等等，
就可以說是「根據我的口味生成」的「每日歌曲推薦」了。
感覺 @邰原朗 的回答的確給出了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！
最後，如果真的有這麼多用戶都覺得網易雲音樂的推薦都非常「驚艷」的話，那這個產品就實在是太成功了，特別是考慮到「眾口難調」的音樂領域。反正我是服氣的。
在私人 FM 里，聽到一首很喜歡的歌，只有幾個人評論，打開就看到了前男友的評論，以及……
私信發現真的是同一個前男友！
真的是相似的人會喜歡同樣的歌呢。
同時也挺感慨，雖然有的感情會讓你哭，但是在一起都是有原因的呀。
這個故事到這裡應該還是個溫馨愉快的小故事。
直到我發現 @Pippa 是個 98 年的漂亮姑娘，
而 90 年出生的我，已經是個 27 歲的阿姨了。
首先，推薦演算法有三種常用的基本套路
1、基於內容的推薦（content-based filtering）。 引用 @JerryJazzy 的解釋，是音樂信息檢索的領域，學術上一般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）在用戶使用一段時間，用戶行為達到一定樣本量以後，程序開始通過內容和社交關係邏輯產出內容，並且與熱門內容按照一定比例推送給用戶。
用戶所有的行為（包括下載/喜歡，評論，播放完成度，播放次數等等）都會以不同的權重呈現在後續的推薦邏輯中。
最近研讀了下「集體智慧編程」，書中提供了完整的推薦演算法介紹。個人參照其中，並模擬網易雲音樂的情景來舉些例子（全文所有數據虛構，僅供參考）。
在詳細介紹推薦演算法前，要提一下協作型過濾（Collaborative Filtering）的概念：協作型過濾演算法會通過對一大部分人進行搜索，從中發現與我們品味相近的一小部分人。演算法會對這些人所偏愛的其他內容進行考查，並將它們組合起來構造出一個經過排名的推薦列表。有許多方法來幫助我們確定哪些人與自己的品味更加相近，在本文中我們將提到兩種方法來實現這個目的，基於用戶的協作型過濾和基於物品的協作型過濾。
我們先從更易理解的基於用戶的協作型過濾開始。
基於用戶的協作型過濾的流程至少包括以下四個步驟：
- 建立評價規則
- 搜集用戶偏好
- 尋找相近的用戶
- 推薦歌曲
1.建立評價規則
下圖是我隨意做的一個評價規則。評價規則應該根據明確的用戶行為來建立。
需要特別注意的是，這個評價規則是可以隨著開發者收集到數據和側重點的不同進行變更（當然不能頻繁變更）。
需要特別注意的是，這個評價規則是可以隨著開發者收集到數據和側重點的不同進行變更（當然不能頻繁變更）。
2.搜集用戶偏好根據評價規則，我們可以得到每個用戶和該用戶相關的每首歌的一個得分。 下圖也是我隨意造的數據。
3.尋找相近的用戶
常用的計算相似度評價值的體系有兩種：歐幾里得距離和皮爾遜相關度。
（用R簡單地畫一下，莫吐槽太丑）
（用R簡單地畫一下，莫吐槽太丑）
再次強調，歐幾里得距離評價的核心是距離，這與票數第一名答案（@邰原朗）中用角度餘弦值來評價有本質區別。
相比歐幾里得距離，皮爾遜相關度評價是一種相對複雜一些的方法。它通過計算兩組數據與某一直線擬合程度的相關係數，來判斷兩個對象的興趣相似度。雖然皮爾遜相關度評價比歐幾里得距離評價的計算公式更複雜一些，但是它在數據不是很規範的時候（比如對甲乙做比較，甲的用戶偏好評分普遍高，乙則相反，用歐幾里得距離評價的結果通常南轅北轍）往往能給出更好的結果。
我們以做對比的兩者分別為坐標軸，在圖中標出兩者對共同音樂的評分情況。如下圖所示。
根據周杰倫和那英的用戶偏好，《真的愛你》分別得分為3分和3分，因此《真的愛你》定位在圖的(3,3)處。
圖中的虛線是最佳擬合線（本例中我採用的是OLS模型。繪製原理簡言之，就是讓這條線儘可能地靠近圖上所有的數據點）。如果兩位用戶對所有歌曲的偏好情況都相同，那麼這條直線將成為對角線，並且會與圖上所有的數據點相交，從而得到一個結果為1的李響相關度評價。第一幅偏好空間的相關係數較低，下面是一個相關係數較高的例子。
採用皮爾遜相關度評價的一個明顯好處是，它修正了「誇大分值（grade inflation）」的情況。在第二幅偏好空間中，雖然汪峰總是傾向於給出比周杰倫更高的分值，但最終的虛線幾乎是擬合的，這是因為他們兩者有著相對近似的偏好。而皮爾遜相關度評價的結果是否就是我們想要的結果，取決於具體的應用場景。
4.推薦歌曲
接下來系統要做的就是，為用戶鄭昊提供歌曲推薦。我們當然可以查找與鄭昊品味最相近的人，從他所喜歡的歌曲中找出一首鄭昊可能還未接觸過的歌曲。不過，這樣的做法未免太隨意了。
目前最通用的做法是，通過一個經過加權的評價值來為歌曲打分，評分結果即排名結果。為此，我們需要取得所有其他用戶的分數，藉此得到相關係數後，再乘以他們與相關歌曲的分數，求和之後再除以對應的相關係數總計，便能獲得一個我們需要的評價值。在下表中我們給出了具體的做法。
「相關係數」一列來自於皮爾遜相關度評價。「歌名」對應各用戶的得分來自評價規則處理後的結果。將前兩者一一對應相乘，便是「歌N*相關係數」的值。如此一來，相比於與我們不相近的人，那些與我們相近的人將會對整體評價值擁有更多的貢獻。總計一行給出了所有加權評價值的總和。
我們可以用總計值來計算歌曲排名，但是我們還需要考慮到，這樣人數會對一首歌的得分產生正相關影響。為了避免這一問題，我們需要將總計除以相關係數總計。相關係數總計等於所有對這首歌曲有影響的用戶的相關係數之和。表中最後一行就是我們所需要的結果。
接下來，我們來介紹基於物品的協作型過濾。
如果將基於用戶的協作型過濾簡述成如下形式：
網易雲音樂用戶甲-&>偏好相近用戶-&>相關歌曲-&>推薦列表。
那麼基於物品的協作型過濾也可以簡述成如下形式：
1.歌曲A-&>相關用戶-&>相關歌曲-&>推薦列表；
2.網易雲音樂用戶甲-&>偏好歌曲-&>推薦列表。
步驟1是對任意一歌曲進行數據抓取，找到相關用戶和這些用戶的偏好數據，再去得到相關歌曲信息，獲取與該歌曲相近的最優推薦。由於與用戶無關，所以步驟1可以安排在網路流量不是很大的時候進行，或者在獨立於主應用之外的另一台計算機上單獨進行。這裡的歌曲A可能是任一一首歌。步驟1承擔了大部分的運算工作。
步驟2在用戶甲有相關需求時發生，通過獲取用戶甲的偏好歌曲和步驟1的結果，就能找到給用戶甲的歌曲推薦。最近幾天剛好在做網易雲的推薦歌單分析。說一點自己的看法吧。
熟悉網易雲的人都知道，歌單的推薦有兩種，第一種是推送是每日推薦歌曲，第二種是推送歌單組合。
一、每日歌曲推薦：
好吧這裡應該有結論：
1、 網易雲的推薦演算法基礎是基於協同過濾，極大可能有通過標籤二次過濾。
2、 推薦系統分析的行為有播放、下載、收藏歌曲。可能存在行為疊加。
3、 對用戶不完整播放的行為不敏感，這個應該算是缺點吧。
4、 總的來說，推得還算準確。但是推薦演算法不算太先進。大家覺得準確，可能是由於網易雲使用的用戶人群屬性較單一，對於推薦演算法來說這樣的人群是十分理想的。QQ音樂新猜你喜歡，自我顛覆的個性化推薦系統，有興趣可以去參考下QQ音樂的推薦系統，在對用戶行為的分析上，會更完善。
推薦的依據，官方聲稱的是由試聽記錄、收藏歌曲、收藏歌手進行推薦的。而事實上，能產生用戶興趣的行為，可能會包括：試聽歌曲、收藏歌曲、收藏歌手、收藏專輯/歌單、搜索、關注用戶、下載歌曲。所以新建了些空白樣本在網易雲的web端做了個測試。
可以看出，網易收集的用戶行為有包括：試聽、喜歡、下載。官方聲稱的根據歌手推薦沒有返回結果。
而當中，有試聽的情況，推薦系統的反應是最好的，有推薦歌曲的入口跟推薦的歌單。而下載及收藏歌曲其次，沒有推薦入口放出，但是用url訪問地址，有推薦的歌曲。所以可以試試判定在行為分析上，網易雲的權重是：試聽
&> 喜歡
&> 下載。
這有點不符合常理，因為普遍覺得喜歡跟下載，是一種更強烈能反應出用戶興趣的行為。所以截包分析了一下，發現在每次播放結束後，會向伺服器傳遞一個行為記錄。當中會對用戶興趣產生影響的有：是否完整播放及播放的時長，歌曲的來源。所以覺得，在推薦行為裡面可能的權重為（按用戶操作的成本）：
下載+播放 &> 喜歡+播放 &> 搜索+播放 &> 播放 &> 下載 &> 喜歡
然後，再來看一下有推薦結果的行為：
目測第二天的數據是沒上傳到給伺服器，或者推薦的演算法權重判斷上，對某些歌曲的播放次數會比是否最近播放更優先。
再看一組播放數據：
這次可以確定，用戶2第二天的數據是沒上傳成功了。推薦系統對是否最近播放的反應很敏感，對主動中止播放這個行為不敏感。這裡應有吐槽，因為切歌算是一種用戶主動不喜歡的行為，理想的推薦結果，應為全部都是純音樂。
最後純喜歡/下載的用戶，推薦的歌曲還算準確。但是4個用戶的結果加起來，感覺在推薦出來的歌曲風格上十分單一。所以懷疑，推薦系統運轉先是基於協同過濾，然後可能存在標籤矯正的機制。也有可能是通過歌手這個緯度的矯正，因為這樣的成本沒標籤高。
二、歌單推薦：
歌單推薦相對於歌曲推薦演算法會簡單很多。主要的邏輯會有：
1、 可能喜歡的歌曲，是經過試聽記錄去判定的，多次聽一首歌，推薦系統就會判定你可能喜歡這首歌。
2、 其實歌曲，都可以分解成一個很大的標籤集的（粵語、搖滾、快歌…），能歸類進一個歌單裡面，直接通過單曲去索引歌單，對用戶興趣的命中率也很高。QQ的專輯推薦也還是基於這個。
3、 準不準的結論不好給，推薦給我的歌單，其實在自己常用帳號還是偶爾能發現不錯的。起碼比QQ的好了。
我們肯定用的不是同一個軟體，每天早上打開看一眼推薦歌單，然後默默地自己去找歌單聽了。。。。
前幾天組內分享，碰巧輪到在網易雲音樂做推薦演算法的同學。聽了分享後，我的感受是，網易雲音樂的推薦演算法雖然和其他各種FM有類似之處，但是仍然有幾個地方做的很有想像力。
1. 冷啟動
如果你使用微博賬號登陸的，將會從你的微博信息為你生成個性化的初始歌單，讓你有種眼前一亮的感覺。因此初期口碑極好，極大地降低了用戶獲取成本。
2. 歌單的設計
用戶喜歡一個口味歌曲，是否就要一個勁的拚命給用戶只推送這種歌曲？網易雲音樂的歌單推薦採取了更加溫和、適度的做法。第一，歌單長度至多二十首，求精不求多；第二，在保證音樂口味方向大體一致的前提下，將各種風格上略有不同的歌曲合理組合，和春晚的節目編排是一個道理，不單調的組合可以有效降低用戶對於節目的厭煩感。
3. 推薦理由
在個性化推薦區域，都會有「根據根據你喜歡的單曲XXX推薦」的字樣。據說在演算法、數據都不變的情況下，只是加上這一行理由說明，就可以讓用戶留存率提高10%。
以上。
…我們用的真的不是同一個軟體，最近一周都沒有聽到中意的歌
------------------------------------------------------------------------------------------
2014.12.01更新，才注意到這張圖，我用網易雲音樂有兩個月
要知道，這136首歌大約有70首是我自己搜出來標註的,也就是我平均聽19首歌才能喜歡一首，19這個數字不太嚇人，但是最近一周都沒有中意的，這個就不太好了
要知道，這136首歌大約有70首是我自己搜出來標註的,也就是我平均聽19首歌才能喜歡一首，19這個數字不太嚇人，但是最近一周都沒有中意的，這個就不太好了
---------------------------------------------------------------------------------------------2015.04.04數據
先說下冷啟動,冷啟動問題就是解決新用戶,新歌曲的推薦問題.一個新用戶過來,網站對其一無所知,如何進行推薦,一首新歌,在用戶數據的積累上也是一片空白,應該把它推薦給誰.
對音樂網站來說,這幾個問題都不算是大問題,特別是itembase的演算法,只要一有行為,就會有推薦產生,作為音樂本身,經過一小段時間的積累,就會在數據上有相似的音樂產生
音樂是個難以琢磨的東西,但是還是可以從一些描述中看出端倪,用一些人工的維度進行區分,比如歌手,比如語言,比如風格.網易在冷啟動問題上,我猜測也使用了決策樹的方式對各個音樂的標籤進行篩選,通過分裂最大熵的標籤來篩選用戶的初始口味.什麼叫最大墒?籠統的說,現在有這麼幾個標籤,快歌,重金屬,輕音樂.我只能問你一個問題,然後就需要對你進行推薦,也就是說,哪個標籤可以最快速的切分用戶?假設我們有10w首歌曲,有快歌標籤的有5w首,重金屬有2w首,輕音樂有1w首.那麼我第一個問題就是"你喜歡挺快歌嗎?"這樣的劃分就是墒最大的劃分,如果還能再問一個問題,假設在快歌里有1w首是重金屬,1k的輕音樂,那麼下一個問題就是你喜歡重金屬嗎?以此類推,如果都是2分問題的話,5個問題就可以把用戶分成32類,平均下來每一類就是3.125%,算是很細緻的了.
有了初始化的測試,就可以按照標籤來進行推薦了.
那我們再來搞清楚一個問題,y do we use tag to recommend?
當我們描述一道菜的時候,會用一大堆的形容詞,比如說辣的,甜的,脆的,軟的.像初戀一樣的,這些都是從食物里提取出來的特徵,用來描述一道菜是什麼樣子的.音樂也是一樣,,快歌,重金屬,輕音樂都是tag,用來描述一首歌曲.有了tag就可以把一首歌進行抽象,不然計算機怎麼知道這首歌到底是一首什麼歌呢?(還有一種方法就是進行音樂指紋的提取,這又是另一種思路了),那麼在計算機看來呢,每一首歌就是一堆tag的向量,such as 我的滑板鞋的tag 假設是 (作者,曲風,時長,熱門程度,等等等),tag的生成可以是用戶ugc標記,也可以由編輯在上傳歌曲的時候標記上,這些問題都不大.
tag怎麼用?
用了tag之後,計算機就能描述一首音樂了,於是你就去聽了幾首歌,這時候,歌曲本身是含有tag的,這些tag就可以描述你,那麼餘弦也好,皮爾遜也好,一大堆相似度演算法就可以用上了,通過tag中介,就可以計算聽者和聽者的相似度,歌和歌的相似度,也可以直接用tag進行推薦
當然這個是非常之粗糙的,但是用來作冷啟動還是不錯的.
再讓我們想一想,描述一首音樂一定要使用tag嗎?還有什麼可以作為維度來描述這首音樂的?
答案就是人,所有的人都是音樂的一首維度,我的滑板鞋子的維度就是(丁磊喜歡,馬雲不喜歡,羅永浩沒聽過),反過來,音樂也是人的維度丁磊(我的滑板鞋,你的滑板鞋,他的滑板鞋),這樣一來,省掉了一大堆編輯tag的時間,同時增加的是運算量,處理的方式和用tag是類似的.
在一個用戶有了一定的行為之後,我們用他聽的歌來描述他,而不是抽取的tag來描述他,這樣在原來的基礎上更近了一步,但是這樣和真是的情況相比如何呢?
可以試著來回答一個問題:
Why do you listen to this song?
A回答,因為是孫燕姿唱的,B回答,音樂是慢歌,C回答,因為不好聽
我想回答是千奇百怪的,而這些正是用戶聽一首歌的真正原因,這是不是和tag又有點相似?好像饒了一圈又回來了,不得不承認,聽某一首歌曲的人會有很多原因,但是往往原因不太多,就像很多人會去看羅永浩的微博,但是原因往往五花八門,為老羅洗地的有,黑的有,還有根本不知道他是什麼東西的也有.使用tag有2個很重要的毛病,一個是維度有限,因為都是人工創造的,不能覆蓋所有的情況,有可能漏掉很重要的維度,第二個毛病是維度的權重沒辦法定義,就像去老羅的微博,洗地的權重,黑的權重,其他人的權重又是多少,這些都是tag沒辦法給出的.
假設我們有一個辦法可以找到事實背後的隱含變數,那麼一切都會迎刃而解
矩陣分解降維的方法就可以完美的解決這個問題,把用戶和音樂分配到各個維度上,假設是1000個,那麼這時相當於有1000個標籤,但是這些標籤不是人工打上去的,而是降維降出來的,所謂降維,原來我們把每個用戶作為一個維度去描述一首歌,現在把這些用戶合併合併,抽象抽象,選擇其中的共性,降到1000維,並且這1000維都是有各自的權重的,舉個例子,我的滑板鞋子(走掉30%,有趣30%,勵志20%),就變成這樣了,最為關鍵的一點在於,這樣出來,用戶和音樂的維度被統一了,這個就超級屌了,原來的推薦要麼是計算人與人之間的相似度,再過度到音樂,或者是通過音樂之間的相似度,進行類比推薦,矩陣分解可以從人通過隱藏維度直接到音樂,並且隱藏維度的權值都是可以算出來的,簡直逆天了.
再換一個思路來看這個問題,我是一個網站的所有者,我並不知道你為什麼去聽一首音樂,我是一個觀察者,我看了太多的人的歌單,幾百萬的,幾千萬,甚至是每天幾億的流水,如果有在商場賣過東西的人一定有這種體會,什麼樣子的搭配是經常出現的,一個老道的銷售人員就是被每天的流水給磨練出來的,買煙的人,配一個打火機應該是個常見的搭配,每天煙和打火機一起結賬的情景不斷的鍛煉著一個銷售人員,那麼從中也可以獲取有用的信息.
so,thats create a super Music editor
也就是說把每天的音樂流水給我們創造出來的超級音樂編輯看,看看他能記住什麼.
用神經網路的方法就可以來製作這個東西了.
我們構造一個神經網路,所有的人都在對他進行訓練,神經網路就像一個結賬人員,把所有人的歌單都看在眼裡,經常一起出現的音樂,就會觸動那根特殊的神經,並進行強化,那麼當你聽取了幾首歌之後,我們的超級編輯就會根據你觸動的神經,推薦同樣觸動了這些神經的歌曲啦~
演算法啥的我不懂，所以這方面還請大神解答。
講點自己的體驗:市面上一些主流的播放軟體大多數都陸陸續續地用過，排除那些個XX音樂還有前面某些童鞋說的落網，我個人覺得知乎上現在用的主流音樂軟體是以下三個:
網易雲，豆瓣，蝦米
這三者都有所謂的推薦歌單功能，根據我個人的主觀體驗，豆瓣的演算法最粗，應該是按照音樂里的大類來進行推薦的，比如我聽了一首董小姐，豆瓣會有一定的幾率推薦我聽在人民廣場吃炸雞，但是這兩者風格又相差很大，但是由於都被分在了民謠之下，所以。。。
民謠還好但是搖滾就差太多了。
________________________________________________________________
蝦米的每日推薦歌單系列是我個人比較喜歡的【終於露出主觀婊的本質了呵呵呵】，其實不難看出，蝦米也是按照類的相似度來進行計算然後推薦歌給你的，但蝦米的類會分的細緻的多，然後再加上你喜歡的歌手的所屬大類，【具體的肯定還要複雜的多】比如我聽了一首wonderwall，它就會給我推薦一系列的OASIS,BLUR，PULP等英倫搖滾分類下的歌，如果我再聽了一些JB，也許下次我會聽到COLDPLAY【這樣黑真的好么。。我只是開個玩笑大家不要當真】。
有時候它也會給我帶來一些驚喜，比如去年在蝦米不經意的聽到了八哥的嗓音，然後就欲罷不能啊嗷嗷嗷，總之在蝦米每次推薦的歌單里我都能發現一點小驚喜。
BUT蝦米的隨機推薦有一個硬傷就是每次打開的都不一樣啊，真的是隨機的！！有時候手一滑等待你的又是新的一份歌單啊有木有！！對於我這種手滑黨真是一件憂傷的事啊，工程師請聽到我的聲音好嘛！
【這特么寫的都像蝦米的軟文了，歡迎支付寶】
—————————————————————————————————————
下面說網易雲。用網易雲的時間短，也就大半年左右的時間。
我和網易雲邂逅的經歷是這樣的:年初的時候我入了一個IPAD，然後想找一個APP聽歌，然後我理所當然的想到了蝦米，但是蝦米沒有ipad客戶端啊，用XX音樂什麼的又覺得太low【裝B遭雷劈啊】，然後我的眼神又不經意的落在了去年音樂節順回來的網易雲徽章上，然後又想起了丁磊養豬的新聞。。【泥垢了】總之，我最後在平板上成功的裝上了網易雲。
都說了這麼多廢話了，我直接跳到網易雲推薦的歌單部分吧。網易雲每日推薦的歌單數量不多，但是剛好，不會產生聽太多聽膩的感覺，每天就只有20幾首哦，聽完了就沒有了哦，趕快來聽哦╭(╯ε╰)╮ 而另兩個則是想聽多少聽多少。
另外來談談聽感。網易的歌單我覺得是最保守的，之所以有人會覺得網易雲推薦的歌單非常准，那是因為這個歌單里有一大半都是你自己最近剛聽過的歌，只不過換了這個歌手的另一首歌給你，就比如我自己最近常聽小鼓，第二天網易雲的歌單里就會有25％小鼓的歌，然後剩下的是你再往前一段時日里被標的喜歡歌手的類似，再加上些你自己也不知道什麼時候標記的紅心歌曲，然後剩下的是一些一般普通人都不會特別討厭的打榜熱歌，比如I"m yours 之類的大神曲兒。。所以你說這樣的一份歌單能不對你胃口嘛？
當然了，從聽感來說這份歌單還是很舒服的，但是局限性也是同樣不可避免的。
但是網易雲在人性化這方面做的還是很不錯的，一些小編做的專題（在這裡私心推薦下空虛小編，萌萌噠的妹紙），音樂人的專訪，包括資源的更新及時度和稀有度【李志的腦殘粉你們都懂的，但是現在蝦米也有李志了。。另外我還在網易找到過蔣勛的全集，這個是其他網站都沒有的，我很喜歡】，UI的美觀度等等，都足以使我對網易雲的好感不斷上升。。
但是從個性化歌單本身來說，網易雲在這塊做的並不夠好。
【當然也可能是我聽的歌不夠多╭(╯^╰)╮】
純屬個人感受， 答的有點偏題，看心情更新【主要是一些證據更新，包括歌單截圖等】
另外看在我手機打了那麼多字的份上給個贊好么【暴露騙贊黨本質】，么么噠╭(╯ε╰)╮
以上
作為同樣是音頻行業搞精準化的產品經理，稍微幫你理一下推薦歌單簡單的相關推薦思路，理論上簡單復現不難。
首先是精準化推薦的幾個數據前提：
1.網易收集了用戶每日播放的聲音記錄。
2.網易收集了用戶關注的用戶、點贊、評論、下載的聲音、分享的聲音/歌單、收藏的歌單。
3.用戶在網易雲音樂上有持續行為，網易數據團隊背後有模型計算你對歌曲和歌單的評價值。
4.網易的歌曲屬於一個或多個歌單
然後是精準推薦的幾個基礎方法，下面只指出歌單推薦的可行方法：
1.contend-based，基於內容的推薦。這個比較簡單，每首歌單擁有語種、場景、風格、情感、主題多種tag，如果你仔細觀察的話，會發現基本上網易推送給你的歌單或者推薦歌單都有1個或者多個tag；利用你平時對歌單的播放傾向性、收藏歌單傾向性不難獲得你對特定幾個tag的傾向性，這種情況下推薦特定幾個tag或者組合的歌單基本都能滿足你基本需求。實際上這種偏向性也可以成為你用戶標籤的基礎。在新聞領域運用tf-idf弄出文章關鍵詞然後給你推薦其實也是類似的方法，當然背後還有詞義間的關係演算法。實際上，包含的聲音所屬的專輯的tag，歌手的tag也可以一併繼承使用。這套實際也就是國外pandora用的打標籤推薦方法。
2.協同過濾亞馬遜和電商用濫的方法了，item-based，利用用戶收聽歌單的行為計算歌單之間的相似度，推薦給你你喜歡的歌單相似的歌單 / user-based, 利用用戶收聽歌單行為計算用戶之間的相似度，推薦給你和你相似的用戶喜歡的歌單
3.利用用戶數據進行用戶分群和內容分群，然後對於初始用戶利用決策樹，提供幾個歌曲進行口味調試，自動將你劃定到預定的幾個分類群去，然後按照分類群的用戶風格進行推送。
4.利用喜歡歌曲、收藏歌手與歌單的關係進行相關推薦，比較簡單粗暴的方法。歌單中包含了你喜歡的歌曲，同時有一部分你沒聽過的歌曲，由於歌單是用戶按照某種邏輯編輯在一起的，其可能符合你的要求。
簡單拋磚引玉而已，如有錯誤請不吝指出
精準化推薦不是單純的技術問題，需要一直進行產品迭代。像網易私人FM、每日推薦歌曲實際都屬於精準化推薦產品，但是背後的邏輯處理其實是基於一些基礎演算法基礎上的不斷調整。實際技術開發重點和體驗重點都有所不同。
某天一打開就給我推薦了【腦殘遊記】這首歌，我也好想好想問一下程序員匹配的是什麼欄位
小明養了一條狗，此為背景。
推薦演算法1：小明喜歡吃肉，狗喜歡吃肉。但狗還喜歡吃屎。此時，系統要不要把屎推薦給小明呢？
推薦演算法2：狗買了肉，還買了屎。接著，小明買了肉，此時系統發現，買了肉的狗，還買了屎。此時，系統要不要把屎推薦給小明？
推薦演算法3：狗買了屎。由於狗住在小明房子里，和小明是同一個IP。小明購物時，系統發現這個IP曾經買過屎，因此，系統要不要把屎推薦給小明？
推薦演算法4：狗的電腦壞了，借用小明的賬號買了屎。從此以後，小明瀏覽的網頁中，只要包含某寶或某東的廣告時，就會發現這些廣告都在一個勁兒地推薦屎。個人感覺：網易雲音樂不僅是靠演算法，還有來自其它影音提供商的大數據。
不談演算法，找個輕鬆的思路，把握住聽音樂過程中的 人，歌單，歌曲，歌手 這幾個實體基本上就能了解這幾個推薦位的推薦邏輯了。
這個臨時找的二部圖可以代表用戶和音樂（用戶和歌手，或歌單和歌曲等簡單關係）的關係，可以擴展往右擴展。最直接的推薦就是通過和你有共同相連節點來擴展你可能的感興趣的歌曲了。
在推薦系統的初期中，實體 就夠用。
可以看到 下面三個推薦位置就是尋找相似歌單（根據包含歌曲就ok了）。每日推薦就是根據你最近播放偏好從用戶-歌手，歌手-歌曲，歌曲-歌曲等二部圖中找到相關的就ok啦。上面的fm，顯然是每日推薦坑位不夠咯，可以給重度用戶更多的推薦增加驚喜。
每天都要長按標記不感興趣，第二天那些歌單還是會出現在我的主頁辣我的眼睛
這演算法就是垃圾
跟雲音樂的內置的音樂圈裡的曲庫君聊天她會很認真回復你的… 這麼認真的軟體想推薦幾個你喜歡聽的歌還不容易？
我就想問問客服 我就是收藏了一個 貼膜歌
為什麼之後給我推薦的歌單 都如此多嬌
讓我不禁跟著音樂 扭動搖擺了起來
貼 貼 貼膜boy
推薦閱讀：