什么是数据挖掘？分类、聚类和关联规则怎么区分

什么是数据挖掘？数据挖掘指的是从已有数据里找出可复用规律的一整套方法，核心是先把问题归到分类、聚类、关联规则、回归预测这4类任务里的某一类。

很多人把这件事当成「算法越复杂越厉害」，其实真正卡住你的不是模型选型。手上的问题归错了任务类型，后面调参、换工具、加预算全都在错的方向上加码。我在项目里见过的返工，十次有七次是第一步就归错了类。

数据挖掘和统计分析的区别，先看它在这个体系里站哪一格

要把数据挖掘讲清楚，先得看它在体系里站哪一格。它属于数据分析大类下的一个分支，上位概念是「用数据支持判断」，同级还有两个常被混进来的东西：描述统计和商业智能报表。三者用的是同一批数据，出口不同，一条通往解释，一条通往预测。

三者的分工可以用一句话切开。描述统计回答「过去发生了什么」，比如上个月的复购率是31%；商业智能报表回答「现在是多少」，比如今天的库存周转天数；挖掘模型回答「下一个会是谁」，比如哪500个用户下个月最可能离开。

区别不在工具，在输出物的形态。统计分析的输出是一个数、一张分布图；建模的输出是一个可以被新数据反复调用的规则或模型。前者看完就结束，后者每来一批新用户都会重新打分。

这个区别决定了投入方式。做一份月度经营分析，3天能出结果；训练一个流失预警模型，光是数据准备就可能占掉整个项目70%以上的时间。我常跟新同事说，先问自己一句：这次要的是一个答案，还是一条以后能一直用的规则。

图源：《BitTiger数据科学、数据工程、数据分析 知识体系构建和培训实践》（第4页 · 原文）

答案要规则不要，就是两条完全不同的路。答案这条路走报表就够，硬上模型是把小问题做贵；规则这条路只做报表，就是把每次都猜一遍的成本长期挂着。

四类任务怎么分：看标签有无，再看预测的是数值还是类别

数据挖掘的四类任务能分清楚，靠的是两个问题，不是算法名字。第一个问题：手上有没有「已知答案」的历史样本。第二个问题：要预测的东西是一个数，还是一个是非。

按这个顺序走一遍不会错。有答案、预测是非，是分类；有答案、预测是数值，是回归预测；没答案、按相似度分组，是聚类；没答案、看谁总跟谁一起出现，是关联规则。这就是一份可以照着走的判定清单。

依据《中国数据分析行业年度发展报告2025》，数据分析已经覆盖金融、医疗、零售、制造、能源、政务六大场景，全球市场以2025年822亿美元为基准，预计到2032年达到4027亿美元，年复合增长率25.5%。场景铺得越开，先把任务归对类这件事就越省时间。

图源：《中国数据分析行业年度发展报告2025-中国商业联合会数据分析专业委员会》（第6页 · 原文）

四类任务里，只有分类和回归预测是「监督」的——历史数据里带答案，模型照着答案学。聚类和关联规则不带答案，它们是从数据自己身上找结构，这叫无监督。很多人嘴里说的挖掘，其实一大半停在聚类这一步，因为聚类不需要标注，最容易上手，也最容易把结果讲成结论。

我的判断是，运营场景里最常被误用的就是聚类。它给出来的分组没有名字，只有相似度；你不给它贴业务标签，它就只是一个分类结果，不是一条能用的判断。

四类任务不是四个并列的选项，它们有先后。分类和回归要标签，标签得先有人定义；聚类和关联规则不需要标签，可以先跑一版看结构，反过来帮你把标签说清楚。我见过一种更稳的做法：先用聚类把用户分成四群，人工给每群起个名字，再拿「是不是这群人」当分类的学习目标。这条路走得慢，但标签是有业务含义的。

分类与回归预测：有标准答案的那两类，门槛在标签质量

分类任务的前提是标签。你说这个人「流失了」，得有明确的定义：多少天没有下单算流失，退款后算不算，只买一次的算不算。这个定义没写死，模型学出来的就是你那句含糊话。标签定义进不了文档，模型结果就进不了会议室。

