【模式识别与机器学习（18）】关联规则：支持度与置信度-Apriori算法-FP-Growth算法-购物篮分析

原创已于 2025-12-05 16:34:11 修改 · 544 阅读

8 ·

CC 4.0 BY-SA版权

文章标签：

#机器学习 #数据库 #oracle

于 2025-12-02 20:26:37 首次发布

模式识别与机器学习基础专栏收录该内容

23 篇文章

订阅专栏

文章目录

本文内容一览（快速理解）

关联规则是什么？ 发现数据中"什么与什么相伴"的模式，通过支持度和置信度两个核心指标，从海量交易数据中自动挖掘有价值的关联模式
支持度vs置信度？ 支持度衡量规则出现的频率（是否常见），置信度衡量规则的可靠性（是否可信），两者结合才能发现真正有价值的关联规则
Apriori如何工作？ 通过先验原理（频繁项集的子集一定是频繁的）减少候选项集，使用逐层搜索系统地发现所有频繁项集，适合频繁项集长度较短的场景
FP-Growth的优势？ 通过构建FP树压缩数据库，避免候选项集生成，直接产生频繁项集，适合频繁项集长度较长的场景
如何选择算法？ 频繁项集长度较短（≤3项）→Apriori，频繁项集长度较长（>3项）→FP-Growth，数据密集→FP-Growth，数据稀疏→Apriori
如何设置参数？ 最小支持度过滤偶然出现的规则（建议从20%开始），最小置信度过滤不可靠的规则（建议从60%开始），根据业务效果调整
购物篮分析实战？ 数据准备（事务数据库格式）→发现频繁项集（Apriori或FP-Growth）→生成强关联规则（满足最小置信度）→业务应用（推荐、搭配销售）
如何评估规则？ 计算支持度和置信度，计算提升度（lift）判断规则是否有趣，使用卡方检验判断统计显著性，过滤误导性规则

总结口诀

核心指标：支持度→是否常见，置信度→是否可信
Apriori：先验原理→减少候选，逐层搜索→系统发现
FP-Growth：FP树→压缩数据，递归挖掘→直接产生
算法选择：短项集→Apriori，长项集→FP-Growth
参数设置：支持度20%起，置信度60%起，根据效果调整

一、支持度与置信度：关联规则的度量基础

[!NOTE]
📝 关键点总结：支持度衡量规则出现的频率（是否常见），置信度衡量规则的可靠性（是否可信），两者结合才能发现真正有价值的关联规则。

核心指标：

支持度：项集在事务数据库中出现频率 = 包含项集的事务数 / 总事务数（判断规则是否常见）
置信度：规则的可信程度 = 支持度(X∪Y) / 支持度(X)（判断规则是否可靠）
最小支持度（minsup）：用户定义的阈值，过滤掉偶然出现的规则
最小置信度（minconf）：用户定义的阈值，过滤掉不可靠的规则

决策标准：支持度低 → 规则可能只是偶然出现，不值得关注；置信度低 → 规则不可靠，不能用于业务决策；只有同时满足最小支持度和最小置信度的规则才是强关联规则。

1.1 什么是支持度

支持度的定义：

包含项集X的事务个数与总事务个数之比，即 $\text{Support}(X) = \frac{|\{d \in D | X \subseteq d\}|}{|D|}$ ，其中D是事务数据库，d是事务。
如果支持度太低，说明这个规则只是偶然出现，没有统计意义，不值得作为业务决策的依据。例如，在购物篮分析中，如果"买面包的人也买牛奶"只出现了1%，这个规则对业务价值很小。

实际应用示例：在电商购物篮分析中，如果"买手机的人也买手机壳"的支持度是60%，说明60%的购物记录中同时包含手机和手机壳，这个规则值得关注。如果支持度只有1%，说明这种情况很少见，可能只是偶然。

决策标准：

支持度 < minsup → 规则不值得关注；
支持度 ≥ minsup → 规则值得进一步分析；
支持度太低 → 可能是偶然出现，不值得作为业务决策依据。

