推02，就算是非技術人員也都有必要了解的一些推薦系統常識

文·HCY崇遠

接上一篇《推01，你們是不是都感覺自己少了個推薦系統？》，上一篇解決的什麼是推薦系統以及為什麼要有推薦系統的問題。這一篇我們關注的是，更細節的一些東西，把推薦系統的一些基礎常識分享給大家。

01 推薦系統概述

在上個章節，我們也大致的提到過，需要先明確的一點就是推薦演算法或者推薦機制並不嚴格等同推薦系統，推薦系統是一個相對複雜的業務系統，裡頭涉及到數據的處理、架構的構成、推薦的邏輯機制，反饋數據的回收、效果的跟蹤、AB測試等等。

並且，很多我們耳熟能詳的推薦演算法，他只是解決的某種特定情況下的推薦機制問題，而整個系統很多時候是複合了多種演算法結果，綜合呈現的一種結果。但可以肯定的是，各種理論邏輯、演算法機制是構建推薦系統的核心支撐，所以，學習推薦系統，首先學習各種推薦演算法並沒有毛病。

推薦演算法概述-基於內容屬性相似的推薦

從原始數據依賴的層面來說，常見的有基於內容屬性的推薦機制，這種推薦邏輯很簡單，只是單純的依賴物品之間的屬性相似來構建推薦關係，容易理解，有時間還是有一定效果的，但實際上很多時候會存在這幾種情況，導致了這種原始推薦失效。

• 如果用戶瀏覽當前的物品本身就不是用戶的菜，甚至是一個非優質信息（當前主體不可控），再基於當前物品進行推薦就是個偽命題。
• 基於上面這條，即使當前主體是用戶的目標，但再推類似主體會造成信息冗餘，即當前主體信息已經解決了用戶的問題。

所以，由於用戶行為的不可控，基於內容屬性相似的推薦，風險還是挺高的，這是導致了這種原始直接的機制並不會得到廣泛的推廣。但與亂推薦相比，還是有一定正向作用的，畢竟用戶瀏覽的主體是自身選擇的結果，本身用戶對於其選擇的信息主體是有一定偏好性的。

推薦演算法概述-基於用戶畫像的推薦

基於物品本身屬性的推薦，其實與個性化是沒有半毛錢的關係的，畢竟推薦候選集只跟物品主體有關，與用戶無關，就談不上什麼個性化了。

而基於用戶畫像（更多人喜歡用基於用戶標籤）的推薦，則更大程度上依賴於用戶的畫像屬性來推薦，這就體現了用戶偏好信息，根據偏好信息來選擇候選集。

這是一種很通用的做法，並且在大規模數據集情況下，很多實際的產生過程中喜歡使用這種機制。而用戶的畫像，或者更具體點用戶的興趣標籤如何構建呢？其實就是依賴用戶累積的行為數據了，通過行為數據生成用戶的興趣標籤。

這看似是一種相對靠譜的做法，畢竟如果把用戶的愛好都分析清楚了，主動給用戶做推薦不就顯得很個性化了嗎？在實際的場景中，首先，並不是所有用戶的行為都足夠用來表徵其興趣偏好的，即我們會高估用戶的行為集合，從而產生有偏差的畫像屬性，更甚者，如果用戶完全沒有行為怎麼辦呢？

其次，通常來說，用戶的興趣愛好是會隨時間遷移而改變的，所以，把我用戶的興趣程度以及其變化並不是一個容易的事情，更何況用戶實際的選擇還會受很多因素影響，比如，我當前查找的一個信息並不是我之前掌握的信息，那意味著這些信息偏好在我的歷史軌跡中都體現不出來，那單純的通過我的興趣去推薦就顯得不靠譜了。

但不管怎麼說，根據用戶的偏好來做推薦，大方向肯定是沒有問題的。

推薦演算法概述-基於協同過濾的推薦

協同過濾，或許了解過推薦系統的的朋友，多多少少都能聽過一些，並且協同推薦可是作為推薦領域典型案例的存在。

協同過濾同樣不會去研究物品的本身屬性，甚至也沒有空去構建用戶的畫像標籤，正如他的名字描述的一樣，他嚴重依靠於用戶的行為以及其周邊用戶的協同行為。舉個例子，為一個用戶推薦信息，那麼我只需要參考其周邊用戶在看什麼信息，就給他推薦什麼信息就好了。

重點在於，如何限定周邊這個範圍，比如根據兩個用戶的行為，去構建相關關係，從而判斷用戶之間的相似程度，把相似用戶的行為推薦給當前用戶，這就是協同中典型的基於用戶推薦。

