简介：这套电影推荐系统毕业设计项目基于协同过滤推荐算法，面向计算机相关专业正在准备毕设、课程设计或期末大作业的学生，也适合需要算法实战练习的学习者。项目达到98分毕设水平，经过严格调试，可以直接运行。资源共2000个文件、28.03MB，其中Python源码有1159个，覆盖算法逻辑与后台开发，同时配有HTML、CSS、JS前端页面以及图片素材、CSV/JSON数据文件，另附PDF论文和项目说明。目前已有219人学习。整套资料的价值在于它不是零散代码，而是一个能演示、能答辩的完整工程：从数据预处理、用户相似度计算到推荐结果列表生成都有对应实现，配合论文可以深入理解协同过滤原理，并方便二次扩展，节省从零搭建系统的时间。

1. 为什么推荐系统是毕业设计的稳妥选择

每年毕业季，计算机相关专业的学生都在选题上反复纠结。要满足“有算法深度、有实现难度、有演示效果、还能写出论文”这几个条件，可选方向其实并不多。基于协同过滤推荐算法的电影推荐系统恰好卡在这个交叉点上：协同过滤是推荐算法里最经典、被研究得最透的一支，算法原理不冷门，做起来有据可依；电影这个载体又自带天然的演示效果，评分数值直观、结果可视化容易，答辩时老师一眼能看出系统在做什么。

更重要的是，这个方向对 Python 熟练度的要求适中，不需要深度学习那套环境配置和调参成本，一个能在本地跑通的推荐系统，核心算法代码量通常在几百行以内。但它的可扩展性又很强，想让分数往上走，可以在相似度计算、冷启动、混合推荐这些方向上继续深挖。如果你有 Python 基础，想选一个能独立完成、不依赖实验室 GPU 资源、做完还能写出一篇结构完整的毕业论文的方向，这个题目值得认真考虑。

2. 先选对算法路线：基于用户还是基于物品

2.1 两种协同过滤的原理与选型判断

协同过滤的核心假设很简单：相似的人会有相似的喜好，相似的商品会被相似的人喜欢。基于这个假设，算法分为两条路线。基于用户的协同过滤（User-Based Collaborative Filtering，UserCF）先找与你评分行为最相似的一批用户，把他们喜欢而你没看过的电影推荐给你；基于物品的协同过滤（Item-Based Collaborative Filtering，ItemCF）则先计算电影之间的相似度，然后根据你历史评分过的电影，推荐与它们最相似的未看影片。

选哪条路线不能靠直觉，要看数据形态和业务场景。UserCF 适合用户数量相对较少、物品数量大且更新频繁的场景，它的推荐结果带有“群体智慧”色彩，能发现跨类别的意外惊喜；ItemCF 则适合用户数量远大于物品数量的场景，计算出的物品相似度表可以离线预先算好，在线推荐时响应更快、解释性也更好——“因为你给《盗梦空间》打了高分，所以推荐《星际穿越》”，这种理由在电影场景里非常自然。实际做毕业设计时，多数情况下我用 ItemCF 做主线，因为它离线计算、在线查询的特性更好写进系统架构里。

2.2 用余弦相似度计算用户或物品的相似矩阵

相似度计算是整个协同过滤的地基。常见的有余弦相似度、皮尔逊相关系数、Jaccard 相似度三种，其中余弦相似度最容易理解和实现，也是论文里最常作为基准方法出现的。对电影推荐场景，我们把每个用户的评分看成一个向量，向量维度是所有电影数量，用户在没看过的电影上取 0，看过的电影上取 1 到 5 的评分数值。两个用户向量的夹角越小，说明他们的评分习惯越接近。

