读“从属性到身份”

[happy]

读了庆兄在“从属性到身份”中对于属性和特征的分析，也试着尝试按照这种思路分析一下我遇到的业务，请大家指点：

那么维度是否也算是属性呢？度量就算是变量了。比如：纳税人的纳税人类型、企业投资规模应该也是属性吧，它们是离散的；而税负率（应纳税额/收入）应该算是变量，它是连续的。
在对纳税人进行纳税评估分析时，把纳税人类型、企业投资规模、税负率都作为属性来看待，就需要对税负率进行离散化操作，比如：正常平均税负是在0.4与0.5之间，0.5以上属于高税负，0.4以下属于低税负。而0.4，0.5的设置应该属于阀值的定义。

我们现在进行纳税评估分析的主要步骤是这样的：
1) 纳税人分群
根据已知的有违反纳税规定的纳税人数据进行聚类，找出这些纳税人的特征，作为目标特征。
2) 纳税人打分
根据上面得到的特征，给纳税人进行打分。打分应该就是和目标特征的相似度吧，越相似的分数越高。

公司专门有一个学统计的定义模型，所以我的描述也许不够专业，让大家多费心了。我有几个问题请教大家：
1) 在“关联规则解读再探”中，庆兄和思征兄对于阀值使用的方式进行讨论，就我上面提到的场景，属性的阀值应该在哪个步骤应用？怎么用？
2) 以前庆兄和思征兄都谈到过阀值的定义是一个很难的事情，我们能不能根据经验先定义一个值，然后再慢慢调整？
3) 听我们公司负责模型的哥们说，他不需要人工定义阀值，他可以通过计算算出阀值。因为既然阀值的定义很难，干脆就全部用机器来给出阀值，然后再人工筛选。不知哪位有这方面的经验？
4) 各位觉得我说的场景中的步骤正确吗？是不是有不合乎逻辑的地方？

thanks
　　　　　　　　致
礼！
happy
　　　　　　　　　　2006-09-23

_ _ _ _
/_/_/_/_/\
/_/_/_/_/\/\
/_/_/_/_/\/\/\
\_\_\_\_\/\/\/
\_\_\_\_\/\/
\_\_\_\_\/



丁西宁
数据仓库解决方案经理
蓬天信息系统（北京）有限公司
Prient Corporation
Power Realtime Intelligent ENTerprise

北京市朝阳区东大桥路8号尚都国际中心25层
电话：8610-58700800 ext 855
传真：8610-58700800 ext 808
手机：86-13910959723
E-mail：xinin...@prient.com
MSN:happ...@hotmail.com
BLOG:http://java.mblogger.cn/happyjava
http://www.prient.com

[Qing]

关于对连续型数值离散化的话题，或者说，是从定量变成定性。方法可能是有不少的，也许那是统计学里面有比较详细的讲解。像我这样一知半解的，只能想到哪儿说到哪儿，照着书本去研究理论，没那个耐心，也指望着一些专家来指导一下。

 

周围有一些这样的专家，如何离散化，得到过一些帮助。在《概貌分析之实践》中，曾经谈过自己尝试的一种方法，虽然后来觉得那种方法比较笨的。就是用quantile函数，根据某个连续值以及样本记录的数量，分成若干份。这是一种比较简单的分法。当然，还有bin、ban的分法，这两者有一次听朋友告诉我它们的区别，现在忘了。好像有一种是根据数值来等分的，例如值的范围是0－100，分成5等，就是(0,20],(20,40]...不论每组里面的样本记录数量是多少，甚至是0。

 

最近设计一个专题分析的时候，也遇到类似的问题，更简单。譬如说，客户的价值，要划分出来一个高和低出来。这里只是拿客户价值举例子，一般来说都已经有客户等级这样的属性了，当然这个属性的由来，恐怕也等通过离散化的手段来完成，不是拍着脑袋就出来的。当然，我可以估计一下，从业务经验上判断，如果一个客户的月消费超过300，它就是高价值，否则为低价值。这无疑是拍脑袋，如果经验丰富，拍脑袋也无妨。但如果要讲点什么科学依据呢，那就得找点辙。

 

