电影推荐系统与票房预测：机器学习毕业设计全流程实战

简介：这是一套面向计算机专业本科生的高完成度毕业设计资源，融合电影推荐与票房预测两大典型机器学习应用场景，专为毕设、课程设计及项目实战练习者打造。资源包含完整可运行的Python源码（16个.py文件）、结构化数据集（16个.csv，含TMDB 5000电影与演职员信息）、多维度分析报告（PDF+Markdown）及可视化结果图（23个.png），涵盖协同过滤（KNN/SVD）、内容推荐、关键词匹配、集成推荐及票房回归预测等核心算法实现，目录模块清晰，支持分步调试与效果对比。压缩包共59个文件，大小30.94MB，已获导师指导并以98分高分通过评审。目前已有273人下载学习，提供从数据清洗、特征工程、模型训练到结果评估的全流程代码与文档支撑，特别适合需快速构建机器学习项目闭环、理解工业级推荐系统架构的学习者。

1. 毕设选题定下来之前，我先想清楚了这四件事

2024年三四月份，我选毕设题目的时候，在选题系统里刷到“电影推荐系统”“票房预测”这类词已经半年了。说实话，这题不是新鲜题，但每年都有人做，每年也都有老师收。我的原则只有一个：不选太冷门、没数据的题，也不选太热门、同质化到看不出个人工作的题。电影推荐+票房预测，两个任务都挂在“机器学习应用”这个大伞下面，数据源公开、模型可比较、效果能可视化，天然适合做毕设。

但这个项目真正值钱的地方，不在于“我用了什么算法”，而在于你能否把两个系统讲成一个闭环：推荐系统解决的是“观众看什么”的问题，票房预测解决的是“片方怎么排片、怎么定宣发策略”的问题。做的时候我不止一次觉得，这两件事其实是同一个核心——对人观影行为的理解。把这个点讲透，报告才有灵魂，答辩才有话可讲。

先说适合谁。这篇文章是写给三类人看的：第一类是正在选毕设题目、想找机器学习教育项目的在校生；第二类是自学者，手里有很多Python和机器学习基础，但没想过怎么把它们串成一个完整落地项目；第三类是已经开始写代码、但卡在数据清洗、推荐评估或者票房特征工程这种细节里的人。我会把从数据获取、算法选型、系统实现到报告撰写的完整链路都拆开讲，尽量把每一步的“为什么”也说清楚。

顺带交代一下我的技术栈，方便你对号入座：编程语言Python，核心库pandas、numpy、scikit-learn，推荐部分用了surprise工具包，票房预测部分对比了线性回归、随机森林和XGBoost，展示层用Flask加一个轻量前端。整体代码量不大，核心源码大概三千行，关键都在算法的正确性评估和数据处理上。

2. 数据从哪来、怎么清洗到能直接喂给模型

2.1 数据集选择：比算法更影响成绩的决策

先说推荐系统的数据。国内外的公开数据集里，最常被推荐的是MovieLens系列，它有100K、1M、10M、25M几个版本，我最后选了1M版本。理由很朴素：100K太少，模型刚跑出一个稳定结果就过拟合了；10M和25M对毕业设计来说又太大，本机跑特征工程和模型训练要等很久，优化起来也麻烦。1M是一个“刚好能讲清楚故事”的规模——它包含约3900部电影、6040个用户、100万条评分记录，评分是1到5的整数，同时附带用户属性表（年龄、性别、职业、邮编）和电影属性表（标题、类型、上映年份）。

但这里有个我在报告里特别强调的坑：MovieLens里的用户历史是1990年代末到2000年代初的，数据分布和今天差别很大，如果直接用它的结果去说明“推荐系统在今天的工业界表现如何”，老师一定会追问。我的处理方法是用它做模型实验，另外补充了一个从公开电影网站上能拿到的近期热门电影列表，做了一个简单的冷启动模拟，证明系统在新物品上线时也能给出合理推荐。这一部分内容不复杂，但能体现你对数据时效性的思考，答辩加分项。

票房预测的数据则完全不同。这类数据没有统一的公开标准集，我的做法是：自己构建了一个包含近500部电影的训练集，每条样本包含电影类型、导演、主要演员的过往票房均值、上映档期（春节档、暑期档、国庆档、平日档）、首周排片场次、宣发热度指数（以物料播放量和社交媒体讨论量加权合成）、影院数，目标变量是最终总票房。收集渠道主要是公开的票房统计平台和影片信息页，数据量不大，但字段设计比量更重要。

