企业官网建设流程全解析

简介：这是一份面向数据分析与机器学习初学者的电影数据集关联规则挖掘实战资源。内容围绕Apriori算法在电影选角与导演偏好分析中的应用展开，结合电影数据集演示如何通过关联规则发现导演选择演员的倾向，并针对sklearn缺少Apriori的问题，给出基于PyPI筛选并使用efficient-apriori工具包的思路。压缩包共9个文件，包含Python脚本（movie_apriori.py与movie_download.py）、Markdown说明文档以及5张结果或流程示意图，总大小约1.01MB，结构紧凑便于快速上手。已有2359人学习下载，适合希望理解关联规则实际落地并掌握Python工具选择方法的读者。通过阅读说明文档和运行脚本，可以复现挖掘过程，学习数据下载、预处理、频繁项集提取与规则解读的完整链路，并迁移到其他商品捆绑或行为分析场景。

1. 电影数据集关联规则挖掘：从观影行为中挖出真实的“搭配偏好”

很多做内容平台或视频业务的人，手里都有一堆用户的观影记录，却不知道怎么用起来。最常被问到的问题不是“哪些电影好看”，而是“看完这部电影的人，接下来还会看什么”。电影数据集关联规则挖掘，解决的就是这个具体问题：把“用户看过的电影”看作一笔交易，把每部电影看作交易中的一件商品，然后找出那些频繁一起出现的影片组合，并算出一条条明确的规则。它不需要复杂的用户画像，也不需要训练模型，只要你手里有用户ID和电影ID，就能跑起来。这篇文章会从数据清洗、事务编码、算法选型、参数调整到实际避坑，完整走一遍可复现的流程。

2. 把电影数据变成关联规则挖掘需要的“购物篮”：从评分表到事务列表

2.1 为什么关联规则挖掘不认普通评分表

关联规则挖掘这套方法，最早是用来分析超市购物篮的。算法本身只认一种数据结构：一条事务包含若干个“项”。放到超市场景里，一条事务就是一张小票，项就是商品。放到电影场景里，一条事务就是一个用户在一段时期内看过的所有电影，项就是电影ID。原始评分表长什么样子你肯定不陌生：每一行是一个用户对一部电影的评分，附带时间戳。这种长表看起来信息很全，但算法没法直接消化，因为它不是事务结构——同一用户的多个行为散落在不同行里，算法无法知道哪些电影属于同一次“购买”。

所以要做的第一件事，就是把用户维度拉出来，让同一个用户看过的所有电影聚合成一个列表，再转成算法可读的格式。这一步在整个挖掘流程里被很多人当成纯体力活，实际上它决定了后续所有规则的质量。如果事务聚合错了，比如把不同账号也算成同一个用户，或者把用户只看了一部的电影也拉进来，都会产生大量噪音，后面调参数怎么调都别扭。

2.2 从评分表到事务列表：标准三步

下面用一份常见的电影评分数据来走一遍标准流程。这里假定原始数据字段为 userId、movieId、rating、timestamp，评分行为代表用户对影片有明确态度，所以没有做额外过滤，直接把所有行都纳入事务构建。

import pandas as pd # 读入原始评分数据，字段约定为 userId, movieId, rating, timestamp df = pd.read_csv("ratings.csv") df = df.dropna(subset=["userId", "movieId"]) # 只看有效评分，把打过分的行为视为“对该片有明确态度” df = df[df["rating"] >= 1] # 按用户分组，把同一用户的 movieId 聚合成列表 transactions = ( df.groupby("userId")["movieId"] .apply(list) .reset_index(name="movie_list") ) # 转成 list of lists，方便后续编码 transaction_list = transactions["movie_list"].tolist() print("事务数:", len(transaction_list)) print("平均每用户看过多少部:", sum(len(t) for t in transaction_list) / len(transaction_list))

这段代码做的事有三步。第一步是删除 userId 或 movieId 为空的行，这种脏数据在导出时很常见，尤其当你从多张表 join 出数据时，经常会出现个别行字段缺失。第二步是按用户分组，把 movieId 聚合为列表。第三步是把 DataFrame 转成 Python 的列表结构，因为后面无论用哪种编码器，接收的都是这种格式。

