关联规则与协同过滤：从原理到选型的推荐系统实战指南-北京尧图网络

1. 先搞清楚两件事一个算“一起买”一个算“像你的人”1.1 关联规则是找“购物篮里的规律”关联规则要做的事情说人话就是从一堆历史订单里找出“哪些东西经常被同时买”。这个思路最早来自线下零售的购物篮分析。顾客结账时收银台扫出来的那一串商品就是一个“购物篮”。当超市的啤酒和尿布经常出现在同一个篮子里就会产生一条规则“买了啤酒的人大概率也会买尿布”。这就是关联规则的核心表达方式用一句很简单的逻辑来描述它买了 A 的人有多大概率会买 B这条逻辑用形式化表达就是A - B意思是“从 A 可以推出 B”。注意这里的“推出”不是因果关系的推出而是“同时出现”的统计关联。啤酒和尿布之间没有任何因果关系但它们在数据上频繁共现就足以支撑一条运营策略把尿布促销信息和啤酒放到同一个推荐位。不少新手容易在这里犯迷糊以为关联规则学的是“用户的偏好”。其实它学的不是人而是商品之间的关系。整条规则里根本没有用户维度只有商品组合和组合出现的统计规律。这也是它和协同过滤最根本的分水岭关联规则不管你是谁、不管你的历史偏好它只看“哪些商品天生就喜欢凑在一起”。1.2 协同过滤是找“人跟人、物品跟物品的相似”协同过滤的名字翻译得不太好初次接触的人很容易被“协同”两个字带偏以为它是什么多人协作的算法。它其实指的是借用群体的行为来共同完成过滤也就是“大家一起帮你筛东西”。它有两个经典分支基于用户的协同过滤UserCF找出和你行为习惯相似的一群人把这些人喜欢而你没见过的物品推荐给你。基于物品的协同过滤ItemCF找出和你已经买过、看过、点过赞的物品相似的其它物品然后推给你。注意协同过滤里的“相似”是基于行为数据的相似不是基于商品属性的相似。两个商品被同一批人频繁一起买、一起看它们就算“行为相似”两个用户频繁对同样的物品产生正向反馈他们就算“行为相似”。所以协同过滤学的是“人或物品的邻居关系”。它天然依赖“用户-物品”的行为矩阵行列分别是人和物品格子里的值表示行为强度比如是否点击、是否购买、打了多少分。你可以这么理解关联规则关心的是“货架上的组合规律”协同过滤关心的是“人群中的品味圈层”。同样是推荐一瓶啤酒关联规则推它是因为啤酒和三文鱼经常出现在同一张订单里协同过滤推它是因为你所在的用户群普遍喜欢精酿而你还不知道这个牌子。1.3 一句话版本关联规则回答的问题是“买了它之后接下来还可能买什么”协同过滤回答的问题是“和我相似的人 / 和我喜欢的东西相似的东西到底是什么”这两种算法的输出形式也不同。关联规则输出的是“规则”比如“面包 - 黄油置信度 0.42”协同过滤输出的是一串带分数的物品排序比如给用户推荐列表[item7, item3, item9]每个物品带一个预测得分。这个区别决定了很多事关联规则的结果好解释运营可以直接看懂协同过滤的结果是个性化的每个人看到的都不一样但解释起来要费一番功夫。两者没有绝对的优劣只是解决的是不同层面的问题。2. 各自的核心指标到底在算什么2.1 关联规则的三件套支持度、置信度、提升度关联规则靠三个指标筛选和排序规则分别是支持度、置信度、提升度。这三个指标不是拍脑袋定的它们分别从“普遍性”“可靠性”“有效性”三个角度考核一条规则。先定义基础符号。假设我们有 N 条交易记录support(A)表示包含商品 A 的交易数量占全部交易数量的比例support(A∪B)表示同时包含 A 和 B 的交易比例。支持度Supportsupport(A - B) support(A ∪ B) A和B同时出现的订单数 / 总订单数支持度的含义是“这条规则覆盖了多少人”。如果啤酒和尿布只在 100 张订单里出现过 1 次那么支持度是 0.01说明这条规则虽然存在但能影响的人群太少了。实际项目中支持度太低意味着样本不足规则可能是噪声一般会设一个最小支持度阈值把它过滤掉。置信度Confidenceconfidence(A - B) support(A ∪ B) / support(A)置信度的含义是“买了 A 的人里面有多少人还买了 B”。假如买了啤酒的人里有 60% 也买了尿布那么啤酒 - 尿布的置信度就是 0.6。置信度越高说明 A 对 B 的预测能力越强规则越可靠。但置信度有个致命缺陷它不考虑 B 本身的热门程度。如果尿布本身就是一个高销量商品不管买不买啤酒所有订单里都有 50% 的订单包含尿布那么啤酒 - 尿布置信度 0.6 看起来很高实际比基准概率 0.5 只高了一点这个提升非常有限。所以单看置信度会误判很多规则。提升度Liftlift(A - B) confidence(A - B) / support(B)提升度衡量的是“买了 A 对买 B 的概率提升程度”。分子是“买了 A 的人中买 B 的概率”分母是“所有人中买 B 的概率”两者的比值就是提升度。lift 1A 和 B 正相关买 A 会显著提升买 B 的概率这是我们要的规则。lift 1A 和 B 互相独立买不买 A 都不影响买 B规则没价值。lift 1A 和 B 负相关买 A 反而会降低买 B 的概率。实际项目中我筛选规则的习惯是先设一个最小支持度保证规则有足够的样本量再按置信度或提升度排序。如果目标是做捆绑促销、寻找强关联组合重点看提升度如果目标是做“买了A再推荐B”的交叉销售重点看置信度。2.2 协同过滤的相似度余弦、皮尔逊、Jaccard协同过滤的核心计算是相似度。你要给用户 A 找邻居就要算 A 和其他用户的相似度要给电影 X 找相似品就要算 X 和其他电影的相似度。不同的数据形态用的相似度算法也不同。最常用的是余弦相似度。把用户的评分向量当成高维空间里的一个点余弦相似度就是两个向量夹角的余弦值。cosine(u, v) (u·v) / (|u|·|v|)它关注的是方向而不是长度。在用户对物品的评分矩阵里一个用户对所有物品都打高分、另一个用户对所有物品都打低分他俩的评分尺度不同但偏好趋势可能一致余弦相似度能把这个共性抓出来。皮尔逊相关系数是余弦相似度的去中心化版本计算时先减去用户的平均分pearson(u, v) Σ((u_i - ū) * (v_i - v̄)) / sqrt(Σ(u_i - ū)² * Σ(v_i - v̄)²)去中心化之后评分尺度差异被消除了。一个习惯打 4-5 分的用户和一个习惯打 2-3 分的用户只要对共同物品的相对评价一致皮尔逊相关系数就会很高。它在评分数据完整、数值有意义的时候表现比余弦好尤其在电影评分、商品评分这类场景。Jaccard 相似度适用于只有“买/没买”“点/没点”这类 0-1 行为的数据jaccard(u, v) |N(u) ∩ N(v)| / |N(u) ∪ N(v)|分子是两人共同产生过行为的物品数分母是两个人物品集合的并集大小。它完全不管行为的强弱只看集合重叠程度好处是计算简单、对稀疏数据相对鲁棒坏处是信息利用不充分两个人都买过同一件热门商品不一定代表偏好一致但 Jaccard 会给它们很高的相似度。2.3 为什么这些公式决定了两者的行为差异如果你把支持度、置信度、提升度和协同过滤的相似度公式放在一起看会发现一个关键差异关联规则处理的是一阶共现协同过滤处理的是二阶关系。具体来说关联规则只看“A 和 B 有没有一起出现在订单里”它不关心用户除了 A、B 之外还买了什么也不关心其他用户的整体画像。这使它非常擅长发现“可并行的商品组合”但也让它完全无法做个性化排序。因为对于同一个商品 B关联规则给所有用户推的理由都一样因为你买了 A而 A 和 B 强关联。它能解释“为什么推 B”却不能解释“为什么给你推 B、给他推 C”。协同过滤则相反。它计算的是“用户-物品矩阵”里的行与行、列与列的关系每个用户都有自己独立的向量相似用户集合因人而异。这使它天然输出个性化列表但代价是计算复杂度高、数据稀疏时相似度不可靠。所以本质上关联规则是“商品视角”的算法协同过滤是“用户视角”的算法。视角不同适用的数据规模、业务场景、工程实现就完全不同。3. 应用场景什么时候用谁混着用会怎样3.1 关联规则的主场超市、电商、线下零售关联规则最典型的应用场景是零售行业因为它直接回答“货该怎么摆、券该怎么发、促销该怎么搭”这类问题。我做过一个模拟的生鲜电商项目数据是用户的下单流水。运营提的需求很明确想把“买一送一”的促销商品和另一个关联商品绑定提升客单价。这个需求里没有“个性化”三个字目标就是找出整个大盘里最稳的组合用关联规则再合适不过。最终跑出来一条很有意思的规则“即食牛油果 - 进口牛奶”的置信度相当高因为很多买牛油果的用户是在做减脂餐牛奶是搭配食材。运营直接把牛油果和牛奶做了套餐转化率确实比单卖高。这类场景的共同特征是商品总数相对可控订单数据量大且业务方需要的是“可解释的规则”而不是“黑盒的个性化列表”。把关联规则的结果直接交给运营运营能理解、能落地、能判断规则是否合理这是它最大的产品优势。3.2 协同过滤的主场内容平台、视频、新闻、社交协同过滤在主流的互联网内容平台里几乎是标配。因为内容平台的核心诉求是“每人看到不同的首页”关联规则推不出这种个性化效果。比如一个视频平台用户看了 A 视频系统要给他推下一个视频。如果用关联规则系统只能找“看完 A 还经常看什么”的统一规律所有看完 A 的人得到的推荐都一样时间一长用户体验会非常单调。用基于物品的协同过滤系统会找与 A 行为相似的一批视频再结合用户自己的历史行为微调排序每个用户得到的列表是独一无二的。协同过滤也分两种用法用户量大、物品量相对少比如招聘、婚恋场景用基于用户的协同过滤找“相似的人”更自然。物品量大、用户行为稀疏比如电商、视频场景用基于物品的协同过滤更稳因为物品之间的相似关系比用户之间的相似关系稳定得多。3.3 一张表看懂场景选择维度关联规则协同过滤核心输出规则 / 商品组合个性化推荐列表个性化程度无个性化一条规则服务所有人强个性化每人生成独立结果核心数据订单 / 购物篮用户-物品行为矩阵冷启动能力新用户也能推规则不依赖用户历史新用户无行为数据无法推荐可解释性很好解释天然面向业务较差需要额外做推荐理由计算成本低商品组合规模可控高矩阵运算和近邻计算开销大典型场景零售捆绑、促销组合、货架陈列内容Feed流、电商猜你喜欢、视频推荐这张表不是说两个算法互斥而是说你得根据业务目标选主算法。目标如果是“提升客单价、做捆绑销售”关联规则是主线目标如果是“让每个用户看到不同的内容”协同过滤是主线。3.4 场景混搭的真实案例实际项目中我见过一个很有意思的混搭案例。模拟项目里有个家居电商商品分成高客单价低频次的大件和低客单价高频次的小件。大件的购买决策周期很长用户几个月才买一次协同过滤在这种数据上表现很差因为行为矩阵太稀疏了。小件则相反用户反复购买协同过滤效果很好。最终方案是分层处理小件走协同过滤做个性化推荐大件走关联规则做组合推荐。比如用户买了一个书架协同过滤推不出什么因为历史上买书架的人太少但关联规则能从所有包含书架的订单里发现“书架桌面收纳盒阅读灯”经常一起出现于是把这三件做成套餐推荐。两种算法各自解决各自的问题效果比硬把它们放在同一个模型里比拼好得多。4. 实操笔记小型推荐系统的选型与实现4.1 数据准备把行为日志整理成两种格式无论用哪种算法第一步都是把原始行为数据整理成算法能吃的样子。原始日志长什么样通常是一张流水表每一行是一次行为事件字段包括用户ID、物品ID、行为类型、时间戳。关联规则需要的是“购物篮格式”的订单数据。每一行代表一个订单里面是所有商品的集合order_id, items 1001, [牛奶, 面包, 鸡蛋] 1002, [牛奶, 啤酒] 1003, [面包, 鸡蛋, 果酱]协同过滤需要的是“用户-物品三元组”每一行是“用户、物品、行为强度”user_id, item_id, rating u001, i001, 5 u001, i002, 1 u002, i001, 4如果数据源是购买流水可以直接从订单表里派生这两种格式。如果行为数据是隐式的比如只有点击数据没有评分就需要自己定义“行为强度”。常见的做法是给不同行为赋权比如点击算 1 分、收藏算 2 分、加购算 3 分、购买算 5 分然后按用户-物品分组求和得到伪评分。这一步看似简单但实际上决定了整个项目能不能做。我踩过一个坑某次项目里只用购买行为生成矩阵结果大量用户只有一两笔订单矩阵稀疏度到了 99.7%协同过滤形同虚设。后来把浏览、收藏行为全部纳入构造了多层级的伪评分矩阵覆盖率和推荐效果才有了明显提升。数据预处理永远是推荐系统里的隐形决定因素。4.2 用关联规则跑出商品组合关联规则的挖掘过程最朴素的实现是穷举所有商品组合但商品数量一多就爆炸了。所以实际用的是 Apriori 或 FP-Growth 这类剪枝算法核心思想都一样如果某个商品组合的支持度已经低于阈值那么任何包含它的更大组合支持度也不可能超过阈值直接剪掉。在代码层面你可以用现成的数据挖掘工具库也可以自己写核心逻辑。下面是用伪代码写的大致流程# 伪代码关联规则挖掘流程 orders load_orders() # [{order_id, items: [...]}] # 1. 计算单个商品的支持度 item_support {} for order in orders: for item in order.items: item_support[item] 1 total_orders len(orders) # 2. 设置最小支持度阈值筛掉长尾商品 min_support 0.01 frequent_items { item: count / total_orders for item, count in item_support.items() if count / total_orders min_support } # 3. 生成候选二项集再计算支持度 pair_counts {} for order in orders: items [i for i in order.items if i in frequent_items] for i in range(len(items)): for j in range(i 1, len(items)): pair (items[i], items[j]) pair_counts[pair] 1 # 4. 筛选并计算规则指标 rules [] for (a, b), count in pair_counts.items(): support count / total_orders confidence count / item_support[a] lift confidence / (item_support[b] / total_orders) if confidence min_confidence: rules.append({ antecedent: a, consequent: b, support: support, confidence: confidence, lift: lift })实际生产我用的是现成封装好的函数但原则是一样的。关键不是实现而是调参数min_support设得太高会漏掉长尾商品的组合设得太低会产生大量噪声规则运行时间也变长。min_confidence通常设在 0.3~0.5 之间具体看业务。捆绑促销要求高置信度品类推荐可以放宽。lift是筛选有效规则的核心我一般要求lift 1.2否则这条规则对业务没什么增量。还要注意规则的方向性。A - B和B - A的支持度一样但置信度不同因为分母一个是 support(A)、一个是 support(B)。业务上要先确定“谁是诱饵谁是目标”。促销里通常把流量大的商品放左边把想要带动销量的商品放右边。4.3 用协同过滤跑出个性化TopN协同过滤的实现也可以走简化路线。以基于物品的协同过滤为例完整流程分三步第一步构造用户-物品矩阵。行是用户列是物品值是行为强度。第二步计算物品两两之间的相似度。这里有个关键点在实际计算时不会对全量物品两两计算而是只对“在同一用户行为记录里共现过的物品对”计算相似度。没有共现关系的物品相似度本来就是 0算它纯属浪费资源。第三步对某个用户生成推荐。拿到用户历史行为过的物品集合找出这些物品的相似物品按相似度加权汇总排除用户已经买过的物品排序取 TopN。伪代码如下# 伪代码基于物品的协同过滤 matrix build_user_item_matrix() # user_id - {item_id: rating} def recommend(user_id, top_k10): user_items matrix[user_id] # 该用户互动过的物品集合 # 累加每个候选物品的推荐得分 scores {} # item_id - 累计得分 for item, rating in user_items.items(): for similar_item, sim_score in item_sim[item].items(): if similar_item in user_items: continue # 排除已经买过的 scores[similar_item] rating * sim_score ranked sorted(scores.items(), keylambda x: x[1], reverseTrue) return [item_id for item_id, score in ranked[:top_k]]这段逻辑很简单但里面藏着一个重要细节rating * sim_score的乘法是什么意思它表示“用户对历史物品的偏好程度”乘以“历史物品和候选物品的相似程度”。用户越喜欢的物品它带来的相似物品推荐权重就越高。这个加权方式就是协同过滤的灵魂。相似度的计算方式也会直接影响结果。如果你发现推荐的物品总是集中在几个热门品类里很可能是因为热门物品的共现次数太高相似度虚高。解决方法是把相似度做归一化或者用皮尔逊相关系数代替余弦相似度。更稳妥的办法是在相似度计算时对热门物品做降权比如用1/log(1 item_流行度)做权重。4.4 评估对比离线指标怎么选两种算法都跑完了怎么判断谁更好很多新人上来就盯着准确率这是个误区。推荐系统里准确率并不是唯一重要的指标甚至很多时候不是最重要的指标。关联规则的评估最直接的是看规则质量规则的支撑面够不够大支持度。的确认程度高不高置信度。是否比随机推荐更有效提升度。业务上是否可解释、可落地。协同过滤的评估离线阶段通常看三组指标精确率与召回率把用户行为数据切成训练集和测试集用训练集建模在测试集上看推荐结果命中了多少比例。精确率看“推的里面有多少是对的”召回率看“用户真正看过的里面有多少被推到了”。覆盖率推荐系统一共推荐了多少不同物品。如果只推荐头部热门覆盖率会很低说明推荐多样性差。多样性/惊喜度推荐结果里品类分布是否均匀。这个指标业务上很关键但离线计算时会稍微复杂一些需要定义物品之间的内容距离。我在实际项目里最常用的对比方式很朴素把用户分成两组一组线上走关联规则策略另一组走协同过滤策略观察点击率、加购率、客单价这些业务指标。离线指标只能帮你筛掉明显不好的方案最终拍板的永远是线上业务结果。5. 常见问题与避坑心得5.1 冷启动谁更适合冷启动是推荐系统最常见的坑。新用户没有任何行为数据协同过滤根本无从下手。你可能觉得关联规则也没好到哪去但这里有个细节区别关联规则不需要用户历史。用户第一次进页面只要他此时点击了任意一个商品系统就能根据这个商品的关联规则立刻推荐搭配商品。这是一种“基于当前行为”的即时推荐冷启动问题天然不存在。协同过滤则比较尴尬。新用户没有行为历史没有相似邻居推荐列表一片空白。常见的处理办法是给新用户推荐热门榜等用户积累行为后再切到协同过滤。所以如果你的新产品刚上线、用户行为数据还很稀疏先用关联规则或者规则策略撑住冷启动阶段并不是丢人的方案反而很务实。5.2 稀疏矩阵为什么协同过滤容易失灵协同过滤的天敌是稀疏性。现实场景里一个平台可能有几百万物品但用户和绝大多数物品都没发生过交互每个用户向量里绝大部分都是 0。评价一下这种向量做余弦相似度结果会很低而且区分度差。稀疏性带来两个问题一是相似度计算不稳定。两个用户如果只在一两个热门物品上有重合算出的相似度可能很高但不是真实偏好相似只是大家都买了那个爆款这个相似度噪声极大。二是推荐的覆盖范围窄。协同过滤倾向于推荐热门物品因为热门物品的共现概率高但真正有价值的长尾推荐反而出不来。缓解手段主要有降维、矩阵分解、引入物品内容特征做混合推荐。实际操作中我建议先用“行为次数加权”的方式削弱热门物品的影响。比如共现矩阵里所有权重除以log(1 物品出现次数)能显著压制热门物品的相似度让长尾物品有机会浮上来。5.3 实时性两个算法的线上成本线上推荐系统对实时性的要求分两种一是“秒级响应”用户请求来了要立刻给结果二是“分钟级更新”用户最新行为要快速反映到推荐里。关联规则在实时性上有个天然优势规则是离线算好的线上只做查询匹配。用户刚买了一个商品系统立刻能在规则表里查到关联商品并返回耗时通常不到一毫秒。缺点是规则更新频率低新出现的消费趋势不能马上反映到推荐结果里。协同过滤的实时更新则复杂得多。基于物品的协同过滤如果想反映用户最新行为最简单的方案是每次请求时实时算推荐得分但当物品数量大时这个方法计算量非常大。常用的优化方案是分两段物品相似度表离线更新线上只做“用户行为乘以相似度”的聚合计算。这样线上负载可控最新行为也能即时影响推荐结果。基于用户的协同过滤就更麻烦一点因为用户相似度矩阵的更新成本更高很多平台已经把它替换成了矩阵分解或向量召回的方案。5.4 常见问题速查表问题现象排查思路关联规则跑出一堆无意义组合置信度不低但提升度接近1提升度是判断有效性的关键把 lift1.2 的规则过滤掉关联规则组合过于集中规则里永远是那几个头部商品降低最小支持度阈值或对商品按品类、价格带分组后分组挖掘协同过滤对老用户有效、新用户无效新用户推荐列表为空给新用户走热门榜或关联规则策略积累行为后再切换协同过滤推荐结果全是热门物品覆盖率低、个性化弱相似度计算时对热门物品做降权引入长尾商品奖励权重用户量很大时基于用户的协同过滤跑不动计算时间成倍增长改成基于物品的协同过滤或者用聚类先分组再算相似度行为数据全是点击、没有购买评分矩阵缺失用“点击1分、加购3分、下单5分”的方式构造伪评分这些经验都是我从一次又一次改Bug、调参数、看线上数据的过程中攒下来的。尤其是“协同过滤推出来全是热门”这个问题几乎每个入门者都会碰上一次。它表面上看起来推荐效果还不错因为热门商品本身点击率就高但你对比一下个性化覆盖率就会发现用户实际看到的东西和他的真实偏好根本没有强关联。还有一个小技巧很多人容易忽略不管用哪种算法最终展示给用户的推荐结果都要做业务规则过滤比如已购商品过滤、库存过滤、限售商品过滤。这一步虽然不属于算法逻辑但对实际效果的影响经常比算法调参还大。我见过不止一次模型离线指标刷得很漂亮上线之后数据却不涨原因就是推荐列表混进了用户已经买过的东西把用户惹烦了。我个人的体会是不要神化任何一个算法。关联规则和协同过滤都是很老的技术但它们至今没有被淘汰说明各自都有不可替代的位置。选型的时候多问自己一句这个业务到底是要“让同一类人看到更合适的东西”还是要“让所有人看到一个更合理的组合”答案清楚了算法自然也就选对了。

关联规则与协同过滤：从原理到选型的推荐系统实战指南

相关推荐

分布式系统中进程组织的四大核心设计原则

关联规则 vs 协同过滤：本质区别、场景选择与实战避坑指南

分布式系统进程组织：五层实战架构与生产级落地

更多资讯

【信息科学与工程学】计算机科学与自动化——第二十四篇编译器04 LLVM编译器01

150KHz 3A PWM 降压型 DC/DC 转换器D1507

IEEE Transactions on Communications (TCOM) 投稿状态记录

软考系统架构设计师历年真题集萃（109）

双运算放大器D4558

Qwen-Image-2.1-PE-T2I输出格式全解析：如何正确读取rewritten_prompt与wh_ratio

今日更新

微信云开发旅游小程序实战：LBS打卡+UGC社交全栈方案

金融AI代理平台核心拆解：从多代理协作到财报分析实战

基于大数据的智慧旅游推荐与可视化平台架构实践

本周精选

金融AI落地指南：从调研报告到技术选型与工程实践

大模型上下文成本与注意力优化技术深度解析——为何O(n²)平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测

基于GMM的语音识别系统原理与MATLAB实现详解

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？