协同过滤算法实战：从零构建电影推荐系统

简介：一份面向Python学习者与计算机专业毕业设计/课程设计的电影推荐系统完整项目。系统基于协同过滤算法，涵盖用户与物品相似度计算、评分预测、Top-N推荐等核心环节，并给出基于用户和基于物品两类实现思路；算法层涉及余弦相似度、皮尔逊相关系数等相似度度量，同时考虑缺失值处理、异常值清洗等数据预处理步骤，可帮助读者理解推荐系统从数据清洗、特征处理到算法落地与界面展示的全流程。压缩包共227个文件，约6.77MB，主要包括17个Python源码文件、14个pyc编译文件、7个CSV评分与电影数据集、1个SQL数据库脚本、148张JPG截图及CSS/JS/HTML前端页面，另附README说明文档，便于按模块学习并快速部署运行。已有41人学习下载，项目结构清晰，适合作为毕业设计选题参考、课程设计答辩展示或推荐系统入门实战练习。

1. 协同过滤不是唯一答案，但它是电影推荐系统最稳的起点

做推荐系统的人容易犯一个毛病：一上来就上深度学习，把双塔、FM、Transformer 全堆上去，结果数据量连一万条评分都没有，模型学出来的东西还不如直接给用户推热映大片。电影推荐系统设计这个题目，尤其容易掉进这个陷阱——因为电影评分的公开数据集太容易拿到，大家默认数据够多、特征够全，却忽略了协同过滤本身的价值边界在哪里。

协同过滤的逻辑其实非常朴素：用户 A 和用户 B 看过相似的电影，那 A 没看过但 B 喜欢的电影，大概率 A 也会喜欢。它不关心电影是什么类型、导演是谁、海报长什么样，只关心“谁和谁像”。这种“以人推物”的思路，在冷启动不严重、用户行为稠密的场景下，往往比内容推荐更直接有效。这也是为什么在毕业设计、课程项目和企业内部 Demo 里，“基于协同过滤的电影推荐系统”始终是出现频率最高的题目——它既涵盖了推荐系统最核心的算法思想，又不至于复杂到一个人做不完。

我需要先讲清楚一件事：协同过滤不是银弹，但它是理解推荐系统的最佳入口。当你把基于用户的协同过滤（UserCF）和基于物品的协同过滤（ItemCF）都实现一遍，再踩一遍相似度计算、稀疏矩阵、冷启动这些坑，你后面学矩阵分解、图神经网络推荐、甚至大模型推荐，都会有坐标系。这篇文章从数据、算法、工程落地三个层面，把一个完整可运行的电影推荐系统拆开讲透。

2. 协同过滤算法的数学原理与选型判断

2.1 从评分矩阵说起：协同过滤到底在算什么

所有协同过滤算法的起点，都是一个用户-物品评分矩阵。行是用户，列是电影，矩阵里的值代表用户对电影的评分。现实中，这个矩阵极度稀疏——一个用户看过几百部电影已经很活跃了，但电影总数可能是几万部，矩阵稀疏度通常在 99% 以上。协同过滤算法的任务，就是把这个矩阵中缺失的值预测出来，然后按照预测评分从高到低为用户生成推荐列表。

两个用户之间的相似度计算，常见的有三种方式，我实践下来各有适用场景：

皮尔逊相关系数（Pearson）适用于评分尺度不一致的场景。有的用户习惯打 3～4 分，有的用户习惯打 1～5 分，如果直接用余弦相似度，用户本身的评分习惯会干扰相似度计算。皮尔逊相关系数通过减去用户自己的平均分来消除这个偏差，公式如下：

# 皮尔逊相关系数 import numpy as np def pearson_sim(user1_ratings, user2_ratings): # 只取两个用户都有评分的电影 common = (user1_ratings > 0) & (user2_ratings > 0) if common.sum() == 0: return 0.0 r1 = user1_ratings[common] r2 = user2_ratings[common] if len(r1) < 2: return 0.0 # 减去各自均值，消除评分尺度偏差 r1_mean = r1.mean() r2_mean = r2.mean() numerator = ((r1 - r1_mean) * (r2 - r2_mean)).sum() denominator = np.sqrt(((r1 - r1_mean) ** 2).sum() * ((r2 - r2_mean) ** 2).sum()) if denominator == 0: return 0.0 return numerator / denominator

