关于数据挖掘工具的讨论

1 view
Skip to first unread message

redyu...@gmail.com

unread,
Jul 25, 2006, 9:47:34 PM7/25/06
to ttnn BI 观点(472成员)
由于我刚刚接触数据挖掘领域,想找一个工具来试验一下是否能够运用到实际项目。至今为止,发现SQL
Server2005是一个门槛比较低的工具。不知道有多少人在实施数据挖掘的项目,你们都使用什么工具呢?大家能否来讨论一下数据挖掘工具呢。

exia

unread,
Jul 26, 2006, 4:58:06 AM7/26/06
to ttnn BI 观点(472成员)
现在天津联通 和上海电信正在使用SAS做数据挖掘
另外所有的银行的信用卡中心都在上SAS做风险分析的数据挖掘

redyu...@gmail.com

unread,
Jul 31, 2006, 10:46:08 PM7/31/06
to ttnn BI 观点(478成员)
由于项目还处在调研阶段,BI方案是否能解决问题不是完全由技术人员说了算的。所以这个时候SQL
Server2005作为试验用途是最好的选择了(正如Qing所说,它是麻雀虽小,五脏俱全)。
就Data
Mining这一块,我也分析了几天了。我之前还真没有什么统计学基础,按照例子跑了一遍,发现很多结果匪夷所思。看来这和编程不一样,正确与否没有评判标准的。
但是我有个想法,SQL Server2005的Data
Mining是否过于简单,虽然使用起来方便,导致分析人员可操作的余地非常小?
使用过其他昂贵的Data
Mining工具(SAS,SPSS...)的同仁能否分享一下,你们在做挖掘时,通常都是怎么做的呢?
有实际例子当然更好了。

Qing

unread,
Jul 31, 2006, 11:50:23 PM7/31/06
to tt...@googlegroups.com
我没有做过具体的挖掘建模工作,但项目组里面有这样的人。观察他们的工作,基本上有些模式可循。当然,这些模式反映出来应该可以称得上是方法论了,SEMMA、CRISP-DM都是。
 
这些方法论路子都差不多,先理解业务,再理解数据,整理数据,建模,评估。不过功夫还是在细节处。曾经考虑过,是否能够将数据挖掘和后续应用设计的接口隔离开来,数据挖掘是一个黑盒子,指定一个输入,得到输出。但这种想法目前还是嫩了点。虽然,可以对挖掘模型指定一个目标值,例如lift要达到3。但事情没怎么简单。
 
如果仅仅达到lift>3的目标,有很多技巧可以达到目的。就挖掘建模这项工作来说,工作方法可以分成操作员型和分析员型的,看起来就不一样。操作员型的,只要达到这个目标就OK,反正就是按照固定的方法。宽表里面整一大堆字段,扔到挖掘工具里面转转,得出结果,然后评估,只要达到3以上,OK,完成任务。具体模型内部是怎样的,譬如哪些因素对最终的预测目标是最关键的,不关心。
 
模型竟然对他成了一种黑盒子。上面提到,将数据挖掘看成当作黑盒子,但还是得有人在黑盒子里面了解其构造,现在倒好,没人再了解其中构造了。
 
还有一种分析员型的,他们建模会比较积极。在数据探索上花费大量的时间,想确定最合适的输入变量,模型训练完了,看到比较奇怪的结果,还要去查明原因。他们几乎是完美主义者。
 
这里并不想批判某种工作方式,这跟个人的态度有关,我也是非常厌恶那种"员工还是积极的好"的论调,那完全是从管理者角度发出的。当然,如果从协同工作角度,肯定还是希望和分析员型的建模人员一起工作。虽然也有问题,总是没完没了地看数据,极尽完美,有时候会受不了的。
 
不论是操作型或是分析型的挖掘建模,都不简单。反正对我来说,是有些害怕投入精力去了解哪些工具应该怎么去使用,细节的参数应该如何调整。那些东西需要数学统计知识,需要经验,甚至是需要业务敏感的。因此,你可以为挖掘模型建立一个度量,衡量其好坏。但建模人员的技能,似乎还是很难去度量的。
 
所以,那些挖掘建模人员在我心目中就像神一样。

 
On 8/1/06, redyu...@gmail.com <redyu...@gmail.com> wrote:
由于项目还处在调研阶段,BI方案是否能解决问题不是完全由技术人员说了算的。所以这个时候SQL
...

Mr.Somebody

