关联分析实战：从Apriori到FP-Growth的落地指南

1. 关联分析到底在解决什么问题

1.1 从购物篮到规则引擎：一个被讲烂但没讲透的故事

"啤酒与尿布"这个故事在数据挖掘圈子里流传了二十多年，几乎每个讲关联分析的人都会拿它当开场白。但大多数人只记住了这个戏剧性的结论，却忽略了背后真正有价值的东西——关联分析这套方法论到底是怎么运作的，以及它在今天的实际项目中还能怎么用。

先把故事本身说清楚。某零售连锁的运营团队在分析POS机交易数据时发现，周四晚上同时购买啤酒和尿布的男性顾客比例异常高。进一步调查后给出的解释是：年轻父亲被妻子派去买尿布，顺手给自己带几罐啤酒。这个发现直接催生了一个经典的货架摆放策略——把啤酒和尿布放在相邻区域，结果两者的销量都出现了明显增长。

这个故事的真实性一直有争议，有人说它最早来自某咨询公司的内部案例，也有人说是某零售巨头的真实发现。但不管出处如何，它揭示的核心逻辑是成立的：交易数据中隐藏着大量未被发现的商品组合规律，这些规律可以直接指导运营决策。

关联分析要解决的问题就是：从海量的交易记录中，自动找出"哪些东西经常被一起购买"以及"这种共现关系有多强"。它不关心因果关系，只关心统计上的共现模式。这一点非常重要，因为很多人第一次接触关联分析时，会误以为它是在找因果——不是的，它只是在找"同时出现"的规律。

1.2 关联分析能落地的四类典型场景

很多人学完Apriori算法之后不知道能干什么，这里我结合实际项目经验，梳理四类最常见的落地场景。

第一类是零售货架优化与捆绑销售。这是最经典的应用。通过分析购物篮数据，找出高频共现的商品组合，然后决定哪些商品应该放在一起、哪些商品适合做捆绑促销。我做过一个母婴用品类的项目，发现"湿巾+纸尿裤+婴儿洗护"这三件套的共现率极高，但它们在门店里分散在三个不同的货架区域。调整陈列之后，客单价提升了大约12%。

第二类是电商推荐系统的召回层。关联规则可以作为推荐系统的召回策略之一。当用户把商品A加入购物车时，系统可以基于关联规则推荐那些经常和A一起购买的商品B、C、D。这个策略的好处是可解释性强——你可以直接告诉用户"买了A的人还买了B"，比协同过滤的黑盒推荐更容易获得用户信任。

第三类是内容平台的标签关联与话题推荐。在内容社区里，用户的阅读行为也可以做关联分析。比如发现"看了某类技术文章的用户，有很高概率会看另一类产品设计文章"，这就可以用来做话题推荐和内容聚合。我见过一个知识付费平台用这个方法做课程推荐，效果比基于内容的推荐好了不少。

第四类是异常检测与风控。这个场景比较隐蔽。在金融风控领域，某些交易行为的组合模式可能暗示风险。比如"短时间内修改绑定手机+大额转账+异地登录"这三个动作同时出现的概率如果远高于各自独立发生的概率乘积，那就值得警惕。关联分析在这里的作用是发现那些"不该一起出现却频繁一起出现"的模式。

1.3 为什么选关联分析而不是其他方法

有人会问：现在深度学习这么发达，为什么还要用关联分析这种"老古董"？我的回答是：关联分析解决的是"发现未知模式"的问题，而大多数机器学习方法解决的是"预测已知目标"的问题。

举个例子。你想预测某个用户会不会买某件商品，这是分类问题，用逻辑回归、XGBoost、深度学习都可以。但如果你想回答"哪些商品组合值得做促销"，这个问题没有明确的标签，你甚至不知道要找什么。关联分析的优势就在于它是无监督的，不需要预先定义目标变量，它自己从数据里挖掘出所有满足条件的规则。

另外，关联分析的结果可解释性极强。"买了啤酒的人有65%也买了尿布"这句话，任何人都能看懂，不需要解释模型内部发生了什么。这在需要向业务方汇报的场景下是巨大的优势。

当然，关联分析也有明显的局限。它只能发现共现关系，不能处理时序信息，不能处理连续变量，而且当商品种类很多时计算量会爆炸。这些问题后面会详细讲怎么处理。