import numpy as np def cosine_similarity(matrix): # matrix: 形状为 (用户数, 物品数) 的评分矩阵，未评分位置为 0 # 先做行归一化，避免向量长度影响相似度数值 norm = np.linalg.norm(matrix, axis=1, keepdims=True) norm[norm == 0] = 1e-10 # 防止除零，全零行视为与任何人都不相似 normalized = matrix / norm # 相似度矩阵 = 归一化矩阵乘以自身转置 sim_matrix = np.dot(normalized, normalized.T) return sim_matrix # 假设有 4 个用户、5 部电影 ratings = np.array([ [5, 4, 0, 0, 3], [4, 5, 0, 0, 2], [0, 0, 5, 4, 0], [3, 2, 4, 5, 1], ]) sim = cosine_similarity(ratings) print(np.round(sim, 3))

这段代码的关键在两点：一是归一化必须在矩阵乘法之前完成，否则相似度会被用户打分的绝对值带偏，一个习惯打 5 分的用户和一个习惯打 3 分的用户，即使喜好顺序完全一致，算出的余弦相似度也不高；二是norm == 0的保护必须加，如果某个用户一条评分都没有，直接除零会产生 NaN，后续整个相似矩阵都会变成无效值。输出矩阵的sim[i][j]表示用户 i 和用户 j 的相似度，范围在 -1 到 1 之间，值越大越相似。

需要特别说明的是，在 Python 里用np.dot(normalized, normalized.T)直接算全量相似矩阵，内存消耗随用户数平方增长。如果用户数是 5 万，这个矩阵就要占用 50000×50000×8 字节约 20GB，显然不可行。毕设用的公开数据集规模通常可控，但如果你打算换大一点的数据集，相似度计算要改成分批计算或者用稀疏矩阵，后面第 5 章我会专门讲这个坑。

2.3 预测评分与 Top-N 推荐的代码骨架

相似矩阵算出来后，下一步是给目标用户生成推荐列表。对 ItemCF 来说，流程是：找到用户已经评过分的电影集合，遍历这些电影的相似电影，剔除用户已经看过的，按加权得分排序，取前 N 个。加权得分的计算方式是：预测分 = 用户对历史电影的评分 × 该电影与候选电影的相似度，然后求和。

import pandas as pd import numpy as np def recommend_itemcf(user_id, rating_df, item_sim_matrix, top_n=10): # rating_df: 包含 userId, movieId, rating 三列的 DataFrame # item_sim_matrix: 物品相似度矩阵，行和列的索引都是 movieId user_history = rating_df[rating_df['userId'] == user_id] if user_history.empty: return [] # 冷启动用户，返回空列表，交给后续策略处理 # 候选物品的得分字典 scores = {} for _, row in user_history.iterrows(): movie_id = row['movieId'] user_score = row['rating'] # 取当前电影在相似矩阵中的完整行 if movie_id not in item_sim_matrix.index: continue sims = item_sim_matrix.loc[movie_id] # 遍历该电影的所有相似物品 for candidate_id, sim_value in sims.items(): if candidate_id == movie_id: continue if candidate_id in user_history['movieId'].values: continue # 排除用户已经看过的电影 if sim_value <= 0: continue # 只保留正相似的物品，负相似没有推荐意义 scores[candidate_id] = scores.get(candidate_id, 0) + user_score * sim_value ranked = sorted(scores.items(), key=lambda x: x[1], reverse=True) return [movie_id for movie_id, _ in ranked[:top_n]] # 调用示例 # recommend_itemcf(user_id=1, rating_df=ratings_df, item_sim_matrix=item_sim_matrix, top_n=10)

这段代码的运行逻辑不复杂，但有一个性能隐患：内层循环遍历sims.items()时，如果电影总数很大，每次推荐都要扫一遍全量物品相似度，耗时随用户历史评分数量线性放大。毕设阶段数据量不大，能跑通就行，但论文里如果你写了“系统实时响应用户请求”，这个性能问题会被答辩老师追问。我一般会在实现里加一层截断：sims = sims.nlargest(50)，只取每个电影最相似的 50 个物品参与候选，效果损失很小，速度提升明显。

2.4 离线评估指标：精确率、召回率与覆盖率

推荐系统不能“看着像就行”，必须有量化评估。毕设论文里最常用的是离线评测：把数据集按时间顺序切分，前 80% 做训练集，后 20% 做测试集，在训练集上构建相似度和推荐逻辑，然后用测试集验证推荐效果。

