关联规则解读再探

Zhu Sizheng 20060905

刘庆在http://groups.google.com/group/ttnn/browse_thread/thread/08383f2d29ad2b71
上提及了关联规则的筛选，最终的结论是：关联规则的解读不能只从数据结果看，必须得结合业务经验来阅读。

这里重新提及关联规则的解读问题，不过话题有些不同，希望大家能多指点，尤其是刘庆兄能多指教一二。

关联规则的挖掘过程脱离不了数据-〉信息-〉知识的过程，所以在进行数据挖掘的时候，对数据质量，维度建模的也有较高的要求。抛开这类问题不谈，单单就关联规则而言，其过程也有明显的步骤，如apriori算法可以分为频繁项集的生成和关联规则的生成两大步骤；FP-Growth算法更是可以分成FP-Tree的生成，频繁项集的生成和关联规则的生成3大步骤。在这些所谓的关联规则挖掘步骤中，所处理的是从数据-〉信息的过程，这里的信息所表现的形式就是关联规则，但信息并不等于是知识。所谓的知识的定义，从数据挖掘的范畴而言，可以有很多种定义。但实际上，所有发现的知识都是相对的，是有特定前提和约束条件，面向特定领域的，同时还要能够易于被用户理解。最好能用自然语言表达所发现的结果。而无论怎样的关联规则所展现的都是数据之间的联系，再向上抽象一点就是属性间的某种关联，再向上抽象一点可以理解成两种业务之间的关联，但无论怎样抽象，关联规则挖掘算法毕竟是不具有人类的智慧的，其最终结果的表现就是用数据来体现某种联系，至于某种联系，需要的是相关业务人员自己来分析的。（不知道这种观点的支持度有多高，可信度又有多少？）

现在的关联规则挖掘算法中，希望并已经引入更多的类似于支持度、可信度的概念来区分关联规则的重要程度，从而更准确的筛选出有用的关联规则，对于关联规则A=〉B其中lift（提高度：支持度AB/（支持度A*支持度B））和兴趣度（I：（支持度A+支持度B）/（支持度A*支持度B））是两个最经常被提及的概念。但这些概念的引入真的就能把重要的关联规则区分开来吗？maybe.......

如果对关联规则按对最终用户的有用程度来进行分类，大概可以分成3类：

1：有用的；
2：价值不高的；
3：令人费解的；

（《Modern Data warehousing,mining,and visualization core concepts 数据仓库、挖掘和可视化—核心概念》George M.Marakas 著 敖富江译）中的分法。

在我当初看来，也就分成两类：1：有用；2：无用。但是，怎么区分有用和无用呢？如果说一个规则的支持度、可信度和lift值都很高的话，这个规则就有80~90%的可能性是业务人员已经凭借经验发现了的并已经应用的规则，那么这样的规则到底是有用还是无用？我想这类规则就可以把它们归结成有用，但价值不高。所以，George M.Marakas提出的3类分类还是有一定的道理。

上面说到支持度、可信度和lift值都很高的规则未必就是有用的关联规则，也未必就是用户想要的关联规则，而对于一些有用的规则，有可能是隐藏在低支持度中的，那么该怎么做呢？降低支持度阈值？可降低支持度阈值所带来的后果很可能就是把这条有用的规则淹没在浩瀚的关联规则内（拽了一下，用了浩瀚这个词，不过确实当支持度很低时所产生的关联规则是海量的，相信做过关联规则的人都有体会）。当支持度降低时一下子产生海量规则的原因是不仅是因为频繁项集的增多，还因为频繁项集的增宽（宽度的增加对关联规则的数量的影响是巨大的，有一定的数学公式和理论来验证）。

而且，除了支持度降低时所带来的海量规则外，也带来了更多的令人费解的关联规则。

怎么办？用更多的业务专家来分析吧，哪来的那么多业务专家阿，即便有那么多人，谁又有那么大的耐心和精力去一条条分析.........

我一直在想，能不能把挑选有用关联规则的重担平滑的交给用户呢？产这种想法的原因有很多，比如前面说的业务专家的问题，还有一个就是最初所说的无论算法怎么改进，怎样加入更多的方法和概念来区分，但那些毕竟处理的都是数据，都是无法确定的信息。