几个参数值得注意。rating 过滤里我用了 >= 1，意思是所有评分都保留，因为只要能确认用户看过这部电影，就已经构成一次事务行为，评分高低对“看没看过”没有影响。如果你只想用高分评价来定义偏好，可以改成 >= 4，这会导致事务变小、数据更稀疏，规则挖掘的结果会更偏向“强烈偏好”而不是“泛看行为”。聚合时用 list 而不是 set，是因为有些编码器处理列表时会更平滑，去重可以放在聚合之后做。

2.3 热编码与稀疏矩阵：事务编码的两种写法

得到事务列表后，下一步是把文本化的电影 ID 转成算法能算的矩阵。最常见的做法是 one-hot 编码：每一行代表一个用户，每一列代表一部电影，单元格为 True 或 False，表示该用户是否看过这部电影。这种编码方式简单直观，列名就是电影 ID，但会出现一个绕不开的问题：列数等于全部电影的数量，而每个用户看过的电影可能只占其中极小一部分。矩阵会非常稀疏，这直接影响后面频繁项集挖掘的效率。

用 mlxtend 的 TransactionEncoder 是最省事的路线：

from mlxtend.preprocessing import TransactionEncoder te = TransactionEncoder() te_ary = te.fit(transaction_list).transform(transaction_list) df_encoded = pd.DataFrame(te_ary, columns=te.columns_) print(df_encoded.shape) print(df_encoded.iloc[:3, :5])

TransactionEncoder 会扫描一遍全部事务，找出出现过哪些电影，然后为每个用户生成一个布尔向量。这里有一个非常容易忽略的坑：如果你在事务构建阶段没有清理掉那些只有极少数人看过的冷门电影，编码后的 DataFrame 列数会非常庞大。我碰到过一次跑了上万个事务的挖掘任务，最后发现列里有一大半是只看过一次的电影，不仅让编码矩阵占用内存暴增，还让后续频繁项集计算慢到像卡死一样。

另一种编码写法是手动构造稀疏矩阵。用 scikit-learn 的 MultiLabelBinarizer 可以做到同样的效果：

from sklearn.preprocessing import MultiLabelBinarizer mlb = MultiLabelBinarizer() sparse_matrix = mlb.fit_transform(transaction_list) df_encoded_sparse = pd.DataFrame(sparse_matrix, columns=mlb.classes_)

MultiLabelBinarizer 与 TransactionEncoder 的核心区别不大，但它的输出是 numpy 数组，可以直接转 scipy 稀疏矩阵，对内存压力小很多。如果你的数据量在百万级事务以上，建议直接用这个方案，后续跑 FP-Growth 时能明显感受到差别。手动编码的好处是对数据格式有完全控制权，坏处是要自己处理列名映射，容易在电影 ID 转换时出错。

3. 选 Apriori 还是 FP-Growth：电影数据场景下的取舍

3.1 Apriori 的结构与瓶颈

Apriori 是最经典的关联规则挖掘算法，它的核心思想用一句话说就是：如果一个项集不频繁，那它的任何超集也不可能频繁。基于这个剪枝策略，它逐层生成候选集，每次生成后扫描全表统计支持度，筛掉不达标的，然后用剩下的项集继续生成更大长度的候选项。这个逻辑清晰，但有一个致命的效率问题：每一次迭代都要完整扫描事务数据库。

在电影数据集上，这个瓶颈体现得非常明显。假设你有十万用户，每用户平均看过三十部电影，那么 1 项集只有几千个，但 2 项集的数量可能就到百万级。Apriori 需要反复扫描十万条事务来统计这些组合的支持度，每轮扫描都是不小的开销。如果频繁项集数量比较多，迭代到 3 项集、4 项集时，运行时间会以指数级别增长。

我一般在两种情况下会坚持用 Apriori：一是数据量不大，几千到几万条事务，跑起来毫无压力；二是刚接触关联规则挖掘，需要看中间结果来理解算法逻辑。Apriori 的所有中间候选集都是可读的，适合调试。如果你的目的是在大数据集上快速产出规则，那它并不是最佳选择。

3.2 FP-Growth 为什么更适合电影库这类高维数据

