DFM推荐模型性能停滞问题排查：数据集与架构疑问

一、性能瓶颈：架构还是数据处理？ #

两者都可能存在问题，优先从数据处理维度排查：

• 负采样逻辑的合理性：用“未交互物品”作为负样本存在噪声风险——未交互不代表用户不喜欢，可能是用户从未接触过这些物品（如曝光不足），这类无效负样本会干扰模型学习真实偏好。建议调整：
  • 采用硬负采样：从用户浏览过但未点击/评分的物品中选负样本，而非全部未交互物品；
  • 调整正负样本比例：不必严格1:1，可尝试3:1或5:1的比例，匹配真实场景下的交互分布。
• 显式转隐式的阈值设计：仅将4-5分标为正样本，丢弃1-3分数据会丢失用户“不喜欢”的关键信号，导致模型只能学习正样本特征，无法区分负偏好。建议保留1-3分作为负样本，或至少部分利用这类数据。

架构层面的潜在问题：

• DFM的两路分支（因子分解+全连接）若全连接层过于复杂，易在小数据集上出现过拟合——你训练集指标提升但验证集停滞，符合过拟合特征。建议简化全连接结构，比如减少层数或神经元数量，同时增强正则化（如将lambda提升至1.5-2.0，或把dropout调至0.5）。
• Embedding维度设置：latent features=8对于12k用户和4k物品可能偏低，无法充分捕捉用户/物品的细粒度特征，可尝试提升至16或32，配合更强的正则化防止过拟合。

二、训练推荐系统遗漏的关键要点 #

• 数据划分方式：若采用随机划分训练/验证集，可能存在数据泄露（如验证集中的用户在训练集中有后续交互），导致模型泛化能力虚高。正确做法是按时间划分：将用户早期交互作为训练集，后期交互作为验证集，模拟真实推荐的时序逻辑。
• 评估指标的适配性：AUC和F1-Score适用于样本均衡的分类场景，但推荐系统中正负样本天然不平衡，这类指标无法准确反映模型的推荐能力。建议改用Recall@k、Precision@k、NDCG@k等推荐专属指标，更贴合业务实际。
• 特征工程缺失：仅使用用户/物品ID特征会限制模型表达能力，若有辅助特征（如用户年龄、性别，物品类别、价格）应加入模型；即使无额外特征，也可补充用户/物品的统计特征（如用户平均评分、物品热门程度）。
• 训练策略优化：CPU环境下batch size=16384偏大，可能导致梯度更新不及时，收敛缓慢。可尝试减小batch size至4096或8192，配合学习率调度（如每隔50轮学习率减半），提升模型收敛效率。

三、推荐系统数据集的核心作用 #

1. 提供偏好信号：数据集是模型学习用户-物品交互规律的唯一依据，正样本（高评分交互）定义“用户喜欢什么”，负样本定义“用户可能不喜欢什么”，共同构建用户偏好画像。
2. 验证泛化能力：验证集用于检验模型在未见过的用户/物品交互上的表现，判断模型是否学到通用偏好规律，而非仅记住训练数据。
3. 约束优化方向：数据集的分布直接决定模型的优化路径——若数据存在噪声（如不合理的负样本），模型会学习错误规律，导致泛化能力下降。

内容的提问来源于stack exchange，提问作者Mig Rivera Cueva