【问题标题】:Like-based Recommendations基于赞的推荐
【发布时间】:2015-02-11 06:17:08
【问题描述】:

我很好奇有哪些算法可用于基于相似的推荐。我的意思是人们可以“喜欢”某事,但他们不能“不喜欢”某事。这种场景有什么样的推荐算法。

我有一个想法,但我认为它不可扩展。我的想法是创建一个图表,其中每个喜欢的项目与其他喜欢的项目之间都有一个边缘,边缘容量是同时喜欢这两个项目的用户数量。然后为了给某个用户提供推荐,你扩充了图,使用户成为一个源节点,对用户喜欢的所有项目都有无限的边。用户不喜欢的所有项目都具有到目标节点的无限容量边缘。然后使用 Ford-Fulkerson 运行最大流,并且可以根据目的地的边缘流对推荐进行排序。但是,仔细考虑一下,包含 1000 项或更多项的图表很快就会失控。

我曾考虑过其他系统,例如协作过滤器,但我不确定它们是否能很好地工作,因为没有否决票或多个点赞。因此,“不喜欢”与“尚未喜欢”是无法区分的。

如果有任何想法或资源,我将不胜感激。

【问题讨论】:

  • “看过和不喜欢”与“没看过”之间存在很大差异。如果用户看到了一个项目,你有数据吗?看到和不喜欢有时被用作微弱的“不喜欢”

标签: algorithm recommendation-engine


【解决方案1】:

有几点你可以使用:

  1. “看过和不喜欢”与“没看过”之间存在很大差异。通常,“看到和不喜欢”被用作弱“不喜欢”,然后您可以使用协同过滤。
  2. 您仍然可以根据喜欢和一组相似用户(倾向于喜欢相似事物)找到“相似用户” - 您可以推荐他们喜欢的项目。如果两个用户喜欢的项目集具有较高的Jaccard similarity(例如),则可以确定两个用户“相似”,并推荐大部分“相似”用户喜欢的项目。

您可以在文献中搜索更多替代方案,这是过去几年 www conference 上的热门话题,并且新方法一直在发展。

【讨论】:

  • 我明白了。因此,使用 Jaccard 相似度,每个推荐的成本大约为 O(N*M),其中 N 是用户数,M 是项目数。实际上,性能将达到 2*M 是喜欢项目的平均数量或类似的东西。现在考虑到可能有 100 万用户和每个用户喜欢的 1000 个项目,我们可能需要稍微快一些的东西。增量方法将在每个新的“喜欢”上花费 O(N)。我想这就是协同过滤开始蓬勃发展的地方。有什么想法吗?
猜你喜欢
  • 2013-05-03
  • 1970-01-01
  • 2015-07-02
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2015-01-16
  • 2016-10-04
相关资源
最近更新 更多