基于Python与Django的电影推荐系统：协同过滤算法与数据库设计实战

1. 为什么选“电影推荐系统”当完整项目：需求拆解与技术选型思路

先说一个很多人容易忽略的点：电影推荐系统这个题目，真正考察的不是你会不会写一个算法，而是你能不能把“协同过滤算法”“Python + Django”“数据库”这三样东西在同一个项目里拧成一根绳。我在帮人做项目踩坑时最深的感受是——算法部分往往一晚上就能跑通，真正耗时间的反倒是数据怎么存、接口怎么调、页面怎么蹦出来。

1.1 从题目到实际需求的认知转化

把题目拆开看，其实藏着三个需要动手解决的问题：

• “基于Python + Django”不是让你在两个技术里二选一，而是要求算法用Python写、Web框架用Django搭、底层数据交给数据库承载。这是一个典型的全栈小项目，前前后后都有活干。
• “协同过滤算法”是推荐系统的核心，但是选题人通常不要求你从零发明新算法，更看重你是否能正确实现“基于用户”或“基于物品”的协同过滤，并且能在网页上把推荐结果展示出来。
• “源码+数据库+文档”说明最终交付物是完整可运行的工程，不只是几个.py文件。数据库里得有用户数据、电影数据、评分数据，文档里得有需求分析、数据库设计、测试说明。

所以我拿到这个需求时，第一步不是去写filter函数，而是先把整个链路画清楚：原始数据集 -> 清洗 -> 评分矩阵 -> 相似度计算 -> 推荐结果 -> Django 视图 -> 前端展示。这个认知转化是最关键的。不看这条链路，代码写到一半一定会卡壳。

1.2 Django + 协同过滤：这套组合解决什么问题

协同过滤算法的核心假设是：如果两个用户在过去对某些电影的评分态度相似，那么他们对未来电影的评分也可能相似；如果两部电影被同一群用户打出相近分数，那么它们就是相似的。放在Web项目里，Django要做的就是接收前端请求、调用算法模块、把结果渲染成页面。

我选Django而非Flask，原因很实在：

1. Django自带ORM，操作SQLite或MySQL时不需要手写一堆原生SQL，对新手友好，而且模型定义清楚后数据库表结构自动生成。
2. Django有完整的Admin后台，可以快速管理用户、电影、评分数据，调试验证阶段特别省事。
3. 项目文档里通常要求体现“MVC/MVT架构”，Django天然就是MVT，答辩时好解释。

当然Django也有学习曲线，比如中间件、信号、迁移机制，第一次接触会觉得“这不是杀鸡用牛刀吗”。但你考虑到毕业设计或课程设计的评审计分点——项目结构是否规范、是否使用框架的完整能力，那Django绝对是比Flask更稳的选择。

1.3 数据库选型：SQLite 起步、MySQL 迁移的平衡点

数据库是标题里明确出现的词，所以这块不能马虎。根据项目实际场景，我建议用这样的策略：

• 开发阶段用SQLite：Django默认配置就是SQLite，零配置文件，不存在数据库账号密码、IP端口等一堆初始化问题。我第一个版本就是直接在db.sqlite3里建表，数据量在几万条评分记录时完全没有性能压力。
• 演示或答辩阶段可以迁到MySQL：如果你担心评阅老师问“为什么不用MySQL”，可以在文档里加一节“数据库可迁移性说明”，并且实际演示一次python manage.py migrate切换到MySQL的流程。注意提前在Django的settings.py里配置databases连接，并装好mysqlclient或pymysql。

下面这个配置是Django连接MySQL的常见写法，注意别在生产代码里写死密码，最好通过环境变量读取：

# settings.py 片段 import os DATABASES = { 'default': { 'ENGINE': 'django.db.backends.mysql', 'NAME': os.environ.get('DB_NAME', 'movie_recommend'), 'USER': os.environ.get('DB_USER', 'root'), 'PASSWORD': os.environ.get('DB_PASSWORD', ''), 'HOST': os.environ.get('DB_HOST', '127.0.0.1'), 'PORT': os.environ.get('DB_PORT', '3306'), } }