那么怎么才能平滑移交呢？增加用户交互，除了让用户设置支持度阈值、可信度阈值、提高度阈值。（一直用提高度这个概念是因为在teradata miner 和微软的ssas中用的就是这个概念，至于置信度的概念，更多的见于复旦大学发表的论文中，还没怎么看到成熟的产品，也许复旦德门的dminer中有这个概念吧，没有具体用过。）还要增加设定频繁项集宽度（这个ssas中也已经实现）。在这些我认为比较重要的参数交互的前提下，我想是否可以加入“让用户指定要产生关联规则的项或一项集”，这里强调的是一项集而不是平常所说的频繁项集。但是“让用户指定要产生关联规则的项或一项集”是否破坏了关联规则挖掘的最大优点，那就是无目标性的，也就是它不需要选择出一种产品作为焦点来运行数据库分析，相反所有的产品都纳入可考虑之列。这是一个疑问？

“让用户指定要产生关联规则的项或一项集”所能带来的最大好处就是用户可以代替业务专家来分析规则的优劣与可用与否，从而将规则分析这一个吃力不讨好的事情踢到用户那里。反过来说，这也提高了规则发现的可能性，因为虽然说关联规则挖掘是无目标性的，但用户多多少少还是会有些特定的疑问和特定的注意焦点，那么增加了“让用户指定要产生关联规则的项或一项集”就增加了让用户聚焦自己所关心的业务的一个方式。

至于在何时、何处添加用户交互也是一个需要探讨的话题。如对fp-grwoth算法而言，是在算法的初始阶段就添加所有的用户交互好（这几乎是所有成熟产品的做法）？还是在生成ＦＰ－Ｔｒｅｅ树后添加好？还是在生成频繁项集后添加好？还是在最后已经生成关联规则后添加好？这不仅和算法的效率有关，也和选择什么样的方式和工具去做有关。如果能在现有关联规则挖掘工具的基础上添加用户交互，其实放在哪里都无所谓（：）），分步骤添加也是必然的。如果是自己写算法，那么基于效率考虑，也许放在频繁项集生成后最好(假设ing,证明ing。)

不知道我想的增加用户交互的方案是否可行？请大家不要砸我鸡蛋，多砸点意见吧。谢谢！

Chenming 20060906

你想的增加用户交互的方案其实早有人想到过。

有两种方式：

一是根据用户设定好的阈值发现所有的关联规则后，然后再通过另外一些阈值比如用户指定规则的前件或后件中的一项或全部，对得到的所有关联规则进行筛选。

二是用户事先就设定好更详细的阈值，把第一种方式中提到的后面的阈值也提到前面设定，然后再运行算法发现指定的关联规则。这就要求对算法进行一定的修改。

我个人觉得第一种方式较好。因为在设定基本的经典阈值所得到所有的关联规则后，这些关联规则可以保存，然后再通过另外一些阈值可进行多次筛选，不必再重新运行算法。

当然，在数据集非常巨大时，第二种方式也是有用武之地的。
 

Zhu Sizheng 20060906

谢谢ming chen 兄,这个想法也是在参考了别人的想法前提下才提出来的.
 
你说的第一种方式根据用户设定好的阈值发现所有的关联规则后，然后再通过另外一些阈值比如用户指定规则的前件或后件中的一项或全部，对得到的所有关联规则进行筛选。我也想到过，这样做的好处就是可以充分利用现有关联规则挖掘工具，减少开发的工作量。而且实现起来也比较简单，只要能把生成的关联规则保存到可存取的存储空间内，比如数据库或其他的文件中，那么我们就可以根据用户指定的一些阈值、关联规则的前件或后件对已经生成并存储起来的关联规则进行筛选，从而让最终用户也参与到关联规则的筛选中。这样作的另外一个好处就是它不破坏关联规则挖掘的无目标性规则，它是一种筛选符合条件的方法，或者说此时用户输入的关联规则的前件或后件就是对关联规则筛选的一种约束。

但这样做的缺点也是显而易见的，这就是受前面设定的阈值的制约。

我们可以归纳一下这种方法的流程：数据（大多数是数据集市中的数据）-〉用户设定支持度、可信度、提高度阈值-〉应用算法过程-〉获得关联规则-〉关联规则的存储-〉关联规则的筛选-〉关联规则的可视化。这其中用户在初始阶段设定的各种阈值对关联规则筛选的影响是巨大的，当各种阈值设定值不合理时，可能就不产生包含用户指定前件或后件的关联规则。如果用户指定的阈值比较小，对算法效率的影响将是巨大的。无论是Aprior算法还是Fp-Growth算法在关联规则的生成这一步骤中可以使用相同的算法（诸如FSA算法），而一个长度为10的频繁项集产生的关联规则可以有2*（10+45+120+210+252+210+120+45+10）种，所以如果将支持度等阈值设定比较低时，运用这个方法在此时显得有些......
 
