我以前做过一个交易平台的风控项目，一个在全年流水几十亿的盘子里，用数据挖掘给运营和风控团队划出高风险用户名单。那段经历让我意识到一件事：很多人学了一堆算法和工具，但真正把数据挖掘落到“风险管理”这个场景里时，踩的坑远比想象中多。数据挖掘在大数据领域的风险管理应用，不是一个炫技的算法show，而是从数据接入、清洗、特征工程、建模到上线监控的一整条链路。这篇内容我会完整复盘一下我的实操路径、工具选型逻辑和踩坑经验，希望能给正在做类似项目，或者准备往风控、反欺诈方向走的同学一些参考。
1. 项目整体设计：风险管理的需求如何翻译成数据挖掘问题
1.1 风险管理的本质与数据挖掘的切入点
风险管理这件事，拆到底就是四个字：不确定性。金融信贷里要回答“这个客户会不会逾期”，反欺诈里要回答“这笔交易是不是盗刷”，经营分析里要回答“这家企业未来三个月会不会倒闭”。所有问题共同指向一个核心：在事件发生之前给出概率判断。
传统做法是规则引擎。比如银行信用卡中心以前干的事就是定一堆硬规则：超过50万的转账人工审核，年龄小于20岁不批大额，黑名单命中直接拒绝。规则的优势是简单透明，可控性强，但劣势也很明显——规则之间相互冲突时很难权衡，欺诈团伙换个马甲就能绕过规则，而且规则覆盖率永远跟不上新攻击手法。
数据挖掘切入的时候，是换了一套完全不同的思路：不是人去定义什么特征组合意味着风险，而是让算法从大量历史数据里自动发现高风险模式。具体到项目里，就是三个子问题：
- 分类问题：一笔交易、一个用户、一家企业，预测其是好是坏。
- 排序问题：所有风险事件按概率从高到低排队，资源优先分配给头部。
- 回归问题：预测坏账率、损失金额这类连续指标，用于定价和计提。
你去看那些成熟的互联网信贷系统，用户进件后秒级返回额度，背后不是一套规则，而是几十个模型并行：反欺诈模型、信用评分模型、收入稳定性模型、还款意愿模型。数据挖掘在这里解决的，是规则引擎永远做不了的“模糊判断”。
1.2 数据挖掘在风险管理中的典型应用场景
结合我实际接触过的项目，数据挖掘在风险管理里主要分布在五个方向：
| 应用场景 | 解决什么问题 | 典型输入数据 | 常用算法 |
|---|---|---|---|
| 信用评估 | 判断借款人是否会逾期 | 身份信息、收入流水、征信记录 | LR、XGBoost、LightGBM |
| 反欺诈 | 识别盗刷、虚假申请、团伙欺诈 | 交易流水、设备指纹、行为序列 | 孤立森林、GNN、异常检测 |
| 贷中监控 | 发现借款人风险恶化 | 用款行为、多头借贷、消费变化 | 时序模型、XGBoost |
| 催收管理 | 预测回款概率辅助催收策略 | 历史催收记录、联系人信息 | 排序模型、LR |
| 合规审计 | 识别可疑交易、关联交易 | 资金流水、股权关系链 | 社区发现、规则+模型 |
信用评分卡是数据挖掘在风控里最成熟的落地场景。一个标准的评分卡项目，输入是客户申请时填的资料、第三方数据源拉取的征信字段，输出是0到100分的分值，对应违约概率。但评分卡有它自己的讲究——不光要准，还要可解释，所以业界至今还在大量使用逻辑回归，用WOE编码把连续变量变成分箱后的离散变量，保证每个变量的系数都可以向监管解释。
反欺诈则是另一个极端：解释性没那么高要求，但时效性要求极高。用户刚提交一笔交易，几百毫秒内得返回风险评分。这种场景下XGBoost、随机森林、甚至深度学习都可以上，特征多为行为序列、设备指纹、IP归属地，拼的是召回率。
1.3 大数据让数据挖掘从“实验”变成“生产”
我见过很多人写论文、做比赛，数据挖掘跑得飞起，但一上生产就瘫了。主要原因不是算法不行，而是数据量和时效性撑不住。
比如信用卡反欺诈模型，训练数据往往是过去三到五年的全量交易流水，单月数据量就能到几十亿条，单机Pandas根本加载不了。这时候就需要大数据技术栈来承接：
- 数据采集层：Kafka、Flume接入实时交易流和日志流。
- 存储层：HDFS建立数据湖，Hive构建数仓分层（ODS、DWD、DWS、ADS）。
- 计算层：Spark做大规模数据清洗和特征工程，MapReduce承担极大批量离线任务。
- 应用层：模型服务接口、风控引擎、可视化大屏。
关于大数据架构本身，大家去看招聘JD，十条里八条会写“Hadoop四层架构”，实际指的就是上面这套逻辑。很多毕业设计题目比如“校园大数据—数据清洗”“网约车大数据综合项目——基于Spark的数据清洗”，本质都是在让你把这几个层次的链路跑通。
数据挖掘在风险管理里的完整路径，必须构建在这样一套大数据的底座上，否则你做的只是玩具项目。我曾经给一个中小型P2P平台做过贷后催收模型，他们数据量很小，单机完全能跑，但等到数据量增长到千万级，模型训练一次要好几个小时，单机方案彻底废掉，最后不得不全部迁移到Spark上重新做特征管道。
2. 核心细节解析与实操要点
2.1 数据挖掘在风控场景的完整链路设计
一个生产级的风控数据挖掘项目，链路基本上可以拆成这样：
数据接入 -> 数据探查 -> 数据清洗 -> 特征工程 -> 样本设计 -> 模型训练 -> 模型评估 -> 模型上线 -> 模型监控
每一步都有坑。我把它拆细一点。
数据接入阶段最容易被低估。前端给你一份Excel，里面混杂着文本数字、百分号数字、科学计数法，这简直就是家常便饭。数据接入如果做得不仔细，后面所有环节都是“屎上雕花”。我的习惯是：接入后先写一份简单的数据字典，标注字段含义、类型、取值分布、业务口径，这一步至少节省后面三天时间。
数据探查的核心是回答三个问题：数据全不全、数据脏不脏、数据有没有明显的长尾。一个偶然的机会我拿到过一个千万级的用户行为数据集，里面光user_id就有17%是空值，设备型号字段有上百个不同的“未知”—包括“未知”、“未知设备”、“未知机型”、“unknown”等等。这就是典型的脏数据，不探查清楚，特征工程没法做。
特征工程是整个流程里最耗时间的环节，业界公认占项目60%以上的工作量。风控特征不是随便把原始字段扔进模型就完事，而是要基于业务理解做加工：比率特征、时间窗统计特征、序列特征、交叉特征。
2.2 为什么选这几种算法：算法选型的取舍逻辑
每次做风控项目，总有人问：XGBoost和随机森林哪个更好？深度学习能不能用？我的回答永远是：先看场景需求，再谈算法选型。
如果是信用评分，需要向监管和客户解释为什么拒绝贷款，那就别用黑盒模型，逻辑回归最稳。虽然LR精度上限低一些，但是配合WOE编码和分箱之后，特征对风险的影响方向、力度都非常清晰。
如果是反欺诈，场景是毫秒级响应、允许一定误杀、追求高召回，那XGBoost、LightGBM这类GBDT模型是性价比之王。它们对离散特征和连续特征的适配都很好，不需要做太复杂的标准化，而且在特征维度上百、样本上百万的情况下训练速度也扛得住。
至于深度学习，在风控领域主要用在文本、时序和图上：用户行为序列用LSTM，设备关系网用GNN。但DL对样本量的要求高，在小样本的风控场景里反而容易过拟合，实际工程里很少一上来就用。
还有一个经常被忽略的模型排序问题。在很多业务场景里，我们做分类只是为了先圈一个池子，真正需要的是所有候选用户的风险排序。这时候可以先用一个召回模型粗筛，再用精排模型打分排顺序，这套思路和推荐系统的粗排精排是一模一样的。
2.3 大数据的存储和计算在风险项目里怎么选型
风险类项目通常涉及的数据有三大类：交易流水、用户画像、行为日志。这三类数据的特点完全不同，选型思路也不一样。
| 数据类型 | 数据特点 | 推荐存储/计算方案 |
|---|---|---|
| 交易流水 | 条数极多、追加为主、极少修改 | Hive/Parquet列式存储，Spark批处理 |
| 用户画像 | 维度宽、更新频率适中 | HBase或ClickHouse，按主键查询 |
| 行为日志 | 半结构化、量大、时效性要求高 | Kafka接实时，Flink做实时特征，落HDFS离线分析 |
关于集群部署策略，我看过不少团队一上来就想上实时计算，结果把Flink集群搭起来了，业务量根本撑不满，维护成本倒是翻了好几倍。我个人的建议是：先离线，再准实时，最后才实时。大部分风控场景，T+1的离线特征已经能覆盖80%需求，实时只用来处理极高风险事件。
我还见过一些毕业设计是“大数据集群部署策略”方向的，实际就是单机版Hadoop模拟集群+NameNode/DataNode配置调优。那是学习路径，和生产环境选型不是一个概念。生产环境重点要考虑的是数据量级、计算资源成本、任务调度周期这几个维度，而不是单纯追求组件多。
2.4 数据清洗与预处理：风控数据里最常见的坑
数据清洗这件事，表面看是脏活累活，实际上直接决定模型上限。风控数据里最常见的几类问题：
缺失值。用户性别缺失、收入缺失、设备型号缺失。处理方式不是简单填均值或删除，而是要根据业务含义来。风控里缺失本身往往就是信息——一个用户不填收入，可能暗示收入不稳定。所以在风控特征工程里，专门会构造一个“是否缺失”的布尔特征，把缺失当成一种状态。
异常值。交易金额出现负值、年龄出现几百岁、身份证号位数不对……这些要么是录入错误，要么是欺诈信号。异常值处理用3σ法则还是IQR法则要看分布，我项目里经常是人工设定业务上限。
重复值。同一个用户重复出现在两个数据表里但user_id不一致，或者同一笔交易被记录了两次。这类问题不解决，后面特征统计会翻倍出错。
还有一种是风控场景特有的坑：时间穿越。训练数据里如果混入了未来信息，模型上线以后效果会直接崩塌。比如你用客户“逾期后收到的催收电话记录”作为特征去预测是否逾期，这个特征在当时根本不存在，这就是典型的特征泄漏。
预处理阶段的代码我偏用pandas处理，数据量大时换PySpark DataFrame。一个常用的数据清洗函数大概长这样：
import pandas as pd import numpy as np def clean_risk_data(df, numeric_cols, category_cols): df = df.copy() # 数字列清洗：去除货币符号、百分号，统一为float for col in numeric_cols: if df[col].dtype == object: df[col] = df[col].str.replace('¥', '').str.replace(',', '').str.replace('%', '') df[col] = pd.to_numeric(df[col], errors='coerce') # 类别列：统一空字符串和'未知'为固定的缺失标记 for col in category_cols: df[col] = df[col].fillna('UNKNOWN') df[col] = df[col].replace(['', 'NULL', 'null', 'nan'], 'UNKNOWN') # 标记缺失 for col in numeric_cols: df[col + '_is_missing'] = df[col].isnull().astype(int) return df2.5 特征工程在风控里的具体战术：时间窗口、比率、分箱
风控特征工程有几个屡试不爽的套路，我每次做项目都会先铺一遍。
时间窗口统计特征。核心思想是把某个时间长度内的行为聚合成统计量。比如过去30天消费总额、过去7天消费次数、过去90天最大单笔金额、过去一年逾期次数。时间窗口不是越大越好，因为用户的近况比历史状况更能反映当前风险，所以业界常用的是多窗口并行（7天/30天/90天）然后让模型自己去选权重。
比率特征。把绝对量变成相对量，消除量纲影响。比如信用卡使用率（已用额度/总额度）、夜间交易占比、大额交易占比、逾期金额占总负债比例。这类特征在风控模型里往往比原始绝对量更有效，因为比率特征天然包含了用户的“度”信息。
分箱和WOE编码。对连续变量，比如年龄、收入、额度，先进行分段（分箱），然后计算每个箱子的坏样本率，用WOE（Weight of Evidence）替代原始值。逻辑回归用WOE编码是标准动作，好处是让特征和目标变量之间保持单调关系，而且变量尺度一致，可以直接比较系数大小。
时序序列特征。拿下单行为举例：用户过去30天下单时间间隔的平均值和标准差，直接被用来判定是否为机器行为。标准差极小的用户群，大概率是脚本在刷。这类特征在做反欺诈时极为有效。
3. 实操过程与核心环节实现：从原始表到上线监控
3.1 数据接入和数据探查：以网约车司机风险预警为例
为了讲清楚整个实操链路，我拿一个“网约车司机风险预警”项目来示例。这个项目的背景是：平台要识别那些驾驶行为异常、投诉率高的司机，提前干预，避免安全事故和客诉风险。
数据表我分成了四张：
- 司机基础表：司机ID、年龄、驾龄、注册城市、车辆类型、评分。
- 订单表：订单ID、司机ID、乘客ID、下单时间、上车点、下车点、订单金额、是否取消。
- 轨迹表：司机ID、时间戳、经度、纬度、速度、加速度。
- 投诉表：投诉ID、订单ID、司机ID、投诉类型（危险驾驶/服务差/绕路等）、投诉时间。
第一步是数据探查。我先看每个表的行数、字段数、主键是否唯一，然后逐个字段看缺失率、分布。拿订单表举例，我会这样检查：
import pandas as pd orders = pd.read_csv('orders.csv') print(orders.shape) print(orders.isnull().mean().sort_values(ascending=False)) print(orders['driver_id'].nunique()) print(orders['order_status'].value_counts())这一步看起来简单，但非常关键。订单表中order_amount的缺失率有8%，cancel_reason缺失率40%，这些都直接影响后续特征构造。还有一个问题是同一张订单在表里重复出现3次，最后查下来是因为上游同步脚本跑重了，空值+重复，花了大半天清理。
3.2 数据清洗和标签设计：坏样本怎么定义
风控项目里，标签设计比特征设计还重要。标签定义错了，后面全白搭。在司机风险这个案例里，“风险”的定义我分成了两个口径：
- 宽口径：发生过一次被投诉且投诉类型属于“危险驾驶”。
- 严格口径：30天内被投诉危险驾驶大于等于2次，或发生过一次交通事故。
我最终选用了严格口径作为建模标签，因为宽口径噪声太大，很多投诉是乘客恶意投诉，会导致模型学到错误信号。
标签设计还有一个关键动作：确定观察期和表现期。比如用司机过去90天的行为数据作为特征，然后看后30天是否发生风险事件。时间窗口切分一旦出错，就会产生特征与标签重叠的问题。
数据清洗阶段，订单金额有负值，我先做业务规则过滤，剔除小于0的订单；驾驶速度超过200km/h的记录直接标记为异常值并剔除。清洗后我用Spark做了一个简单的统计任务来验证数据的正确性：
from pyspark.sql import SparkSession from pyspark.sql import functions as F spark = SparkSession.builder.appName('driver_risk_etl').getOrCreate() df = spark.read.parquet('orders_clean.parquet') df.groupBy('driver_id').agg( F.count('order_id').alias('order_cnt'), F.sum('order_amount').alias('total_amount'), F.avg('order_amount').alias('avg_amount') ).show(10)3.3 特征工程实战：从原始数据到建模特征
特征工程环节，我针对司机风险定义了三个维度的特征：
驾驶行为特征：从轨迹表里计算急加速、急刹车、急转弯次数，超速比例，夜间行驶时长占比。这些可以反映司机驾驶的激进程度。
订单运营特征：每天的完单量、平均评分、取消率、投诉率、平均每单时长、每单金额稳定性（标准差/均值）。
时间衰减特征：因为人的行为是随时间变化的，我们用的不是单纯的计数，而是做了时间衰减加权，比如越近的行为权重越高：
import pandas as pd import numpy as np def time_decay_weighted_count(df, date_col, decay_halflife=30): # 假设df是司机的行为表，包含日期和数量列 # 用指数衰减函数给不同日期的行为赋予权重 df = df.copy() df['decay_weight'] = np.power(0.5, (pd.Timestamp.today() - pd.to_datetime(df[date_col])).dt.days / decay_halflife) result = df.groupby('driver_id').apply( lambda x: np.sum(x['behavior_count'] * x['decay_weight']) ).rename('behavior_score') return result所有特征生成完之后，我把它们合并成一张宽表：
feature_matrix = driver_base.merge(behavior_features, on='driver_id', how='left') feature_matrix = feature_matrix.merge(order_features, on='driver_id', how='left') feature_matrix = feature_matrix.merge(complaint_features, on='driver_id', how='left')合并完成之后，我还用了一个简单手段检查特征有效性：计算每个特征与标签的相关系数，相关方向不对的特征（比如“驾龄越长越危险”这种明显违背业务常识的），直接回到特征工程去debug。
3.4 模型训练与参数选择
建模环节我用的是LightGBM。选它而不是XGBoost，主要是训练速度快，内存占用小，而且对类别特征原生支持，省去了不少独热编码工作。
import lightgbm as lgb from sklearn.model_selection import train_test_split from sklearn.metrics import roc_auc_score, precision_score, recall_score # 假设 X 是特征矩阵，y 是标签 X_train, X_test, y_train, y_test = train_test_split( X, y, test_size=0.2, stratify=y, random_state=42 ) model = lgb.LGBMClassifier( n_estimators=500, learning_rate=0.05, num_leaves=31, max_depth=7, subsample=0.8, colsample_bytree=0.8, random_state=42, class_weight='balanced' ) model.fit( X_train, y_train, eval_set=[(X_test, y_test)], eval_metric='auc', callbacks=[lgb.early_stopping(50)] ) y_pred = model.predict_proba(X_test)[:, 1] print('AUC: ', roc_auc_score(y_test, y_pred))参数设置上有几个注意点：
- class_weight='balanced'是处理样本不平衡的简单有效方式。我们这个项目里，风险司机的占比只有2.3%，如果不调权重，模型会全部预测为正常司机。
- num_leaves不要设太大，默认31对大多数风控场景已经是偏高风险的上限，再大会过拟合。
- early_stopping一定开，否则GBDT在几百轮迭代后验证集AUC早就开始掉了，白算大量时间。
训练完之后，我跑了一下特征重要性排名，靠前的是：近30天被投诉次数、急刹车次数/百公里、夜间行驶占比、超速比例。这个排序和业务判断基本吻合，方向对了。
3.5 模型评估：只看准确率远远不够
风控模型不能只看准确率，因为样本极度不平衡。我见过有人报出99.7%的准确率，但实际上是模型把所有样本都预测为正常，一眼假。
我通常看这几个指标：
- AUC：整体区分度，一般大于0.75才勉强能上线。
- KS：衡量模型对好坏样本的区分程度，风控一般要求0.3以上。
- Precision@Top N：只看预测风险概率最高的那批人，命中率有多高，这个更贴近业务实际操作。
- 混淆矩阵：看漏杀和误杀的比例。
在司机风险这个项目中，Top 5%高风险司机里，实际风险事件覆盖了42%，这个数字对业务来说比AUC好理解得多。风控团队真正关心的是：我圈500个人去重点监控，里面能命中多少个。
3.6 模型上线与监控
模型离线跑得好，不代表上线就行。风险场景最大的敌人是分布漂移。用户群体变了、业务政策变了、季节变了，都会导致模型失效。
我上线后的标准动作是：每周监控模型评分分布（PSI）、特征分布和AUC变化。如果PSI超过0.2，说明模型已经明显漂移，需要重训。监控脚本用定时任务跑，结果推送到企业微信告警。
另外还有一个细节：模型要支持灰度。先让5%的流量走新模型，和旧模型的预测结果做对比，确认没有大偏差再全量。这是工程化落地的底线。我见过有团队直接把新模型全量上线的，结果因为训练数据和实时数据的分布差异，审批通过率出现大幅波动，当天就回滚了。
4. 案例复盘：互联网信贷反欺诈中的实战应用
前面讲的是网约车司机的案例，我再扩展一个互联网信贷反欺诈的实战，因为这是数据挖掘在风险管理中最典型的应用场景。
信贷反欺诈面临的核心问题是：如何在几秒钟内识别出一笔申请是否为欺诈。欺诈团伙会批量伪造身份信息、包装流水、养号，从单条样本看和正常用户区别不大，但放到群体维度看就有明显的聚集特征。
这个场景里我用过一个很有效的特征：关联图谱特征。把同一个设备ID、同一个IP、同一个联系电话关联起来的用户构建成一个图，然后计算每个用户在图里的度数、PageRank值、连通分量大小。你会发现欺诈团伙的节点会形成巨大的连通子图。这个特征单独拿出来就能刷到0.7的AUC，叠加其他行为特征后能到0.88。
另外还要重点处理的就是拒绝推断问题。信贷场景里，被拒绝的用户没有后续表现记录，直接用历史放款用户建模会有偏差。实操中我们用了半监督的思路，把拒绝用户的模型预测概率作为伪标签，然后重新训练，AUC提升了约2个百分点。
这个案例说明一件事：数据挖掘在风险管理中的价值，很大程度上来自于对业务场景的深度理解和问题重构能力，而不是单纯堆算法。
5. 常见问题与排查技巧实录
5.1 样本不平衡：坏样本太少怎么办
风控里坏样本占比经常不足5%，甚至不足1%。处理思路一般是：
- 采样层面：对多数类欠采样、对少数类过采样。
- 算法层面：类别权重、异常检测（孤立森林/One-Class SVM）代替二分类。
- 评价层面：改用Precision-Recall曲线，不要只看AUC。
我常用的是一套组合拳：先用LightGBM（带class_weight='balanced'）训练，如果训练集的recall还是不足，再对少数类做SMOTE过采样。SMOTE在风控里效果一般，因为它会在特征空间中插值，可能导致样本变成不符合业务逻辑的合成样本，所以我不是每次都用它。
5.2 特征泄漏：你以为的“好特征”是作弊
特征泄漏是风控建模中最隐蔽的问题，也是最致命的。常见的泄漏有三种：
- 未来数据泄漏：用未来的信息预测当下。
- 全样本统计泄漏：对整个数据集做标准化，导致训练和测试信息重叠。
- 标签泄漏：特征中直接包含了标签相关的信息。
排查特征泄漏有一个技巧：训练一个模型，然后看那些“好得反常”的特征。如果某个特征的Gain值排名异常靠前，而业务上又解释不通，十有八九是泄漏了。
5.3 时间窗口错位：训练和上线口径不一致
训练时用过去90天的数据构造特征，上线时却用的是过去30天规则，这就叫时间窗口错位。解决方法是把特征工程封装成统一的函数，训练和上线都走同一套代码，杜绝手写两遍。
5.4 数据漂移：监控模型是否“过期”
数据漂移检测有几种手段：
- PSI（Population Stability Index）：衡量特征分布的变化。
- KS差异：训练集和上线后的模型评分rank差异。
- 每日K-S检验：用两样本检验实时数据和训练数据是否同分布。
一旦发现漂移，应对策略是：重新校准模型阈值、触发增量重训、或者人工介入调整规则。
下面这张表总结了我踩过的坑和排查思路，可以当速查表用：
| 问题现象 | 可能原因 | 排查思路 | 解决方案 |
|---|---|---|---|
| 模型上线后效果断崖式下跌 | 特征泄漏或时间窗口错位 | 看验证集AUC和上线后AUC差异 | 统一训练/推理特征管道，去除泄漏 |
| 坏样本召回率极低 | 样本不平衡且未处理 | 查看混淆矩阵 | 加类别权重、过采样，调整阈值 |
| 特征重要性排名和业务常识矛盾 | 数据质量有问题 | 回查原始数据分布 | 清洗异常值，检查缺失标记 |
| 预测概率整体偏差 | 样本选择偏差 | 比较训练集和实时数据分布 | 增加模型校准，定期重训 |
| 规则引擎和模型结果冲突 | 规则和模型目标不一致 | 拉出冲突样本人工评估 | 规则和模型建立统一决策矩阵 |
5.5 工程上的其他坑
除了模型层面的问题，工程上也有几个容易出事的点：
- 主键不唯一：两张表关联之后行数暴增，一做聚合全乱了。必须做去重和主键检查。
- 分区数据缺失：跑每日任务遇到上游某一个分区数据没生成，导致当天特征全为空，模型输出一堆异常分数。需要加一个数据完整性校验步骤。
- 时区问题：订单时间用北京时间，日志时间用UTC，合并之后时间窗口完全错乱。统一时区是基本操作。
关于这个方向，我最后再分享一点经验
做数据挖掘在风险管理领域的应用，最大的门槛其实不在算法，而在于把业务问题转化为数据问题的能力。你和风控业务方聊需求的时候，他们不会跟你说“我要一个XGBoost模型”，他们会说“这些人太可疑了，你帮我看看里面有没有规律”。这时候你要做的不是急着写代码，而是把“可疑”翻译成可定义、可标注、可计算的东西。
我踩过无数次坑之后的总结是：数据质量决定模型下限，特征工程决定模型上限，算法选型决定训练效率，而业务理解决定项目成败。这四个环节缺一不可，而很多人只盯着中间的算法部分。
后续如果你想在这个方向深入，我建议把Hive、Spark、Python、机器学习基础这四块先打牢，然后找一个具体的风险场景（信贷、反欺诈、反洗钱都行），从数据接入开始完整地做一遍，比刷一百道面试题都管用。数据挖掘做风险，做的是实打实的降损失、控风险，这个价值在任何行业都能被看到。