三个指标必写。精确率（Precision）衡量推荐列表里有多少是用户真正看过的，等于命中数除以推荐总数；召回率（Recall）衡量用户真正看过的电影里有多少被推荐出来了，等于命中数除以测试集观看总数；覆盖率（Coverage）衡量推荐系统到底推荐了多少不同电影，等于被推荐过的电影数除以电影总数。精确率和召回率是一对矛盾，调大推荐列表长度 N，召回率会上升，精确率往往下降。论文里最好画一张 N 从 5 到 50 的指标变化折线图，这比直接贴一个精度数字更有说服力。

3. 从数据到特征：把公开数据集变成可训练的评分矩阵

3.1 数据集选择与评分矩阵构建

做电影推荐系统，最常用的公开数据集是 GroupLens 的 MovieLens 系列。选哪个版本要看机器配置和论文定位：100K 版本（约 10 万条评分）适合快速跑通全流程，代码调试时间短，但数据太稀疏会导致相似度计算质量一般；1M 版本（约 100 万条评分）是毕设的黄金选择，规模适中、计算时间可控、结果也有区分度。数据文件通常包含ratings.csv（用户 ID、电影 ID、评分、时间戳）、movies.csv（电影 ID、标题、类型）、users.csv（用户 ID、年龄、性别、职业）。

拿到原始数据后第一步不是建模，而是清洗。先检查有没有缺失值和重复评分记录，再把 ID 列统一成整数类型，把时间戳转成可读的日期格式。这里有一个容易被忽视的细节：评分文件里可能同一个用户对同一部电影有多条记录，建模之前必须去重或者保留最近一条，否则相似度计算时同一对 (userId, movieId) 会被重复累加。

import pandas as pd # 加载评分数据 ratings = pd.read_csv('ratings.csv') # 列名: userId, movieId, rating, timestamp movies = pd.read_csv('movies.csv') # 列名: movieId, title, genres # 去重：同一用户对同一电影保留评分时间戳最新的一条 ratings = ratings.sort_values('timestamp').drop_duplicates( subset=['userId', 'movieId'], keep='last' ) # 交叉验证评分范围，MovieLens 评分应为 0.5 到 5.0 步长 0.5 valid_ratings = ratings[(ratings['rating'] >= 0.5) & (ratings['rating'] <= 5.0)] print('有效评分数量:', len(valid_ratings)) # 统计每个用户的评分数量，后续做用户分群分析 user_count = valid_ratings.groupby('userId').size() print(f'用户总数: {len(user_count)}, 平均评分条数: {user_count.mean():.1f}')

清洗之后要做的关键操作是把评分表转成用户-物品矩阵。这一步看似简单，但它决定了后面所有计算的效率。直接用pivot_table或者pivot就能得到 DataFrame 格式的矩阵，行是用户、列是电影，缺失位置是 NaN。但要注意：这个 DataFrame 里大部分位置都是空值，直接转成 numpy 数组会占用巨大内存。我一般会保留 DataFrame 形态用于查看和调试，真正做相似度计算时转换成 scipy 的稀疏矩阵，只存非零元素，内存占用瞬间从 GB 级降到 MB 级。

3.2 按时间戳切分训练集与测试集

切分数据的方式直接影响评估结果的可信度。如果随机切分，测试集里会出现“用户已经看过且系统能看到评分”的电影，相当于泄漏了未来信息，评估分数虚高。正确做法是按时间戳切分：每个用户的历史评分记录按时间排序，前 80% 进训练集，后 20% 进测试集。这样模拟的是“用过去预测未来”的真实推荐场景，答辩时也能清楚讲出评估设计的合理性。

# 每个用户按时间戳排序，取前 80% 作为训练集 ratings_sorted = ratings.sort_values(['userId', 'timestamp']) train_list = [] test_list = [] for user_id, group in ratings_sorted.groupby('userId'): split_idx = int(len(group) * 0.8) train_list.append(group.iloc[:split_idx]) test_list.append(group.iloc[split_idx:]) train_data = pd.concat(train_list, ignore_index=True) test_data = pd.concat(test_list, ignore_index=True) print(f'训练集规模: {len(train_data)}, 测试集规模: {len(test_data)}')

