简介基于MATLAB的FP-Growth关联规则挖掘算法实现资源面向数据挖掘初学者、电商零售分析人员以及需要在高维交易数据中挖掘频繁项集的研究者。压缩包内含8个文件包括7个.m脚本和1个.mat数据集完整覆盖从数据读取、FP树构建、条件模式基生成、递归挖掘到关联规则输出的代码流程并附带mydata演示数据方便直接运行与替换自定义事务数据。目前已有191人学习下载。通过该资源读者可以深入理解FP-Growth算法如何通过树结构压缩候选集、减少扫描次数并掌握支持度阈值设定、频繁项集提取及置信度计算等关键环节同时基于MATLAB的矩阵运算实现也便于快速验证算法效果并迁移到市场篮子分析、网络行为分析等实际场景。整个rar包仅5KB结构紧凑适合算法学习、课设实验或快速原型验证。1. 处理几百万行订单明细时为什么我首选 FP-Growth 而不是 Apriori去年接了一个零售订单的关联分析需求明细表几百万行一个订单平均两三件商品稀疏得一眼能看出来。第一版用 Apriori跑了十分钟还在反复扫数据库换成 FP-Growth 之后同样的频繁项集挖掘几十秒内出结果。这个标题里的 .rar 包看着像个老课程设计核心却是一棵 FP-Tree把所有事务压缩成公共前缀路径只扫描两遍数据不生成候选集这条性能曲线恰好是稀疏购物篮数据最吃的那一套。这篇笔记不打算讲太多算法史直接按“这是什么、怎么跑通、参数怎么调、坑在哪、怎么验证”的顺序走一遍。适合要拿关联规则做捆绑促销、日志共性分析、商品组合分析的人也适合刚拿到类似代码包但不知道怎么改的开发者。看完照着操作至少能少走几条弯路。2. 把 .rar 拆开跑通FP-Growth 项目结构、数据格式与最小命令2.1 解压后先分清实现路线纯 Python 版还是库封装版解压完别急着点 README先看主脚本。压缩包里的文件叫什么名字只是纸面印象真正的路线差异在 import 语句里grep -n import fpgrowth.py输出里如果只有标准库itertools、collections 这类是纯 Python 实现好处是每一步都可以加日志、改剪枝逻辑如果出现了 pyfpgrowth 或 mlxtend是封装库实现主脚本主要在做数据处理和参数转发算法本身是个黑匣子。拿到手先跑通再决定要不要打开黑匣子。判断跑通的标准是终端出现频繁项集或规则输出不是“不报错”。有些老压缩包跑起来不报错但数据文件编码不对出来的结果全是空。我一般会先用包自带的示例数据跑一遍示例数据能出结果再换成自己的数据。示例都跑不通九成是 Python2 时代留下的编码问题数据文件用文本编辑器另存为 UTF-8 后再跑这个坑经常被当成算法问题排查半天。2.2 最小跑通命令与输出解读常见做法是主脚本支持命令行参数最小命令长这样python fpgrowth.py --input transactions.txt --min-support 3 --min-confidence 0.6 --output rules.csv参数含义--input输入事务文件每行一个事务--min-support 3绝对支持度至少出现 3 次的项集才会被保留--min-confidence 0.6关联规则置信度门槛 0.6--output规则输出路径第一次跑不要追求最优参数只要输出有内容就算通。如果包不支持命令行参数常见做法是打开主脚本改 min_support、min_conf 两个变量改完直接 python fpgrowth.py。注意支持度入参是次数还是比例代码里一般写得很清楚如果写的是 0.05 那它要的是百分比阈值。跑完看输出常见是三段每个频繁项集的支持度计数、每条规则的前件后件与置信度。如果连二元频繁项集都没有问题大概率不在算法在数据格式接着看 2.3。2.3 数据格式化把订单明细聚合成事务文件FP-Growth 的输入是“事务”而不是“明细”。比如订单明细表是 order_id 和 item 两列每件商品占一行而“一个订单”才是一个事务。直接把明细表灌进去每行都只有一件商品算法永远找不出二元组合。先把数据聚合成标准的事务格式import pandas as pd # 订单明细order_id 订单号item 商品名 detail pd.read_csv(order_detail.csv) detail detail.dropna(subset[order_id, item]) detail[item] detail[item].astype(str).str.strip() # 同订单内商品先去重再把一个订单的所有商品拼成一行 trans_list ( detail.groupby(order_id)[item] .apply(lambda s: ,.join(sorted(set(s)))) .tolist() ) # 写入 FP-Growth 需要的标准输入格式 with open(transactions.txt, w, encodingutf-8) as f: f.write(\n.join(trans_list))逻辑说明groupby 按订单聚合set 去重保证同一个商品在订单里出现两次也只记一次这与关联规则“该商品是否出现在该事务中”的语义一致。sorted 排序不是强迫症FP-Tree 构建要求事务内的项顺序是确定且一致的否则同一组商品在树上可能走出不同分支头指针表维护会乱。参数说明order_id、item 要替换成真实列名如果原始表存在同一订单同一商品的重复行提前 drop_duplicates 可以减小 groupby 的压力set 也能兜底。数据量特别大时groupby 的内存占用需要考虑可以先分块处理再合并思路不变。提示如果事务文件里出现了“nan”这样的项先看 dropna 是否生效空行和非法字符会在统计支持度时混进结果集这也是结果异常里最隐蔽的一种。3. FP-Growth 三参数调试支持度、置信度、提升度怎么配合结果才不是一堆废话3.1 支持度决定 FP-Tree 的剪枝深度支持度是唯一真正影响 FP-Tree 形态的参数。第一遍扫描统计每个项的全局出现次数低于阈值的项直接不进树频繁项集挖掘又是在这棵树上递归完成的所以支持度直接决定树的节点数和递归层数。支持度设太高树被剪得很干净留下的全是高频项能组成的二元组合屈指可数跑出来的规则不用看都知道是牛奶面包。支持度设太低低频项大量进树内存直线上升常见的就是进程被系统 kill。所以支持度不是数学公式选出来的是在“频繁项集数量可读”和“内存能扛住”之间试出来的。参考区间我用过的是这样事务量级支持度起步值说明千级以内绝对次数 3~10数据量小百分比波动大万级0.5%~2%按百分比便于向业务解释十万到百万级0.1%~0.5%稀疏购物篮常见区间百万以上0.05%~0.1% 起步配合绝对次数交叉验证用绝对次数还是百分比取决于包实现的入参。我习惯先用绝对次数摸一遍比如“至少出现 3 次”看输出量再切到百分比口径方便给业务讲。同一个模型换一份数据阈值差一个数量级很常见每次都要按输出量重新校准这部分没法偷懒。3.2 置信度管强度、提升度管价值规则生成代码与指标口径置信度和提升度都是基于支持度算出来的但口径完全不同。置信度 support(A∪B) / support(A)衡量“买了 A 的人里有多少还买了 B”提升度 support(A∪B) / (support(A) × support(B))衡量“A 和 B 的共现是不是比随机独立出现的概率更高”。一块面包出现率 80%牛奶搭配面包的置信度可能高达 90%但提升度只有 1.125说明牛奶和面包几乎独立。所以只看置信度会把热门商品推成万金油规则提升度才是筛出真实关联的那一关。生成规则时我一般会把三个指标一起算出来import itertools def generate_rules(freq_itemsets, min_conf0.6): 从频繁项集生成关联规则支持度用绝对次数分子分母口径一致占比也行 rules [] for itemset, sup_all in freq_itemsets.items(): if len(itemset) 2: continue # 枚举前件的所有真子集 for k in range(1, len(itemset)): for lhs in itertools.combinations(itemset, k): lhs tuple(sorted(lhs)) rhs tuple(sorted(set(itemset) - set(lhs))) sup_lhs freq_itemsets[lhs] conf sup_all / sup_lhs sup_rhs freq_itemsets[rhs] lift sup_all / (sup_lhs * sup_rhs) if conf min_conf: rules.append({ antecedent: lhs, consequent: rhs, support: sup_all, confidence: round(conf, 4), lift: round(lift, 4), }) return rules逻辑说明freq_itemsets 的键必须是排序后的 tuple否则枚举子集时查不到对应的 support这是规则生成里最常见的报错点。支持度不管用绝对次数还是占比分子分母口径一致置信度和提升度的比值就正确。参数说明min_conf 只过滤置信度提升度留给后面做排序如果频繁项集特别多itertools 枚举会带来组合量增长建议先把频繁项集按长度截断一般长度 4 以上对业务就没有增量了。3.3 参数调试顺序与参考起步值三参数不要同时乱试。我自己的调试顺序是先定支持度让频繁项集数量落在几百到几千条再定置信度让规则数量落在几十到几百条最后用提升度 1.2 做后置过滤把常识规则扔掉。如果频繁项集只有几十条说明支持度太高先降一个数量级再看。如果规则输出几百条但大部分提升度在 1.1 徘徊不用降置信度直接调提升度过滤线。需要注意支持度决定后置信度的高低往往已经受数据分布限制不是想设多高就能设多高先看全量规则的置信度分位数再定阈值比自己拍脑袋靠谱得多。4. FP-Growth 实战避坑现象、原因、解决五条血泪记录关联规则看起来是跑完参数就万事大吉实际翻车都翻在看不见的地方。下面五条按出现频率排每一条都值得在你自己的数据上先自查一遍。4.1 跑出满屏单项集订单明细没按事务聚合现象输出全是牛奶,、面包,这种长度为一的频繁项集二元组合几乎没有。原因输入文件每行是一件商品不是一个订单。FP-Growth 把每行当成一个事务事务里只有一项自然组不出二元组合。解决回到 2.3 的聚合脚本先按订单号 groupby再把商品去重、排序、拼成一行。检查输入文件的第一列如果第一个字段是订单号或流水号那这就是明细表不是事务文件。4.2 频繁项集一堆却没有规则置信度阈值设太高现象频繁项集输出几十上百条规则输出却是空的。原因置信度是条件概率A 出现 10 次AB 出现 4 次置信度只有 0.4阈值设 0.7 时所有规则都被过滤一条不剩。解决先把 min_conf 降到 0.3 看规则量再往上调。更稳的办法是先把规则全量生成看一眼置信度分布再定阈值confs [r[confidence] for r in rules] # 先不过滤全量生成 import numpy as np print(np.percentile(confs, [25, 50, 75, 90]))如果 90 分位的置信度才 0.5说明数据里本来就少有高置信度规则硬把阈值设到 0.7 等于把结果全删了。置信度分布是调参的直接依据比靠感觉设阈值靠谱。4.3 支持度一调低就内存爆掉低频项与超长事务是元凶现象支持度调低之后FP-Tree 构建几分钟跑不完或者进程直接被系统 kill。原因支持度低大量低频项进入树节点数量膨胀另一种情况是数据里有超长事务一个订单包含几十上百个商品路径深度直接拉满。解决先统计事务长度分布把超过 90 分位数的超长事务截断或剔除再决定支持度。百万级数据先用 10% 采样做参数探索确定可行阈值再全量跑别拿全量数据频繁试参那是拿生产资源做实验。4.4 规则全是常识没有增量提升度接近 1 的高频项假象现象牛奶→面包、鸡蛋→牛奶规则都对运营看一眼说“这还用跑吗”。原因后件是高频商品时任何前件搭配它都会有可观的置信度但提升度趋近 1说明共现并没有显著高于随机。解决加一行按提升度过滤。提升度 1.2 是常见起步线业务数据噪声大的时候可以放到 1.5同时看 leverage杠杆值 support(A∪B) - support(A)×support(B)这个指标是线性口径出现负值直接放弃对应规则。4.5 把关联规则当个性化推荐用广播式推热门点击率会告诉你答案现象把 FP-Growth 规则直接接进推荐服务向所有用户广播后件商品点击率起不来。原因关联规则描述的是商品的共现统计不是用户偏好。热门商品在任何规则里都会高频出现广播式推荐本质上是在推热门货谈不上个性化。解决关联规则用在捆绑满减、陈列组合、品类运营这些“商品与商品”的场景要做用户维度的个性化推荐换协同过滤或序列推荐这属于算法选型错误调参救不回来。5. 把频繁项集翻译成业务动作规则排序、方向判断与去冗余5.1 三张不同排序的规则表对应三种运营动作规则生成出来只是中间态业务方要的不是规则列表是“先推哪个、怎么摆、跟着谁卖”。我一般把规则按三种口径排序分别给到不同角色按提升度排序选交叉销售组合适合详情页关联推荐按支持度排序选大众捆绑套餐适合购物车凑单和满减按置信度排序选话术抓手适合销售话术和客服推荐排序代码import pandas as pd df pd.DataFrame(rules) # 交叉销售提升度优先置信度兜底 df.sort_values([lift, confidence], ascendingFalse).head(20) # 大众套餐支持度优先置信度兜底 df.sort_values([support, confidence], ascendingFalse).head(20) # 销售话术置信度优先但提升度必须大于 1.2 df[df[lift] 1.2].sort_values(confidence, ascendingFalse).head(20)逻辑说明三张表对应三种不同运营动作排序前先完成提升度过滤防止高频项假象混进来。head(20) 只是预览实际条数按后台位次决定位次少就取前 10位次充裕可以取前 50。5.2 高频项与低频项的规则方向置信度不对称但玩法不同同一组商品的两个方向置信度往往差很多。原因很简单分母不同。support(A) 和 support(B) 不一样conf(A→B) 和 conf(B→A) 就不会一样。方向选择可以直接复用这张表规则方向置信度表现提升度适合动作高频 → 低频偏低往往偏高买高频引流品时顺带带低频高毛利品低频 → 高频偏高可能也高买小众商品时顺手加购大众品实际运营里我会把每条规则的正反两个方向都生成出来分别评估。高频→低频适合做关联推荐低频→高频适合做满减凑单因为消费心理不同前者是被动发现后者是主动加购。5.3 规则去冗余别把 A→C 这种可推导组合发给业务频繁项集挖掘会产出大量冗余规则。假如 A→B、B→C 都是强规则A→C 大概率也会被挖出来但它没有新增信息业务方看多了会觉得规则系统不用心。我一般的去冗余逻辑所有规则按提升度降序排对后件相同的规则做前件包含判断——如果长前件规则的前件包含了一条更强规则的完整前件且后件相同就认为长前件规则是更短规则的自然推论丢弃。def dedup_rules(df_rules): 按前件包含关系去冗余保留提升度更高的一条 df_rules df_rules.sort_values(lift, ascendingFalse) keep [] for _, r in df_rules.iterrows(): dup False for k in keep: if set(r[antecedent]).issuperset(k[antecedent]) and \ set(r[consequent]) set(k[consequent]): dup True break if not dup: keep.append(r) return keep逻辑说明issuperset 判断前件覆盖关系consequent 相同时才比较。只保留最短前件或最高提升度的那条业务侧拿到的规则量能砍掉三分之一以上。参数说明规则量不大时直接跑几十万条规则可以先按后件分组再并行处理避免嵌套循环拖太久。6. 用一个跨行打乱实验验证 FP-Growth 结果不是巧合调参调到最后最怕的不是程序报错而是结果看起来合理但其实是高频项叠加出来的巧合。我有一个每次都要做的验证步骤把原始事务的项全部打散按原来的行长随机重组成新事务再跑一遍完全相同的参数。如果打乱后的数据里还是能跑出一堆高提升度规则说明这些规则根本不是共现关系是数据本身的分布特征撑出来的。import random def shuffle_transactions(src_path, dst_path, seed42): 跨行打乱把项放进公共池再按原长度随机分配破坏一切共现结构 random.seed(seed) with open(src_path, encodingutf-8) as f: rows [line.strip().split(,) for line in f if line.strip()] # 打散进公共池 pool [item for row in rows for item in row] random.shuffle(pool) # 按原来的行长重新分配 new_rows, idx [], 0 for row in rows: new_rows.append(pool[idx:idx len(row)]) idx len(row) with open(dst_path, w, encodingutf-8) as f: f.write(\n.join(,.join(r) for r in new_rows))跑完对比两张表真实数据里提升度大于 1.2 的规则数量和打乱数据里的数量。打乱数据里如果还有类似数量直接放弃这批规则如果打乱后规则数量断崖式下降说明原结果确实来自商品间的真实共现。这是我被一次线上促销活动的结果坑过之后养成的习惯。那次规则看着没问题上线后效果平平回来一验数据才发现多数“关联”靠的是两个头部商品的超高销量。后来不论项目多急这个打乱实验我都会先跑一遍。希望帮到你。本文还有配套的精品资源点击获取