2.2 清洗流程：细节决定模型能不能收敛

不管你用多好的算法，数据没洗干净就等于白做。我的清洗流水线分四步走：

第一步是重复值处理。MovieLens的userId和movieId组合理论上唯一，但我还是用drop_duplicates(subset=['userId', 'movieId'])做了防御性去重，防止后面join出笛卡尔积。

第二步是缺失值处理。用户表里职业字段存在少量缺失，我对缺失用户做了整行保留但将职业统一编码为0的处理，而不是直接删除——推荐系统里用户信息本来就稀疏，删行会让评估失去真实感。电影类型字段拆成多列并做one-hot编码，没有类型标记的冷门影片全部归入“未知”类型列。

第三步是时间字段的解析。这个细节很多人忽略。MovieLens的评分时间戳要转成北京时间，然后构造出“用户对该电影的评分日期与该电影上映年份的时间差”“用户近30天活跃评分次数”这类时间特征。我在报告里专门做了分析：用户对老片子的评分往往更严厉，对近年影片更宽松，这个偏差会影响协同过滤的评分归一化处理。所以我在清洗阶段就为每条评分构造了一个“评分年份偏差”字段，后续在协同过滤计算相似度前做了均值中心化。

第四步是票房数据的单位一致化。总票房有的表是万元、有的是亿元，导演历史票房有的是全球票房、有的是内陆票房，我统一换算成亿元并且保留两位精度单位指标，避免后续特征工程出现十倍误差。这一步看起来琐碎，但真的是我实际踩过的坑——最开始跑线性回归R2是0.78，怎么调都上不去，检查数据才发现导演特征列的单位混了两个口径。

2.3 特征工程的几条硬经验

我对推荐系统做了三组特征：

• 用户特征：年龄分箱、职业编码、性别、历史平均评分、历史评分标准差、活跃天数。
• 电影特征：类型one-hot、年份、平均评分、评分人数log变换。
• 交互特征：用户对该类型电影的历史平均评分、用户是否看过续集类影片。

对票房预测做了两组特征：

• 影片内容特征：类型、国别、片长、导演过往平均票房、编剧历史票房分位数。
• 市场特征：档期类型、竞品数量（同档期上映片数）、首周宣传指数、影院排片占比均值。

做特征工程最需要注意的问题是避免“未来信息泄漏”。票房预测里最难防的就是这一点：首周票房和首日票房是很多现成模型的强力特征，但如果你的目标是“上映前预测总票房”，你压根不该把首周数据放进来。我没有用任何上映后的数据，只用上映前可获得的宣传物料数据、排片预期数据、主创历史数据、档期数据。这是我的报告里一个重要决策点，也值得答辩时主动讲出来——老师一听就明白你理解预测任务的本质。

3. 推荐系统：从UserCF到混合推荐的完整落地

3.1 算法选型：为什么我放弃了只做一个协同过滤

推荐系统的核心算法我前后实现了四个版本：基于用户的协同过滤（UserCF）、基于物品的协同过滤（ItemCF）、基于SVD矩阵分解的模型，以及把这些结果做加权融合的混合推荐。做了这么多之后，我负责任地说一句话：单靠任何一个算法，在毕业设计的系统里都会暴露明显短板。

UserCF的逻辑是“相似的人喜欢什么就推什么”，它适合社区性强的场景，但在MovieLens 1M上有一个天然问题：用户之间评分习惯差异很大，有的人全都打4分以上，有的人评分均值只有2.8，直接用原始评分算相似度会被“打分风格”主导。解决方法是评分中心化：用每行用户评分减去该用户均值，算出的是“相对偏好”，再进行余弦相似度计算。这样出来的相似度才有意义。

相似度计算公式我用的是调整余弦相似度（Adjusted Cosine），对评分偏差做惩罚。在surprise工具包里，直接用KNNWithMeans算法就很方便，它本身已经内置了均值中心化逻辑。我本地跑出来的结果是，UserCF在MovieLens 1M上的RMSE约0.94，ItemCF约0.90——这在文献里属于正常范围。ItemCF的优势是稳定、可解释性强，电影之间相似度可以直观展示在界面上，用户容易理解“因为你喜欢《盗梦空间》，所以推荐《星际穿越》”。劣势是覆盖率偏低，热门电影经常被过度推荐，冷门影片永远没有出头机会。

3.2 SVD矩阵分解与冷启动补救

