我有以下设置：
布尔数据：（userid，itemid）
基于hadoop的mahout itemsimilarityjob，具有以下参数：---similarityclassname similarity\u LogLikelibility--maxsimilaritiesperitem 50和others（输入、输出..）
基于项的布尔推荐程序：-模型mysqlbooleanprefjdbcdatamodel-相似度mysqljdbcinmemoryitemsimilarity-候选策略allsimilaritemscandidateitemsstrategy-mostsimilaritemscandidatestrategy allsimilaritemscandidateitemsstrategy
有没有办法在我的设置中使用相似性来获得最终的推荐？如果我在作业中插入相似性，mysqljdbcinmemorysimilarity前提条件检查将失败，因为计数将大于1。我知道我可以通过在预计算的相似性上运行推荐程序作业来获得最终的推荐。有没有办法像在使用mysqlinmemorysimilarity的相似性loglikelihood（以及相似性值介于-1和1之间的其他相似性度量）的情况下那样，使用api来实时完成这项工作？
如何在项目相似性作业中限制每个项目的最大相似项目数。这里我的意思是allsimilaritemscandidateststrategy调用.allsimilaritems（item）来获取所有可能的候选项。有没有一种方法可以让我说，前10/20/50类似的项目使用api。我知道我们可以把一个--maxsimilaritiesperitem传递给item similarity作业，但是我不能完全确定它代表什么以及它是如何工作的。如果我把这个设定为10/20/50，我就能达到上面所说的。还有什么方法可以通过api来实现呢？
我正在使用一个重新排序器来筛选和重新排序最终建议。有了rescorer，对/recomment/userid？howmany=10&rescore={..}&to/similar/itemid？howmany=10&rescore{..}的调用要比没有rescorer的调用长（300ms-400ms）。我使用redis作为内存存储来获取重新存储的数据。rescorer还接收一些运行时数据，如上所示。rescorer中只进行了一些检查。问题是，随着特定用户的项目首选项数量增加（>100），对isfiltered（）和rescore（）的调用数量会大量增加。这主要是因为对于每个用户首选项，对candidatestrategy.getcandidatems（item）的调用都会为每个项返回大约（100+）个相似的项，并为每个项调用rescorer。因此需要限制作业中每个项目的最大相似项目数。这是正确的还是我遗漏了什么？在这种情况下，优化救援人员的最佳方法是什么？
mysqljdbcinmemorysimilarity使用genericitemsimilarity加载memeory中的项相似性，并使用其.allsimilaritems（item）从mysql中预计算的项相似性返回给定项的所有可能相似项。我是否需要实现自己的item similarity类来返回前10/20/50个相似项。如果用户的首选项数量继续增长呢？
如果有人能告诉我如何实现上述目标，那真的很好吗？谢谢你！