基于Python协同过滤的新闻推荐系统实操指南

简介这套基于Python协同过滤算法的新闻推荐系统毕业设计主要面向计算机相关专业学生、毕业设计选题者以及推荐系统入门开发者用于解决从零搭建个性化新闻推荐项目的完整流程。系统涵盖新闻数据采集与清洗、用户浏览与点击行为分析、基于用户和物品的协同过滤推荐、相似度计算、Top-N推荐列表生成并结合准确率、召回率、F1值等指标开展效果评估与优化。资源包内包含146个文件压缩后总大小仅577KB文件类型以Java与Scala实现的核心算法类、Vue前端页面、Python脚本为主同时含有XML配置、SQL数据库文件、Dockerfile和项目说明文档等能够覆盖推荐系统从离线训练到Web服务部署的各个环节。目前已有353人学习下载。深入研究该源码可掌握余弦相似度、皮尔逊相关系数及奇异值分解等推荐算法在实际项目中的落地方法参考其系统架构与模块划分来搭建自己的新闻推荐演示系统既适合毕业设计参考也适合作为推荐系统工程化实践的学习素材能有效缩短从理论到实现的路径。1. 毕设做新闻推荐系统先认清这个题目的本质很多同学拿到基于Python协同过滤算法的新闻推荐系统这个毕设题目时真实的心理活动是推荐系统不是大厂才玩得起的东西吗协同过滤的数学公式看着就头疼答辩的时候怎么证明自己的东西真的能用其实这个题目的本质就两层——Python 这一层负责数据处理、相似度计算和 Web 展示协同过滤算法这一层负责核心的推荐逻辑。它要求你交付的不是论文里的一个概念而是一个能导入新闻数据、对用户行为建模、最终给每个用户返回 Top-N 推荐列表的可运行系统。这篇笔记按我带毕设的实际思路走一遍从数据表怎么建、UserCF 和 ItemCF 怎么写到冷启动怎么兜底、哪些地方容易翻车最后落到离线评估和答辩展示。2. 数据是推荐的起点四张表与推荐主流程很多人口头说算法是核心但真正动手时死在第一步的是数据没归好。新闻场景和电商不一样用户几乎不会给新闻打分系统里只有点击、收藏、转发这类行为日志。所以你要做的第一件事不是写算法而是把行为日志清洗成协同过滤能吃进去的评分矩阵。我一般会先把数据模型定成四张表这四张表足够撑起整个毕设项目。2.1 四张核心表用户、新闻、行为、推荐结果第一张表是用户表存用户基本信息第二张是新闻表存新闻的标题、分类、发布时间、是否下架第三张是行为表这是最重要的一张表每一条用户行为都落在这里第四张是推荐结果表跑批完把每个人的推荐列表存进去前端直接查表展示。CREATE TABLE users ( user_id INT PRIMARY KEY, username VARCHAR(50), created_at DATETIME ); CREATE TABLE news ( news_id INT PRIMARY KEY, title VARCHAR(255), category VARCHAR(50), publish_time DATETIME, is_delete TINYINT DEFAULT 0 ); CREATE TABLE behavior ( id INT PRIMARY KEY AUTO_INCREMENT, user_id INT, news_id INT, behavior_type TINYINT COMMENT 1点击 2收藏 3转发, score FLOAT DEFAULT 1.0, created_at DATETIME, INDEX idx_user (user_id), INDEX idx_news (news_id) ); CREATE TABLE rec_result ( user_id INT, news_id INT, score FLOAT, rank INT, create_date DATE );这里有个关键细节行为表里除了 behavior_type 还单独存了一个 score 字段。这是给后面算法留的口子——评分矩阵里的数值不能直接用行为类型凑合而是要做一个映射。我的映射规则是点击 1.0收藏 2.0转发 3.0如果阅读时长超过 10 秒再额外加 0.5。这样做的理由是新闻没有星级评分协同过滤又必须有数值型评分矩阵隐式反馈转显式评分是绕不开的一步。映射规则不唯一但要点是能拉开分数差距全部设成 1 会导致后面算相似度时区分度极差。2.2 用代码把推荐主流程串起来四张表建好后推荐主流程就固定成六步加载行为数据 → 构造用户-新闻评分矩阵 → 计算相似度矩阵 → 取出目标用户的 Top-K 相似用户 → 加权聚合出候选新闻 → 过滤已读和下架内容后输出 Top-N。import pandas as pd from sklearn.metrics.pairwise import cosine_similarity def run_recommend(user_id, behavior_df, news_df, k20, n10): # 1. 行为数据做成评分矩阵空位填 0 matrix behavior_df.pivot_table( indexuser_id, columnsnews_id, valuesscore, fill_value0 ) # 2. 计算用户间的余弦相似度矩阵 sim_matrix pd.DataFrame( cosine_similarity(matrix), indexmatrix.index, columnsmatrix.index ) # 3. 取出和当前用户最像的 k 个用户 top_users sim_matrix.loc[user_id].drop(user_id).sort_values(ascendingFalse).head(k) # 4. 相似用户看过的新闻按相似度加权累加 scores {} for neighbor, sim_val in top_users.items(): for news_id, rating in matrix.loc[neighbor].items(): if rating 0: scores[news_id] scores.get(news_id, 0) sim_val * rating # 5. 过滤用户已读和已下架新闻 read_news behavior_df[behavior_df[user_id] user_id][news_id].tolist() valid_ids news_df[news_df[is_delete] 0][news_id].tolist() scores {nid: s for nid, s in scores.items() if nid not in read_news and nid in valid_ids} # 6. 按分数降序取前 n 条 top_n sorted(scores.items(), keylambda x: x[1], reverseTrue)[:n] return [news_id for news_id, _ in top_n]两个参数需要说明k 是相似用户个数默认 20太大推荐结果会偏大众化太小则容易过拟合到某个极端用户n 是最终返回的新闻条数前端一页展示 10 条是比较常规的设计。第 4 步的加权累加是 UserCF 的核心代码里用的是相似度 × 评分的原始累加没有除以相似度总和。严格写法应该除但在过滤了零值后两种写法对排序结果影响很小毕设里可以接受。2.3 离线跑批 在线缓存别把计算压在实时接口里还有一个容易踩坑的设计问题不要把上面这些计算放在每次请求里实时执行。用户量稍微上来一点pivot_table 和 cosine_similarity 都要花好几秒接口直接超时。常见做法是离线算好、在线查表。_CACHE {} def get_recommend_with_cache(user_id): if user_id in _CACHE: cached _CACHE[user_id] if time.time() - cached[ts] 600: return cached[data] result run_recommend(user_id, behavior_df, news_df) _CACHE[user_id] {ts: time.time(), data: result} return result这个缓存方案用 dict 就能实现600 秒过期。毕设阶段没必要上 Redis但你要在答辩时说清楚离线计算 内存缓存这个架构思路这比在上微服务有价值得多。整个推荐链路的执行路径是每天凌晨跑一次全量计算把结果写入 rec_result 表白天接口只查缓存和表响应时间控制在百毫秒级。这个设计在毕设里已经足够完整。3. 用户协同过滤(UserCF)给用户找一群口味相似的人UserCF 的思想一句话就能讲完物以类聚人以群分。如果你和另外几个用户点开的新闻高度重合那他们看过的你没看过的新闻就有很大概率也是你感兴趣的。这个逻辑在新闻场景里成立因为新闻消费是高频行为用户画像比电商更稳定。这一章从头到尾把 UserCF 的代码写出来每一步都说明白为什么这么做。3.1 把行为日志变成可以计算的评分矩阵协同过滤的输入是用户 × 新闻的矩阵行是用户列是新闻格子里的值就是前面映射出来的评分。pandas 的 pivot_table 是最直接的构造方式但要注意用户数和新闻数稍微一多这个矩阵会非常大而且绝大多数格子是 0是典型的稀疏矩阵。matrix behavior_df.pivot_table( indexuser_id, columnsnews_id, valuesscore, fill_value0 )这个操作把行为日志表直接变成了矩阵。fill_value0 表示没看过的新闻记 0 分。这里有个容易被忽视的点pivot_table 对同一对 (user_id, news_id) 出现多次时会做聚合默认是求平均。如果你希望用户看了两次就说明更喜欢可以在 pivot_table 里加 aggfuncsum把多次行为的分数累加。新闻场景里一个人重复点同一篇新闻的情况不多平均和求和的差异不算大但你要知道自己用了哪种聚合方式答辩时能解释得清。3.2 用余弦相似度衡量用户口味是否接近有了评分矩阵下一步就是算用户和用户之间的相似度。最常用的是余弦相似度把每个用户的评分看作一个向量向量越接近相似度越高。sklearn 已经封装好了公式直接调用即可。from sklearn.metrics.pairwise import cosine_similarity sim_matrix pd.DataFrame( cosine_similarity(matrix), indexmatrix.index, columnsmatrix.index )sim_matrix 是一个 N×N 的矩阵sim_matrix.loc[u1, u2] 就是用户 u1 和 u2 的相似度范围在 0 到 1 之间。为什么选余弦而不是皮尔逊因为新闻场景的行为数据是稀疏的 0/1 直到小数的混合分布皮尔逊相关系数要求向量有方差如果某个用户所有评分都是 1标准差为 0算出来就是 NaN。余弦相似度没有这个限制虽然它没做均值中心化但在稀疏场景下更稳定这是我在实践中反复对比后的选择。3.3 用相似用户的行为生成推荐列表核心步骤来了拿到目标用户最像的 k 个用户后把他们看过的新闻按相似度加权汇总。这一步要处理一个细节——最后要除以总相似度把分数归一化否则相似用户多的人天然占便宜。def user_based_recommend(user_id, matrix, sim_matrix, k20, n10): if user_id not in matrix.index: return [] # 目标用户已读的新闻 read_news matrix.loc[user_id][matrix.loc[user_id] 0].index.tolist() # 按相似度取前 k 个用户 top_users sim_matrix.loc[user_id].drop(user_id).sort_values(ascendingFalse).head(k) scores {} sim_sum {} for neighbor, sim_val in top_users.items(): neighbor_rated matrix.loc[neighbor] for news_id, rating in neighbor_rated[neighbor_rated 0].items(): if news_id in read_news: continue scores[news_id] scores.get(news_id, 0) sim_val * rating sim_sum[news_id] sim_sum.get(news_id, 0) sim_val # 归一化 scores {nid: scores[nid] / sim_sum[nid] for nid in scores} top_n sorted(scores.items(), keylambda x: x[1], reverseTrue)[:n] return [news_id for news_id, _ in top_n]这段代码里有两个细节值得解释。第一内层循环遍历了相似用户的所有评分项复杂度是 O(k×M)M 是新闻总数当 M 上万时这层循环会比较重但毕设规模完全可以接受如果后续数据量上来可以用矩阵乘法一次性算完。第二归一化那一步是必要的否则一个相似度高的用户贡献了大量新闻会主导整个推荐结果。3.4 UserCF 的两个必调参数UserCF 的调参核心就两个k 值和相似度阈值。参数建议范围影响k相似用户数15~30越大推荐越稳但越大众越小越个性化但也越容易跑偏相似度阈值0.1~0.3低于阈值的用户强迫视为不相似减少噪声n返回条数10~20由前端页面决定一般 10 条足够相似度阈值这个概念容易被忽略。不加阈值时哪怕相似度只有 0.02 的用户也会参与推荐这类低质量邻居会把结果带偏。我的习惯是先按相似度降序取前 k 个再筛掉相似度低于阈值的两者取交集。调参时要记住一个反直觉结论k 调大不一定让指标变好因为新闻场景里大众化内容会随着 k 增大被反复推荐precision10 反而可能下降。4. 物品协同过滤(ItemCF)与冷启动相似新闻怎么算新新闻怎么推UserCF 解决找相似的人ItemCF 解决找相似的新闻。在新闻推荐这个场景里ItemCF 往往比 UserCF 更实用原因很直接新闻时效性强你昨天看的新闻今天大概率不会再推但你看了 A所以给你推和 A 相似的 B这个逻辑永远成立而且便于解释。4.1 ItemCF 和 UserCF 在新闻场景的取舍做毕设时不要直接选一个先对比再决定权重。维度UserCFItemCF适用场景兴趣稳定、用户行为密集物品时效性强、用户兴趣变化快推荐结果解释难解释相似用户看了说服力弱容易解释因你看了 A 所以推荐 B冷启动问题新用户无法找到相似用户新新闻无法找到相似新闻计算复杂度用户数平方新闻数平方新闻场景表现推荐容易偏向热门能更好地找出长尾关联结论是新闻场景里 ItemCF 作为主推、UserCF 作为辅助混合是比较经典的组合。ItemCF 的另一个好处是支持实时更新——用户刚点了一条新闻立刻就能把和这条新闻相似的推给他这在新闻 App 里是刚需。4.2 基于共现矩阵计算物品相似度ItemCF 的相似度不是靠内容算出来的而是靠行为共现。核心思想是如果两篇新闻经常被同一个人看那它们就相似。数学上用一个矩阵乘法就能算完。import numpy as np def item_similarity(matrix): 输入: 用户-新闻评分矩阵, 行用户, 列新闻 输出: 新闻-新闻相似度矩阵 # 转置后做矩阵乘法, 得到新闻间的共现次数 # matrix.T 是 新闻×用户, matrix 是 用户×新闻 co_occur np.dot(matrix.T, matrix) # 对角线上是每篇新闻被多少个用户看过 popularity np.sqrt(np.diag(co_occur)) # 除以 popularity 的乘积, 消除热门新闻的偏置 sim co_occur / np.outer(popularity, popularity) return sim这个实现里有两个关键参数要理解。第一co_occur 矩阵的 [i][j] 位置存的是同时看过新闻 i 和新闻 j 的用户数用的是用户-评分矩阵的转置做点积这是一行代码算出共现矩阵的标准方式。第二co_occur 除以两个物品流行度的几何平均本质上是在做余弦相似度归一化。如果不做这一步热门新闻和所有新闻的共现次数都高会被错误地当成和谁都相似这是 ItemCF 最常见的翻车点。算完之后对每篇新闻只保留 Top-20 最相似的新闻存储成字典在推荐时直接查表。def build_item_sim_dict(sim_matrix, news_ids, top20): item_sim {} for i, nid in enumerate(news_ids): sim_scores sim_matrix[i] # 取前 top 个最相似的新闻(排除自己) top_indices np.argsort(-sim_scores)[1:top 1] item_sim[nid] [(news_ids[idx], sim_scores[idx]) for idx in top_indices] return item_simtop 参数表示每篇新闻最多保留多少个相似邻居。20 是经验值太小覆盖不够太大存储翻倍且增益有限。这里建议把新闻的 category 字段也存进字典推荐时优先在同类目里找——因为新闻跨类目共现的概率本来就低可以在相似度基础上再乘一个类目惩罚系数。4.3 时间衰减让昨天的热点让位于今天的热点新闻推荐的时效性是生命线。五小时前的热点和三天前的热点推荐优先级完全不同。如果直接用行为分数累加老新闻会靠历史累计分数霸榜新新闻永远排不进去。解决办法是引入时间衰减行为发生时间越久它对当前推荐的贡献越小。import math def time_decay_score(score, created_at, current_time, half_life24): score: 原始行为分 created_at: 行为发生时间 current_time: 当前时间 half_life: 半衰期, 单位小时, 默认 24 小时 hours_diff (current_time - created_at).total_seconds() / 3600 decay 0.5 ** (hours_diff / half_life) return score * decay半衰期设为 24 小时意思是这条行为在一天后权重降为原来的一半两天后降为四分之一。这个参数在新闻场景里建议设在 12~48 小时之间时政快讯类目设短一点深度报道类目设长一点。要注意的是时间衰减应该作用在用户行为分上再参与相似度计算和推荐打分而不是最后对结果做一次性惩罚。前者能把衰减融进模型后者只是对排序做修正效果差很多。4.4 新新闻冷启动没有行为数据时靠内容相似ItemCF 的硬伤是一篇新发布的新闻没有任何用户行为共现矩阵里它全为零永远无法被推荐。解决思路是把协同过滤暂时放一边用内容相似度顶上。对新新闻做 TF-IDF 特征和用户最近看过的新闻算内容相似度找出最像的那篇直接推给用户。from sklearn.feature_extraction.text import TfidfVectorizer from sklearn.metrics.pairwise import cosine_similarity import jieba def chinese_tokenizer(text): return jieba.lcut(text) # 把新闻标题摘要分词后转TF-IDF向量 vectorizer TfidfVectorizer(tokenizerchinese_tokenizer, max_features5000) tfidf_matrix vectorizer.fit_transform(news_df[title] news_df[summary]) # 和用户最近看过的新闻算相似度 def content_similar_recommend(user_news_id, n10): sim_scores cosine_similarity(tfidf_matrix[user_news_id], tfidf_matrix).flatten() top_idx np.argsort(-sim_scores)[1:n 1] return news_df.iloc[top_idx][news_id].tolist()这里有一个特别容易被坑的细节中文文本不能直接用 TfidfVectorizersklearn 不会自动分词。必须先用 jieba 分词把句子拆成词序列再向量化。max_features5000 是特征维度上限防止词表过大导致矩阵稀疏到没意义。内容相似度只是冷启动期的临时方案当新新闻积累了一定量的用户行为后就应该走回 ItemCF 的正常通道。判断标准可以简单定成行为数量大于 10 条就加入协同过滤的离线任务。4.5 UserCF 和 ItemCF 的代码复用技巧两个算法看起来是两套逻辑但本质上完全对称UserCF 是用户-用户相似度 × 用户对新闻的评分ItemCF 是新闻-新闻相似度 × 用户对相似新闻的评分。我一般会抽一个公共计算函数避免两份代码重复维护。def collaborative_filter(matrix, target_idx, sim_matrix, k20, n10): 统一实现 UserCF 和 ItemCF UserCF: matrix 是 用户×新闻, target 是用户, sim 是用户相似度 ItemCF: matrix 是 用户×新闻.T, target 是新闻, sim 是新闻相似度 scores {} sim_sum {} # 取和目标最相似的 k 个邻居 neighbors sim_matrix[target_idx].copy() neighbors[target_idx] -1 top_neighbors neighbors.argsort()[-k:] for nei_idx in top_neighbors: sim_val sim_matrix[target_idx, nei_idx] if sim_val 0: continue rated_items np.where(matrix[nei_idx] 0)[0] for item in rated_items: if matrix[target_idx, item] 0: continue scores[item] scores.get(item, 0) sim_val * matrix[nei_idx, item] sim_sum[item] sim_sum.get(item, 0) sim_val scores {i: scores[i] / sim_sum[i] for i in scores if sim_sum[i] 0} return sorted(scores.items(), keylambda x: x[1], reverseTrue)[:n]numpy 化和抽公共函数之后两个算法共用一个函数体区别只在传入的矩阵和相似度矩阵不同。这个设计在答辩时是个亮点——说明你不是把两个算法死板地各写一遍而是理解到了它们内在的对称性。5. 避坑五个最容易翻车的地方这一章把我在实际调试和带毕设过程中遇到的高频问题整理成五条每条都是现象 → 原因 → 解决的结构直接照着检查你自己的代码。5.1 现象推荐结果永远是大热门用户画像等于没做不管给哪个用户推荐出来的都是全站点击量最高的那几条新闻个性化完全失效。原因多半出在评分映射和相似度归一化上如果所有行为的 score 都设成 1那热门新闻因为被很多人看过在加权累加时天然分数最高另一个常见原因是 ItemCF 的共现矩阵没有除以流行度导致热门新闻和所有新闻都相似。解决办法是双管齐下第一行为评分拉开差距点击 1、收藏 2、转发 3第二计算物品相似度时用余弦归一化。如果做完这两步还是偏向热门可以考虑在最终排序时显式降低热门新闻权重比如给新闻加一个 content_score整体排序改为 ranking_score rec_score * pow(content_score, 0.5)。5.2 现象相似度矩阵内存直接爆掉几千个用户、几万篇新闻时构建出来的稠密相似度矩阵能轻松占掉几个 G 内存。原因很简单N×N 的 numpy 矩阵float 类型每个元素 8 字节1 万用户就是一个 800MB 的矩阵。解决办法有三个按推荐程度排序第一用 scipy.sparse.csr_matrix 存稀疏矩阵只保留非零元素第二相似度矩阵只保留每行 Top-K 的值其余都归零直接截断存储第三如果连截断后的矩阵都嫌大就只在离线任务里计算算完写入数据库运行时不加载相似度矩阵只加载每篇新闻的 Top-20 相似列表。毕设场景建议直接选第三种又简单又稳。5.3 现象新新闻一条都推不出去协同过滤的训练数据来自历史行为新发布的新闻没有任何行为在相似度矩阵里有如不存在。用 ItemCF 推荐时新新闻永远不可能出现在结果里。这不是 bug是冷启动问题的直接体现。解决办法是维护两条推荐通路一条走协同过滤处理有行为的老新闻另一条走内容相似基于 TF-IDF 把新新闻和用户近期看过的新闻关联起来。我把两条通路的结果做个简单的混合有行为的新新闻用 ItemCF 分数无行为的新新闻用内容相似度分数两者最后合并排序。5.4 现象算出来的皮尔逊相关系数全是 NaN用 scipy.stats.pearsonr 或 pandas 的 corr(methodpearson) 计算用户相似度时结果矩阵全是 NaN。原因是用户的评分向量没有方差——新闻场景里很多人所有行为都是点击score 全为 1标准差等于 0皮尔逊公式的分母塌了。这个坑在新闻推荐里几乎是必踩的因为不像电商有 1~5 星评分新闻行为的区分度天然很低。解决方法是换用余弦相似度它不做均值中心化不要求方差非零或者把评分映射改成时长分 行为分的组合比如阅读超过 30 秒的点击记 1.5短点击记 0.5人为制造方差。5.5 现象答辩时说不清推荐效果到底怎么样很多人的毕设做到最后演示能跑、界面能看但导师问你的推荐准确率是多少时只能拿出几个推荐结果截图。原因是在开发过程中只关注了能不能推出东西从没想过怎么量化。解决办法是留出评测集按时间切分前 7 天的行为做训练第 8 天的真实点击做测试计算 precision10、recall10 和覆盖率。指标不用高但要有而且要能说出我的 baseline 是什么、调了什么参数之后涨了多少。这个细节在答辩时的价值比你多写一个没用的接口大得多。6. 混合加权与离线评估让推荐效果在答辩里能说清楚单独跑 UserCF 或 ItemCF 都有各自的死角混合是毕设收尾的常见做法。我的混合公式很简单最终分数 0.4 × UserCF 分 0.4 × ItemCF 分 0.2 × 热度分。热度分用新闻最近 24 小时的点击对数平滑能保证新用户和冷门时刻也有东西可推。权重不建议固定死给个直观的调节方向如果你发现推荐结果太大众就把 UserCF 权重调大如果发现推荐结果太分散、解释性差就把 ItemCF 权重调大。混合之后还有一个好处UserCF 和 ItemCF 的交集通常就是用户最可能点的那一篇答辩时可以把多路召回 加权融合作为系统设计的亮点来讲。评估代码不要到最后才写从一开始就要留出口子。按时间切分是为了保证训练集里没有未来信息这一点在新闻场景里尤其重要它也是答辩时能讲清楚的方法论。def precision_at_k(train, test, recommend_func, k10): hits 0 total 0 for user_id, actual_list in test.items(): rec_list recommend_func(user_id) hits len(set(rec_list[:k]) set(actual_list)) total 1 return hits / (total * k)演示的时候有一个小技巧非常管用挑一个行为记录多的用户在 PPT 上展示他的历史点击再展示推荐结果然后讲清楚这个用户点过 A、B、C系统找了和他最像的 D 用户D 用户看过 E、F所以把 E、F 推荐给了他。这套可解释的推荐路径比任何指标都更能让答辩老师相信你真的理解了推荐系统。我自己带毕设时一直坚持把能讲明白为什么推荐放在指标好看前面因为推荐系统本身就带一点玄学成分能解释清楚的系统才是不敢糊弄的。希望帮到你。本文还有配套的精品资源点击获取