我找得辙是用帕雷托原理，也就是常说的二八原理，在这里为客户价值离散化的场景下，可以说成是，"20％的客户产生80％的价值"。说实话，我不知道这个原理到底是在什么环境下才成立的，曾经死板地套用过，例如对所有客户统计过，贡献最大价值的前20％客户，并非产生了80％的价值，可能是50％，或者60％，要是70％，我还凑合着信了这个原理。

 

但无论怎样，这条原理始终是个原理，有时候拿出来确实能够震的住的，如果你不愿深究的话。

 

于是，按照这个思路，我首先按照客户价值排序，取前20％数量的用户。然后取出其中价值最小的那个值，差不多地，抛掉零头，取整，便作为高低价值划分的阀值。

 

划分之后，跟局方讨论，还行，至少从他们的业务经验判断，这条线大差不差。可自己还是心存疑虑，因为它后头基于的原理好像并不太令人信服啊。

 

说起来，这种划分方法，跟开始提到的quantile方法是类似的，都是根据记录数量来划分。

 

但西宁在文中还提出，关联分析规则解读中，对置信度、支持度的阀值，我想这里的"阀值"跟上面客户价值的"阀值"总是有点区别，虽然无法将它表述清楚。你想，对客户价值定义高低，是区分他们的等级。而对置信度、支持度的阀值，它是要确定该规则有无意义。而前者，高价值的客户需要关注，低价值的客户也需要关注。如果要是用同样的二八原理去给置信度、支持度来界定阀值，似乎不大能够行的通。

 

On 9/23/06, happy <xinin...@prient.com> wrote:

读了庆兄在"从属性到身份"中对于属性和特征的分析，也试着尝试按照这种思路分析一下我遇到的业务，请大家指点：

...

[Zhu Sizheng]