不过话说回来，对于这个项目的数据量级，SQLite完全够用，不要为了炫技而盲目上MySQL。我在实测中发现，如果评分表只有几万行，Django ORM查询加一点索引后，响应速度根本感觉不到差别。真正影响性能的是后面要说的相似度计算，而不是存储层。

2. MovieLens 数据集的导入、清洗与评分矩阵的构建

做推荐系统最怕的不是算法写不出来，而是“没有数据”。电影推荐系统常用的公开数据集是 MovieLens，它包含用户ID、电影ID、评分（0-5分）和时间戳等信息。你直接下载后可以看到这些文件。需要提醒一句：论文或课程设计中使用公开数据集一定要在文档里注明出处，防止被认为数据造假。

2.1 数据源字段语义与导入前检查

以 MovieLens 100K 为例，核心文件包括：

• u.data：每一行是“用户ID、电影ID、评分、时间戳”，使用制表符分隔。
• u.item：电影信息，关键字段是“电影ID、电影标题、上映年份、类型标签”。
• u.user：用户信息，包含年龄、性别、职业等，推荐系统入门阶段不一定用得上。

导入到Django前，我们要做两步检查：

1. 检查分隔符。很多初学者直接用csv.reader去读，结果发现字段错位，就是因为没注意到分隔符是\t而不是逗号。
2. 检查评分范围。MovieLens的评分是1-5分整数，如果后续要做归一化或均值中心化，需要先明确边界。

2.2 基于 pandas 的评分数据清洗策略

我的清洗思路是这样的：

import pandas as pd ratings = pd.read_csv( 'ml-100k/u.data', sep='\t', header=None, names=['user_id', 'movie_id', 'rating', 'timestamp'] ) # 检查缺失值 print(ratings.isnull().sum()) # 检查每个用户评分数量的分布 user_count = ratings.groupby('user_id').size() print(user_count.describe())

这里有一个特别容易被忽略的细节：有些用户只评了1部电影，这种用户的评分数据对协同过滤来说几乎没用，因为相似度计算的共现项太少。我处理时会把评分数量小于5的用户过滤掉，这是实际项目中验证过的做法。

valid_users = user_count[user_count >= 5].index ratings = ratings[ratings['user_id'].isin(valid_users)]

清洗之后，把数据导入Django的Rating模型。如果数据有几万行，直接遍历create()会很慢，建议用bulk_create批量导入：

from movierecommend.models import Rating batch = [] for row in ratings.itertuples(index=False): batch.append( Rating( user_id=int(row.user_id), movie_id=int(row.movie_id), rating=float(row.rating) ) ) if len(batch) >= 5000: Rating.objects.bulk_create(batch) batch.clear() if batch: Rating.objects.bulk_create(batch)

2.3 把 DataFrame 变成稀疏矩阵：不要犯直接用稠密矩阵的错

协同过滤算法的输入通常是“用户-电影评分矩阵”，行是用户，列是电影，单元格是评分。MovieLens 100K 的用户数约 943，电影数约 1682，如果用普通DataFrame.pivot生成稠密矩阵，会有大量 NaN，计算相似度时空转很多，内存也会浪费。

我强烈建议一开始就使用scipy.sparse或numpy屏蔽 NaN 的矩阵：

import numpy as np from scipy.sparse import csr_matrix, coo_matrix # 先构造稀疏的 coo_matrix row = ratings['user_id'].values - 1 # 索引从0开始 col = ratings['movie_id'].values - 1 data = ratings['rating'].values sparse_ratings = coo_matrix((data, (row, col))) print(sparse_ratings.shape) print(sparse_ratings.nnz) # 非零元素个数

这一节一定要写进文档里，因为“稀疏矩阵”是推荐系统的关键词，也是答辩时的加分点。当时我自己的教训是：第一版用了pivot_table后测试集上跑一次相似度计算要等1分钟，改成稀疏矩阵后计算直接变成秒级，效果天差地别。

3. 协同过滤算法源码拆解：相似度计算与打分预测逻辑

算法本身不算高深，真正容易写错的地方是“相似度怎么算”和“预测分数怎么加权”。这块我把自己的实现思路完整拆开讲，代码你可以直接抄，但更建议先理解每一行在干什么。

3.1 基于物品的协同过滤：我为什么推荐优先实现 item-based