2. 核心概念与算法原理拆解

2.1 三个核心指标：支持度、置信度、提升度

关联分析的所有讨论都建立在三个指标之上。这三个指标必须同时看，只看其中一两个很容易得出错误结论。

支持度（Support）衡量的是一个商品组合在所有交易中出现的频率。公式是：

Support(A→B) = 同时包含A和B的交易数 / 总交易数

支持度低说明这个组合很少出现，可能只是偶然。比如总共10000笔交易，A和B同时出现50次，支持度就是0.5%。这个值太低的话，即使置信度很高，也不值得关注，因为影响面太小。

置信度（Confidence）衡量的是在买了A的条件下，买B的概率有多大。公式是：

Confidence(A→B) = 同时包含A和B的交易数 / 包含A的交易数

置信度高说明A和B的关联性强。但置信度有一个陷阱：如果B本身就是热销品，那不管A是什么，置信度都会很高。比如"买了任何东西的人有80%也买了矿泉水"，这不代表任何东西和矿泉水有关联，只是因为矿泉水太畅销了。

提升度（Lift）就是为了解决这个问题而存在的。公式是：

Lift(A→B) = Confidence(A→B) / Support(B)

提升度衡量的是"买了A之后买B的概率"相对于"什么都不看直接买B的概率"提升了多少倍。Lift大于1说明正相关，等于1说明独立无关，小于1说明负相关。提升度是判断关联规则是否真正有价值的核心指标。

我通常的建议是：支持度用来过滤掉太罕见的组合，置信度用来筛选关联强度，提升度用来排除那些因为商品本身热销而产生的虚假关联。三个指标缺一不可。

2.2 Apriori算法的核心思想：逐层剪枝

Apriori是关联分析最经典的算法，理解它的核心思想比会调包更重要。

Apriori的核心洞察是：如果一个项集是频繁的，那么它的所有子集也一定是频繁的；反过来，如果一个项集是非频繁的，那么它的所有超集也一定是非频繁的。这个性质叫做"向下封闭性"。

基于这个性质，Apriori采用逐层搜索的策略：

1. 先扫描一遍数据，找出所有满足最小支持度的单个商品（1项集）
2. 用1项集两两组合生成2项集，扫描数据计算支持度，筛掉不满足的
3. 用2项集生成3项集，继续筛选
4. 重复直到无法生成更大的项集

这个过程中，剪枝是关键。比如如果"啤酒+尿布"不满足最小支持度，那"啤酒+尿布+薯片"肯定也不满足，直接跳过不用计算。这个剪枝策略大幅减少了计算量。

但Apriori有一个致命问题：它需要反复扫描数据集。每生成一层候选项集就要完整扫描一遍数据。如果最大项集长度是10，就要扫描10遍。对于大规模数据，这个IO开销是不可接受的。

2.3 FP-Growth：用树结构避免反复扫描

FP-Growth算法就是为了解决Apriori反复扫描数据的问题而提出的。它的核心思路是：把数据集压缩成一棵FP树（频繁模式树），然后在树上直接挖掘频繁项集，只需要扫描两遍数据。

FP树的构建过程大致是这样的：

1. 第一遍扫描数据，统计每个商品的出现频次，去掉不满足最小支持度的商品
2. 把每个交易记录中的商品按频次降序排列
3. 第二遍扫描数据，把每条交易记录插入FP树中。插入时相同前缀的路径可以共享节点，节点上记录计数

构建完成后的FP树，每个节点代表一个商品，从根到某个节点的路径代表一个商品组合，节点上的计数代表这个组合出现的次数。挖掘时从频率最低的商品开始，找到它的条件模式基，递归构建条件FP树，直到树中只剩一条路径。

FP-Growth的优势很明显：只需要扫描两遍数据，而且不需要生成候选项集。在大多数场景下，它比Apriori快一个数量级以上。缺点是FP树可能很大，如果数据稀疏且商品种类极多，FP树会占用大量内存。

2.4 关键参数怎么定：最小支持度和最小置信度

这两个参数直接决定了挖掘结果的数量和质量，是实操中最需要经验的地方。

最小支持度的设定取决于数据集规模和业务需求。一个经验法则是：如果你希望某个规则至少覆盖100笔交易，而总交易数是100万，那最小支持度就设为0.0001。但实际中我通常不会设这么低，因为会产生太多规则。