西宁兄，庆兄:

 

        关于关联规则阈值的使用方式和时机，从业务上来说似乎不太好说，我手头也没有太好的例子。最近一直在研究关联规则算法中阈值的使用时机问题，现先将思路整理如次，具体的详细论证可能还需要一些时日。

 

       1：使用阈值的目的何在？

            阈值的使用是为了获取合乎约束的规则，也就是说是为了筛选自认为有用的规则。

            关联规则的是事物之间的普遍联系。关联规则从本质上说是一种普遍联系的反映，通过一种特定的衡量方式来描述事物之间的某种特定联系，而这种衡量的方式就是统计学原理。它通过统计并分析大量的已经存在的单个事务间多个事物的内在联系来寻找事物间的普遍联系。

 

       2：什么样的规则才是有用的规则？

            规则是否有用最后谁说了算？用户，当然是最终用户。用户说有用才有用，不然即便各类阈值设定的再完美，也没有什么价值。至于关联规则的有用与否的分类，我比较赞同如下的分法：    

               （1）：有用的 

                有用的规则是指对用户有帮助的规则。如著名的啤酒和尿布的故事。

               （2）：价值不高的

               价值不高的规则是业务领域内众所周知的规则。例如，发现购买电视延长保修期的人通常也会购买电视机—因为没有电视保修期是无意义的；比如，原本原本知道某门课程A是学校规定学生必选的课程,而用课程A推选出来的规则对用户而言意义也不大，价值也不高。

              （ 3）：令人费解的

                 这类规则并不明显，也不一定没有用处，但并不具有明显的商业价值。如发现只有当新的五金店开张时盥洗室的门把手才会卖的好。没有明显的原因证明会导致这种趋势的出现，为什么人们只有当新五金店开张时才需要盥洗室的门把手？这其中似乎隐含着某种规律性，但是其中的原因我们并不清楚。

 

         所以，关联规则有用与否的评定权紧紧的握在用户的手里面，但因为关联规则算法的原理基于统计学方法，所以从数学的角度，引申出来了一些阈值，称为客观性度量标准。另外还有一些主观性度量的阈值，主要取决于用户的意愿，带有比较明显的主观性质。

 

       3：客观性评价指标类阈值

            这类阈值主要有：支持度，置信度，提升度

            如：支持度是用来衡量项集在事务集中出现的频率。

                  置信度是用来描述在出现关联规则左件（左项）的前提下又出现关联规则右件（右项）的概率。置信度: P(B｜A)，即在出现项集A的事务集D中，项集B也同时出现的概率。

                提升度是用来衡量关联规则左件与右件独立性的指标，也就是概率论中的                               P(AB)/P(A)P(B)。

      

        4：主观性评价指标类阈值

            这类阈值主要有：新颖度，用户感兴趣度，简洁度

            新颖度是将新产生的关联规则与已经存在的知识库中规则进行比对后得出的一个指标，这个和专家库息息相关，在科学研究领域应用比较多，在商务领域应用比较少。

            用户感兴趣度就是为了满足用户只想看包含自己想看的项的规则而设定的指标，比如用户在业务进行中对某个项比较感兴趣，她就可以指定计算与这个项相关的规则。

            简洁度就是指定规则或者项集的宽度。简洁度（记为CN）是用来衡量关联规则的最终可理解程度的指标。它也表现在两个方面：一方面表现在规则的个数上，如果规则项数很多将不利于对这条规则的理解。因此，规则的项数越少，规则的简洁性越好。另一方面表现在规则所包含的抽象层次上，规则包含的抽象层次越高，它对应的解释力越强。

            这个指标在apriori系列算法中颇为有用。其他指标适用于关联规则的所有不同算法。

 

        

          关联规则的实现总体可以分为两大步骤：一是频繁项集的获取，二是关联规则的生成。

 

 

          5：apriori算法中各阈值的设定时机探讨

          5.1：应用Apriori算法的现存工具

                  现在几乎所有的现成工具中使用的的联规则算法是apriori"系列"算法，如sas中的enterprise minier,microsoft 的ssas使用的是priori算法，另外，IBM是关联规则apriori算法的传造者，是否使用就不言而喻了。所以这里先讨论apriori算法中各阈值的设定时机，如有机会，对Fp-Growth中使用各阈值的时机仍会作一个讨论。

           5.2：Apriori算法

                   详见ttnn 矩阵：

                    http://ttnn.c3crm.com/index.php?title=%E5%85%B3%E8%81%94%E8%A7%84%E5%88%99%E6%8C%96%E6%8E%98%E7%AE%97%E6%B3%95%E7%BB%BC%E8%BF%B0#.E7.BB.8F.E5.85.B8.E7.9A.84.E9.A2.91.E9.9B.86.E7.AE.97.E6.B3.95

                   Apriori算法总体可以分为两大步骤实现，一是频繁项集的获取，二是关联规则生成。关联规则的生成算法相对固定，因此挖掘关联规则的总体性能由第一步决定，第二步相对容易实现。
            5.3：Apriori算法中的频繁项集生成

                    Apriori首先产生频繁1-项集L1，然后是频繁2-项集L2，直到有某个r值使得Lr为空，这时算法停止。这里在第k次循环中，过程先产生候选k-项集的集合Ck，Ck中的每一个项集是对两个只有一个项不同的属于Lk-1的频集做一个(k-2)-连接来产生的。Ck中的项集是用来产生频集的候选集，最后的频集Lk必须是Ck的一个子集。Ck中的每个元素需在交易数据库中进行验证来决定其是否加入Lk，这里的验证过程是算法性能的一个瓶颈。这个方法要求多次扫描可能很大的交易数据库，即如果频集最多包含10个项，那么就需要扫描交易数据库10遍，这需要很大的I/O负载。

                     在频繁项集生成步骤中需要统计的关键指标：总事务数，每个项集出现的频次

                     在频繁项集生成步骤中可以引入的阈值有：支持度，简洁度

                     在本阶段引入支持度的原因和目的：

                           1：从数学角度分析，好像不需要什么阈值。（迷惑ing）

                           2：频繁项集产生的初始步骤是产生频繁一项集，频繁一项集定义为支持度大于最小支持度的一项集称为频繁1项集，所以此时需要指定最小支持度；

                           3：候选项集的产生是频繁项集进行叉积的结果。因此频繁项集的多少（或者可以称之为频繁项集集合的大小）是影响算法效率的关键因素之一。因此，设定最小支持度，通过进行剪枝操作，可以对参与运算的频繁项集进行控制；

                      在本阶段引入简洁度的原因和目的：

                           1：确定了项集的SIZE也就确定了扫描事务数据库的次数。

                           2：项集size的大小不仅决定了扫描次数，对关联规则的生成效率也有较大影响。

                           3：过多事物之间的线性联系容易造成规则解读上的困难。如，重点不突出。

              

           支持度大小对关联规则筛选的影响：

                 1：支持度越大，关联规则越有分量吗？

                 2：支持度越小，关联规则的有用性就越小吗？

                 3：支持度阈值的最大缺点是什么？

            我试图自问自答： 

                 支持度阈值设定的越高，所求得的频繁项集数目（&关联规则数目）越少，且频繁项集（&关联规则）出现的频次也相应越高（出现频次低的项都被无情的抛弃了），但此时容易出现的情况是：最后获取的关联规则是有价值但价值不高的规则（价值不高的规则是业务领域内众所周知的规则。例如，发现购买电视延长保修期的人通常也会购买电视机—因为没有电视保修期是无意义的）此时最可恨是发现了已经发现过的，抛弃了有可能很有用的规则。试问60%的概率和59%的概率区别会有多大？但当支持度阈值设定在0.6的时候，那么支持度为0.59的规则就会被无情的淘汰。支持度越低，关联规则的可用性就会越小？未必见得，但苦于无现实例子说服,只能凭直觉。总体感觉是这样，0.03也就是3%的支持度阈值应该算低的吧，100个里面出现3个纯属小概率事件，但是我们知道大多数数据挖掘面对的都是数以十万计百万计的事务，十万* 0.03=3000,当有三千个同类出现的时候,整体也较为可观了吧,如果百万计呢？

                 另外一点，就是支持度对关联规则的求取到底起到的是什么作用？我试图从算法执行的过程来分析一下：对于apriori算法，如果支持度阈值设为0（亦即没有支持度阈值的限制），那么所发现的项集应该都能被称为频繁项集。我们先从1项频繁集作起，此时的一项频繁集就是事务集中所包含的所有的项的集合，真正做到了关联规则的无目标性挖掘（体现事务是普遍联系的，狗屁哲学，没有区分的联系，没有重点的联系对于用户来说就是一团烂麻，一陀大便）。然后在生成2项候选项集的时候不需要支持度阈值，对2项候选集进行剪枝时也不需要支持度阈值（此时将生成所有在事务集中存在的2项集并作为频繁2项集使用），同样的推理，进行n项频繁集生成的过程中都可以忽略支持度阈值的存在。 也就是说，从数学的角度而言，支持度阈值是可有可无的。但是，从算法的效率角度分析（减少了参与计算的项，增加了与阈值进行比对的代价，所以对算法效率的支撑也是一个相对的概念，从绝大多数的情况来看，支持度的不同对算法效率的影响是很大的），从用户筛选规则的便利性角度分析，从抓住主要矛盾的观点分析支持度阈值是必须的 ，所以，我认为引入支持度阈值的目的在于规则筛选&算法效率。但是，有利总归会有弊端。支持度阈值的引入解决了规则筛选&算法效率的问题，却带来了一个最大的，被无数人诟病的的问题：会丢失可能有用的规则。（几乎所有的阈值都会有类似的境况）这恐怕也是大多数人在阈值设定上存在犹豫、疑惑的原因吧。   （人性中最大的弱点：贪婪与恐惧在此暴露）               

          

        说了这么多还没有牵涉到具体到阈值设定的大小该如何去思考，该遵循怎样的思路。我的想法是先将这几个代表性的阈值解读后，能有一个综述性的阈值设定的思路。这需要大家多讨论，共同探讨一下究竟该怎样去思考阈值的设定。

 

         明天放假，今天先写这么多。下面还有关于关联规则其他阈值的解读以及阈值确定的思路。祝各位假期愉快！多多讨论。

 

        另外，西宁兄。阀值和阈值之间的区别我查了一些资料，你看是否可以讨论一下这两个术语，然后确定下来，为大家探讨问题提供一个清晰的定义。

 