这段代码的关键在于：先做“共同评分项”的筛选（common.sum() == 0时直接返回 0），再去均值、算协方差。denominator 为 0 的情况在真实数据里很容易出现——比如两个用户共同评分的电影只有一部，或者某一方评分完全一致，此时相关系数无意义，直接返回 0 是稳妥做法。

余弦相似度（Cosine）实现最简单、计算最快，适用于评分矩阵已经做过归一化处理的场景，比如把评分减掉全局均值。它的缺陷是不考虑用户评分习惯差异，两个都爱打高分的人会被算成相似，即使他们对具体电影的口味并不一致。

调整余弦相似度（Adjusted Cosine）在 ItemCF 里比标准余弦相似度效果更好。计算物品 i 和物品 j 的相似度时，先减去每个用户对该物品评分的均值，再做余弦计算。原因在于：不同用户对同一部电影的评分尺度不同，减去用户均值相当于做了一次用户维度的标准化。

2.2 UserCF 和 ItemCF 的取舍：什么时候用哪个

选 UserCF 还是 ItemCF，不能拍脑袋，要看业务场景。

UserCF 的思路是：找到与目标用户最相似的 K 个用户，把这 K 个用户喜欢的、目标用户没看过的电影，按加权分数推荐给他。它社交属性更强，适合新闻推荐、社区内容推荐这类用户兴趣变化快的场景。但在电影推荐里，UserCF 有个明显问题：用户数量远大于电影数量时，用户相似度矩阵的计算和存储成本都很高；而且电影推荐面对的是几百万用户量级，实时计算用户相似度的延迟很难压下来。

ItemCF 的思路则是：计算电影之间的相似度，给用户推荐他看过电影的相似电影。Amazon 最早使用 ItemCF 做“买了 A 的人也买了 B”，它胜在物品数量通常远小于用户数量，物品相似度矩阵可以离线算好存起来，线上查询的时候只需要查表加聚合。对电影推荐来说，ItemCF 更合理——用户的兴趣会漂移，但电影之间的内容相关性是相对稳定的。

我一般会这样选型：

电影推荐场景下，我几乎总是先做 ItemCF，因为物品数量可控，矩阵容易离线维护，线上推理只有两步查表和一次加权求和，工程上非常干净。

2.3 相似度计算的三个必踩的坑

第一个坑是零均值处理缺失。直接用原始评分算余弦相似度，会导致所有“高评分用户”互相相似，所有“低评分用户”互相相似，与电影内容无关。实践中至少要做中心化处理，减去用户均值或全局均值。

第二个坑是共同评分数量过少。两个用户只看过同一部电影且都打了 5 分，皮尔逊系数算出来是 1.0，相关系数满分——但这个相似度完全没有统计意义。规避方法是设置一个最小共同评分阈值，我一般取 5~10，小于阈值直接判为不相似。

第三个坑是数据稀疏下的计算性能。暴力实现的时候，算一个用户相似度要遍历所有其他用户，复杂度是 O(U² × I)。数据量到了几十万用户就没法看了，必须用倒排索引：先为每个物品建立评分用户列表，计算相似度时只遍历共同评分过的用户对，复杂度降一个量级。

3. 从 MovieLens 数据到可运行的最小推荐系统

3.1 数据准备：用 MovieLens 1M 还是 100K

做电影推荐系统，MovieLens 数据集是事实标准。它由明尼苏达大学 GroupLens 研究组维护，包含用户 ID、电影 ID、评分（1~5 分）、时间戳和用户画像信息。两个常用版本：

• MovieLens 100K（10 万条评分、943 个用户、1682 部电影）：适合快速验证算法，单机跑无压力，用来调试相似度计算的边界条件很方便。
• MovieLens 1M（100 万条评分、6040 个用户、3952 部电影）：更接近真实分布，训练集/测试集切分的统计意义更明显，推荐质量评估结果可参考性更高。