FP-Growth 的出发点就是解决 Apriori 反复扫描数据库的问题。它把全部事务压缩到一棵 FP-Tree 上，树的每条路径代表一组共同出现的项，每个节点记录该项在路径中出现的次数。整个过程只需要扫描两次原始数据：第一次统计每个项的频率，用于过滤不频繁的项；第二次构建树。之后直接在树上递归挖掘频繁项集，不再返回原始数据。

对于电影数据来说，FP-Growth 几乎总是优于 Apriori。原因很简单，电影数据集通常是高维稀疏的——电影数量动辄几千上万，单用户行为只有几十条。这种数据放到 FP-Tree 上，树的高度不会太高，但节点数量会被压缩得非常好，内存占用和计算时间都远低于 Apriori 的候选集枚举方式。

mlxtend 库里两种算法的接口几乎一样，切换成本很低。下面是用 FP-Growth 挖掘频繁项集的写法：

from mlxtend.frequent_patterns import fpgrowth # df_encoded 是上一步得到的布尔矩阵，列名为 movieId frequent_itemsets = fpgrowth(df_encoded, min_support=0.03, use_colnames=True) # 观察候选项集 frequent_itemsets["length"] = frequent_itemsets["itemsets"].apply(lambda x: len(x)) print(frequent_itemsets.sort_values("support", ascending=False).head(10))

参数里最关键的是 min_support=0.03，它表示只有出现在 3% 以上用户行为中的电影及其组合才会被保留下来。这个值直接决定频繁项集的数量，设得太低会产生大量没啥实际意义的冷门组合，设得太高又会漏掉有商业价值的垂直偏好。use_colnames=True 让结果直接以电影 ID 呈现，而不是列索引，调试时能省去查映射关系的步骤。length 列是我自己加上的，用来标记每个项集里含多少部电影，这在排序时非常有用——因为以 support 排序时，单部热门片的支持度必然高于任何组合项集，不按长度过滤时你会看到结果前几行全是单个电影名，误以为算法没跑对。

3.3 从频繁项集到关联规则：方向与拆分

频繁项集只告诉你“这些电影经常一起出现”，但没告诉你方向。比如项集 {电影A, 电影B} 出现频率很高，它既能拆成规则“看A的人也会看B”，也能拆成“看B的人也会看A”。这两条规则在实际推荐场景里方向不同，价值也不同，所以需要在频繁项集基础上再做一步规则生成。

from mlxtend.frequent_patterns import association_rules rules = association_rules(frequent_itemsets, metric="lift", min_threshold=1.2) rules = rules[rules["antecedent_len"] >= 1] print(rules[["antecedents", "consequents", "support", "confidence", "lift"]].head(20))

association_rules 会对每个频繁项集生成所有非空真子集的前后件组合。metric="lift" 和 min_threshold=1.2 是筛选规则的两道关卡：先按提升度大于 1.2 保留正相关规则，再按置信度观察强度。这里需要注意，新版 mlxtend 的输出里有 antecedent_len 字段，老版本没有，如果你用老版本，可以自己加一列计算。

这一步最容易犯的错误是不做任何过滤直接把全部规则输出。如果一个频繁项集有 5 部电影，它能拆出 30 条规则，全部输出会让结果爆炸。所以生成规则后第一件事就是过滤掉那些前后件长度不合理的规则，这个具体操作我会在第 5 章详细讲。

4. 参数怎么设：支持度、置信度、提升度在电影数据里的落地调整

4.1 支持度：先看懂数据分布再定阈值

支持度衡量的是一个项集在全部事务中的覆盖率。电影场景里，如果一部电影只被几百个用户看过，它的支持度就非常低；如果一部热门片被几万人看过，支持度可能高达 0.2 甚至 0.3。这个差异反映到规则上，就是频繁项集结果的底部堆满长尾冷门组合，顶部被大众热门霸榜。所以你需要在跑算法之前，先搞清楚数据的支持度分布。

item_freq = df_encoded.sum(axis=0) / len(df_encoded) print(item_freq.describe(percentiles=[0.5, 0.8, 0.9, 0.95])) # 看看最常见的10部电影能到多少支持度 print(item_freq.sort_values(ascending=False).head(10))