unread,
Aug 1, 2006, 4:35:19 AM8/1/06
to ttnn BI 观点(478成员)
对把模型当黑盒子的态度不敢苟同.
数据挖掘的目的并不完全在于最终的模型,还在于建模过程中的知识发现.
一个模型如果是没办法合理解释的话它的用处很有限.我只能说敢不了解模型的解释力而直接套用模型的人要么是很有魄力(我不知道他的信心是从哪里来的)要么是没有知识.

happy

unread,
Aug 1, 2006, 10:57:12 AM8/1/06
to tt...@googlegroups.com
上周刚刚接受了为期三天的SPSS的培训,虽然时间很短,也还是小有收获。
SPSS的数据挖掘方法论是CRISP-DM,包括业务理解、数据理解、数据处理、建模、模型评估、模型发布这个六个步骤。国外很注重方法论的研究,所以对CRISP-DM理论的深入研究对于理解数据挖掘一定很有帮助。
SPSS软件与SAS相比,优点就是很容易上手,三天下来,每个人都可以完成一套完成的挖掘流程,建立所谓的数据模型。为什么说是所谓的数据模型呢?在上述的六个步骤中,前三个即业务理解、数据理解、数据处理不需要太多的数理统计分析的知识,只要稍微学一下数据挖掘的课程就能够掌握,像关联规则、聚类分析等算法主要是用来帮助我们对于数据的理解,只需要了解算法能干什么就可以。最难的就是模型的建立,首先要理解决策树、神经元网络等等这些算法的含义,不然的话对于这些算法参数的调整自然无从下手。其次是对于模型建立的每一个步骤要能够给出合理的解释,包括从业务角度以及数据的角度。不然的话,随便丢一个算法上去,也会生成一个模型,但要是无法解释它的过程和结果,模型就没有含义,这就是为什么说它是个所谓的数据模型。
与SAS相比,SPSS非常的易学易用(当然我还没接触太深),拖拖拽拽就完成了一个挖掘的流程。我觉得对于刚刚开始接触数据挖掘的客户和开发商来说,不失为一个好的数据挖掘工具。
不过最近发现,最好还是要有数理统计分析的知识,不然越往后越不知人家在说什么。



======= 2006-07-26 09:47:34 您在来信中写道:=======

>由于我刚刚接触数据挖掘领域,想找一个工具来试验一下是否能够运用到实际项目。至今为止,发现SQL
>Server2005是一个门槛比较低的工具。不知道有多少人在实施数据挖掘的项目,你们都使用什么工具呢?大家能否来讨论一下数据挖掘工具呢。
>
>>

= = = = = = = = = = = = = = = = = = = =


        致
礼!


        happy
          2006-08-01



redyu...@gmail.com

unread,
Aug 1, 2006, 9:47:44 PM8/1/06
to ttnn BI 观点(478成员)

我想请问一下CRISP-DM中,对于其各个过程的是否有比较具体的准则(最好是量化指标)定义来判断该过程允许结束,可以进入下一个阶段呢?如Qing所说的Lift>3,我还不明白这是否就是一个"模型评估"的量化指标?看来可以先了解一下CRISP-DM。我个人觉得先从方法论学起,可以了解这些复杂技术、算法的根本目标是什么。一头扎进庞大的数据和技术泥潭,非常容易找不到方向。
happy提到算法方面的情况,倒是在MS
BI都能看到,看来是MS
BI还是提供了比较经典的挖掘算法。我还想请教一下,如果发现目标预测数据随时间成周期性变化(比如以周为单位,波动曲线很相似),可以用算法来形成预测模型?针对连续数据的决策树算法是否可行呢?

peter yu

unread,
Aug 1, 2006, 11:36:07 PM8/1/06
to tt...@googlegroups.com
看你用什么方法,决策树自然很好解释 这也是它的优点
像神经网络方面的 无论是ann svm lssvm都不好解释 甚至可以说无法解释 就像你不能解释人的大脑神经是怎样工作的 人的判断是怎样产生的
模型是建出来的 是验证出来的 不是解释出来的 当然合理的解释也是很重要的~~~~~

 
2006/8/1, Mr.Somebody <Mr.So...@gmail.com>:
对把模型当黑盒子的态度不敢苟同.
数据挖掘的目的并不完全在于最终的模型,还在于建模过程中的知识发现.
一个模型如果是没办法合理解释的话它的用处很有限.我只能说敢不了解模型的解释力而直接套用模型的人要么是很有魄力 (我不知道他的信心是从哪里来的)要么是没有知识.


peter yu

unread,
Aug 1, 2006, 11:41:57 PM8/1/06
to tt...@googlegroups.com
数据清理才是最难的吧 数据清理应该占到建模的70%左右的工作量
建模的工具反而不是那么重要  如果要求不是特别严格 没必要把神经网络之类的高级算法弄上来
无论从稳定性还是鲁棒性都令人头痛

 
2006/8/1, happy <xinin...@prient.com>:

Qing

unread,
Aug 2, 2006, 1:20:55 AM8/2/06
to tt...@googlegroups.com
Somebody先生对将模型当作黑盒子不大认同,我理解这个意思。其实我说的意思是指从职责角度,将建模这个活动当作一个黑盒子,有比较明确的输入、输出,这是一种理想化的的考虑。
 
如果挖掘就是一门高深的、艺术化的工作,是只可意会不可言传的,那整个项目成本必然就很高,对负责此项工作人员技能的依赖就非常高。
 
我相信其实任何事情做成精了,都可以有艺术化的空间。目前这个阶段将要将挖掘应用做好,忽视建模的技术不太现实。
 
拿我们现在的挖掘模型来说,确实在用,甚至真的就是直接套用模型哦。因为我们有lift>3的说服力嘛,通过数据就可以证明模型的好坏,用这种模型给用户打分,输出营销名单等等。这种应用,我们是敢做的。
 
但有些模型确实是需要业务解释,譬如产品关联分析、客户分群。虽然前者有也有lift,置信度等"客观"指标,但因为需要对每条关联规则给出解释,所以,去跟客户说一条看起来似乎毫不相干的规则真的就是有业务意义,就不大自信了。需要更多了解数据和业务,可能是因为前段时间某个特定的营销活动导致了这两个业务相关,或是两个业务本身确实有某种潜在依赖关系的。
 
至于客户分群,更是如此,虽然跟客户吹得天花乱坠,用工具分出若干的群是轻而易举的,将结果解读出来,也非难事。但将分群应用到日常的业务活动中,自信不够。客户提出的很多问题,都是比较难以回答。
 
例如:
为什么要分出10群而不是9群?
为什么要考虑这个变量而没有考虑那个变量?
为什么没有某某群(这个某某群是客户脑海中一种印象,认为应当有的)?

也许回答这些问题并不是太难,只要告诉他,"分群是一种基础性的分析工作,完全从数据出发,应用要提升到一种战略战术层面,不能在执行层面"。就不知道有没有人信,当然这就扯到忽悠技巧上去了,不谈这个。
 
还是来谈谈黑盒子。
 
术业有专攻,那客户分群举例子。将分群建模当作一个黑盒子,由挖掘专家来负责建模,而业务专家指定输入变量。挖掘专家需要做的只是考虑变量的衍生(一些非业务上的衍生),借助建模工具分出符合技术指标的(譬如群间距离、区分度等)的分群结果,输出每个群每个变量的均值,提交给业务专家解读之。
 
显然,此处对于变量的指定,输出数据的规格是事先由挖掘专家和业务专家约定好的。目前此处我觉得是欠缺的,因此,也就没有办法将挖掘建模当作黑盒子。挖掘专家肯定是要充当业务专家的,去理解业务,去选择变量,甚至自己去解读。长期看,这不符合"专攻"路线。
 

Mr.Somebody

unread,
Aug 4, 2006, 7:35:48 AM8/4/06
to ttnn BI 观点(482成员)
先对黑盒子谈谈,还是不同意这个观点,连专攻的观点也不同意.

业务专家和挖掘专家是必须要紧密合作的,特别是业务理解、数据理解和模型解释.这里有一个知识发现,传递,验证,纠正的互动过程.一个挖掘项目,挖掘者必须要在业务人员的帮助下理解业务,在业务人员的帮助下选择变量,在业务人员的帮助下去解读.'由挖掘专家来负责建模,而业务专家指定输入变量'或者是'专攻'的观点则去掉了这些互动的过程,这样很容易导致失败.

同意模型是建出来的 是验证出来的 不是解释出来的...
不过在很多重大决策里可不能随便把模型拿到现实里面验证,仅仅凭LIFT>3太不够说服力了.作为挖掘者我必须要把模型解释给客户听,为什么模型效果会好,还要解释模型怎么反映市场的变化,客户消费心理的趋势等等.模型本身不是知识,对模型的合理解释和通过模型反映出来的市场/客户的特征才是知识.

Zhu Sizheng

unread,
Aug 6, 2006, 9:49:04 PM8/6/06
to tt...@googlegroups.com
不太同意黑盒的说法.
 