适合判断规则是否常见，但不能判断规则是否可靠。需要结合置信度才能发现强关联规则。

1.2 什么是置信度

置信度就像统计"买面包的人中有多少比例也买了牛奶"，如果100个买面包的人中有80个也买了牛奶，说明这个规则很可靠。就像统计"下雨天带伞的人的比例"，如果100个下雨天中有90个带伞，这个规则就很可靠。

置信度定义为既包含X也包含Y的事务个数与包含X的事务个数之比，即 $\text{Confidence}(X \rightarrow Y) = \frac{\text{Support}(X \cup Y)}{\text{Support}(X)}$ 。

置信度衡量规则的可信程度，判断当条件X出现时，结果Y出现的概率。

支持度只能判断规则是否常见， 但不能判断规则是否可靠。

例如，"买面包的人也买牛奶"的支持度是60%，但如果买面包的人中只有30%买了牛奶，这个规则就不够可靠。置信度告诉我们，当条件X出现时，结果Y出现的概率，如果置信度高，说明这个规则可靠。

决策标准：

置信度 < minconf → 规则不可靠；
置信度 ≥ minconf → 规则可靠，可以用于业务决策；
置信度太低 → 规则不可靠，不能用于业务决策。

1.3 频繁项集与强关联规则

频繁项集就像"经常一起出现的商品组合"，强关联规则就像"如果买了A，很可能也买B"这样的可靠规则。

通过最小支持度阈值发现频繁项集，通过最小置信度阈值从频繁项集中提取强关联规则。故这里有两个发现强关联关系的步骤

第一步：发现满足最小支持度阈值的所有项集（频繁项集）
第二步：从频繁项集中提取满足最小置信度阈值的规则（强关联规则）

如果直接计算所有可能的规则，计算复杂度太高（包含d个项的数据集可以产生 $3^d - 2^{d+1} + 1$ 条规则）。通过两步法，先过滤掉不频繁的项集，再从中提取可靠的规则，可以大幅降低计算复杂度。

商品推荐示例：在电商购物篮分析中，如果"面包、牛奶"是频繁项集（支持度≥60%），且"面包→牛奶"的置信度≥75%，则生成强关联规则"买面包的人也买牛奶"。这个规则可以用于商品推荐：当用户购买面包时，推荐牛奶。

应用边界：适合发现布尔关联规则（项之间是否存在关联），但不适合发现定量关联规则（项之间的数量关系）。需要根据业务需求设置合适的阈值。

二、Apriori算法：基于先验原理的高效挖掘

[!NOTE]
📝 关键点总结：Apriori算法通过先验原理（频繁项集的子集一定是频繁的）大幅减少候选项集数量，使用逐层搜索方法系统地发现所有频繁项集。

核心机制：

先验原理：如果一个项集是频繁的，则它的所有子集也一定是频繁的；如果一个项集是非频繁的，则它的所有超集也一定是非频繁的（利用支持度的反单调性）
逐层搜索：从频繁1项集开始，逐层生成频繁k项集，直到不能再找到频繁项集
候选项集生成：通过合并频繁(k-1)项集生成候选k项集，仅当前(k-1)个项相同时才合并
候选项集剪枝：使用先验原理删除包含非频繁子集的候选项集

决策标准：数据量大 → Apriori算法（通过先验原理减少候选项集）；需要发现所有频繁项集 → Apriori算法；频繁项集长度较短（≤3项） → Apriori算法效果好；频繁项集长度较长（>3项） → 考虑FP-Growth算法。

2.1 先验原理：减少候选项集的核心机制

先验原理就像"如果一个人不买面包，那他肯定也不会买面包+牛奶的组合"，利用这个逻辑可以提前排除很多不必要的计算。就像如果一个人不会游泳，那他肯定不会参加游泳比赛，不需要考虑他参加游泳比赛的可能性。

本质原理：先验原理基于支持度的反单调性：一个项集的支持度绝不会超过它的子集的支持度。因此，如果一个项集是非频繁的（支持度 < minsup），则它的所有超集也一定是非频繁的，不需要计算支持度就可以直接删除。