协同过滤有两种主流路线：

• 基于用户（user-based）：找和你口味相似的用户，看他们喜欢什么电影。
• 基于物品（item-based）：找你喜欢的电影，找与它相似的电影，再推荐给你。

两者在原理上是对称的，但对于“电影推荐系统”这个场景，我更推荐先实现item-based，理由很实际：

1. 电影数量相对用户数量增长更慢，物品间的相似度矩阵可以离线计算好，等用户发起请求时直接查表，在线响应压力小。
2. 推荐结果的解释性好——“因为你收藏了《盗梦空间》，所以推荐《星际穿越》”这种话术容易在网页展示。
3. user-based 的相似度矩阵会随新用户注册频繁变化，线上维护成本更高，对算法理解不到位的初学者更容易写出性能灾难。

3.2 余弦相似度和皮尔逊相关系数怎么选

相似度公式是协同过滤的核心细节。余弦相似度的公式是：

cos(user_i, user_j) = sum(rai * raj) / (sqrt(sum(rai^2)) * sqrt(sum(raj^2)))

皮尔逊相关系数则是在余弦相似度的基础上，先对每个用户的评分做了均值中心化，消除不同用户打分习惯的偏差。比如一个用户总喜欢打4分以上，另一个用户总打3分左右，皮尔逊系数能更好地抓“趋势相似”。

我实际开发时发现：在MovieLens这个数据集上，均值中心化的皮尔逊相似度表现普遍比纯余弦好，因为MovieLens用户确实存在明显的打分偏向。但皮尔逊有一个副作用：如果两个用户共同评分的项目很少，计算出的相似度可能很高，但这是假信号。所以后面要引入“共同评分项数量下限”这个阈值。

3.3 item-based 核心实现：预测评分公式与 Python 代码

基于物品的协同过滤预测用户u对电影i的评分，公式是：

pred(u, i) = sum( sim(i, j) * rating(u, j) ) / sum( abs(sim(i, j)) )

其中j是用户u已评分过的电影集合中，与i相似度最高的k个电影；sim(i, j)是电影i和电影j的相似度。

下面是我完整跑通过的实现逻辑，分为三步。

第一步：计算电影之间的相似度矩阵。注意这里不是直接用原评分矩阵做余弦，而是先中心化或归一化，可以减少评分偏差影响。

def compute_item_similarity(sparse_ratings, top_k=50): # 转成物品-用户矩阵，便于计算物品间相似度 item_user = sparse_ratings.T.tocsr() # 均值中心化 item_means = np.asarray(item_user.mean(axis=1)).flatten() item_user_centered = item_user.copy() # scipy稀疏矩阵无法直接广播，因此逐行处理或使用乘法技巧 for idx in range(item_user.shape[0]): item_user_centered[idx, :] = item_user[idx, :] - item_means[idx] # 使用余弦公式计算相似度 norm = np.sqrt(item_user_centered.multiply(item_user_centered).sum(axis=1)) norm = np.asarray(norm).flatten() norm[norm == 0] = 1e-6 item_user_norm = item_user_centered.multiply(1.0 / norm[:, None]) similarity = item_user_norm @ item_user_norm.T return similarity

第二步：对目标用户未看过的每部电影，找到该用户已看过的电影中与目标电影最相似的 k 部，做加权预测。

def predict_rating(user_id, movie_id, rating_matrix, similarity, user_movies): # rating_matrix: 用户-电影中心化后的稀疏矩阵 # user_movies: 该用户已评分的电影索引列表 # 取出用户已评分电影与目标电影相似度 sim_scores = similarity[movie_id, user_movies] rating_scores = rating_matrix[user_id, user_movies] # 取绝对值保证分母不为零，同时保留方向 denom = np.abs(sim_scores).sum() if denom == 0: return global_mean_rating if 'global_mean_rating' in globals() else 3.0 return (sim_scores * rating_scores).sum() / denom

第三步：给用户生成 Top-N 推荐列表。遍历所有未评分电影，计算预测分数，按分数排序取前 N 个。

