網易雲推薦演算法

Ⅰ 個性化推薦演算法

隨著演算法的普及，大量的產品有了個性化推薦的功能，這也成為內容類產品的標配。個性化定製化逐漸成為了互聯網思維的新補充，被提升到了越來越重要的地位。演算法推薦經過了很長一段時間的發展，才逐漸達到能給用戶驚喜的階段。比如在電商領域，推薦演算法可以挖掘用戶潛在購買需求，縮短用戶選取商品的時間，提升用戶的購物體驗；在新聞或段視頻領域，推薦演算法可以推送用戶喜歡的內容，提高用戶的閱讀效率，減少用戶選擇內容的時間，也增加了用戶在產品上的停留時長。

演算法應用階段

內容類產品發展初期，推薦演算法一般為「熱度演算法」，就是系統把熱點內容優先推薦送給用戶，完成熱點內容的高閱讀率。在積累了一定的用戶數據後，會發現用戶閱讀內容過於集中於熱點信息，長尾信息中的優質資源往往被忽略，造成資源浪費。「千人一面」的狀況已不是一個優質的解決方案，所以演算法逐漸演變為「個性化推薦」，也就是協同過濾的方法論支撐下的一種演算法。協同過濾能很好的根據用戶的喜好，推薦匹配的內容，減少資源浪費，增加用戶使用的友好體驗。真正做到「千人千面」。

推薦演算法的信息來源

第三方數據

一個新系統在初期沒有數據積累的情況下，可與第三方合作，互授部分信息共享。比如，很多系統支持微信登陸，這時候可以獲取客戶的微信信息，生活地點，部分生活習慣等。同時會獲取用戶的社交信息，共同好友越多表明圈子越相似，可以推薦更多相似的內容。

用戶行為數據

記錄用戶在系統內的使用習慣，可以准確的描述單個用戶的行為特徵，愛好特徵等有效的信息，系統根據提取出的分析結果，將內容與之匹配，完成更精準的推薦。如，某用戶經常瀏覽體育信息，系統將對應推薦更多體育相關的咨詢，省去用戶搜索篩選的時間。

基於生活習慣

基於生活習慣，生活常識的推薦，往往也可以作為內置的一個信息來源途徑。比如，外賣的app推薦用戶的餐廳，一般默認是位置優先，就近推薦，如果是快中午的時間段使用，系統默認推薦午餐，其次是晚餐。靠生活常識作出的系統演算法，可以更符合人類的習慣，給用戶更好的體驗。

熱度演算法

熱度演算法簡單的說就是把最核心的內容優先推薦，用新聞舉例，每一條新聞都具有實效性，隨著時間的推移，該條新聞的關注度降低，關注點被新的熱點新聞取代。量化以上的過程，把各個影響因素設定為變數，會得出以下的公式：

新聞熱度=初始熱度分+用戶交互熱度分-衰減熱度分

初始熱度分為新聞產生時，系統對新聞主體的預判熱度值。預判的分值一般為以下兩種模式，一種情況，按照新聞類別的不同，娛樂新聞大於財經新聞，大於國際新聞，大於文化新聞等等系統的預設，依次給出不同的初始熱度分；另一種情況，系統預置熱詞詞庫，用新聞的關鍵詞和詞庫的去匹配，匹配度高的，初始熱度分高。

用戶的交互熱度分也是一個變數，先要明確用的哪些行為會影響新聞熱度，然後對這些行為量化，加權或打分等方式。例如，網易雲音樂，用戶的聽歌，重復循環，收藏，評論，分享等行為，系統為每一種行為打分，求和後得出用戶交互的熱度分：

用戶交互熱度分=聽歌X10+循環X5+收藏X10+評論X5+分享X3

此公式還可以繼續細化，每一種操作的分值也可以作為變數，在產品前期時，傳播產品為主要任務，所以分享的加權要大一些，隨著網易雲的發展，社區的概念逐漸強化，評論區互動的加權會加大，所以評論的分值會增加，系統隨時調整分數加權，得出更准確的用戶交互的影響值。

衰減熱度分是一個隨時間變化而變化的數值，往往是一個函數的表達。用新聞舉例，新聞的熱度會隨著時間的推移而衰減，並且趨勢是越來越快，人們在接受新的熱點後，迅速忘記「舊聞」，直至熱度趨近於零。根據理論數據，構建函數，准確的表達衰減分值。

還有很多其他的影響因素，比如傳播次數，傳播層數，停留時長等等，都會影響熱度值，要想更精準的表達，就需要把涉及到的因素都作為變數，不斷完善演算法，才能更精準的完成推薦。

個性化推薦演算法