减低计算复杂度：如果不使用先验原理，需要计算所有可能的项集（包含d个项的数据集可以产生 $2^d - 1$ 个项集），计算复杂度是指数级的。使用先验原理后，只需要计算频繁项集，可以大幅降低计算复杂度。例如，枚举所有项集（到3项集）的蛮力策略将产生 $C (6, 1) + C (6, 2) + C (6, 3) = 41$ 个候选，使用先验原理后减少为 $C (6, 1) + C (4, 2) + 1 = 13$ 个候选。

实际应用示例：在购物篮分析中，如果"面包"不是频繁项集（支持度 < minsup），则"面包、牛奶"、"面包、鸡蛋"等所有包含"面包"的项集都不可能是频繁项集，不需要计算支持度就可以直接删除。

应用边界：适合布尔关联规则挖掘，但需要多次扫描数据库（每层一次扫描）。对于频繁项集长度较长的场景，计算复杂度仍然较高。

2.2 逐层搜索：系统发现频繁项集

逐层搜索就像"先找单个商品，再找两个商品的组合，再找三个商品的组合"，一层一层地发现频繁项集。就像建房子，先打地基（1项集），再建第一层（2项集），再建第二层（3项集）。

核心作用：从频繁1项集开始，逐层生成频繁k项集，直到不能再找到频繁项集，系统地发现所有频繁项集。

本质原理：Apriori算法使用逐层搜索（宽度优先）的迭代搜索方法：

首先扫描数据库，累计每个项的计数，找出频繁1项集 $L_1$
然后 $L_1$ 用于找频繁2项集 $L_2$
$L_2$ 用于找频繁3项集 $L_3$
如此下去，直到不能再找到频繁k项集

逐层搜索可以系统地控制候选项集的指数增长，每层只需要扫描一次数据库，计算复杂度可控。如果使用深度优先搜索，虽然可以更快地检测到频繁项集边界，但需要更多存储空间。

实际应用示例：在购物篮分析中，

首先找出频繁1项集（如"面包"、“牛奶”、“鸡蛋”），
然后找出频繁2项集（如"面包、牛奶"、 “面包、鸡蛋”），
再找出频繁3项集（如"面包、牛奶、鸡蛋"），直到不能再找到频繁项集。

应用边界：适合发现所有频繁项集，但需要多次扫描数据库。对于大规模数据，可以通过事务压缩、划分等方法提高效率。

决策标准：

频繁项集长度较短（≤3项） → 逐层搜索效果好；
频繁项集长度较长（>3项） → 考虑使用深度优先搜索或FP-Growth算法；
需要发现所有频繁项集 → 逐层搜索；
只需要发现最大频繁项集 → 考虑深度优先搜索。

2.3 候选项集生成与剪枝

候选项集生成就像"把两个频繁项集合并成一个更大的候选项集"，候选项集剪枝就像"如果合并后的候选项集包含非频繁子集，就删除它"。就像组合两个小组，如果两个小组都合格，就合并成一个大组；如果合并后的大组包含不合格的小组，就删除这个大组。

核心作用：通过合并频繁(k-1)项集生成候选k项集，使用先验原理删除包含非频繁子集的候选项集。

本质原理：

候选项集生成：使用 $F_{k-1} \times F_{k-1}$ 方法：合并一对频繁(k-1)项集，仅当它们的前(k-1)个项都相同时才合并。例如，合并 $A = \{a_1, a_2, ..., a_{k-1}\}$ 和 $B = \{b_1, b_2, ..., b_{k-1}\}$ ，如果 $a_i = b_i$ (i=1,2,…,k-2) 且 $a_{k-1} \neq b_{k-1}$ ，则合并为 ${a_1, a_2, ..., a_{k-1}, b_{k-1}\}$ 。
候选项集剪枝：使用先验原理：删除包含非频繁(k-1)项集的候选项集。

$F_{k-1} \times F_{k-1}$ 方法可以避免产生重复的候选项集（使用字典序），比蛮力方法（产生所有k项集）和 $F_{k-1} \times F_1$ 方法（可能产生不必要的候选）更高效。候选项集剪枝可以大幅减少需要计算支持度的候选项集数量。

