推薦系統從入門到 Spark 案例實踐
課程介紹
隨著移動網際網路的高速發展，網際網路所承載的資訊呈爆炸式增長，而我們所能接觸的資訊量也急速增長，並且隨著移動網際網路的進一步發展，使用者時間高度碎片化，如何在最短的時間內，快速抓住使用者焦點、提升產品粘性、提升使用者體驗成了重中之重。
而設計合理的推薦系統恰巧能很好的解決當前的難題，進行使用者個性化的捕獲、提升資訊觸達的精度、縮短使用者與所需資訊之間的路徑、提升使用者的體驗。
所以，推薦系統已經成為了線上視訊、電商、線上音樂、內容資訊等各個領域的標配，無論是技術人員還是產品經理，掌握以及瞭解推薦系統的知識體系已經成為了一個迫切的需求。
本課程的核心思路在於如何從零構建一個完整的推薦系統，並且將會以容易理解的陳述方式，來講解推薦系統的需求背景、涉及到的一些基礎知識、常用的演算法策略、工程架構、涉及到的產品思維以及評估體系等。整個課程內容都在圍繞如何構建以及認識推薦系統這麼一個常見的產品形態為準，期間還會結合 Spark 工程案例進行深入講解，理論與實踐結合，幫助大家快速提升。
作者介紹
黃崇遠，畢業於哈工大，6 年多大資料以及網際網路從業經驗。目前為 SEE 小電鋪大資料主管，負責公司整個資料團隊建設以及資料服務體系搭建。大資料原創公號『資料蟲巢』（ID：blogchong），在大資料架構、大資料應用挖掘、資料產品化以及大資料團隊建設等方面有一定的積累。
課程內容
導讀：推薦系統正成為所有領域的一種標配
為什麼推薦系統越來越大行其道
近段時間團隊在擴建演算法小組，首當其衝的崗位就是推薦演算法工程師，然而歷經一、兩個月的招聘後，卻發現一個事實，推薦演算法工程師太難招了。
要麼根本就約不過來，要麼就是手裡握著好幾個 Offer 騎驢找馬不亦樂乎，又或者是給人家發了 Offer，人家根本就不 care。
是的，推薦演算法工程師，又或者說演算法工程師已經成了一個香饃饃，進一步看招聘市場不難發現，各家都在搶演算法以及推薦演算法相關的人才。自己隨便做的一個 App，如果沒有個性化推薦的智慧元素，似乎已經拿不出手，不好意思說出去。
這確實是事實，推薦系統已變得越來越大行其道。
人們的耐心正在逐漸的降低
隨著移動網際網路的進一步發展，從各種各樣的渠道不難發現，人們的注意力正在不斷的從 PC 端往移動端遷移。
而我們知道，對於移動端，人們的使用時間是高度碎片化的，這與我們移動端的使用場景有關，這就意味著，對於任何 App 或者相關的應用，很難維持使用者長時間的集中在應用中。
除此之外，雖然中國的基礎技術建設方面依然落後於美國等發達國家，但是據傳聞中國的網際網路應用已經走在了世界的前列，美國很多公司已經在複製中國網際網路企業模式。換種角度說，在國內，各類應用的開發已經到了“喪心病狂”的地步了，即你會發現各個領域，應用的同質化已經非常嚴重。
上述的兩個重大原因，會讓使用者在單一的應用中，其停留的時間以及注意力將會越來越少，這也就是為何說，人們的耐心正在逐漸的降低。
每個 App 或者說應用都面臨著一個問題，那就是如何在最短的時間內抓住使用者的焦點，來提升使用者的體驗。
面臨海量資訊選擇困難症，如何快速的為使用者篩選有效以及有用資訊成為了首要解決的問題，於是，能夠理解使用者以及用於替代海量資訊平鋪陳列的推薦模式成為了潮流。
資訊獲取的兩種機制
具體聊推薦系統之前，我們先來了解一下獲取資訊的兩種基本機制，第一是主動獲取，第二是被動獲取。
主動獲取資訊很容易理解，我們是抱著很明顯的目的去執行，即在獲取資訊之前對於將要獲取的資訊已經有了比較明確的定義，在我們去觸達的時候，會有比較明確的思路，以及對於即將要獲取的資訊所付出的成本也有一定的心理預期。
主動獲取資訊
對於資訊主動獲取的方式，最典型的有兩種，一個是搜尋，另一個是導航。
對於搜尋，想必大家能最快想到的就是國產大百度，其次便是搜尋界一霸谷歌。百度和谷歌通過解決使用者的資訊主動檢索問題，便能成就一個產業，所以對於資訊主動獲取的需求是很巨大的。
對於另一個主動資訊獲取的方式，即導航。在門戶時代，入口網站的分門別類的各色頻道，以及頻道下對應的各級選單其實就是一種導航，再到目前國內遙遙領先世界的電子商務領域，其各色平臺，少不了的就是類目導航。
導航提供的是一種通用的目錄結構，人們通過對資訊的認知，再結合通用的樹狀結構，逐步檢索到自己需要的資訊。
同樣，通過導航獲取資訊的方式也需要花費巨大操作成本（與搜尋相比），但在主動需求的平衡中，這種成本的支出是可預期的。
被動獲取資訊
但是很遺憾，對於大部分的場景中，至少過半的使用者並不是抱著一個很明確的目的去使用的，大部分都是一種隨意看看、隨便逛逛的心態，這就意味著被動資訊獲取的場景我們同樣需要去滿足。
雖然使用者是隨便看看、隨便逛逛，但作為被逛的主體方可不能帶著這種心態，我們必須在使用者的隨便行為中，把使用者給牢牢吸引住，不然就不知不覺地給逛走了。
這就涉及到了被動資訊獲取機制中的推薦系統。對於使用者來說，推薦是一種被動的行為，主體方意圖通過推薦的方式將最吸引使用者或者說使用者最可能感興趣的東西被動呈現給使用者。
通過推薦的方式，縮短使用者與其潛在需求資訊的路徑，從而提升使用者的體驗、提升使用者的粘性。
搜尋有大百度、大谷歌，但也不要小看推薦系統這種模式的魅力，除非各色各樣非典型非代表性的推薦案例，這兩年來今日頭條就是依靠推薦引擎起家的，硬生生成為了資訊分發領域裡的一霸，包括我們的大百度也在玩命的在其搜尋 App 中或者應用中做個性化的資訊流，意圖切分一份蛋糕。
除此之外，還有一個典型的推薦案例，那就是微信生態中的朋友圈廣告，實際上也是一個典型的推薦案例，微信通過對於推薦以及社交關係的研究，大大提升了其廣告投放的準確率，一方面不至於浪費流量，另一方面也不會讓使用者產生過多的厭惡感，畢竟瞎推亂搭的資訊對於使用者的體驗傷害還是很大的。
推薦系統的場景
在上面，我們對於推薦系統的大致市場行情以及推薦產生的背景，以及分析資訊獲取的幾種機制，最終我們確定推薦系統確實是一個剛需。現在具體來看看一些常見的推薦系統場景，以及分析其具體能解決什麼問題。
通過下面的幾個例子，我們對於推薦系統場景化的認識或許可以加強，以及具體推薦以一種什麼樣的形態去展現。
線上視訊領域
這是騰訊視訊某個視訊播放頁的推薦場景，在我截圖的時候，當前播放主頁是《蜘蛛俠3》，我們再來結合當前主體資訊來推斷其推薦列表的演算法機制，不難發現其屬性相關佔比的權重會比較大，所謂屬性相關即與當前主體的相關屬性，諸如同一系列、同個主題、同個導演等諸如此類。
當然，這裡我們只是做一個場景的熟悉，並不是要去評估一個推薦列表的好壞，那是後幾個章節需要做的事。
但需要順帶說一下的就是，一個完整的推薦系統，推薦演算法並不是它的全部，甚至很多時候一個推薦列表的生成也並不單純的依賴於某個推薦演算法。
整個推薦系統，承載演算法的模型層只是其中最重要的一環，除此之外還有整個演算法架構、工程架構、策略引擎，甚至包括推薦系統中涉及的一些產品思維，這些在本系列中將會逐一進行闡述。
線上音樂領域
我們再來看一下騰訊體系下其他的推薦場景，諸如 QQ 音樂平臺的歌單推薦。
具體說根據什麼邏輯進行的推薦，以及推薦的是否合理，有沒有點選的慾望等，這裡暫時不做評論。
網路文學領域
除了視訊音樂領域，我們再來看看網文文學領域，這是同屬大騰訊體系下的起點中文網圖書主頁的推薦列表。
從其推薦理由的設計來看，其推薦列表的生成與當前書本的關聯性會比較大，以及通過觀測與當前主體的屬性關聯性也很強。
不難發現，上述列了三個不同領域，三個不同推薦場景其推薦欄位的欄位名稱，我們一般更喜歡稱其為推薦理由，都是不盡相同的，推薦理由是推薦系統中的一個重要組成成分，甚至很多時候會在推薦轉化的過程中，起到重要的作用，在後續章節裡，涉及到推薦產品思維的章節裡，我們會重點講解。
電商領域
說到推薦的場景，不得不說的就是電商領域，電商平臺是最早引入個性化推薦系統的領域，對的，說的就是亞馬遜，可謂是推薦系統的鼻祖了，並且整個推薦的發展程序，亞馬遜的 Push 作用確實是不容忽視。
據有訊息稱，亞馬遜整個體系中已經有 20%~30% 的 GMV 是通過推薦帶來的，我們來看看亞馬遜網站的推薦場景。
當然，這只是其中的一個購買主頁的場景，其他的場景大家自行去探索。至今為止，各大電商網站平臺，推薦系統已經是一個標配，包括我們熟悉的某寶某東，如果說沒有受到亞馬遜推薦一定的影響，我是不信的。
推薦系統正在成為全領域的一種標配
如上，我們只是列舉了線上視訊、線上音樂、網路文學、電商等領域的推薦場景，實際上還有其他我們耳熟能詳的一些產品，典型如內容資訊領域，也是推薦系統的“重災區”。
不止如此，正如我們開篇所講，面對著使用者時間的碎片化，以及資訊的同質化、海量化，以及使用者耐心的減少，各個領域都需要解決同樣的問題：如何最快的去留住使用者，縮減使用者獲取有用資訊的路徑。
而推薦，或者說個性化推薦系統是當前相對比較好的一種解決方案，這也就是為何如開題所說，推薦系統正成為所有領域的一種標配。
基於此，我們所有涉及到相關的從業人員，包括資料相關的技術人員、產品甚至是運營，我們對於推薦都需要有一定的瞭解和認知。
在本系列的後面章節裡，我們將從推薦系統中的推薦常識講起，到最核心的常見推薦系統演算法，再到演算法架構，到工程架構，再到推薦的核心迭代神器快速實驗平臺，最後再到推薦系統的產品思維等，來幫助大家逐漸構建起一個相對完善的推薦系統知識體系。
本系列課程分為以下三大部分：
- 第一部分（導讀~第02課），主要闡述推薦系統的需求背景、目前常見的應用場景、一些推薦的基礎常識等維度，對推薦系統涉及到相關基礎進行一個大致的掌握。
- 第二部分（第03~09課），主要從推薦系統演算法的維度進行常見推薦系統演算法的學習和掌握，推薦系統演算法是推薦系統的核心，針對於每個演算法，我們都將結合理論，以及 Spark 工程程式碼例項進行講解。
- 第三部分（第10~12課），主要從推薦系統的推薦架構以及推薦系統的產品設計思維兩個大方向進行學習和了解，最終架構起整個推薦體系。
備註：購買本課程的讀者，可聯絡作者額外獲取完整的工程程式碼包，第06課中有作者的聯絡方式。
第01課：推薦演算法不等於推薦系統
在上篇導讀中，我們對推薦的需求背景以及場景等偏業務領域的知識，有了個大概的認知，從這篇起，我們將逐漸過渡到偏技術的層次上。
這裡我們將對推薦，或者更確切的說是推薦系統有個更全面的認知，比如它的組成結構，涉及到哪些需要解決的技術問題、哪些技術領域，以及這些問題的具體表現等。
推薦系統概述
在上篇中，我們看到了很多推薦的應用場景、各個領域、各種應用都或多或少的體現了這個模式的可用性，但對於業務層來說，我們單純看到的就是一個推薦欄位、欄位名稱及推薦的形式，具體的推薦列表。
所以，這種情況會給人帶來一種錯覺，下意識的認為推薦演算法其實就是推薦系統的全部，我們能看到的推薦列表就是通過某個推薦演算法計算出來的，而我們研究推薦其實就是研究推薦演算法。
這個觀點實際上是很不負責任的，推薦系統是一個相對複雜的業務系統，其中會涉及到資料是如何處理的、架構是如何搭建的、推薦的演算法如何去設計實現、反饋的資料如何收集、基於收集的資料如何做優化迭代、整體系統如何做評估、產品形態上如何做設計。
如此看來，整個推薦體系實際上是一個相對複雜的體系，遠不止我們瞭解的那樣簡單，而想要達到一個好的推薦效果，整個體系的完善是必不可缺少的。
而我們所接觸的最近的以及最熟悉的實際上是推薦的產品形態，以及推薦演算法或者說推薦策略，當然，不可否認的是，推薦演算法確實是整個推薦系統的靈魂，其好壞嚴重影響整個推薦的轉化。
常見的推薦演算法簡介
既然推薦演算法是推薦系統中的核心，我們有必要對常規常見的一些推薦演算法有個直觀的認知，然後再結合自身的產品體驗對推薦演算法的一些邏輯進一步深入的理解。
基於內容屬性的推薦
這種推薦邏輯很簡單，只是單純的依賴物品之間的屬性相似來構建推薦關係，結合導讀中的騰訊視訊推薦的例子，比如如果我在看《蜘蛛俠3》，你給我推薦《鋼鐵俠》、《蝙蝠俠》，理論上是有一定道理的，都是科幻大片嘛，說不定還是同個系列呢。
所以，基於內容的推薦，容易理解，並且很多時候還是有一定效果的，但實際上很多時候會存在這幾種情況，導致了這種原始推薦失效。
如果使用者瀏覽當前的物品本身就不是使用者的菜，甚至是一個非優質資訊（當前主體不可控），再基於當前物品進行推薦就是個偽命題。
基於上面這條，即使當前主體是使用者的目標，但再推類似主體會造成資訊冗餘，即當前主體資訊已經解決了使用者的問題。
所以，由於使用者行為的不可控，基於內容屬性相似的推薦，風險還是挺高的，這是導致了這種原始直接的機制並不會得到廣泛的推廣。
但與亂推薦相比，還是有一定正向作用的，畢竟使用者瀏覽的主體是自身選擇的結果，本身使用者對於其選擇的資訊主體是有一定偏好性的。
基於畫像的推薦
基於物品本身屬性的推薦，其實與個性化是沒有任何的關係，畢竟推薦候選集只跟物品主體有關，與使用者無關，就談不上什麼個性化了。
而基於使用者畫像（更多人喜歡用基於使用者標籤）的推薦，則更大程度上依賴於使用者的畫像屬性來推薦，這就體現了使用者偏好資訊，根據偏好資訊來選擇候選集。
這是一種很通用的做法，並且在大規模資料集情況下，在很多實際的產生過程中喜歡使用這種機制。而使用者的畫像，或者更具體點使用者的興趣標籤如何構建呢？其實就是依賴使用者累積的行為資料了，通過行為資料生成使用者的興趣標籤。
這看似是一種相對靠譜的做法，畢竟如果把使用者的愛好都分析清楚了，主動給使用者做推薦不就顯得很個性化了嗎？在實際的場景中，首先，並不是所有使用者的行為都足夠用來表徵其興趣偏好的，即我們會高估使用者的行為集合，從而產生有偏差的畫像屬性，更甚者，如果使用者完全沒有行為怎麼辦呢？
其次，通常來說，使用者的興趣愛好是會隨時間遷移而改變的，所以，把握使用者的興趣程度以及其變化並不是一個容易的事情，更何況使用者實際的選擇還會受很多因素影響，比如，我當前查詢的一個資訊並不是我之前掌握的資訊，那意味著這些資訊偏好在我的歷史軌跡中都體現不出來，那單純的通過我的興趣去推薦就顯得不靠譜了。
但不管怎麼說，根據使用者的偏好來做推薦，大方向肯定是沒有問題的。
基於協同過濾的推薦
協同過濾，或許瞭解過推薦系統的的朋友，多多少少都能聽過一些，並且協同推薦可是作為推薦領域典型案例而存在的。
協同過濾同樣不會去研究物品的本身屬性，甚至也沒有空去構建使用者的畫像標籤，正如他的名字描述的一樣，他嚴重依靠於使用者的行為以及其周邊使用者的協同行為。
舉個例子，為一個使用者推薦資訊，那麼我只需要參考其周邊使用者在看什麼資訊，就給他推薦什麼資訊就好了。
重點在於，如何限定周邊這個範圍，比如根據兩個使用者的行為，去構建相關關係，從而判斷使用者之間的相似程度，把相似使用者的行為推薦給當前使用者，這就是協同中典型的基於使用者推薦。
而如果以物品為維度，以使用者的購買或者觀看記錄為向量，則可以構建物品的相似度量，針對於每一個待推薦選項，使用者的歷史軌跡就是其向量構成，就可以判斷該使用者歷史的軌跡資訊與當前的待選物品的向量相關度了，從而判斷是否要推薦，這就是基於物品的協同邏輯。
與基於使用者畫像的推薦對比，這種推薦有一定機率可以發現新物品，即並不嚴格依賴使用者的興趣。舉個例子，假設幾個資訊的層級是 A、B、C，並且 A、B、C 是層級遞進關係，並不是同一個東西，對於一個使用者來說，他掌握的是 A，則意味著他的興趣偏好大多偏向於 A，根據興趣標籤，其實是很難推薦這種遞進相關的資訊。
但是，如果其他使用者的學習軌跡都是 A→B→C 這種軌跡，這意味著 A、B、C 三者之間本身就有前後潛在邏輯關係存在的，基於協同，即可為該使用者在掌握 A 的基礎上，推薦 B、C 的內容，這也是基於興趣所做不到的地方。
當前，基於協同行為的推薦，除了基於物品還有基於使用者，還有其他諸如基於模型的協同，典型如最近鄰模型、基於矩陣分解以及基於圖關係模型的構建的推薦機制。
基於關聯規則的推薦
在上一篇中，相信大家有看到其中一個推薦場景的理由“看過 XX 的還看過”，或者“買過 XX 的使用者還買過”類似的推薦理由。
實際上支撐類似理由的一個很重要的推薦演算法就是關聯規則。即我們通過一定的邏輯來尋找物品之間的相關關係，請注意是相關關係並不是相似關係，又或者說我們尋找並不是嚴格意義上屬性上的相似，單純只是為了尋找他們之間的關聯性。
這就要從“啤酒與尿布”的故事說起，或許很多朋友已經聽過這個故事，即超市對使用者的的購物清單進行分析，發現一個很奇怪的現象，那就是很多經常在購買尿布的時候順帶會購買啤酒。
這是一個很奇怪的組合，單純從物品屬性的角度上看，兩者之間很難有明面上的關係，但事實就是他們確實存在某種關聯，超市於是將這兩種商品放在同個貨架中，於是大大提升了兩者的搭配銷售額，並且做了類似的計算，來優化整個貨架陳列，從而提升銷售額。
實際上這就是一個推薦場景，即在尿布的商品瀏覽的時候適當進行啤酒的推薦，從而提升搭配銷售的效果，實際上這是一個關聯分析的過程。
即通過他們歷史的搭配售賣情況，來分析每個搭配之間的合理性，即分析不同商品組合之間的相關性，這種相關性很難去解釋，但確實是在生效。
其他常見推薦演算法
其實在我們實際的操作過程中，並不會嚴格的依賴於這種條條框框、只要合理即可行，比如我們完全可以把推薦問題轉化為分類問題，針對於每個待選項，它都是 Yes or No 的問題，即一個二值分類。
再比如微信朋友圈，微信一定是會研究使用者的朋友圈關係的，比如你對哪類朋友點贊、互動行為最多，它是不是會考慮推薦你欣賞的朋友偏好內容給你？畢竟微信是一個典型的熟人社交模型。
所以，推薦演算法看似重要，但其實想想又沒有這麼重要，很多時候並不是一成不變的，都要我們根據場景去考慮，最最最重要的是，需要我們用實際效果來選擇機制，也或許是多種機制共同生效的結果。
本篇主要從推薦系統的整體涉及的一些概念上，以及針對於推薦系統最重要的一些常見演算法進行簡單的介紹，讓大家對於推薦的演算法邏輯有個大致的瞭解。
在下一篇中，我們將繼續補充推薦體系相關的基礎知識，包括冷啟動的機制，推薦裡產生的馬太效應的體現，以及具體深入分析推薦系統的評判方式，最終來幫助大家建立起推薦系統的基礎知識框架。
然後再深入演算法設計以及實現層，進行實操。
第02課：推薦冷啟動 & 馬太效應 & 評估機制
第03課：基於內容的推薦（原理）
第04課：基於內容的推薦（工程示例）
第05課：融合了使用者興趣的推薦才更具個性（原理）
第06課：融合了使用者興趣的推薦才更具個性（工程示例）
第07課：協同推薦（原理）
第08課：協同推薦（工程示例）
第09課：靈活多變的推薦演算法設計
第10課：推薦系統的架構設計（上）
第11課：推薦系統的架構設計（下）
第12課：實驗平臺搭建 & 產品設計思維
閱讀全文: http://gitbook.cn/gitchat/column/5b4ee9df01d18a561f3430d9