我一般在开发阶段先用 100K 跑通流程，确认无 bug 后再切 1M 出最终结果。不要直接上 1M 调试，每次跑一遍 ItemCF 还要等计算相似度矩阵，太浪费时间。

数据下载后是zip压缩包，解压后会得到三个文件：ratings.dat、users.dat、movies.dat。MovieLens 1M 的字段分隔符是::，需要注意：

# 解压 data.zip 并查看数据文件结构 unzip data.zip -d ml-1m/ head -5 ml-1m/ratings.dat # 输出示例： # 1::1193::5::978300760 # 1::661::3::978302109 # 1::914::3::978301968 # 1::3408::4::978300275 # 1::2355::5::978824291

各字段依次是：用户 ID（UserID）、电影 ID（MovieID）、评分（Rating，取值 1~5）、时间戳（Timestamp）。head看到的时间戳是 Unix 时间戳，如果要转成可读时间可以用date -d @978300760做验证，但推荐系统的特征工程阶段一般用不到这个字段。

3.2 加载与预处理：pandas 完成评分矩阵构建

用 pandas 加载评分数据并转换成用户-物品矩阵，代码很直接。关键点是处理好缺失值：没有评分的位子填 0 还是留 NaN，取决于后面相似度计算用的是 numpy 还是 scipy。

import pandas as pd import numpy as np # 读取评分数据，注意分隔符是 "::" ratings = pd.read_csv( "ml-1m/ratings.dat", sep="::", names=["userId", "movieId", "rating", "timestamp"], engine="python", encoding="latin-1" ) # 过滤掉评分数量过少的用户和电影，降低矩阵稀疏度 user_count = ratings["userId"].value_counts() movie_count = ratings["movieId"].value_counts() ratings = ratings[ratings["userId"].isin(user_count[user_count >= 20].index)] ratings = ratings[ratings["movieId"].isin(movie_count[movie_count >= 10].index)] # 构建用户-电影评分矩阵，缺失值填 0 rating_matrix = ratings.pivot_table( index="userId", columns="movieId", values="rating" ).fillna(0)

这里的过滤逻辑是实践里的关键。原始 MovieLens 1M 矩阵稀疏度已经很高，如果不把评分次数太少的用户和电影去掉，相似度计算结果会被大量噪声干扰。我只保留评分次数不少于 20 的用户和不少于 10 的电影，这是一种通用做法，具体阈值可以根据数据量调整，逻辑是先降稀疏度再算相似度。

3.3 ItemCF 核心代码：完整可跑的推荐流程

下面这段代码是我在本地验证 ItemCF 的完整实现，直接复制就能跑，注释里标注了每个环节的作用。

from sklearn.metrics.pairwise import cosine_similarity import numpy as np # 1. 计算电影-用户倒排矩阵（转置评分矩阵，行变成电影） # 目的是计算电影之间的相似度 movie_user_matrix = rating_matrix.T # 2. 计算电影之间的余弦相似度矩阵 # 矩阵形状为 (n_movies, n_movies)，[i][j] 表示电影 i 和电影 j 的相似度 item_sim_matrix = cosine_similarity(movie_user_matrix.values) # 把相似度矩阵转成 DataFrame，方便按电影 ID 索引 item_sim_df = pd.DataFrame( item_sim_matrix, index=movie_user_matrix.index, columns=movie_user_matrix.index ) def recommend_itemcf(user_id, top_n=10, k_neighbors=20): """基于物品协同过滤为用户生成推荐列表 参数说明： - user_id: 目标用户 ID - top_n: 最终返回的推荐电影数量 - k_neighbors: 给每部电影取多少个最相似的近邻电影参与打分 """ # 当前用户已经评过分的电影（评分大于 0 的列） user_rated = rating_matrix.loc[user_id] rated_movies = user_rated[user_rated > 0].index # 对用户没看过的电影打分 candidate_scores = {} for movie_id in rating_matrix.columns: if movie_id in rated_movies: continue # 对每个候选电影，找到用户已看过且与其相似的电影 sim_sum = 0.0 score_sum = 0.0 for rated_movie in rated_movies: sim = item_sim_df.loc[movie_id, rated_movie] if sim <= 0: continue sim_sum += sim score_sum += sim * user_rated[rated_movie] if sim_sum > 0: candidate_scores[movie_id] = score_sum / sim_sum # 按预测分数降序排序，取前 top_n 个 sorted_scores = sorted(candidate_scores.items(), key=lambda x: x[1], reverse=True) top_items = [movie_id for movie_id, _ in sorted_scores[:top_n]] return top_items

