简介这是一套基于协同过滤推荐算法的电影推荐系统毕业设计项目面向计算机、信息管理及相关专业学生可用于毕业设计、课程设计或期末大作业。项目已通过导师指导与答辩评审分高达97分代码完整、数据齐全下载后即可运行无需二次修改。资源包共687个文件涵盖Python后端源码、Vue前端组件、JavaScript与CSS样式、SQL数据库脚本及毕业论文文档同时附有安装、运行、构建批处理脚本和清晰目录结构整体约13.32MB便于快速启动与查看。目前已有356人学习下载。通过该项目可深入理解协同过滤算法原理、推荐流程实现、前后端数据交互及项目部署方式尤其适合需要参考完整毕设源码与论文撰写思路的学习者。1. 一个毕设题为什么大家都选协同过滤电影推荐每年一到毕设季「Python 基于协同过滤推荐算法的电影推荐系统」都会出现在选题清单的前排这当然不奇怪推荐系统是算法方向里少数能在单机、离线、小数据量下讲清楚完整闭环的题目。标题里这个 zip 包本质上是把一套最小可用工程装进了压缩包——能跑的 Python 源码、一份足够做实验的电影评分数据、一篇能对着改的毕业论文。它真正解决的痛点是「公式会背但工程不会搭」很多同学知道协同过滤的原理却不知道怎么把公式变成能答辩、能演示、能写进论文的完整系统。这篇笔记按我自己做这个方向的经验来写把数据预处理、UserCF 与 ItemCF 实现、相似度度量选型、离线评估到论文图表这条链路拆开讲顺带把所有我踩过的坑标出来。适合两类人需要完成毕设的学生以及想快速落地一个离线推荐 Demo 的开发者。2. 协同过滤的两条主线UserCF 与 ItemCF 怎么选2.1 基于用户的协同过滤UserCF找口味相似的人借用他们的片单协同过滤的核心假设很朴素过去口味相近的人未来的口味也相近。基于用户的协同过滤UserCF就是把这句话直接翻译成算法——先找到和目标用户最像的一批用户再把这些近邻看过、而目标用户没看过的电影捞出来用相似度做权重预估目标用户会给每部候选电影打多少分最后按预估值排序取前 N 个推荐。具体落地可以拆成三步第一步用评分记录计算用户之间的相似度矩阵维度是 user × user第二步对目标用户 u从相似度矩阵里取出相似度最高的 k 个近邻第三步用近邻对候选电影的评分做加权平均得到 u 对电影 i 的预测分。第 3 步最常见的预测公式长这样pred(u, i) Σ_{v∈N(u)} sim(u,v) × r(v,i) / Σ_{v∈N(u)} |sim(u,v)|其中 N(u) 是目标用户 u 的近邻集合sim(u,v) 是用户 u 和用户 v 的相似度r(v,i) 是近邻 v 对电影 i 的评分。这个公式的分子是「相似度加权的评分和」分母是「相似度绝对值之和」作用是把预测分归一化到和原始评分相近的量纲。如果候选电影在任何一个近邻的评分记录里都没出现过分子直接是 0这部电影就不会进入推荐列表。动手之前我习惯先读数据、构建评分矩阵确认数据量和稀疏度再决定方案。下面是最小可运行的加载与建矩阵代码import pandas as pd # 读取评分数据常见列名userId、movieId、rating、timestamp ratings pd.read_csv(ratings.csv) print(ratings.head()) print(评分记录数:, len(ratings)) print(用户数:, ratings[userId].nunique()) print(电影数:, ratings[movieId].nunique()) # 构建 user-item 评分矩阵行是用户列是电影 user_item ratings.pivot_table( indexuserId, columnsmovieId, valuesrating ).fillna(0) print(评分矩阵形状:, user_item.shape) sparsity 1 - (ratings.shape[0] / (user_item.shape[0] * user_item.shape[1])) print(稀疏度: {:.4f}.format(sparsity))pivot_table 把长表变成了宽表行是用户、列是电影、值是评分。.fillna(0)在这里只是教学便利让矩阵能参与后续运算但真正算相似度时直接拿 0 填充会有大坑后面第 5 章会专门展开。稀疏度是 1 减去非零评分占比电影推荐数据里 95% 以上稀疏是常态看到这个数字不需要慌——算法本来就要在稀疏数据上工作关键是怎么处理稀疏带来的相似度失真。2.2 基于物品的协同过滤ItemCF换一个方向找相似的电影ItemCF 的思路是换了个方向不再找相似的人而是找相似的电影。它背后的假设是「用户喜欢某部电影很可能也会喜欢与它相似的其他电影」。这里要特别注意「相似」不是指题材、导演、年代这些内容属性而是指「被同一批用户喜欢」的共现关系——在协同过滤里两部电影相似是因为大量用户同时给它们打了分而不是因为它们长得像。ItemCF 的计算也可以拆成两步第一步根据所有用户的评分记录计算电影之间的相似度矩阵维度是 item × item第二步对目标用户 u 评分过的每部电影 j在相似度矩阵里找到 j 的相似电影 i用 u 对 j 的评分乘以 sim(i,j) 加权累加得到 u 对 i 的预测分。预测公式和 UserCF 几乎对称只是下标从用户换成了电影pred(u, i) Σ_{j∈H(u)} sim(i,j) × r(u,j) / Σ_{j∈H(u)} |sim(i,j)|H(u) 是用户 u 评分过的电影集合。这个公式有个容易被忽略的前提候选电影 i 必须是用户没评分过的否则推荐就没有意义。所以 ItemCF 的推荐流程通常是四步取出用户已评分的电影集合对集合里每部电影在 item 相似度矩阵里找出 Top-N 相似电影合并成候选集过滤掉用户已经评分过的电影用加权公式算候选集预测分排序取前 K 个。在电影场景里 ItemCF 有一个天然优势物品之间的关系比用户关系稳定得多。用户的兴趣会漂移今年喜欢科幻、明年看文艺片但《某科幻片A》和《某科幻片B》是否被同一批人评分短期内不会剧烈变化。这意味着物品相似度矩阵可以离线算好、定时更新每次推荐请求只做查表和加权求和工程上非常舒服。UserCF 则需要根据最新用户行为频繁重算用户相似度在线系统里代价高很多。2.3 毕设场景下为什么把 ItemCF 当主力UserCF 当对照组很多教程一开篇就写 UserCF因为它概念上更直观先入为主。但真做毕设或离线 Demo我一般建议把 ItemCF 当主力理由有三条都很实际。第一ItemCF 的相似度矩阵规模更可控。典型电影场景里电影数量几千到几万远小于用户数量几万到几十万item × item 矩阵的内存占用比 user × user 小一个量级。我用一份十万级评分记录做过对比user × user 矩阵在普通笔记本上已经能明显感觉到卡顿item × item 却能秒级算出。毕设演示现场如果是老笔记本这个差距直接决定你能不能在评委面前流畅跑起来。第二ItemCF 的可解释性强答辩演示效果好。推荐理由可以直接写成「因为你喜欢《某电影A》所以推荐相似的《某电影B》」评委一听就懂。UserCF 的推荐理由是「因为和你口味相近的用户也在看」解释起来绕一圈还容易暴露数据稀疏的软肋——一旦近邻本身就不够像这个理由就很苍白。第三论文里做对比实验省力。同一份数据上把两个模型都跑一遍画出精确率、召回率随近邻数 K 变化的曲线两组实验就撑起了「实验与分析」这一章。只做单模型的话图表会很单薄评委也容易问「你为什么不试试另一个」。对比项UserCFItemCF相似度矩阵user × useritem × item矩阵规模随用户量增长容易爆炸电影数通常小于用户数可解释性弱理由绕强可直接落到电影相似度稳定性用户兴趣漂移需频繁更新物品关系稳定可离线定时重算冷启动短板新用户无历史无法找近邻新电影无共现无法算相似所以我的结论是毕设主实现选 ItemCFUserCF 作为 baseline 和对比对象保留两个都写在论文里。这样既保证了演示效果又让实验章节有对比可写工作量分配也合理。3. 数据预处理与评分矩阵从长表到相似度计算的三个准备3.1 电影评分数据的标准结构与加载检查无论数据从哪来电影评分数据的结构基本逃不开两张表。评分表每条记录是一个用户对一部电影的一次打分最少包含 userId、movieId、rating 三个字段电影信息表最少包含 movieId、title、genres。有些版本会额外带 timestamp 时间戳这个字段后面做时间切分的评估实验时非常值钱千万不要为了省事删掉。拿到一份数据不要急着跑推荐先做三件事检查每一件都能在后期替你省掉数小时的排查时间。第一userId 和 movieId 是否有缺失或非数字脏值第二rating 是否在合法区间常见是 1 到 5 的整数或半整数也有 0 到 10 的变体第三同一个 (userId, movieId) 是否出现重复评分记录。这三个问题在公开数据集和手工整理的数据里都出现过最后一种最隐蔽。import pandas as pd ratings pd.read_csv(ratings.csv) movies pd.read_csv(movies.csv) # 1. 字段完整性检查 print(ratings.isnull().sum()) print(movies.isnull().sum()) # 2. 评分取值区间检查 print(ratings[rating].describe()) # 3. 重复评分检查同一用户对同一电影理应只有一条评分 dup ratings.duplicated(subset[userId, movieId], keepFalse) print(重复评分记录数:, dup.sum()) if dup.sum() 0: ratings ratings.drop_duplicates(subset[userId, movieId], keepfirst) # 4. 剔除评分不在合法区间的脏数据 ratings ratings[(ratings[rating] 1) (ratings[rating] 5)]pd.read_csv 读进来后isnull().sum() 能快速看到每一列的缺失量。评分表里如果出现空行多数是从 Excel 转 CSV 时带入的直接 dropna 就行。重复评分是最值得警惕的有些数据做了多版本合并同一用户对同一电影的多次打分可能来自不同采集批次如果不去重后面 pivot 成矩阵时 pandas 会报错或做隐式聚合行为不可控。这里刻意用 keepfirst 而不是求均值是为了保证「一次评分行为只计一次」语义上更干净也更容易在论文里说明。3.2 从长表到评分矩阵pivot、稀疏度与存储陷阱用户的评分数据天然是长表long format一行一个评分事件像流水账。但协同过滤算法需要的是宽表wide format行是用户、列是电影、单元格是评分。pivot_table 是把长表转宽表最直接的工具一行代码就能完成。# 构建评分矩阵行用户列电影值评分 user_item ratings.pivot_table( indexuserId, columnsmovieId, valuesrating ) print(user_item.shape) # 稀疏度计算1 - 非空评分数 / 矩阵总格子数 nonzero user_item.count().sum() total user_item.shape[0] * user_item.shape[1] sparsity 1 - nonzero / total print(稀疏度: {:.4f}.format(sparsity))电影推荐数据的稀疏度通常在 95% 以上这很正常不需要处理成稠密。真正需要注意的是内存pandas 的宽表里大量单元格是 NaN但 pandas 依然按双精度浮点为每个格子分配空间。粗略估算10 万条评分、1 万部电影、2 万用户宽表就是 2 亿个浮点数约 1.6GB 内存普通笔记本在这个规模上已经明显吃紧。所以后续算相似度时我一般不用这个稠密宽表直接算而是改用 scipy 的稀疏矩阵或者干脆在长表上做聚合计算。把宽表当成理解数据结构、做可视化的教学工具把稀疏矩阵当成真正能跑大批量的工程工具两条路线心里都要有数。如果毕设数据超过几十万条评分这一步的选型直接决定了后面代码能不能跑完。3.3 相似度度量怎么选余弦、皮尔逊与修正余弦协同过滤的核心计算是相似度而相似度度量选错后面一切白搭。常见的候选有三个余弦相似度、皮尔逊相关系数、修正余弦相似度。它们之间的差别本质上是「做没做均值中心化」以及「在哪个维度上做中心化」。度量公式要点对评分尺度是否敏感适用场景余弦相似度计算向量夹角余弦不做任何中心化敏感打分手松手紧会被误判为不相似评分尺度差异小的数据皮尔逊相关系数先对每个用户做均值中心化再算余弦不敏感消除用户打分的宽严差异UserCF 优先选它修正余弦相似度先对每个电影做均值中心化再算余弦不敏感消除电影热度导致的评分基准差异ItemCF 优先选它这里解释一下为什么皮尔逊适合 UserCF假设用户 A 习惯给分偏低平均只打 3 分用户 B 习惯给分偏高平均打 4 分两人对同一批电影的实际偏好可能完全一致但原始余弦相似度会因为「尺度错位」被拉低。对每个用户减去自己的平均分后剩下的就是「相对自己平均水平的偏好偏差」这时候再算余弦才能真实反映口味接近程度。修正余弦对 ItemCF 同理不过减去的是电影自己的平均分——热门电影普遍高分冷门电影分低减去电影均值后剩下的才是「用户对这部电影偏离其自身基准」的信号。def cosine_sim(mat): mat 的每一行是一个向量计算行与行之间的余弦相似度 norm np.sqrt((mat * mat).sum(axis1)) norm[norm 0] 1e-10 return (mat mat.T) / np.outer(norm, norm) def pearson_sim(mat): 先对每行做均值中心化再用余弦公式等价于皮尔逊系数 mat_centered mat - mat.mean(axis1, keepdimsTrue) return cosine_sim(mat_centered)实际做毕设时我的默认配置是UserCF 用皮尔逊ItemCF 用修正余弦。如果发现推荐结果「谁都不像谁」先别怀疑算法本身回头检查这三节的内容数据去重了吗、评分区间过滤了吗、相似度度量选对了吗。这三个环节出问题的概率比算法本身出问题的概率高得多。4. 推荐引擎核心实现UserCF 与 ItemCF 的完整代码与参数4.1 稀疏矩阵构建先解决内存再谈算法第 3 章说过几万用户乘几万电影的稠密矩阵会撑爆笔记本内存。所以真正写推荐引擎之前第一步是把评分数据转成 scipy 的稀疏矩阵。这一步做对了后面所有矩阵乘法都又快又省内存。import numpy as np from scipy.sparse import csr_matrix, diags def build_user_item_sparse(df): 把评分长表转成 user x item 的 CSR 稀疏矩阵 user_list sorted(df[userId].unique()) movie_list sorted(df[movieId].unique()) user_index {u: i for i, u in enumerate(user_list)} movie_index {m: i for i, m in enumerate(movie_list)} rows df[userId].map(user_index).values cols df[movieId].map(movie_index).values data df[rating].values.astype(float) mat csr_matrix((data, (rows, cols)), shape(len(user_list), len(movie_list))) return mat, user_list, movie_list, user_index, movie_index def mean_center_rows(mat): 对用户行做均值中心化只调整非零位置保留稀疏结构 mat mat.tolil(copyTrue) row_mean np.asarray(mat.mean(axis1)).ravel() for i in range(mat.shape[0]): if row_mean[i] 0: continue data mat.data[i] for j in range(len(data)): data[j] - row_mean[i] return mat.tocsr() def cosine_sim_sparse(mat): 稀疏矩阵行与行之间的余弦相似度行归一化后做矩阵乘法 norm np.sqrt(np.asarray(mat.multiply(mat).sum(axis1)).ravel()) norm[norm 0] 1e-10 mat_norm diags(1.0 / norm) mat return mat_norm mat_norm.T这里的关键是 mean_center_rows 里用 tolist 格式逐行修改非零元素而不是用 numpy 直接对稠密矩阵操作。tolil 是行列表格式遍历每一行的非零下标和值逐个减去该行均值改动完再转回 CSR。这样中心化过程不会把隐式的 0 变成非零值稀疏度保持不变。cosine_sim_sparse 先按行求 L2 范数再用对角矩阵做行归一化最后用矩阵乘法一次算出所有行对行相似度比双重 for 循环快几个数量级。4.2 UserCF 完整实现近邻选择与加权预测有了稀疏矩阵和相似度函数UserCF 就可以封装成一个类。核心逻辑是第 2 章的公式先算用户相似度矩阵再对目标用户取 top-k 近邻最后用近邻评分做加权预测。class UserCFRecommender: def __init__(self, user_item_mat, k10, min_common3): self.mat user_item_mat # user x item 稀疏矩阵 self.k k # 近邻数 self.min_common min_common # 最少共同评分数低于此值视为不相似 self.user_sim None def fit(self): # 用均值中心化后的矩阵计算用户相似度即皮尔逊相似度 centered mean_center_rows(self.mat) self.user_sim cosine_sim_sparse(centered) self.user_sim[self.user_sim 0] 0 # 负相似度直接置 0不进近邻 np.fill_diagonal(self.user_sim, 0) # 自己不算自己的近邻 def recommend(self, user_idx, top_n10): sim_row self.user_sim[user_idx].toarray().ravel() # 取相似度最高的 k 个近邻 k min(self.k, len(sim_row)) neighbor_idx np.argsort(sim_row)[::-1][:k] neighbor_weights sim_row[neighbor_idx] if neighbor_weights.sum() 0: return [] # 近邻评分加权求和近邻权重向量 近邻评分矩阵 neighbor_mat self.mat[neighbor_idx] # k x M 稀疏 pred (neighbor_weights.reshape(1, -1) neighbor_mat) pred pred.toarray().ravel() / neighbor_weights.sum() # 用户已看过的电影不能推荐预测分置为负无穷 rated self.mat[user_idx].indices pred[rated] -np.inf # 取 top_n 个预测分最高的电影 top_idx np.argsort(pred)[::-1][:top_n] result [(int(idx), float(pred[idx])) for idx in top_idx if pred[idx] 0] return resultfit 阶段把负相似度清零是因为负相关的用户在推荐场景里没有意义让负权重参与加权会把预测分搅乱还可能导致推荐的电影和用户偏好反向。diagonal 置零是防止用户把自己当近邻自己对自己的相似度一定是 1不排除的话每个用户的近邻列表第一位都是自己推荐就变成了「复述历史评分」。recommend 里最关键的一行是neighbor_weights.reshape(1, -1) neighbor_mat它把近邻相似度作为权重对近邻的评分矩阵做一次加权求和得到一个长度为电影总数的预测分向量。除以权重和是为了归一化让预测分和原始评分的量纲一致。最后用pred[rated] -np.inf把已看电影排除再取 Top-N。这里要注意 pred 里的 0 分项它们代表没有任何近邻评过这些电影pred[idx] 0这个过滤条件会顺手把它们挡掉。4.3 ItemCF 完整实现物品相似度离线计算与推荐ItemCF 的实现结构几乎一样差别只在相似度矩阵的构建方向和推荐时的查询方式。fit 阶段计算的是 item × item 相似度推荐阶段从用户的历史评分电影出发去相似度矩阵里找候选电影。class ItemCFRecommender: def __init__(self, user_item_mat, k10): self.mat user_item_mat # user x item 稀疏矩阵 self.k k self.item_sim None def fit(self): # 修正余弦先对用户行做均值中心化再转置得到 item x user 矩阵 centered mean_center_rows(self.mat) item_mat centered.T # item x user self.item_sim cosine_sim_sparse(item_mat) self.item_sim[self.item_sim 0] 0 np.fill_diagonal(self.item_sim, 0) def recommend(self, user_idx, top_n10): rated_items self.mat[user_idx].indices # 用户已评分的电影下标 if len(rated_items) 0: return [] # 取这些电影的相似电影构成候选集和对应相似度 sim_sub self.item_sim[rated_items] # len(rated) x M # 用户对已评分电影的实际评分作为权重 user_row self.mat[user_idx].toarray().ravel() weights user_row[rated_items] # 加权求和权重向量 候选相似度矩阵 pred (weights.reshape(1, -1) sim_sub).toarray().ravel() # 用相似度绝对值之和做归一化 sim_sum np.abs(sim_sub).sum(axis0) sim_sum[sim_sum 0] 1e-10 pred pred / sim_sum pred[rated_items] -np.inf # 排除已看过的电影 top_idx np.argsort(pred)[::-1][:top_n] result [(int(idx), float(pred[idx])) for idx in top_idx if pred[idx] 0] return resultItemCF 的 fit 比 UserCF 多一次转置把 user × item 矩阵转成 item × user 后每行变成「一部电影在所有用户上的评分向量」行与行之间的余弦相似度就是电影之间的相似度。这里用的是修正余弦因为在 mean_center_rows 中已经对用户均值做了中心化转置后算余弦时这部分中心化信息会保留在向量里等价于修正余弦的定义。推荐阶段的权重用的是用户的实际评分weights user_row[rated_items]意思是用户给《某电影A》打了 5 分那么 A 的相似电影在预测分里的贡献就大给《某电影B》打了 2 分B 的相似电影贡献就小。这个设计既利用了相似度结构又利用了用户的偏好强度是 ItemCF 里最值得在论文里展开讲的一个点。归一化分母用np.abs(sim_sub).sum(axis0)而不是原始和是为了和预测公式里的绝对值保持一致避免负相似度把分母拉小导致预测分虚高。4.4 核心参数怎么设k 值、min_common 与相似度阈值代码能跑通之后调参就是决定推荐质量的关键这部分也是最容易被毕设论文带过但答辩必问的地方。近邻数 k 是最直接的参数。k 太小近邻只有两三个人评分记录少预测方差大推荐结果像抽签k 太大混进来大量相关性很弱的用户或电影预测被平均掉了推荐结果趋于热门榜。以十万级评分数量的公开数据为例k 在 10 到 50 之间通常是比较稳的区间具体值要靠第 6 章的评估实验去扫不建议拍脑袋定。min_common 是容易被忽略但非常关键的保护参数。两个用户如果只共同评过一两部电影算出来的相似度往往虚高——他们可能只是碰巧都看过《某热门电影A》并不能代表口味一致。设置 min_common 为 3 或 5意思是一对用户至少共同评过这么多部电影才算有效相似度否则相似度直接置 0。这个参数能显著压低「伪相似度」带来的推荐噪声在稀疏数据上几乎是必开项。def prune_with_min_common(sim_mat, co_occurrence, min_common3): 把共同评分数低于阈值的相似度对置为 0 sim_pruned sim_mat.copy() sim_pruned[co_occurrence min_common] 0 return sim_pruned实践上我一般这么组合UserCF 设 min_common3k 扫描 5/10/20/30ItemCF 设 min_common5k 扫描 5/10/20。评分数据越稀疏min_common 越不能设太大否则有效相似度对太少推荐列表会变得很短。这两个参数加上相似度度量选型就是论文「参数分析」小节的全部素材。5. 协同过滤毕设避坑5 个高频翻车现场与排查方案5.1 相似度全是零推荐结果像抽签现象跑完 fit 后打印相似度矩阵发现绝大多数相似度都是 0正的非零值寥寥无几推荐出来的电影和用户历史评分毫无关系每次运行结果还不太一样。原因数据稀疏度过高大多数用户之间根本没有共同评分的电影。没有共同评分余弦相似度天然就是 0。第 2 章说过电影数据稀疏度 95% 以上是常态在这样一张矩阵上做近邻选择选出来的「近邻」其实是随机用户推荐结果当然像抽签。解决两层措施。第一层给相似度计算加 min_common 门槛共同评分数小于阈值的相似度直接清零宁缺毋滥保证进入近邻池的都是「真的认识」的用户或电影。第二层是给冷启动用户兜底如果一个用户的历史评分少于 min_common说明他本身就无法参与协同过滤此时直接回退到热门电影榜别硬算。热门榜可以用评分数最多的前 50 部电影生成这是工程里最常见的冷启动兜底方案。5.2 中心化没做对评分习惯差异毁掉相似度现象UserCF 的推荐结果里全是「打分慷慨」的用户爱看的电影习惯打低分的用户永远得不到他们真正想要的推荐或者 ItemCF 推荐的全是热门电影冷门好片几乎没有露脸机会。原因用了原始余弦相似度没有做均值中心化。打分手松的用户普遍给高分手紧的用户普遍给低分原始余弦会把这种「系统性的尺度差异」误判成「口味差异」。ItemCF 那边则是电影热度干扰热门电影普遍高分冷门电影普遍低分不减去电影均值相似度里混入的全是热度信号偏好信号被淹没。解决UserCF 用皮尔逊相关系数实现上就是在算余弦前先对每个用户行做均值中心化ItemCF 用修正余弦同样是先做用户均值中心化再转置算电影相似度。判断有没有做对的土办法打印自己和自己相似度为 1 的那个用户看他推荐列表里是否有明显偏好评分的迹象或者随机抽两个平均分差异很大的用户算一下原始余弦和中心化后余弦的差差异明显说明中心化确实起了作用。这一步做对了推荐列表的主观质量提升是肉眼可见的。5.3 随机切分训练集和测试集评估指标虚高现象离线评估精确率做到了 0.3 以上觉得很不错但答辩现场演示或者让身边同学试用时推荐效果明显没有评估数字那么好看落差很大。原因随机切分训练集和测试集造成了时间穿越。协同过滤依赖的是「过去的行为预测未来的行为」如果把时间上靠后的评分混进训练集模型相当于「偷看」了未来的答案。比如用户上周才看的电影被随机分到了训练集模型学到了这个行为再去预测本周的评分自然一猜一个准。评估数字虚高但真实场景里没有这个优势。解决按时间戳切分。用评分记录里的 timestamp 字段排序前 80% 时间范围内的评分做训练集后 20% 做测试集。如果数据没有 timestamp至少也要按用户维度切分先把这个用户前 80% 的评分事件分到训练集后 20% 分到测试集。切分完成后评估出来的精确率、召回率才会和真实场景接近也才能在论文里理直气壮地说模型的泛化能力。# 按时间切分前 80% 时间内的评分做训练后 20% 做测试 ratings ratings.sort_values(timestamp) cutoff int(len(ratings) * 0.8) train ratings.iloc[:cutoff] test ratings.iloc[cutoff:]5.4 全量相似度矩阵把内存打爆现象执行cosine_sim_sparse或pearson_sim时笔记本风扇狂转再过一会儿进程被系统杀掉报 MemoryError连保存的内核日志都来不及看。原因相似度矩阵虽然逻辑上是稀疏的但计算过程中间结果可能是稠密的。user × user 矩阵在用户数五万时就是 25 亿个浮点数约 2GB 起步item × item 在一万部电影时也有 1 亿个格子。如果用双重 for 循环逐对计算再填充更是会把 O(n²) 的时间复杂度变成实际的等待灾难。解决从三个方向下手。第一数据层做截断把评分记录少于 5 条的用户和电影直接过滤掉这叫「冷启动清洗」既降内存又提质量。第二计算层避免 dense 转换全程用 scipy 稀疏矩阵正如图 4.1 里的实现行归一化用对角矩阵做乘法不要把稀疏矩阵转成 numpy 稠密数组。第三如果数据量实在大就把相似度计算按块切分每次只算 1000 × 1000 的块写回磁盘或内存共享文件。毕设数据规模下前两层手段通常足够。5.5 论文公式和代码实现「两张皮」答辩一问就穿帮现象论文里写着皮尔逊相关系数公式代码里用的却是原始余弦论文里预测公式带 abs 绝对值归一化代码实现里是简单的加权求和评委追问一行代码的数学含义答不上来。原因写代码和写论文的时间隔得太久两边各写各的没有对齐。这是毕设里最常见的低级失误但杀伤力很大——算法类毕设的评委一定会看核心公式然后和代码做对应对不上就会质疑工作的真实性。解决写完代码后把论文里的公式逐个编号在代码注释里标出「这个公式对应第 3.2 节的式 (3.1)」实现细节也保持一致。比如论文写的是皮尔逊代码里就一定要有均值中心化那一步缺了就是硬伤。建议在提交前做一次「公式-代码对照检查」把每一个矩阵运算都问一遍这一步对应论文里的哪个符号、哪个下标、哪个归一化因子。能逐行解释清楚自己代码的人答辩场上基本不会被动。6. 把离线评估做成答辩亮点切分策略、指标计算与参数寻优离线评估是算法类毕设里最能体现工程素养的部分也是评委最常追问的环节。别只给一个精确率数字给出「切分策略 多个指标 参数扫描曲线」的组合说服力会强很多。评估流程我一般固定为四步第一步按时间或按用户切分训练集和测试集这一步在第 5.3 节已经讲过时间切分优先第二步定义指标毕设里用精确率 PrecisionN、召回率 RecallN、覆盖率 Coverage 三个就够第三步把近邻数 k 按 5/10/20/30/50 扫描画出指标曲线第四步选曲线上的拐点作为最终参数写进论文。def evaluate(recommender, train_mat, test_df, top_n10): 计算 PrecisionN 和 RecallNtest_df 按用户分组 hit total_pred total_test 0 for user, group in test_df.groupby(userId): test_items set(group[movieId]) if not test_items: continue user_idx user_index[user] rec_items [mid for mid, _ in recommend(test_mat, user_idx, top_n)] rec_set set(rec_items) hit len(rec_set test_items) total_pred len(rec_set) total_test len(test_items) precision hit / total_pred if total_pred else 0.0 recall hit / total_test if total_test else 0.0 return precision, recall注意这里有一个在论文里必须写清楚的操作测评时如果测试集里的用户根本没有出现在训练集的近邻里或者测试集的电影是训练集里没有的新电影推荐列表会为空这些用户要单独统计数量否则分母里混入大量空推荐精确率会被严重稀释。我的习惯是把「空推荐用户占比」也作为一个辅助指标列进表里这能解释很多指标上的异常。参数寻优扫 k 值时别只看精确率最大值。推荐的规律通常是k 小精确率高但召回率低列表窄k 大召回率上升但精确率下降列表趋于热门。合理的选参是找一个两边的折中比如精确率和召回率乘积最大或者 F1 最大。把扫描结果做成表格放进论文再顺手画一条精确率召回率随 k 变化的折线图实验章的厚度立刻就出来了。最后一个习惯是每次跑完实验我都会把数据切分种子固定下来记录在实验日志里。参数扫描的每个结果都对应同一份训练集和测试集指标才能真正可比。答辩前我会把推荐结果里最典型的案例挑两个存成截图比如某个用户的历史评分为《某科幻片A》打了 5 星系统推荐的 Top-1 是《某科幻片B》这个「推荐理由可解释」的案例比任何指标都直观。这个习惯从我做第一个推荐系统沿用到现在救了我好几次——评估数字再漂亮都不如一个让人一眼看懂的真实推荐案例有说服力。希望帮到你。本文还有配套的精品资源点击获取