看分布的意义在于选阈值。如果数据有 1 万用户，其中 50% 的电影只有不到 1% 的用户看过，那把 min_support 设为 0.01 会导致频繁项集数量爆炸，因为大量 1% 附近的项集都会进来。我通常的做法是：先看 50 分位和 80 分位，如果 80% 的电影支持度都在 0.02 以下，说明数据长尾严重，min_support 定在 0.02 到 0.05 之间比较合适。如果目标是做长尾内容推荐，可以把阈值降到 0.005，但你要准备好接受大量噪音。

一个常见的误区是直接把 min_support 设得很低来追求“挖掘出更多规则”。最后你会发现，规则多了，但真正能解释、能落地执行的比例反而下降了，因为大量规则是只有个位数用户看过的冷门组合，统计上根本不稳定。

4.2 置信度与提升度：一个看概率，一个看独立性

置信度的公式是 P(后件|前件)，它回答“看了前件的人里面有多少人看了后件”。这个指标很直觉，单独用它做排序却容易踩坑。举个具体例子：假设《某超级英雄片》有 30% 的用户都看过。那任何一部前件片推导到这部影片的规则，置信度都不会太低，因为这个数值的基数已经很大了。你看到一条规则置信度 0.6，感觉很强，实际上拆分两部电影单独看，后者本来就是大热门，0.6 一点都不稀奇。

提升度的公式是 P(前件∩后件) / (P(前件)·P(后件))，它衡量的是“这两个电影共同出现是否比独立出现更频繁”。提升度大于 1，说明确实是搭配关系在起作用，而不是单品热度造成的假象。所以我的原则是：用提升度做筛选，用置信度做排序。先保住“真相关”，再在真相关里找“高概率”。

这里有一个很重要的习惯：跑完规则后记得按提升度降序看一眼前 20 条，你会发现很多之前被置信度排序埋没的组合。比如《冷门纪录片A》和《冷门纪录片B》置信度可能只有 0.25，但提升度高达 4，说明看 A 的人看 B 的概率是全局平均概率的 4 倍。这类规则在专题运营里价值极高。

4.3 一个参数不对引发结果变形的实际例子

之前处理一份电影数据时，我一开始把 min_support 设成 0.01，然后跑 FP-Growth，结果频繁项集数量从预期的一千多条暴涨到七万多条，生成规则时内存直接溢出。当时第一反应是代码写错了，反复检查后发现是数据里混了约 25% 的冷门实验影片，这些影片的支持度极低，但架不住数量庞大，把频繁项集的规模顶上去了。

之后把阈值策略改成两段式：先用支持度阈值筛掉纯冷门影片，比如只保留出现在至少 50 个用户行为里的电影，再基于过滤后的影片集合重新构建事务，然后跑规则。这样处理后频繁项集数量下降了一个数量级以上，剩下的规则也更有业务解释空间。所以参数不是拍脑袋设的，它必须跟着数据分布走，你在调 min_support 前，先花两分钟看支持度分布，能省掉后面大量的排错时间。

5. 电影关联规则挖掘避坑记录：热编码、冷门片与虚假规则

5.1 现象一：热编码后数据稀疏，编码矩阵占满内存

现象：事务数只有几万条，但编码后的 DataFrame 列数上万，内存占用轻松超过几个 GB，程序运行慢到像卡死。

原因：没有在编码前过滤掉低频电影。原始数据里可能包含大量“只被一个用户看过一次”的冷门片，它们的列在布尔矩阵里几乎全是 False，但对空间和计算时间的影响却是实实在在的。

解决：在构建事务列表前，先统计每部电影的出现次数，过滤掉出现次数低于某个阈值的电影。阈值可以按绝对用户数设，比如至少被 10 个用户看过，也可以按相对比例设，比如不低于总用户数的 1%。

from collections import Counter movie_counter = Counter() for txn in transaction_list: movie_counter.update(set(txn)) # 保留至少被 10 个用户看过的电影 valid_movies = {mid for mid, cnt in movie_counter.items() if cnt >= 10} transaction_list_filtered = [ [mid for mid in txn if mid in valid_movies] for txn in transaction_list ] # 清除可能出现空事务的行 transaction_list_filtered = [txn for txn in transaction_list_filtered if len(txn) > 0]

这里用 set 去重后再计数，避免同一用户多次看同一部电影被重复累计。过滤后的 transaction_list_filtered 就是后续编码的输入，这一步做完，列数通常会减少一大半，运行效率提升立竿见影。