我的做法是分两步：先用一个较高的支持度（比如0.01）跑一遍，看看有多少规则；如果规则太少，再逐步降低；如果规则太多，就提高。通常我会把支持度设在能产生几百到几千条规则的范围内，这样既不会漏掉重要模式，也不会被噪音淹没。

最小置信度通常从0.5开始尝试。低于0.5的规则意味着"买了A之后买B的概率不到一半"，这种规则的实用价值有限。但如果你的业务场景对召回率要求高，可以降到0.3甚至更低。

还有一个容易被忽略的参数是最小提升度。我强烈建议在筛选规则时加上Lift>1的条件，否则你会得到大量"因为B本身热销所以A→B置信度高"的无效规则。

2.5 关联分析的几个变体

标准的关联分析处理的是"交易中有哪些商品"这种布尔型数据。但实际场景中还有很多变体：

多层关联分析处理的是商品类目层级。比如"啤酒→尿布"是底层规则，但"酒类→婴儿用品"是高层规则。高层规则支持度高但太泛，底层规则具体但支持度低。实际中通常需要在多个层级上同时挖掘。

量化关联分析处理的是数值型属性。比如"购买了5件以上商品的顾客→购买高端商品"，这里的"5件以上"就是一个量化条件。这类问题通常需要先把数值离散化，再用标准方法处理。

序列模式挖掘处理的是有时序关系的交易。比如"买了A之后，下一次会买B"，这比简单的共现关系多了一个时间维度。常用的算法有PrefixSpan和GSP。

负关联分析找的是"买了A的人反而不买B"这种模式。这在推荐场景中有用——如果你知道用户买了A，那就不应该推荐B。但负关联的挖掘比正关联复杂得多，因为项集空间更大。

3. 完整实操：从原始交易数据到可落地的关联规则

3.1 数据准备与预处理

假设我们有一份超市的POS交易数据，格式是每行一条交易记录，包含交易ID和商品列表。原始数据通常长这样：

T001, 啤酒, 尿布, 薯片 T002, 尿布, 湿巾, 婴儿奶粉 T003, 啤酒, 薯片, 花生 ...

第一步是数据清洗。实际数据中常见的问题包括：商品名称不统一（"啤酒"和"啤酒500ml"是同一个东西）、退货记录混在里面、测试交易没有剔除。这些问题不处理干净，挖掘出来的规则会有大量噪音。

第二步是格式转换。关联分析算法通常需要两种格式之一：交易列表格式（每行是一个交易的商品列表）或稀疏矩阵格式（行是交易，列是商品，值表示是否购买）。Python中mlxtend库用的是前者，pyspark.ml用的是后者。

第三步是确定分析粒度。是按SKU级别分析还是按品类级别分析？SKU级别规则具体但支持度低，品类级别支持度高但太泛。我的经验是：如果SKU数量超过5000，建议先在品类级别挖掘，找到有意义的品类组合后，再在对应品类内部做SKU级别的细化分析。

3.2 用Python实现Apriori的完整流程

下面是一个可以直接跑的完整示例。我用mlxtend库，因为它API简洁，适合快速验证。

import pandas as pd from mlxtend.preprocessing import TransactionEncoder from mlxtend.frequent_patterns import apriori, association_rules # 原始交易数据 transactions = [ ['啤酒', '尿布', '薯片'], ['尿布', '湿巾', '婴儿奶粉'], ['啤酒', '薯片', '花生'], ['啤酒', '尿布', '湿巾'], ['尿布', '婴儿奶粉', '湿巾'], ['啤酒', '薯片'], ['啤酒', '尿布', '薯片', '花生'], ['尿布', '湿巾'], ['啤酒', '尿布', '婴儿奶粉'], ['啤酒', '薯片', '湿巾'] ] # 转换为one-hot编码 te = TransactionEncoder() te_array = te.fit(transactions).transform(transactions) df = pd.DataFrame(te_array, columns=te.columns_) # 挖掘频繁项集 frequent_itemsets = apriori(df, min_support=0.2, use_colnames=True) print(frequent_itemsets) # 生成关联规则 rules = association_rules(frequent_itemsets, metric="confidence", min_threshold=0.5) print(rules[['antecedents', 'consequents', 'support', 'confidence', 'lift']])