而如果以物品為維度，以用戶的購買或者觀看記錄為向量，則可以構建物品的相似度量，針對於每一個待推薦選項，用戶的歷史軌跡就是其向量構成，就可以判斷該用戶歷史的軌跡信息與當前的待選物品的向量相關度了，從而判斷是否要推薦，這就是基於物品的協同邏輯。

與基於用戶畫像的推薦對比，這種推薦有一定幾率可以發現新物品，即並不嚴格依賴用戶的興趣。舉個例子，假設幾個信息的層級是ABC，並且ABC是層級遞進關係，並不是同一個東西，對於一個用戶來說，他掌握的是A，則意味著他的興趣偏好大多偏向於A，根據興趣標籤，其實是很難推薦這種遞進相關的信息。

但是，如果其他用戶的學習軌跡都是A->B->C這種軌跡，這意味著ABC三者之間本身就有前後潛在邏輯關係存在的，基於協同，即可為該用戶在掌握A的基礎上，推薦BC的內容，這也是基於興趣所做不到的地方。

當前，基於協同行為的推薦，除了基於物品還有基於用戶，還有其他諸如基於模型的協同，典型如最近鄰模型、基於矩陣分解、以及基於圖關係模型的構建的推薦機制。

推薦演算法概述-其他

其實在我們實際的操作過程中，並不會嚴格的依賴於這種條條框框、只要合理即可行，比如我們完全可以把推薦問題轉化為分類問題，針對於每個待選項，他都是YES OR NO的問題，即一個二值分類。

又比如在上一篇我們學習的一個場景，即閱文網站的小說推薦，還記得他的推薦標題嗎？「喜歡這本書的人還喜歡」，這就是典型的「啤酒與尿布」的解法，即貨架思維，關聯銷售，也是可以作為一種推薦機制而存在的。

在比如微信朋友圈，微信一定是會研究用戶的朋友圈關係的，比如你對哪類朋友點贊、互動行為最多，它是不是會考慮推薦你欣賞的朋友偏好內容給你？畢竟微信是一個典型的熟人社交模型。

所以，推薦演算法看似重要，但其實想想又沒有這麼重要，很多時候並不是一成不變的，都要我們根據場景去考慮，最最最重要的是，需要我們用實際效果來選擇機制，也或許是多種機制共同生效的結果。

02 相似度量

在我們上面的推薦演算法機制中，有個不得不提的操作處理就是各種相似相關度的計算，我們來簡單分享一下幾種相似或者相關度量的方式。

