做推荐系统这几年有一个算法我几乎每个项目都绕不开就是基于用户的协同过滤userCF。不管是早期做资讯流还是后来做电商场景的个性化推荐它都是最直观、最容易解释给业务方听的一种召回策略。简单说userCF的核心逻辑就一句话找到和你兴趣相似的一群人把他们喜欢而你还没见过的内容推荐给你。放在社交场景里这几乎是不需要教育的产品逻辑——“你的朋友都在看你也大概率会喜欢”。这篇内容我会从算法原理、代码实现、工程落地三个层面把userCF拆开揉碎讲清楚。适合刚入门推荐系统、想弄明白协同过滤背后细节的同学也适合已经在做推荐、想再回头梳理userCF坑点的工程师参考。我会把相似度计算、打分排序、冷启动、热门物品打压这些关键环节都过一遍附上可以直接跑的Python实现最后聊聊我在实际项目里踩过的坑。1. 项目核心思路为什么现在还要认真学userCF1.1 userCF解决的是什么问题推荐系统本质上做的是信息过滤。用户面对海量内容时我们得判断“哪些东西对这个用户最有价值”。userCF的切入角度特别朴素人以群分。它不关心物品本身的属性也不需要分析文本、图片、标签这些内容特征只需要一份用户对物品的行为记录比如点击、收藏、购买、评分就能把推荐做起来。这套逻辑放到实际场景里非常有用。比如你做一个社区产品用户A和用户B都收藏过某几个相同的帖子系统就认为他们兴趣相近。这时候用户B收藏过一篇新的帖子用户A没看过这篇帖子就会被推给用户A。整个过程不需要理解帖子内容是什么也不需要打标签纯靠行为数据就能建立推荐关系。这里的关键点在于userCF抓住的是“社交相似性”而不是“内容相似性”。这两种思路的差别在后续优化上表现得非常明显。内容相似性比如itemCF更稳推荐结果容易被解释而userCF更擅长发现惊喜能挖掘出用户自己都没想到会喜欢的东西。在需要强个性化、用户兴趣变化快的产品里userCF有它不可替代的位置。1.2 选userCF而不是itemCF的场景判断很多初学者会问既然有itemCF为什么还要用userCF我的经验是这两个算法适用的产品形态有很明显的分野。userCF更适合用户量相对可控、物品数量大、用户个性化需求强的场景。典型代表是资讯推荐、社交feed流、短视频早期冷启动。在这类产品里用户规模可能几十万到几千万用户行为比较密集兴趣分化明显用户之间能找到较强的相似关系。比如新闻客户端一个用户看了几条科技新闻系统找到另一群也爱看科技新闻的人把他们在看的其他新闻推荐出来效果通常不错。另一点值得注意userCF的推荐结果带有明显的**“圈层传播”特性**。因为推荐源头是相似用户的行为所以天然适合做社交裂变、话题扩散。如果你在做一个鼓励用户互动的内容社区userCF往往比itemCF更能带动“大家都在看”的氛围。反过来如果一个产品的用户量远远大于物品量比如电商平台用户几亿商品几百万那userCF计算用户相似度矩阵的开销会非常大这时候itemCF反而更合适。这也是为什么业界常说“社区用userCF电商用itemCF”。当然真实系统里经常两者都做最后融合排序但在起步阶段搞清楚主次能省很多事。2. 算法原理拆解userCF三个核心环节的计算逻辑2.1 用户相似度计算的常用方法userCF的第一步是把用户之间的相似度算出来。业界最常用的两个指标是余弦相似度Cosine Similarity和皮尔逊相关系数Pearson Correlation Coefficient。拿余弦相似度来说我们把每个用户的行为记录表示成一个向量向量的维度是物品值是这个用户对物品的评分或者行为权重。用户u和用户v的相似度就是这两个向量夹角的余弦值[ sim(u, v) \frac{\sum_{i \in I_{uv}} r_{ui} \cdot r_{vi}}{\sqrt{\sum_{i \in I_u} r_{ui}^2} \cdot \sqrt{\sum_{i \in I_v} r_{vi}^2}} ]其中(I_{uv})是两个用户都产生过行为的物品集合。只看“共同打分过的物品”可以避免大量零值向量带来的计算浪费。形式上余弦相似度衡量的是两个用户行为方向是否一致你点了科技、我也点了科技我们就相似至于你点了10篇还是我点了50篇并不直接影响相似度。皮尔逊相关系数比余弦多了一步它先对每个用户的评分做中心化减去该用户的平均分。这样做的好处是能消除用户打分习惯的偏差。比如有的用户天生手松什么东西都给5星有的用户手紧好东西也就给3星。直接用原始分算余弦手松的用户会被误判跟很多人相似皮尔逊相关系数就能把这部分偏差去掉。在实际使用中我还有一个小经验如果行为数据是隐式的比如只有点击、曝光没有评分用余弦相似度配合行为权重就足够如果行为数据是显式的用户明确打了1到5分优先考虑皮尔逊相关系数。这个选择在工程上能减少很多调参时间。2.2 候选物品打分与TopN推荐算完相似度接下来要根据相似用户的兴趣来生成推荐列表。假设我们要给用户u推荐物品大致流程是从用户u的历史行为中找到他交互过的物品集合这些物品不能重复推荐。找到与用户u最相似的K个用户。把这K个用户的行为物品汇总排除用户u已经交互过的物品。对每个候选物品i用下面的公式计算用户u对它的感兴趣程度[ score(u, i) \sum_{v \in S(u, K) \cap N(i)} sim(u, v) \cdot r_{vi} ]简单解释一下如果用户v和用户u很相似而且v用户对物品i有正向行为那么物品i在u这边的得分就会高。最后按得分从高到低取TopN物品推荐给用户。这里有个细节值得反复琢磨K值的选取。K太小相似用户圈层太窄推荐结果容易局限在几个紧密好友的范围内K太大相似用户圈层太泛推荐结果趋近于热门榜。我通常的做法是先在离线评测里扫一遍K值观察准确率和召回率的变化曲线再结合业务场景做取舍。资讯类产品K可以取20到50社交属性强的产品K可以适当放大到50到100具体还是要拿数据说话。2.3 userCF的数学表达与代码设计思路从工程实现角度看userCF的完整流程可以拆成以下几块离线构建“用户-物品”行为矩阵、计算用户相似度矩阵、在线推荐时查询相似用户并聚合候选物品、按公式打分排序。我见过很多初学者一上来就自己去实现相似度计算的循环两层for遍历所有用户用户量一上万就卡死。正确做法是先构建“物品到用户”的倒排索引再遍历每个物品下共同出现过的用户对从而只计算有共同行为的用户对之间的相似度。这个优化思路几乎决定了一个userCF能不能在真实规模的数据上跑起来。举个例子如果有100万个用户全量两两算相似度是10的12次方量级根本算不动。但如果通过倒排索引一个物品下面最多几百个用户产生过行为遍历所有物品时只更新这些用户对的共同物品计数计算量会下降好几个数量级。这是userCF工程落地里最重要的一步后面我会给出具体的代码实现。3. 从零实现一个可运行的userCF3.1 数据集准备与预处理为了让你直观感受userCF的完整过程我用Python写一个精简但可运行的版本。数据我用一个极简的评分数据集来说明格式是用户ID, 物品ID, 行为分数A, 苹果, 4 A, 香蕉, 5 A, 西瓜, 3 B, 苹果, 5 B, 香蕉, 4 B, 草莓, 2 C, 苹果, 2 C, 梨, 4 C, 樱桃, 5 D, 香蕉, 3 D, 樱桃, 4 D, 芒果, 5真实场景里行为分数可以是点击次数、完播时长、购买金额的某种映射。预处理时要注意几个点把缺失值处理掉把用户和物品都映射成稠密整数ID方便矩阵索引对行为分数做归一化或者截断避免异常值主导相似度。3.2 相似度矩阵与推荐主流程的实现我直接给出核心代码建议你跑一遍之后再看解释。import math from collections import defaultdict def load_data(): # 返回 user_items: {user: {item: score}} user_items defaultdict(dict) with open(ratings.csv, r, encodingutf-8) as f: for line in f: user, item, score line.strip().split(,) user_items[user][item] float(score) return user_items def build_item_users(user_items): # 构建物品-用户倒排索引这是性能优化的关键 item_users defaultdict(set) for user, items in user_items.items(): for item in items: item_users[item].add(user) return item_users def calc_user_sim(user_items): # 思路遍历物品下的用户集合统计用户共同行为物品数 item_users build_item_users(user_items) user_item_count defaultdict(int) co_occur defaultdict(int) for item, users in item_users.items(): for u in users: user_item_count[u] 1 for v in users: if u v: continue # 只统计共同物品数后续再算相似度 co_occur[(u, v)] 1 user_sim defaultdict(dict) for (u, v), cnt in co_occur.items(): # 余弦相似度共同物品数 / sqrt(|N(u)| * |N(v)|) sim cnt / math.sqrt(user_item_count[u] * user_item_count[v]) user_sim[u][v] sim return user_sim def recommend(user, user_items, user_sim, top_k3, top_n5): if user not in user_items: return [] interacted set(user_items[user].keys()) # 找到最相似的top_k个用户 if user not in user_sim: return [] sim_users sorted(user_sim[user].items(), keylambda x: x[1], reverseTrue)[:top_k] scores defaultdict(float) for sim_user, sim_val in sim_users: for item, score in user_items[sim_user].items(): if item in interacted: continue scores[item] sim_val * score ranked sorted(scores.items(), keylambda x: x[1], reverseTrue)[:top_n] return ranked if __name__ __main__: user_items load_data() user_sim calc_user_sim(user_items) print(用户A的推荐结果:, recommend(A, user_items, user_sim))这段代码把核心逻辑压缩到几十行重点看calc_user_sim这一段我没有直接两两遍历用户而是先遍历物品在其用户集合内更新共同出现次数这样就避开了(O(N^2))的全量用户计算。这个倒排思路是userCF工程实现的关键建议当成模板记下来。3.3 输出结果与运行效果分析跑完上面的代码输入里面的数据用户A的推荐结果大概会是草莓、樱桃、梨、芒果这一类的物品。我们稍微分析一下这个结果用户A和用户B同时喜欢苹果、香蕉相似度很高B喜欢的草莓就进入了A的候选列表C和A共同行为少贡献的樱桃、梨得分次之。最终按加权得分排序后输出TopN。这里有个很有意思的现象如果某个物品比如苹果特别热门几乎每个用户都行为过那它在相似度计算里会被反复计为共同物品导致热门物品对相似度的“贡献虚高”。后面我讲优化时会专门提到怎么解决这个问题。4. 工程中的常见坑与排查技巧4.1 稀疏用户行为怎么处理真实系统里绝大多数用户的行为记录少得可怜可能注册三个月就点了两三个商品。在这种稀疏数据下userCF会遇到“相似用户找不到”的尴尬局面。我见过最典型的表现是一个冷启动用户上线系统只能找到几个行为极少的相似用户推荐结果五花八门完全不能用。应对思路通常有三条。第一对行为做降级处理比如点击、收藏、加购、支付分别赋予不同权重一个支付行为可以等价于多次点击这样能提高行为矩阵的密度。第二引入用户画像特征做相似性的“桥接”当行为数据不够时先用注册信息、活跃时段、设备偏好等属性特征算一个先验相似度再和行为相似度做加权融合。第三在召回阶段设置最低行为阈值只让那些有足够行为记录的用户参与相似度计算其他用户直接走热门榜或规则召回等行为积累到一定程度再切换个性化策略。4.2 热门物品导致的同质化问题这是userCF最典型的问题之一。因为共同行为过的物品越多用户相似度就越高而热门物品恰恰最容易成为共同行为对象结果是两个用户哪怕只都看过一部爆款电视剧相似度也会被拉得很高导致推荐结果严重偏向大众化丧失个性化。有两个改进方向很有效。一个是对热门物品做出惩罚在计算共同物品数时给热门物品的权重打折比如John S. Breese在论文里提出的(1/\log(1|N(i)|))形式物品越热门对相似度的贡献越低。另一个是对相似用户做反向筛选不要只看相似度最高的一批用户而是尽量保留不同圈层的用户扩大推荐来源的多样性。我在一个资讯项目里试过加上热门物品惩罚之后推荐结果的点击率大约提升了12%到15%效果相当明显。4.3 userCF的在线实时性瓶颈很多团队在做实时推荐时都会踩到userCF的性能坑。因为用户相似度矩阵需要基于全量用户行为不断更新行为数据增长越快矩阵更新越频繁。如果每次更新都是全量重算耗时和资源消耗会非常惊人。我常用的折中方案是离线全量近线增量。离线任务每天重算一次用户相似度矩阵分钟级的新行为通过增量计算只更新受影响的局部用户相似度。比如一个用户刚看了某篇文章我们就只更新这篇文章下涉及的活跃用户对其他部分不动。这样既保证了推荐结果的时效性又把计算开销控制在一个可接受的范围。等做深了会发现推荐系统的工程难点往往不在算法本身而在于怎么在实时性、准确率、成本三者之间找到平衡。5. userCF的进阶优化与生产落地建议5.1 相似度权重修正和惩罚项前面已经提到热门物品惩罚这里再补充几个我实际用过的修正手段。行为时间衰减用户的兴趣会随着时间漂移。三个月前喜欢的东西和昨天喜欢的东西对当前兴趣的指示作用完全不同。可以在计算相似度或打分时引入时间衰减因子比如(e^{-\alpha \Delta t})让越久远的行为权重越低。相似度归一化不同用户的活跃度差异很大直接拿原始相似度做加权活跃用户可能会“霸榜”。我常做的是对相似度做最大最小值归一化让它落在0到1之间再参与后续打分。惩罚高度活跃用户如果一个用户关注了几千个物品、跟所有人都相似那他的“个性化”参考价值其实很低。可以用(1/\log(1|N(u)|))这类因子压低这类用户的权重效果跟热门物品惩罚类似。5.2 离线采集、特征拼接与实时推荐的整体架构生产环境里的userCF很少独立存在通常是整个推荐链路中的一路召回。以我经历过的一个内容推荐项目为例整体架构大致是这样的数据层埋点上报的用户曝光、点击、停留时长等行为经过清洗后落到数据仓库形成“用户-物品-行为”宽表。离线计算层定时任务跑userCF模型产出每个用户的TopN候选列表写回线上存储比如Redis或AB测试用的特征表。近线增量层监听实时行为队列增量更新最近一小时内有行为的用户相似度补充新产生的候选物品。在线服务层用户请求进来时合并多个召回源的候选集再经过粗排、精排最后输出给用户。这种架构下userCF只是候选来源之一它的输出会和itemCF、向量召回、热门兜底做融合。这样一来单个算法的短板不至于拖垮整个推荐效果系统整体的稳定性和可解释性也能兼顾。5.3 用什么参数评估和调优userCF效果评估userCF不能只看一个指标。常见的做法是分成两部分离线指标看准确率Precision、召回率Recall、覆盖率Coverage、多样性Diversity在线指标看点击率、转化率、人均浏览时长。我举一个具体的调参体验。有一回我发现离线准确率提升了但线上人均浏览时长反而下降了。排查之后发现高准确率是因为推荐结果太集中在用户已经看过的同类物品上惊喜感不够用户很快产生审美疲劳。后来我调整了相似用户K值稍微牺牲一点准确率增加了推荐结果的多样性在线时长很快就回来了。这个案例说明离线指标只能作为参考最终要回到业务目标来评判。在实际做调优时我会把几个关键参数记录成一张对照表方便横向对比参数作用调小的影响调大的影响相似用户K值控制候选来源范围结果窄、个性化强结果泛、趋向热门热门物品惩罚力度降低热门对相似度的贡献推荐大众化推荐长尾化行为时间衰减系数控制历史行为的影响短期行为主导长期兴趣主导行为权重映射区分点击/收藏/购买价值浅层行为主导深层行为主导这种表格在跟业务方对齐“为什么推荐结果是这样”时特别好用也能帮助后续迭代时快速定位问题出在哪个环节。最后再分享一个小技巧userCF在正式上线前一定要用真实的用户行为日志做一次时间切割验证比如用前7天的行为训练用后1天的行为验证别用全量数据直接评估。这个习惯能帮你提前发现时间漂移带来的很多脏问题省掉不少线上返工的麻烦。