这段代码的输出会告诉你哪些商品组合满足最小支持度0.2，以及在此基础上置信度大于0.5的规则有哪些。association_rules函数还支持用lift作为筛选指标，把metric参数改成"lift"，min_threshold改成1.0即可。

3.3 用FP-Growth处理更大规模的数据

当交易数据超过几十万条时，Apriori的速度会明显变慢。这时候换成FP-Growth：

from mlxtend.frequent_patterns import fpgrowth frequent_itemsets = fpgrowth(df, min_support=0.01, use_colnames=True) rules = association_rules(frequent_itemsets, metric="lift", min_threshold=1.2)

FP-Growth的API和Apriori几乎一样，切换成本极低。在我的测试中，对于10万条交易、500个商品的数据集，Apriori需要大约3分钟，FP-Growth只需要15秒左右。

如果数据量再大一个数量级，单机内存放不下，就需要上分布式方案。Spark的FP-Growth实现可以处理千万级甚至亿级的交易数据。核心代码：

from pyspark.ml.fpm import FPGrowth fp = FPGrowth(itemsCol="items", minSupport=0.001, minConfidence=0.3) model = fp.fit(transactions_df) model.freqItemsets.show() model.associationRules.show()

注意Spark版本的FP-Growth参数含义和mlxtend略有不同，minSupport和minConfidence是在训练时一起指定的。

3.4 规则筛选与业务解读

算法跑出来的规则通常有几百上千条，不可能全部落地。筛选策略我一般分三步：

第一步，按提升度排序，取Top 50。提升度最高的规则往往是最反直觉、最有业务价值的。比如我见过一条规则是"购买了某品牌高端酱油的顾客，有很高概率同时购买某品牌进口矿泉水"，提升度超过3。这两个品类在门店里相隔很远，但顾客群体高度重合。

第二步，排除显而易见的规则。比如"买了手机的人买了手机壳"，这种规则提升度可能很高，但没有任何新信息量。判断标准是：如果业务方看到这条规则的反应是"这还用你说"，那就应该排除。

第三步，按业务可行性分组。有些规则虽然有趣，但落地成本太高（比如需要重新调整整个门店的陈列），有些规则可以立即执行（比如在电商详情页加一个推荐位）。把规则按可行性分类，优先落地那些"高价值+低成本"的。

3.5 参数调优的实操记录

我拿一份真实的零售数据集做过参数调优实验，数据规模是50万笔交易、约3000个SKU。以下是不同参数组合的结果对比：

从这张表可以清楚看到：支持度降低一倍，频繁项集数可能增加三到四倍，规则数增加得更快。当支持度降到0.001时，规则数已经多到人工无法处理了。所以我的建议是：先用较高的支持度快速验证方向，确认有值得深入的模式后，再针对特定商品子集降低支持度做精细挖掘。

4. 常见问题与避坑指南

4.1 规则太多或太少怎么办

这是最常见的问题。规则太多通常是因为支持度设得太低，或者数据中包含了大量热销品导致的虚假关联。解决办法：提高支持度、提高提升度阈值、排除那些出现在超过80%交易中的"超级热销品"。

规则太少则可能是支持度设得太高，或者数据太稀疏。解决办法：降低支持度、按品类聚合后再挖掘、或者把分析范围缩小到某个子类目（比如只看酒水品类内部的关联）。

我遇到过一个极端情况：某便利店的数据只有2000笔交易，但SKU有1500个，数据极其稀疏。这种情况下标准的关联分析几乎跑不出有意义的规则。最后的解决方案是把SKU按品类聚合，降到50个品类级别再分析，才得到了一些可用的结果。

4.2 提升度很高但业务不认可的规则

有时候算法给出的规则统计指标很漂亮，但业务方看了直摇头。常见原因有三个：

一是规则涉及的商品组合虽然统计上相关，但业务逻辑上无法解释。比如"购买了某品牌猫粮的顾客同时购买了某款汽车用品"，提升度可能很高，但这很可能是因为某个特定人群（比如养猫的车主）恰好集中购买，不代表任何可操作的关联。这种规则需要结合业务知识判断是否值得跟进。

二是规则对应的商品组合虽然相关，但无法干预。比如发现"购买了A的顾客倾向于同时购买B"，但A和B的购买决策是分离的（比如一个是个人用品一个是家庭用品），你没法通过陈列或推荐来影响。