切分时有两个点要注意。第一，如果某些用户评分特别少（比如只有 1 条），80% 切分后训练集为空，这个用户的测试数据也要丢弃，否则评估时系统对该用户一无所知，命中率必然为 0，拖低整体指标。我通常在切分前先过滤掉评分条数少于 5 条的用户。第二，切分完成后要再检查一次训练集和测试集是否有完全相同的 (userId, movieId) 对，理论上不会出现，但一旦出现就说明排序或切分逻辑有 bug，指标会失真。

3.3 数据稀疏性与最小覆盖处理

MovieLens 1M 数据集的稀疏度大约是 4%，意思是用户-物品矩阵里只有不到 5% 的位置是非零评分。这是协同过滤的先天问题，也是论文里绕不开的一个讨论点。稀疏度过高时，很多用户之间没有共同评分过的电影，相似度算出来为 0，推荐效果就很差。

处理策略常见的有三种。第一种是过滤掉评分数量过少的电影，比如把只有个位数评分的冷门电影从物品集合里剔除，减少噪声；第二种是调整相似度计算方式，把“用户对电影的平均打分偏移”作为向量值，这样即使用户打分习惯不同，也能通过正负偏移比对喜好方向；第三种是引入物品的类目属性做填充，比如两部电影同属“科幻”类型，即使没有共同评分用户，也给予一个基础相似度。

要明确一点：稀疏度低是数据集本身的特性，不要指望预处理彻底解决。论文里把稀疏度分析、处理策略和效果对比写清楚，比硬调参数得到一点点分数提升更有价值。我自己的习惯是保留原始稀疏度与过滤后的两组数据，分别跑一轮实验对比，这个对比本身就是很好的论文素材。

4. 把算法变成系统：目录组织与 Web 端展示

4.1 系统目录结构与模块边界

毕设评分很看重“系统完整性”，算法代码写得再好，只有一个 .py 文件跑出推荐列表，在答辩时很难展示。完整的电影推荐系统至少要有四个模块：数据处理层、算法层、接口层、展示层。我常用的目录结构是：

movie_recommend/ ├── data/ # 原始数据集与预处理脚本 │ ├── raw/ │ └── processed/ ├── model/ # 算法模块 │ ├── similarity.py # 相似度计算 │ ├── recommend.py # 推荐逻辑 │ └── evaluate.py # 离线评估 ├── web/ # Web 服务层 │ ├── app.py # Flask 主应用 │ ├── templates/ # 前端模板 │ └── static/ # 静态资源 └── test/ # 单元测试与结果输出

这个结构的好处是每一层职责单一，论文里画系统架构图时可以按这个层级清晰描述，答辩问“模块之间怎么解耦的”也能直接回答。我在实际操作中会把算法层的所有代码设计成“不依赖 Web 框架”的纯 Python 函数，这样离线评估时直接调用算法层，启动 Web 时也调用同样的函数，不会出现“论文里跑的结果和系统展示的结果不一致”的尴尬情况。

4.2 离线推荐流程与缓存设计

系统的核心流程是：启动时加载训练好的相似度矩阵，收到推荐请求后，根据用户 ID 实时计算候选电影排序，返回 Top-N 列表。这里不需要在每次请求时重新计算相似度，相似度矩阵是一次性离线算好的，启动时加载到内存即可。但需要注意：不同用户看到的推荐结果不能每次都现算，应该做缓存，把每个用户的推荐结果存成 JSON 文件或者键值对，设置过期时间，只有用户产生了新的评分行为才让缓存失效。