第三个版本是SVD。surprise里的SVD实现很稳定，我调过几组参数，最终在1M数据上用默认的20个隐因子跑出了约0.87的RMSE，比KNN类方法好了不少。矩阵分解的本质是把用户和物品映射到同一个隐语义空间，用隐向量点积预测评分，它抓住了用户和物品之间的深层交互关系。在报告里我画了一张隐因子可视化图，把电影类型在隐空间的分布投影到二维平面，能明显看出科幻片、纪录片、喜剧片各自聚成团，这个图答辩时很加分。

但SVD有个致命问题——冷启动。新用户没有评分记录，新电影没有被评分过，隐向量根本无从学起。这是任何协同过滤类算法的通病。我的补救方案是做内容画像：给没有行为记录的电影，用它的类型、导演、年份构造一个内容向量，计算它和已有电影内容向量的相似度，作为“临时相似物”补位。同时给新用户弹出偏好选择页，让他们先挑5个喜欢的类型或电影，系统用这些初始信号做一轮“伪评分”再进入SVD预测。这个冷启动模块我在代码里专门建了一个cold_start.py，报告里也单独写了小节，属于系统亮点之一。

3.3 混合推荐：不是简单相加，而是带权重的组合

最终系统上线用的不是单一算法，而是混合推荐。我采用的方案是加权融合：在线阶段先判断用户是否有足够的交互记录，有历史记录的用户，最终得分 = 0.45 × SVD预测分 + 0.30 × ItemCF预测分 + 0.25 × UserCF预测分；冷启动用户则直接切换到内容召回模块，不再走协同过滤融合。

权重不是拍脑袋定的。我先跑了网格搜索，在1M数据的5折交叉验证上分别测试几个权重组合的RMSE和NDCG，选出了当前这组。实际测试下来，混合后的RMSE稳定在0.84左右，虽然比单个SVD只提升了一点点，但NDCG（衡量推荐列表排序质量的指标）提升明显，从0.62升到了0.68——这说明排名靠前的推荐更精准了。

这里想多说一句：不要追求算法复杂度，要追求评价指标的完整性。我的报告里不仅写了RMSE，还写了precision@10、recall@10、coverage、novelty四类指标。老师看到你理解“一个推荐系统的好坏不止看误差”这个观念，就已经超出很多同学的认知水平了。

4. 票房预测系统：特征依赖比模型本身更值得抠

4.1 这个任务本质是回归问题，但它的难点在标签分布

票房预测说到底是一个回归问题，输入是影片描述特征，输出是总票房。但实际做的时候，光标签这一个环节就能劝退很多人：票房数值跨度极大，从几十万小成本文艺片到几十亿的商业大片，可能相差三个数量级。如果直接对原始票房做回归，模型会被几个头部大片拉偏，对小成本影片的预测误差惨不忍睹。

我的处理是先把标签做log1p变换——对票房加1取自然对数。这个操作让标签分布从严重右偏变成接近正态，线性模型和树模型都能更好地拟合。预测结束之后再取指数还原成票房金额。这个细节我在报告中写了整整一页，因为它直接影响所有后续结果。

4.2 三个模型对比：线性回归、随机森林与XGBoost

我对比了三个模型，简单说下结论：

从数据上能直观看出，XGBoost在这份数据上的综合表现最好。但我不会简单推荐每个人都去用XGBoost。它的优势在于能自动处理特征交互，比如“春节档+喜剧+大导演”这个组合对票房的拉动是倍增而不是简单加法，这种关系线性回归要手动构造交叉特征才能学到。随机森林在树的数量和深度上更稳健，不容易过拟合，但对连续特征的最优切分点不如XGBoost细腻。

还有一点：我没有在这个项目里使用深度学习模型，比如MLP或DeepFM。原因不是深度学习不好，而是500条票房样本量太小，深度模型很容易在验证集上表演式过拟合。这不是我技术储备不够，而是根据数据规模做出的合理取舍。做毕设最重要的是展现你理解“什么场景下该用什么方法”，而不是一味堆高级模型。

4.3 特征重要性的解读比模型本身重要

XGBoost训练完直接输出特征重要性，我的top5特征是这样的：

1. 首周宣传热度指数（影响权重约32%）
2. 导演过往作品票房均值（约21%）
3. 档期类型（约16%）
4. 主创演员历史平均票房（约12%）
5. 同档期竞品数量（约9%）

这个排序和行业经验是吻合的：电影是典型的注意力经济产品，宣发力度直接决定首周热度，首周热度又决定了后续排片和口碑扩散的基数。导演和演员的历史成绩反映观众信任度，档期决定市场容量上限。

