使用离线数据集评估基于用户的 CF 算法的标准程序是什么?

机器算法验证 计算统计 推荐系统 信息检索
2022-04-04 08:18:32

我已经阅读了一些关于推荐系统(RS)评估的论文和其他材料。他们中的大多数讨论了 RS 的各种属性(例如准确性、多样性等),以及不同任务的指标(例如 RMSE、精度、召回率等),以及一些协议。但是我对数据分区和详细的验证过程仍然不是很清楚。[Shani、Guy 和 Asela Gunawardana。“评估推荐系统。” 推荐系统手册。施普林格美国,2011. 257-297.]

例如,我想用评分反馈评估一个基本的基于用户的 CF 算法。数据格式是用户项目评级。数据集中有 100 个用户。现在我想使用 5 折交叉验证方法。这是我的方式:

  1. 根据用户的说法,我将原始数据集随机分成 5 折。每个折叠包含 20 个用户。
  2. 对于所有用户,我设置了一个相同的时间瞬间,因此在此时间瞬间之前和之后,每个用户都包含许多评级。时刻之前的任何用户 x 的数据用于创建用户配置文件,时刻之后的数据用于验证评分预测(用户 x 作为被预测的用户)或只是被隐藏(用户 x 在邻域选择中)。
  3. 对于所有 5 折中的每个用户 i,我为用户 i 创建一个由评级向量{} 表示的用户配置文件。
  4. 对于 fold-1,对于 fold-1 中的每个用户 i,我计算用户 i 与 fold-2 ~ fold-5 中的用户之间的用户相似度,并设置适当的 k-NN 值以获得每个用户的邻域。
  5. 对于 fold-1 中的每个用户 i,我通过适当的评分平均方程从他的邻域用户(测试用户未使用的项目)获得预测评分。
  6. 计算用户 i 的预测误差。
  7. 对每一折重复步骤 2~6(全部 5 次),得到平均预测误差。这是一轮。
  8. 使用不同的参数组合(如k-NN邻域大小),多次重复步骤2~7,以获得最低的预测误差(即最佳参数组合)。
  9. 最好的参数组合,我得到的预测误差最小,这就是最终的评估结果。

我有两个问题:

  • 此过程对于评估基于用户的 CF 算法是否正确?
  • 如果是,那么这个过程中的具体数据是什么,对应于Statistics中的“训练集”、“测试集”和“验证集”的概念?
1个回答

关于“三套”

  • 训练集:训练折叠中的用户限制在拆分日期之前的评级。该数据用于构建模型。
  • 验证集:验证折叠中的用户仅限于拆分日期之后的评级。该数据用于评估模型。
  • 测试集:预先放置的用户(目前在您的设置中没有发生),仅限于拆分日期之后的评级。这是通过以下方式完成的:
    • 使用训练和验证集中的所有数据来构建模型(仅限于拆分日期之前的评级)
    • 使用拆分日期之前的测试集中的用户数据计算邻域,并使用拆分数据之后的评级计算误差(标准程序)

重要的一点是,测试集用于评估在实践中的泛化错误和质量(在完成所有优化之后)。如果这一步的质量大大低于在验证集中获得的质量,则过度拟合已经滑入。

另请参阅此问题:测试集和验证集有什么区别?

关于内部与外部交叉验证

内部交叉验证用于优化所谓的超参数(http://en.wikipedia.org/wiki/Hyperparameter_optimization),如邻域 k。这是通过再次拆分训练集来完成的。外部交叉验证用于评估此优化的泛化能力和误差。

另请参阅此问题:模型选择的嵌套交叉验证

现在有人可能会问:为什么要重新划分训练数据?为什么不直接说

  • 内部交叉验证的训练部分对应训练集
  • 内部交叉验证的验​​证部分对应验证集
  • 外部交叉验证的验​​证部分对应于测试集

可以做到这一点。但是考虑到这种没有预先放置任何数据的拆分,必须注意不要使用不同的设置重新运行外部交叉验证,因为在这种情况下,您没有未污染的数据可用于最终估计泛化能力和误差。

关于忽略测试集和超参数优化参数的验证过程

基本上,验证本身是好的和有效的!将用户分成多个折叠会改变训练数据中存在的兴趣组合,同时在特定日期拆分每个用户配置文件会考虑“新项目进入”或“当下热门”等及时方面。

一些想法基于我自己的经验...

(外部)交叉验证的重复

您可以在不改变模型的超参数的情况下对不同的用户和评级拆分重复交叉验证,以获得更可靠的泛化误差估计。注意不要经常重复(根据 Kohavi 对交叉验证的分析,我推荐 6-10 次),因为重复次数越多,再次发生相同类型拆分的概率就越高。

沉思:在某个日期放弃分裂?

一个建议:在特定日期拆分的缺点是训练数据和验证数据的数量可能因用户而异,具体取决于他们的活动水平。区分这些类型的用户可能有助于首先构建一个好的推荐器,然后使其也适用于少量数据。

为了解释这一点,可以...

  • 要么不要在训练数据量很小的情况下使用用户进行验证。
  • 在日期删除拆分并随机拆分评级(例如2/3 / 1/3或类似的东西)。这仅适用于动态较少的项目(书籍、电影),然后是动态高的项目(时尚)。为了以某种方式平衡这一点,我将验证限制在某个时间范围内(例如一个月)至少发生一次的项目。时间范围是根据项目的动态来选择的,即它代表项目/评级发生可以被认为是稳定的时间范围。

思考:放弃用户分裂?

当推荐系统在实践中应用时,所有在发布日期之前有活动的用户都是已知的。因此,以这样一种方式拆分用户,将一些用户放入训练折叠中,而另一些放入验证折叠中是不太现实的。在特定日期或随机(2/3 / 1/3)拆分每个用户的评分会更现实,使用拆分训练部分中所有用户的所有数据进行构建,其余用于相应的验证.

但是,与用户和评级拆分的唯一区别是,仅评级拆分可以在日期拆分之前在验证折叠中利用用户的评级。所以总的来说差别不大。user-and-rating-splitting 让模型训练变得更难一些,但另一方面又增强了稳定性。这是某种正则化。