（总览）基于商品属性的相似商品推荐算法
系列随笔：
（二）基于商品属性的相似商品推荐算法——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
可以看到，这种基于商品属性的对比，点对点的对比，更有说服力，也更形象、更本质的说明两个商品是否相似（关键是实现起来，也不需要大量的计算！！）
下一节：（一）基于商品属性的相似商品推荐算法——整体框架及处理流程
