协同过滤/推荐系统性能与方法

Question

我真的很想了解人们是如何使用协作过滤和推荐引擎等的。我的意思更多的是在脚本的性能方面，而不是任何东西。我已经说过阅读编程集体智能，这是非常有趣的，但倾向于更多地关注算法方面的事情。

我目前只有2k用户，但我目前的系统已经证明完全不是未来的证据，而且已经对服务器造成了很大的负担。整个系统的基础是向用户推荐帖子。我的应用程序是PHP/MySQL，但是我使用一些MongoDB来进行协作过滤--我使用的是一个大型的Amazon实例。我的设置实际上是一个2步的过程。首先，我计算项目之间的相似之处，然后使用这些信息提出建议。下面是它的工作原理：

首先，我的系统计算用户帖子之间的相似之处。脚本运行一个算法，该算法为每对返回一个相似度分数。该算法检查信息，如公共标签，普通评论者和普通的相似者，并能够返回一个相似的分数。这个过程是这样的：

每次添加帖子时，都会添加标记、注释或喜欢我将其添加到队列中。

• I通过cron (每天一次)处理此队列，查找每个帖子的相关信息，例如评论人和喜欢者的user_id和标记_id。我以这种结构将这些信息保存到MongoDB上：{"post_id":1，"tag_ids":12,44,67，"commenter_user_ids":6,18,22，"liker_user_ids":87,6}。这允许我最终构建一个MongoDB集合，它使我能够轻松、快速地访问所有相关信息，以便当我试图计算相似性
• 时，我会运行另一个cron脚本(每天也运行一次，但在前面的脚本之后)，该脚本再次遍历队列。这一次，对于队列中的每个帖子，我从MongoDB集合中获取它们的条目，并将其与所有其他条目进行比较。当两个条目有一些匹配的信息，我给他们+1的相似性。最后，我对每一对帖子都有一个总体评分。我将分数保存到一个不同的MongoDB集合中，其结构如下：{" post_id ":1、“相似”：{“23”：2、"2":5、"7":2}} (‘key=>value’是一个以post_id为键、以相似度分数为值的key=>value数组。如果是0，我就不存分数。

我有5k个职位。因此，以上所有这些在服务器上都很难实现。有大量的读和写要执行。现在，这只是问题的一半。然后，我使用这些信息来计算特定用户感兴趣的帖子。因此，我每小时运行一次cron脚本，它运行一个脚本，该脚本计算站点上每个用户推荐的帖子1。这个过程是这样的：

• 脚本首先决定用户将得到哪种类型的推荐。这是一个50到50的变化- 1。一个类似于你的帖子或2。一个类似的帖子，你已经与之互动。
• 如果1，然后脚本从MySQL抓取用户post_ids，然后使用他们从MongoDB获取相似的帖子。该脚本采用最类似的帖子，尚未推荐给用户。
• If 2，脚本获取用户从MySQL中评论或喜欢的所有帖子，并在上面的1中使用他们的in进行相同的操作。

不幸的是，每小时的推荐脚本变得非常资源密集，并且慢慢地需要越来越长的时间来完成.目前为10-15分钟。我担心在某一时刻，我将无法提供每小时的推荐。

我只是想知道是否有人觉得我能更好地接近这个？

Answer 1

我开始计划怎么做了。第一件事可能是摆脱数据库技术，或者用triplestore或图形技术来补充数据库技术。这将为分析类似的喜欢或主题提供一些更好的性能。

接下来是得到一个子集。以用户拥有的一些兴趣为例，获得一小部分具有相似兴趣的用户池。

然后，按照某种有意义的顺序建立喜欢的索引，并计数反转(这与合并排序非常相似，您可能希望在退出时对拆分反转进行排序)。

我希望这会有所帮助--你不想把所有的东西都和其他的东西比较，或者它肯定是n2。你应该能够用一些介于常量和线性之间的东西来代替它，如果你选择了一组有相似爱好的人，并使用它。

例如，从图的角度来看，取一些他们最近喜欢的东西，然后查看其中的边缘，然后跟踪它们并分析这些用户。也许可以在一些最近喜欢的文章上这样做，然后从这些文章中找到一组普通的用户，并将其用于协作筛选，以查找用户可能会喜欢的文章。然后，您将遇到一个可行的问题大小--特别是在没有索引增长的图表中(尽管在文章中需要遍历的边可能更多--这只会让您更多地找到可用的数据)。

更好的办法是将文章本身输入，这样，如果某篇文章被某人喜欢，你就可以看到他们可能喜欢的其他用户的文章(即亚马逊的“购买这篇文章的用户也购买了”)。

希望能给你一些想法。对于图形分析，有一些框架可能有助于像faunus这样的统计和嘲笑。

Answer 2

拥有5000条帖子，即25,000,000个关系，增加了O(n^2)。

您的第一个问题是如何避免每次批处理运行时检查这么多关系。使用标签或关键字将有助于内容匹配--您可以使用日期范围来限制常见的“喜欢”。除此之外，我们还需要更多地了解建立关系的方法。

另一个考虑是当你建立关系的时候。为什么要等到批处理运行时才将新帖子与现有数据进行比较？当然，异步处理这一问题是有意义的，以确保快速处理请求--但是(除了平台施加的限制之外)，为什么要等到批处理启动之后才建立关系？使用异步消息队列。

事实上，根据处理消息所需的时间长短，甚至有可能在检索到项时而不是在创建项时重新生成缓存的关系数据。

如果我正在编写一个平台来度量与数据的关系(线索就在名字中)，我肯定会倾向于一个关系数据库，在这里连接很容易，而且很多逻辑都可以在数据库层上实现。

当然，可以缩短系统交叉引用数据所需的时间。这正是问题地图所要解决的问题