推荐系统随便谈（一）

　　从对推荐一无所知到作过几个推荐系统，再到完成一个推荐系统生态框架的设计，以为是时候沉淀下来一些知识，而后继续找好吃的。《推荐系统随便谈》系列将从最简单的推荐系统提及，并随着业务需求增多和认识深刻来复杂化系统设计，中间偶尔分享一些其余人的设计思路。

　　推荐，你们最熟悉的就是亚马逊的“看了这件商品的用户还看了”，“购买了这件商品的用户还购买了”，例子够简单易懂吧。实际上推荐能够认为是搜索的补充，搜索是用户的一种主动行为，目标十分明确，只是不知道答案，须要搜索引擎告诉我。而推荐目的在于用户不知道本身明确的需求时，告诉用户你可能喜欢某些东西。OK，有构建搜索引擎或推荐引擎经验的同窗可能会发现他们的联系其实很是密切，后文再说这些复杂的地方。

　　回到亚马逊的例子，实际上咱们能够简单地创建起一个相似亚马逊的推荐引擎，这里我们说是《推荐系统随便谈》系列的v1.0系统把。只须要统计每一个商品与其余商品的同时被购买或浏览次数，按多到少排序，就能够获得某个商品的共同购买列表（商场大妈都会啊！）。是的，我们小白最粗暴的解决方案就是从表面上学人家这样搞。。

item_co_occurrence = {}
item_co_occurrence["A"] = {}
item_co_occurrence["A"]["B"] = 2
item_co_occurrence["A"]["C"] = 1
item_co_occurrence["A"]["D"] = 3
item_co_occurrence["B"] = {}
item_co_occurrence["B"]["A"] = 2
item_co_occurrence["B"]["D"] = 1
item_co_occurrence["C"] = {}
item_co_occurrence["C"]["A"] = 1

　　若是你真这样作，那么问题就来了。。。大妈神气地对经理说，我算出来的结果是，买了XXX的用户还购买的最多的商品是塑料袋！妈蛋，坑爹么这是@&#￥%.....若是简单的统计共同出现，那么很容易会被热门物品或者常见并无做用的物品占据了你的候选推荐前几位。

　　稍微聪明的同窗会说，我得加个预处理，把你说的热门物品或者常见且没有做用的物品，好比装东西的塑料袋给删了。看起来是正确的，可是你要怎么删才合理？

　　这时候搞过搜索引擎的同窗站出来讲，咱们作文本处理时关键词提取的思想好像能够复用？“常见且没有做用的物品”其实就是“停用词”，“热门”但对总体没有贡献的物品也同样能够经过tf-idf来计算获得。是的，百度一下tf-idf，你会发现次数计算只是其中一个步骤而已。因此实际上计算两两物品相关信息时能够采用更加科学的方法，如互信息，类tf-idf，余弦距离等，固然也须要考虑自身数据是否有特殊分布。

　　通过预处理和屡次调整计算公式，大妈信心满满的把工具给了苦逼码农，说：我跑出来效果不错，拿去用吧！可是码农实际使用时发现确实肉眼看效果还能够，可是我一个事务，或者说一个交易可能有10+个商品，我这样搞单机怎么跑那么多的东西啊！！大妈摔桌子(╯‵□′)╯︵┻━┻说：妈蛋，作个东西又要效果又要效率！！那你就搞几台破机器一块儿跑啊。大妈一言道出真谛，让码农想起了Hadoop神器！！把大妈的程序用Map-Reduce过程来改造，map过程枚举，sort按字母序排，reduce过程merge计数。

　　恩，初版推荐系统完成！虽然效果和性能都很是锉，可是感谢大妈指导！你们期待下大妈用更好的方法来解决问题把。