1. 为什么相似度是协同过滤的“心脏”做推荐系统的人绕不开协同过滤做协同过滤的人绕不开相似度。这句话听起来像废话但我在实际项目里见过太多团队模型框架搭得花里胡哨Embedding、双塔、深度交叉特征全上了最后召回效果还不如一个老老实实调相似度参数的ItemCF。问题出在哪出在他们把相似度当成了一个“调包就行”的步骤而没有理解它背后到底在度量什么。协同过滤的核心逻辑其实非常朴素物以类聚人以群分。你喜欢A和B我也喜欢A那我大概率也会喜欢B。这个“大概率”的强弱就是靠相似度来量化的。用户之间的相似度决定了“跟我口味相近的人喜欢什么”物品之间的相似度决定了“跟我喜欢的这个东西相似的东西是什么”。所以相似度不是一个可有可无的中间产物它是整个推荐链路的排序依据和召回依据。这篇文章适合谁看如果你正在做推荐系统的召回或排序层或者你是一个刚接触协同过滤、被各种相似度公式搞得头晕的开发者再或者你已经用了现成的推荐库但效果始终不理想、想从底层搞清楚问题出在哪那这篇内容就是写给你的。我会把UserCF和ItemCF两条线都拆开讲重点放在相似度的计算细节、参数选择、工程实现和踩坑经验上尽量做到你读完就能直接上手改代码。需要提前说明的是下面涉及的具体代码和参数是基于常见工程实践给出的参考方案不同业务场景下的最优值会有差异你需要结合自己的数据分布去调整。2. 协同过滤的两条路线与相似度的角色定位2.1 UserCF和ItemCF的本质区别协同过滤按相似度计算的对象不同分成两个流派。UserCF算的是用户之间的相似度核心假设是“跟你相似的人喜欢的东西你也可能喜欢”。ItemCF算的是物品之间的相似度核心假设是“跟你喜欢的东西相似的物品你也可能喜欢”。这两个路线在实际工程中的表现差异非常大我列个表对比一下对比维度UserCFItemCF相似度计算对象用户-用户物品-物品推荐结果解释性较弱“跟你相似的人还看了”较强“跟这个物品相似”用户数增长的影响相似度矩阵膨胀快相对稳定物品数增长的影响相对稳定相似度矩阵膨胀快实时性用户行为变化需重算物品相似度可离线预计算适用场景社交属性强、用户量可控物品更新慢、用户量大的场景我个人的经验是大多数电商和内容平台场景下ItemCF更实用。原因很简单用户量通常远大于物品量而且用户兴趣变化快用户相似度矩阵维护成本高。但UserCF在新闻、社交这类场景下反而有优势因为新闻的时效性强物品新闻的生命周期短算物品相似度意义不大。2.2 相似度在推荐链路中的位置不管走哪条路线相似度的计算都处于推荐链路的最前端。以ItemCF为例完整链路是这样的构建用户-物品交互矩阵评分、点击、购买等基于交互矩阵计算物品-物品相似度矩阵根据用户历史行为找到其交互过的物品取这些物品的相似物品作为候选集对候选集打分排序生成推荐列表相似度矩阵的质量直接决定了第4步候选集的质量。如果相似度算得不准后面排序模型再强也是在垃圾堆里挑金子。我见过一个团队排序层用了很复杂的深度模型但召回层的相似度矩阵是用原始点击数据直接算余弦相似度没有做任何归一化和热度惩罚结果推荐结果全是爆款长尾物品根本出不来。后来他们在相似度计算里加了热度惩罚项整体CTR提升了将近8个百分点。2.3 相似度计算的基本输入形式相似度计算的输入通常是一个用户-物品交互矩阵。这个矩阵的每一行是一个用户每一列是一个物品矩阵元素是交互强度。交互强度的定义取决于业务场景显式反馈用户评分1-5分、点赞/踩隐式反馈点击0/1、购买0/1、停留时长、播放完成度隐式反馈的处理比显式反馈麻烦得多。显式评分天然有大小之分5分就是比3分更强烈的喜欢。但隐式反馈里用户没有点击一个物品不代表他不喜欢可能只是没看到。所以隐式反馈通常需要做置信度加权比如点击次数越多置信度越高或者用停留时长做加权。注意隐式反馈中负样本的选取非常关键。很多团队直接把未交互的物品当负样本但这里面混杂了大量“用户可能喜欢但没曝光”的物品直接当负样本会严重误导相似度计算。3. 相似度度量方法全解析与选型逻辑3.1 余弦相似度最常用但不一定最好余弦相似度是协同过滤里出场率最高的相似度度量。它的计算方式是取两个向量的夹角余弦值cos(a, b) (a · b) / (||a|| * ||b||)在用户-物品矩阵里两个物品的向量就是它们在所有用户上的交互强度列向量。余弦相似度的优点是对向量长度不敏感也就是说一个热门物品和一个冷门物品只要它们的用户交互模式相似余弦相似度就会很高。但这个“优点”在推荐场景下恰恰可能是缺点。举个例子物品A被10000个用户交互过物品B只被10个用户交互过如果这10个用户恰好都交互过A余弦相似度会很高。但B只有10个用户这个相似度的置信度非常低可能只是巧合。所以直接用余弦相似度容易让冷门物品和热门物品产生虚高的相似度。我通常会在余弦相似度的基础上加一个惩罚项比如sim(a, b) cos(a, b) * min(|Ua|, |Ub|) / (|Ua| |Ub|)这个惩罚项的思路是两个物品的共同交互用户数越少相似度的置信度越低需要打折。具体惩罚函数的形式可以调整核心思想是让相似度不仅反映“方向一致”还反映“证据充分”。3.2 皮尔逊相关系数去偏但计算量大皮尔逊相关系数在余弦相似度的基础上做了去中心化处理pearson(a, b) cov(a, b) / (std(a) * std(b))去中心化的意义在于消除用户评分偏好的影响。比如有的用户打分普遍偏高什么都给5分有的用户打分普遍偏低最好也就给3分。如果不做去中心化这两个用户的向量方向可能差异很大但实际上他们的偏好可能很相似。皮尔逊相关系数把每个用户的评分减去其均值相当于把每个人的评分标准拉到了同一水平线上。皮尔逊的缺点是计算量比余弦大而且当两个物品的共同评分用户很少时相关系数的方差会很大不稳定。所以在实际工程中皮尔逊更多用在显式反馈场景隐式反馈场景下用得少。3.3 杰卡德相似度适合二值化场景杰卡德相似度衡量的是两个集合的交集与并集之比jaccard(a, b) |Ua ∩ Ub| / |Ua ∪ Ub|它只关心“有没有交互”不关心交互强度。适合点击、购买这类二值化行为。杰卡德的计算非常简单工程上很容易做并行化所以在海量数据的粗排阶段经常被用到。但杰卡德的问题也很明显它完全忽略了交互强度。用户点击1次和点击100次在杰卡德里是一样的。所以它通常用在召回阶段做快速筛选精排阶段再换更精细的相似度。3.4 调整余弦相似度ItemCF的经典选择调整余弦相似度Adjusted Cosine Similarity是ItemCF里非常经典的一种度量方式。它的核心思想是在计算物品相似度时减去用户对物品的平均评分而不是减去物品自己的平均评分。adjcos(a, b) Σ_u (r_ua - r_u) * (r_ub - r_u) / sqrt(Σ_u (r_ua - r_u)^2) * sqrt(Σ_u (r_ub - r_u)^2)其中r_u是用户u对所有物品的平均评分。这样做的目的是消除不同用户评分尺度的影响。因为ItemCF算的是物品之间的相似度而物品是被不同用户评分的如果不做用户维度的去偏热门物品和冷门物品的相似度会被用户的评分习惯扭曲。3.5 相似度选型速查表相似度方法适用反馈类型计算复杂度抗热度偏置推荐使用场景余弦相似度显式/隐式低弱快速原型、粗排皮尔逊相关系数显式中中评分数据、精排杰卡德相似度二值隐式极低弱海量数据粗筛调整余弦相似度显式中强ItemCF精排欧氏距离倒数显式/隐式低弱低维稠密向量选型的时候不要迷信某一种方法我通常的做法是粗排用杰卡德或余弦快速筛精排用调整余弦或皮尔逊。如果数据量特别大还会考虑用局部敏感哈希LSH做近似最近邻搜索避免全量计算相似度矩阵。4. 相似度计算的工程实现与参数调优4.1 数据预处理交互矩阵的构建与归一化在算相似度之前交互矩阵的预处理做得好不好直接决定了相似度的质量。我一般会做这几步第一步是去噪。把明显的异常行为过滤掉比如一个用户在一秒内点击了100个物品这大概率是爬虫或者误操作。过滤规则可以根据业务定常见的是限制单用户单日最大交互次数。第二步是加权。不同行为类型的权重不一样。比如电商场景下购买权重大于加购加购大于收藏收藏大于点击。可以设计一个权重映射表behavior_weight { purchase: 5.0, add_to_cart: 3.0, favorite: 2.0, click: 1.0 }第三步是归一化。把交互强度归一化到同一量纲。常见做法是除以用户的最大交互强度或者做对数变换。对数变换对长尾分布特别有效import numpy as np weighted np.log1p(raw_weight)第四步是去偏。对热门物品做惩罚。一个简单有效的方法是用TF-IDF的思想给每个物品的交互乘以一个逆频率权重idf np.log(total_users / (item_user_count 1))这样热门物品的权重会被压低冷门物品的权重相对提升有助于挖掘长尾。4.2 相似度矩阵的稀疏化与截断全量相似度矩阵是N×N的N是物品数。如果物品有100万这个矩阵就是1万亿个元素根本存不下。所以必须做稀疏化。最常用的方法是Top-K截断每个物品只保留相似度最高的K个邻居其余置零。K的取值一般在20到200之间。K太小召回覆盖率不够K太大计算和存储成本高而且会引入噪声。我通常会用分位数截断代替固定K值先算出一个物品的所有相似度然后取第95百分位作为阈值低于阈值的置零。这样不同物品保留的邻居数不一样热门物品邻居多冷门物品邻居少更符合实际分布。还有一种方法是相似度阈值截断只保留相似度大于某个阈值的邻居。阈值一般取0.1到0.3之间具体看相似度分布。可以画一个相似度直方图找到长尾开始的位置作为阈值。实操心得截断之后一定要检查一下每个物品的邻居数分布。如果发现大量物品的邻居数为0说明阈值设高了或者K设小了需要调整。我一般会保证95%以上的物品至少有5个邻居。4.3 相似度计算的并行化方案相似度计算是典型的计算密集型任务单机跑全量数据基本不现实。工程上一般用MapReduce或者Spark来做。以Spark为例计算ItemCF相似度的核心思路是把用户-物品交互数据转成(user, item, weight)的格式按用户分组对每个用户交互过的物品两两组合生成(item_a, item_b, weight_a * weight_b)的中间结果按(item_a, item_b)聚合得到共同交互的权重和分别计算每个物品的模长然后归一化得到相似度# 伪代码示意 pairs interactions.groupBy(user).flatMap(lambda x: [(i, j, wi*wj) for i, wi in x.items for j, wj in x.items if i ! j]) similarity pairs.reduceByKey(lambda a, b: a b)这个方案的问题在于笛卡尔积爆炸。如果一个用户交互了1000个物品就会产生100万对组合。所以实际工程中会做用户活跃度截断只保留交互物品数在某个范围内的用户比如5到500。太少的用户信息不足太多的用户计算量太大且可能是异常行为。另一个优化是分块计算。把物品分成若干块每次只计算块与块之间的相似度降低单次计算的内存压力。4.4 相似度矩阵的增量更新策略全量重算相似度矩阵的成本很高但用户行为是实时产生的相似度矩阵需要定期更新。常见的更新策略有三种全量更新每天凌晨跑一次全量计算替换旧矩阵。优点是简单可靠缺点是无法反映当天的新行为。增量更新只计算新产生的交互对相似度的影响增量地更新矩阵。优点是实时性好缺点是实现复杂而且多次增量后会有累积误差。混合更新每天全量更新一次白天每隔几小时做一次增量更新。这是大多数团队采用的方案平衡了实时性和实现成本。我个人的经验是相似度矩阵的更新频率不需要太高。物品之间的相似关系是相对稳定的一天更新一次通常就够了。真正需要实时性的是用户兴趣的捕捉那是召回阶段的事不是相似度矩阵的事。5. 相似度效果评估与常见问题排查5.1 离线评估指标不只是看AUC相似度矩阵的质量评估不能只看最终的推荐AUC。我一般会从三个层面评估第一层是相似度本身的合理性。随机抽一些物品人工检查它们的Top-K邻居是否合理。比如“篮球”的邻居里应该有“篮球鞋”“运动护具”如果出现了“口红”“洗发水”那相似度计算肯定有问题。第二层是召回覆盖率。统计有多少物品能出现在推荐结果里。如果只有头部物品能出现说明相似度矩阵被热门物品主导了。第三层是最终业务指标。CTR、转化率、人均点击物品数、长尾物品曝光占比等。这些指标反映的是相似度矩阵在完整链路中的最终效果。评估层面核心指标健康值参考相似度合理性Top-K邻居人工抽检准确率80%召回覆盖率有曝光的物品占比60%业务效果CTR相对提升5%多样性人均曝光物品类别数持续监控5.2 常见问题一相似度矩阵被热门物品主导这是最常见的问题。表现是推荐结果里全是爆款长尾物品几乎没有曝光。根本原因是热门物品和任何物品都有较高的相似度因为它们的交互用户多和谁都有交集。解决方法我试过几种最有效的是在相似度计算前做热度惩罚。具体做法是在交互矩阵上乘以一个逆频率权重item_popularity interactions.groupBy(item).count() idf_weight np.log(total_users / (item_popularity 1)) weighted_interaction raw_interaction * idf_weight这样热门物品的交互强度被压低它们和冷门物品的相似度就不会虚高。另一个方法是在相似度计算后做最大相似度归一化把每个物品的相似度向量除以它的最大相似度值这样热门物品的相似度分布会被拉平。5.3 常见问题二冷启动物品相似度无法计算新上架的物品没有任何交互数据无法计算相似度也就无法被召回。这是协同过滤的固有缺陷。工程上的常见解法是基于内容的相似度兜底。用物品的标题、类目、标签等属性算一个内容相似度新物品先用内容相似度做召回等积累了一定交互数据后再切换到协同过滤相似度。另一个方法是利用物品的元数据做映射。比如新物品属于某个类目就用该类目下热门物品的相似度向量做平均作为新物品的初始相似度。这个方法比较粗糙但在冷启动阶段能快速让新物品有曝光机会。5.4 常见问题三相似度计算中的数值稳定性在计算皮尔逊相关系数或调整余弦相似度时如果分母的标准差接近0会出现除零错误或者数值爆炸。这种情况通常发生在交互数据极少的物品上。解决方法是在分母上加一个平滑项denominator np.sqrt(var_a epsilon) * np.sqrt(var_b epsilon)epsilon一般取1e-8到1e-6。另外对于交互用户数少于某个阈值比如5个的物品直接不计算相似度或者用默认相似度填充。5.5 常见问题速查表问题现象可能原因排查方法解决方案推荐全是爆款热门物品相似度虚高检查Top-K邻居的热度分布加逆频率权重、最大相似度归一化新物品无曝光冷启动无交互数据检查新物品的邻居数内容相似度兜底、类目平均向量相似度计算报错分母为零或极小检查方差分布加平滑项、过滤低交互物品推荐结果重复相似度矩阵过于稠密检查平均邻居数提高截断阈值、降低K值更新后效果波动大增量更新累积误差对比全量和增量矩阵差异定期全量重算、限制增量次数6. 从相似度到最终推荐完整链路串讲6.1 召回阶段的相似度应用召回阶段的目标是从海量物品中快速筛选出几百个候选。相似度在这里的作用是快速定位候选集。以ItemCF为例召回流程是取用户最近交互的N个物品每个物品取Top-K相似物品合并去重后作为候选集。这里有两个关键参数N和K。N一般取10到50K一般取20到100。N太大用户兴趣漂移会导致召回不准N太小召回覆盖率不够。我通常会用时间衰减加权来处理N个物品的贡献。越近期的交互权重越高time_decay np.exp(-lambda_ * (current_time - interaction_time))lambda_的取值决定了衰减速度一般取0.01到0.1之间对应半衰期几天到几十天。6.2 排序阶段的相似度特征到了排序阶段相似度不再直接决定推荐结果而是作为特征输入到排序模型里。常见的相似度特征包括用户历史交互物品与候选物品的最大相似度用户历史交互物品与候选物品的平均相似度用户历史交互物品与候选物品的相似度加权和按时间衰减加权候选物品的相似物品中用户交互过的数量这些特征从不同角度刻画了用户和候选物品的匹配程度比单一相似度值更有信息量。6.3 一个完整的ItemCF推荐示例假设我们有一个简单的用户-物品交互矩阵用户A: 物品1(5分), 物品2(3分), 物品3(4分) 用户B: 物品1(4分), 物品2(5分), 物品4(2分) 用户C: 物品2(4分), 物品3(5分), 物品4(3分)计算物品相似度用调整余弦物品1和物品2的共同评分用户是A和B。用户A的平均分是4用户B的平均分是3.67。adjcos(1,2) [(5-4)*(3-4) (4-3.67)*(5-3.67)] / [sqrt((5-4)^2(4-3.67)^2) * sqrt((3-4)^2(5-3.67)^2)] [(-1) (0.33*1.33)] / [sqrt(10.11) * sqrt(11.77)] [-1 0.44] / [1.05 * 1.66] -0.56 / 1.74 -0.32这个结果是负的说明物品1和物品2在去偏后是负相关。这其实合理用户A对物品1评分高但对物品2评分低用户B对物品1评分低但对物品2评分高两个物品的偏好方向相反。这个例子说明调整余弦相似度能捕捉到原始余弦相似度忽略的偏好方向信息。如果用原始余弦物品1和物品2的相似度会是正的因为它们的评分都偏高。6.4 相似度矩阵的存储与检索优化相似度矩阵的存储和检索是工程上的一个大问题。100万物品的Top-100相似度矩阵大约有1亿个非零元素每个元素存物品ID和相似度值大概需要几百MB到几GB的内存。这个量级单机还能扛但如果物品数到千万级就必须用分布式存储。检索方面给定一个物品要快速找到它的Top-K相似物品。如果相似度矩阵是稠密存储的直接查表就行。如果是稀疏存储的可以用倒排索引key是物品IDvalue是相似物品列表。查询时直接取value的前K个即可。对于近似最近邻搜索可以用局部敏感哈希LSH或者HNSW等算法把相似度检索的复杂度从O(N)降到O(logN)。但这些方法会引入近似误差需要根据业务对精度的要求来权衡。7. 相似度优化的进阶思路7.1 多行为融合的相似度单一行为的相似度往往不够全面。用户点击了一个物品可能只是被标题吸引但用户购买了一个物品说明他真的需要。把多种行为融合起来算相似度通常比单行为效果好。融合的方法有两种前置融合和后置融合。前置融合是在构建交互矩阵时就把多种行为加权合并成一个综合交互强度。后置融合是分别算每种行为的相似度然后加权平均。我倾向于前置融合因为实现简单而且能保持相似度矩阵的稀疏性。后置融合会产生多个相似度矩阵存储和计算成本都高。7.2 基于图嵌入的相似度把用户-物品交互看成二部图用Graph Embedding的方法如DeepWalk、Node2Vec学习物品的向量表示然后用向量余弦相似度代替原始的共现相似度。这种方法的优势是能捕捉高阶相似关系两个物品即使没有共同交互用户但通过多跳路径连接也能学到相似的向量。我在一个内容推荐项目里试过这个方法对于长尾物品的召回效果提升明显。但缺点是训练成本高而且需要调参的地方多不如传统相似度方法稳定。7.3 相似度的在线学习与自适应调整相似度矩阵不一定要静态的。可以根据线上反馈实时调整相似度。比如一个推荐结果被用户点击了说明这个推荐是好的可以增强对应物品对的相似度如果被忽略了可以减弱相似度。这种在线学习的方法实现复杂度高而且容易陷入反馈循环。我的建议是谨慎使用至少要有充分的离线评估和AB实验验证。8. 我踩过的那些坑说几个我在实际项目里踩过的坑都是文档里不会写的。第一个坑是忽略了交互矩阵的时间维度。早期做ItemCF的时候我把所有历史交互一视同仁结果推荐结果里出现了很多用户很久以前喜欢但现在可能已经不喜欢的东西。后来加了时间衰减效果明显改善。时间衰减的系数需要根据业务调整快消品衰减快耐用品衰减慢。第二个坑是相似度矩阵更新太频繁。有一段时间我们每小时更新一次相似度矩阵结果发现效果反而下降了。原因是频繁更新引入了噪声物品相似度在短时间内波动太大推荐结果不稳定。后来改成每天更新一次白天只做增量效果就稳定了。第三个坑是Top-K的K值设得太大。一开始觉得K越大召回越全设了500。结果召回阶段候选集太大排序阶段压力大而且引入了很多弱相关的物品最终CTR反而下降。后来把K降到50配合更好的相似度计算效果反而更好。K值不是越大越好关键是相似度的质量。第四个坑是忘了做相似度的对称化处理。余弦相似度是对称的但有些相似度度量比如基于KL散度的不是对称的。如果用了非对称相似度检索的时候要注意方向。我见过一个团队用非对称相似度但按对称矩阵存储导致一半的相似度值是错的。第五个坑是相似度矩阵没有做归一化。不同物品的相似度分布范围不一样有的物品相似度普遍偏高有的普遍偏低。如果不做归一化打分的时候热门物品会占优势。我通常会对每个物品的相似度向量做L2归一化或者最大最小值归一化。9. 相似度计算的性能优化清单最后整理一份性能优化的检查清单都是实际项目中验证有效的交互矩阵用稀疏存储CSR或CSC格式比稠密矩阵省几十倍内存相似度计算用分块矩阵乘法避免一次性加载全量数据Top-K截断在聚合阶段就做不要等全量算完再截断边算边截断用整数索引代替字符串ID相似度计算是数值密集型的字符串ID会拖慢速度相似度值用float32而不是float64精度损失可忽略内存和计算速度提升明显并行度根据数据量调整数据量小的时候并行度太高反而慢因为调度开销大相似度矩阵缓存到内存或SSD不要每次推荐都重新算离线算好存起来定期监控相似度矩阵的稀疏度和分布发现异常及时排查这些优化手段不是每个都需要用根据你的数据规模和性能要求选择。小规模数据物品数10万基本不需要做太多优化单机就能跑。大规模数据物品数100万就需要认真做工程优化了。我在实际项目中的体会是相似度计算这件事理解原理比调包重要数据质量比算法复杂重要工程实现比理论推导重要。很多团队花大量时间研究新的相似度公式但忽略了交互数据的清洗和加权最后效果还不如把数据质量做好。先把基础打牢再考虑进阶优化这个顺序不能反。