这个解读让我在答辩时有了一个非常强的叙事逻辑：预测模型不只是算一个数字，它还能拆解出哪些因素在影响票房，从而为片方提供可操作的策略建议。比如某部春节档喜剧片，模型预测票房不高，原因不是类型和导演弱，而是同档期竞品数量太多。这种归因能力是纯做技术演示的同学讲不出来的。

5. 系统串联、界面交互与报告撰写的破绽规避

5.1 整体架构：两个系统一个后端

我的项目目录结构很简单，按照功能分层：

movie_project/ ├── data/ # 原始数据和清洗脚本 ├── models/ # 训练好的模型文件 ├── recommender/ # 推荐系统核心 │ ├── user_cf.py │ ├── item_cf.py │ ├── svd_model.py │ └── hybrid.py ├── box_office/ # 票房预测系统 │ ├── features.py │ ├── train.py │ └── predict.py ├── web/ │ ├── app.py # Flask后端 │ └── templates/ # HTML+JS前端页面 └── report/ # 最终PDF和答辩PPT素材

Flask后端提供两个核心接口：/api/recommend?user_id=123返回推荐电影列表，/api/predict?movie_id=456返回票房预测结果和特征归因。前端页面左边是推荐区，用户输入ID或选择冷启动偏好后展示Top10推荐；右边是票房预测区，输入影片信息或选择数据库预置影片后显示预测总票房和置信区间。整个界面没有任何花哨动画，干净、能看、每一步都有结果反馈就够了。

我提醒你一点：做系统交互时，不要为了展示前端能力而堆UI组件。毕业设计的评分核心永远在算法本身，界面只要做到能完整展示算法结果即可。我见过太多同学把时间花在选前端框架上，结果算法乱成一团，最后答辩被老师追问两句就答不上来。

5.2 报告怎么写才能让老师觉得“有工作量”

报告PDF最后有九十多页，但我真正写的核心内容只有五个部分：

摘要和绪论里，我一句话讲清楚项目目标：“基于用户行为数据构建电影推荐系统，基于影片前验信息构建票房预测系统，并为两个系统设计统一的数据清洗与特征工程流程。”

第二章是相关工作，这部分不能被忽视。我调研了近五年的推荐系统综述文献，还对照了多种模型的paper，把“协同过滤的稀疏性问题”“矩阵分解的隐语义解释”“内容特征在冷启动中的作用”这些概念都写了。不要小看这部分，它占的篇幅不多，但能让老师一眼看出你阅读过资料，而非只看了博客。

第三章是数据获取与处理，我完整复现了第2.2节讲到的清洗流水线，每个环节都附了处理前后的数据对比表和可视化图。比如清洗前评分分布是左偏的、清洗后接近正态；缺失值处理前后样本数变化；单位统一前后导演特征数值分布。

第四章是算法设计与实验，这是报告的核心。每个算法都按“思想来源、数学表达、代码实现、实验结果、不足分析”这个格式来写。这里我要强调一个很多人会忽略的点——不要只报最好的结果，把失败实验也写进去。我在报告里专门留了一节讲“为何纯线性回归效果差”“为何直接对原始票房做回归不收敛”，这两段内容成为答辩老师追问我时最能体现思考深度的部分。

第五章是总结和展望，不要写空话。我的写法是：“当前系统在离线评估上达到RMSE 0.84，但对近两年新上映电影的推荐精度明显下降，下一步可引入更多时效性特征、考虑图神经网络建模用户社交关系。”这就是一句实在话，比写十句“随着人工智能的发展”都管用。

5.3 答辩前我必须确认的十个问题

我把答辩前一晚过了一遍的十个问题列出来，这些都是指导老师或者评委最可能问的：

1. 为什么不用深度学习？——数据量太小，传统方法够用且可解释。
2. 你的推荐结果如何评估？——RMSE看误差，precision/recall看命中率，coverage看覆盖度。
3. 冷启动怎么解决？——内容召回+用户偏好初始化。
4. 票房预测的标签为什么做log变换？——右偏分布会导致拟合偏差。
5. 你的特征会不会有未来信息？——已排除所有上映后数据。
6. 用户矩阵稀疏怎么办？——SVD和中心化可以缓解，但不能根治。
7. 为什么用RMSE不用MAE？——RMSE对大误差更敏感，适合评分预测场景。
8. 推荐和票房预测两个系统有什么关系？——都围绕用户观影决策，一个服务观众，一个服务片方。
9. 你的代码用了哪些第三方库？——pandas、numpy、scikit-learn、surprise、xgboost、Flask。
10. 如果数据规模扩大100倍，你的系统哪些部分要改？——矩阵分解要换成分布式训练，协同过滤要换近似最近邻检索。