实际应用示例：在购物篮分析中，如果"面包、牛奶"和"面包、鸡蛋"是频繁2项集，且它们的前1个项相同（都是"面包"），则合并为候选3项集"面包、牛奶、鸡蛋"。如果"牛奶、鸡蛋"不是频繁2项集，则删除候选3项集"面包、牛奶、鸡蛋"（因为它包含非频繁子集"牛奶、鸡蛋"）。

应用边界：适合布尔关联规则挖掘，但候选项集生成和剪枝的计算复杂度仍然较高。对于大规模数据，可以使用Hash树等方法减少比较次数。

2.4 支持度计数优化

实际应用示例：在购物篮分析中，如果候选项集数量很多（如1000个），使用Hash树可以将候选项集分成多个桶（如10个桶），每个桶只有100个候选项集，事务只需要与同一桶内的候选项集比较，比较次数减少10倍。

Hash树方法将候选项集划分为不同的桶，并存放在Hash树中。在支持度计数期间，包含在事务中的项集也散列到相应的桶中，只与同一桶内的候选项集进行匹配。例如，使用Hash函数 $\bmod 3$ ，将候选项集散列到不同的桶中，事务中的项集也散列到相应的桶中，只与同一桶内的候选项集比较。

事务与事务中的项集概念

单个 “事务”：对应一次完整的购物行为（比如一位顾客结账时的购物篮）；
事务中的 “项集”：就是这个购物篮里的所有商品组合（可以是单个商品、多个商品）。
事务 1（顾客 A 的购物篮）：{牛奶、面包、鸡蛋} → 这个集合就是事务 1 的项集；
事务 2（顾客 B 的购物篮）：{可乐、薯片} → 这是事务 2 的项集；
甚至单个商品 {牛奶}，也可以叫事务 1 中的 “1 项集”，{牛奶、面包} 是 “2 项集”。

适合候选项集数量较多的场景，但Hash树的构建和维护需要额外开销。对于候选项集数量很少的场景，蛮力方法可能更简单。

三、FP-Growth算法：避免候选项集生成的直接挖掘

[!NOTE]
📝 关键点总结：FP-Growth算法通过构建FP树（频繁模式树）压缩数据库，避免候选项集生成，直接产生频繁项集，适合频繁项集长度较长的场景。

核心机制：

FP树构建：将数据库压缩到一棵频繁模式树，保留项集关联信息（只存储频繁项，按支持度降序排列）
条件模式基：为每个频繁项构建条件模式基（包含该项的所有路径的前缀）
条件FP树：基于条件模式基构建条件FP树，递归挖掘频繁项集

决策标准：频繁项集长度较长（>3项） → FP-Growth算法（避免候选项集生成）；数据密集（事务包含很多项） → FP-Growth算法效果好；数据稀疏（事务包含很少项） → Apriori算法可能更简单；需要多次挖掘 → FP-Growth算法（FP树可以复用）。

3.1 FP树：压缩数据库的频繁模式树：相同内容只存储一次

FP树就像"把购物记录压缩成一棵树，相同的前缀共享同一个节点"，这样就不需要生成候选项集，直接从树中挖掘频繁项集。就像把多本书的内容压缩成一本书，相同的内容只存储一次。

FP树（Frequent-Pattern Tree）是一种压缩的数据结构，只存储频繁项，按支持度降序排列。相同前缀的路径共享同一个节点，每个节点存储项名和支持度计数。FP树通过共享前缀，大幅压缩数据库，避免重复存储。

Apriori算法需要生成候选项集，计算复杂度较高。FP-Growth算法通过构建FP树，将数据库压缩，避免候选项集生成，直接产生频繁项集，计算复杂度更低。对于频繁项集长度较长的场景，FP-Growth算法的优势更明显。

实际应用示例：在购物篮分析中，如果多个事务都包含"面包、牛奶、鸡蛋"，FP树会将它们压缩到同一条路径上，共享前缀"面包、牛奶"，只存储一次，大幅减少存储空间。