对于第二种方法，ming chen兄说的对，就需要对算法进行进一步的修改。这也是我前面提到的在何时何地添加用户交互的问题。用户可以参与的交互的时机无非也就算法开始前，算法计算中，算法结束后。在第一种方法中重我们所添加的用户交互在算法开始前和算法结束后。在第二种方法中，也就是算法的计算中添加用户交互的时机又有哪些？我们可以拿FP-Growth算法作例，此时用户可以参与的交互可以分步在FP-Tree的生成后、频繁项集的生成后。如果是在关联规则生成后再添加用户交互，那么就回到了第一种方法去了。如果在Apriori算法中，可以添加用户交互的时机只能在频繁项集生成后；那么为了增加更强的适用性，我认为将用户指定的前件或后件的交互添加在频繁项集生成后是最合适的。支持这种观点的论据如下：

1：在频繁项集生成后添加用户交互同在关联规则生成后添加用户交互所产生的结果是一致的；（可以证明，证明略）

2：这样做不会破坏关联规则无目标性这一大优势

3：这样做可以避免在第一种方法中产生的问题，从而提高关联规则的生成效率。

但是这样做也不可避免的带来新的问题：

1：频繁项集的支持度确定的时机问题

2：是否需要生成完全项集的问题（我原本的想法就是利用FP-Growth算法的特性生成完全FP-Tree,然后生成完全项集，但这样做所付出的代价也将是巨大的，代价的付出还是集中在频繁项集的产生上。）
 
另外一个疑问就是，这样做对原有算法将产生多大的改动？在关联规则的算法中，很明显的分成两大部分，一部分是频繁项集的获取，另一个部分就是关联规则的生成。关联规则生成算法可以是并行或串行的原因就是因为频繁项集产生关联规则时的迭代性。由于在关联规则产生以后添加用户交互，因此对频繁项集的产生算法不需要有怎样的修改。只需要对关联规则生成算法进行一定的修改即可。
 
该如何修改呢？另外上面提到的一些疑问又当如何思考呢？
请大家多提宝贵意见。

Qing 20060906

这阀值的设定真是有些难度哦。
 
反正我是没找到什么好的方法，到最后，基本上采用chenming所说的第一种方法。将规则列出来，对前件和后件进行过滤。这里，我不知道"前件"和"后件"是什么东西，但猜测，应该就是指关联分析之中，一种业务（属性）和另一种业务（属性），它们就是前件和后件吧。不知道我想的对不对。
 
在7月底，我谈到的关联规则解读一系列中，开始，我用的就是设定阀值的方法，对置信度、支持度和提升率设定了相应的值。但最后发现，如果这样一刀切，确实将很多有意义的规则隐藏起来了，在真正解读的时候，并没有用这个方法。其实想想，对这几个指标设定阀值，实在没什么客观标准，也不知道经验能不能帮的上忙。例如置信度小于0.1的是不是就真的意味这条规则没有意义。如果说客观，似乎只有提升率能有个基本的标准，如果它小于1的话，自然就让这条规则没有意义。可一般在这个标准上看，仍然有很多"垃圾"规则。
 
在前后件上做过滤，我当时按照我们的习惯，称之为业务一、业务二。
 
将业务二目标，如果我要让用户使用业务二，就去定位哪些已经使用业务一的。这个目标一定下来，其实是可以过滤好多规则。剩下的，即便是一条一条地审视这些规则，也可以容忍。
 
关联分析这种东西，看起来客户挺喜欢。可能是它的思路比较简单明了吧，不像其他的分类预测、聚类模型等，客户始终搞不懂，你是怎么预测出来的，是怎么将一群用户聚在一起的。要去解释这些模型，总是说得太复杂（将这些模型说得简洁，那得需要一定功力），还是无法理解。而关联分析，一条一条的规则，容易接受一些。
 
不过有一次，有位客户希望能不能将关联分析做成自动化的，也就是自动地提取有意义规则，并且根据这些规则锁定目标客户群。这个想法当然有些理想，我们做不到。
 
为什么做不到，就是因为思征提到的这些问题。缺少客观依据去设定这些阀值。因此，我们现在还是来点"人工智能"吧。
 
另：思征说了很多的专业术语，看着有些吃力。当然在这里解释这些术语是不太合适的，如果兄弟们愿意整理这些术语的，请到ttnn矩阵上去走走。关于"关联规则"这项，请看：
http://ttnn.c3crm.com/index.php?title=%E5%85%B3%E8%81%94%E8%A7%84%E5%88%99

微信扫一扫实时了解行业动态

微信扫一扫分享本文给好友