系列隨筆：
（二）基於商品屬性的相似商品推薦算法——Flink SQL實時計算實現商品的隱式評分
（三）基於商品屬性的相似商品推薦算法——批量處理商品屬性，得到屬性前綴及完整屬性字符串
（四）基於商品屬性的相似商品推薦算法——推薦與評分高的商品屬性相似的商品
2020.04.15 補充：協同過濾推薦算法.pptx
提取碼：4tds
碎碎念（可跳過）
項目背景：
對於一個商城（或社區系統或其他）來說，”推薦“是一個很有必要，而且很必要的功能。它可以幫忙用戶更快的找到自己心怡的商品，提高商品的轉化率、增加銷售收入；一個好的推薦系統，還能帶給用戶予驚喜、提高用戶對系統的整體滿意度及口啤，吸引更多的新用戶和訪問量。
經典推薦算法：
比較經典的推薦算法有《基於人的協同推薦算法》和《基於物的協同推薦算法》，兩種算法的原理是一致的，具體請自行百度。
簡單來說：
基於人的推薦就是先找到有相同愛好的一個同好群（興趣圈），然后由里面的”知己“推薦商品；也就是說”我和你是知己，我喜歡的東西，你大概也喜歡，拿去康康吧“。"知己"的定義為：喜歡的商品大致相同。
基於物的推薦就是兩個（或多個）商品被同時喜歡的次數很高，那這些商品應該是相似的。例如，張三喜歡商品A和D，李四喜歡商品A、B、D，王五喜歡商品A、C、D，雖然這三人喜歡的商品不完全一樣，但他們都喜歡A和D（喜歡A的都喜歡D），也就是說A和D應該是相似的；現在來了一個趙六，他喜歡A，那么現在應該可以給他推D
協同推薦算法缺陷：
基於人的推薦的問題在於，如果”圈子“比較小，大家喜歡的商品也是類似的，相互推薦會變成一個惡性循環。會使得推薦的商品都一樣，或者到最后沒商品可推薦；基於物的推薦一般會比基於人的推薦會好一些，但它們共同的問題是：數據稀疏（系統的商品數量是巨大的，而一個用戶瀏覽過的商品是有限的，通常不到1%），計算量巨大。
一個運營良好的系統（平台）的用戶和商品的數量都是巨大的；假設系統有200w用戶，10w個商品，為一個用戶推薦商品時：
基於人的時候，需要遍歷200w用戶，查詢他們喜歡的商品及對商品的評分（計算量巨大），對比各個用戶對相同商品的評分情況（計算量巨大），找出品味相近的N個圈子，從當前用戶所有的圈子里挑取評分高的商品進行推薦。當然，你也可以不完全遍歷所有用戶來找品味相近的人，你可以查詢當前用戶都對哪些商品進行了評分（有個顯示評分和隱式評分的問題，這里就不展開了），然后查詢對（其中一個或一些）商品有過評分的其他用戶，這里查詢得到的用戶就會少一些，然后還是進行用戶評分矩陣的對比（相似度計算）；不過依然是操作復雜，計算量大；
基於物的時候，需要遍歷所有商品，查詢計算每個商品被多少個人喜歡、每個人的評分是怎樣的（計算量巨大），然后對比得到相似的商品；根據當前用戶喜歡的商品，推薦相近的其他商品。計算量依然是巨大；
解決數據稀疏的主要算法有單值分解、聚類等（有點復雜）；解決計算量大的方法是分布式計算（也就是說，提高算力），例如：Spark；這個對服務器的要求比較高（額外的預算），然后開發、部署、運營的難度也較高~~
PS：上面對這兩種經典的協同過濾推薦算法的講解和評論屬於個人理解。個人水平較低，可能說錯或不太嚴謹。讀者請自己查閱資料，選擇適合自己的推薦算法。
基於商品屬性的相似商品推薦算法：
”我們是知己，我喜歡這個，你也應該會喜歡。“、”同時喜歡商品A和商品D的人比較多，這兩個商品應該是相似的，你喜歡A的話，應該也會喜歡D“~~~~~
不管是基於人還是基於物的協同推薦算法，它們的“相似”，都只是一個客觀上的”相似“，只是應該是相似的，並不是商品間真正的相似。那么什么是真正的相似咧？
例如：我們在看兩個人是不是長得像的時候，觀察的是眼睛、鼻子、嘴巴等等是不是長得像。我們觀察人的這些特征（五官或其他），對比的是特征是否一樣或相似，最終判斷兩個人是否相似；
再例如：我們想買手機的時候，需要看兩台（或多台）手機是否真的相似，哪個配置高？我們可以去中關村在線，進行商品對比，對比商品的屬性。相同屬性越多，兩台手機就越相似~
http://detail.zol.com.cn/ProductComp_param_1298290-1302451.html
可以看到，這種基於商品屬性的對比，點對點的對比，更有說服力，也更形象、更本質的說明兩個商品是否相似（關鍵是實現起來，也不需要大量的計算！！）
下一節：（一）基於商品屬性的相似商品推薦算法——整體框架及處理流程