可扩展的基于实时项目的 mahout 推荐器，使用项目相似性 hadoop 作业预先计算项目相似性？答案

【问题标题】：Scalable real time item based mahout recommender with precomputed item similarities using item similarity hadoop job?可扩展的基于实时项目的 mahout 推荐器，使用项目相似性 hadoop 作业预先计算项目相似性？
【发布时间】：2012-08-26 08:33:11
【问题描述】：

我有以下设置：

布尔数据：(userid, itemid)

基于 hadoop 的 mahout itemSimilarityJob 具有以下论点： --similarityClassname Similarity_Loglikelihood --maxSimilaritiesPerItem 50 及其他（输入、输出..）

基于项目的布尔推荐器： -model MySqlBooleanPrefJDBCDataModel -相似性 MySQLJDBCInMemoryItemSimilarity -candidatestrategy AllSimilarItemsCandidateItemsStrategy -mostSimilarItemsCandidateStrategy AllSimilarItemsCandidateItemsStrategy

有没有办法在我的设置中使用相似性共现来获得最终推荐？如果我在作业中插入 SIMILARITY_COOCCURENCE，MySqlJDBCInMemorySimilarity 前置条件检查将失败，因为计数变得大于 1。我知道我可以通过在预先计算的相似性上运行推荐器作业来获得最终推荐。在使用 MysqlInMemorySimilarity 的相似性对数似然（以及其他相似性值在 -1 和 1 之间的相似性度量）的情况下，有没有办法使用 api 实时执行此操作？
我们如何限制最大数量。项目相似性作业中每个项目的相似项目数。我的意思是 allsimilaritemscandidatestrategy 调用 .allsimilaritems(item) 来获取所有可能的候选人。有没有一种方法可以让我使用 API 获得前 10/20/50 个类似项目。我知道我们可以将 --maxSimilaritiesPerItem 传递给项目相似性作业，但我不完全确定它代表什么以及它是如何工作的。如果我将其设置为 10/20/50，我是否能够实现上述目标。还有没有办法通过api来完成这个？
我正在使用重新评分器来过滤和重新评分最终推荐。使用 rescorer，与 (30-70ms) 相比，对 /recommend/userid?howMany=10&rescore={..} 和对 /similar/itemid?howMany=10&rescore{..} 的调用正在变得更长 (300ms-400ms)没有记分员。我正在使用 redis 作为内存存储来获取重新评分数据。 rescorer 还接收一些运行时数据，如上所示。 rescorer 中只进行了一些检查。问题是，没有。特定用户的项目偏好增加（> 100），没有。对 isFiltered() 和 rescore() 的调用大大增加。这主要是因为对于每个用户偏好，对 CandidateStrategy.getCandidatItems(item) 的调用会为每个返回大约 (100+) 个相似的项目，并且为每个这些项目调用 rescorer。因此，需要限制工作中每个项目的最大相似项目数。这是正确的还是我在这里遗漏了什么？在这种情况下，优化 rescorer 的最佳方法是什么？

MysqlJdbcInMemorySimilarity 使用 GenericItemSimilarity 来加载 memeory 中的项目相似性，它的 .allsimilaritems(item) 从 mysql 中预先计算的项目相似性中返回给定项目的所有可能的相似项目。我是否需要实现我自己的项目相似性类来返回前 10/20/50 个相似项目。如果用户的号码呢？的喜好继续增长？

如果有人能告诉我如何实现上述目标，那就太好了？多谢！

【问题讨论】：

标签： hadoop machine-learning mahout

【解决方案1】：

您指的是什么前提条件检查？我没有看到它们；我不确定是否实际上禁止相似性大于 1。但您似乎在问是否可以创建一个仅返回共现的相似性函数，作为不与 Hadoop 一起使用的ItemSimilarity。是的你可以;它在项目中不存在。我不建议这样做； LogLikelihoodSimilarity 会更聪明。

您需要不同的CandidateItemStrategy，尤其是查看SamplingCandidateItemsStrategy 及其javadoc。但这与 Hadoop 无关，而与运行时元素无关，并且您提到了 Hadoop 作业的标志。那不是一回事。

如果重新评分很慢，这意味着IDRescorer 很慢。它被调用了很多次，以至于您肯定需要在内存中缓存任何查找数据。但是，减少上述每个候选者的数量也会减少调用的次数。

不，不要实现自己的相似性。您的问题不是相似性度量，而是有多少项目被视为候选者。

我是您所说的大部分代码的作者。我认为您正在努力解决大多数人在尝试大规模进行基于项目的工作时遇到的各种问题。你可以，只要有足够的采样和调整。

但是，我正在将新的开发投入到一个名为 Myrrix 的不同项目和公司中，该公司正在开发一种基于相同 API 的“下一代”推荐器，但它应该在没有这些复杂性的情况下进行扩展，因为它基于矩阵分解。如果你有时间和兴趣，我强烈建议你看看 Myrrix。相同的 API，实时服务层是免费/开放的，并且支持的基于 Hadoop 的计算层也可用于测试。

【讨论】：

嗨，肖恩，非常感谢您的回复。关于前置条件检查，我的意思是当我将 SIMILARITY_COOCCURENCE 与 ItemSimilarity Job 一起使用时，如果我没记错的话，hadoop 输出就像 {item1,item2,noOfCoocurences}。这被导入 MySql 表 - taste_item_similarity。 MySqlJDBCInMemorySimilarity 尝试读取此表数据内存时，会抛出前置条件检查 (-1
另外，将查找 Sampling Candidate Items Strategy，但您能否解释一下 hadoop 标志是什么意思。您是指传递给作业的 --maxSimilaritiesPerItem 选项吗？它是否控制最大数量。作业的输出 csv 文件中生成的每个项目的相似项目数。再次感谢大家，一定会去看看 Myrrix。
好的，没有看到这个检查，但它存在是有道理的。虽然不在那个班。同样，我不会使用原始共现计数作为相似性度量的基础。 --maxSimilaritiesPerItem 是控制修剪的 Hadoop 作业的标志，但这与 CandidateItemStrategy 无关，后者在运行时进行不同类型的修剪。它控制在运行时查看的项目/用户数量。