这个实现对干代码最重要的三个点做个拆解。第一，它先构建了电影-用户倒排矩阵，这一步决定了相似度计算的对象是电影而不是用户。第二，评分预测用的是加权平均——用户对已看过的电影的评分乘以两部电影的相似度，再除以相似度之和做归一化，这比直接累加更合理，因为不同电影的近邻数量不一样，直接累加会导致高分电影优势过大。第三，if sim <= 0: continue这个判断过滤掉了不相似的电影，避免负相似度把预测分数拉向错误方向。

3.4 小规模验证：让输出结果可解释

算法跑完不是终局，你要能解释“为什么给用户推荐了这部片子”。我在评测时常用的做法是抽出推荐结果的相似来源：

def explain_recommendation(user_id, movie_id, top_k=5): """解释电影 movie_id 为什么被推荐给用户 user_id""" user_rated = rating_matrix.loc[user_id] rated_movies = user_rated[user_rated > 0] # 找出已看电影中与 movie_id 最相似的 k 部 sims = [(m, item_sim_df.loc[movie_id, m], user_rated[m]) for m in rated_movies.index] sims.sort(key=lambda x: x[1], reverse=True) res = [] for movie, sim, score in sims[:top_k]: res.append(f"看过《{movie}》(评分{score:.0f})，相似度{sim:.3f}") return f"推荐《{movie_id}》理由: " + "; ".join(res) # 示例：解释用户 1 看到的第 1 个推荐 recs = recommend_itemcf(1, top_n=5) for m in recs[:3]: print(explain_recommendation(1, m))

这个可解释性模块在答辩和项目展示中非常加分，也符合业务侧对推荐系统的基本要求——不能只会给结果，还要能讲清楚推荐理由。虽然上面的代码直接用 movieId 显示电影名称，实际项目中要 joinmovies.dat把 ID 映射成片名。

4. 系统架构与工程化：从单机脚本到可复用服务

4.1 推荐系统各模块的职责拆分

单机脚本谁都会写，但要称为“系统设计”，至少要能在模块层面讲清楚数据从哪来、计算结果存在哪、线上推理如何响应。一个可维护的电影推荐系统，通常分四层：数据存储层、离线计算层、在线服务层、评估与监控层。

数据存储层：评分数据存在 MySQL 里做业务回源，物品相似度矩阵和推荐结果存到 Redis 或 HBase 供线上快速读取。开发阶段用 pandas 生成的中间结果落到本地文件即可。

离线计算层：定时任务每天或每周跑一次 ItemCF 相似度矩阵更新。注意不是每次用户产生新评分都重算全量矩阵，那样计算成本太高。常见做法是离线全量重算 + 在线增量更新：每天凌晨跑一次全量，白天新产生的评分只更新该用户的候选列表。

在线服务层：接收用户 ID，从 Redis 读取该用户的推荐列表直接返回。如果该用户是新用户（冷启动），降级为热门电影榜单。如果该用户有实时行为但还没进离线更新窗口，追加一个轻量的“实时相似推荐”逻辑。

4.2 相似度矩阵的存储与定时更新方案

物品相似度矩阵在电影数量为 1 万时，矩阵大小是 1 亿个浮点数（约 800MB 内存）。直接全量存 Redis 有点浪费，实际工程中我一般只保留每部电影 Top-K 相似邻居，比如每部电影只存相似度最高的 50 个邻居，这样存储量直接降两个量级。

# 只保存每部电影 Top-K 相似邻居，压缩存储量 k = 50 top_neighbors = {} for movie_id in item_sim_df.index: # 排除自身，取相似度最高的 K 个 neighbors = item_sim_df.loc[movie_id].sort_values(ascending=False) neighbors = neighbors.drop(movie_id).head(k) top_neighbors[movie_id] = neighbors.to_dict() # 序列化后存入 Redis，key 用 "itemcf:sim:{movieId}" import json import redis r = redis.Redis(host="localhost", port=6379, db=0) for movie_id, neighbors in top_neighbors.items(): r.set(f"itemcf:sim:{movie_id}", json.dumps(neighbors))