import json import os CACHE_DIR = 'cache/' def get_recommendation_with_cache(user_id, top_n=10): cache_file = os.path.join(CACHE_DIR, f'user_{user_id}.json') # 命中缓存则直接返回 if os.path.exists(cache_file): with open(cache_file, 'r', encoding='utf-8') as f: cached = json.load(f) if cached['expire_at'] > time.time(): return cached['movie_ids'] # 未命中缓存，重新计算 movie_ids = recommend_itemcf(user_id, train_data, item_sim_matrix, top_n) payload = { 'movie_ids': movie_ids, 'expire_at': time.time() + 24 * 3600, # 24 小时后过期 } with open(cache_file, 'w', encoding='utf-8') as f: json.dump(payload, f, ensure_ascii=False) return movie_ids

这段缓存逻辑要写进系统里，其中一个原因是答辩时老师很可能问“在线推荐为什么快”。答案是：相似度矩阵离线算、推荐结果带缓存、冷启动用户走单独的兜底策略。这三点构成了完整的性能叙事。要注意缓存失效的处理：如果用户刚刚提交了一条新的评分，推荐结果必须马上重新计算，缓存时间设计得过长会导致用户感觉推荐不更新，过短则失去缓存意义。按 24 小时过期并配合评分后手动清缓存是比较稳的方案。

4.3 Web 交互层的推荐逻辑接入

Web 框架选择上，Flask 就够用。如果选 Django，模型管理功能确实丰富，但对一个演示型毕设来说架构偏重，答辩时反而容易暴露出“配置文件里很多都不懂”的短板。Flask 的学习曲线低，代码结构一目了然。前端不需要做得多花哨，用模板渲染出电影海报、标题、类型和推荐理由即可。推荐理由可以简单写成“因为你看过《XXX》”，这让系统显得更智能，也是答辩演示时的加分细节。

from flask import Flask, render_template, request import pandas as pd app = Flask(__name__) # 加载预处理好的电影信息和相似度数据 movies_meta = pd.read_csv('data/processed/movies_cleaned.csv') movie_id_to_title = dict(zip(movies_meta['movieId'], movies_meta['title'])) @app.route('/') def index(): return render_template('index.html') @app.route('/recommend') def recommend(): user_id = int(request.args.get('user_id', 1)) rec_ids = get_recommendation_with_cache(user_id, top_n=10) rec_detail = [] for movie_id in rec_ids: title = movie_id_to_title.get(movie_id, '未知电影') rec_detail.append((title, movie_id)) return render_template('recommend.html', user_id=user_id, rec_list=rec_detail) if __name__ == '__main__': app.run(debug=False, port=5000)

接入时有几个细节容易出错。第一，模板里循环渲染时要注意 movieId 和 title 的键名对齐，如果 movies_meta 里的列名和字典构造时不一致，页面会显示中文乱码或者空值。第二，推荐接口必须处理“未知用户 ID”的情况，不能让系统直接报 500 错误，我通常的做法是新用户走热门电影兜底（用全站平均评分最高的电影）。第三，Flask 的 debug 模式在展示时一定要关掉，否则错误信息会直接暴露到前端页面上，显得很不专业。

5. 避坑指南：推荐系统毕业设计的 6 个常见问题

5.1 相似度计算时间过长，等了 10 分钟还没出结果

现象：训练集上跑相似度计算，日志一直停在第一个用户，任务迟迟不结束。

原因：使用双层循环对每个用户逐一和全量用户计算相似度，复杂度是 O(n²)，n 是用户数量。MovieLens 1M 有 6000 多个用户，纯 Python 双层循环就是几千万次操作，耗时自然不可接受。

解决：用numpy向量化替代循环，把用户评分矩阵一次性读入内存，通过np.dot批量计算相似度。如果内存放不下，改用sklearn.metrics.pairwise.cosine_similarity，它对稀疏矩阵有专门优化。我在实测中，6000 用户的矩阵用向量化计算只需要秒级，循环写法要跑到半小时以上。

5.2 冷启动用户推荐结果为空

现象：新注册用户没有评分记录，调用推荐接口返回空列表，页面上什么都显示不出来。

原因：协同过滤天然依赖用户历史行为，冷启动是算法本身的结构性短板，不是代码 bug。

