给你一个真实到不能再真实的业务场景用户正盯着一台投影仪的详情页你的推荐位就在他正下方。如果这时候跑找一群和他口味相似的人看看他们买了什么的UserCF逻辑会立刻撞上三堵墙相似用户要现算、推荐理由很难解释、结果被活跃用户带偏。而换成因为这台投影仪经常和高清线、幕布、音响一起出现在购物车里所以把这几样递过去的基于物品的协同过滤Item-Based Collaborative Filtering整个逻辑瞬间干净、可解释、还能离线缓存。这也正是很多电商详情页看了又看搭配购买区域背后的主力算法。这篇文章从零开始带你把Item-Based CF完整走一遍不绕弯子。先讲清楚为什么在电商、视频点播这类场景里物品相似比用户相似更划算然后对比余弦相似度、修正余弦相似度、皮尔逊相关系数三套公式的差异接着给出可以直接复制运行的Python实现再用一套小规模数据做离线评测最后聊聊真正上线时那些坑——稀疏矩阵、冷启动、增量更新、线上一致性。无论你是刚入门推荐系统的学生还是被业务逼着下周就要上线一个推荐位的工程师这套流程都能直接抄作业。1. 为什么物品相似比用户相似更像一门生意1.1 行为共现比内容语义更接近真实需求先建立一个关键认知ItemCF里的物品相似并不是内容上的相似而是行为上的共现相似。投影仪和HDMI线在商品分类里可能隔了三个类目但在成百上千个用户的购物车里它们反复同时出现。这种由群体行为沉淀出来的搭配感远比内容标签算出来的语义相似更贴近真实购买决策。道理也很简单用户购物车里的组合是用户用真金白银投出来的票。一个人同时买投影仪和幕布可能是做了功课几百个人同时买就说明这两样东西之间存在某种稳定的消费关联。ItemCF要做的就是把这个群体共现信号量化成一个相似度数字然后形成看了A就推荐B的链路。举个具体例子。某个用户刚加购了一台4K投影仪页面下方最合适推荐的绝不是另一台参数相近的投影仪——那更像同类目导购也不能完全说错但如果他同时还需要HDMI线、壁挂支架、抗光幕布这些不同类却强共现的物品才是真正的增量。内容推荐做不到这件事ItemCF天生就是干这个的。1.2 UserCF和ItemCF的适用边界一张表说清楚很多同学刚学推荐系统时习惯从UserCF入手因为人以群分这个直觉特别顺。但落到业务约束上差别非常明显我把关键维度整理成了下表对比维度UserCF基于用户的协同过滤ItemCF基于物品的协同过滤计算规模用户-用户相似度矩阵复杂度近似O(U²)物品-物品相似度矩阵复杂度近似O(I²)规模量级用户量动辄上亿矩阵难以全量维护物品量通常百万级全量计算更可行更新频率用户兴趣变化快需高频捕捉物品关系稳定离线低频更新即可推荐结果解释和你相似的人也在看X解释依赖用户聚类因为你看了A所以推荐B解释成本极低热点发现能力强新内容出现后靠用户网络快速扩散弱新物品没有行为积累前无法参与计算典型场景新闻资讯、社区内容、热点短视频电商、视频点播、阅读书架、音乐歌单这里最重要的落点是U和I的量级差。一家电商平台的SPU标准产品单元可能只有百万级但注册用户是亿级。UserCF要维护的是全体用户两两之间的关系存储和计算压力会随用户规模爆炸而ItemCF把计算量转移到物品维虽然也要面对百万级物品对的组合但配合只保留TopK邻居的策略工程上完全可控。1.3 和基于内容的推荐怎么分工还需要划清另一条边界ItemCF和Content-Based基于内容的推荐经常被混为一谈其实逻辑完全不同。基于内容推荐靠的是物品自身的属性——标题、类目、标签、品牌、文本向量——两件商品只要描述相似就算相似。ItemCF则完全不管物品长什么样只看用户行为矩阵里的共现关系。这两者不是竞争关系而是天然的接力关系新商品上架当天行为数为零ItemCF完全没有信号这时候用内容相似做打底等商品积累了几百个行为再切换到行为相似效果会显著变好。我的实践经验是内容相似负责冷启动行为相似负责精细排序两者混合往往比单用任何一种都稳。值得注意的是纯ItemCF在冷启动上存在明显短板所以我在后面第5章会专门讲工程上的兜底策略。2. 相似度算法的选型余弦、修正余弦与皮尔逊2.1 三种公式的数学含义与直觉差异ItemCF的核心步骤是算物品之间的相似度最常见的候选公式有三个余弦相似度、修正余弦相似度、皮尔逊相关系数。公式放在代码里都能跑但选错了一个推荐效果可能差出一大截。余弦相似度把每个物品表示成一个由所有用户的评分构成的向量计算两个向量的夹角余弦值。公式是cos(i,j)等于两向量点积除以模长之积。它衡量的是方向一致性不关心评分的绝对高低。修正余弦相似度先对每个用户的评分离散值减去该用户的平均打分得到一个中心化后的评分矩阵再在这个矩阵上计算余弦相似度。它的核心动机是消除用户评分尺度的差异。皮尔逊相关系数本质上是对物品维度的评分做中心化后计算相关系数。在UserCF中很常用在ItemCF中用得相对少但理解它有助于厘清对谁做中心化这个关键问题。为什么必须强调中心化对象继续往下看。2.2 修正余弦为什么是ItemCF的默认选择我见过太多初学者直接用原始余弦算物品相似结果效果奇差还不明所以。问题出在用户的评分尺度上。假设有三个用户对两部电影打分用户甲打分宽松喜欢就给4分、5分用户乙打分严格同样很喜欢一部电影也只给2分、3分。如果拿原始评分做余弦甲的向量数值普遍大乙的向量数值普遍小两者夹角会被拉大相似度被低估。但如果我们先减去每个用户自己的平均分甲的4分变成了正的偏差乙的3分也变成了正的偏差两人的偏好方向反而会变得一致。这就是修正余弦的动机按用户均值中心化之后保留的不再是打分的绝对水平而是这个物品在这个用户心中的相对位置。推荐系统真正关心的正是相对偏好而不是绝对分数。因此在大多数显式评分和隐式反馈场景里物品相似度计算我都会默认用修正余弦。2.3 用一组手算例子看穿公式差异为了让你彻底分清我把三种公式放在同一个最简单例子里两个物品i和j三个用户对它们的评分如下。用户对物品i的评分对物品j的评分用户平均分u1544.5u2322.5u3153.0原始余弦的计算要点是直接用原分做点积再归一化。修正余弦则先把每个用户的评分减去自己的平均分u1变为[0.5,-0.5]u2变为[0.5,-0.5]u3变为[-2.0,2.0]然后计算这三对中心化向量的余弦。皮尔逊系数则是对每个物品维度的评分先减去物品均值再计算。同一份数据三种算法给出的相似度排序很可能不一样这一点在真实数据里尤为明显。我在实践中的选择经验是用户评分尺度差异大优先修正余弦如果数据已经是标准化后的隐式反馈点击次数、播放时长等原始余弦可能就够用如果想保留物品本身的绝对热度信息再考虑皮尔逊。理解公式背后对谁做中心化、保留什么信息远比死记公式更重要。2.4 修正余弦的Python实现与一个高频易错点直接给出一个可运行的修正余弦实现import numpy as np def adjusted_cosine_similarity(R, min_common5): R: 用户-物品评分矩阵0表示未评分 min_common: 共同评分数低于该值的物品对相似度直接置0 R R.astype(float) mask R 0 # 按用户均值中心化注意未评分的位置必须保持为0 row_mean R.sum(axis1) / mask.sum(axis1) R_centered R - row_mean[:, None] * mask # 计算列向量两两之间的余弦相似度 item_norm np.sqrt((R_centered ** 2).sum(axis0)) sim R_centered.T R_centered / (item_norm[:, None] * item_norm[None, :] 1e-9) # 过滤共同评分数过少的不可靠物品对 co_count mask.T mask sim[co_count min_common] 0 np.fill_diagonal(sim, 0) return sim, co_count这里最容易踩的坑也是我当年排查了两天的坑中心化时不能直接写R - R.mean(axis1)因为这样会把所有未评分的0变成负数。这些假负分会被余弦计算当成用户强烈反感某物品的信号直接把相似度矩阵污染掉。正确做法是row_mean[:, None] * mask只对真正有评分的位置做减法。别小看这一行它决定了你的推荐列表是干净还是出现一堆莫名其妙的物品。3. 从原始日志到推荐结果全流程拆解与代码实现3.1 数据清洗行为日志怎么变成评分矩阵真实业务里很少直接给你一个完整的评分矩阵通常只有一张行为日志表user_id、item_id、action_type、timestamp。action_type可能是曝光、点击、收藏、加购、购买。第一步是给行为赋权把隐式反馈转成可计算的分数。我常用的权重方案是点击1收藏2加购3购买5。这个权重不是拍脑袋定的它反映的是用户意愿的递进关系你也可以按业务调。接着做两层过滤物品维度上行为总数低于10的删除否则相似度几乎全是噪声用户维度上行为总数低于5的删除或者单独圈出来走热门兜底。还有一个细节如果你的场景里同一个人反复用同一个账号刷一个物品需要按useritem做聚合取最大值或加权求和避免重复行为权重溢出。最关键的一步是数据集划分不要随机shuffle必须按时间切。训练集用前90天测试集用之后7天。随机划分会让模型用未来预测过去离线指标虚高上线一对比立刻被打回原形。3.2 用户-物品矩阵的稀疏存储与相似度矩阵计算清洗完数据后把三元组转成矩阵。生产环境里别用稠密的numpy二维数组内存根本扛不住。直接上scipy的稀疏矩阵from scipy.sparse import csr_matrix users ... # 去重后的用户编号列表 items ... # 去重后的物品编号列表 user_idx ... # 每条行为对应的用户下标 item_idx ... # 每条行为对应的物品下标 values ... # 每条行为的加权分数 R_sparse csr_matrix((values, (user_idx, item_idx)), shape(len(users), len(items)))全量计算物品两两相似度在百万物品规模下不可行必须限定候选集。我的做法是分两步走第一步用矩阵乘法算出物品间的共现次数矩阵只保留co_count大于阈值比如20的物品对作为候选第二步只对候选对计算修正余弦相似度每件物品只保留TopK个最相似的邻居K通常取50到200。这一步做完相似度矩阵就从稠密I×I变成了每行最多K个非零值的稀疏邻接表存储和查询压力都小很多。3.3 预测打分与Top-N推荐生成有了物品相似度矩阵推荐就变成一件很机械的事。对用户u他的推荐物品j的预测得分为pred(u, j) 所有用户u评过分的物品i与j的相似度乘以用户u对i的评分之和再除以所有参与计算的相似度绝对值之和。这个分母很容易被忽略但它非常重要。如果不除以相似度绝对值之和那么被大量低相似度邻居包围的大众物品会因为邻居数量多而分数虚高推荐列表会被热门物品霸占。我见过不少团队的初版推荐列表长短都一样——全是爆款就是因为少了这层归一化。直接给可运行的推荐函数def recommend_for_user(user_items, topk_sim, top_n10): user_items: {item_id: rating} 用户已交互物品 topk_sim: {item_id: [(neighbor_id, sim_score), ...]} scores {} weights {} for item_i, rating in user_items.items(): for item_j, sim in topk_sim.get(item_i, []): if item_j in user_items: continue # 过滤已交互 scores[item_j] scores.get(item_j, 0) sim * rating weights[item_j] weights.get(item_j, 0) abs(sim) ranked sorted( ((scores[item] / weights[item]) if weights[item] 0 else 0.0, item) for item in scores ) ranked.sort(keylambda x: x[0], reverseTrue) return [item for _, item in ranked[:top_n]]这里的乘法用的是评分加权。如果你的数据是纯隐式反馈没有评分强度可以直接用sim累加但归一化仍然要做。另外排序前建议再做一次规则过滤删除用户已购买、已收藏、明确点过不感兴趣的物品这些负反馈不过滤干净指标再好看也是空谈。4. 离线评测别被看起来还不错骗了4.1 评测协议设计的三条硬规矩没有评测的实验等于自嗨。ItemCF离线评测有公认的流程但真正执行时容易在细节上翻车。第一条规矩是严格按时间切分训练集和测试集。训练集是用户前90天的行为测试集是之后7天的行为。测试集用户如果完全没有行为直接丢弃否则精确率、召回率会被大量零分母稀释。第二条规矩是负样本构造要谨慎。推荐场景里用户没交互不等于用户不喜欢很多物品只是没有被曝光过。常见的处理方式是从用户的未交互物品里随机抽K个作为负样本再配合AUC这类排序指标一起看。第三条规矩是必须分层看指标不能只看一个整体数字。头部重度用户的交互行为多如果他们对推荐照单全收整体召回率会很好看但腰部用户可能毫无感知。我习惯把用户按行为量分成三档分别看指标。4.2 四个核心指标与它们的真实含义HitRate / RecallK测试集里用户真正交互过的物品有多少出现在推荐列表前K个中。这是最重要的召回指标。PrecisionK推荐列表前K个里用户真正交互的比例。注意离线环境里用户可能根本没见过这些推荐所以精确率天然会被低估。Coverage覆盖率推荐系统覆盖了多少不同物品。覆盖率太低说明推荐结果高度集中在爆款没有挖掘长尾价值。平均推荐热度推荐列表物品的行为量均值。同样的Recall下这个值越低说明推荐越个性化。我给四个指标一个直观的比喻召回率回答该抓的鱼抓到了几条精确率回答捞上来的网里鱼占多少覆盖率回答整片海域去过了多少平均热度回答捞上来的是不是都是同一群容易捞的鱼。四个指标互相制衡单看任何一个都会被带偏。4.3 一套可复现的小规模对比实验为了让你直观看到选错相似度公式的后果我用合成数据做了一套100个用户、60个物品、1800条评分的实验稀疏度约70%按时间切分出训练集和测试集分别对比三种方案热门物品推荐Top-NbaselineItemCF相似度用原始余弦ItemCF相似度用修正余弦以我实际跑出来的相对结果为例以下数值用于说明大小关系具体数字随数据分布变化方案Recall10Precision5覆盖率平均推荐热度热门物品推荐0.230.3112%0.85ItemCF原始余弦0.360.4038%0.61ItemCF修正余弦0.410.4641%0.55这套对比最直观的结论有两点第一ItemCF比热门推荐强在覆盖率和热度分散上推荐列表更有个性第二修正余弦在稀疏评分数据上比原始余弦更有优势因为用户评分尺度的干扰被提前剥掉了。如果数据里用户评分习惯差异不大两者差距会缩小这也提醒你评测要在自己的数据上做不要照搬别人的结论。4.4 离线指标和线上业务指标之间那道沟离线指标再漂亮也解释不了用户为什么不下单。离线Recall高说明大概率你会想看它但用户看到一个推荐位时还要被标题、价格、图片、信任感层层过滤。所以上线之前必须走小流量A/B测试观察点击率、加购率、转化率这些业务指标。我的经验是离线评测负责筛选方案的相对优劣业务指标负责确认方案的最终价值。两者中间还有一道重要工序——人工检查推荐列表。随机抽50个用户的推荐结果肉眼扫一遍有没有已经买过的有没有明显不符合当前上下文的有没有低质甚至违规内容这道工序成本很低但往往比任何指标都先暴露问题。5. 工程落地稀疏、冷启动与增量更新的三板斧5.1 稀疏到80%以上时的对策真实评分矩阵稀疏度动辄95%以上。此时如果还执着于全量计算所有物品对的相似度计算量和存储量都会快速失控。工程上有三件套组合拳第一提高共同评分阈值。两个物品至少要有20个以上共同评分的用户相似度才有统计意义。阈值太低少量共现会被随机性放大成假相似。第二用稀疏矩阵乘法先算共现计数只保留候选物品对其余位置根本不计算。第三引入近似最近邻库比如Annoy、HNSW这一类。先把每个物品的评分向量作为索引输入建好索引后每个物品只查最近的TopK邻居相似度计算成本从全量O(I²)量级降到每个物品只找K个候选的量级配合多线程百万物品也能在数小时内算完。相似度矩阵算完后的存储也是讲究。线上推荐响应要毫秒级推荐服务启动时直接把TopK相似邻居表加载进内存key是item_idvalue是排序好的(neighbor_id, score)列表。如果内存吃紧就只把相似度大于0.3的邻居放进内存其余丢弃。这一层阈值就是线上效果和内存成本的平衡旋钮。5.2 冷启动的两条靠谱路线冷启动分为新用户和新物品两个方向策略完全不同。新物品的冷启动核心思路是替身。物品没有行为就用内容属性先顶上类目、品牌、标签、文本描述向量。先用内容相似度算出它和已有物品的近似邻居把这个伪邻居表当成相似度矩阵来用。等这个物品积累了足够行为几百个交互下一次离线重算就会把它换到真实行为相似度上。注意这里要做平滑切换别在某一次重算后突然大变样线上会抖。新用户的冷启动靠热门兜底。用户没有任何行为时直接推榜单一旦用户产生了一个点击或加购立刻用这个行为物品的TopK邻居生成个性化推荐这就是单点播种。别小看这个逻辑很多推荐系统的冷启动阶段一个精准种子行为能带来的点击率提升比后面调十轮模型参数都明显。5.3 相似度矩阵的更新策略别每天全量重算相似度本质是群体一致行为的沉淀变化是缓慢的不需要跟着用户实时行为高频更新。完全不更新也不行用户的兴趣会漂移新物品需要融入矩阵。我的做法是第一时间衰减。把行为日志的打分乘上一个时间衰减系数exp(-λ*天数差)λ一般取0.01到0.05让1个月前和3个月前的行为权重拉开。第二滑动窗口重算。每次只取最近90天行为来计算相似度矩阵而不是拿全部历史。第三更新频率上离线每天或每两天全量重算一次TopK邻居表线上只做读取。不要在线上去动态更新相似度一旦出问题线上没有回滚的余地。这套策略的关键是全量重算、低频落地、线上只读三个词。维护成本低稳定性高效果也足够好。5.4 线上服务最容易忽略的四个细节把ItemCF上线到服务端时有几个细节点经常被忽略我按踩坑频率排个序第一个是训练时数据处理逻辑和线上推理逻辑必须完全一致。阈值过滤、归一化、时间窗在训练代码里是什么参数线上就要一模一样。很多事故都是训练用了一套过滤规则线上服务用了另一套结果推荐结果莫名其妙变差。第二个是推荐结果要做业务规则过滤已购、已收藏、已点不感兴趣的都要剔掉尤其要防止把用户正在看的物品再推荐一次。第三个是多样性控制。只用相似度排序结果容易堆成清一色同类目可以引入MMR最大边际相关这类算法做列表重排在相关性和多样性之间取平衡。第四个是回滚开关。每次更新相似度矩阵之前先把旧版本结果缓存成兜底新版本灰度一段时间有问题立刻切回避免线上长时间不可用。另外我强烈建议加一道推荐质量监控每天统计推荐列表的平均热度、覆盖率、相似度分布。如果发现平均热度突然升高往往是归一化逻辑出了问题如果覆盖率骤降可能是某个热门物品的邻居表异常膨胀。指标异常比用户投诉来得早盯住它们能省掉很多半夜被叫醒的麻烦。最后说说我自己的体会。ItemCF看起来是老技术但它的鲁棒性和可解释性到今天依然非常能打难点从来不在公式而在数据清洗和工程细节。我踩过最痛的一次坑就是中心化时忘了对未评分位置做mask推荐列表被一堆负分伪相似物品霸占排查了两天才定位到那一行代码。把这些基础流程做扎实、评测做严谨比追着新模型跑要值钱得多。