这段存储逻辑有一个容易被忽略的设计决策：只保留 Top-K 而非全量相似度，这背后是精度与延迟的权衡。相似度很低的电影对预测贡献极小，还拖慢推理速度。K 取多少，我的经验是 20～80 之间，电影领域 50 是比较稳的默认值。

定时更新可以用 APScheduler 加到主进程，也可以在独立机器上用 Crontab 跑 Python 脚本，我更倾向于后者，因为离线任务失败不影响线上服务。

# 伪代码：定时任务入口，每天凌晨 2 点执行全量重算 def update_itemcf_job(): ratings = load_ratings_from_db() rating_matrix = build_matrix(ratings) sim_matrix = compute_item_sim(rating_matrix) top_neighbors = extract_top_k(sim_matrix, k=50) write_to_redis(top_neighbors) # 写日志并发送告警，如果矩阵数据量异常说明上游数据有问题 logger.info(f"itemcf updated, movies: {len(top_neighbors)}")

4.3 接口设计：推荐 API 的参数和返回格式

前端或客户端要接入推荐能力，需要一个标准化的 HTTP 接口。我常用的设计是/api/recommend，参数包括用户 ID、推荐数量，还可选传入过滤条件。返回格式采用 JSON，便于联调，核心字段如下：

from flask import Flask, request, jsonify app = Flask(__name__) @app.route("/api/recommend", methods=["GET"]) def recommend_api(): user_id = int(request.args.get("user_id")) top_n = int(request.args.get("top_n", 10)) exclude_seen = bool(request.args.get("exclude_seen", True)) # 在线服务只做查表和聚合，不实时计算相似度 recs = get_recommend_list(user_id, top_n, exclude_seen) if not recs: # 冷启动降级：返回热门电影 recs = get_hot_movies(top_n) return jsonify({"code": 0, "data": recs, "user_id": user_id}) if __name__ == "__main__": app.run(host="0.0.0.0", port=8000)

这个接口的一个关键设计是冷启动降级逻辑：当用户没有历史评分或算法没有产出时，不是报错，而是返回热门榜单兜底。线上推荐系统最怕的不是推荐不准，而是接口不可用。

5. 评估指标与参数调优：不只是算法能跑就行

5.1 离线评估：召回率、精确率、覆盖率、多样性

推荐系统不仅有准确率。评估一个协同过滤模型，我一般看五个指标：

精确率（Precision@K）：推荐的前 K 部电影里，有多少是用户真正喜欢（评分 >= 4）的。公式是用户喜欢且被推荐的电影数 / 推荐电影总数，衡量的是推荐列表的“含金量”。

召回率（Recall@K）：用户所有喜欢的电影里，有多少被推荐出来了。公式是用户喜欢且被推荐的电影数 / 用户喜欢的电影总数。

覆盖率（Coverage）：系统推荐出的不同电影数量占总电影数量的比例。如果覆盖率低，说明推荐集中在那几部热门电影上，长尾物品没有被利用。

多样性：推荐列表中不同类型、不同导演的电影占比。实现上是计算推荐物品之间的平均相似度，平均相似度越低越好。

# 一个简洁的评估函数 def evaluate_itemcf(test_set, train_matrix, k=10): """test_set 是用户实际的行为数据; train_matrix 是训练集评分矩阵""" precision_sum = 0.0 recall_sum = 0.0 user_count = 0 for user_id, liked_movies in test_set.items(): # 在训练矩阵上生成推荐 recs = recommend_itemcf(user_id, top_n=k) if not recs: continue hit = len(set(recs) & set(liked_movies)) precision_sum += hit / k recall_sum += hit / len(liked_movies) user_count += 1 return { "precision@10": precision_sum / user_count, "recall@10": recall_sum / user_count }