隨著用戶量的增加，產品日活的增加，用戶也不能僅限於千人一面熱點閱讀的模式中，個性化推薦在此時顯得尤為重要。個性化推薦有兩種常見的解決方案，一種是基於內容的推薦演算法，推薦內容往往是根據用戶的使用習慣得來，較為精準；另一種是基於用戶的協同推薦演算法，系統會根據以往使用內容，為用戶建模，然後根據群體中個體的使用習慣，推薦更多超預期的內容，達到預測推薦的效果。

基於內容的推薦演算法-預期內

基於內容的推薦演算法，靠收集用戶的使用習慣，進而推薦相關的內容。系統使用分詞庫匹配、關鍵詞匹配等等方式，達到內容的匹配，做到內容的精確劃分。比如，用戶瀏覽了某部科幻電影，系統就會按照該電影所對應的標簽，如科幻，然後系統推薦相同標簽的影片給用戶。

這樣的推薦方案，確定性強，推薦的內容都是根據用戶的歷史來確定，不能挖掘用戶的潛在需求。

基於用戶的協同推薦-超預期

做到精準推薦後，系統會繼續挖掘更潛在的推薦需求，給用戶超預期的推薦體驗。這就到了基於用戶協同推薦的階段。簡單的說，這種演算法是增加了用戶建模的環節，將同標簽的用戶群分，對比群體中單個個體的特徵，默認這種特徵為這類人的潛在特徵，再將此特徵內容推薦給同標簽的用戶，達到超預期的推薦效果。

比如，某用戶購買了一個蘋果手機，系統會將此用戶歸類為果粉，系統識別出很多果粉除了買蘋果的商品，還會購買小米作為備用機，這個特徵會被系統識別為潛在需求，推薦給果粉，減少果粉選擇備用機的時間。

這樣的推薦演算法，不僅能完成精準的推薦，還能給用戶小驚喜，讓系統「有溫度」。但是這樣的推薦方式，往往需要積累了大量用戶資料為基礎，才可以精確的完成。

Ⅱ 網易雲的音樂推薦演算法適用於其他軟體嗎

好像是也比較適合用於其他的一些軟體，但是也需要把這個音樂推薦演算法重新改正一下，只需要稍微修改就適合其他軟體了。

Ⅲ 網易雲音樂的歌單推薦演算法是怎樣的

「這個只能說是理論基礎。歌曲不考慮熱門冷門，同時不考慮用戶數和歌曲數計算復雜度的話第一一天內離線數據計算不完的（當然網易雲音樂用戶量小全量暴力計算當我沒說），實際應用起來復雜很多了。現在的推薦系統並不存在一種演算法通吃，除了演算法上的問題，還需要考慮基礎數據的影響因素，比如兩張歌單有多少歌曲重合，歌單的質量是怎麼樣的。」 我上一帖也說了，'向量夾角餘弦' 解決的是『量化顧客口味相似度』的問題(是最經典的解法，也有別的解法)，不是有了它就能輕易實現第一類演算法的，難處在後面咯。繼續第一類演算法的話題，目標「每日歌曲推薦」(其實題主感興趣的是這個吧，旁邊『根據你喜歡的xxx推薦的yyy歌單』我覺得不咋樣)。首先就是如何定維度。 直接用『歌』當維度是不行的，第一是太多了算不過來，第二維度數一直猛漲也不是個事。用『歌單』或者『專輯』，『演唱/演奏者』呢？也有類似的困難。說到這里大家應該都意識到了，咱不是還有『tag』嘛！雲音樂初期，tag是可以由大家自己填的，我記得我填過『莫扎特』，『鋼協』，『交響』這樣的tag，現在都不見了吧。一段時間之後，tag無法自填了，只能從雲音樂給的tag lib中選，這肯定有原因的。我的推測就是，他們需要用tag來當作維度，所以不希望tag數經常變化。第一階段，他們需要搜集用戶的輸入來做出tag lib，第二階段，他們構建了多維度空間，就不希望再動維度了，因此關閉了自填tag的功能。假設就用tag做為維度，那麼第二個難處在於，維度上的'刻度'必須有正有負才好使，用戶沒有機會直接表達對tag的好惡(不能收藏，播放，跳過一個tag)，如何定刻度呢。我認為每一首歌背後是有其所屬tags這個屬性的，這個屬性在UI上看不到很可能是因為比較容易引起口水。歌往往隸屬於很多歌單，而那些歌單都是有tags的，根據那些歌單的播放數收藏數分享數可以決定其'權威性'，取'權威性'高的歌單的tag，就可以得到每首歌的tag屬性。然後用戶在表達對一首首歌的好惡的時候，其實就不知不覺地影響了他在相應維度上的刻度。假設維度和刻度都這樣解決，那麼我們可以對每個用戶做出『口味向量』了，接下來的難處是，啥時候算/如何保存『用戶相似性』？所有用戶兩兩算一下相似性，存為一個NxN的矩陣。