三是规则的支持度太低，虽然提升度高，但影响面太小。比如只有0.1%的交易满足这个规则，即使提升度是10，实际带来的增量也微乎其微。

4.3 数据质量问题的排查清单

关联分析对数据质量非常敏感。以下是我在实际项目中总结的排查清单：

4.4 关联分析结果的验证方法

挖掘出规则之后，怎么知道这些规则是真实有效的而不是数据噪音？我通常用三种方法交叉验证：

第一种是时间外验证。用前6个月的数据挖掘规则，用后3个月的数据验证。如果规则在后3个月的数据中依然成立（支持度和置信度没有大幅下降），说明它是稳定的。

第二种是A/B测试。对于要落地的规则（比如调整陈列、增加推荐位），直接做A/B测试看实际效果。这是最可靠的验证方式，但成本也最高。

第三种是业务专家评审。把Top规则拿给业务方看，让他们判断哪些符合经验、哪些出乎意料。出乎意料但统计显著的规则往往最有价值，值得深入调查。

4.5 几个容易踩的坑

坑一：忽略了商品的生命周期。新上市的商品和历史商品的关联模式可能完全不同。如果数据中混入了大量已下架商品，挖掘出的规则可能无法落地。建议只分析当前在售商品。

坑二：把关联当因果。这是最危险的错误。"啤酒和尿布一起购买"不代表"买啤酒导致买尿布"。如果基于错误的因果假设做决策，可能适得其反。比如你以为是啤酒带动了尿布，于是把啤酒降价促销，结果可能只是吸引了一批只买啤酒的顾客，尿布销量并没有提升。

坑三：忽略了季节性。夏季的关联模式和冬季可能完全不同。比如烧烤类商品在夏季的关联性很强，但冬季就很弱。如果不分季节分析，得到的规则可能只在特定时间段有效。

坑四：过度拟合历史数据。如果支持度设得太低，很容易找到一些只在历史数据中偶然出现的模式。这些模式在未来不会重复。我的经验是：支持度不要低于0.001，除非你的数据集非常大（百万级以上）。

坑五：忽略了规则的冗余性。如果"啤酒→尿布"和"啤酒+薯片→尿布"同时出现，后者可能是前者的冗余规则。需要检查规则的独立性，避免重复推荐。

5. 从规则到行动：落地策略与效果评估

5.1 零售场景的落地路径

在零售场景中，关联规则的落地通常分三个层次：

第一层是陈列优化。把高提升度的商品组合放在相邻位置。但要注意，不是所有关联商品都适合放在一起。比如"牙膏→牙刷"适合放在一起，但"高端红酒→婴儿纸尿裤"就不适合，因为购买场景完全不同。陈列调整需要考虑顾客的购物动线，不能只看统计指标。

第二层是捆绑促销。把关联性强的商品做成组合套餐，给予一定折扣。这里的关键是定价——折扣太大损失利润，折扣太小没有吸引力。我通常的做法是：组合价格比单独购买便宜10%-15%，同时确保组合的毛利率不低于单个商品的平均毛利率。

第三层是个性化推荐。在电商场景中，根据用户购物车中的商品实时推荐关联商品。这个层次的效果最容易量化，因为可以精确追踪推荐带来的转化率。

5.2 效果评估的指标体系

落地之后怎么评估效果？不能只看销量变化，因为销量受太多因素影响。我通常用以下指标：

推荐点击率（CTR）：推荐位被点击的次数除以曝光次数。这是最直接的指标，反映推荐的相关性。

推荐转化率（CVR）：通过推荐位购买的商品数除以推荐位点击次数。反映推荐的精准度。

连带率：平均每笔交易的商品件数。如果关联推荐有效，连带率应该上升。

增量销售额：通过A/B测试对比实验组和对照组的销售额差异。这是最终的业务指标。

需要注意的是，这些指标需要综合看。有时候CTR很高但CVR很低，说明推荐吸引了点击但没有促成购买，可能需要调整推荐的商品或价格。

5.3 一个完整的落地案例复盘

某线上母婴用品平台，月活用户约50万，SKU约8000个。运营团队希望提升客单价和复购率。

数据准备阶段：取最近6个月的订单数据，约120万笔交易。剔除退货和测试订单后剩余约110万笔。按品类聚合后得到约200个品类。