歐幾里得距離(Euclidean Distance

最常見的距離度量方式，衡量多維空間中兩點之間的絕對距離，要求維度的統一。

明可夫斯基距離(Minkowski Distance)

明氏距離是歐氏距離的擴展，是對多個距離度量公式的概括性的表述(可以看到，當p=2時，其實就是歐式距離)。

曼哈頓距離(Manhattan Distance)

曼哈頓距離來源於城市區塊距離，是將多個維度上的距離進行求和後的結果，即當上面的明氏距離中p=1時得到的距離度量。

//還有其他的一些距離度量，但是都不太常用，最常用的依然是歐式距離度量。

向量空間餘弦相似度(Cosine Similarity)

餘弦相似度用向量空間中兩個向量夾角的餘弦值作為衡量兩個個體間差異的大小。相比距離度量，餘弦相似度更加註重兩個向量在方向上的差異，而非距離或長度上。

皮爾森相關係數(Pearson Correlation Coefficient)

即相關分析中的相關係數r，分別對X和Y基於自身總體標準化後計算空間向量的餘弦夾角。基於內容的推薦，還有一點需要注意的就是，對於物品自身屬性，如果屬性值過少，我們需要適當進行擴大維度，如果維度過多，則需要進行降維。

關於降維和升維，都是一個很大的研究方向，大體上可以說一下幾種常見的方式。例如降維，我們可以進行維度聚類、主題抽取，進一步把相關維度進行合併，進一步減少維度；而對於升維，我們可以把維度進行矩陣化，例如假設物品X有A和B兩個維度屬性，那麼我們通過生成A*B矩陣的方式，把維度擴充到A*B個維度。

03 冷啟動問題的解決

所謂冷啟動，即在推薦系統初期時，沒有任何用戶與物品的交集信息，即無用戶的行為軌跡，無法通過類似協同或者用戶偏好等方式進行推薦，這種時候，我們就稱推薦系統處於冷啟動狀態。

這種情況，我們需要儘快的累積起第一批用戶行為軌跡。我們可以通過基於內容的推薦，或者做一些其他類似的操作，快速有效的進行物品推薦。一段時間後，累積到一定的用戶行為時，整個系統就能夠正常使用協同過濾等方式進行推薦了。

但是，針對於新加入的用戶，或者新加入的物品，同樣也是出於冷啟動狀態的，這個時候，我們通過需要對這種物品或者用戶做特殊的處理。

除了基於內容屬性的推薦，我們還有其他的一些策略用於彌補這種行為數據不足的情況，比如典型的熱度模型，推薦熱點信息這種行為雖然low，但是從整體的反饋來看，還是有一定效果的，此外，還可以根據一些統計學上的結論，進行基於統計分析結論的推薦。

除此之外，我們也可以通過其他渠道收集用戶的數據，比如用戶註冊的時候所填寫的個人資料，這些都是可以作為推薦的原始依賴數據。

04 馬太效應

馬太效應或者說長尾效應，即熱者愈熱，實際舉例來說就是，在實際的購買場景中，由於你推薦的次數越多，部分優質的商品購買或者點擊的次數就越多，形成的用戶購買軌跡就越多，所以得到的推薦機會就越多，進而產生的推薦也越多，變得越熱。

隨著不斷迭代，子子孫孫無窮盡也，這樣得到推薦的商品就會集中在少部分商品中，而大部分長尾商品是沉寂的，一個推薦系統如果長時間處於長尾效應中，造成推薦疲勞，其推薦效果就會減弱。

所以，一個好的推薦系統，要考慮到適當的挖掘長尾商品，通過真的個性化，把適當的長尾商品送到真正需要他們的人手裡，在實際的操作過程中，我們可以適當的進行熱度降權，從而讓一些中下層的商品得到更多的曝光機會，當然前提是保證點擊率的情況下。

另外一個場景會形成馬太效應的是熱度模型，即我們的熱度榜單，長時間的高居榜首，一定會獲得更多的點擊，而點擊越多其熱度越高，但我們的信息是需要保持新鮮度的，不然點擊率遲早會下架的。

所以，我們使用一些機制讓處於頭部的商品或者信息降權，時間衰減是一個比較通用的做法，即隨著時間的遷移，其整體熱度會不斷的下降，至於說下降的方式，速率就看模型的設計了。

05 AB測試

關於推薦的效果，之前我們說過其核心的考核標準就是點擊率，點擊的越多說明推薦的越準確，用戶的停留時長也會越長，只要把用戶留在平台中，機會總是會有的。其實就是一層漏斗嘛？這一層的基數越大，下一層轉換的量就會越高，這也是推薦系統的核心存在意義。

並且之前也說到過，一個不好的推薦系統有時間反而會形成反向作用，所以，一個推薦系統的迭代更新至關重要。離線的效果評估一定是要做的，最起碼在離線實驗的階段需要保證當前的效果優於線上效果，才能進行迭代。

但是，實際情況是複雜的，對於推薦的模型來說，離線的實驗其實並沒有想像中靠譜，那麼，就丟到線上去真多真槍的實驗一把，就知道效果了。但是，實際的生產環境中，任何一點轉化波動的影響都是極其嚴重的，誰也不敢拿實際生產開玩笑。

於是，就有了AB測試機制的產生，所謂AB測試機制，即將流量分為AB兩類，A流量走原始的舊模型，B流量走新模型，同步測試同步對比，效果一目了然。

當然，在實際的AB測試流程中，首先流量是可以自由分配的，一般情況下新模型在最終確認之前流量一定是少量的，隨著模型逐漸被驗證，流量比重會逐漸加大，最終確認後流量全部導向新模型，完成新模型的正式上線。

並且，通常，在實際的環境中，或許我們會同時有十多個甚至是幾十個新模型在同時實驗，每個模型調整的因子都不一樣，最終選擇最適合的因素進行調整，達到效果最優，這也就是AB測試機制的魅力所在。

所以，打造一個好的AB測試系統，首先流量是需要可控的，其次模型的迭代上線是需要高度靈活的，最後，肯定是需要有完整的數據回收、數據分析對比機制存在的。

這篇大概就這些了，核心還是一些推薦系統相關知識點，哪怕是非技術人員也是比較容易理解的，並且對於推薦場景，個人認為只要是從業者都應該或多或少了解一些相關的機制。

在下一篇，我們將正式進入到實操層，並且結合實際的推薦案例來學習推薦演算法的流程。

06 相關閱讀

《推01，你們是不是都感覺自己少了個推薦系統？》

關於我：

大數據行業半個老鳥，我家梓塵兄的超級小弟，會敲代碼、會寫文章，還會泡奶粉哄小屁孩。

想和我交流的，可以加我個人微信mute88，可以拉你入交流群，但請註明身份and來意~

如果覺得文章用些用，歡迎分享給你的朋友。