分类算法与关联规则挖掘这组主题，算是数据挖掘里最经典的一对搭档。一个负责预测——拿到一条数据判断它属于哪个类别；一个负责发现——从大量记录中找出频繁出现的组合模式。两者覆盖了从监督学习到无监督挖掘的核心思路，无论做推荐系统、风控模型还是用户行为分析，都绕不开这两个方向。这篇文章是个人从实际项目中整理出来的总结，把算法原理、评估指标、数据预处理、参数调优串在一起，适合正在学习数据挖掘的初学者，也适合刚入行需要快速搭建分析方案的从业者参考。
1. 分类算法的选型逻辑与场景适配
做分类任务的第一步不是调参，而是搞明白拿到的数据长什么样、业务上要解决什么问题。很多人一上来就套XGBoost或深度模型，结果样本量只有几千条，特征维度也不高，反而把简单问题复杂化。分类算法的选择本质上是一个权衡：可解释性、非线性拟合能力、训练效率、对异常值的容忍度。不同场景下，最优解往往不是同一个算法。
1.1 逻辑回归：能解释业务的底线模型
逻辑回归虽然名字里有“回归”，但它解决的是分类问题，核心是借助Sigmoid函数把线性加权输出映射到0到1之间。实际项目中，逻辑回归最大的价值不是精度，而是可解释性。比如信贷风控领域，监管要求必须说明每个用户的拒绝理由，逻辑回归的权重可以直接对应到特征贡献度，这是树模型和神经网络很难替代的。
用逻辑回归需要注意几个细节。特征之间如果相关性太强，会导致权重估计不稳定；所以入模前要做相关性筛选，或者用正则化压一下。L2正则适合大多数场景，L1则可以用来做特征选择。此外，特征标准化对逻辑回归的收敛速度很重要，尤其是用了梯度下降优化时。我习惯先对连续变量做分箱再WOE编码，这样既能捕捉非线性关系，又保持业务可解释性。
1.2 决策树与随机森林：处理非线性关系的实用派
决策树的思路很直观：按特征做一系列条件判断，把样本不断划分到纯度更高的子集中。它的优点是几乎不需要特征预处理，数值型和分类型都能直接处理，对缺失值也有应对策略。缺点是单棵树极易过拟合，深度稍微大一点，训练集上准确率接近100%，测试集却惨不忍睹。
随机森林通过两个层面的随机性缓解过拟合：每棵树随机抽取样本（有放回抽样），每次分裂随机选择特征子集。实际使用中，有两个参数最值得下功夫：一是树的数量n_estimators，不是越大越好，超过某个阈值后收益递减，且内存开销增加；二是max_features，分类任务一般取特征总数的平方根左右。随机森林还能输出特征重要性，虽然这个重要性存在偏好（数值型高基数特征容易被高估），但用来做粗筛是足够的。
1.3 KNN与朴素贝叶斯：简单假设下的可用方案
KNN不训练模型，而是把训练集记住，预测时找最近的K个样本投票。它的关键是距离度量方式和特征缩放。如果特征之间量纲差异大，比如一个特征范围是0到1，另一个是0到10000，不做标准化的话，距离计算基本被量纲大的特征主导，模型等于废了。
朴素贝叶斯基于“特征独立”假设，这个假设在真实数据里几乎不成立，但它依然能打，尤其在文本分类场景。因为文本特征经过TF-IDF处理后，独立性假设带来的偏差在工程上是可以接受的，而且它训练极快、需要样本量少。垃圾邮件过滤、情感分类这些场景，朴素贝叶斯仍然是很靠谱的基线方案。
1.4 SVM与梯度提升树：从边界划分到集成优势
SVM的核心是找一个最大间隔超平面来分隔类别，通过核函数把低维不可分的数据映射到高维空间。它适合小样本、高维特征的数据集，但对参数敏感，核函数的选择（线性核、RBF核）会影响结果，且在大规模数据上训练速度慢。
梯度提升树（GBDT、XGBoost、LightGBM）是当前表格数据分类任务的主流选择。它通过串行训练多个弱学习器，每棵树拟合前一棵树的残差。相比随机森林的并行思想，GBDT能把重点放在难分类的样本上。实际操作中，LightGBM的直方图算法大幅提升了训练速度，特征维度高、样本量大的场景下推荐优先尝试。调参时重点关注学习率、树深度、叶子节点数这三个核心参数，其中学习率调低一点通常能带来稳定的精度提升。
2. 模型评估指标：别被准确率骗了
很多新手在分类任务上只看准确率，这在类别均衡的数据集上问题不大，但一旦遇到不平衡数据——比如欺诈检测中正常样本占99.9%、欺诈样本占0.1%——准确率就变成一个极具误导性的指标。哪怕模型把所有样本都预测为正常，准确率也能达到99.9%，但这个模型毫无价值。理解评估指标的含义和适用场景，是建模流程中和调参同等重要的一环。
2.1 混淆矩阵是一切的基础
先分清四个基本概念：TP（真正例）是实际为正且预测为正，FP（假正例）是实际为负但预测为正，FN（假负例）是实际为正但预测为负，TN（真负例）是实际为负且预测为负。由此衍生出精确率（Precision）= TP/(TP+FP)，它回答的是“预测为正的样本中有多少是真阳性”；召回率（Recall）= TP/(TP+FN)，回答的是“所有真实阳性中有多少被找出来了”。精确率和召回率就像跷跷板的两端，侧重哪一个取决于业务场景。
2.2 F1值与业务阈值的联调
F1值是精确率和召回率的调和平均，用来在两者之间取得平衡。但F1值不是万能标准。实际项目中，阈值是动态可调的——模型输出的概率默认以0.5为分类边界，但你完全可以降到0.3来提高召回率，或者升到0.7来提升精确率。业务场景不同，最优阈值也不同。比如一个营销响应模型，误发给用户一条推荐消息的代价很低，漏掉一个潜在客户的代价反而更高，这时阈值应该下调，牺牲一点精确率来换召回率。
2.3 AUC的意义与局限
ROC曲线以假正例率（FPR）为横轴、真正例率（TPR）为纵轴，AUC是曲线下的面积。AUC的含义是：随机取一个正样本和一个负样本，模型把正样本排在负样本前面的概率。它的好处是不依赖于具体阈值，只衡量模型的排序能力。但AUC也有局限——它关注的是全局排序，如果业务只在某个概率区间内操作，AUC可能高但实际效果不佳。比如我只关心预测概率在前5%的用户，AUC的提升不一定反映这部分人群的排序变好了，这时候应该看P-R曲线或者前几%样本的精确率。
2.4 交叉验证与过拟合的对抗
评估指标的可靠性离不开验证方式的支撑。常见的做法是K折交叉验证，把数据分成K份，轮流用K-1份训练、剩下1份验证，最终取K轮结果的平均。实际使用中，5折或10折比较常用。但要注意：交叉验证计算的是模型在随机切分数据上的表现，如果数据存在时间顺序——比如用过去半年预测未来一个月，随机切分会造成信息泄露，必须用时间序列切分的方式。另一个容易踩坑的地方是数据预处理要在每一折内部独立进行，如果先对整个训练集做标准化再切分，验证结果会虚高。
提示：在模型评估时不要反复使用同一份测试集做调参。调参本质上是拿测试集的信息反向指导模型，多次操作后测试集等于变相参与了训练。稳妥做法是划分训练集、验证集、测试集三份，或用嵌套交叉验证来评估调参流程本身的可靠性。
3. 数据预处理与不平衡样本的关键处理
数据质量决定了模型的上限，算法只是在逼近这个上限。同一个算法，在原始数据上一顿跑和在预处理后的数据上喂进去，效果可能是天壤之别。这一节聊几个在分类任务里最常见的数据问题：缺失值、异常值、类别不平衡、特征分布偏斜。
3.1 缺失值与异常值处理的原则
缺失值处理不是简单地填均值或删除。要区分缺失机制：完全随机缺失可以直接删除或填充；与标签相关的缺失得小心，比如高收入人群可能倾向于不填收入字段，直接删除会造成样本偏差。实际经验是，对于树模型，缺失值可以保留，让模型在分裂时自动选择缺失方向的增益；对线性模型和SVM，填充策略尽量简单，中位数比均值稳健，类别型变量用众数填充，或者新增一个“是否缺失”的标记列。
异常值方面，分类型模型对异常值的敏感度比回归模型低，但极端的离群点可能影响特征缩放、影响线性模型的决策边界。处理思路是先把明显异常的数据清洗掉——比如用IQR方法标记出超过上四分位+1.5倍IQR的样本——然后再视情况决定是剔除还是做截尾处理。我一般会先做一轮描述统计，绘制箱线图和数据分布图，确认异常值不是正常业务形态（比如真实存在的高端消费金额）后，再做处理。
3.2 类别不平衡：从重采样到代价敏感学习
类别不平衡是分类任务里绕不开的顽症。处理策略大致分为三类：数据层面、算法层面、评估层面。数据层面的常用手段是过采样和欠采样。欠采样删除多数类样本，但会丢失信息，适合多数类样本量很大的情况；过采样复制少数类样本容易过拟合，更推荐SMOTE这类合成采样方法，它通过在少数类样本之间插值生成新样本。
算法层面的手段是调整类别权重。在逻辑回归和SVM中，代价敏感学习可以直接给少数类的错误分类更高的惩罚系数；在决策树系模型中，可以通过class_weight参数设置权重。这两者结合起来往往比单纯重采样效果更稳定。评估层面则是前面说的，使用精确率召回率、PR曲线这类对不平衡更敏感的指标。
3.3 特征编码与缺失量级对模型结果的影响
类别特征编码是容易出错的地方。LabelEncoder给类别打上0、1、2的标签，会引入不存在的顺序关系，对线性模型不友好；对于无序类别，用One-Hot编码更合适；但高基数的类别特征（比如用户ID、城市代码）用One-Hot会产生大量稀疏列，这时要么做目标编码（用目标变量均值编码），要么先做频次分箱再编码。目标编码容易过拟合，需要用交叉验证来防止标签信息泄露。
特征缩放方面，标准化的目的是把特征调整到相似的量纲范围，这对基于距离和梯度下降的算法影响巨大。对树模型则基本没影响，因为它们的分裂依据是阈值比较而非距离计算，并不需要做标准化。
4. 频繁模式与关联规则挖掘的核心原理与实操
关联规则挖掘的任务是找“什么和什么经常一起出现”。不管你听没听说过Apriori算法，购物篮分析这个概念应该不陌生——超市收银台的数据里藏着“买啤酒的人同时也会买尿布”这类模式。识别这类共现关系对商品推荐、捆绑销售、用户行为路径分析都非常有价值。
4.1 支持度、置信度与提升度，三维度拆解一个关联规则
规则的形式是X → Y，表示在包含X的交易中也倾向包含Y。评估规则好不好，三个指标缺一不可。支持度（Support）表示包含X和Y的交易占总交易的比例，支持度太低，说明这个规则涉及的样本太少，统计意义存疑。置信度（Confidence）表示包含X的交易里有多大比例也包含Y，度量的是规则的条件概率。但置信度高不等于规则有效，举个例子：啤酒的支持度本身就很高，哪怕和尿布没有真实关联，“啤酒→尿布”的置信度也可能很高。这时候就需要提升度（Lift）出场，它衡量包含X是否提升了Y出现的概率，计算方式是置信度除以Y的支持度。提升度大于1才说明X对Y有正向促动作用，等于1说明相互独立，小于1则是抑制关系。
注意：支持度过滤虽然能剔除低频项集，但也会误伤低频高价值模式。比如某些小众高端商品的购买频次很低，可是它和特定配件的关联极强，支持度阈值稍高就直接被砍掉了。实际项目里，支持度阈值要结合业务数据量级反复调，不宜一刀切。
4.2 Apriori算法拆解：候选生成与剪枝
Apriori是关联规则挖掘的奠基算法，思路分两步：第一步找频繁项集，第二步由频繁项集生成规则。频繁项集的判断依据就是支持度不低于最小支持度阈值。
找频繁项集的过程是迭代的。先扫描数据集，统计每个单项出现次数，筛掉低于最小支持度的单项；然后用频繁1项集两两组合生成候选2项集，再扫描数据计支持度，筛掉不合格的；再三三组合生成候选3项集……直到不能再生成更长的频繁项集。这里有个核心性质叫先验性质（Apriori性质）：如果某个项集是频繁的，那么它的所有非空子集一定也是频繁的；反过来，如果某项集不频繁，它的任何超集都不可能是频繁的。根据这条性质，在生成候选项集时可以直接剪枝——如果一个候选项集存在不频繁的子集，就不需要再计算它的支持度了。
这段逻辑用生活类比的话，有点像筛选“最佳组合搭档”：你先看哪些单品卖得好，卖得不好的单品直接丢掉，不带它玩；然后用卖得好的单品去组合，组合后还卖得好的留下，卖得不好的组合里的单品再拆散，和别的单品重新组队尝试。Apriori的这个剪枝流程能大幅减少候选集数量，但在项集很长的场景下，反复扫描数据库的开销还是很大。
4.3 FP-Growth算法：从候选生成到模式树生长的效率革命
FP-Growth是对Apriori的大改良，核心思路是省去候选集生成的过程，用两次扫描构建一棵FP树（频繁模式树），把数据库压缩到内存中，再在这棵树上挖掘频繁项集。
第一步扫描数据库计算每个项的频次，过滤掉低于支持度的项；第二步扫描数据库按支持度降序排列每笔交易中的项，然后逐条插入FP树，相同前缀的项共享节点路径，同时维护每个节点的计数。挖掘阶段从支持度最低的频繁项开始，找出该节点的所有条件模式基（即以该项为后缀的所有路径），基于条件模式基构建条件FP树，再递归挖掘。
实操中，FP-Growth对内存的占用和数据结构设计要求较高，但速度优势明显。对于包含大量长事务的数据集，FP-Growth的性能往往比Apriori高一个量级。不过Apriori实现简单、易理解，适合数据量小或教学场景；工业级应用基本都倾向FP-Growth或者它的变体。
4.4 关联规则生成与最小阈值设定的经验值
频繁项集确定后，生成规则的过程相对简单：对每个频繁项集，枚举其所有非空子集作为前件，其余部分作为后件，计算置信度并和最小置信度阈值比较，筛掉置信度不足的规则。
阈值设定是理论之外最考验经验的环节。最小支持度设太高，挖掘不到规则；设太低，候选集爆炸，输出一堆低质量的规则。一个小技巧是先看数据规模，交易记录几万条级别的，支持度从1%起步逐步调整；百万级以上的，0.1%可能都偏高。最小置信度则结合业务考虑，比如推荐场景需要的置信度至少要比基准转化率高，否则这个推荐没有增益价值。提升度筛选也值得重视，很多实践里会直接要求提升度大于等于2才纳入业务规则。
5. 关联规则与分类模型的业务联动设计
把分类模型和关联规则拆开看，各自解决不同问题，但真实业务往往是嵌套使用的。以一个电商平台的实际项目为例，可以清楚看到两类方法是如何配合的——这也是数据挖掘项目里最有参考价值的部分。
5.1 购物篮分析与商品捆绑策略的落地
购物篮分析的目标很简单：找出经常一起购买的商品组合，然后决定怎么陈列、怎么捆绑、怎么推送。先用不高于1%的支持度跑一遍关联规则，筛出置信度高且提升度大于1.5的规则，再按提升度排序取前N条规则进入人工审核。
这里有个容易踩的坑：直接对全量订单做关联挖掘，会把热门单品组合推上来，比如手机和手机壳，这种组合业务上显然无效。实际操作中，我会先按品类去重，不考虑同品类多次购买，同时对大促囤货的异常订单做剔除，再按不同用户群体分段做关联分析，新客和老客的关联模式差别很大，合并在一起会互相干扰。经过这些处理后产出的商品组合才能实际派发到推荐系统侧，做捆绑促销试验。
5.2 分类用户价值与关联偏好，双引擎推荐策略
分类模型负责圈定人，关联规则负责决定推荐什么。总体思路是这样：先构建用户特征，用逻辑回归或梯度提升树对用户做分群或价值预测，识别出哪些是高质量用户、哪些是高流失风险用户、哪些是最容易接受推荐的新用户；然后针对不同用户群分别做关联规则挖掘，产生差异化的商品组合推荐。
举个具体的例子，一个做内容社区的平台，用分类模型预测用户的付费意愿，按预测概率把用户划分为高、中、低三档；对高付费意愿用户，用他们近一个月的浏览行为做关联规则挖掘，找出内容倾向与付费产品的关联，比如“浏览了Running类内容的人，大概率会看运动补给类内容”；低付费意愿用户则推轻量级内容。这个链路把预测和规则挖掘串成了整体，比单纯依赖协同过滤或者规则引擎都更能解释推荐逻辑。
5.3 风控场景中分类与规则引擎的协同机制
在风控场景中，分类模型预测欺诈概率，关联规则负责兜底识别已知的犯罪模式。分类模型输出了一个风险概率，阈值以上直接拒绝，阈值以下的通过，但这里有个问题：某些欺诈模式在数据中非常稀少，分类模型学不到这种特征组合，概率打分可能低于阈值。
解决思路是把历史已确认的欺诈行为做关联规则挖掘，找出欺诈案件中频繁出现的特征组合模式——比如同一设备短时间内关联多个不同收货地址、同收货地址下绑定了多张不活跃银行卡——把这些规则固化下来，作为硬规则叠加在模型概率之上。只要命中硬规则，无论模型预测概率多低都直接转人工审核。这种方式能有效补充模型在冷启动场景下的不足，提高风险识别的覆盖面。
6. 实战中的常见问题与调优思路整理
算法和原理落地的过程中，会遇到各种不写在教科书里的问题。这一节把我在多个项目中遇到的高频问题整理出来，每条都附带具体的排查思路和解决建议，可以作为快速定位问题时的手册使用。
6.1 分类模型效果不好时先排查什么
分类模型在测试集上表现差，很多人第一反应是换更强的模型，但其实大概率是数据管线或者评估方式出问题。第一步做的是检查训练集和验证集的数据分布，用均值、方差、分位数对比一下关键特征，如果分布差异明显，大概率是数据划分出了问题，比如不同时间段的样本混在一起。第二步检查标签是否有噪声，特别是人工标注的数据集，标注错误率超过5%就会明显拖累模型效果。第三步看特征的预测能力，可以单跑一个简单模型，看训练集和测试集的效果gap，如果训练集很好但测试集很差，大概率过拟合了。
注意：遇到效果差时，先停掉调参的手，花时间做数据探查。实际经验是，10次效果不佳中有6到7次是数据问题，真正需要更换算法的场景其实不算多。做数据检查时，重点看缺失值比例异常的特征、覆盖面很小的编码类别、和标签高度相关的泄露特征，这三类问题最容易潜伏。
6.2 关联规则输出质量差的三种常见情况
关联规则输出一长串垃圾规则，是新手最容易遇到的挫败场景。第一种情况是支持度阈值设太低，生成了大量基于随机共现的弱规则，解决办法是提高支持度门槛或增加最小提升度约束。第二种情况是数据中存在大量高频项，比如某个引流商品的购买率占全店的40%，几乎所有规则都包含这个单品，淹没了有意义的低频关联，解决办法是把这个高频项剔除后再挖掘，或者按商品类目分组建模。第三种情况是置信度合格但提升度接近1甚至小于1，说明规则没有实际增益，此时要优先关注提升度指标的排序。
6.3 类别不平衡与调参过拟合的组合对策
类别不平衡和过拟合常常同时出现，原因是少数类样本太少，模型会走捷径——把所有样本预测为多数类，或者为少数类过度拟合细节噪声。两种做法叠加使用效果更好：在训练阶段用SMOTE或类别权重让模型见得到少数类样本；在调参阶段严格控制模型复杂度，比如限制决策树深度、提高随机森林的特征子采样比例、加大正则化系数。我的一个经验是，先用类别权重跑一版基线，再评估是否需要过采样。簇状数据（少数类样本天然分成几个子群）用SMOTE容易产生不合理样本，这时更推荐用类别权重或专门针对局部特征的合成方法。
6.4 时间序列数据与普通表格数据处理方式的差异
如果数据是时间序列形态的，比如按天记录的用户行为日志、按周统计的销量数据，处理方式就和普通表格数据明显不同。第一，划分数据集不能随机切，要按照时间顺序划分，保证测试集全部晚于训练集的时间点，否则模型会被未来信息污染。第二，窗口特征设计很重要，比如用最近7天、30天的滑动窗口计算均值、最大值、趋势斜率，这比直接输入原始时间戳更有效。第三，要注意概念漂移问题，用户行为和业务规律随时间变化，今天训练好的模型，三个月后可能就不太适用了，需要定期重训或做增量更新。
注意：在时间序列场景下，交叉验证的方式也要调整为滚动时间窗口形式，比如用1到3月的数据训练预测4月，再用2到4月训练预测5月。传统的K折随机交叉验证在这里会高估模型效果，而且这种高估往往非常严重。
7. 从原理到落地的数据挖掘项目总结与避坑清单
分类算法和关联规则挖掘看起来是两个方向，但实际项目中经常配合使用。分类模型帮我们做预测和分群，关联规则帮我们发现事物间的组合规律，两者的数据处理流程、评估思路、调参路径都有相通之处。这一节我用个人实操过的完整项目流程来做一次串联复盘，梳理出从拿到数据到最终上线的完整路径，同时把那些贯穿始终的坑标记出来。
7.1 完整项目流程的六步串联
第一步是业务理解和目标拆解，把模糊的需求（“提升转化率”“找到关联商品”）翻译成明确的数据挖掘任务：二分类预测还是频繁模式挖掘。第二步是数据采集和探查，做缺失率、基数、分布、相关性的全面体检，这个阶段不写模型，只写数据探查代码，产出包含字段说明、数据质量报告、分布图表的探查文档。第三步是数据清洗与特征工程，解决缺失值、异常值、编码问题，构造窗口聚合特征、目标编码特征等。第四步是模型训练与评估，用交叉验证测基线，逐步调参优化，用评估指标+业务场景校准最优阈值。第五步是关联规则挖掘，在清洗后的数据集上做项集挖掘，配合业务规则筛选出可用规则。第六步是上线部署与监控，把模型封装成服务，设置预测和规则命中的监控面板，定期观察效果指标。
7.2 避坑清单与实操经验总结
罗列几条最值得记住的经验，大小项目里都可能用得上。
强调数据泄露问题。特征工程阶段如果用了全局统计量（比如整个数据集的均值），在训练和验证之间会造成信息泄露，正确做法是在每个交叉验证折内单独计算统计量。这属于最容易踩且最难排查的坑，排查时可以用特征重要性和时间切分验证来找，尤其要警惕那些重要性高到离谱的特征，基本是泄露了。
强调代码工程层面的规范。要先固化数据划分逻辑，用固定随机种子，别每次运行都重新随机切分，否则模型效果无法复现，调参判断也无从谈起；再固化特征处理逻辑，训练、验证、线上推理的特征处理函数保持一致，验证阶段做过几次特征变换，线上也要原样执行，任何一步不一致都会导致线上效果崩盘。
再强调一点业务指标的导向作用。技术指标（准确率、AUC、支持度、置信度）最终要翻译回业务语言。一个分类模型AUC提升0.01第几，如果业务侧的转化率没有实质性变化，意义有限。关联规则提升度再高，如果没有供应链配对或选品空间，也无法落地。建模的时候保持和业务方对齐，甚至可以用业务方给出的可接受代价来反推阈值参数，这样产出的模型和规则使用率会高出很多。
7.3 工具选型与算力资源配置参考
工具方面，做分类任务和数据处理我最常用的组合是Pandas加Scikit-learn，表格数据用LightGBM和XGBoost，特征工程复杂、容易写出样板代码的项目会配合Featuretools一类的自动化特征工具。关联规则挖掘用Python的mlxtend库就足够了，它实现了Apriori和FP-Growth算法，接口简洁。大规模数据的关联分析可以考虑Spark MLlib的FP-Growth实现，但数据量没有到达百万级交易量时，单机处理就够了，没必要引入分布式开销。
算力配置上，表格类数据的分类模型，哪怕是几十万样本、几百个特征，单机16GB内存的笔记本跑XGBoost或者LightGBM也够用。深度学习模型如果不做图像和文本，表格数据用深度网络的优势不明显，还会引入调参成本和算力门槛，这个鲜明的对比用在实际选型上很管用。
8. 后续可以继续深入的方向
两个主题延展出去，还有很多值得探索的方向。分类任务可以对标更前沿的AutoML框架，让特征工程、模型选型、超参优化自动化；也可以对比Stacking集成学习的效果差异，用多个模型的预测结果作为新特征再跑一层；还可以研究机器学习可解释性工具SHAP，让黑盒模型的决策过程可视化。关联规则挖掘可以延伸到序列模式挖掘，处理有时间先后顺序的事件序列——用户的App操作路径、网页点击序列都属于这类场景，和普通购物篮分析有本质差异。多模态场景下，文本和图像数据的特征组合也不适合直接套用传统的关联挖掘思路。
不过，无论选择哪个方向深入，数据挖掘的核心能力定位没有变化：把业务问题翻译成数学问题，用数据驱动的方式给出决策支持。分类和关联规则这两块，是最值得花时间把地基夯实的部分。
