使用基于项目的协作过滤，我们利用类似用户对给定用户的项目评分来生成推荐。研究经常建议使用保留测试集来评估算法，例如20％的数据与80％的培训。但是，如果在特定项目的所有评级都被拒绝的情况下呢？我们的培训数据将不再包含该项目，并且永远不会推荐。使用测试集合评估协同过滤算法
E.g. 5个用户每人观看10部电影，其中之一是'泰坦尼克号'。我们随机推出了每个用户20％数据的测试集= 2部电影/用户。如果“泰坦尼克号”在每个用户的测试集中怎么办？它永远不会被推荐。
评估方法取决于用例和数据类型。因此，在某些情况下，随机分配80/20的评估是不够的，即当时间扮演着基于会话的建议等重要角色时。
假设可以用这种方式评估这个用例，尽量不要仅将评估基于单个随机训练/测试拆分，而是进行N倍交叉验证。在这种情况下，使用保留进行5倍交叉验证。评估结果将汇总所有折叠结果。进一步来说，这个单一的实验可以重复几次，以获得最终的结果。
退房这两项目：
既可以对您有用。至少在寻找适当的评估方法。
第一个答案是，如果性能指标正确平均，这种影响将不显着。为此，我总是使用[email protected]或平均精度。这只能衡量建议的精确度，但要以某种方式进行，以便在缺少某些数据的情况下，平均值通常仍然有效。
作为@BartłomiejTwardowski说，你也可以做一些事情，如k-fold test，它对不同的分割进行评估并对其进行平均。这不太容易出现小数据集问题，您仍然可以使用MAP @ k作为衡量标准，因为k-fold仅解决分割问题。
我们所做的是使用MAP @ k并在日期分割，以获得培训拆分中的80个老用户和探测/测试拆分中的20％新用户。这模拟了现实世界推荐人将如何工作。由于在建立模型后经常会有新用户进来。
顺便说一句，不要忘记，推荐“传播”也与转换中的提升有关。所以召回很重要。作为一种便宜而不是非常严格的召回方式，我们可以看看有多少人拿出一套建议。如果您正在比较一种调谐与另一种调谐，则召回与多少人可以得到推荐相关，但您必须在两种情况下使用完全相同的分割。
BTW2请注意，您正在使用与给定用户类似的用户评分，这是基于用户的协作过滤。当你发现类似于某个示例项目的项目对谁进行了高度评价时，您正在进行基于项目的项目。区别在于项目或用户是否是查询。
用于我们使用的新算法的最后一个插件。为了完成基于物品和基于用户的记录（以及购物车等项目集记录），我们使用CCO（相关交叉事件）来利用所有用户操作作为输入。 In a blog post对此我们发现，当我们使用用户“喜欢”以及“不喜欢”预测喜欢时，从电影评论网站收集的数据集中，MAP @ k增加了20％+。该算法在Apache Mahout中实施，并且完整的交钥匙推荐器是here。