基于用户和基于项目的过滤器之间的决策
Decision between an user-based and item-based filter
我正在研究一种算法，为您可以在其中评论餐厅的平台生成推荐。因此数据库存在 3 个表，'Users'、'Restaurants' 和 'Reviews'。评论的评分为 1-5。每个餐厅可以有多个评论，用户也可以有多个评论。一条评论只能有 1 位用户和 1 家餐厅。
首先我会解释一下我现在的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 |
要为用户生成推荐，您必须创建用户正面评价的餐厅列表。
然后检查矩阵，看看哪些餐厅与这些餐厅相似。
在此之后，您将必须检查用户尚未评论哪些餐厅。这些将是给用户的建议。
使用基于项目的过滤器将解决您在使用基于用户的过滤器时遇到的大多数问题。
数据稀疏。因为你不再依赖相似的用户，所以你不会有'Not enough reviews'.
冷启动问题。因为您可以根据用户的 1 条评论提出建议，所以您不会遇到冷启动问题（除了关于用户的空数据）
可扩展性。您不必生成很多相似度矩阵。你可以每天甚至一周做一次。为了生成推荐，您只需查阅矩阵并从中检索餐馆。
现在我的问题：
我真的很想听听一些意见。我并不是说我的任何研究都是事实，我只是想知道我做的事情是否正确。
我做的每件事都正确吗？我做了很多研究，但由于每个场景都不同，我发现很难确定我做的是否正确。
基于项目的过滤器真的比基于用户的过滤器好得多吗？
您如何准确计算餐厅之间的相似度？我知道向量之间的角度，但是你如何确定向量上的点？您不能只接受评论并将其与其他评论进行对比，因为那样所有评分最高的餐厅都会非常相似。你如何设置这些向量？
在我的场景中，什么是最好的解决方案，什么相似系数最好？
此外，当我的评论矩阵看起来像这样时会发生什么？
| R1 | R2 |
User 1 | ? | 5 |
User 2 | ? | 3 |
User 3 | 5 | ? |
User 4 | 3 | ? |
是否可以计算出这两家餐厅之间的相似度？如果没有，我该如何解决？
如有任何反馈，我们将不胜感激！
看来你的问题很对，我会尽量给你一些指点和建议：
冷启动：
你将无法解决冷启动问题。时期。你只能减轻它，一个项目到项目的方法受到较少的冷启动，但你仍然需要餐厅有一些评论，并且用户至少有一个。
如果您可以访问有关用户和餐厅的内容信息，则可以利用它在您没有足够数据时提出建议。
这使我有了一个有趣的见解。您不需要使用相同的算法来提出所有建议。您可以为具有不同数据量的用户指定不同的方法。
比如你可以先向用户推荐当地最受欢迎的餐厅，如果你有位置，否则就使用你数据库中最受欢迎的餐厅。
项目 2 项目 vs 用户 2 用户 vs 其他：
I2I和U2U Collaborative filtering是推荐系统算法，已经取得了很好的效果，但是它们都存在你提到的所有问题。 I2I 通常性能更好，但也存在冷启动、可扩展性和其他问题。
还有另一种 class 的算法一直优于 I2I 和 U2U，并且也是基于使用评论来确定推荐哪些项目的相同直觉。 矩阵分解算法 尝试用隐藏因素表示用户和项目信息，并根据这些因素提出建议。你应该进一步调查它。
相似度计算：
起点肯定是余弦相似度，其中代表一家餐厅的每个向量都是一个数组，其中包含所有用户对该餐厅的评论，当用户没有评论该餐厅时为 0。
详细解释示例here。
缩放：
尽管 I2I 的扩展性更好，但对于内存和计算要求而言，它仍然是餐厅数量的二次方。
因此，您应该研究其他选项，例如使用 Local Sensitive Hashing 来计算相似度。我不会详细介绍，因为我不太熟悉该算法，但我认为您可以应用它来计算最相似的对，而不必存储整个矩阵。
进一步调查的来源：
- 很好的介绍：Mining Massive Datasets
的第 9 章
- 推荐系统圣经：Recommender Systems Handbook
我正在研究一种算法，为您可以在其中评论餐厅的平台生成推荐。因此数据库存在 3 个表，'Users'、'Restaurants' 和 'Reviews'。评论的评分为 1-5。每个餐厅可以有多个评论，用户也可以有多个评论。一条评论只能有 1 位用户和 1 家餐厅。
首先我会解释一下我现在的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 |
要为用户生成推荐，您必须创建用户正面评价的餐厅列表。
然后检查矩阵，看看哪些餐厅与这些餐厅相似。
在此之后，您将必须检查用户尚未评论哪些餐厅。这些将是给用户的建议。
使用基于项目的过滤器将解决您在使用基于用户的过滤器时遇到的大多数问题。
数据稀疏。因为你不再依赖相似的用户，所以你不会有'Not enough reviews'.
的问题
冷启动问题。因为您可以根据用户的 1 条评论提出建议，所以您不会遇到冷启动问题（除了关于用户的空数据）
可扩展性。您不必生成很多相似度矩阵。你可以每天甚至一周做一次。为了生成推荐，您只需查阅矩阵并从中检索餐馆。
现在我的问题：
我真的很想听听一些意见。我并不是说我的任何研究都是事实，我只是想知道我做的事情是否正确。
我做的每件事都正确吗？我做了很多研究，但由于每个场景都不同，我发现很难确定我做的是否正确。
基于项目的过滤器真的比基于用户的过滤器好得多吗？
您如何准确计算餐厅之间的相似度？我知道向量之间的角度，但是你如何确定向量上的点？您不能只接受评论并将其与其他评论进行对比，因为那样所有评分最高的餐厅都会非常相似。你如何设置这些向量？
在我的场景中，什么是最好的解决方案，什么相似系数最好？
此外，当我的评论矩阵看起来像这样时会发生什么？
| R1 | R2 |
User 1 | ? | 5 |
User 2 | ? | 3 |
User 3 | 5 | ? |
User 4 | 3 | ? |
是否可以计算出这两家餐厅之间的相似度？如果没有，我该如何解决？
如有任何反馈，我们将不胜感激！
看来你的问题很对，我会尽量给你一些指点和建议：
冷启动：
你将无法解决冷启动问题。时期。你只能减轻它，一个项目到项目的方法受到较少的冷启动，但你仍然需要餐厅有一些评论，并且用户至少有一个。
如果您可以访问有关用户和餐厅的内容信息，则可以利用它在您没有足够数据时提出建议。
这使我有了一个有趣的见解。您不需要使用相同的算法来提出所有建议。您可以为具有不同数据量的用户指定不同的方法。
比如你可以先向用户推荐当地最受欢迎的餐厅，如果你有位置，否则就使用你数据库中最受欢迎的餐厅。
项目 2 项目 vs 用户 2 用户 vs 其他：
I2I和U2U Collaborative filtering是推荐系统算法，已经取得了很好的效果，但是它们都存在你提到的所有问题。 I2I 通常性能更好，但也存在冷启动、可扩展性和其他问题。
还有另一种 class 的算法一直优于 I2I 和 U2U，并且也是基于使用评论来确定推荐哪些项目的相同直觉。 矩阵分解算法 尝试用隐藏因素表示用户和项目信息，并根据这些因素提出建议。你应该进一步调查它。
相似度计算：
起点肯定是余弦相似度，其中代表一家餐厅的每个向量都是一个数组，其中包含所有用户对该餐厅的评论，当用户没有评论该餐厅时为 0。
详细解释示例here。
缩放：
尽管 I2I 的扩展性更好，但对于内存和计算要求而言，它仍然是餐厅数量的二次方。 因此，您应该研究其他选项，例如使用 Local Sensitive Hashing 来计算相似度。我不会详细介绍，因为我不太熟悉该算法，但我认为您可以应用它来计算最相似的对，而不必存储整个矩阵。
进一步调查的来源：
- 很好的介绍：Mining Massive Datasets 的第 9 章
- 推荐系统圣经：Recommender Systems Handbook