企业官网建设流程全解析

简介：这是一份以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, axis=1) # 相同用户对相同商品的多次行为分数累加 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(axis=1) rating_matrix_centered = rating_matrix - user_mean # 计算用户间余弦相似度，结果是一个 N x N 矩阵 user_sim = cosine_similarity(rating_matrix_centered, dense_output=False) user_sim.setdiag(0) # 自己对自己的相似度置 0，避免自推荐

cosine_similarity支持稀疏矩阵输入，dense_output=False让结果保持为稀疏矩阵。把对角线置 0 是必要的一步，因为不置 0 的话，用相似度做加权平均时，用户自身的评分会对预测结果产生主导性影响，推荐列表会和用户历史购买高度重合，等于没有推荐。

预测评分的公式是：预测用户 u 对商品 i 的评分 = 用户 u 的评分均值 + 与 u 最相似的 K 个用户对 i 的加权评分偏离和。这里要特别处理：K 个相似用户可能有一部分没买过 i，此时他们的评分就是缺失值，参与加权前需要填充为用户自身均值，否则加权结果会被无意义地拉低。

import numpy as np K = 10 # 取相似度最高的 K 个用户 def predict_usercf(user_idx, item_idx, K=K): # 取与 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_output=False) item_sim.setdiag(0) # 商品自己与自己的相似度不算 # 归一化：每个商品对相似向量做归一化，便于后续分数合并 row_sum = item_sim.sum(axis=1) 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, topn=20): # 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(), key=lambda x: x[1], reverse=True)[: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, topn=20): hit = 0 total = 0 for user_idx, test_items in test_set.items(): recs = recommend_func(user_idx, topn=topn) # 只评估测试集中有行为的用户 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 调度就行。希望这些实现细节和踩坑记录能帮你少走弯路。

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