评估时要注意时间切分问题：不能用随机切分训练集和测试集，那会造成“未来数据预测过去行为”的泄漏。正确做法是按时间序列切分——用前 80% 时间段的评分训练，用后 20% 时间段的评分测试。推荐系统是一个时间敏感场景，用户当下的行为受之前行为影响，时序切分才能模拟真实线上环境。

5.2 必调参数：K 近邻数、相似度阈值、归一化方式

ItemCF 最核心的参数是近邻数 K，它对推荐结果的影响显著。K 太小，候选电影的特征表达不充分；K 太大，噪声会被带进预测。

第二个参数是相似度阈值，即只保留相似度大于某值的邻居参与打分。我一般会在0.1 ~ 0.3之间做试验，根据最终推荐结果的好坏反向调整。

第三个参数是评分归一化。原始 1~5 分的评分预测容易受到用户评分习惯影响，常见的做法是做 z-score 归一化：

# z-score 归一化 def normalize_ratings(rating_matrix): """对每行（用户）做均值方差归一化""" user_mean = rating_matrix[rating_matrix > 0].mean(axis=1) user_std = rating_matrix[rating_matrix > 0].std(axis=1) # 避免除零，用 epsilon 兜底 user_std = user_std.replace(0, 1e-8) normalized = rating_matrix.sub(user_mean, axis=0).div(user_std, axis=0) # 把原来的 0 保持为 0（无评分项不参与归一化） normalized[rating_matrix == 0] = 0 return normalized

归一化后的评分在做加权平均时，不同用户的评分尺度被拉齐，预测值会更接近“这个用户相对自己平均水平的偏好”，而不是绝对分值。

5.3 冷启动问题：新用户新电影怎么推荐

协同过滤有个天生的短板：它依赖历史行为。新用户没有任何评分，算法无法计算他和其他用户的相似度；新电影没有评分，算法无法计算它和其他电影的相似度。

冷启动的常见解法，按顺序从简单到复杂：

对于新用户，直接推荐全局热门电影，这个方案简单有效，因为热门电影被喜欢的概率较高，保证第一个接口不空返回即可。用户产生几条评分后再切换到 ItemCF 推荐，效果平滑串接。

对于新电影，收集电影的内容属性（导演、演员、类型标签），在 ItemCF 计算相似度的时候，如果新电影没有评分，就回退到基于内容的相似度——比如类型标签相同的电影直接赋予一个先验相似度。这个方案不需要训练模型，就是查电影元数据表。

这些方案都不是完美的，但你在答辩或者项目汇报时能把冷启动的解法讲清楚，说明你真的理解推荐系统工程落地，而不只是背了一个算法公式。

6. 用 visual 评估和 zip 项目交付时的一个提速技巧

当你要交付这个电影推荐系统给别人运行时，把项目打包成zip安装包是常见做法。这里有一个经常踩坑的地方：zip 包解压后路径里带空格或不兼容字符，导致导入数据zip文件时路径拼接出错。我一般习惯在做最终交付前跑一次 7-Zip 或 unzip 的完整校验，确保压缩包里文件完整。

# 校验 zip 包完整性 unzip -t movie_recommendation.zip # 输出包含 "No errors detected" 才算完整

另一个提升交付质量的技巧是把数据集和代码分开打包。MovieLens 数据文件较大且不会频繁变动，代码会多次修改。合在一个 zip 里，每次改代码都要整个包重新传递。我一般打成两个包：code.zip（代码 + requirements.txt + README.md）和data.zip（解压后的数据文件）。README 里必须有且仅有这几行，能让人不读代码就能跑起来：

# 一键运行 python main.py --mode itemcf --dataset data/ml-1m # 评估模式 python main.py --mode eval --k 10

最后一个提速技巧是用来验证 ItemCF 结果是否合理的简单方法：取一部电影，输出它最相似的 5 部电影，人工看一下结果是否合理。比如《星球大战（1977）》的相似电影应该是《帝国反击战》《绝地归来》，如果算法推荐出的是毫无关联的喜剧片，那大概率是数据预处理环节出了问题——特征没有清洗干净，或者相似度公式选错了。这个“单点验证 + 人工判断”的流程，比跑完整评估指标快得多，适合在每次改代码后做快速回归。这种数据质量审查习惯，比调参本身更能决定最终系统的好坏。

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