首页 文章

基于用户和基于项目的过滤器之间的决策

提问于
浏览
2

我正在研究一种算法,以便为您可以查看餐馆的平台生成建议 . 因此,数据库存在3个表,“用户”,“餐馆”和“评论” . 评论的评分为1-5 . 每个餐厅都可以有多个评论,用户可以有多个评论 . 评论只能有1个用户和1个餐厅 .

First I'll explain my current research/conclusions

我已经实现了大部分基于用户的系统,但我遇到了一些产生推荐的问题 .

首先,数据稀疏性问题,因为用户可能会对非常不同的餐馆进行一些评论,因此很难确定用户之间的相关性 .

其次,我遇到了冷启动问题 . 在能够计算用户之间的相关性之前,对于完全相同的餐厅,每次评论需要大约4次评论 .
我通过使用基于内容的过滤器找到了'solution' . 当有更好的解决方案时,我个人不喜欢这种过滤方式(即基于项目的过滤)

最后,可扩展性问题 . 因为(希望)该应用程序将取得巨大成功,所以为每个用户计算这些相关性的性能将非常沉重 .

由于这些问题,我决定对基于项目的过滤器进行一些研究 . 我想要一些反馈,以确保我的建议是正确的,并确保我理解这是如何完全的 .

首先,您必须根据所述餐厅的评论计算餐馆之间的相似性相关性 .

矩阵示例(如果我是正确的)其中R1 =餐厅1等 .

|  R1  |  R2  |  R3  |  R4  |
R1 |  1   | 0.75 | 0.64 | 0.23 |
R2 | 0.75 |  1   | 0.45 | 0.98 |
R3 | 0.64 | 0.45 |  1   | 0.36 |
R4 | 0.23 | 0.98 | 0.36 |  1   |

要为用户生成推荐,您必须创建用户已经正面评论的餐馆列表 .
然后检查矩阵以查看哪些餐馆与这些餐馆相似 .
在此之后,您必须检查用户尚未查看过哪些餐厅 . 这些将是用户的建议 .

使用基于项目的过滤器将解决使用基于用户的过滤器时遇到的大多数问题 .

  • 数据稀疏性 . 因为您不再依赖类似用户,所以您不会遇到“评论不够”的问题 .

  • 冷启动问题 . 因为您可以根据用户的1次审核 Build 您的建议,所以您不会遇到冷启动问题(除了有关于用户的空数据)

  • 可扩展性 . 您不必经常生成相似性矩阵 . 你可以每天或甚至一周做一次 . 为了生成建议,您可以简单地查阅矩阵并从中检索餐馆 .

Now my questions:

我真的很喜欢一些意见 . 我想知道我是否正确地做事 .

我做的一切都正确吗?我做了大量的研究,但由于每种情况都不同,我发现很难确定我是否做得对 .

基于项目的过滤器是否比基于用户的过滤器好得多?

你究竟如何计算餐馆之间的相似性?我理解矢量之间的角度,但是你如何确定矢量上的点?你不能只是评论并把它们放在其他评论中,因为那时所有评价最高的餐厅都会非常相似 . 你如何设置这些载体?

在我的场景中,什么是最好的解决方案,什么相似系数最好?

此外,当我的评论矩阵看起来像这样时会发生什么?

|  R1  |  R2  | 
User 1 |  ?   |  5   | 
User 2 |  ?   |  3   | 
User 3 |  5   |  ?   |  
User 4 |  3   |  ?   |

是否可以计算这两家餐厅之间的相似度?如果没有,我该如何解决?

任何有关这方面的反馈将不胜感激!

1 回答

  • 1

    你看起来对你有正确的问题,我会尽量给你一些指示和一些建议:

    Cold Start:

    您将无法解决冷启动问题 . 期 . 你只能缓解它,物品到物品方法的冷启动较少,但你仍然需要餐馆有一些评论和用户至少有一个 .

    如果您访问了有关用户和餐馆的内容信息,那么请利用它来为您提供足够数据时的建议 .

    这让我有了一个有趣的见解 . 您无需使用相同的算法来提出所有建议 . 您可以为具有不同数据量的用户指定不同的方法 .

    例如,您可以从推荐当地最受欢迎的餐厅开始用户如果您有位置,否则只需使用数据库中最受欢迎的餐馆 .

    Item 2 Item vs User 2 User vs Something Else:

    I2I和U2U协同过滤是推荐系统算法,已取得了良好的效果,但是它们遇到了您提到的所有问题 . I2I通常表现更好,但也有冷启动,可扩展性和其他问题 .

    还有另一类算法优于I2I和U2U,并且也基于使用评论确定要推荐的项目的相同直觉 . Matrix Factorization Algorithms 尝试用隐藏因素表示用户和项目信息,并根据这些因素提出建议 . 你应该进一步调查它 .

    Similarity Calculation:

    起点肯定是余弦相似度,其中表示餐馆的每个向量是包含该餐馆的所有用户的评论的数组,并且当用户未评论餐厅时为0 .

    详细解释与例子here .

    Scaling:

    即使I2I更好地扩展,但对于存储器和计算要求,它仍然是餐馆数量的二次方 . 因此,您应该调查其他选项,例如使用 Local Sensitive Hashing 来计算相似性 . 我不会详细介绍,因为我对该算法不是很舒服,但我认为你可以应用它来计算最相似的对,而不必存储整个矩阵 .

    Sources for further investigation:

相关问题