应用边界：适合频繁项集长度较长的场景，但FP树的构建需要扫描数据库两次（第一次统计支持度，第二次构建FP树）。对于数据稀疏的场景，Apriori算法可能更简单。

决策标准：

频繁项集长度较长（>3项） → FP-Growth算法；
数据密集 → FP-Growth算法效果好；
数据稀疏 → Apriori算法可能更简单；
需要多次挖掘 → FP-Growth算法（FP树可以复用）。

3.2 条件模式基与递归挖掘

条件模式基就像"找出所有包含某个频繁项的路径的前缀"，然后基于这些前缀递归挖掘频繁项集。就像找"所有包含某个关键词的句子"，然后找出"这些句子的共同前缀"。

FP-Growth算法从FP树的底部（支持度最低的频繁项）开始，为每个频繁项构建条件模式基（包含该项的所有路径的前缀），基于条件模式基构建条件FP树，递归挖掘频繁项集。例如，对于频繁项e，找出所有包含e的路径的前缀，构建条件FP树，递归挖掘以e为后缀的频繁项集。

通过递归挖掘，可以系统地发现所有频繁项集，而不需要生成候选项集。条件模式基只包含频繁项，可以大幅减少搜索空间。

实际应用示例：在购物篮分析中，如果频繁项"鸡蛋"的条件模式基是"面包、牛奶"，则构建条件FP树，递归挖掘以"鸡蛋"为后缀的频繁项集（如"面包、牛奶、鸡蛋"）。

应用边界：适合频繁项集长度较长的场景，但递归挖掘需要构建多个条件FP树，内存开销较大。对于数据稀疏的场景，Apriori算法可能更简单。

决策标准：频繁项集长度较长 → 递归挖掘效果好；数据密集 → 递归挖掘效率高；需要发现所有频繁项集 → 递归挖掘；只需要发现最大频繁项集 → 可以考虑其他方法。

四、实战场景：电商购物篮分析

4.1 业务痛点识别

电商平台积累了海量交易数据，但不知道哪些商品经常一起被购买，无法制定有效的商品推荐和搭配销售策略。传统的人工分析方式效率低、成本高，且容易遗漏有价值的关联模式。

核心挑战：

数据量大（百万级交易记录），人工分析效率低
不知道哪些商品经常一起被购买
无法制定有效的商品推荐和搭配销售策略
需要自动发现关联模式，支持业务决策

4.2 方案拆解：用核心知识点解决问题

第一步：数据准备与参数设置

将交易数据转换为事务数据库格式，每个事务代表一次购物记录，包含购买的商品列表。根据业务需求设置最小支持度（如60%）和最小置信度（如75%），过滤掉偶然出现的规则和不可靠的规则。

为什么这样准备：事务数据库格式是关联规则挖掘的标准输入格式，每个事务代表一次购物记录。最小支持度和最小置信度阈值需要根据业务需求设置：支持度太低会导致规则太多（包含偶然出现的规则），支持度太高会导致规则太少（遗漏有价值的规则）；置信度太低会导致规则不可靠，置信度太高会导致规则太少。

第二步：发现频繁项集

使用Apriori算法或FP-Growth算法发现频繁项集。如果频繁项集长度较短（如2-3项），使用Apriori算法；如果频繁项集长度较长（如5项以上），使用FP-Growth算法。通过先验原理或FP树，高效地发现所有频繁项集。

为什么这样选择：Apriori算法适合频繁项集长度较短的场景，通过先验原理减少候选项集，计算复杂度可控。FP-Growth算法适合频繁项集长度较长的场景，通过FP树避免候选项集生成，计算复杂度更低。根据数据特点选择合适的算法，可以提高挖掘效率。

第三步：生成强关联规则

从频繁项集中提取满足最小置信度阈值的规则。例如，如果"面包、牛奶"是频繁项集，且"面包→牛奶"的置信度≥75%，则生成强关联规则"买面包的人也买牛奶"。