def recommend(user_id, rating_matrix, similarity, k=10, n=5): rated = rating_matrix[user_id].nonzero()[0] unrated = [i for i in range(rating_matrix.shape[1]) if i not in rated] if len(unrated) == 0: return [] results = [] for movie_id in unrated: # 只与已评分的电影做一次相似度过滤 score = predict_rating(user_id, movie_id, rating_matrix, similarity, rated) results.append((movie_id, score)) results.sort(key=lambda x: x[1], reverse=True) return [movie_id for movie_id, _ in results[:n]]

这里有个细节：rating_matrix[user_id]取出来的是一个一维数组，直接nonzero()[0]得到已评分电影索引，但如果你面对的是csr_matrix，取行可能需要先tolil()再操作，否则会有警告。实际项目里我通常把矩阵转成 LIL（list-of-lists）格式后再遍历，避免性能与语法的双重坑。

3.4 面向网页实时推荐的性能改造

如果每次请求都现算相似度矩阵，那项目演示时一定会卡到让你尴尬。我的做法是启动时预先计算相似度矩阵并缓存到内存或数据库表。

Django 里可以用一个简单的模块级变量缓存，或者写一个cached_similarity()函数：

from django.core.cache import cache _SIM_CACHE_KEY = 'item_similarity_matrix' def get_similarity_matrix(): cached = cache.get(_SIM_CACHE_KEY) if cached is not None: return cached matrix = compute_item_similarity(sparse_ratings) cache.set(_SIM_CACHE_KEY, matrix, timeout=60 * 60 * 24) return matrix

如果数据量再大一点，可以考虑不缓存全量矩阵，而是只保留每个物品的 top-k 相似物品列表，存储到数据库一张ItemSimilarity表里。我的实践结论是：对 MovieLens 100K 这个规模，全量矩阵完全撑得住，不要过度设计。

4. Django 集成：模型设计、推荐接口与前端页面的衔接

算法部分跑通后，项目就进入“如何把算法塞进Web框架”的阶段。这一步的目标是做出来一个能点、能看、能演示的网页系统，而不是只在 Jupyter Notebook 里出结果。

4.1 models.py 里的三张核心表：User、Movie、Rating

Django 默认有用户模型，但为了灵活性和演示方便，我建议自定义一个简单的UserProfile或直接使用内置 User。电影表和评分表是必须的：

from django.db import models from django.contrib.auth.models import User class Movie(models.Model): title = models.CharField(max_length=255) genres = models.CharField(max_length=200, blank=True) release_year = models.IntegerField(null=True, blank=True) def __str__(self): return self.title class Rating(models.Model): user = models.ForeignKey(User, on_delete=models.CASCADE) movie = models.ForeignKey(Movie, on_delete=models.CASCADE) rating = models.FloatField() timestamp = models.DateTimeField(auto_now_add=True) class Meta: unique_together = ('user', 'movie')

这里重点说一下unique_together。它的含义是一个用户对同一部电影只能有一条评分记录，否则协同过滤评分矩阵的构造会产生重复项，导致数据污染。这个约束在实际项目里极重要，也是我反复强调的坑。

4.2 请求处理流程与推荐逻辑的视图实现

一个典型的推荐页视图是这样的：用户请求/recommend/，视图读取当前登录用户，取其评分记录，调用协同过滤模块，推荐若干电影ID，再查数据库获取电影详情，渲染到模板。

import numpy as np from django.shortcuts import render from django.contrib.auth.decorators import login_required from .models import Rating, Movie from .algorithms import recommend @login_required def recommend_view(request): user = request.user # 构造该用户的评分矩阵行向量 user_ratings = Rating.objects.filter(user=user).values_list('movie_id', 'rating') if len(user_ratings) == 0: # 冷启动处理：按全体用户平均分或热门度推荐 top_movies = Movie.objects.annotate(avg_rating=Avg('rating')).order_by('-avg_rating')[:10] return render(request, 'recommend.html', {'movies': top_movies}) # 这里需要把你刚算好的稀疏矩阵和相似度矩阵传进来 # 正常项目中可以通过一个 service 层封装 movie_ids, scores = run_recommendation_for_user(user.id) recommended_movies = Movie.objects.filter(id__in=movie_ids) return render(request, 'recommend.html', {'movies': recommended_movies})