"阀值"和"阈值"

作者：夏　朝　晖    (计算机应用编辑部,610041 ,成都)

辞海》中关于"阀"和"阈"的词条如下:
阀fá　控制、开关、把持。
1) 机械名词,指在管道中用来控制液体或气体的部件。意为阀门、开关、把持。如截止阀、减压阀、安全阀。
2) 在某一方面有特殊支配地位的人物或集团,如军阀、财阀。
3) 阀阅。大门外的左右柱,左为阀,右为阅。亦指功绩和经历。

阈yù　范围,边界,程度。
1) 门槛、门限,引申为边界、界阈、视阈。
2) 阈浓度,用作制定最高容许浓度的基本参数。

可见"阀"与"阈"是词义不同的2 个词。那么"阀值"会不会是一个新词呢? 经查,不是! 因此,在表达"界限"、"范围"的意思时应该用"阈"而不是"阀"。可是为什么有那么多人用错呢? 我想大概有2 个方面的原因:一是"阈"和"阀"字形比较相像,容易混淆;二是"阀"字的"开关"之意容易随意引申出"过了某个界限开或关",从而将"阀值"当成是界限值的代名词。

看来还是阈值更权威一些，而且跟英文threshold value对应。

--
朱思征

[Qing]

国庆七天累，回来继续吹。

 