分类的输出通常是概率，不是结论。模型告诉你这个用户流失概率是0.62，要不要发券、发多大面额，那是业务侧的动作，不归模型管。我见过最典型的一幕是：模型说0.62，运营直接按0.6以上全发50元券，结果成本翻倍，流失率只降了2个百分点。

回归预测多走一步，预测的是一个连续的数：下个月的订单量、单个用户的次月消费额、一次活动的参与人数。它的误差通常比分类更难解释，因为「差了多少」比「猜对猜错」更容易被追问。回归结果最好配一个区间，只给一个点值，业务方一定会拿它当承诺。

这两类任务共用一个前置环节叫数据准备。源文档里把这块比作「洗菜」——清洗、对齐、去重，然后才谈建模。放到运营的实际里，数据准备就是把订单表、用户表、行为表按同一个用户ID对齐，把重复下单、测试账号、刷单记录先剔干净。

图源：《高阶运营方法论6-数据分析》（第5页 · 原文）

数据准备做得好不好，有一个简单的验收方式：让两个不同的人分别从原始表拉一遍同一批订单，看两个数对不对得上。对不上，说明口径里混着退款、拆单、测试账号这些东西，这时候往下建模，等于把错误放大。我做过一个复购预测，第一版偏差很大，查了半天才发现「用券下单」和「积分兑换」被算成了两次购买。

聚类与关联规则：没有答案的那两类，难点在结果解读

聚类是「物以类聚」的形式化。你把用户的购买频次、平均客单价、最后一次下单距今多少天放进同一个空间，算法会把彼此靠近的归成一组。它不告诉你这组人叫什么，你得自己看：一组是高频高额，一组是三个月没来但历史客单价很高，还有一组只在大促出现。

聚类的组数不是越多越好。分5组和分8组，业务能配上的动作数量差不多，但组一多，每组样本就变少，结论就不稳。我一般按「能配几个动作就分几组」来定，运营手上只有三套话术，就别硬分六群。

运营里有个现成的替代品叫RFM，用最近一次消费、消费频次、消费金额三个维度给用户分层。它其实是聚类的简化版——人先把分组规则定死，算法只负责归档。RFM好用在可解释，差在规则是人拍的，赶上品类特殊就会切错。

关联规则解决的是另一件事：谁和谁总一起出现。经典例子是购物篮里的啤酒和尿布，运营场景里更常见的是「买了A套餐的人80%会加购B配件」。它输出的是规则，每条规则带两个指标：支持度（多少人同时买了这两样）和置信度（买了A的人里有多少买了B）。

类似的活儿我做过不少，最花时间的其实是找齐参考资料。运营动脉把方案、课件、报告按行业分好类了，翻起来不费劲。

图源：《高阶运营方法论6-数据分析》（第2页 · 原文）

规则跑出来一般是一大张表，几十到几百条，别整张表往会上放。筛的时候就三条线：支持度低于5%的先扔掉，置信度低于60%的先扔掉，业务上做不出来的（比如需要拆包装重组的）也扔掉。三条筛完，能用的通常只剩几条。

这两个指标必须一起看。置信度高的规则，支持度常常很低——10个买了A的人里9个买了B，听着厉害，可加起来只有10个人。拿这种规则去定主推套餐，等于为一个小众偏好改了全店结构。

聚类和关联规则还有一个共同点：它们没有「对错」，只有「有没有用」。所以评估方式也不一样，不看准确率，看分组之后能不能对应上具体动作，看规则能不能落到货架、套餐、弹窗上。落不到动作的分组，就是一份好看的名单。

一个项目从头到尾走一遍：CRISP流程里的每一步在做什么

把四类任务串起来的，是一套叫CRISP的流程。不同资料里的叫法略有出入，主干一致：理解业务、理解数据、数据准备、建模、评估、部署。运营侧最容易省掉的，恰恰是第一步和第六步。

理解业务这一步，产出应该是一句能量化的话。不是「降低流失」，而是「把30天未活跃用户里的流失率从18%压到14%，用短信加站内券，两个月内做完」。这句话里带着指标、带着动作、带着时间窗，模型才知道自己该优化什么。

数据准备最耗时，也最容易被当成杂活。材料里有一组分工能说明它为什么慢：一个数据项目里，数据工程师负责整合数据源、建立数据管道和数据仓库，分析师的活是清洗、表层分析和可视化，模型的构建则归数据科学家。这三拨人要是混在一个岗位上，项目通常卡在第二步。