这十个问题里，第九和第十个是最能区分别人是否真的做过项目的。临时抱佛脚看不懂代码的同学，在这两个问题上肯定露馅。

6. 实操中的坑：损失值不降、推荐冷启动、票房过拟合

6.1 训练SVD时损失值不降的排查链路

我训练SVD时遇到过一次很头疼的情况：前5轮迭代RMSE从0.95降到0.88，但之后30轮始终卡在0.88附近不动了。当时的我第一反应是学习率太大或太小，调了半天也没用。后来仔细排查发现，问题出在数据加载环节——我把MovieLens的评分数据读取时没有把评分列从字符串转成float，导致surprise内部把所有评分当成分类标签处理，学习目标根本就不是评分回归。

排查过程复盘下来，正确的链路是：先确认数据schema是否正确，再检查训练集和验证集的标签分布是否一致，最后才动模型参数。如果一上来就调参，只会浪费几个小时还找不出问题。我后来规范化了数据读取的检查：每次加载完数据先打印df.dtypes和df['rating'].describe()，确保评分是float且范围正常再进入模型。

6.2 票房预测过拟合的元凶是“导演名气”

票房预测随机森林版本一开始的R2在训练集上0.95，验证集上只有0.68，典型的过拟合。我把特征逐一拆开来做单特征验证，才发现问题出在导演历史票房特征上——有几位大导演（比如张艺谋、陈凯歌）历史票房极高，树模型抓到“只要导演是这几位，预测值就拉满”的路径，但对中小导演完全不泛化。

我的解决方法是把这个特征从连续值换成离散分箱：按导演历史票房分成五个等级（S/A/B/C/D），同时加入该导演历史作品数量做辅助特征。这样一来，模型不再单纯依赖导演绝对值，而是综合导演等级和作品量做判断，验证集R2从0.68回升到了0.79。类似的分箱处理还用在演员特征上，但演员特征维度更稀疏，我用了经验贝叶斯收缩——演员作品少于3部时，把历史均值向全体均值靠拢。

6.3 协同过滤里的“热门偏差”和覆盖率下降

在推荐系统评估阶段，我注意到一个现象：ItemCF带来的结果虽然RMSE不错，但推荐列表里出现频次最高的永远是《肖申克的救赎》《教父》《阿甘正传》这几部热门片，覆盖率指标惨不忍睹。这意味着系统对长尾电影几乎是失明的。

解决这个问题的思路是引入“探索因子”：在混合推荐阶段，以5%的概率从用户历史偏好相似类型但热度较低的电影里采样补充进推荐列表。这个操作看起来简单，但它让覆盖率从32%提升到了47%，同时RMSE只增加了0.01。这个“用一点点精度换大幅度多样性”的策略，我在报告里做了专项对比，答辩时老师明确表示了认可。

6.4 写代码时的几个防御性习惯

最后分享几个我实际坚持下来的代码习惯，虽然琐碎但对保住成绩很有帮助：

• 所有模型训练之前先固定随机种子np.random.seed(42)，否则每次结果都不同，你没法判断改动是有效的还是运气。
• 模型文件用时间戳命名：svd_20240721.pkl，避免覆盖旧版导致实验结果无法复现。
• 每次跑完实验把指标结果自动追加到一份CSV里，表格列是：算法、参数、RMSE、precision@10、coverage、实验时间。写报告时这个CSV就是你的素材库。
• 所有清洗函数都写成纯函数，输入DataFrame输出DataFrame，不修改全局变量。这样后面做A/B对比时能清晰地切换数据变换方式。

按我个人的体会，这个项目做完，你收获最大的其实不是那些模型和指标，而是完整地把“一个问题从数据到算法再到产品”走了一遍。很多时候你从零写一个系统时，不知道会在哪里翻车；但在这个项目里因为题目足够经典、数据足够干净，你翻车的每个坑都是别人踩过的，也都有迹可循。这套经验之后你换任何数据集、换任何方向，基本思考路径都是一样的。如果时间允许，我建议你在提交前再自己试着改一次特征工程，比如把用户年龄特征从离散分箱改成连续值，观察推荐效果变化——这种小实验会让你对整个系统的理解更扎实。

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