今天是8号，打开信箱，咕咚咕咚好多新信件。打开这篇一看，不由大叹一声，我操，I服了sizheng。洋洋千言，不仅介绍了阀值和阈值的区别。还介绍了在算法中，对几种阈值选择的考虑。甚至，从人性的角度来阐述阈值选择的困境。原来，真的不明白原来这个问题里面还是有这么多道道的。

 

从定量到定性，我想这里讨论阈值都是属于定量范畴的吧。最后总归要给每条规则定个性。上一次的关联规则解读中，我只是定了两个性：有意义、无意义。即通过支持度、置信度、lift来过滤，也从业务意义上过滤，但后来发现效果真的不好。稍微总结一下，还是觉得对支持度、置信度一刀切的方法不太合适，总担心会丢掉一些"有意义"的规则，也许这就是体现了人性的贪婪了吧。最终的结果是几乎都是从业务理解角度，"拍脑袋"地选出一些"有意义"的规则，当然这个拍脑袋过程，肯定是与那些指标有关系的。不可能一个规则的lift<1，还将它当作有意义的。

 

思征兄认同的三种对关联规则定性划分：有用的、价值不高的、令人费解的。这种划分也许好一些，但还是有个问题。

 

如果关联规则只是供理解，如此的划分便于认识业务之间的关系。但如果关联规则是要用来支持前台的营销活动，那么就必须得是明确而非模棱两可。比如要用这些规则来提取一些客户名单用于营销，价值不高的就不提取了吗？未必啊，价值不高只是说这些关联可能一眼就看出来，但实际上确实有效。"有用的"规则自然可以用来提取名单。但"令人费解的"呢？也许这些令人费解的规则是有用的，也许也是价值不高的啊。

 

这个问题不知思征兄如何考虑的？
 

On 9/30/06, Zhu Sizheng <seaso...@gmail.com> wrote:

。。。

。。。