5.2 现象二：冷门电影干扰候选集，导致热闹的组合被淹没

现象：挖掘出的规则里有大量冷门文艺片和实验影片，它们的前件后件组合都只有个位数用户支持，业务上完全没法用。

原因：支持度阈值设得太低，或者过滤逻辑只看了绝对数量没看相对比例。冷门片虽然不是最多的，但数量庞大，低阈值下它们会大量涌进来，挤掉那些真正有商业价值的中间层内容。

解决：采用两级过滤。第一级按绝对出现用户数过滤长尾；第二级在算频繁项集时按相对支持度再筛一次。两级过滤的目标不同：第一级是为了控制编码矩阵规模，第二级是为了控制规则输出质量。我一般把第一级阈值设在“至少 30 个用户看过”，第二级阈值设在 0.02 到 0.05 之间，具体看业务线。

5.3 现象三：置信度高但提升度接近1，规则全是废话

现象：排序前 20 条规则全是“看了《热门片A》的人会看《热门片B》”，置信度都挺高，但提升度只有 1.0 左右，换谁都看得出来这两部片本来就看的人多，不需要挖掘也知道。

原因：置信度天然偏向高频后件。热门片因为基础概率高，作为后件时几乎每条规则都表现良好，实际上这是一种幸存者偏差。

解决：把筛选和排序分开。先用提升度过滤，保留 lift > 1.2 的规则；再在剩余规则里按置信度排序。如果你想专门找冷门片带动热门片的组合，可以再加条件：前件支持度低于后件支持度。这种规则对内容冷启动运营特别有用，因为你可以把冷门片推给对应热门片的观众。

5.4 现象四：评分等级混入事务，导致同一电影被拆成多个项

现象：规则里出现“电影A评分5星”和“电影A评分4星”两个项，它们作为独立项参与计算，导致同一部电影的规则碎片化，支持度被稀释。

原因：构建事务列表时，把 rating 也拼在了项里。比如把“movieId:rating”作为一个复合项，本意是区分高分和低分用户，但实际效果是把一部电影拆成三四个项，每个项的支持度都被拉低，挖掘出来的规则既乱又难解释。

解决：事务里只保留电影 ID。评分等级的信息可以留到规则生成后再过滤，比如只保留那些用户评分均值高于 4 的影片的规则。如果想分析特定评分群体的偏好，可以在事务构建阶段先把评分低于 4 的行删掉，再按用户聚合，而不是把评分融进项目名称里。

5.5 现象五：未设置最小项集长度，规则里全是单件项集

现象：规则输出里出现前件或后件为空的情况，比如一条规则只有后件没有前件，或者前件只含一部电影而它就是整个频繁项集本身。这类规则没有任何推荐价值。

原因：关联规则生成时，任何一个频繁项集都会被拆分成左右两侧的规则。如果项集只有一部电影，它只能生成一条“空前件”的规则，这种规则在数学上代表“整部电影出现的概率”，但放在“看A推荐B”的业务语境里毫无意义。

解决：规则生成后立刻过滤掉前件或后件为空的行，并把后件长度限制为 1。前件长度建议控制在 1 到 2，这样推荐理由可读性强；前件超过 3 部电影时，普通用户完全无法感知推荐逻辑。

# 过滤前后件非空，且后件只保留一个影片 rules = rules[rules["antecedents"].map(len) > 0] rules = rules[rules["consequents"].map(len) == 1] # 前件长度限制为 1 或 2 rules = rules[rules["antecedents"].map(len) <= 2]

这一小段过滤代码我几乎每次都会写上。它能立刻清掉接近一半的无效规则，让结果表变得正常许多。很多人忽略这一步，最后拿着满是空前件规则的输出在研究半天，这是典型的没读懂规则生成逻辑导致的冤枉时间。

6. 让关联规则挖掘真正落地：从规则结果到可用的观影偏好分析

6.1 用效果验证规则，而不是只信统计指标

离线挖掘出的规则，如果不经过验证，很容易给你一种“好像很有道理”的错觉。我常用的验证方法是留一验证：把用户行为按时间切成前后两段，用前段数据挖掘规则，再用后段数据检验规则是否成立。具体来说，每条规则的后件电影，在多少用户的真实后续行为中出现过，这个命中率就是规则的业务价值参考。

