我有以下设置：
布尔数据：（userid，itemid）
基于hadoop的mahout itemSimilarityJob以及以下争论： --similarityClassname Similarity_Loglikelihood --maxSimilaritiesPerItem 50＆amp;其他人（输入，输出......）
基于项目的布尔推荐器： -model MySqlBooleanPrefJDBCDataModel -similarity MySQLJDBCInMemoryItemSimilarity -candidatestrategy AllSimilarItemsCandidateItemsStrategy -mostSimilarItemsCandidateStrategy AllSimilarItemsCandidateItemsStrategy
有没有办法在我的设置中使用相似性cooccurence来获得最终建议？如果我在作业中插入SIMILARITY_COOCCURENCE，则MySqlJDBCInMemorySimilarity前提条件检查失败，因为计数大于1.我知道我可以通过在预先计算的相似性上运行推荐器作业来获得最终建议。有没有办法在使用MysqlInMemorySimilarity的相似性loglikelihood（以及-1和-1之间的相似度值的其他相似性度量）的情况下使用api实现这样的实时？
我们怎样才能限制最大数量。项目相似性作业中每个项目的类似项目。我在这里的意思是allsimilaritemscandidatestrategy调用.allsimilaritems（item）来获得所有可能的候选者。有没有办法可以使用API来说出10/20/50类似的项目。我知道我们可以将--maxSimilaritiesPerItem传递给项目相似性工作，但我不完全确定它代表什么以及它是如何工作的。如果我将其设置为10/20/50，我是否能够达到上述目的。还有办法通过api来实现这个目标吗？
我正在使用rescorer来过滤和重新定位最终建议。使用rescorer，调用/ recommended / userid？howMany = 10＆amp; rescore = {..}＆amp; to / similar / itemid？howMany = 10＆amp; rescore {..}正在采取更长的时间（300ms-400ms），相比之下（30-70ms）没有rescorer。我使用redis作为内存存储来获取rescore数据。 rescorer还接收一些运行时数据，如上所示。 rescorer中只发生了一些检查。问题是，作为没有。对于特定用户的项目偏好增加（> 100），没有。调用isFiltered（）＆amp; rescore（）大量增加。这主要是因为对于每个用户首选项，对candidateStrategy.getCandidatItems（item）的调用返回每个（100+）个相似的项目，并为每个项目调用rescorer。因此需要限制作业中每个项目的最大类似项目数。这是正确的还是我错过了什么？在这种情况下，优化rescorer的最佳方法是什么？
MysqlJdbcInMemorySimilarity使用GenericItemSimilarity在memeory中加载项目相似性，其.allsimilaritems（item）返回mysql中预先计算的项目相似性中给定项目的所有可能类似项目。我是否需要实现自己的项目相似度类别才能返回前10/20/50类似项目。如果用户的号码怎么样？偏好继续增长？
如果有人能告诉我如何实现上述目标，真的会很棒吗？谢谢堆！
答案 0 :(得分：2)
您指的是哪些先决条件检查？我没有看到他们;我不确定相似性是否真的被禁止＆gt;但是你似乎在问你是否可以创建一个只返回共现的相似函数，作为一个不与Hadoop一起使用的ItemSimilarity。是的你可以;它在项目中不存在。我不建议这样做; LogLikelihoodSimilarity会变得更聪明。
您需要一个不同的CandidateItemStrategy，特别是SamplingCandidateItemsStrategy及其javadoc。但这与Hadoop无关，而与运行时元素无关，并且您提到了Hadoop作业的标志。这不是一回事。
如果重新缓慢，则意味着IDRescorer很慢。它被调用了很多次，你当然需要在内存中缓存任何查找数据。但是，减少每个候选人的数量也会减少这个被调用的次数。
不，不要实现自己的相似性。您的问题不是相似性度量，而是有多少项被视为候选项。
我是您正在谈论的大部分代码的作者。我认为你正在努力解决大多数人在尝试以大规模进行基于项目的工作时遇到的问题。你可以通过足够的采样和调整来实现。
然而，我正在将一个新的开发项目和公司称为Myrrix，它正在开发一种基于相同API的“下一代”推荐器，但它应该在没有这些复杂性的情况下进行扩展，因为它是基于矩阵分解。如果您有时间和兴趣，我强烈建议您查看Myrrix。相同的API，实时服务层是免费/开放的，并且支持的基于Hadoop的计算层也可用于测试。