搜索系统11：协同过滤的数据源和遗留问题

前一文中已经对推荐算法做了个简单的介绍，最常用的就是协同过滤，可分为基于用户的或者基于作品的。我以mahout对这两个算法进行了测试，发现只用这两个算法来完成推荐的工作，还远远不够。这两算法有以下问题待解决:

1.数据源的广度和精度。

算法需要大量的user_id,product_id,like_num(偏好度)这样的数据，而我们的实际系统并没有这样的数据，实际数据需要转化为这样的数据格式才能使用该算法。这就需要我们回答：我们用哪些实际数据来做转化？这就是数据源的广度。实际的数据如何转为like_num，这就是数据的精度问题。

2.推荐算法只能给一部分用户计算出推荐数据。

我的测试数据用户总数有8万多，而实际计算出的推荐数据的用户总数仅为6千多，也就是说只有8%的用户有推荐数据，92%的没有。

3.如何给那剩下92%的用户推荐？

这92%的用户是有实际操作记录的，那还是要计算这些数据关系，进而推荐。只是我们用不了上面的算法，要么自己写一个，要么改mahout协同过滤算法的实现！

4.如何给新用户（没有操作记录）做推荐？

这个可以做个兜底的数据，就是平台认识最好的。

整理一下思路:

聚类算法有欧氏距离等，这个也可不用mahout来做，自己写就行。主要问题是单机太慢了。《mahout in action》在第7章开始讲聚类算法，不过hello world就用上了hadoop。要玩这个看来就得先把这个hello world运行起来，不玩hadoop不行了。

对于92%的未推荐用户还有一个解决办法，就是用浏览实时推荐。前面之所以没有把浏览记录做为mahout的数据来源，原因有两个。

1.浏览记录一般就是最近的有效，用户不会关心一个月或一年前看过的商品，他可能早忘了。
2.浏览数据特别太，会干扰推荐算法，并且让计算速度变慢。

所以把浏览记录做为实时推荐是一个很好的办法，但只有浏览记录是无法完成推荐的。用户看了A产品，必须在事前建立好A与B、E、F产品的关系，才能推荐出B、E、F产品来。