推荐系统这个领域很多人一上来就被各种深度模型、双塔、序列建模吓住了觉得门槛高得不行。但真正在生产环境里跑过推荐业务的人都知道协同过滤才是那个地基——尤其是基于邻域的方法UserCF和ItemCF这两条路线至今仍然是很多中小规模场景下性价比最高的方案。我见过不少团队数据量还没到千万级就开始硬上复杂模型结果效果还不如老老实实调一版ItemCF来得实在。这篇内容就是想把基于邻域的协同过滤从头到尾讲透包括它到底在算什么、UserCF和ItemCF的本质区别在哪、实际落地时相似度怎么选、参数怎么调、有哪些坑是文档里不会写的。不管你是刚接触推荐系统的新手还是想回头把基础打牢的从业者这篇都值得花时间看完。1. 基于邻域的协同过滤到底在解决什么问题1.1 从物以类聚、人以群分说起协同过滤的核心思想其实特别朴素利用群体行为来预测个体偏好。你之所以会喜欢某样东西大概率是因为和你口味相似的人也喜欢它或者和你之前喜欢的那些东西相似的物品你也会感兴趣。这个逻辑放到推荐系统里就衍生出了两条完全不同的技术路线。基于邻域的方法Neighborhood-based是协同过滤里最经典、最直观的一类实现。它不需要训练复杂的参数模型核心工作就是维护一个用户-物品的交互矩阵然后通过计算相似度来找到邻居最后用邻居的偏好来生成推荐。你可以把它理解成一个超级加强版的看了又看和买了又买只不过背后的计算逻辑更加严谨。为什么叫基于邻域因为整个算法的关键就在于定义并利用一个局部邻域——要么是和你相似的一群用户要么是和你交互过的物品相似的一群物品。这个邻域的大小、相似度的度量方式、最终聚合的策略决定了推荐质量的上限。1.2 UserCF和ItemCF的分野一个根本性的视角差异UserCF和ItemCF虽然都属于基于邻域的方法但它们看待问题的视角截然不同。UserCF基于用户的协同过滤的思路是先找到和你兴趣相似的一批用户然后看这批人还喜欢什么你没见过的物品把这些物品推荐给你。它的核心是人找人——你和我口味像你喜欢的东西我也大概率喜欢。ItemCF基于物品的协同过滤的思路则是先看你历史上喜欢过哪些物品然后找到和这些物品相似的其它物品推荐给你。它的核心是物找物——你喜欢A而A和B很像那你大概率也会喜欢B。这个视角差异看起来简单但在实际工程中会导致完全不同的系统行为。我举个具体的例子你就明白了假设一个电商平台用户A买了一个手机壳UserCF会去找也买了手机壳的其他用户然后推荐那些人买的其它东西而ItemCF会去找和这个手机壳相似的其它手机壳或配件然后推荐给用户A。前者依赖用户群体的行为模式后者依赖物品之间的关联强度。1.3 为什么2024年了还要聊基于邻域的方法你可能会问现在大模型都这么强了还聊这种古老的方法有意义吗我的回答是非常有意义而且在很多场景下它仍然是最优解。第一基于邻域的方法可解释性极强。当系统告诉你因为你喜欢A所以推荐B或者和你相似的用户也喜欢C时这个推荐理由是用户能直接理解的。相比之下深度模型的推荐理由往往是一堆隐向量的内积你根本没法跟用户解释。第二冷启动和增量更新友好。新用户来了只要有几条行为就能找到邻居新物品上架只要有人交互就能被推荐出去。不需要重新训练整个模型。第三工程实现简单维护成本低。没有GPU也能跑没有复杂的特征工程也能work对于中小团队来说这是能快速上线并产生业务价值的方案。第四它常常是深度模型的重要基线。如果你连ItemCF都跑不赢那说明你的深度模型大概率有问题。很多团队在论文里报告的巨大提升其实是因为基线选得太弱。2. UserCF的完整计算链路与工程实现细节2.1 用户相似度计算的几种主流方案UserCF的第一步是计算用户之间的相似度。给定一个用户-物品交互矩阵每一行代表一个用户对所有物品的交互记录通常是0/1或者评分我们要衡量两个用户行向量之间的相似程度。最常用的三种相似度度量方式余弦相似度Cosine Similarity是最直观的选择。它衡量的是两个向量在方向上的接近程度对向量的绝对长度不敏感。公式是sim(u, v) |N(u) ∩ N(v)| / sqrt(|N(u)| * |N(v)|)其中N(u)是用户u交互过的物品集合。这个公式的好处是天然做了归一化不会因为某个用户交互的物品特别多就导致相似度虚高。皮尔逊相关系数Pearson Correlation则更进一步它先减去每个用户的平均评分再计算余弦相似度。这样做的好处是能消除不同用户评分尺度不同带来的偏差——有的人打分普遍偏高有的人普遍偏低皮尔逊系数能部分修正这个问题。但它的前提是用户对物品有显式评分如果是隐式反馈点击、浏览这个方法的优势就不明显了。Jaccard相似度适用于纯二元交互场景它只关心交集和并集的比例sim(u, v) |N(u) ∩ N(v)| / |N(u) ∪ N(v)|Jaccard的问题在于它没有考虑热门物品的影响——两个用户都买过纸巾和矿泉水这种大众商品并不代表他们兴趣相似。2.2 相似度计算中的归一化与热门惩罚直接用上面的公式算相似度会遇到一个很实际的问题热门物品会主导相似度计算。两个用户都买过爆款商品并不代表他们口味相近可能只是因为这个商品太火了谁都会买。解决这个问题的经典做法是引入逆文档频率IDF式的惩罚项。具体来说在计算交集时对每个共同交互的物品除以它的流行度对数sim(u, v) Σ(i∈N(u)∩N(v)) 1 / log(1 |N(i)|) / sqrt(|N(u)| * |N(v)|)其中|N(i)|是交互过物品i的用户数量。这个惩罚项的效果是共同交互了一个冷门物品对相似度的贡献远大于共同交互了一个热门物品。这个改进在实际业务中带来的效果提升非常明显我实测过在新闻推荐场景下加了热门惩罚之后推荐结果的多样性提升了将近30%。另一个需要注意的点是相似度矩阵的稀疏性。用户数量一多两两计算相似度的复杂度是O(U²)而且大部分用户之间根本没有共同交互相似度为0。工程上通常的做法是先用倒排索引物品到用户的映射来快速找到有共同交互的用户对只对这些用户对计算相似度避免全量计算。2.3 从邻居到推荐列表聚合策略的选择有了用户相似度矩阵之后下一步就是为目标用户生成推荐。基本流程是找到和目标用户最相似的K个用户K通常取20到200之间收集这K个用户交互过、但目标用户没交互过的物品对每个候选物品用邻居的相似度加权计算推荐分数按分数排序取Top-N作为推荐结果推荐分数的计算公式score(u, i) Σ(v∈S(u,K)∩N(i)) sim(u, v) * r(v, i)其中S(u,K)是和u最相似的K个用户N(i)是交互过物品i的用户集合r(v,i)是用户v对物品i的交互记录隐式反馈通常取1。这里有一个工程上的细节值得展开K值的选择。K太小邻居不够推荐覆盖面窄K太大会引入不相关的邻居降低推荐精度。我的经验是在用户量百万级、物品量十万级的场景下K取40到80之间比较稳妥。但这不是绝对的需要根据你的数据稀疏度和业务特点来调。一个实用的方法是先固定其它参数让K从10到200遍历观察召回率和准确率的变化曲线找到那个拐点。还有一个容易被忽略的点是推荐结果的去重和打散。如果多个邻居都交互了同一个物品这个物品的分数会很高但推荐列表里不应该出现重复物品。另外如果推荐列表里全是同一类目的物品用户体验会很差需要做类目打散。2.4 UserCF的适用边界什么时候该用它UserCF并不是万能的它有明确的适用场景和局限性。适合的场景用户数量相对较少、用户兴趣比较稳定、物品更新频率高的场景。比如新闻推荐、短视频推荐因为物品新闻、视频更新极快ItemCF需要频繁重新计算物品相似度而UserCF的用户相似度相对稳定更新成本更低。不适合的场景用户数量远大于物品数量的场景。比如电商平台用户可能上亿物品只有几百万这时候计算用户相似度矩阵的代价太高而且用户兴趣变化快相似度矩阵需要频繁更新。这种情况下ItemCF更合适。还有一个实际问题是用户兴趣的漂移。一个用户上个月喜欢看健身内容这个月可能迷上了烹饪。UserCF基于历史行为计算相似度如果不做时间衰减推荐结果会滞后于用户当前兴趣。工程上的做法是引入时间衰减因子让近期的交互在相似度计算中占更大权重。3. ItemCF的工程落地从相似度矩阵到线上服务3.1 物品相似度的计算逻辑与UserCF的本质差异ItemCF计算的是物品之间的相似度而不是用户之间的相似度。给定一个用户-物品交互矩阵每一列代表一个物品被哪些用户交互过我们要衡量两个物品列向量之间的相似程度。公式上和UserCF是对称的sim(i, j) |N(i) ∩ N(j)| / sqrt(|N(i)| * |N(j)|)其中N(i)是交互过物品i的用户集合。同样可以加入热门惩罚sim(i, j) Σ(u∈N(i)∩N(j)) 1 / log(1 |N(u)|) / sqrt(|N(i)| * |N(j)|)注意这里的惩罚项变成了对活跃用户的惩罚——一个用户如果交互过大量物品那他对物品相似度的贡献应该被降低。这和UserCF中对热门物品的惩罚是对偶的。ItemCF和UserCF最本质的差异在于ItemCF的相似度矩阵更稳定。物品的属性、类别、受众群体相对固定两个物品之间的相似关系不会因为某个用户的兴趣变化而剧烈波动。这意味着ItemCF的相似度矩阵可以离线计算、定期更新线上服务只需要做查表和加权聚合响应速度极快。3.2 相似度矩阵的离线计算与存储方案在实际工程中ItemCF的相似度矩阵通常是离线计算的。具体流程从数据仓库中拉取最近N天的用户行为数据构建用户-物品交互矩阵用倒排索引加速相似度计算只计算有共同交互的物品对对每个物品保留最相似的Top-K个物品K通常取100到500将相似度矩阵存入KV存储或倒排索引中供线上服务查询这里有几个工程上的关键决策点相似度矩阵的截断。全量的物品相似度矩阵是O(I²)的I是物品数量。如果物品有100万这个矩阵根本存不下。所以必须做截断每个物品只保留Top-K个最相似的物品。K的选择需要平衡推荐质量和存储成本。我的经验是K取200左右能覆盖大部分推荐需求存储成本也可控。相似度的归一化。不同物品的相似度分布可能差异很大有的物品和很多物品都相似有的物品只和少数物品相似。如果不做归一化热门物品的相似物品会主导推荐结果。常见的做法是对每个物品的相似度向量做L2归一化或者用最大相似度做缩放。增量更新策略。全量重算相似度矩阵的代价很高尤其是物品数量大的时候。工程上通常采用全量增量的策略每天凌晨做一次全量计算白天用增量数据做局部更新。增量更新的逻辑是当有新交互产生时只更新涉及到的物品对的相似度而不是重算整个矩阵。3.3 线上推荐服务的架构设计ItemCF的线上服务架构相对简单核心就是一个查表聚合的过程获取用户最近交互过的N个物品N通常取10到50对每个物品从相似度矩阵中查出Top-K个相似物品将这些相似物品合并用相似度加权计算推荐分数过滤掉用户已经交互过的物品按分数排序取Top-N返回推荐分数的计算公式score(u, j) Σ(i∈N(u)) sim(i, j) * r(u, i)其中N(u)是用户u交互过的物品集合sim(i,j)是物品i和j的相似度r(u,i)是用户u对物品i的交互强度。这个架构的延迟主要取决于两个因素查相似度矩阵的次数等于用户交互物品数和每次查询返回的候选数量等于K。如果用户交互了50个物品每个物品查200个相似物品那就是10000个候选需要在毫秒级完成排序和过滤。工程上的优化手段包括用布隆过滤器快速判断物品是否已被交互、用堆排序代替全排序、对相似度矩阵做量化压缩等。3.4 ItemCF在实际业务中的调参经验ItemCF看起来简单但实际调参有很多门道。以下是我在多个项目中总结的经验相似度计算的时间窗口。用最近7天、30天还是90天的数据来计算相似度窗口太短相似度矩阵不稳定窗口太长会引入过时的关联。我的经验是对于快消品电商7到14天比较合适对于图书、家电这类长决策周期的品类30到90天更好。交互强度的加权。不是所有的交互都同等重要。购买比加购重要加购比收藏重要收藏比浏览重要。在计算推荐分数时应该给不同行为赋予不同的权重。一个常用的权重方案是购买5加购3收藏2浏览1。这个权重需要根据业务特点来调。相似度的阈值过滤。相似度太低的物品对不应该被推荐。通常设置一个阈值比如0.1低于这个值的相似物品直接丢弃。这样可以避免推荐一些完全不相关的物品提升推荐精度。类目约束。有时候业务上希望推荐结果集中在某些类目或者强制跨类目推荐。这需要在候选生成阶段做过滤或者在排序阶段加类目权重。实时特征的融合。纯ItemCF只用了用户的历史交互没有考虑实时上下文。可以在排序阶段融合实时特征比如用户当前会话的行为、时间、地点等提升推荐的时效性。4. UserCF与ItemCF的选型对比与融合策略4.1 一张表看清两种方法的适用场景对比维度UserCFItemCF核心逻辑找相似用户推荐他们喜欢的物品找相似物品推荐给用户相似度矩阵规模O(U²)用户数平方O(I²)物品数平方矩阵稳定性较低用户兴趣会漂移较高物品关联相对稳定冷启动表现新用户友好新物品不友好新物品友好新用户不友好可解释性和你相似的人也在看因为你看了A所以推荐B实时性较差需要更新用户相似度较好相似度矩阵可离线预计算适合场景新闻、短视频、社交电商、视频、音乐计算复杂度较高用户数通常很大较低物品数通常可控这张表不是绝对的实际选型还要看具体的数据规模和业务特点。但有一个经验法则用户数远大于物品数时选ItemCF物品数远大于用户数时选UserCF。因为你要计算的是较小那一侧的相似度矩阵。4.2 混合推荐让两种方法互补在实际系统中UserCF和ItemCF往往不是二选一而是融合使用。常见的融合策略有加权融合。分别用UserCF和ItemCF生成推荐列表然后按权重合并。权重的确定可以通过离线实验找到使AUC或NDCG最大的权重组合。通常ItemCF的权重会更高一些因为它的推荐结果更稳定。切换融合。根据用户的状态动态选择。新用户用UserCF因为缺乏历史交互ItemCF无法工作老用户用ItemCF因为历史充分ItemCF更精准。这个切换逻辑需要根据用户交互数量来定阈值。级联融合。先用一种方法做粗排再用另一种方法做精排。比如先用UserCF召回一批候选再用ItemCF的相似度做精排。这种方式的优势是能结合两种方法的优点但工程复杂度更高。特征融合。把UserCF和ItemCF的推荐分数作为特征输入到一个排序模型中让模型学习最优的融合方式。这是最灵活的方式但需要有一个排序模型。4.3 相似度计算的进阶优化基础的余弦相似度在很多场景下够用但如果你想让效果更进一步可以尝试以下优化基于共同交互数量的惩罚。两个用户只共同交互了1个物品和共同交互了10个物品相似度的可信度是完全不同的。可以引入一个置信度因子共同交互数量越多相似度越可信。时间衰减。近期的交互应该比久远的交互更重要。可以对每个交互乘以一个时间衰减因子比如exp(-λ * Δt)其中Δt是交互距今的时间。基于图的相似度。把用户和物品看作二部图中的节点用户和物品之间的交互是边。相似度可以通过随机游走、PageRank等图算法来计算。这种方法能捕捉到更高阶的关联但计算复杂度也更高。基于嵌入的相似度。用矩阵分解或神经网络学习用户和物品的隐向量然后用隐向量的内积或余弦相似度来衡量相似程度。这种方法能缓解数据稀疏问题但失去了基于邻域方法的可解释性。5. 实战中那些文档不会告诉你的坑5.1 数据稀疏与长尾问题协同过滤最大的敌人是数据稀疏。在真实的推荐场景中用户-物品交互矩阵的稀疏度通常在99%以上也就是说绝大部分用户和物品之间没有交互记录。这会导致两个严重后果相似度计算不可靠。两个用户只共同交互了1个物品算出来的相似度可能是1.0但这个相似度完全没有统计意义。解决方法是设置一个最小共同交互数量的阈值低于这个阈值的相似度直接置零。长尾物品得不到推荐。热门物品有大量交互容易找到相似物品长尾物品交互稀少相似度矩阵中几乎没有它的位置。这会导致推荐结果越来越集中在头部物品形成马太效应。解决方法是引入探索机制给长尾物品一定的曝光机会或者用基于内容的相似度来补充协同相似度。5.2 相似度矩阵的更新频率与时效性相似度矩阵的更新频率是一个需要仔细权衡的问题。更新太频繁计算成本高更新太慢推荐结果会过时。我的经验是根据业务的变化速度来定。新闻类应用物品新闻的生命周期可能只有几小时相似度矩阵需要小时级更新电商类应用物品的生命周期是几天到几周天级更新就够了图书、音乐类应用物品的生命周期是几个月到几年周级更新也可以接受。另一个技巧是分层更新。热门物品的相似度变化快可以高频更新长尾物品的相似度变化慢可以低频更新。这样能在保证效果的同时降低计算成本。5.3 推荐结果的多样性与惊喜度纯协同过滤的推荐结果往往缺乏多样性。因为算法本质上是找相似的所以推荐结果会集中在用户已经表现出兴趣的领域。这会导致信息茧房问题——用户越看越窄越窄越看。提升多样性的方法有几种在候选生成阶段引入随机性。不是严格取Top-K相似物品而是从Top-K中随机采样。这样能增加推荐结果的多样性但可能会降低短期点击率。在排序阶段做打散。对推荐列表做类目打散、作者打散等避免同一类目的物品连续出现。引入探索与利用的平衡。用多臂老虎机或强化学习的框架在推荐已知用户喜欢的物品利用和推荐用户可能喜欢的新物品探索之间做平衡。5.4 评估指标的选择与离线在线一致性协同过滤的评估指标有很多选错了指标会导致优化方向错误。离线指标常用的有准确率Precision、召回率Recall、F1值、AUC、NDCG、MAP、Hit Rate等。这些指标各有侧重需要根据业务目标来选择。如果业务关心推荐列表里有多少是用户真正喜欢的用准确率如果关心用户喜欢的物品有多少被推荐出来了用召回率如果关心排序质量用NDCG或MAP。在线指标包括点击率CTR、转化率CVR、人均点击次数、停留时长、留存率等。离线指标和在线指标往往不完全一致这是推荐系统的一个经典难题。我的经验是离线指标用来做粗筛和快速迭代在线指标才是最终裁判。不要过度优化离线指标而忽略了在线效果。还有一个容易被忽略的点是评估时的数据泄露。如果用未来的数据来评估模型结果会虚高。正确的做法是按时间划分训练集和测试集用过去的数据预测未来的行为。5.5 工程实现中的性能陷阱最后聊几个工程实现中容易踩的性能坑相似度矩阵的内存占用。如果物品有100万每个物品保留200个相似物品每个相似度用4字节浮点数存储那就是100万 * 200 * 4 800MB。这还只是相似度值如果加上物品ID的索引内存占用会更大。解决方案是用量化压缩比如用2字节存储相似度、用稀疏存储格式、或者把相似度矩阵放在SSD上。线上服务的延迟。ItemCF的线上服务需要查多次相似度矩阵如果每次查询都有网络开销延迟会很高。解决方案是把相似度矩阵加载到本地内存或者用Redis等内存数据库做缓存。冷启动的处理。新用户没有历史交互ItemCF无法工作。这时候需要降级到热门推荐或基于内容的推荐。新物品没有交互记录无法被ItemCF召回。这时候需要用基于内容的相似度来补充或者给新物品一定的探索流量。并发更新的问题。如果相似度矩阵在线上服务运行期间更新需要保证读写的一致性。常见的做法是双缓冲维护两份相似度矩阵一份在线服务一份离线更新更新完成后原子切换。6. 从零搭建一个可用的协同过滤推荐模块6.1 数据准备与交互矩阵构建假设你手头有一份用户行为日志包含用户ID、物品ID、行为类型、时间戳。第一步是把它转换成用户-物品交互矩阵。import pandas as pd import numpy as np from scipy.sparse import csr_matrix # 假设df是行为日志包含user_id, item_id, behavior_type, timestamp # 行为权重映射 behavior_weight { buy: 5.0, cart: 3.0, fav: 2.0, view: 1.0 } # 计算交互强度 df[weight] df[behavior_type].map(behavior_weight) # 对同一用户-物品对的多次交互取最大权重或累加 df_agg df.groupby([user_id, item_id])[weight].max().reset_index() # 构建用户和物品的索引映射 user_ids df_agg[user_id].unique() item_ids df_agg[item_id].unique() user_to_idx {uid: i for i, uid in enumerate(user_ids)} item_to_idx {iid: i for i, iid in enumerate(item_ids)} # 构建稀疏矩阵 rows df_agg[user_id].map(user_to_idx) cols df_agg[item_id].map(item_to_idx) values df_agg[weight] interaction_matrix csr_matrix( (values, (rows, cols)), shape(len(user_ids), len(item_ids)) )这段代码的关键点是行为权重的设计。不同行为的权重需要根据业务来定我给的是一组经验值实际使用时应该通过AB测试来调优。另外对同一用户-物品对的多次交互取最大值还是累加也需要根据业务来定。取最大值能避免刷行为导致的权重虚高累加则能反映用户的真实兴趣强度。6.2 相似度矩阵的高效计算有了交互矩阵之后计算物品相似度的核心代码如下from sklearn.preprocessing import normalize import numpy as np def compute_item_similarity(interaction_matrix, top_k200, min_common3): 计算物品相似度矩阵 interaction_matrix: 用户-物品交互矩阵 (U x I) top_k: 每个物品保留的相似物品数量 min_common: 最小共同交互用户数 # 转置得到物品-用户矩阵 item_user interaction_matrix.T # 对物品-用户矩阵做L2归一化 item_user_norm normalize(item_user, norml2, axis1) # 计算相似度矩阵 (I x I) # 注意这里用稀疏矩阵乘法避免稠密矩阵的内存爆炸 similarity item_user_norm item_user_norm.T # 将相似度矩阵转为稠密格式如果物品数量可控 similarity similarity.toarray() # 将对角线置零物品和自己的相似度 np.fill_diagonal(similarity, 0) # 对每个物品保留Top-K个相似物品 result {} for i in range(similarity.shape[0]): # 获取相似度最高的K个物品 top_indices np.argsort(similarity[i])[::-1][:top_k] top_scores similarity[i][top_indices] # 过滤掉相似度太低的 valid_mask top_scores 0.01 result[i] list(zip(top_indices[valid_mask], top_scores[valid_mask])) return result这段代码有几个工程上的优化点值得说明。第一用稀疏矩阵乘法代替循环计算速度能提升几十倍。第二对物品-用户矩阵做L2归一化这样矩阵乘法直接得到余弦相似度。第三只保留Top-K个相似物品避免存储全量相似度矩阵。但这段代码有一个问题没有做热门惩罚。如果要加入热门惩罚需要对交互矩阵做预处理对每个交互除以物品流行度的对数。这个操作可以在构建交互矩阵时完成。6.3 推荐列表的生成与后处理有了相似度矩阵之后生成推荐列表的逻辑如下def recommend(user_id, user_to_idx, item_to_idx, interaction_matrix, item_similarity, top_n50, history_n20): 为指定用户生成推荐列表 if user_id not in user_to_idx: return [] # 冷启动降级到热门推荐 user_idx user_to_idx[user_id] # 获取用户最近交互的N个物品 user_items interaction_matrix[user_idx].toarray().flatten() interacted_items np.where(user_items 0)[0] # 按交互强度排序取Top-N interacted_items interacted_items[ np.argsort(user_items[interacted_items])[::-1][:history_n] ] # 聚合相似物品的推荐分数 scores {} for item_idx in interacted_items: if item_idx not in item_similarity: continue weight user_items[item_idx] for sim_item, sim_score in item_similarity[item_idx]: if sim_item in scores: scores[sim_item] weight * sim_score else: scores[sim_item] weight * sim_score # 过滤掉用户已经交互过的物品 for item_idx in interacted_items: scores.pop(item_idx, None) # 按分数排序取Top-N sorted_items sorted(scores.items(), keylambda x: x[1], reverseTrue)[:top_n] # 转换回原始物品ID idx_to_item {v: k for k, v in item_to_idx.items()} return [(idx_to_item[idx], score) for idx, score in sorted_items]这段代码里有一个细节需要注意用户历史交互物品的选取。我取了最近交互的Top-N个物品而不是全部历史。这样做有两个好处一是降低计算量二是聚焦用户近期兴趣。N的取值需要根据用户平均交互数量来定通常取10到50之间。另一个细节是推荐分数的归一化。不同用户的推荐分数尺度可能不同如果要做跨用户的比较或排序需要对分数做归一化。常见的做法是除以用户历史交互物品的数量或者做Min-Max归一化。6.4 离线评估与参数调优搭建好推荐模块之后需要做离线评估来验证效果和调参。核心的评估流程def evaluate_recommendation(interaction_matrix, item_similarity, test_users, top_n50, k_neighbors200): 离线评估推荐效果 precisions [] recalls [] ndcgs [] for user_idx in test_users: # 获取用户真实交互的物品测试集 user_items interaction_matrix[user_idx].toarray().flatten() ground_truth set(np.where(user_items 0)[0]) if len(ground_truth) 0: continue # 生成推荐列表 recommendations recommend_by_idx( user_idx, interaction_matrix, item_similarity, top_n ) rec_items set([item for item, _ in recommendations]) # 计算准确率和召回率 hits len(rec_items ground_truth) precision hits / len(rec_items) if rec_items else 0 recall hits / len(ground_truth) if ground_truth else 0 precisions.append(precision) recalls.append(recall) return { precision: np.mean(precisions), recall: np.mean(recalls), f1: 2 * np.mean(precisions) * np.mean(recalls) / (np.mean(precisions) np.mean(recalls) 1e-8) }调参的核心参数有三个相似度计算的Top-K、推荐时使用的历史物品数量、推荐列表长度。我的调参经验是相似度Top-K从50到500遍历观察召回率的变化。通常在200左右达到饱和。历史物品数量从5到50遍历观察准确率的变化。通常在20左右达到最优。推荐列表长度根据业务需求定通常50到200之间。需要注意的是离线评估的结果和在线效果往往有差距。离线评估主要用来做粗筛和快速迭代最终的参数确定还是要靠在线AB测试。7. 一些个人体会协同过滤这套东西看起来简单但真正做好需要大量的细节打磨。我见过太多团队算法选型没问题但效果就是上不去问题往往出在数据质量、参数调优、工程实现这些脏活累活上。一个很深的体会是不要迷信算法要迷信数据。同样的ItemCF用干净的行为数据跑出来的效果可能比用脏数据跑出来的复杂模型还要好。所以在做推荐之前先把数据清洗做好把刷单、爬虫、异常行为过滤掉这比换算法带来的提升大得多。另一个体会是推荐系统的效果是迭代出来的不是设计出来的。不要指望一次就把所有参数调到最优先上线一个能用的版本收集线上反馈然后持续迭代。每次迭代只改一个变量观察效果变化这样才能积累出对系统的直觉。最后基于邻域的协同过滤虽然老但它的思想——利用群体智慧来预测个体偏好——是推荐系统永恒的核心。理解了这一点再去学矩阵分解、深度模型你会发现它们本质上都在做同一件事只是用了更复杂的工具而已。 
长河君 · 2026/10/15 16:06:45 · 阅读 1.2k 基于邻域的协同过滤：UserCF与ItemCF原理、调参及工程实践
推荐系统这个领域很多人一上来就被各种深度模型、双塔、序列建模吓住了觉得门槛高得不行。但真正在生产环境里跑过推荐业务的人都知道协同过滤才是那个地基——尤其是基于邻域的方法UserCF和ItemCF这两条路线至今仍然是很多中小规模场景下性价比最高的方案。我见过不少团队数据量还没到千万级就开始硬上复杂模型结果效果还不如老老实实调一版ItemCF来得实在。这篇内容就是想把基于邻域的协同过滤从头到尾讲透包括它到底在算什么、UserCF和ItemCF的本质区别在哪、实际落地时相似度怎么选、参数怎么调、有哪些坑是文档里不会写的。不管你是刚接触推荐系统的新手还是想回头把基础打牢的从业者这篇都值得花时间看完。1. 基于邻域的协同过滤到底在解决什么问题1.1 从物以类聚、人以群分说起协同过滤的核心思想其实特别朴素利用群体行为来预测个体偏好。你之所以会喜欢某样东西大概率是因为和你口味相似的人也喜欢它或者和你之前喜欢的那些东西相似的物品你也会感兴趣。这个逻辑放到推荐系统里就衍生出了两条完全不同的技术路线。基于邻域的方法Neighborhood-based是协同过滤里最经典、最直观的一类实现。它不需要训练复杂的参数模型核心工作就是维护一个用户-物品的交互矩阵然后通过计算相似度来找到邻居最后用邻居的偏好来生成推荐。你可以把它理解成一个超级加强版的看了又看和买了又买只不过背后的计算逻辑更加严谨。为什么叫基于邻域因为整个算法的关键就在于定义并利用一个局部邻域——要么是和你相似的一群用户要么是和你交互过的物品相似的一群物品。这个邻域的大小、相似度的度量方式、最终聚合的策略决定了推荐质量的上限。1.2 UserCF和ItemCF的分野一个根本性的视角差异UserCF和ItemCF虽然都属于基于邻域的方法但它们看待问题的视角截然不同。UserCF基于用户的协同过滤的思路是先找到和你兴趣相似的一批用户然后看这批人还喜欢什么你没见过的物品把这些物品推荐给你。它的核心是人找人——你和我口味像你喜欢的东西我也大概率喜欢。ItemCF基于物品的协同过滤的思路则是先看你历史上喜欢过哪些物品然后找到和这些物品相似的其它物品推荐给你。它的核心是物找物——你喜欢A而A和B很像那你大概率也会喜欢B。这个视角差异看起来简单但在实际工程中会导致完全不同的系统行为。我举个具体的例子你就明白了假设一个电商平台用户A买了一个手机壳UserCF会去找也买了手机壳的其他用户然后推荐那些人买的其它东西而ItemCF会去找和这个手机壳相似的其它手机壳或配件然后推荐给用户A。前者依赖用户群体的行为模式后者依赖物品之间的关联强度。1.3 为什么2024年了还要聊基于邻域的方法你可能会问现在大模型都这么强了还聊这种古老的方法有意义吗我的回答是非常有意义而且在很多场景下它仍然是最优解。第一基于邻域的方法可解释性极强。当系统告诉你因为你喜欢A所以推荐B或者和你相似的用户也喜欢C时这个推荐理由是用户能直接理解的。相比之下深度模型的推荐理由往往是一堆隐向量的内积你根本没法跟用户解释。第二冷启动和增量更新友好。新用户来了只要有几条行为就能找到邻居新物品上架只要有人交互就能被推荐出去。不需要重新训练整个模型。第三工程实现简单维护成本低。没有GPU也能跑没有复杂的特征工程也能work对于中小团队来说这是能快速上线并产生业务价值的方案。第四它常常是深度模型的重要基线。如果你连ItemCF都跑不赢那说明你的深度模型大概率有问题。很多团队在论文里报告的巨大提升其实是因为基线选得太弱。2. UserCF的完整计算链路与工程实现细节2.1 用户相似度计算的几种主流方案UserCF的第一步是计算用户之间的相似度。给定一个用户-物品交互矩阵每一行代表一个用户对所有物品的交互记录通常是0/1或者评分我们要衡量两个用户行向量之间的相似程度。最常用的三种相似度度量方式余弦相似度Cosine Similarity是最直观的选择。它衡量的是两个向量在方向上的接近程度对向量的绝对长度不敏感。公式是sim(u, v) |N(u) ∩ N(v)| / sqrt(|N(u)| * |N(v)|)其中N(u)是用户u交互过的物品集合。这个公式的好处是天然做了归一化不会因为某个用户交互的物品特别多就导致相似度虚高。皮尔逊相关系数Pearson Correlation则更进一步它先减去每个用户的平均评分再计算余弦相似度。这样做的好处是能消除不同用户评分尺度不同带来的偏差——有的人打分普遍偏高有的人普遍偏低皮尔逊系数能部分修正这个问题。但它的前提是用户对物品有显式评分如果是隐式反馈点击、浏览这个方法的优势就不明显了。Jaccard相似度适用于纯二元交互场景它只关心交集和并集的比例sim(u, v) |N(u) ∩ N(v)| / |N(u) ∪ N(v)|Jaccard的问题在于它没有考虑热门物品的影响——两个用户都买过纸巾和矿泉水这种大众商品并不代表他们兴趣相似。2.2 相似度计算中的归一化与热门惩罚直接用上面的公式算相似度会遇到一个很实际的问题热门物品会主导相似度计算。两个用户都买过爆款商品并不代表他们口味相近可能只是因为这个商品太火了谁都会买。解决这个问题的经典做法是引入逆文档频率IDF式的惩罚项。具体来说在计算交集时对每个共同交互的物品除以它的流行度对数sim(u, v) Σ(i∈N(u)∩N(v)) 1 / log(1 |N(i)|) / sqrt(|N(u)| * |N(v)|)其中|N(i)|是交互过物品i的用户数量。这个惩罚项的效果是共同交互了一个冷门物品对相似度的贡献远大于共同交互了一个热门物品。这个改进在实际业务中带来的效果提升非常明显我实测过在新闻推荐场景下加了热门惩罚之后推荐结果的多样性提升了将近30%。另一个需要注意的点是相似度矩阵的稀疏性。用户数量一多两两计算相似度的复杂度是O(U²)而且大部分用户之间根本没有共同交互相似度为0。工程上通常的做法是先用倒排索引物品到用户的映射来快速找到有共同交互的用户对只对这些用户对计算相似度避免全量计算。2.3 从邻居到推荐列表聚合策略的选择有了用户相似度矩阵之后下一步就是为目标用户生成推荐。基本流程是找到和目标用户最相似的K个用户K通常取20到200之间收集这K个用户交互过、但目标用户没交互过的物品对每个候选物品用邻居的相似度加权计算推荐分数按分数排序取Top-N作为推荐结果推荐分数的计算公式score(u, i) Σ(v∈S(u,K)∩N(i)) sim(u, v) * r(v, i)其中S(u,K)是和u最相似的K个用户N(i)是交互过物品i的用户集合r(v,i)是用户v对物品i的交互记录隐式反馈通常取1。这里有一个工程上的细节值得展开K值的选择。K太小邻居不够推荐覆盖面窄K太大会引入不相关的邻居降低推荐精度。我的经验是在用户量百万级、物品量十万级的场景下K取40到80之间比较稳妥。但这不是绝对的需要根据你的数据稀疏度和业务特点来调。一个实用的方法是先固定其它参数让K从10到200遍历观察召回率和准确率的变化曲线找到那个拐点。还有一个容易被忽略的点是推荐结果的去重和打散。如果多个邻居都交互了同一个物品这个物品的分数会很高但推荐列表里不应该出现重复物品。另外如果推荐列表里全是同一类目的物品用户体验会很差需要做类目打散。2.4 UserCF的适用边界什么时候该用它UserCF并不是万能的它有明确的适用场景和局限性。适合的场景用户数量相对较少、用户兴趣比较稳定、物品更新频率高的场景。比如新闻推荐、短视频推荐因为物品新闻、视频更新极快ItemCF需要频繁重新计算物品相似度而UserCF的用户相似度相对稳定更新成本更低。不适合的场景用户数量远大于物品数量的场景。比如电商平台用户可能上亿物品只有几百万这时候计算用户相似度矩阵的代价太高而且用户兴趣变化快相似度矩阵需要频繁更新。这种情况下ItemCF更合适。还有一个实际问题是用户兴趣的漂移。一个用户上个月喜欢看健身内容这个月可能迷上了烹饪。UserCF基于历史行为计算相似度如果不做时间衰减推荐结果会滞后于用户当前兴趣。工程上的做法是引入时间衰减因子让近期的交互在相似度计算中占更大权重。3. ItemCF的工程落地从相似度矩阵到线上服务3.1 物品相似度的计算逻辑与UserCF的本质差异ItemCF计算的是物品之间的相似度而不是用户之间的相似度。给定一个用户-物品交互矩阵每一列代表一个物品被哪些用户交互过我们要衡量两个物品列向量之间的相似程度。公式上和UserCF是对称的sim(i, j) |N(i) ∩ N(j)| / sqrt(|N(i)| * |N(j)|)其中N(i)是交互过物品i的用户集合。同样可以加入热门惩罚sim(i, j) Σ(u∈N(i)∩N(j)) 1 / log(1 |N(u)|) / sqrt(|N(i)| * |N(j)|)注意这里的惩罚项变成了对活跃用户的惩罚——一个用户如果交互过大量物品那他对物品相似度的贡献应该被降低。这和UserCF中对热门物品的惩罚是对偶的。ItemCF和UserCF最本质的差异在于ItemCF的相似度矩阵更稳定。物品的属性、类别、受众群体相对固定两个物品之间的相似关系不会因为某个用户的兴趣变化而剧烈波动。这意味着ItemCF的相似度矩阵可以离线计算、定期更新线上服务只需要做查表和加权聚合响应速度极快。3.2 相似度矩阵的离线计算与存储方案在实际工程中ItemCF的相似度矩阵通常是离线计算的。具体流程从数据仓库中拉取最近N天的用户行为数据构建用户-物品交互矩阵用倒排索引加速相似度计算只计算有共同交互的物品对对每个物品保留最相似的Top-K个物品K通常取100到500将相似度矩阵存入KV存储或倒排索引中供线上服务查询这里有几个工程上的关键决策点相似度矩阵的截断。全量的物品相似度矩阵是O(I²)的I是物品数量。如果物品有100万这个矩阵根本存不下。所以必须做截断每个物品只保留Top-K个最相似的物品。K的选择需要平衡推荐质量和存储成本。我的经验是K取200左右能覆盖大部分推荐需求存储成本也可控。相似度的归一化。不同物品的相似度分布可能差异很大有的物品和很多物品都相似有的物品只和少数物品相似。如果不做归一化热门物品的相似物品会主导推荐结果。常见的做法是对每个物品的相似度向量做L2归一化或者用最大相似度做缩放。增量更新策略。全量重算相似度矩阵的代价很高尤其是物品数量大的时候。工程上通常采用全量增量的策略每天凌晨做一次全量计算白天用增量数据做局部更新。增量更新的逻辑是当有新交互产生时只更新涉及到的物品对的相似度而不是重算整个矩阵。3.3 线上推荐服务的架构设计ItemCF的线上服务架构相对简单核心就是一个查表聚合的过程获取用户最近交互过的N个物品N通常取10到50对每个物品从相似度矩阵中查出Top-K个相似物品将这些相似物品合并用相似度加权计算推荐分数过滤掉用户已经交互过的物品按分数排序取Top-N返回推荐分数的计算公式score(u, j) Σ(i∈N(u)) sim(i, j) * r(u, i)其中N(u)是用户u交互过的物品集合sim(i,j)是物品i和j的相似度r(u,i)是用户u对物品i的交互强度。这个架构的延迟主要取决于两个因素查相似度矩阵的次数等于用户交互物品数和每次查询返回的候选数量等于K。如果用户交互了50个物品每个物品查200个相似物品那就是10000个候选需要在毫秒级完成排序和过滤。工程上的优化手段包括用布隆过滤器快速判断物品是否已被交互、用堆排序代替全排序、对相似度矩阵做量化压缩等。3.4 ItemCF在实际业务中的调参经验ItemCF看起来简单但实际调参有很多门道。以下是我在多个项目中总结的经验相似度计算的时间窗口。用最近7天、30天还是90天的数据来计算相似度窗口太短相似度矩阵不稳定窗口太长会引入过时的关联。我的经验是对于快消品电商7到14天比较合适对于图书、家电这类长决策周期的品类30到90天更好。交互强度的加权。不是所有的交互都同等重要。购买比加购重要加购比收藏重要收藏比浏览重要。在计算推荐分数时应该给不同行为赋予不同的权重。一个常用的权重方案是购买5加购3收藏2浏览1。这个权重需要根据业务特点来调。相似度的阈值过滤。相似度太低的物品对不应该被推荐。通常设置一个阈值比如0.1低于这个值的相似物品直接丢弃。这样可以避免推荐一些完全不相关的物品提升推荐精度。类目约束。有时候业务上希望推荐结果集中在某些类目或者强制跨类目推荐。这需要在候选生成阶段做过滤或者在排序阶段加类目权重。实时特征的融合。纯ItemCF只用了用户的历史交互没有考虑实时上下文。可以在排序阶段融合实时特征比如用户当前会话的行为、时间、地点等提升推荐的时效性。4. UserCF与ItemCF的选型对比与融合策略4.1 一张表看清两种方法的适用场景对比维度UserCFItemCF核心逻辑找相似用户推荐他们喜欢的物品找相似物品推荐给用户相似度矩阵规模O(U²)用户数平方O(I²)物品数平方矩阵稳定性较低用户兴趣会漂移较高物品关联相对稳定冷启动表现新用户友好新物品不友好新物品友好新用户不友好可解释性和你相似的人也在看因为你看了A所以推荐B实时性较差需要更新用户相似度较好相似度矩阵可离线预计算适合场景新闻、短视频、社交电商、视频、音乐计算复杂度较高用户数通常很大较低物品数通常可控这张表不是绝对的实际选型还要看具体的数据规模和业务特点。但有一个经验法则用户数远大于物品数时选ItemCF物品数远大于用户数时选UserCF。因为你要计算的是较小那一侧的相似度矩阵。4.2 混合推荐让两种方法互补在实际系统中UserCF和ItemCF往往不是二选一而是融合使用。常见的融合策略有加权融合。分别用UserCF和ItemCF生成推荐列表然后按权重合并。权重的确定可以通过离线实验找到使AUC或NDCG最大的权重组合。通常ItemCF的权重会更高一些因为它的推荐结果更稳定。切换融合。根据用户的状态动态选择。新用户用UserCF因为缺乏历史交互ItemCF无法工作老用户用ItemCF因为历史充分ItemCF更精准。这个切换逻辑需要根据用户交互数量来定阈值。级联融合。先用一种方法做粗排再用另一种方法做精排。比如先用UserCF召回一批候选再用ItemCF的相似度做精排。这种方式的优势是能结合两种方法的优点但工程复杂度更高。特征融合。把UserCF和ItemCF的推荐分数作为特征输入到一个排序模型中让模型学习最优的融合方式。这是最灵活的方式但需要有一个排序模型。4.3 相似度计算的进阶优化基础的余弦相似度在很多场景下够用但如果你想让效果更进一步可以尝试以下优化基于共同交互数量的惩罚。两个用户只共同交互了1个物品和共同交互了10个物品相似度的可信度是完全不同的。可以引入一个置信度因子共同交互数量越多相似度越可信。时间衰减。近期的交互应该比久远的交互更重要。可以对每个交互乘以一个时间衰减因子比如exp(-λ * Δt)其中Δt是交互距今的时间。基于图的相似度。把用户和物品看作二部图中的节点用户和物品之间的交互是边。相似度可以通过随机游走、PageRank等图算法来计算。这种方法能捕捉到更高阶的关联但计算复杂度也更高。基于嵌入的相似度。用矩阵分解或神经网络学习用户和物品的隐向量然后用隐向量的内积或余弦相似度来衡量相似程度。这种方法能缓解数据稀疏问题但失去了基于邻域方法的可解释性。5. 实战中那些文档不会告诉你的坑5.1 数据稀疏与长尾问题协同过滤最大的敌人是数据稀疏。在真实的推荐场景中用户-物品交互矩阵的稀疏度通常在99%以上也就是说绝大部分用户和物品之间没有交互记录。这会导致两个严重后果相似度计算不可靠。两个用户只共同交互了1个物品算出来的相似度可能是1.0但这个相似度完全没有统计意义。解决方法是设置一个最小共同交互数量的阈值低于这个阈值的相似度直接置零。长尾物品得不到推荐。热门物品有大量交互容易找到相似物品长尾物品交互稀少相似度矩阵中几乎没有它的位置。这会导致推荐结果越来越集中在头部物品形成马太效应。解决方法是引入探索机制给长尾物品一定的曝光机会或者用基于内容的相似度来补充协同相似度。5.2 相似度矩阵的更新频率与时效性相似度矩阵的更新频率是一个需要仔细权衡的问题。更新太频繁计算成本高更新太慢推荐结果会过时。我的经验是根据业务的变化速度来定。新闻类应用物品新闻的生命周期可能只有几小时相似度矩阵需要小时级更新电商类应用物品的生命周期是几天到几周天级更新就够了图书、音乐类应用物品的生命周期是几个月到几年周级更新也可以接受。另一个技巧是分层更新。热门物品的相似度变化快可以高频更新长尾物品的相似度变化慢可以低频更新。这样能在保证效果的同时降低计算成本。5.3 推荐结果的多样性与惊喜度纯协同过滤的推荐结果往往缺乏多样性。因为算法本质上是找相似的所以推荐结果会集中在用户已经表现出兴趣的领域。这会导致信息茧房问题——用户越看越窄越窄越看。提升多样性的方法有几种在候选生成阶段引入随机性。不是严格取Top-K相似物品而是从Top-K中随机采样。这样能增加推荐结果的多样性但可能会降低短期点击率。在排序阶段做打散。对推荐列表做类目打散、作者打散等避免同一类目的物品连续出现。引入探索与利用的平衡。用多臂老虎机或强化学习的框架在推荐已知用户喜欢的物品利用和推荐用户可能喜欢的新物品探索之间做平衡。5.4 评估指标的选择与离线在线一致性协同过滤的评估指标有很多选错了指标会导致优化方向错误。离线指标常用的有准确率Precision、召回率Recall、F1值、AUC、NDCG、MAP、Hit Rate等。这些指标各有侧重需要根据业务目标来选择。如果业务关心推荐列表里有多少是用户真正喜欢的用准确率如果关心用户喜欢的物品有多少被推荐出来了用召回率如果关心排序质量用NDCG或MAP。在线指标包括点击率CTR、转化率CVR、人均点击次数、停留时长、留存率等。离线指标和在线指标往往不完全一致这是推荐系统的一个经典难题。我的经验是离线指标用来做粗筛和快速迭代在线指标才是最终裁判。不要过度优化离线指标而忽略了在线效果。还有一个容易被忽略的点是评估时的数据泄露。如果用未来的数据来评估模型结果会虚高。正确的做法是按时间划分训练集和测试集用过去的数据预测未来的行为。5.5 工程实现中的性能陷阱最后聊几个工程实现中容易踩的性能坑相似度矩阵的内存占用。如果物品有100万每个物品保留200个相似物品每个相似度用4字节浮点数存储那就是100万 * 200 * 4 800MB。这还只是相似度值如果加上物品ID的索引内存占用会更大。解决方案是用量化压缩比如用2字节存储相似度、用稀疏存储格式、或者把相似度矩阵放在SSD上。线上服务的延迟。ItemCF的线上服务需要查多次相似度矩阵如果每次查询都有网络开销延迟会很高。解决方案是把相似度矩阵加载到本地内存或者用Redis等内存数据库做缓存。冷启动的处理。新用户没有历史交互ItemCF无法工作。这时候需要降级到热门推荐或基于内容的推荐。新物品没有交互记录无法被ItemCF召回。这时候需要用基于内容的相似度来补充或者给新物品一定的探索流量。并发更新的问题。如果相似度矩阵在线上服务运行期间更新需要保证读写的一致性。常见的做法是双缓冲维护两份相似度矩阵一份在线服务一份离线更新更新完成后原子切换。6. 从零搭建一个可用的协同过滤推荐模块6.1 数据准备与交互矩阵构建假设你手头有一份用户行为日志包含用户ID、物品ID、行为类型、时间戳。第一步是把它转换成用户-物品交互矩阵。import pandas as pd import numpy as np from scipy.sparse import csr_matrix # 假设df是行为日志包含user_id, item_id, behavior_type, timestamp # 行为权重映射 behavior_weight { buy: 5.0, cart: 3.0, fav: 2.0, view: 1.0 } # 计算交互强度 df[weight] df[behavior_type].map(behavior_weight) # 对同一用户-物品对的多次交互取最大权重或累加 df_agg df.groupby([user_id, item_id])[weight].max().reset_index() # 构建用户和物品的索引映射 user_ids df_agg[user_id].unique() item_ids df_agg[item_id].unique() user_to_idx {uid: i for i, uid in enumerate(user_ids)} item_to_idx {iid: i for i, iid in enumerate(item_ids)} # 构建稀疏矩阵 rows df_agg[user_id].map(user_to_idx) cols df_agg[item_id].map(item_to_idx) values df_agg[weight] interaction_matrix csr_matrix( (values, (rows, cols)), shape(len(user_ids), len(item_ids)) )这段代码的关键点是行为权重的设计。不同行为的权重需要根据业务来定我给的是一组经验值实际使用时应该通过AB测试来调优。另外对同一用户-物品对的多次交互取最大值还是累加也需要根据业务来定。取最大值能避免刷行为导致的权重虚高累加则能反映用户的真实兴趣强度。6.2 相似度矩阵的高效计算有了交互矩阵之后计算物品相似度的核心代码如下from sklearn.preprocessing import normalize import numpy as np def compute_item_similarity(interaction_matrix, top_k200, min_common3): 计算物品相似度矩阵 interaction_matrix: 用户-物品交互矩阵 (U x I) top_k: 每个物品保留的相似物品数量 min_common: 最小共同交互用户数 # 转置得到物品-用户矩阵 item_user interaction_matrix.T # 对物品-用户矩阵做L2归一化 item_user_norm normalize(item_user, norml2, axis1) # 计算相似度矩阵 (I x I) # 注意这里用稀疏矩阵乘法避免稠密矩阵的内存爆炸 similarity item_user_norm item_user_norm.T # 将相似度矩阵转为稠密格式如果物品数量可控 similarity similarity.toarray() # 将对角线置零物品和自己的相似度 np.fill_diagonal(similarity, 0) # 对每个物品保留Top-K个相似物品 result {} for i in range(similarity.shape[0]): # 获取相似度最高的K个物品 top_indices np.argsort(similarity[i])[::-1][:top_k] top_scores similarity[i][top_indices] # 过滤掉相似度太低的 valid_mask top_scores 0.01 result[i] list(zip(top_indices[valid_mask], top_scores[valid_mask])) return result这段代码有几个工程上的优化点值得说明。第一用稀疏矩阵乘法代替循环计算速度能提升几十倍。第二对物品-用户矩阵做L2归一化这样矩阵乘法直接得到余弦相似度。第三只保留Top-K个相似物品避免存储全量相似度矩阵。但这段代码有一个问题没有做热门惩罚。如果要加入热门惩罚需要对交互矩阵做预处理对每个交互除以物品流行度的对数。这个操作可以在构建交互矩阵时完成。6.3 推荐列表的生成与后处理有了相似度矩阵之后生成推荐列表的逻辑如下def recommend(user_id, user_to_idx, item_to_idx, interaction_matrix, item_similarity, top_n50, history_n20): 为指定用户生成推荐列表 if user_id not in user_to_idx: return [] # 冷启动降级到热门推荐 user_idx user_to_idx[user_id] # 获取用户最近交互的N个物品 user_items interaction_matrix[user_idx].toarray().flatten() interacted_items np.where(user_items 0)[0] # 按交互强度排序取Top-N interacted_items interacted_items[ np.argsort(user_items[interacted_items])[::-1][:history_n] ] # 聚合相似物品的推荐分数 scores {} for item_idx in interacted_items: if item_idx not in item_similarity: continue weight user_items[item_idx] for sim_item, sim_score in item_similarity[item_idx]: if sim_item in scores: scores[sim_item] weight * sim_score else: scores[sim_item] weight * sim_score # 过滤掉用户已经交互过的物品 for item_idx in interacted_items: scores.pop(item_idx, None) # 按分数排序取Top-N sorted_items sorted(scores.items(), keylambda x: x[1], reverseTrue)[:top_n] # 转换回原始物品ID idx_to_item {v: k for k, v in item_to_idx.items()} return [(idx_to_item[idx], score) for idx, score in sorted_items]这段代码里有一个细节需要注意用户历史交互物品的选取。我取了最近交互的Top-N个物品而不是全部历史。这样做有两个好处一是降低计算量二是聚焦用户近期兴趣。N的取值需要根据用户平均交互数量来定通常取10到50之间。另一个细节是推荐分数的归一化。不同用户的推荐分数尺度可能不同如果要做跨用户的比较或排序需要对分数做归一化。常见的做法是除以用户历史交互物品的数量或者做Min-Max归一化。6.4 离线评估与参数调优搭建好推荐模块之后需要做离线评估来验证效果和调参。核心的评估流程def evaluate_recommendation(interaction_matrix, item_similarity, test_users, top_n50, k_neighbors200): 离线评估推荐效果 precisions [] recalls [] ndcgs [] for user_idx in test_users: # 获取用户真实交互的物品测试集 user_items interaction_matrix[user_idx].toarray().flatten() ground_truth set(np.where(user_items 0)[0]) if len(ground_truth) 0: continue # 生成推荐列表 recommendations recommend_by_idx( user_idx, interaction_matrix, item_similarity, top_n ) rec_items set([item for item, _ in recommendations]) # 计算准确率和召回率 hits len(rec_items ground_truth) precision hits / len(rec_items) if rec_items else 0 recall hits / len(ground_truth) if ground_truth else 0 precisions.append(precision) recalls.append(recall) return { precision: np.mean(precisions), recall: np.mean(recalls), f1: 2 * np.mean(precisions) * np.mean(recalls) / (np.mean(precisions) np.mean(recalls) 1e-8) }调参的核心参数有三个相似度计算的Top-K、推荐时使用的历史物品数量、推荐列表长度。我的调参经验是相似度Top-K从50到500遍历观察召回率的变化。通常在200左右达到饱和。历史物品数量从5到50遍历观察准确率的变化。通常在20左右达到最优。推荐列表长度根据业务需求定通常50到200之间。需要注意的是离线评估的结果和在线效果往往有差距。离线评估主要用来做粗筛和快速迭代最终的参数确定还是要靠在线AB测试。7. 一些个人体会协同过滤这套东西看起来简单但真正做好需要大量的细节打磨。我见过太多团队算法选型没问题但效果就是上不去问题往往出在数据质量、参数调优、工程实现这些脏活累活上。一个很深的体会是不要迷信算法要迷信数据。同样的ItemCF用干净的行为数据跑出来的效果可能比用脏数据跑出来的复杂模型还要好。所以在做推荐之前先把数据清洗做好把刷单、爬虫、异常行为过滤掉这比换算法带来的提升大得多。另一个体会是推荐系统的效果是迭代出来的不是设计出来的。不要指望一次就把所有参数调到最优先上线一个能用的版本收集线上反馈然后持续迭代。每次迭代只改一个变量观察效果变化这样才能积累出对系统的直觉。最后基于邻域的协同过滤虽然老但它的思想——利用群体智慧来预测个体偏好——是推荐系统永恒的核心。理解了这一点再去学矩阵分解、深度模型你会发现它们本质上都在做同一件事只是用了更复杂的工具而已。