简介面向电子设计大赛电赛参赛者、数据挖掘与推荐系统学习者的百度电影推荐比赛评分预测项目资料包聚焦“根据用户历史评分、电影属性、评分时间等多维信息构建预测模型”的任务完整覆盖数据预处理、特征工程、模型选择与调优、评估验证等关键环节也可作为毕业设计开展综合实践的重要参考。包内共34个文件以14个java源码与7个jar依赖库为主辅以readme说明、properties运行配置、trainingset训练集、movie2id和user2id映射表、predict预测输出、gitignore等项目工程文件整体约6.11MB。已有40人学习下载。资料保留了实际参赛项目的工程目录和日志输出便于读者快速复现运行环境理解从数据清洗、评分特征构造到模型输出、结果落盘的具体实现路径进而迁移到其他推荐系统或数据竞赛任务中提升机器学习与数据挖掘的实战能力。1. 电赛百度电影推荐评分预测为什么回归不能当分类做那年我拿电赛的百度电影推荐题练手第一次线上提交就被现实泼了冷水我把评分当成分类问题输出四舍五入的整数RMSE卡在1.2下不去排名掉到后半段。后来改成回归输出浮点数同一个模型分数明显抬了一截。这个比赛的核心就是评分预测——给一批用户-电影-评分三元组训练样本再给一批待预测的(user, movie)对要求预测1到5分的评分官方用RMSE评定。适合刚能跑通回归模型、想完整刷一遍推荐系统流程的人这套参赛包把数据梳理、基线、协同过滤、矩阵分解到融合提交的路径串好了照着复现能直接上手。2. 数据口径三张表、四个字段、一个RMSE脚本打开这份参赛包通常不是文件夹越复杂越好反而是越朴素越省事。推荐系统比赛的数据基本就三类用户信息表、电影信息表、评分记录表。比赛给的数据里评分记录是核心用户和电影表用于做特征工程。我在动手之前会先把文件挨个看一遍确认列名、分隔符、缺失值这一步比调模型更影响结果——后面所有验证都依赖你对数据口径的理解。2.1 参赛包目录长什么样先看目录结构。这个zip里的数据文件一般按下面这种形式组织文件路径内容主要字段data/user.txt用户属性user_id, gender, age, occupationdata/movie.txt电影信息movie_id, title, year, genredata/rating_train.txt训练评分user_id, movie_id, rating, timestampdata/rating_test.txt待预测对user_id, movie_iddoc/数据说明.txt官方赛制与提交格式评分范围、评估指标评分记录表是最容易看走眼的。字段虽然就四个但user_id和movie_id往往是字符串比如“u1001”“m2034”直接读进来会变成object类型。如果后面要接Sklearn或Spark第一步必须统一ID的编码方式否则merge时会出现大量空值。timestamp这一列能利用的价值很高后面按时间切验证集全靠它不要一上来就删掉。电影表里的year和genre是很好的特征。genre一般是一串用竖线分隔的标签比如“动作|冒险|科幻”做特征时要拆开统计而不是把它当单一类目处理。user表相对简单但年龄和职业在冷启动阶段可以兜底——当某个新用户没有任何评分历史时至少能靠同类用户的平均分做个粗糙预测。2.2 先写验证脚本别在没尺子的情况下调模型数据看完了我习惯先把验证框架固定下来再碰任何模型。评分预测最怕的不是模型差而是你根本不知道模型差在哪。验证脚本里要做两件事算RMSE、切验证集。训练测试比分两种看法一种是用train_test_split随机抽另一种是按时间切。比赛要预测的是用户未来的评分随机抽样会把未来信息混进训练集导致线下验证虚高、线上翻车所以我一般直接按时间切。# rmse_utils.py import numpy as np import pandas as pd def rmse(truth, pred): truth np.asarray(truth, dtypenp.float64) pred np.asarray(pred, dtypenp.float64) return float(np.sqrt(np.mean((pred - truth) ** 2))) def split_by_time(df, ratio0.8): df df.sort_values(timestamp).reset_index(dropTrue) cut int(len(df) * ratio) return df.iloc[:cut], df.iloc[cut:]这个脚本的作用有两个rmse函数负责算最终指标的平方根误差split_by_time按时间戳把样本排序取前80%当训练、后20%当验证。这样做是因为线上需要预测的评分都发生在训练数据之后只有用时间切分验证集才能模拟线上环境。参数说明里ratio一般取0.8到0.9太小验证集波动大太大训练集不充分。具体跑的时候可以在0.8附近多试两档看误差变化是否稳定。如果数据没有timestamp就退而求其次用train_test_split(df, test_size0.2, random_state42)但心里要知道这种随机切分偏乐观最终分数要打点折扣看。2.3 提交格式的细节决定你能否进决赛很多人前期模型调得顺利最后栽在提交格式上。这个比赛要求的提交文件一般是一个不带表头的文本文件每行对应一个待预测样本字段顺序为user_id、movie_id、rating_pred评分推荐保留六位小数。行数必须与测试集完全一致多一行或少一行都可能被判无效。检查项要求常见错误行数等于测试集行数合并测试表用了inner join丢了冷门样本预测值范围建议在1到5之间模型预测出负值或大于5的值没有截断小数位保留六位直接提交了整数或者科学计数法文件编码UTF-8微软默认保存成GBK中文备注乱码或换行符错乱这里有个坑我当时踩得很深用DataFrame做merge时如果测试集里有电影在训练评分表里没有出现过map函数会返回NaN最后生成的文件行数看起来没变但NaN会被写成空字符串提交的时候就出事了。所以每次生成提交文件后我用print(submit.shape)核对行数用print(submit.isnull().sum())检查空值这两个打印语句比模型本身还重要。3. 基线跑通均值模型、偏置项与梯度下降任何评分预测任务先跑通一个最朴素的基线再谈高级模型。很多新手上来就套深度学习结果模型框架跑起来了数据预处理没跟上最后分数还不如一个均值模型。先做基线不是为了刷榜而是为了建立一条清晰的参考线后续模型如果连物品均值都打不过那说明问题不在模型结构而在数据或特征侧。3.1 全局均值与物品均值先确认代码没写崩第一个基线是全局均值模型。它的逻辑很简单——不管用户是谁、电影是谁预测值都取所有评分的平均值。看起来蠢但它能验证一条完整的数据通路读数据、算平均值、生成提交文件。分数大概会落在1.2附近的RMSE这个数字会成为后面所有模型的起点。import pandas as pd import numpy as np train pd.read_csv(data/rating_train.txt, sep\t, names[user_id, movie_id, rating, timestamp]) test pd.read_csv(data/rating_test.txt, sep\t, names[user_id, movie_id]) train[rating] train[rating].astype(float) global_mean train[rating].mean() movie_mean train.groupby(movie_id)[rating].mean() test[pred_global] global_mean test[pred_movie] test[movie_id].map(movie_mean).fillna(global_mean) print(global mean predict RMSE on train:, rmse(train[rating], np.full(len(train), global_mean)))逻辑上这步做的是用groupby算出每部电影的平均分然后映射到测试集。核心点在fillna(global_mean)——冷门电影在训练集里没有评分映射后是空值必须用全局均值兜底否则提交文件里会出现空字段。这个兜底动作后面会反复用到。从pred_movie这条预测线来看物品均值通常比全局均值低0.1到0.2个RMSE。原因是评分行为有强烈的物品倾向好电影就是容易得高分烂片就是容易得低分。用物品均值等于先把“这个电影本身的口碑”吃进去了这在冷启动场景下是性价比最高的一步。3.2 用户偏置加电影偏置用梯度下降手写一个baseline物品均值之后第二个该做的是偏置模型。它的思想是评分 全局均值 用户偏置 电影偏置。用户偏置表达的是“这个用户打分是偏松还是偏严”电影偏置表达“这部电影整体口碑的偏移”。from collections import defaultdict def train_bias(df, lr0.01, reg0.02, iters20): global_mean df[rating].mean() bu defaultdict(float) bi defaultdict(float) for _ in range(iters): for u, m, r in df[[user_id, movie_id, rating]].values: pred global_mean bu[u] bi[m] err r - pred bu[u] lr * (err - reg * bu[u]) bi[m] lr * (err - reg * bi[m]) return global_mean, bu, bi这个训练函数用的是随机梯度下降的雏形每个样本进来先算预测误差再沿着误差方向更新该用户和该电影的偏置。lr是学习率控制每一步迈多大reg是正则化系数防止某个只出现过几次的用户或电影偏置被冲到极端值。参数设置上lr0.01、reg0.02、iters20是起步档。数据量大时可以把iters压到10数据量小时可以放到30判断依据是验证集RMSE是否还在下降。与物品均值相比偏置模型一般能再往下拉0.05左右因为它额外吸收了用户打分习惯的信息。注意这里用的是Python的defaultdict(float)好处是没见过的key自动返回0.0预测时不需要再写判断。这个模型最大的短板在于它假设用户和电影的影响是线性的、互不干扰的真实情况下用户喜欢动作片还是文艺片会影响他对一部电影的评分——这部分交给第4章的矩阵分解。3.3 验证集上怎么比较模型验证集必须一视同仁。切完验证集后把所有模型都predict到同一批验证样本上算RMSE再做横向对比。千万别搞混——有些模型用了全部数据训练又拿到全部数据上评这种情况下看到的RMSE是训练集的不能代表线上水平。我在这个阶段会用一张表记录每个模型的表现模型验证集RMSE说明全局均值约1.2基准线物品均值约1.1冷启动用全局均值兜底用户偏置电影偏置约1.05梯度下降训练后续矩阵分解约0.95加了隐向量这张表的目的不是记数字而是确认每一步改进的方向是对的。如果某个模型比上一个还差先检查代码有没有bug再考虑模型设计问题。大部分时候都是数据处理出了毛病不是算法的错。4. 矩阵分解从ItemCF到SVD以及什么时候换Scala偏置模型做到头想再往下压RMSE就得建模用户和电影之间的交互。最经典的手段是协同过滤和矩阵分解。这章会用ItemCF和SVD两条路来讲ItemCF偏向直观的可解释预测SVD则是评分预测里性价比最高的模型。竞赛圈里常说的“电影推荐系统scala”版本就是在这个阶段把训练搬到Spark上去做的。4.1 先算ItemCF用相似电影打分做加权ItemCF的原理是想预测用户u对电影m的评分先找和m最相似的k部电影再看用户u在那些电影上打过分多少按相似度加权求平均。选ItemCF而不是UserCF主要原因是物品数量通常远小于用户数量计算量小且结果稳定而且物品相似度相对用户在短期内变化更慢缓存后能反复用。from scipy.sparse import csr_matrix from sklearn.metrics.pairwise import cosine_similarity R csr_matrix((train[rating], (train[movie_id], train[user_id]))) R R.toarray() sim cosine_similarity(R.T) # 电影与电影的相似度矩阵 def itemcf_predict(movie_id, user_id, sim, R, k30): if movie_id not in movie_id_index: return global_mean idx movie_id_index[movie_id] sim_scores sim[idx] rated np.where(R[:, user_id] 0)[0] rated rated[np.argsort(sim_scores[rated])[-k:]] if len(rated) 0: return global_mean w sim_scores[rated] w[w 0] 0 return np.average(R[rated, user_id], weightsw)这里我把评分矩阵R的行当电影、列当用户。cosine_similarity(R.T)算的是电影间的相似度结果存在sim里。预测时取出用户打过的所有电影找和目标电影最像的top 30部用相似度作为权重做加权平均。这段代码只是功能演示真实工程中建议用稀疏矩阵的knn实现不要toarray展开否则内存会爆掉。它的推广价值在于让“相似物品”这个概念具象化——你会发现续集、同系列电影经常聚成一个紧密的簇这类信号在评分预测里非常强。ItemCF在验证集上通常能跑到和偏置模型持平或略好但它和偏置模型信息重合度高最后融合时权重不宜给太大。4.2 手写正则化SVD矩阵分解的落地写法真正让评分预测分数有明显提升的是带偏置的矩阵分解也就是常说的SVD。它的公式是评分 ≈ 全局均值 用户偏置 电影偏置 用户隐向量·电影隐向量。隐向量就是把用户和电影都映射到一个低维空间维度通常取10到50这个空间里的点积表达了用户和电影之间的匹配程度。import numpy as np from collections import defaultdict def train_svd(df, dim20, lr0.005, reg0.02, epochs30): global_mean df[rating].mean() bu defaultdict(float) bi defaultdict(float) pu defaultdict(lambda: np.random.normal(0, 0.1, dim)) qi defaultdict(lambda: np.random.normal(0, 0.1, dim)) for epoch in range(epochs): df df.sample(frac1, random_state42) for u, m, r in df[[user_id, movie_id, rating]].values: pred global_mean bu[u] bi[m] pu[u].dot(qi[m]) err r - pred pu[u] lr * (err * qi[m] - reg * pu[u]) qi[m] lr * (err * pu[u] - reg * qi[m]) bu[u] lr * (err - reg * bu[u]) bi[m] lr * (err - reg * bi[m]) return pu, qi, bu, bi, global_mean这个train_svd函数把之前偏置模型的更新逻辑扩展了一层除了更新偏置还更新用户隐向量和电影隐向量。点积pu[u].dot(qi[m])是模型逼近用户偏好的核心机制err是当前样本的预测误差沿着误差的反方向推参数就是SGD的本质。参数说明里dim是隐向量维度太小拟合不足太大会过拟合。lr0.005比偏置模型小因为隐向量的参数空间更大步子太大容易震荡。reg0.02是正则化它在每次更新时让向量往零的方向缩一点避免某个用户看了一部电影就被赋予极端权重。epochs决定遍历数据的次数这个值不需要贪多15到30轮之间很容易逼近最优值。和ItemCF比SVD能捕捉到“用户喜欢这类电影”的潜在偏好而不是依赖可观测的显式相似。我的经验是SVD和偏置模型分别单独跑完后再融合效果往往好过只用其中任何一个因为偏置模型负责大势SVD负责细节。4.3 数据量大了再换Scala和Spark如果训练数据从几十万条涨到几百万条Python里的这个双循环就成了瓶颈。我一般把SVD的训练搬到Spark的ALS上用Scala写训练流程。这也是“电影推荐系统scala”这个搜索词常出现的原因——用Spark处理大规模推荐矩阵是工业级的标配做法。import org.apache.spark.ml.recommendation.ALS val als new ALS() .setMaxIter(15) .setRank(50) .setRegParam(0.05) .setUserCol(user_id) .setItemCol(movie_id) .setRatingCol(rating) .setColdStartStrategy(drop) val model als.fit(training) val predictions model.transform(testing)这里的关键参数和Python版本一一对应maxIter相当于epochsrank相当于dimregParam相当于reg。setColdStartStrategy(drop)是Spark里一个容易忽略的坑如果不设置测试集里出现没见过的user或movieALS会输出NaN设置成drop会丢弃这些预测但要注意丢掉的样本需要在提交前手动补全局均值。alpha参数用于隐式反馈但评分预测是显式反馈场景保持默认即可。什么时候换Scala我的判断标准是当单机训练一轮SVD超过15分钟或者内存吃力时就搬到Spark。比赛阶段大多数数据集用Python已经够用没必要为了“技术先进”提前上分布式但如果你要来年再接数据量更大的推荐比赛提前熟悉ALS这套接口会轻松很多。5. 避坑评分预测最容易翻车的五个细节评分预测赛题看着简单坑几乎都在数据口径和验证逻辑里。这章把我在这个项目里踩过、也见过别人踩的五个问题整理出来每条按“现象→原因→解决”的顺序说清楚。5.1 验证集随机切分导致线上翻车现象本地验证RMSE很好看线上提交后分数倒退一大截排名反而落后。原因随机抽样把未来时间的评分混进了训练集模型学到了“未来”的信息而线上测试集里的评分全部发生在训练集之后随机切分的验证结论天然偏乐观。解决优先按时间戳排序再切分用前80%当训练、后20%当验证。没有时间戳时退而求其次按user_id哈希分层抽样至少要保证同一用户的评分不会被全部塞进训练集或验证集。5.2 提交文件行数少了或出现空值现象生成的提交文件只有九成行或者提交后被提示非法。原因合并测试集时用了inner join冷门电影在训练集里没有评分被直接丢弃或者map之后没有fillna空值写入了文件。解决测试集一律用howleft合并预测列全部fillna(global_mean)提交前强制检查submit.shape[0] test.shape[0]和submit.isnull().sum().sum() 0两行断言能拦住八成事故。5.3 把评分当分类导致RMSE卡住现象预测值全是1到5的整数RMSE死活下不去。原因评分看起来是离散值但RMSE是面向连续值的平方损失。模型输出四舍五入的整数等于人为限制了预测精度稍微偏一点就产生不可挽回的损失。解决训练和预测全程用浮点数输出提交前如果官方要求保留六位小数就照做不要round。只有在展示给用户看时再做离散化处理。5.4 Spark上ID类型不一致导致特征错乱现象同一个user_id在训练集和测试集里分别被读成了整数和字符串模型分不对人。原因训练数据清洗时把ID转成了数字测试数据保持原样或者反过来。Spark ALS要求user和item列类型一致否则运行时报错就算不报错也是悄悄把ID错配。解决在Spark里统一用StringIndexer给ID建映射训练和预测共用同一套映射关系提交前用IndexToString把预测结果对应回原始user_id和movie_id。5.5 训练损失下降但验证损失反弹现象训练RMSE一路走低到第12轮后验证RMSE开始回升我还是跑完了30轮。原因模型过拟合了。推荐数据里噪声很多有些用户只看了一部电影就打分这类样本很容易被模型背下来。解决每个epoch结束后在验证集上算一次RMSE记录最优轮次如果验证RMSE连续两轮上升就提前停。SVD的正则化系数从0.02往0.05方向调通常能换回一点稳定性。6. 融合与提交让三个模型互补再踩一脚油门在评分预测比赛里单模型冲到一定分数后就会撞天花板。这时候真正管用的手段是融合把偏置模型、ItemCF和SVD的预测结果按权重叠起来靠各自的优势互补。融合不是玄学它有清晰的逻辑——不同模型的误差来源不一样线性加权能抵消一部分偏差。6.1 加权线性融合的小脚本我一般直接在验证集上优化三个权重目标函数还是RMSE约束是权重和为1。from scipy.optimize import minimize def blend_loss(w): return rmse(val_truth, w[0] * p_bias w[1] * p_itemcf w[2] * p_svd) def constraint(w): return 1.0 - sum(w) ini [0.4, 0.2, 0.4] res minimize(blend_loss, ini, methodNelder-Mead, constraints{type: eq, fun: constraint})这段代码把三个模型在验证集上的预测列当作三个特征用minimize搜索最优权重。blend_loss返回的是当前权重下的RMSEconstraint保证三个权重加起来等于1。经过几轮迭代通常会发现SVD的权重在0.5上下偏置模型和ItemCF瓜分剩下部分。权重稳定后把这组权重应用到测试集上融合预测的RMSE一般比最好的单模型再低0.02到0.03。这个提升在排名榜上可能是几十名的差距。6.2 提交前十分钟的检查清单融合完模型我有一张固定的提交前检查表照着走一遍就安心了检查维度方法通过标准行数与测试集文件逐行比对完全一致空值isnull().sum()为零预测范围截断到1和5之间无NaN、无负值小数位文件里取几条看格式六位小数文件编码用UTF-8保存中文不乱码这张表看着简单每一行都是我翻车后总结出来的。现在每次提交前都强制走一遍前后不超过十分钟但能挡掉八成提交事故。6.3 让最终分数再涨一点的小技巧最后说一个提升很细微但很稳定的技巧在融合后的预测上叠加用户最近评分均值。做法是统计每个用户最近10条评分的时间加权平均值把它作为偏置加到预测结果里。这个特征捕捉的是用户近期打分的松紧变化——比如用户最近连续给了几部烂片低分他对下一部电影也会带有类似的严苛倾向。融合后加上这个微调验证集RMSE通常还能降0.005到0.01幅度不大但在排名胶着时很有价值。从那以后我每次做评分预测任务都会强制走一遍这套流程先按时间切验证集再跑均值基线和偏置模型上SVD融合提交前查行数和空值。这已经是我的肌肉记忆了。希望帮到你。本文还有配套的精品资源点击获取 推荐系统评分预测实战：从均值基线到矩阵分解的完整流程
简介面向电子设计大赛电赛参赛者、数据挖掘与推荐系统学习者的百度电影推荐比赛评分预测项目资料包聚焦“根据用户历史评分、电影属性、评分时间等多维信息构建预测模型”的任务完整覆盖数据预处理、特征工程、模型选择与调优、评估验证等关键环节也可作为毕业设计开展综合实践的重要参考。包内共34个文件以14个java源码与7个jar依赖库为主辅以readme说明、properties运行配置、trainingset训练集、movie2id和user2id映射表、predict预测输出、gitignore等项目工程文件整体约6.11MB。已有40人学习下载。资料保留了实际参赛项目的工程目录和日志输出便于读者快速复现运行环境理解从数据清洗、评分特征构造到模型输出、结果落盘的具体实现路径进而迁移到其他推荐系统或数据竞赛任务中提升机器学习与数据挖掘的实战能力。1. 电赛百度电影推荐评分预测为什么回归不能当分类做那年我拿电赛的百度电影推荐题练手第一次线上提交就被现实泼了冷水我把评分当成分类问题输出四舍五入的整数RMSE卡在1.2下不去排名掉到后半段。后来改成回归输出浮点数同一个模型分数明显抬了一截。这个比赛的核心就是评分预测——给一批用户-电影-评分三元组训练样本再给一批待预测的(user, movie)对要求预测1到5分的评分官方用RMSE评定。适合刚能跑通回归模型、想完整刷一遍推荐系统流程的人这套参赛包把数据梳理、基线、协同过滤、矩阵分解到融合提交的路径串好了照着复现能直接上手。2. 数据口径三张表、四个字段、一个RMSE脚本打开这份参赛包通常不是文件夹越复杂越好反而是越朴素越省事。推荐系统比赛的数据基本就三类用户信息表、电影信息表、评分记录表。比赛给的数据里评分记录是核心用户和电影表用于做特征工程。我在动手之前会先把文件挨个看一遍确认列名、分隔符、缺失值这一步比调模型更影响结果——后面所有验证都依赖你对数据口径的理解。2.1 参赛包目录长什么样先看目录结构。这个zip里的数据文件一般按下面这种形式组织文件路径内容主要字段data/user.txt用户属性user_id, gender, age, occupationdata/movie.txt电影信息movie_id, title, year, genredata/rating_train.txt训练评分user_id, movie_id, rating, timestampdata/rating_test.txt待预测对user_id, movie_iddoc/数据说明.txt官方赛制与提交格式评分范围、评估指标评分记录表是最容易看走眼的。字段虽然就四个但user_id和movie_id往往是字符串比如“u1001”“m2034”直接读进来会变成object类型。如果后面要接Sklearn或Spark第一步必须统一ID的编码方式否则merge时会出现大量空值。timestamp这一列能利用的价值很高后面按时间切验证集全靠它不要一上来就删掉。电影表里的year和genre是很好的特征。genre一般是一串用竖线分隔的标签比如“动作|冒险|科幻”做特征时要拆开统计而不是把它当单一类目处理。user表相对简单但年龄和职业在冷启动阶段可以兜底——当某个新用户没有任何评分历史时至少能靠同类用户的平均分做个粗糙预测。2.2 先写验证脚本别在没尺子的情况下调模型数据看完了我习惯先把验证框架固定下来再碰任何模型。评分预测最怕的不是模型差而是你根本不知道模型差在哪。验证脚本里要做两件事算RMSE、切验证集。训练测试比分两种看法一种是用train_test_split随机抽另一种是按时间切。比赛要预测的是用户未来的评分随机抽样会把未来信息混进训练集导致线下验证虚高、线上翻车所以我一般直接按时间切。# rmse_utils.py import numpy as np import pandas as pd def rmse(truth, pred): truth np.asarray(truth, dtypenp.float64) pred np.asarray(pred, dtypenp.float64) return float(np.sqrt(np.mean((pred - truth) ** 2))) def split_by_time(df, ratio0.8): df df.sort_values(timestamp).reset_index(dropTrue) cut int(len(df) * ratio) return df.iloc[:cut], df.iloc[cut:]这个脚本的作用有两个rmse函数负责算最终指标的平方根误差split_by_time按时间戳把样本排序取前80%当训练、后20%当验证。这样做是因为线上需要预测的评分都发生在训练数据之后只有用时间切分验证集才能模拟线上环境。参数说明里ratio一般取0.8到0.9太小验证集波动大太大训练集不充分。具体跑的时候可以在0.8附近多试两档看误差变化是否稳定。如果数据没有timestamp就退而求其次用train_test_split(df, test_size0.2, random_state42)但心里要知道这种随机切分偏乐观最终分数要打点折扣看。2.3 提交格式的细节决定你能否进决赛很多人前期模型调得顺利最后栽在提交格式上。这个比赛要求的提交文件一般是一个不带表头的文本文件每行对应一个待预测样本字段顺序为user_id、movie_id、rating_pred评分推荐保留六位小数。行数必须与测试集完全一致多一行或少一行都可能被判无效。检查项要求常见错误行数等于测试集行数合并测试表用了inner join丢了冷门样本预测值范围建议在1到5之间模型预测出负值或大于5的值没有截断小数位保留六位直接提交了整数或者科学计数法文件编码UTF-8微软默认保存成GBK中文备注乱码或换行符错乱这里有个坑我当时踩得很深用DataFrame做merge时如果测试集里有电影在训练评分表里没有出现过map函数会返回NaN最后生成的文件行数看起来没变但NaN会被写成空字符串提交的时候就出事了。所以每次生成提交文件后我用print(submit.shape)核对行数用print(submit.isnull().sum())检查空值这两个打印语句比模型本身还重要。3. 基线跑通均值模型、偏置项与梯度下降任何评分预测任务先跑通一个最朴素的基线再谈高级模型。很多新手上来就套深度学习结果模型框架跑起来了数据预处理没跟上最后分数还不如一个均值模型。先做基线不是为了刷榜而是为了建立一条清晰的参考线后续模型如果连物品均值都打不过那说明问题不在模型结构而在数据或特征侧。3.1 全局均值与物品均值先确认代码没写崩第一个基线是全局均值模型。它的逻辑很简单——不管用户是谁、电影是谁预测值都取所有评分的平均值。看起来蠢但它能验证一条完整的数据通路读数据、算平均值、生成提交文件。分数大概会落在1.2附近的RMSE这个数字会成为后面所有模型的起点。import pandas as pd import numpy as np train pd.read_csv(data/rating_train.txt, sep\t, names[user_id, movie_id, rating, timestamp]) test pd.read_csv(data/rating_test.txt, sep\t, names[user_id, movie_id]) train[rating] train[rating].astype(float) global_mean train[rating].mean() movie_mean train.groupby(movie_id)[rating].mean() test[pred_global] global_mean test[pred_movie] test[movie_id].map(movie_mean).fillna(global_mean) print(global mean predict RMSE on train:, rmse(train[rating], np.full(len(train), global_mean)))逻辑上这步做的是用groupby算出每部电影的平均分然后映射到测试集。核心点在fillna(global_mean)——冷门电影在训练集里没有评分映射后是空值必须用全局均值兜底否则提交文件里会出现空字段。这个兜底动作后面会反复用到。从pred_movie这条预测线来看物品均值通常比全局均值低0.1到0.2个RMSE。原因是评分行为有强烈的物品倾向好电影就是容易得高分烂片就是容易得低分。用物品均值等于先把“这个电影本身的口碑”吃进去了这在冷启动场景下是性价比最高的一步。3.2 用户偏置加电影偏置用梯度下降手写一个baseline物品均值之后第二个该做的是偏置模型。它的思想是评分 全局均值 用户偏置 电影偏置。用户偏置表达的是“这个用户打分是偏松还是偏严”电影偏置表达“这部电影整体口碑的偏移”。from collections import defaultdict def train_bias(df, lr0.01, reg0.02, iters20): global_mean df[rating].mean() bu defaultdict(float) bi defaultdict(float) for _ in range(iters): for u, m, r in df[[user_id, movie_id, rating]].values: pred global_mean bu[u] bi[m] err r - pred bu[u] lr * (err - reg * bu[u]) bi[m] lr * (err - reg * bi[m]) return global_mean, bu, bi这个训练函数用的是随机梯度下降的雏形每个样本进来先算预测误差再沿着误差方向更新该用户和该电影的偏置。lr是学习率控制每一步迈多大reg是正则化系数防止某个只出现过几次的用户或电影偏置被冲到极端值。参数设置上lr0.01、reg0.02、iters20是起步档。数据量大时可以把iters压到10数据量小时可以放到30判断依据是验证集RMSE是否还在下降。与物品均值相比偏置模型一般能再往下拉0.05左右因为它额外吸收了用户打分习惯的信息。注意这里用的是Python的defaultdict(float)好处是没见过的key自动返回0.0预测时不需要再写判断。这个模型最大的短板在于它假设用户和电影的影响是线性的、互不干扰的真实情况下用户喜欢动作片还是文艺片会影响他对一部电影的评分——这部分交给第4章的矩阵分解。3.3 验证集上怎么比较模型验证集必须一视同仁。切完验证集后把所有模型都predict到同一批验证样本上算RMSE再做横向对比。千万别搞混——有些模型用了全部数据训练又拿到全部数据上评这种情况下看到的RMSE是训练集的不能代表线上水平。我在这个阶段会用一张表记录每个模型的表现模型验证集RMSE说明全局均值约1.2基准线物品均值约1.1冷启动用全局均值兜底用户偏置电影偏置约1.05梯度下降训练后续矩阵分解约0.95加了隐向量这张表的目的不是记数字而是确认每一步改进的方向是对的。如果某个模型比上一个还差先检查代码有没有bug再考虑模型设计问题。大部分时候都是数据处理出了毛病不是算法的错。4. 矩阵分解从ItemCF到SVD以及什么时候换Scala偏置模型做到头想再往下压RMSE就得建模用户和电影之间的交互。最经典的手段是协同过滤和矩阵分解。这章会用ItemCF和SVD两条路来讲ItemCF偏向直观的可解释预测SVD则是评分预测里性价比最高的模型。竞赛圈里常说的“电影推荐系统scala”版本就是在这个阶段把训练搬到Spark上去做的。4.1 先算ItemCF用相似电影打分做加权ItemCF的原理是想预测用户u对电影m的评分先找和m最相似的k部电影再看用户u在那些电影上打过分多少按相似度加权求平均。选ItemCF而不是UserCF主要原因是物品数量通常远小于用户数量计算量小且结果稳定而且物品相似度相对用户在短期内变化更慢缓存后能反复用。from scipy.sparse import csr_matrix from sklearn.metrics.pairwise import cosine_similarity R csr_matrix((train[rating], (train[movie_id], train[user_id]))) R R.toarray() sim cosine_similarity(R.T) # 电影与电影的相似度矩阵 def itemcf_predict(movie_id, user_id, sim, R, k30): if movie_id not in movie_id_index: return global_mean idx movie_id_index[movie_id] sim_scores sim[idx] rated np.where(R[:, user_id] 0)[0] rated rated[np.argsort(sim_scores[rated])[-k:]] if len(rated) 0: return global_mean w sim_scores[rated] w[w 0] 0 return np.average(R[rated, user_id], weightsw)这里我把评分矩阵R的行当电影、列当用户。cosine_similarity(R.T)算的是电影间的相似度结果存在sim里。预测时取出用户打过的所有电影找和目标电影最像的top 30部用相似度作为权重做加权平均。这段代码只是功能演示真实工程中建议用稀疏矩阵的knn实现不要toarray展开否则内存会爆掉。它的推广价值在于让“相似物品”这个概念具象化——你会发现续集、同系列电影经常聚成一个紧密的簇这类信号在评分预测里非常强。ItemCF在验证集上通常能跑到和偏置模型持平或略好但它和偏置模型信息重合度高最后融合时权重不宜给太大。4.2 手写正则化SVD矩阵分解的落地写法真正让评分预测分数有明显提升的是带偏置的矩阵分解也就是常说的SVD。它的公式是评分 ≈ 全局均值 用户偏置 电影偏置 用户隐向量·电影隐向量。隐向量就是把用户和电影都映射到一个低维空间维度通常取10到50这个空间里的点积表达了用户和电影之间的匹配程度。import numpy as np from collections import defaultdict def train_svd(df, dim20, lr0.005, reg0.02, epochs30): global_mean df[rating].mean() bu defaultdict(float) bi defaultdict(float) pu defaultdict(lambda: np.random.normal(0, 0.1, dim)) qi defaultdict(lambda: np.random.normal(0, 0.1, dim)) for epoch in range(epochs): df df.sample(frac1, random_state42) for u, m, r in df[[user_id, movie_id, rating]].values: pred global_mean bu[u] bi[m] pu[u].dot(qi[m]) err r - pred pu[u] lr * (err * qi[m] - reg * pu[u]) qi[m] lr * (err * pu[u] - reg * qi[m]) bu[u] lr * (err - reg * bu[u]) bi[m] lr * (err - reg * bi[m]) return pu, qi, bu, bi, global_mean这个train_svd函数把之前偏置模型的更新逻辑扩展了一层除了更新偏置还更新用户隐向量和电影隐向量。点积pu[u].dot(qi[m])是模型逼近用户偏好的核心机制err是当前样本的预测误差沿着误差的反方向推参数就是SGD的本质。参数说明里dim是隐向量维度太小拟合不足太大会过拟合。lr0.005比偏置模型小因为隐向量的参数空间更大步子太大容易震荡。reg0.02是正则化它在每次更新时让向量往零的方向缩一点避免某个用户看了一部电影就被赋予极端权重。epochs决定遍历数据的次数这个值不需要贪多15到30轮之间很容易逼近最优值。和ItemCF比SVD能捕捉到“用户喜欢这类电影”的潜在偏好而不是依赖可观测的显式相似。我的经验是SVD和偏置模型分别单独跑完后再融合效果往往好过只用其中任何一个因为偏置模型负责大势SVD负责细节。4.3 数据量大了再换Scala和Spark如果训练数据从几十万条涨到几百万条Python里的这个双循环就成了瓶颈。我一般把SVD的训练搬到Spark的ALS上用Scala写训练流程。这也是“电影推荐系统scala”这个搜索词常出现的原因——用Spark处理大规模推荐矩阵是工业级的标配做法。import org.apache.spark.ml.recommendation.ALS val als new ALS() .setMaxIter(15) .setRank(50) .setRegParam(0.05) .setUserCol(user_id) .setItemCol(movie_id) .setRatingCol(rating) .setColdStartStrategy(drop) val model als.fit(training) val predictions model.transform(testing)这里的关键参数和Python版本一一对应maxIter相当于epochsrank相当于dimregParam相当于reg。setColdStartStrategy(drop)是Spark里一个容易忽略的坑如果不设置测试集里出现没见过的user或movieALS会输出NaN设置成drop会丢弃这些预测但要注意丢掉的样本需要在提交前手动补全局均值。alpha参数用于隐式反馈但评分预测是显式反馈场景保持默认即可。什么时候换Scala我的判断标准是当单机训练一轮SVD超过15分钟或者内存吃力时就搬到Spark。比赛阶段大多数数据集用Python已经够用没必要为了“技术先进”提前上分布式但如果你要来年再接数据量更大的推荐比赛提前熟悉ALS这套接口会轻松很多。5. 避坑评分预测最容易翻车的五个细节评分预测赛题看着简单坑几乎都在数据口径和验证逻辑里。这章把我在这个项目里踩过、也见过别人踩的五个问题整理出来每条按“现象→原因→解决”的顺序说清楚。5.1 验证集随机切分导致线上翻车现象本地验证RMSE很好看线上提交后分数倒退一大截排名反而落后。原因随机抽样把未来时间的评分混进了训练集模型学到了“未来”的信息而线上测试集里的评分全部发生在训练集之后随机切分的验证结论天然偏乐观。解决优先按时间戳排序再切分用前80%当训练、后20%当验证。没有时间戳时退而求其次按user_id哈希分层抽样至少要保证同一用户的评分不会被全部塞进训练集或验证集。5.2 提交文件行数少了或出现空值现象生成的提交文件只有九成行或者提交后被提示非法。原因合并测试集时用了inner join冷门电影在训练集里没有评分被直接丢弃或者map之后没有fillna空值写入了文件。解决测试集一律用howleft合并预测列全部fillna(global_mean)提交前强制检查submit.shape[0] test.shape[0]和submit.isnull().sum().sum() 0两行断言能拦住八成事故。5.3 把评分当分类导致RMSE卡住现象预测值全是1到5的整数RMSE死活下不去。原因评分看起来是离散值但RMSE是面向连续值的平方损失。模型输出四舍五入的整数等于人为限制了预测精度稍微偏一点就产生不可挽回的损失。解决训练和预测全程用浮点数输出提交前如果官方要求保留六位小数就照做不要round。只有在展示给用户看时再做离散化处理。5.4 Spark上ID类型不一致导致特征错乱现象同一个user_id在训练集和测试集里分别被读成了整数和字符串模型分不对人。原因训练数据清洗时把ID转成了数字测试数据保持原样或者反过来。Spark ALS要求user和item列类型一致否则运行时报错就算不报错也是悄悄把ID错配。解决在Spark里统一用StringIndexer给ID建映射训练和预测共用同一套映射关系提交前用IndexToString把预测结果对应回原始user_id和movie_id。5.5 训练损失下降但验证损失反弹现象训练RMSE一路走低到第12轮后验证RMSE开始回升我还是跑完了30轮。原因模型过拟合了。推荐数据里噪声很多有些用户只看了一部电影就打分这类样本很容易被模型背下来。解决每个epoch结束后在验证集上算一次RMSE记录最优轮次如果验证RMSE连续两轮上升就提前停。SVD的正则化系数从0.02往0.05方向调通常能换回一点稳定性。6. 融合与提交让三个模型互补再踩一脚油门在评分预测比赛里单模型冲到一定分数后就会撞天花板。这时候真正管用的手段是融合把偏置模型、ItemCF和SVD的预测结果按权重叠起来靠各自的优势互补。融合不是玄学它有清晰的逻辑——不同模型的误差来源不一样线性加权能抵消一部分偏差。6.1 加权线性融合的小脚本我一般直接在验证集上优化三个权重目标函数还是RMSE约束是权重和为1。from scipy.optimize import minimize def blend_loss(w): return rmse(val_truth, w[0] * p_bias w[1] * p_itemcf w[2] * p_svd) def constraint(w): return 1.0 - sum(w) ini [0.4, 0.2, 0.4] res minimize(blend_loss, ini, methodNelder-Mead, constraints{type: eq, fun: constraint})这段代码把三个模型在验证集上的预测列当作三个特征用minimize搜索最优权重。blend_loss返回的是当前权重下的RMSEconstraint保证三个权重加起来等于1。经过几轮迭代通常会发现SVD的权重在0.5上下偏置模型和ItemCF瓜分剩下部分。权重稳定后把这组权重应用到测试集上融合预测的RMSE一般比最好的单模型再低0.02到0.03。这个提升在排名榜上可能是几十名的差距。6.2 提交前十分钟的检查清单融合完模型我有一张固定的提交前检查表照着走一遍就安心了检查维度方法通过标准行数与测试集文件逐行比对完全一致空值isnull().sum()为零预测范围截断到1和5之间无NaN、无负值小数位文件里取几条看格式六位小数文件编码用UTF-8保存中文不乱码这张表看着简单每一行都是我翻车后总结出来的。现在每次提交前都强制走一遍前后不超过十分钟但能挡掉八成提交事故。6.3 让最终分数再涨一点的小技巧最后说一个提升很细微但很稳定的技巧在融合后的预测上叠加用户最近评分均值。做法是统计每个用户最近10条评分的时间加权平均值把它作为偏置加到预测结果里。这个特征捕捉的是用户近期打分的松紧变化——比如用户最近连续给了几部烂片低分他对下一部电影也会带有类似的严苛倾向。融合后加上这个微调验证集RMSE通常还能降0.005到0.01幅度不大但在排名胶着时很有价值。从那以后我每次做评分预测任务都会强制走一遍这套流程先按时间切验证集再跑均值基线和偏置模型上SVD融合提交前查行数和空值。这已经是我的肌肉记忆了。希望帮到你。本文还有配套的精品资源点击获取