# 假设 train_transactions 是前段行为，test_transactions 是后段行为 train_rules = association_rules( fpgrowth(train_encoded, min_support=0.03, use_colnames=True), metric="lift", min_threshold=1.2 ) hit_count = 0 total_count = 0 for txn in test_transactions: for _, rule in train_rules.iterrows(): ante = set(rule["antecedents"]) cons = set(rule["consequents"]) if ante.issubset(txn) and cons.issubset(txn): hit_count += 1 if ante.issubset(txn): total_count += 1 print("规则命中率:", hit_count / max(total_count, 1))

这段代码逻辑很简单：在测试事务里找那些满足前件条件的样本，再看这些样本中有多少也满足后件条件。命中率越高，规则在真实行为中的可复现性越强。注意这里没有考虑规则数量太多导致的重复计数，所以我会在跑之前先做一次规则裁剪，保留前 200 条置信度最高的。

另一种验证方法是直接做人工核查。每次挖掘结果出来后，抽取排序最靠前的 50 条规则，让运营或内容团队标注“是否可推荐”。不需要多复杂，就三个选项：可用、不可用、说不好。跑一次下来，你就能得到一批规则在业务侧的真实接受度，这些标注结果反过来还能作为调整筛选参数的依据。

6.2 一套可复制的最小落地流程

我把电影关联规则挖掘的流程固定成了四个步骤，每次换数据都照着跑一遍。第一步导数据，限定字段范围和时间窗口；第二步清洗并构建事务；第三步用 FP-Growth 挖掘频繁项集并生成规则；第四步输出规则表，按业务分数排序。

# 给规则加一个可调节的业务分，方便运营侧排序 rules["business_score"] = ( rules["confidence"] * rules["lift"] * 0.8 ) rules = rules.sort_values("business_score", ascending=False)

业务分公式里的 0.8 是时间衰减系数，你可以替换成更复杂的权重，比如最近行为权重或内容质量分。这里要提醒一点：不要追求把所有指标融进一个公式，业务分的核心目标是让运营人员有一个稳定、可解释的排序依据，而不是做一个黑匣子分数。规则本身的可解释性才是它最大的价值。

流程跑熟之后，你会发现真正的效率瓶颈往往不在算法上，而在“规则生产”和“规则消费”之间缺一条通道。产出规则只是第一步，怎么把规则推给下游推荐系统，怎么生成运营专题，才是投入产出比更高的环节。我目前的做法是把规则存成一张宽表，键是前件电影 ID 集，值是后件电影 ID 加规则指标，下游业务按需查询，可以做到每日更新一次。

6.3 关联规则之外：方向与迭代

关联规则挖掘在电影数据上还能往两个方向延伸。第一个方向是引入内容属性，把项从“电影ID”换成“类型”“导演”“演员”等维度，比如挖掘“喜欢某导演的人还会关注哪些演员”“看某类型片的人还会看哪些导演的作品”。这类规则在一些电影库内容稀疏的新平台特别有用，因为单纯靠电影 ID 做关联可能没有足够的共现数据，但聚合到类型和创作者维度后数据就足够支撑有意义的分析。

第二个方向是加时间维度，规则变成“看完A之后的一周内看了B”。这属于序列模式挖掘的范畴，但起步阶段你完全可以用关联规则打底：先把时间窗口切割好，比如以 7 天为一个窗口切分用户行为，再在每个窗口内构建事务，挖掘窗口内的共现规则。这个方法比直接上序列挖掘算法更直观，而且结果很容易做对比分析，识别出“短期搭配”和“长期偏好”的差异。

我自己做了多次规则挖掘后，最大的收获是：先看负相关规则。提升度小于 1 的组合告诉你哪些内容不应该放在一起推荐，这种信息在运营排布上比正向规则更稀缺。每次跑完规则，我都会单独拉一屏负相关组合看看，凡是那些统计上负相关但业务直觉上“好像有关系”的组合，几乎都是埋着数据问题的线索。

把这一步也做成日常习惯之后，关联规则挖掘就成了我处理电影数据时最稳定的产出工具——它不追求预测准确率，不依赖复杂的模型训练，就是用最朴素的共现逻辑把用户行为中的结构清晰地暴露出来。希望这套流程能帮到你。

本文还有配套的精品资源，点击获取