关联规则解读再探
朱思征
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。)
不知道我想的增加用户交互的方案是否可行？请大家不要砸我鸡蛋，多砸点意见吧。谢谢！
Ming Chen
你想的增加用户交互的方案其实早有人想到过。
有两种方式：
一是根据用户设定好的阈值发现所有的关联规则后，然后再通过另外一些阈值比如用户指定规则的前件或后件中的一项或全部，对得到的所有关联规则进行筛选。
二是用户事先就设定好更详细的阈值，把第一种方式中提到的后面的阈值也提到前面设定，然后再运行算法发现指定的关联规则。这就要求对算法进行一定的修改。
我个人觉得第一种方式较好。因为在设定基本的经典阈值所得到所有的关联规则后，这些关联规则可以保存，然后再通过另外一些阈值可进行多次筛选，不必再重新运行算法。
当然，在数据集非常巨大时，第二种方式也是有用武之地的。
