每年到这个时间点，总有人问我同一个问题：机器学习方向的毕业设计到底选什么题才稳妥。问我的人里有真想做东西的，也有只想快点交差的，但我的回答基本一致——推荐系统这个方向，属于“看着不难、做着有事干、写完能讲清、答辩不容易翻车”的典型选择。尤其是把Python、Django、协同过滤算法、爬虫这几个关键词串成一条链路之后，既有数据采集的工程活，又有算法设计的理论活，还有系统开发的实现活，一个题目就把整个项目流程全练了一遍。
不过“好写”不等于“好糊弄”。我见过不少同学一上来就找现成源码，改个名字就交，等到答辩被问“你这里为什么用余弦相似度”就当场卡住。今天这篇就当是给准备做类似题目的同学写的一份经验贴，从题目拆解、数据准备、算法实现、工程落地方案到论文答辩，完整走一遍。我结合自己做过的项目和一些带毕业设计的经验，把那些最容易踩的坑和最容易忽略的细节全部摊开讲。
1. 为什么电影推荐系统是毕业设计的“稳妥之选”，但又不那么好对付
1.1 一个题目覆盖完整技术链路
先说说选题这件事。很多学校的毕设题目都是老师给方向，学生自己具体化，而“机器学习毕业设计”这个大类下，真正适合本科阶段独立完成的方向其实屈指可数。图像识别要调模型训数据，自然语言处理要面对算力和语料的双重压力，强化学习则是题目听着高级但两个月根本跑不出像样效果。相比之下，推荐系统需要的技术栈恰好是一个计算机相关专业学生在校期间都会碰到的：Python写算法、关系型数据库存数据、Web框架做前端展示、爬虫做数据采集。
但链路的完整反而是双刃剑。数据怎么合法合规地拿下来，算法算出来之后怎么解释给用户听，系统跑起来之后推荐结果到底是“看着合理”还是有“实际效果”，这些问题都会被答辩老师逐一追问。很多人拿到一个推荐系统源码就以为自己毕业设计完成了一大半，这是最大的误解——源码只是骨架，真正要你写清楚的是为什么这样设计、每个模块之间怎么协作、算法选型背后有什么依据。
1.2 豆瓣电影作为数据源的特殊优势
选豆瓣电影数据集而不自己造数据，背后是有讲究的。第一，电影领域用户认知门槛低，不管答辩老师是什么方向的，他都看过电影，都能理解“给你推荐你没看过但可能喜欢的电影”是什么意思。第二，电影数据的结构化程度高——导演、演员、类型、年份、评分、评论数、短评内容，每一类字段都对应一种可挖掘的特征。第三，豆瓣电影本身带有非常成熟的评分体系，用户打1到5分的行为本身就是天然的协同过滤训练信号，不需要你做过多信号转换。
第三点尤其重要。协同过滤算法最基础的输入就是“用户-物品评分矩阵”，而豆瓣的星级评分机制天然就是稠密度尚可的矩阵。相比之下，如果你选电商数据，用户“购买”和“喜欢”之间差着十万八千里，还得自己设计隐式反馈的处理策略，工作量立刻翻倍。这也是为什么我几乎每次都建议想选推荐系统题目的同学拿电影作为切入领域——数据的先天质量决定了算法的后天工作量。
当然，豆瓣数据也有它的脾气：短评文本乱、标点符号混用、同一个导演的译名在不同电影里不一致、Top250榜单和全量电影之间热度偏差巨大。这些坑我在后面爬虫和清洗的部分会详细说，它们看似琐碎，但每一个都可能在你跑数据的时候浪费你一整天。
2. 双协同过滤到底是什么：两种算法的底层逻辑和融合方式
2.1 “推荐系统中协同过滤”的核心假设
协同过滤并不是一个高深的概念。它的底层假设就两句话：口味相近的人会对同一部电影给出相近的评价；看过相似电影的人在下一个电影的选择上也会有重叠。前者对应User-based协同过滤，后者对应Item-based协同过滤。
用生活场景来理解：你朋友说一部片子好看，你大概率会去看，因为你觉得你们审美相似——这是UserCF。你在视频网站看完一部科幻片，网站下方出现“喜欢这部电影的人还喜欢这些”，你就顺着点进去了——这是ItemCF。
但把它们落到代码里，事情就变得不那么浪漫了。你需要一套数学工具来量化“相似”和“相近”，需要一套预测机制把“相似性”变成一个“可推荐程度”的分数，还需要一套工程机制让这套计算在用户点击页面的那一刻来得及响应。
2.2 相似度计算的常见公式与适用边界
协同过滤最核心的步骤是计算相似度。我见过很多同学直接抄代码，把余弦相似度、皮尔逊相关系数、杰卡德相似系数一股脑全放上去，但问他为什么选这个就说不出来。这里我展开讲清楚。
余弦相似度衡量的是两个向量在方向上的接近程度，公式为：
cos(u, v) = Σ(u_i * v_i) / ( sqrt(Σu_i^2) * sqrt(Σv_i^2) )它适合“评分尺度一致”的场景。比如两个用户都喜欢给高分，那他们评分的绝对数值都会偏高，但余弦相似度关注的是方向，所以不会因此错误地认为两个给三四分的用户比一个给三分一个给五分的用户更相似——它完全忽略了你评分习惯的“慷慨程度”。所以更严谨的做法是使用皮尔逊相关系数，它会先对每个用户减去自己的平均分，再计算相关性：
pearson(u, v) = Σ((r_ui - r̄_u) * (r_vi - r̄_v)) / ( sqrt(Σ(r_ui - r̄_u)^2) * sqrt(Σ(r_vi - r̄_v)^2) )这样处理之后，一个习惯打4分的人和一个习惯打2分的人，只要他们的“相对偏好”一致，相似度就会很高。实际项目中我推荐先做用户评分的均值中心化，再算余弦相似度，这样既保留余弦的效率，又解决了尺度偏移问题，实现上也很简单——先让矩阵的每一行减去该行的均值即可。
杰卡德相似系数主要用于只看“是否评分过”不考虑评分高低的情况，公式是交集除以并集。它适合处理隐式反馈，但在豆瓣这种有明确分数的场景下信息利用率不足，所以一般作为辅助指标。
2.3 评分预测公式：从“相似”到“推荐”的关键一跳
有了相似度，还不能直接说“推荐了”。你需要把相似用户或相似物品的评分，加权成一个预测评分。UserCF的经典预测公式如下：
pred(u, i) = r̄_u + Σ( sim(u, v) * (r_vi - r̄_v) ) / Σ|sim(u, v)|注意右边是邻居用户v对物品i的评分r_vi先减去v自己的平均分r̄_v，再按相似度加权求和，最后在左侧加回u自己的平均分r̄_u。这种“均值中心化”的处理，就是为了应对不同用户打分尺度不同的问题——有人手松有人手紧，不中心化的话预测值会系统性偏移。
ItemCF的预测公式思路类似，写出来是：
pred(u, i) = Σ( sim(i, j) * r_uj ) / Σ|sim(i, j)|其中j是用户u已经评分过的物品，sim(i, j)是物品i和物品j的相似度。也就是说，你要预测用户对电影i的评分，就看用户以前评过的每一部电影j和电影i有多像，再拿j的评分按相似度加权平均。
2.4 “双协同”的价值：加权融合还是级联过滤
现在关键问题来了：为什么“双协同过滤”比单纯用其中一种更好？
答案是它们在实践中的表现场景不同。ItemCF在物品数量相对稳定、用户行为足够多的场景下通常更稳，因为它更像“物以类聚”，物品间的相似度相对用户间的相似度更不容易随着时间发生剧烈变化。但ItemCF有一个天然盲区：当用户历史行为非常少时，基于他仅有的几次评分去寻找相似物品，几乎找不到任何有效邻居。UserCF恰恰能在用户历史行为少但用户群体足够大时，通过找到“和他口味接近的老用户”来弥补冷启动问题。
所以“双协同”并不是把两个算法结果摆在一起显得厉害，而是让两者互补，避免在数据稀疏、冷启动等特定场景下算法失效。我做项目时实际采用了两级策略：
- 候选召回阶段：用UserCF从当前用户的近邻用户行为中召回一个候选电影池，比如取Top 100。这个阶段的目标不是把顺序排得多么精细，而是把“可能感兴趣的物品”尽量都捞进来，避免遗漏。
- 精排打分阶段：用ItemCF对候选池里的每部电影进行精细预测评分，按分数排序输出Top N。
这种“先召回后精排”的思路在业界工业系统里也是主流玩法，放到毕业设计论文里，既能让答辩老师看到你有工程思维，又能把职责边界写得很清楚。当然也有人用权重融合公式final_score = α * UserCF_score + (1 - α) * ItemCF_score直接算一个总分，这种方案实现更简单但解释力弱一些——你在论文里很难说清楚α取0.6而不是0.5的根据是什么。所以我更推荐级联式，理由在答辩时也更站得住脚。
3. 数据从哪来：豆瓣电影爬虫的设计、反爬应对与清洗细节
3.1 爬什么：字段设计决定算法能跑多远
爬虫的任务不是“把网页内容存下来”，而是“把你以后需要的东西一次性拿全”。我在搭建这套系统时，定义了三层数据：
第一层是电影基础信息：电影ID、片名、年份、导演、编剧、主要演员、类型、片长、评分、评价人数。这是推荐系统的“物品侧”特征，也是后续做ItemCF时计算物品相似度所依赖的基础。注意不要把ID留在网页页面上——所有内部关联都应该用电影ID而不是电影名，因为不同页面里同一个电影的中文译名可能出现细微差异，用名字做主键会在关联时吃大亏。
第二层是用户评分数据：模拟用户、评分值、评论内容。真实场景中，豆瓣的用户评分数据无法通过公开页面完整爬取，所以这里需要做一个实用的取舍——对于毕业设计来说，常见的做法是爬取公开的短评内容，再基于短评内容模拟生成一组“虚拟用户”和评分记录。严格来说这不是真实用户数据，但作为算法演示和系统验证完全够用。如果你想在论文里写得更规范，还可以说“本研究在公开短评数据基础上构造了评分数据集”，这个表述是准确的。
第三层是榜单与排序信息：比如Top250榜单页面、分类页面的排序结果，这些信息可以用来构造“热门榜”等非个性化推荐模块，解决新用户没有历史行为时的兜底推荐问题。
3.2 请求策略：别让你的爬虫一分钟干完一天的活
豆瓣对爬虫的识别是有成熟机制的，简单说就是：频繁的短时间请求、无规律的User-Agent、固定的访问频率模式，都会被判定为异常。我的建议很简单：
- 使用
requests库，配合随机的User-Agent池进行请求； - 每两个请求之间随机休眠2到4秒；
- 单日请求总量控制在数千次以内；
- 请求失败时不要立刻重试，先检查是否被临时屏蔽；
- 爬取数据仅用于个人学习研究，不对外提供下载服务。
对于本项目只需要几千条电影数据和对应的短评，按上述策略跑几个小时就能完成，根本不需要任何激进手段。如果你发现请求几个页面之后开始出现验证码响应，说明频率还是太快，把休眠时间拉长就好，不要和反爬机制硬刚。
我见过有人为了让爬虫更快，用多线程并发请求豆瓣，结果几百个请求就触发了账号风控，最后不得不换网络环境重新跑，浪费的时间远多于省下的时间。爬虫这里讲究的是“稳定拿完”，不是“速度跑满”。
3.3 解析与清洗：真正拉开工作量差距的地方
网页解析其实没什么神秘的，用BeautifulSoup或者正则表达式就能搞定。真正费时间的是清洗。我说几个我实际遇到的情况：
第一个是译名不一致。同一个导演，有的页面写“克里斯托弗·诺兰”，有的写“Christopher Nolan”，关联导演维度的数据时如果不统一，会出现“同一个导演拍了同一部电影”的错觉。清洗方案是建立中英文译名映射表，或者干脆全部保留英文原名作为关联字段，中文名只做展示。
第二个是评分缺失。新上映或者小众电影经常没有评分，或者评价人数极少只有个位数的评分，这种情况下这些评分对算法的参考价值极低。清洗策略是保留但另做标记，比如引入置信度字段：评价人数低于50的电影，其评分不参与相似度计算，只参与展示。
第三个是类型字段的“多值难拆”。豆瓣电影的类型是“剧情 / 爱情 / 历史”这样用斜杠分隔的复合值，在存数据库时不能把整个字符串当成一个字段就完事，应该拆成一个独立关联表，或者用JSON数组字段存成多值形式，否则后面你想做“基于类型的召回”时无从下手。
清洗完之后，数据要落库。我用的是Django默认配置的SQLite起步，后面数据量达到数万级别时切到MySQL，两者的区别不在算法侧而在访问并发。实际上对于毕业设计这个数据量级，SQLite完全顶得住，别一上来就折腾MySQL的配置，那纯属给自己加戏。
4. Django工程怎么搭：从离线计算到在线推荐的分层设计
4.1 一条推荐的完整路径：用户点开页面时发生了什么
很多同学写Django代码时，习惯把所有逻辑堆在视图函数里：接收请求、查数据库、算相似度、排序、渲染模板，一气呵成。这样写在小系统里没问题，但一旦数据量上来，用户点击页面后要实时算一遍协同过滤，等待时间可能达到几十秒甚至几分钟，这在毕业设计演示时非常尴尬。
我的做法是把推荐分成离线和在线两层。
离线层做的事情有两个。第一，定时重新计算“用户-用户相似度矩阵”和“物品-物品相似度矩阵”；第二，基于当前全量数据，预先把每个用户（或每个物品）的Top N推荐列表算好，存进一张专门的推荐结果表。这样做的次数不需要很频繁，一天一次甚至两天一次都够，因为用户行为数据的增长速度远不会快到需要分钟级更新。
在线层要做的就是查询。用户访问推荐页面时，Django视图函数直接从推荐结果表里查询该用户的Top N电影列表，然后补上电影详细信息返回给前端。整个响应时间快得和普通页面完全一样，因为真正消耗算力的部分早就离线完成了。
4.2 Django各模块的职责划分
我建议的Django项目结构大致是这样：
models.py：定义User、Movie、Rating、Similarity矩阵缓存、Recommendation结果五个核心模型。其中Similarity和Recommendation相当于是“算法结果落地表”，User和Rating是“行为数据源”，Movie是“物品基础信息”。algorithms/下放独立算法模块，比如user_cf.py和item_cf.py。这些模块不依赖Django ORM，入参是标准Python字典或DataFrame，出参也是标准字典。这样做的最大好处是你可以脱离Django环境单独调试算法，写单元测试也方便得多。views.py：只负责HTTP请求的接收和响应，做参数校验、调用算法服务模块、组装返回数据。每个视图函数控制在50行以内，超过说明你把太多职责塞进了一个函数。management/commands/下放自定义命令，比如python manage.py compute_similarity用来触发生成相似度矩阵，python manage.py update_recommendations用来刷新推荐结果表。这样做的好处是你的系统有一个“定期任务”的入口，在答辩时可以演示你手动执行更新命令后，推荐列表随之变化，比直接改数据库有说服力得多。
4.3 推荐结果表的巧妙设计
很多人只在数据表里存用户和评分，推荐结果靠函数临时算。但加入一张推荐结果表，有几个加分项：
- 你可以为同一个用户生成多份推荐列表：基于UserCF的、基于ItemCF的、双协同融合的，以及热门兜底的。这样在系统界面上可以做一个小型对比功能——用户可以选择切换推荐模式，直观看到不同算法给出的结果差异。
- 你可以给每条推荐记录加一个“推荐来源”字段：是UserCF来的，ItemCF来的，融合结果，还是热门兜底。这条信息在论文里写实验分析时非常有价值，因为它能支持你做各类算法的覆盖率和准确率对比。
- 更新推荐时只需增量刷新，不用全表重算。
我在实际开发中还加了一个字段叫explain_text，专门存放“为什么推荐这部电影”的文本。很多推荐系统项目没有解释功能，你做出来之后，推荐页面每部电影下方会显示类似“因为你看过《星际穿越》，所以推荐《盗梦空间》”这样的话。这个亮点在答辩演示时非常容易给评委留下印象——它证明你不只是把推荐跑通了，还考虑了用户体验层面的可解释性问题。
4.4 前端交互：不算技术难点但是加分项
前端我用的Django模板配合Bootstrap，没有上React或Vue，因为对毕业设计来说重心在算法和架构，前端尽量用最少的时间做清晰的效果。页面我设计了四个：
- 登录注册页——用户身份从模拟用户池中选择或新建；
- 电影浏览页——支持按类型、年份、评分排序筛选，这张页面本质是建立用户的“冷启动行为入口”；
- 评分页——用户给看过的电影打1到5星，这些评分进入Ratings表成为后续推荐迭代的基础；
- 推荐页——展示个性化推荐列表，每部电影卡片上写推荐理由，顶部提供推荐模式切换。
这套页面的核心不是花哨，而是形成完整的产品闭环：新用户进入系统后先浏览和评分，积累行为后才产生个性化推荐。这个闭环设定了，推荐算法才真正有展示空间。
5. 算法跑起来的那些坑：稀疏、冷启动、参数调优与实验评估
5.1 评分矩阵稀疏得吓人：你该怎么处理
豆瓣电影全量数据几万部电影、几十万条短评，如果不做任何处理直接构造成“用户-物品评分矩阵”，稀疏度会超过99%。这是什么概念？就是你创建了一个上万行、上万列的二维矩阵，里面几乎全是0，只有零星几个有值。
稀疏带来的直接后果是相似度计算时，很多用户之间完全没有共同评分过的物品，这些用户对的相似度就是0，在找邻居时直接被排除。这会导致召回列表很短，推荐结果覆盖面极窄。
我实际采用的缓解手段有三个。第一，用皮尔逊中心化而不是原始余弦，这样有少量共同评分的用户对也能获得较合理的相似度，而不是因为两个高分用户的绝对值接近被误判为高度相似。第二，对用户侧做筛选，只保留评分数量超过一定阈值（我用的是至少10条）的用户进入矩阵，把“只点亮了三部电影就跑了”的噪声用户剔除。第三，对评分做归一化处理，把每个用户的评分按比例缩放到0到1区间，减少极端打分风格的干扰。
5.2 冷启动问题：新用户和新电影怎么办
冷启动是推荐系统里最经典的问题，也是答辩老师最爱问的。新用户进来没有任何评分，协同过滤完全无法工作——你的相似度矩阵里根本没有他的数据。
这个问题的处理思路写出来并不难：当无法个性化时，就做非个性化兜底。我在系统里设计了一个热门榜兜底模块，基于全站电影的评价人数和平均分，计算一个“综合热度分”，大致是热度分 = 平均评分 * 0.6 + 评分人数归一化值 * 0.4，然后按热度分排序。新用户未产生评分行为时推荐这个榜，产生评分后立刻切换为协同过滤推荐。
新电影冷启动同理。一部刚爬进数据库、还没有用户评分的电影，ItemCF中它与任何物品的相似度都是0。处理方案有两个：一是基于内容特征做过渡，即计算电影的类型向量之间的相似度做兜底；二是把无评分电影从推荐池中排除，等有人评分后再纳入。毕业设计阶段我建议用方案二，简单清晰，论文里也容易解释边界条件。
5.3 参数调优：K值、相似度阈值、热门惩罚
协同过滤的调参说多不多，说少不少，核心就几个参数：
邻居数量K。UserCF中K值决定了每个用户取多少个相似用户作为邻居，ItemCF中则是取多少个相似物品。K太小，邻居噪声影响大，推荐结果不稳定；K太大，又会把大量低相似度但没什么参考价值的数据混进来稀释精度。就这套系统而言，我用留出法交叉验证，K设置在10到40之间效果较好，最后选了20。
相似度阈值。只保留相似度高于阈值的邻居。我设为0.1，低于这个值的相似度一律视为不相关，防止噪声对预测评分产生干扰。
热门物品惩罚。如果一个电影几乎人人都看过，那它在协同过滤中很容易被“错误推荐”——因为它和所有电影都有共同被看过的记录。解决思路是在相似度计算时对热门物品降权，具体做法是给物品加一个参数1 / log(1 + popularity)，其中popularity是该物品的评分人数。这样热门物品的共现次数虽然多，但权重被压下来，真正的“长尾”物品才有机会进入推荐列表。
这几个参数看起来各自独立，实际上是联动的。K变大时相似度阈值也得相应调严，否则大量低相似度的邻居会涌进来；热门惩罚加得重了，小众电影曝光会明显上升，但有可能牺牲头部热门电影的推荐精度。我在调参时是画了简单的趋势图来看指标变化的，这个方法不花哨但非常直观，答辩时拿出来展示会显得你实验做得扎实。
5.4 离线评估：怎么证明你的算法比“随便排”强
这是整个项目在“学术含金量”上最重要的一步。做推荐系统最容易犯的错误是：系统上线了，推荐列表能显示出来，就觉得算法是“对的”。但“能跑”和“有效”完全是两回事。
我使用的评估方案是离线实验法。把评分数据按时间顺序切分，用前80%做训练集，后20%做测试集。训练集只用来计算相似度矩阵和预测评分，测试集则把测试用户“已评分过但没让算法看到”的那些电影的预测结果拿出来验证。
评估指标选了两个主流的：
- RMSE（均方根误差）：衡量预测评分和真实评分的偏差，公式是
sqrt(平均((预测值-真实值)^2))，值越小说明预测越准。 - Top-N推荐的Precision和Recall：把算法推荐的前10部电影中，命中用户在测试集中真的看过或打高分的电影比例作为准确率。
跑完实验后，我把双协同过滤的结果、单独UserCF的结果、单独ItemCF的结果、以及热门榜兜底的结果集中放一张对照表，双协同的RMSE会明显低于单算法，Top-N准确率也会更高。这张表就是论文里最有力的“你的工作有实际效果”的证据。我实际测试中，双协同RMSE大约比单ItemCF降低8%左右，Top-10准确率比热门榜提升了将近一倍。
这里有个细节必须提醒：训练集和测试集切分时不要用随机切分，而要用时间去切分。原因很好理解：推荐系统是预测用户“未来”会喜欢什么，用过去预测未来才是合理的评价设定；随机切分相当于让算法通过“偷看未来”来预测已经知道的结果，数值会虚高，答辩时被老师一追问就露馅。
6. 论文与答辩：从“做了个系统”到“讲清一个方法”
6.1 系统设计章节怎么写才有说服力
论文这部分很多人容易写成“系统的功能有登录、注册、浏览、评分、推荐……”，这是流水账，没有信息量。写系统设计章节的核心原则是：让读者能从你的图、表和文字中直接还原整个技术方案。
我的建议是论文里至少包含以下内容：
- 一张三层架构图，数据层（爬虫+数据库）、算法层（相似度计算+召回+精排）、应用层（Django视图+前端页面），每层说明职责和接口关系；
- 一张数据表结构说明表，逐表列出关键字段的含义和类型；
- 对协同过滤算法的每一个公式做编号，公式之后紧跟“参数说明”和“在本系统中的应用场景”；
- 融合策略写清楚：为什么采用召回后再精排的级联式结构，而不是直接加权融合，这样写的论文读起来才像一个有设计过程的研究报告而不是一个功能清单。
6.2 答辩追问与应对思路
答辩最忌答非所问。以下是我整理出来最常被问的几个问题以及应对思路：
“为什么选协同过滤而不选基于内容的推荐？”答：基于内容的推荐只依赖物品特征，比如导演演员类型，但很难捕捉用户对电影风格的细微偏好，协同过滤直接利用用户行为数据，能够发现内容特征之外的隐性模式。比如内容特征无法表达“我喜欢的不是科幻，而是那种叙事结构层层嵌套的节奏感”，但协同过滤可以通过相似用户的行为间接学到。
“你提到的‘双协同过滤’跟混合推荐系统有什么区别？”答：混合推荐的范围更广，可以是内容+协同、深度学习+协同等任意组合；本系统的“双协同”限定在UserCF和ItemCF两个同源算法的组合，用UserCF解决召回覆盖率问题，用ItemCF解决排序精度问题，属于混合推荐大框架下的一个具体实现实例。这样回答既显示你了解更大体系，又不会把概念说散。
“如果评分数据未来每隔几分钟就大量更新，你的离线计算方案会不会过时？”答：当前系统面向毕业设计演示场景，数据量有限，离线日更策略完全够用；如果扩展到真实业务场景，可以把架构升级为离线计算+在线增量更新结合，比如对新增的用户行为实时更新相似度的增量部分，或引入近实时流计算框架。年轻的同学注意这个问题的关键不是真的去做流计算，而是让老师知道你有扩展方向的认识。
“你的项目里爬虫爬了豆瓣的数据，跨平台使用数据在法律上有没有问题？”答：这是近年来很现实的问题，答辩老师也不是真要把你送进去，而是想看你有没有版权和数据合规意识。到这里必须老老实实说清楚，项目数据仅用于课程学习和算法研究，不对网站运营产生影响，不对外公开数据文件，论文中会说明数据来源并遵循合理使用原则。这个回答没有标准公式，但底线就一条，不夸大、不碰红线、说明仅用于学术演示。
写在最后
做这套系统前前后后最大的体会是：推荐系统项目的核心其实不在“推荐系统”三个字，而在“数据链路能走通”这件事本身。爬虫拿到数据、清洗落库、矩阵构造、相似度计算、结果存储、页面展示，任何一个环节断掉，整个项目就卡住。如果你也是第一次接触这类题目，不妨先定一个“最小版本”——能跑通的数据量不需要很大，几百部电影、几千条评分记录就够了，把所有链路跑通之后再去扩数据、调算法、加功能。
给两个具体的操作建议。第一，算法模块一定要独立于Django，先用纯Python脚本跑通，再接入系统。这个习惯能帮你节省大量调试时间，因为Django的迁移、重启、静态文件这些环境问题会不断干扰你对算法本身的判断。第二，从第一天开始就把每张表、每个字段、每个关键步骤记录下来，不要等到写论文时才回忆，否则你会发现自己根本想不起来某些参数为什么这样设。
题目选好了，别慌，按数据、算法、工程、评估这条线往前走，每一步都留好中间结果。毕业设计这件事，二十周看起来很紧张，实际上每天两小时，节奏稳一点，完全来得及做出一套能讲故事的完整作品。