解决：做两层兜底。第一层，用户没有评分时，返回全站评分人数最多的热门电影 Top-N；第二层，用户只有 1-3 条评分时，用“类型匹配”兜底，取用户评分最高电影的类型，在同类电影里找评分高的推荐。这两层逻辑要写进同一套推荐接口里，前端感知不到差别。

5.3 评分数据切分后测试集大量用户没有可推荐项

现象：离线评估时，召回率显示为 0，日志发现测试集里几乎没有用户能有推荐结果。

原因：切分时没有过滤掉评分过少的用户，导致大量用户训练集只包含 1-2 条评分，推荐算法找不到足够的相似物品。

解决：切分前统一过滤，评分数量低于 5 条的用户直接从训练集和测试集一起移除。这个阈值可以作为一个超参数在论文里讨论，并给出不同阈值下的评估指标对比。

5.4 物品相似度全部为 0，推荐列表是空的

现象：相似度矩阵非零元素极少，输出结果基本等于随机推荐。

原因：矩阵有大量 NaN 位置，归一化前没有把空值填 0；或者评分的 pandas Series 和 numpy 数组在类型转换时不匹配，导致 dot 计算时隐式全部变零。

解决：构造矩阵时显式检查数据类型和空值比例。转换 numpy 数组前执行matrix = matrix.fillna(0).values，转换完后打印非零元素数量，如果少于预期就回头检查数据处理链路。

5.5 同样的代码在 Windows 上运行报编码错误

现象：读入 ratings.csv 时文件路径报错，或者模板渲染时中文变成乱码。

原因：Windows 默认编码是 GBK，而数据集和代码里应显式指定 UTF-8，两者不匹配。

解决：所有open()和read_csv()调用都显式加上encoding='utf-8'；代码文件首行加# -*- coding: utf-8 -*-；写缓存 JSON 文件时同样指定编码。这个坑不深，但在 Windows 本机上调试时经常遇到，建议一开始就统一规范。

6. 从“能跑”到“高分”：论文里怎么把结果讲成贡献

这个项目做完系统只是第一步，论文写作决定了它能拿到什么档次的分数。我见过很多同学代码写得不错，但论文写成了“开发报告”，通篇讲系统功能和界面截图，算法部分只贴公式，评估环节草草带过，最后分数都不理想。要想拿高分，论文的核心不是“做了一个系统”，而是“围绕协同过滤的数据稀疏问题做了什么、效果如何”。

论文结构上，我建议把第三章留给你对算法做出的改进。比如在标准 ItemCF 基础上加了评分时间衰减，让更近期的评分对相似度计算有更高权重；或者针对冷启动问题设计了基于电影类型标签的混合推荐策略。这些改进不一定复杂，但必须要有对照组实验支撑。论文里放一张表格，对比“基础 ItemCF”和“你的改进方案”在精确率、召回率、覆盖率上的数值差异，这一张表的说服力胜过十页描述。

实验设计上还有一个习惯值得养成：调一次参数就记录一次结果。相似度计算里的近邻数 K、推荐列表长度 N、时间衰减系数，每个参数选 3 到 5 个不同值跑一遍，并把结果整理成折线图。这不仅仅是论文素材积累，还能帮你真正理解参数如何影响系统行为。我从自己的经历看，最怕的就是参数调好了但忘了当初用的什么值，后期写论文时只能重跑，浪费时间不说，还可能复现不出原来的结果。

答辩时你的底气就来自这些图表和对参数的熟悉程度。老师问“你这个推荐为什么效果好”，你能直接回答出“因为我在相似度计算时加了时间衰减，衰减系数取了 0.9，能在召回率掉 0.5% 的代价下提升精确率 2.1%”，这个答案远远好过“我参考了很多文献然后实现的”。建议你在写论文前先动手把实验记录本建起来，调参时顺手把数值和效果写进去，后续写论文会发现顺畅很多。希望这篇笔记能帮你用最短路径完成一个经得起推敲的推荐系统毕业设计。

本文还有配套的精品资源，点击获取