不要把这个视图里处理所有逻辑。推荐系统的算法调用最好独立成一个service.py或algorithms.py，视图只负责拉数据、调服务、返回结果。这样文档里的“模块设计”写起来也清晰。

4.3 前端如何展示推荐结果：模板渲染与简单交互

前端部分不需要做重活，Django 模板系统足够。推荐页可以有：

• 展示当前用户的评分历史，方便演示时验证推荐效果。
• 展示推荐电影列表，附带电影标题、类型、预测评分。
• 提供一个“评分”输入框，用户给某部电影打分后，点击提交，刷新推荐结果。

模板示例：

<!-- recommend.html 片段 --> {% if movies %} <ul> {% for movie in movies %} <li> <p>{{ movie.title }}</p> <p>{{ movie.genres }}</p> <p>预测评分: {{ movie.pred_score|floatformat:2 }}</p> </li> {% endfor %} </ul> {% else %} <p>还没有足够的评分数据来生成推荐，先去评分吧。</p> {% endif %}

这里有个实用技巧：为了让页面看起来不单调，建议加一个“热门电影榜”作为冷启动的补充模块。这样即使用户没有评分记录，也不会看到一片空白。标题里要求的“系统完整性”，很多时候就体现在这种细节里。

5. 调试过程中真正让我头疼的四个坑（附排查链路）

这部分不是凑字数，而是我实际调试这个项目时踩完坑后的沉淀。每个坑都附了排查思路，你可以顺着链路自己复现一遍，比直接拿答案更有收获。

5.1 稀疏矩阵导致的 ZeroDivisionError：不只是一行代码的事

现象：预测评分函数跑起来后，时不时报ZeroDivisionError: division by zero。

我的排查链路：

1. 先在predict_rating函数里打印denom，发现它等于0。
2. 继续打印sim_scores，发现所有相似度分数都是0，原因是有两个电影没有任何共同评分用户。
3. 再深入发现，因为我对所有电影计算了全局相似度矩阵，而很多“冷门电影”之间共现为0，相似度天然是0。
4. 修复方案不是简单加一个if denom == 0，而是应该在过滤候选电影时提前排除掉那些与用户已评分电影完全没有相似性的电影，减少无效计算。

最终代码里加了两层保护：

sim_scores = similarity[movie_id, user_movies] valid_mask = sim_scores > 0 user_valid_movies = user_movies[valid_mask] sim_scores = sim_scores[valid_mask]

这样既能避免除零，又能减少噪声。你以后要把这个经验写进文档的测试章节，比只写“运行无报错”有说服力得多。

5.2 新注册用户没有评分记录时的冷启动 fallback

现象：新注册用户登录后点击“获取推荐”，直接空白页。

这其实是冷启动问题。我当时的修复方案是：

def get_recommendation_for_user(user): user_ratings_count = Rating.objects.filter(user=user).count() if user_ratings_count == 0: # 策略一：全局热门电影 return Movie.objects.filter(rating_count__gte=50).order_by('-avg_rating')[:10] # 策略二：给用户随机推荐几部高评分电影 return ...

方案选了“热门电影Top榜”，因为它的业务语义最清楚，模板也好展示。

5.3 SQLite 并发写锁在测试阶段的干扰

现象：我在网页上连续快速提交多条评分时，偶尔出现database is locked错误。

排查后发现：Django开启多个线程时，SQLite对写操作的并发能力比较弱。测试阶段我用浏览器的多个标签页同时操作，触发了锁冲突。

修复思路有两个：

1. 修改settings.py中的连接选项，增加超时时间：

OPTIONS = {'timeout': 20}

2. 正式演示或报告时提前说明“本项目开发环境使用SQLite，生产环境建议切换为MySQL”。这句话看似简单，却能让答辩老师觉得你有工程思维。

5.4 编码问题导致的电影标题乱码

现象：导入电影数据时，部分标题显示为“之类乱码。

排查链路：读文件时没有指定 UTF-8 编码，导致特殊字符解析错误。修复位置是pandas读文件或数据导入脚本：

movies = pd.read_csv('u.item', sep='|', encoding='latin-1', header=None)

MovieLens 老版本的数据中标题可能混合了非UTF-8编码，用latin-1通常能兼容。导入Django后，记得在数据库层确认连接编码为utf8mb4。

