简介这是一份以Python实现的商品推荐系统完整项目包面向希望掌握推荐算法落地流程的学生、数据分析与机器学习初学者。项目基于约15万用户、12万商品及对应特征的脱敏数据集完整覆盖数据加载、特征工程、基于内容推荐、协同过滤与矩阵分解SVD/ALS等核心环节并包含模型训练评估与参数调优思路适合用作课程设计或推荐系统入门实践。资源共7个文件以4个Python脚本为主配合2个二进制数据文件和1个Markdown说明文档整体约37.37MB目录清晰便于对照学习。当前已有414人学习下载说明该方案具有一定参考价值。通过阅读源码与文档可快速复用数据读取、评分预测、排序召回等模块理解从数据清洗到最终推荐结果生成的完整链路。1. 商品推荐系统不是猜你喜欢是替你找出“和你像的人”商品推荐系统这个词听起来像是“AI猜你喜欢”但真要把一套能上线的推荐逻辑用 Python 落地核心思路反而是另一件事找出和你行为最像的一群人或者和你买过的商品最像的一批商品然后从里面挑出你还没见过的。这个思路叫协同过滤也是目前中小型电商、内容社区、线下零售做推荐时性价比最高的起点。Python 在这个方向上的优势不是算法多高级而是 pandas、numpy、scikit-learn 这些库把数据清洗、相似度计算、离线评估串成了一条很顺的流水线一个能跑通最小闭环的推荐系统几百行代码就能搭出来。这篇笔记适合刚接触推荐系统的 Python 开发者也适合已经在做数据分析、想给业务加一个“猜你喜欢”模块的工程师。我会把从原始日志到最终推荐列表的完整路径拆开讲连踩过的坑一起说清楚。2. 选型先行三种推荐算法的适用边界别一上来就写代码2.1 三类主流算法的适用边界什么时候别用协同过滤商品推荐系统的算法选型决定了后面所有代码的结构。最常见的三类是基于用户的协同过滤UserCF、基于物品的协同过滤ItemCF、基于内容的推荐Content-Based。很多初学者一上来就写 UserCF 的相似度公式但对业务场景不加判断结果要么冷启动阶段效果差要么计算量爆炸。先给结论如果是小规模商品池几千到几万个 SKU优先 ItemCF如果是用户量远大于商品量且用户行为稀疏UserCF 能找出跨品类的兴趣迁移如果是新商品频繁上架、行为数据少Content-Based 的标签匹配兜底但它的天花板很低因为推荐结果永远在用户已有的偏好标签里打转无法发现新兴趣。基于用户的协同过滤核心假设是“和你购买行为相似的人你也会喜欢他买过的东西”。适合的场景是用户量不大比如几千个种子用户、用户兴趣有群体性比如同一批人既买婴儿奶粉又买辅食机。但它的致命问题是计算复杂度随用户数平方增长而且用户兴趣漂移后相似度矩阵要频繁重算。基于物品的协同过滤核心假设是“一个用户买过的商品和他没买过的商品如果经常被同一批人购买那这两个商品相似”。注意这里算的是商品间的相似度不是内容标签的相似度而是“被同一用户购买”的共现关系。这在电商场景里比 UserCF 稳定得多因为商品之间的共现关系相对固定可以离线计算相似度矩阵线上只做查表。基于内容的推荐则是把商品打上标签类目、品牌、价格带、颜色然后根据用户历史购买过的商品标签找出同标签的新品。它对新品友好但没有惊喜度。我一般会把它做成一个召回通道和协同过滤的结果做混合而不是单独使用。选型标准用户增长率大于商品增长率用 ItemCF商品上新极快、生命周期短用 Content-Based 兜底用户量少且群体特征明显UserCF 还能撑得住用户行为数据稀疏到每个用户不足 20 条行为协同过滤基本失效这时候用热门商品打底而不是强行上算法。2.2 熟悉度和惊喜度的权衡为什么 ItemCF 在商品商城更主流选型的另一个维度是“熟悉度 vs 惊喜度”。UserCF 天然适合做惊喜推荐——因为你的相似用户可能买了你完全没想到的商品类目ItemCF 则偏向推荐和已购商品相似的“安全”选项转化率往往更高但推荐列表看起来不够新鲜。这也是为什么实际商业场景里ItemCF 的使用频率远高于 UserCF。以电商商城为例用户的每个点击、加购、购买行为都构成一个共现对商品间的相似关系本质上来自用户行为的统计规律而不是内容属性。用 Python 做 ItemCF 时你只需要一张行为表用户 ID、商品 ID、行为类型、时间戳就能算出商品共现矩阵代码量最小而且效果在数据量上来后表现稳定。再补一个容易忽略的细节行为类型要区分权重。购买 加购 点击这个权重比例大概在 5 : 3 : 1如果日志里有收藏行为可以让收藏权重比加购略低比如 2.5。权重的选择直接影响相似度矩阵的质量。你可以在离线评估阶段对比不同权重的效果而不是凭感觉拍一个数。注意这里说的权重不是给算法公式加的而是在构造“用户-物品评分矩阵”时把每种行为的次数换算成分数。比如同一用户对同一商品点击了 5 次、加购 1 次、购买 1 次最终评分 5×1 3 5 13。3. 数据准备从原始日志到评分矩阵Python 怎么搭这条流水线3.1 把用户行为日志清洗成标准评分表pandas 操作与时间衰减推荐系统第一步不是写算法而是把业务日志清洗成一个标准结构用户 ID、商品 ID、行为类型、行为时间。实际生产里的日志通常存在数据仓库里字段可能叫 member_id、goods_id、action_type、create_time还可能混着重复数据、缺失数据和爬虫刷出来的垃圾流量。我一般用 pandas 读数据先做三件事去重、过滤异常用户、时间对齐。去重用drop_duplicates这里有个坑同一用户同一商品同一行为在同一秒出现两次可能是前端重复埋点直接去重但用户在不同时间点对同一商品产生行为这是正常的兴趣信号不能去重。import pandas as pd # 读原始日志假设字段为user_id, item_id, action, ts df pd.read_csv(user_behavior_log.csv, parse_dates[ts]) # 去重同一用户同一商品同一行为在同一秒内视为重复埋点 df df.drop_duplicates(subset[user_id, item_id, action, ts]) # 过滤行为数少于 5 条的用户信息量不足保留反而增加噪声 user_action_cnt df.groupby(user_id)[item_id].count() valid_users user_action_cnt[user_action_cnt 5].index df df[df[user_id].isin(valid_users)] # 过滤被购买/点击次数极低的长尾商品行为数 3可以暂时剔除 item_action_cnt df.groupby(item_id)[user_id].count() valid_items item_action_cnt[item_action_cnt 3].index df df[df[item_id].isin(valid_items)]这段代码做了三层清洗。第一层去重解决埋点重复第二层过滤用户是因为行为数极少的用户无法支撑协同过滤的相似度计算保留他们只会让矩阵更稀疏第三层过滤长尾商品是因为只出现过一两次的商品没法和其他商品形成可靠的共现统计。清洗之后要构造评分表。这里用到时间衰减用户三个月前的购买和三天前的购买对当前兴趣的指示意义完全不同。常见做法是指数衰减权重乘以 exp(-λ × 时间差天数)λ 一般取 0.01 到 0.05具体值可以用一个小验证集测试。import numpy as np now df[ts].max() def behavior_score(row): # 行为基础权重购买5加购3收藏2.5点击1 base_weight {buy: 5.0, cart: 3.0, fav: 2.5, click: 1.0} # 时间衰减间隔天数越大权重越小 days_diff (now - row[ts]).days decay np.exp(-0.02 * max(days_diff, 0)) return base_weight.get(row[action], 1.0) * decay df[score] df.apply(behavior_score, axis1) # 相同用户对相同商品的多次行为分数累加 rating df.groupby([user_id, item_id])[score].sum().reset_index()这段代码是指定行为权重和时间衰减的实现。base_weight的取值来自业务经验你可以根据数据特点调整np.exp(-0.02 * days_diff)让 30 天前的行为权重衰减到 0.55 左右90 天前的衰减到 0.17这是比较常用的节奏。如果商品类目是快消品可以调大到 0.05如果是耐用品衰减可以更慢。3.2 从长表到用户-物品矩阵python 数组切片与稀疏存储上一步得到的是一个三列长表user_id, item_id, score要用于相似度计算需要把它转成标准的用户-物品评分矩阵行是用户列是商品值是分数。这个转换用 pandas 的pivot_table就够了但要注意如果直接转成稠密 DataFrame用户量和商品量以万计的时候内存会瞬间爆掉。一个用户 1 万、商品 1 万稠密矩阵就是 1 亿个格子float64 占 800MB这还只是单个矩阵。所以实际做法是转成 scipy 的稀疏矩阵格式CSR 或 COO只存有值的位置。from scipy.sparse import csr_matrix # 给用户和商品编码成 0-based 索引 user_ids rating[user_id].astype(category) item_ids rating[item_id].astype(category) row user_ids.cat.codes.values col item_ids.cat.codes.values data rating[score].values # 构建稀疏评分矩阵shape (用户数, 商品数) rating_matrix csr_matrix((data, (row, col)), shape(user_ids.cat.categories.size, item_ids.cat.categories.size))用稀疏矩阵后相同数据的内存占用可以降到原来的 1% 以内。这里嵌一个细节csr_matrix((data, (row, col)))中如果同一个 (row, col) 出现两次scipy 会自动求和所以前面的groupby.sum()可以省掉直接在构建时合并。这会减少一次全表聚合计算。矩阵构建完之后要顺手存一份 user_id、item_id 和编码索引的映射表因为后续算出来的相似度结果都是索引编号需要映射回原始 ID 才能输出。user_encoder dict(zip(user_ids.cat.categories.values, range(user_ids.cat.categories.size))) item_encoder dict(zip(item_ids.cat.categories.values, range(item_ids.cat.categories.size))) item_decoder {v: k for k, v in item_encoder.items()}4. 协同过滤核心实现评分预测与 TopN 推荐生成4.1 基于用户的协同过滤找相似用户并预测评分选定了 UserCF 场景后实现分为三步计算用户相似度矩阵、为每个用户找出 TopK 相似用户、用相似用户的评分加权预测目标物品分数。用户相似度的计算常见做法是余弦相似度但在商品评分场景里用户对商品的评分普遍偏少直接用原始分数算余弦相似度会被“用户评分尺度不一致”干扰。更稳的做法是均值中心化对每个用户的评分减去该用户所有评分的均值再算余弦相似度。这样处理后相似度反映的是用户间的兴趣结构而不是评分绝对值的高低。from sklearn.metrics.pairwise import cosine_similarity # 对每个用户的评分做均值中心化消除评分尺度差异 user_mean rating_matrix.mean(axis1) rating_matrix_centered rating_matrix - user_mean # 计算用户间余弦相似度结果是一个 N x N 矩阵 user_sim cosine_similarity(rating_matrix_centered, dense_outputFalse) user_sim.setdiag(0) # 自己对自己的相似度置 0避免自推荐cosine_similarity支持稀疏矩阵输入dense_outputFalse让结果保持为稀疏矩阵。把对角线置 0 是必要的一步因为不置 0 的话用相似度做加权平均时用户自身的评分会对预测结果产生主导性影响推荐列表会和用户历史购买高度重合等于没有推荐。预测评分的公式是预测用户 u 对商品 i 的评分 用户 u 的评分均值 与 u 最相似的 K 个用户对 i 的加权评分偏离和。这里要特别处理K 个相似用户可能有一部分没买过 i此时他们的评分就是缺失值参与加权前需要填充为用户自身均值否则加权结果会被无意义地拉低。import numpy as np K 10 # 取相似度最高的 K 个用户 def predict_usercf(user_idx, item_idx, KK): # 取与 user_idx 相似度最高的 K 个用户索引 sim_row user_sim.getrow(user_idx).toarray().ravel() top_k_idx np.argsort(sim_row)[::-1][:K] # 如果用户没有相似邻居退回全局均值 if sim_row[top_k_idx[0]] 0: return user_mean[user_idx, 0] # 取这 K 个用户对 item_idx 的评分可能是 0表示没买过 neighbor_ratings rating_matrix[top_k_idx, item_idx].toarray().ravel() neighbor_sims sim_row[top_k_idx] # 计算加权评分分子 邻居评分偏移 x 相似度分母 相似度之和 valid_mask neighbor_ratings 0 if not valid_mask.any(): return user_mean[user_idx, 0] numerator (neighbor_ratings[valid_mask] - user_mean[top_k_idx[valid_mask], 0]).ravel() weighted_sum (numerator * neighbor_sims[valid_mask]).sum() sim_sum neighbor_sims[valid_mask].sum() return user_mean[user_idx, 0] weighted_sum / sim_sum这段代码的边界检查有三处相似度全为 0 时回退到全局均值K 个邻居对目标商品都没有行为时回退到该用户均值有效邻居数不足 K 时只对有行为的邻居加权。这些分支在实际数据里都会遇到如果不写预测分数会严重偏向某个固定值离线评估指标看起来还行线上一测就翻车。4.2 基于物品的协同过滤离线算好相似度矩阵线上只做查表ItemCF 是生产环境里用得最多的方案因为它把计算拆成了离线阶段和在线阶段离线算商品相似度矩阵线上根据用户历史行为查相似商品再合并打分。Python 实现的重点是共现矩阵的构建。商品相似度的计算核心是如果两个商品被很多用户同时购买过它们的相似度就高。用共现矩阵来表达就是item_sim[i][j] 同时购买 i 和 j 的用户数 / (购买 i 的用户数 × 购买 j 的用户数开根号)这是修正后的余弦相似度能消除热门商品对相似度的干扰。# 基于用户-物品评分矩阵计算商品相似度 # 思路先转置成物品-用户矩阵再计算列余弦相似度 item_rating_matrix rating_matrix.T # shape (商品数, 用户数) # 物品相似度矩阵shape (商品数, 商品数) item_sim cosine_similarity(item_rating_matrix, dense_outputFalse) item_sim.setdiag(0) # 商品自己与自己的相似度不算 # 归一化每个商品对相似向量做归一化便于后续分数合并 row_sum item_sim.sum(axis1) item_sim_normalized item_sim.multiply(1.0 / row_sum)这里用cosine_similarity直接算物品向量的余弦相似度等效于修正余弦相似度。multiply(1.0 / row_sum)是逐行归一化作用是让每个商品的相似度向量之和为 1这样在合并用户历史商品分数时不会因为某个商品的相似邻居特别多而主导结果。线上推荐时用户历史行为商品集合是已知的只需要把这些商品在相似度矩阵中的邻居累加打分。def recommend_itemcf(user_idx, user_hist_items, topn20): # user_hist_items: 用户历史有行为的商品索引列表 scores {} for item_idx in user_hist_items: # 取该商品的相似商品及其相似度 sim_items item_sim_normalized[item_idx].toarray().ravel() # 按相似度从高到低取前 50 个相似商品 cand_indices np.argsort(sim_items)[::-1][:50] for cand_idx in cand_indices: if cand_idx in user_hist_items: continue # 排除用户已购买过的商品 # 得分累加相似度 x 用户对该历史商品的评分 weight rating_matrix[user_idx, item_idx] if weight 0: scores[cand_idx] scores.get(cand_idx, 0) sim_items[cand_idx] * weight # 按得分排序返回 TopN 商品索引 ranked sorted(scores.items(), keylambda x: x[1], reverseTrue)[:topn] return [item_decoder[idx] for idx, _ in ranked]这段代码的核心参数有两处每个历史商品取前 50 个相似邻居以及累加时用用户原始评分做权重。50 这个数字不是越大越好太大了会把弱相关商品带进来导致推荐列表发散太小了候选集不够覆盖率低。实际调参时可以从 20 试到 100看离线指标变化。注意代码里的 scores 累加没有做归一化。如果用户历史行为有 50 个商品和只有 3 个商品的情况下分数绝对值会差很多。生产环境一般在累加结果上除以用户历史行为数或者对最终分数做一次 log 变换让长行为用户的推荐列表不至于被短行为用户淹没。5. 推荐系统避坑指南五个让模型翻车的经典问题与排查方法5.1 数据稀疏导致相似度失真现象是相似度矩阵几乎全为 0现象离线评估时推荐结果的命中率低得离谱查看相似度矩阵发现大部分值是 0 或接近 0少数几个商品撑起了所有推荐。原因用户行为数据太少尤其是只有点击没有购买的情况下物品之间的共现次数极少余弦相似度分子趋近于 0。另一个原因是清洗阶段把行为数少的用户全过滤了导致剩余用户的平均行为数也不高。解决先把清洗门槛下调行为数少于 5 的用户保留到 3 条。再做行为权重的调整把点击的权重从 1.0 提到 1.5因为点击行为虽然弱于购买但数量大对共现统计的贡献不可忽视。最后补一个兜底策略对相似度为 0 的商品对用类目标签做内容相似度替代作为冷启动的临时方案。5.2 相似度未归一化导致热门商品霸榜推荐列表永远是大路货现象推荐的 TopN 商品基本都是爆款、头部商品长尾商品几乎没有机会出现个性化程度低。原因热门商品被大量用户购买和其他商品的共现次数天然高余弦相似度里哪怕做好了分母惩罚热门商品的绝对得分在汇总阶段仍然占优。尤其在 ItemCF 的累加打分里热门商品的相似邻居多最终分数容易排到前面。解决有两个常用手段。一是在累加阶段对商品相似度做 MinMax 归一化把每个商品的相似度向量压缩到 [0, 1] 区间减少尺度过大的影响二是把点击行为权重调低因为点击行为贡献了最多的共现对而点击对兴趣的指示性弱。5.3 用户评分尺度不一致导致相似度计算偏斜高评用户主导结果现象UserCF 的相似度矩阵中某些用户和大量用户都高度相似但这些“高相似用户”其实只是喜欢给所有商品打高分。原因不同用户的评分习惯不一样有人习惯给 4 分以上有人给 2-3 分。如果不做均值中心化余弦相似度会被评分绝对值主导结构相似性被掩盖。解决实现代码里已经做了中心化——用户评分减去用户均值再算相似度。如果你跳过这步直接用原始矩阵算结果一定会偏。这也是为什么前面的实现里专门有一行rating_matrix_centered rating_matrix - user_mean。5.4 时间窗口设置不合理推荐了用户三个月前感兴趣的旧品现象线上推荐结果里用户早就买完、不再需要的东西反复出现点击率持续下降。原因评分矩阵构造时没有做时间衰减或者衰减系数 λ 太小三个月前的行为权重和昨天的行为几乎一样。对快消品来说三个月前买过的东西基本已经消费完了。解决把衰减系数从 0.02 上调到 0.05同时设置硬性时间窗口只取最近 90 天的行为数据。对耐用品类目家电、家具这类商品的购买间隔很长时间衰减可以放宽到 180 天。核心是让行为新鲜度参与评分而不是全部丢进模型。5.5 新用户和新商品没法推荐冷启动直接抛异常或返回空列表现象新注册用户没有行为数据新上架商品没有共现记录推荐接口拿到这类用户/商品时直接返回空列表前端展示空白区域。原因协同过滤算法本身依赖历史行为没有行为就无法计算相似度。如果代码里没有兜底逻辑评分预测函数在邻居全为 0 时返回的只是默认值而不是有意义的新品推荐。解决补两层兜底逻辑。一层是用户侧新用户用热门商品榜单填充推荐位按销量或浏览量排序取 TopN另一层是商品侧新商品没有共现记录时用类目相同且价格带相近的商品相似度作为过渡这类内容相似度可以用商品属性表离线算好。等新商品积累到一定行为量比如 20 个用户购买再切换到协同过滤通道。6. 混合推荐与离线评估用命中率验证你的系统值不值得上线混合推荐不复杂常见做法是加权融合ItemCF 的分数、Content-Based 的分数、热门兜底的分数各占一个权重相加后按总分排序。我一般会用 0.5 : 0.3 : 0.2 作为初始值跑完离线评估再调。融合之前三个通道的分数必须做归一化到 [0, 1] 区间否则分数高的通道永远霸占前排。评估这一个环节很多人忽略。评估指标不推荐用 RMSE因为推荐系统的业务目标不是预测评分准不准而是用户会不会点你推的东西。更合适的指标是 TopN 命中率把用户行为按时间切成前 80% 和后 20%用前 80% 训练出推荐列表看后 20% 里有多少商品出现在推荐列表中除以用户的总购买数得到命中率。这个值做到 0.03-0.05 已经算可用内容平台可以做到 0.1 以上电商会因为行为稀疏命中率更低。def evaluate_hit_rate(train_matrix, test_set, recommend_func, topn20): hit 0 total 0 for user_idx, test_items in test_set.items(): recs recommend_func(user_idx, topntopn) # 只评估测试集中有行为的用户 if not test_items: continue rec_set set(recs) test_set_items set(test_items) hit len(rec_set test_set_items) total len(test_set_items) return hit / total这段代码的核心在于 test_set 的构造每个用户的后 20% 购买记录。注意如果用户行为数很少后 20% 可能只有一条记录命中率波动会很大所以最好只对行为数大于等于 10 的用户做评估。我自己的习惯是先在离线评估上把命中率从 0.01 提到 0.04再小流量上线做 A/B对比 CTR 和人均推荐点击数。如果离线指标提升但线上没有变化大概率是数据时间窗口、行为权重这些细节在线上环境里表现不一致导致的。最后补一句要记住的经验商品推荐系统上线之后真正的维护工作不是调模型而是监控行为数据的分布变化——一旦用户行为模式变了离线算好的相似度矩阵就会失效需要定期重算。这个周期性重算的任务用 Python 的 cron 或 Airflow 调度就行。希望这些实现细节和踩坑记录能帮你少走弯路。本文还有配套的精品资源点击获取