建模和评估是中间的活。模型这一层可以外包，但评估口径不能外包，因为它必须对齐业务方认的那个数。评估不能只看模型自己的指标，要看它跟业务指标对不对得上。分类的准确率是90%，但把最该发的券发给了不会走的人，业务上就是负收益。评估环节要设一条线：模型上线后，哪个数变了才算成功。

部署阶段有一件事常被漏掉：模型怎么进到业务系统里。运营后台要能直接看到这批人的名单，券要能按名单自动发出去，客服手里的工单上要标出这个人属于哪一类。模型跑在别人的电脑上，等于没跑。

图源：《中国数据分析行业年度发展报告2025-中国商业联合会数据分析专业委员会》（第3页 · 原文）

部署之后是持续监控。模型会随时间衰减，用户的购买习惯一季一变，去年训练的流失模型今年可能就把最该挽留的人漏掉了。我一般建议每季度回看一次，重点看漏掉的那批人，比看整体准确率有用得多。

还有一件事要提前定：验收谁签字。模型上线前，业务负责人得先认一个数，比如「30天流失率降到14%以内」。这个数不认，模型跑得再好也只是技术自娱自乐。验收口径写进项目文档，比写在周报里管用。

整个流程走完，你手上留下三样东西：一个定义清楚的标签、一套可复用的特征、一条业务上认账的动作规则。这三样才是项目真正的资产，模型文件反而是最容易替换的那个。

最容易踩的三个坑：边界在哪，什么时候别用它

第一个坑是把聚类当结论。分出来「高价值人群」就宣布要重点运营，可这一组的特征可能只是「客单价高」——而客单价高的人本来就不需要券。没有对照组的结论，不叫结论。

第二个坑是拿它去回答「为什么」。模型能告诉你谁会流失，答不了为什么流失。要回答因果，得改用实验设计：分一半人发券，一半人不发，比一比。这两件事的目标不同，混着做两头都做不好，我见过一个团队为这个问题吵了整整两周。

第三个坑是数据本身不够。样本只有300个用户，硬要训一个带十几个特征的分类模型，结果只能是过拟合——训练集上准确率很高，新用户一来就失灵。这种情况下更实用的做法是先做一次描述统计，把能看出来的差异列成清单，比强行上线一个模型强。

图源：《中国数据分析行业年度发展报告2025-中国商业联合会数据分析专业委员会》（第2页 · 原文）

还有一条边界值得记住：数据挖掘擅长找相关性，不擅长证明因果。它能在你有一批历史数据、有一个明确的动作目标、有一批可以反复使用的新样本时发挥最大作用。三个条件缺两个，就不该启动项目。项目该不该开，先看这三条，不看预算。

回到最开头那句。你手上有问题的时候，先问两句：有没有带答案的历史样本，要预测的是数还是类别。这两句答清楚了，剩下的部分就只是执行。答不清楚，再贵的工具也只是把猜测做得更精致。

你可以拿手上正在跟的一个需求试一遍：把标签定义、预测对象、业务动作三行写出来，写不出来的那一行，就是这次项目最容易返工的地方。写完再决定要不要建模，比先开会定方案省事得多。

图源：《中国数据分析行业年度发展报告2025-中国商业联合会数据分析专业委员会》（第4页 · 原文）

我自己的习惯是，每个挖掘项目立项前先在文档里留一页纸，写清楚这次的判断标准和验收口径，会后抄送给业务方。这一页纸救过我至少两次：一次发现标签定义根本对不上财务口径，一次发现所谓的新模型和现成的RFM分层结论完全一样。

如果这次你手上连一批干净的历史数据都没有，我的建议是先别立项。先把订单、用户、行为三张表按用户ID对齐，对齐之后能看出多少差异，就是你现在能做的上限。这不是从算法开始的项目，是从数据能不能用开始的。

记住一句话就够了：数据挖掘不是找最厉害的算法，是把问题放对那四类里的一个位置。位置对了，模型朴素也能用；位置错了，模型再花哨也交不出动作。

图源：《高阶运营方法论6-数据分析》（第4页 · 原文）