对业务专家和挖掘专家是必须紧密合作的.业务专家明白要什么,技术专家明白有什么样的技术可以去满足业务专家的需求.在这样的合作中有一个知识发现,传递,验证,纠正的互动过程.(同意).然而,一个单纯的数据挖掘算法是否能够真正满足业务需求还需要分不同的情况进行讨论,我的整体感觉是单纯的一个挖掘算法是不太能够满足业务需求的,挖掘算法间的融合会是一个趋势.那么在这种情况下,对挖掘专家的要求会是什么?
 
我想对业务的理解应该是对挖掘专家的最急迫的要求吧.在初始阶段,业务专家和挖掘专家必须是相互合作的关系,那么当挖掘专家真正弄清楚了业务的需求,甚至是非常细分的需求之后.那么整个挖掘模型的输入输出对他来说就应该是透明的,而对业务专家而言,这时需要控制的就是验证,控制输出.
 
模型本身不是知识,对模型的合理解释和通过模型反映出来的市场/客户的特征才是知识.站在业务专家和客户角度而言的确如此,但是站在技术人员的角度,我们在进行业务分析之前应该先明白模型本身的功能甚至是模型的整个细节执行过程,对于中间变量的设置.控制应该是技术人员所必须明白的.否则,你怎么对输出做出合理的解释让业务专家去相信你所求出的输出就是他想要的东西?因此,黑盒的与否应该是因人而异,因角色而理解不同吧.
 
那么这样就牵扯出了我们的定位问题,我们是定位于技术专家还是业务专家?技术人员走业务专家的道路应该比业务专家走技术道路简单,这也是很多技术人员最终脱离程序员角色的一条道路....
由此看来业务和技术的融合是已经正在发生的事实,那么是否就意味着专业化分工正在走向弱势?
 
谈到专业化分工这方面的东西,可能又是另外一个话题了吧.在整个软件产业链还不是清晰的当下,是否可以借鉴建筑产业链来类比软件产业?建筑产业中规划院,设计院,施工单位,监理单位,甚至到最后的物业都处处刻画了专业化分工的痕迹,那么软件产业呢?我感觉到从大的格局来讲,专业化分工恰恰才是软件产业的方向,然而对于个人来讲,是专好还是融合好??
 
扯远了.
 
对于CRISP-DM中包括业务理解、数据理解、数据处理、建模、模型评估、模型发布这个六个步骤我个人认为也应该是一个迭带的过程.不过由于没有真正的试验过,因此不便发表什么言论.
 
 
 
On 8/4/06, Mr.Somebody <Mr.So...@gmail.com> wrote:
先对黑盒子谈谈,还是不同意这个观点,连专攻的观点也不同意.

zeus amiao

unread,
Aug 10, 2006, 12:55:34 PM8/10/06
to tt...@googlegroups.com
本来讨论工具的,大家一下子转到方法论上去了。通病啊,哈哈,就虚。方法论大家都可以谈。每个DM工具还是都有特点的,但SAS是最出色的一个,处理数据的能力,分析的能力。但也要考虑的MONEY以及你做事情的需要,再权衡选择。

You ZB

unread,
Aug 17, 2006, 10:19:04 PM8/17/06
to ttnn BI 观点(500成员)
工具是死的,正确的运用工具解决实际问题。以前的人走了很多弯路,其中有些人就把这些弯路总结了一下,这就叫方法论,不是你所讲的"虚"。。。。。

另外,不管从市场份额,还是实际运用来看,都没有任何证据表明在mining这个领域,sas是最出色的,至少也是出色之一。。。

zeus amiao

unread,
Aug 20, 2006, 9:36:15 AM8/20/06
to tt...@googlegroups.com
工具是一回事情,方法论是另一回事情!这个讨论的主题是数据挖掘工具,不知道你有没有看清楚这个题目。方法论的东西,CRISP-DM跟SEMMA基本是类似的,在实际工作中都会用到。我说的虚,是因为有些人对工具还不是了解的情况下,或者说只在厂商的白皮书的情况下,去讨论方法论,这样有一种空中楼阁的味道。
确实,在解决实际工作中,还是人,有经验的人,懂得业务与数据的人。LIDOFF在他的《MASTER DATA MINING》,更强调MINING是一个PROCESS。至于SAS,在实际的数据处理与分析中,是最出色的,我没有说MINING领域,至少我知道FDA只认SAS软件的处理的报告。
 
在您回答这个问题以前,最好能看清楚别人说话要说的含义,否则什么都一塌糊涂的!

You ZB

unread,
Aug 21, 2006, 10:35:29 PM8/21/06
to ttnn BI 观点(504成员)
就算我没看清,你说清楚不就行了么?
大家都只是就问题讨论问题而已,你这么激动干吗?
Reply all
Reply to author
Forward
0 new messages