为什么这样生成：只有同时满足最小支持度和最小置信度的规则才是强关联规则，值得用于业务决策。支持度保证规则不是偶然出现，置信度保证规则可靠。例如，"面包→牛奶"的支持度是60%（常见），置信度是80%（可靠），这个规则可以用于推荐。

第四步：业务应用

将强关联规则应用于商品推荐、搭配销售、库存管理等业务场景。例如，在用户购买面包时，推荐牛奶；将面包和牛奶放在相邻位置，促进搭配销售。

为什么这样应用：关联规则的价值在于业务应用。商品推荐可以提高用户满意度，搭配销售可以提高销售额，库存管理可以优化库存配置。例如，如果"面包→牛奶"是强关联规则，在用户购买面包时推荐牛奶，可以提高牛奶的销量。

完整流程：

数据预处理：将交易数据转换为事务数据库格式
参数设置：设置最小支持度（60%）和最小置信度（75%）
频繁项集发现：使用Apriori或FP-Growth算法发现频繁项集
规则生成：从频繁项集中提取满足最小置信度的规则
规则评估：计算提升度、卡方检验等指标，过滤误导性规则
业务应用：将强关联规则应用于推荐、营销、库存管理等场景

4.3 长期适配策略

数据更新策略：定期重新挖掘关联规则，适应商品和用户行为的变化。对于新增商品，可以增量更新关联规则。

判断标准：数据变化大（如新增大量商品） → 重新挖掘关联规则；数据变化小（如小幅更新） → 增量更新关联规则；需要实时更新 → 增量更新关联规则。

参数调优策略：根据业务效果调整最小支持度和最小置信度。如果规则太多，提高阈值；如果规则太少，降低阈值。

判断标准：规则太多（包含偶然出现的规则） → 提高最小支持度或最小置信度；规则太少（遗漏有价值的规则） → 降低最小支持度或最小置信度；业务效果不好 → 调整阈值，重新挖掘。

算法选择策略：根据数据特点选择合适的算法。数据密集且频繁项集长度较长 → FP-Growth算法；数据稀疏且频繁项集长度较短 → Apriori算法。

判断标准：频繁项集长度较长（>3项） → FP-Growth算法；频繁项集长度较短（≤3项） → Apriori算法；数据密集 → FP-Growth算法；数据稀疏 → Apriori算法。

规则评估策略：使用提升度、卡方检验等指标评估规则的有趣程度，过滤掉误导性规则。

判断标准：提升度 > 1 → 规则有趣，值得关注；提升度 ≤ 1 → 规则不有趣，可能是误导性规则；卡方检验显著 → 规则统计显著，值得关注。

总结

关联规则挖掘通过支持度和置信度两个核心指标，从海量数据中自动发现有价值的关联模式。通用应用逻辑公式：
（1）数据准备（将业务数据转换为事务数据库格式，设置最小支持度和最小置信度阈值）；
（2）频繁项集发现（使用Apriori算法或FP-Growth算法发现频繁项集）；
（3）规则生成（从频繁项集中提取满足最小置信度的规则）；
（4）规则评估（使用提升度、卡方检验等指标评估规则的有趣程度）；
（5）业务应用（将强关联规则应用于推荐、营销、库存管理等场景）。

可直接套用的落地模板：
（1）数据准备：将业务数据转换为事务数据库格式，设置最小支持度阈值（建议从20%开始），设置最小置信度阈值（建议从60%开始）；
（2）算法选择：频繁项集长度较短（≤3项）→Apriori算法，频繁项集长度较长（>3项）→FP-Growth算法，数据密集→FP-Growth算法，数据稀疏→Apriori算法；
（3）规则评估：计算支持度和置信度，计算提升度（lift）判断规则是否有趣，使用卡方检验判断规则的统计显著性；
（4）业务应用：商品推荐（在用户购买A时推荐B），搭配销售（将A和B放在相邻位置），库存管理（根据关联规则优化库存配置）；
（5）效果监控：定期重新挖掘关联规则，根据业务效果调整阈值，监控规则的应用效果。