6. 离线评价与调优：用 RMSE 说话，而不是凭感觉

很多人做推荐系统时，自己觉得推荐结果“差不多”，但答辩时一问“准确率多少”就卡壳。所以离线评价是项目中不可跳过的一环。

6.1 按时间切分训练集与测试集

评分数据不能随机切分，因为协同过滤依赖时间演化的用户行为。更稳妥的方法是按时间戳排序，取前80%作为训练集，后20%作为测试集，模拟真实场景。

ratings = ratings.sort_values('timestamp') cutoff = int(len(ratings) * 0.8) train = ratings.iloc[:cutoff] test = ratings.iloc[cutoff:]

然后用训练集构建矩阵，用测试集中的“用户-电影”对做预测，比较预测评分和真实评分。

6.2 RMSE/MAE 的计算与基准对比

RMSE 的公式是：

RMSE = sqrt( mean( (pred_i - actual_i)^2 ) )

MAE 是平均绝对误差：

MAE = mean( abs(pred_i - actual_i) )

计算代码很简单，但关键是要有基准线——比如“全部预测为全局平均分”的RMSE是多少。我实测 MovieLens 100K 上：

这组数据基本符合一般论文的结论：基于物品的协同过滤在RMSE上略优于基于用户的版本。你可以把这组对比表写进文档，评分老师会很喜欢这种“有数字支撑”的调优记录。

6.3 k 近邻数量的优化与稀疏度阈值

k是预测时选取相似电影的数量。k太小容易受噪声影响，k太大则把不相似的电影也拉进计算。我在做调参时，使用网格搜索：

for k in [5, 10, 20, 30, 50]: rmse, mae = evaluate(train, test, k) print(k, rmse, mae)

我在 MovieLens 100K 上的经验最佳区间是k = 20~30。当k超过50后，RMSE不降反升，原因是太多无关电影稀释了有效信号。

另外，共同评分项数量阈值也值得设置。没有共同评分项时相似度直接设为0，有共同评分项但数量小于3时，应将其相似度乘以一个小的权重，降低置信度。这个细节我在文档中单列了一小节，命名为“相似度置信度修正”。

7. 项目文档怎么写才能让评分老师挑不出毛病

标题里明确提到“文档”，所以不要只写技术代码，文档同样是项目交付物。我的文档结构大致如下：

7.1 需求分析部分的重点

需求分析不要写成“系统需要登录、注册、推荐”这种流水账。要包含：

• 业务背景：为什么需要电影推荐系统？用户面临信息过载，需要个性化推荐。
• 功能需求：用户注册登录、电影列表浏览、评分、推荐列表展示。
• 非功能需求：性能（响应时间小于2秒）、可用性（冷启动处理）、可扩展性（支持MySQL迁移）。

7.2 架构图与数据库设计说明

我不建议用复杂UML图，但一定要有系统模块图和数据库ER图。数据库设计部分重点写清楚三张表：用户表、电影表、评分表，标出外键关系和索引设计。下面是一个简洁的表结构说明：

7.3 测试与运行说明的坑

文档中的测试部分，一定要包含：

• 各页面的功能测试用例（登录、评分、推荐展示）。
• 算法模块的离线评测结果，放上面RMSE对比表。
• 运行环境说明：Python版本、依赖清单（requirements.txt）、启动方式。

这里最常见的问题是：文档里写的启动命令和实际代码不一致。我通常会专门在交付前按文档环境重头跑一遍，记录每一个步骤。如果有人拿到项目后半小时内跑不起来，评阅印象分会大打折扣。

另外，requirements.txt要固定版本号，别写django>=5.0这种，因为未来版本升级可能导致API变化。我个人更推荐：

pip freeze > requirements.txt

但生成后要检查其中是否有本机特有的安装路径，有的话手动清理掉。

最后再分享一个经验：我在演示这个系统时，一般会准备两三个评分记录丰富的老账号，和一个刚注册的空白账号。老账号用来展示协同过滤推荐的个性化效果，空白账号用来展示热门榜的冷启动兜底策略。这样整套系统的功能逻辑都被覆盖到了，不到十分钟就能把核心亮点讲完，配合上面的RMSE表和文档结构，基本上不会出现无话可说的冷场局面。