挖掘阶段：用FP-Growth算法，最小支持度设为0.005，最小置信度设为0.4，最小提升度设为1.2。得到约1500条规则。

筛选阶段：按提升度排序，排除显而易见的规则（如"纸尿裤→湿巾"），排除无法干预的规则（如两个不同品类的商品购买决策分离），最终保留约80条可落地规则。

落地阶段：在购物车页面增加"经常一起购买"推荐位，展示Top 3关联商品。同时在商品详情页增加"买了这个的人还买了"模块。

效果评估：运行4周后，实验组的客单价比对照组提升了8.3%，连带率从2.1提升到2.4。推荐位的CTR约为12%，CVR约为3.5%。整体增量销售额约为每月45万元。

踩过的坑：初期推荐位展示了太多低单价商品，虽然点击率高但客单价没有明显提升。后来调整策略，优先推荐单价在平均客单价30%以上的关联商品，效果明显改善。

5.4 关联分析与其他方法的组合使用

关联分析很少单独使用，通常和其他方法组合：

与协同过滤组合：关联规则作为召回层，协同过滤作为排序层。先用关联规则快速筛选出候选商品，再用协同过滤模型精排。

与时间序列组合：关联分析发现共现模式，时间序列预测需求量。比如发现"啤酒+尿布"的关联后，用时间序列预测下周两者的销量，决定备货量。

与聚类组合：先对顾客聚类，然后在每个群体内部做关联分析。不同顾客群体的关联模式可能完全不同，分群分析能得到更精准的规则。

与因果推断组合：关联分析发现模式，因果推断验证因果性。比如用A/B测试验证调整陈列是否真的能提升销量，而不仅仅是统计相关。

6. 进阶话题与个人经验

6.1 处理大规模数据的工程实践

当数据量达到千万级交易、十万级SKU时，单机方案基本不可行。我的工程实践方案是：

数据存储层：交易数据存在Hive或数据仓库中，按日期分区。商品维度表单独存储，包含品类、品牌、价格带等属性。

计算层：用Spark做分布式FP-Growth。关键参数是minSupport，通常设在0.0001到0.001之间。如果数据量特别大，可以先按品类分组，每组单独挖掘，最后合并结果。

结果存储层：挖掘出的规则存入Redis或Elasticsearch，供线上系统实时查询。规则需要定期更新（通常每周或每月一次）。

线上服务层：推荐服务接收用户当前购物车中的商品列表，查询关联规则库，返回Top N关联商品。响应时间需要控制在50ms以内。

6.2 关联规则的时效性管理

关联规则不是一成不变的。商品会下架、季节会变化、顾客偏好会迁移。我通常这样管理规则的时效性：

定期全量更新：每月重新挖掘一次全量规则，替换旧规则库。

增量更新：每周用最近一周的数据验证现有规则的支持度和置信度，如果下降超过30%，标记为"待观察"。

实时反馈：线上系统记录每条规则的点击率和转化率，如果某条规则连续一周CTR低于1%，自动降权或下线。

人工审核：每月人工审核一次Top 100规则，剔除业务上不再合理的规则。

6.3 我个人在实际操作中的几点体会

做了这么多关联分析的项目，最大的体会是：算法本身不难，难的是数据质量和业务解读。Apriori和FP-Growth的代码半小时就能写完，但把数据清洗干净、把规则解释清楚、把结果落地下去，往往需要几周甚至几个月。

另一个体会是：不要追求规则的绝对数量，要追求规则的可执行性。100条能落地的规则比10000条躺在报告里的规则有价值得多。我现在的习惯是，每次挖掘完只输出Top 50规则，并且每条规则都附上业务解读和落地建议。

还有一个容易被忽略的点：关联分析的结果需要持续跟踪。很多团队做完一次分析、落地几个策略之后就结束了，没有持续监控效果。实际上，顾客行为在变化，今天有效的规则明天可能就失效了。建立一套持续的监控和更新机制，比单次分析重要得多。

最后分享一个小技巧：如果你不确定最小支持度该设多少，可以先跑一个"支持度分布直方图"——统计所有商品组合的支持度分布，看看在哪个阈值附近有一个明显的"断崖"。通常断崖之前是真实模式，断崖之后是噪音。这个方法比盲目试参数高效得多。