机器学习反欺诈实战：基于IEEE-CIS数据集的LightGBM二分类与特征工程全流程

简介：针对IEEE-CIS欺诈检测竞赛的探索性数据分析（EDA）与特征工程资源，面向参加Kaggle比赛或研究金融风控反欺诈的算法工程师，适合具备一定机器学习基础、希望快速上手金融风控场景的中高级学习者。任务本质是二分类：判断用户行为是否属于点击欺诈，资源围绕此目标给出完整分析流程。主文件Jupyter笔记包含数据分布、缺失情况、相关性等深度洞察，配套数据清洗、可视化、特征工程三个Python脚本，可高效处理大规模交易与身份信息表格。压缩包共6个文件，涵盖Jupyter笔记、Python脚本与说明文档，大小仅1.02MB。已有599人学习。笔记可引导读者从原始表格到洞察结论，掌握单变量/双变量分析与聚合特征构造思路；Python脚本则提供缺失值填补、类型转换、图表报告等可复用函数，便于迁移至相似反欺诈项目，也可直接作为数据科学课程教学演示。整体代码结构清晰，能有效缩短EDA流程、提升建模效率。

1. IEEE-CIS-Fraud-Detection 是什么：一份能直接复现的欺诈检测全流程

IEEE-CIS-Fraud-Detection 很适合用来练手表格类机器学习：一份 Jupyter Notebook 把约 59 万条交易、394 个脱敏特征、约 3.5% 的欺诈正样本做成可训练、可验证、可扩展的二分类方案，核心任务是预测每笔交易的 isFraud 是否为 1，评估指标用 ROC AUC。它适合刚入门风控和异常检测的开发者，想把特征工程、LightGBM 交叉验证整条链路跑通；也适合已经在用业务规则做反欺诈的工程师，想看看机器学习能不能替代写死的阈值。整个流程不依赖 GPU，16GB 内存的机器就能跑完，Notebook 里每个 cell 都保留了中间输出，方便逐行对照。它不只是一个模型文件，而是一套从原始 CSV 到提交结果的完整流程，换数据集时改改列名就能复用。

2. 先摸清工程结构：Transaction 与 Identity 两张表、394 个特征和 isFraud 目标

拿到这份资源的第一步不是急着跑代码，而是先搞清楚数据从哪来、表怎么关联、每个字段属于哪一族。这一步没做透，后面写特征工程时很容易把两套表混在一起处理，等模型训完才发现 join 错了行数，返工成本很高。

2.1 目录结构：Notebook、数据输入、训练输出三方分离

整套工程在目录上按「原始数据 / Notebook / 输出」三个区域分开，实际下载后大致是这个样子：

ieee-cis-fraud-detection/ ├── input/ # 原始 CSV，只读不写 │ ├── train_transaction.csv # 主表：约 59 万行，394 列 │ ├── train_identity.csv # 身份设备表：约 14 万行，41 列 │ └── test_transaction.csv # 测试集：无 isFraud 标签 ├── notebooks/ │ ├── 01_eda.ipynb # 数据概览、缺失率、目标分布 │ ├── 02_feature_engineering.ipynb # 特征工程全流程 │ └── 03_train_lgb.ipynb # 五折训练 + OOF 评估 + 提交 ├── output/ │ └── submission.csv └── README.md

这里有个值得学习的设计：input 目录只放原始 CSV，路径不硬编码在 Notebook 里；output 统一收预测结果。这样换机器、换环境时不需要改动任何 cell，训练产物也永远不会污染数据目录。三个 Notebook 按 01、02、03 编号，本身就是在表达「先看数、再提特征、最后建模」的先后依赖关系，你照着编号顺序执行就能复现完整流程。

2.2 两张源表的关联关系：按 TransactionID 做扩展，Identity 只覆盖四分之一

主表是 train_transaction.csv，每一行是一笔交易，包含交易本身的时间、金额、卡片、地址信息。train_identity.csv 则记录设备指纹和身份相关字段，需要通过 TransactionID 关联回主表。注意 identity 表只覆盖了约四分之一的主表记录——不是每笔交易都有设备信息。

这个覆盖率差异直接决定了特征工程的处理方式：主表自身的字段可以全量参与特征构建，而 identity 表 join 不上来的行只能按缺失值处理。有人会先把两张表左连接成一张大宽表再统一处理，也有人分开构造特征矩阵后再合并；我一般倾向后者，因为 identity 字段缺失率本身就是一个很有价值的信息维度，分开处理更清晰。

2.3 特征族谱：394 列到底在描述什么

394 个特征看着吓人，拆成族谱后其实就八类。竞赛方对原始字段做了脱敏和匿名化，但字段命名规律仍然保留了分组信息：

V1 到 V339 是篇幅最大的一个族，也是缺失率最严重的地方。这类字段通常是原始特征经过匿名变换后的产物，语义已经不可解读，只能当作纯数值特征喂给模型，缺失率过高的列直接丢弃。

2.4 目标变量与评估口径：为什么是 ROC AUC 而不是准确率

isFraud 的正样本比例约 3.5%，属于典型的类别不平衡场景。如果拿准确率当指标，模型全预测 0 也能拿到 96.5% 的准确率，但这个模型毫无价值。ROC AUC 评估的是排序能力：随机抽一个欺诈样本和一个正常样本，模型给欺诈样本打出更高分数的概率。

这个口径和反欺诈业务是对齐的——生产环境里你不会只卡一个阈值，而是按分数从高到低排序，依次审核。AUC 高意味着同样的审核人力下能捞到更多欺诈交易。所以 Notebook 里第一个 cell 通常是打印正负样本比例和 TransactionDT 的时间跨度，先把基本盘看清。

3. 特征工程拆解：内存压缩、缺失填充、组合特征与聚合特征的四个关键动作

这个项目的分数高低，八成取决于特征工程而不是模型本身。LightGBM 是出了名的"给好特征就出好结果"，反过来也一样——原始 394 列直接丢进模型，AUC 通常只能做到 0.90 上下；把特征工程做完整，同样的模型能上到 0.95 左右。差距全在这几个动作里。

3.1 内存优化：float64 到 float32，先让 394 列装得进内存

59 万行乘以 394 列，pandas 默认按 float64 读取时，单表内存占用轻松超过 2GB，再加上身份表、测试集和中间变量，16GB 内存很快见底。这个项目场景下的标准做法是写一个降精度函数：

import numpy as np import pandas as pd def reduce_mem_usage(df: pd.DataFrame) -> pd.DataFrame: """把数值列从 float64/int64 降到够用的精度，内存直接减半""" for col in df.columns: col_type = df[col].dtype if col_type == "object": continue # 字符串列后面单独做编码 c_min = df[col].min() c_max = df[col].max() if str(col_type)[:3] == "int": if c_min > np.iinfo(np.int8).min and c_max < np.iinfo(np.int8).max: df[col] = df[col].astype(np.int8) elif c_min > np.iinfo(np.int16).min and c_max < np.iinfo(np.int16).max: df[col] = df[col].astype(np.int16) else: df[col] = df[col].astype(np.int32) else: df[col] = df[col].astype(np.float32) # 浮点一律压到 float32 return df train = reduce_mem_usage(train)

这个函数的逻辑是：对整数列按取值范围选最小的整型（int8/int16/int32），对浮点列一律压到 float32。LightGBM 训练对数值精度不敏感，float32 和 float64 的预测差异基本在 AUC 小数点后第四位，但内存直接省一半。有个细节要注意：边界判断用的是>而不是>=，如果某列的最小值恰好等于 -128 会被漏判，自己复用时改成>=更稳妥。

3.2 缺失值处理与 label encoding：-1 占位是这类项目的默认动作

V 列大量缺失、identity 表覆盖率只有四分之一，意味着缺失值处理是整个特征工程里最绕不开的一步。常见的做法是先统计每列缺失率，把缺失超过 80% 的列直接丢掉，剩余列在训练里交给 LightGBM 的原生缺失值支持处理；类别列则先转 codes，用 -1 统一表示"缺失/未知"：

# 统计缺失率并丢弃高缺失列 missing_rate = train.isna().mean() drop_cols = missing_rate[missing_rate > 0.8].index.tolist() train = train.drop(columns=drop_cols) # 类别列编码：astype('category') 后缺失值自动映射为 -1 cat_cols = ['ProductCD', 'card1', 'card2', 'card3', 'card4', 'card5', 'card6', 'addr1', 'addr2', 'P_emaildomain', 'R_emaildomain'] for col in cat_cols: train[col] = train[col].astype('category').cat.codes

cat.codes会把每个类别编号成从 0 开始的整数，缺失值自动编为 -1，正好当作"未知"这一类别。要特别注意的是，codes 编号只表示类别序号，不代表大小关系——card5 的 7 并不比 3 "大"。所以这类特征喂给 LightGBM 时必须通过categorical_feature参数声明为类别特征，否则模型会把编号当成有序数值来切分，效果会变差。

3.3 组合特征：card1_card2 与 addr 的高基数"黑匣子"

这个项目里最有名的一个技巧是组合特征。card1 到 card6 各自脱敏后仍然保留了一定的卡片辨识度，把 card1 和 card2 拼成一个新类别，等于构造出"这张具体卡片"的近似标识。模型就能学到"这张卡过去是否有欺诈历史"这种强规律：

train['card1_card2'] = (train['card1'].astype(str) + '_' + train['card2'].astype(str)) train['card1_card2'] = train['card1_card2'].astype('category').cat.codes

这类组合特征基数很高，很多组合在训练集里只出现一两次。我的习惯是构造完之后统计一下基数，如果某个组合特征的唯一值数量接近样本量，就说明它已经开始"背样本"了。此时要么做频次过滤（出现次数小于阈值就归为 -1），要么改用组合后的 count/mean 聚合特征，保留信息的同时把基数降下来。这条经验在后面避坑章节还会再展开。

3.4 时间与聚合特征：从 TransactionDT 拆小时，按 card1 算金额统计

TransactionDT 是以秒为单位的相对时间戳，直接当数值特征用只能让模型学会"第几天"，信息密度太低。通过取模运算可以还原出小时和星期规律——欺诈交易在一天内的分布并不均匀，这些周期性信号模型自己很难从原始秒数里学到：

train['hour'] = train['TransactionDT'] // 3600 % 24 # 一天 24 小时 train['weekday'] = train['TransactionDT'] // 86400 % 7 # 一周 7 天

聚合特征方面，最常用的是按 card1 分组统计金额的均值、标准差和最近一次金额：

train['amt_mean_card1'] = train.groupby('card1')['TransactionAmt'].transform('mean') train['amt_std_card1'] = train.groupby('card1')['TransactionAmt'].transform('std')

transform会把聚合结果广播回每一行，不需要再 merge，也不会改变行数。这几个特征表达的是"这张卡的历史平均金额"和"金额波动程度"，模型拿到它们之后就能识别出金额明显偏离卡片历史习惯的交易。groupby 聚合结果是按索引对齐的，如果之前做过行筛选或排序，务必先reset_index再聚合，否则特征会错位——这个问题每年都有新人踩一次。

4. 建模与训练：五折交叉验证下 LightGBM 的完整链路

特征工程做完，接下来就是建模。整个训练链路设计成"五折交叉验证 + 早停 + OOF 汇总"三段式，这套结构几乎是表格类比赛的标准答案，换任何二分类数据集都能复用。

4.1 数据集划分：StratifiedKFold 保持正负样本比例

3.5% 的正样本率意味着如果用普通 KFold 随机切五折，某些折里的欺诈样本数可能波动很大，导致不同折的模型看到的数据分布不一致。StratifiedKFold 能保证每一折里 isFraud 的比例都和全量基本一致：

from sklearn.model_selection import StratifiedKFold skf = StratifiedKFold(n_splits=5, shuffle=True, random_state=42)

n_splits=5是权衡后的选择：折数太少验证集波动大，折数太多则每折训练数据变少。shuffle=True先打散再切分，避免原始数据按时间排序后切出偏枯的折；random_state=42固定下来，保证任何人复现时拿到完全一样的划分。这一点很重要——如果不固定随机种子，每次跑出来的 AUC 都不一样，你就永远说不清分数变化到底是改特征导致的还是随机波动导致的。

4.2 LightGBM 参数与早停：小学习率配大轮数

模型主体用 LightGBM，核心参数组合是"小学习率 + 大树数 + 早停"，让模型在低风险下把容量吃满：

import lightgbm as lgb params = { 'objective': 'binary', # 二分类 'metric': 'auc', # 与竞赛评估口径一致 'learning_rate': 0.01, # 小步长，每轮只走一点 'num_leaves': 64, # 单棵树叶子数，控制复杂度 'feature_fraction': 0.8, # 每棵树随机用 80% 的特征 'bagging_fraction': 0.8, # 每棵树随机用 80% 的行 'bagging_freq': 1, # 每轮都做行采样 'min_child_samples': 20, # 叶子最少样本数，防过拟合 'verbosity': -1, # 别刷屏 } oof = pd.Series(0, index=train.index) for fold, (tr_idx, va_idx) in enumerate(skf.split(train, y)): tr = lgb.Dataset(train.iloc[tr_idx], y.iloc[tr_idx], categorical_feature=cat_cols) va = lgb.Dataset(train.iloc[va_idx], y.iloc[va_idx], categorical_feature=cat_cols) model = lgb.train(params, tr, num_boost_round=10000, valid_sets=[va], callbacks=[lgb.early_stopping(200)])

learning_rate=0.01配num_boost_round=10000的意思是：每棵树只学一点点，靠轮数把精度堆上去，这样比大学习率少树更稳定，尤其适合高基数特征多的场景。early_stopping(200)指定验证集连续 200 轮不提升就停，并把当前最好轮次记在best_iteration上。feature_fraction和bagging_fraction是列采样与行采样，两个都开能显著降低特征之间的共线性影响——本项目里 V 列之间相关性很高，这个设置价值尤其大。

4.3 OOF 汇总与特征重要性：不靠单折分数下结论

五折训完，把每一折验证集的预测拼回原位置，得到 OOF（out-of-fold）预测。它等价于"每个样本都被一个没见过它的模型预测了一次"，用这个输出去算 AUC，才是真实泛化性能的估计：

from sklearn.metrics import roc_auc_score oof_score = roc_auc_score(y, oof) print(f"OOF AUC = {oof_score:.5f}")

要注意 predict 时必须指定num_iteration=model.best_iteration，否则会用完整 10000 棵树预测，而早停已经证明后面的树在验证集上是负贡献。特征重要性则用 gain 而非 split 来排序：

imp = pd.DataFrame({ 'feature': train.columns, 'gain': model.feature_importance('gain'), }).sort_values('gain', ascending=False) imp.head(20)

gain 表示该特征在分裂中带来的信息增益总和，比 split（分裂次数）更能反映实际贡献。通常跑完第一次就能看到 card1_card2、amt_mean_card1 这类特征排在最前面，这时候你就能确信特征工程的方向没错。

5. 常见坑与排查：内存爆炸、验证集虚高和"背题"特征的翻车记录

这套流程踩过的坑不少，我挑四个最有代表性的写下来，每条都是「现象 → 原因 → 解决」三段式，你照着排查能省不少时间。

5.1 读取后内存直接爆掉

现象：read_csv 加载 train_transaction.csv 后，进程被杀或 Jupyter 内核崩溃，查看任务管理器发现内存占用接近 20GB。 原因：pandas 默认把数值列读成 float64 和 int64，394 列堆下来非常占内存；中间如果再复制一次 DataFrame，内存直接翻倍。 解决：读取时就指定 dtype 或用前面写的reduce_mem_usage函数第一时间压缩。另一个办法是先pd.read_csv(..., nrows=1000)探测每列类型，再带着精确的 dtype 字典全量读取，两种方式都能把峰值内存压低到 4GB 以内。

5.2 随机划分验证 AUC 虚高，时序划分分数掉一截

现象：StratifiedKFold 随机划分时 OOF AUC 稳定在 0.95 以上，换成按 TransactionDT 排序后切验证集，AUC 立刻掉到 0.92 左右。 原因：欺诈行为在时间上存在聚集性，随机打散等于把"未来的欺诈模式"泄漏进了训练集。模型学到的是时间段规律而不是跨时间的泛化规律，这在业务上不可用——线上永远只有过去的数据。 解决：训练之前先做一致性检查：跑两版实验，一版随机划分、一版按时间顺序划分，两个分数都记录下来。如果时间划分分数明显更低，说明特征里时间相关信号过重，优先剔除与 TransactionDT 强相关的列，或者干脆以时间划分的分数作为主指标。

5.3 加上 card1_card2 后训练 AUC 逼近 1，验证集却波动很大

现象：引入组合特征后训练集 AUC 冲到 0.99，但五折验证分数互相能差 0.02，稳定不下来。 原因：组合特征基数太高，很多组合在训练集里只出现几次甚至一次，模型直接把这些样本"背"下来了，遇到没见过的组合就乱猜。 解决：对组合特征做频次过滤，把出现次数低于 10 的组合统一映射成 -1；或者退一步，用组合后的 count 特征（每个组合出现的次数）和金额聚合替代原始组合编码，信息还在，基数可控。记住一个判断标准：特征唯一值数量超过样本量的 5%，基本就是在背题。

5.4 本地 AUC 正常，提交分数对不上

现象：OOF AUC 0.95，提交后分数远低于本地，甚至接近随机。 原因：测试集在特征工程阶段被 shuffle 或筛选过，预测阶段输出 submission.csv 时行序没有对齐原始索引，标签和特征错位。 解决：从训练阶段就把流程固化下来——预测前test.reset_index(drop=True)，把索引重置干净后再做特征工程；保存提交文件时按原始 TransactionID 排序并校验行数。这个坑属于典型的"过程正确但结果全错"，光看本地分数根本发现不了。

6. 二次开发思路：把这套 Notebook 改造成自己的风控基线

复现只是第一步，这套资源真正的价值在于可以迁移到自己的业务数据上。我的改造路径分三步走。

第一步是换数据源时的列名映射。拿自己系统的交易表过来，先写一个字段映射字典，把业务字段对齐到这套工程的主表字段上：

field_map = { 'pay_time': 'TransactionDT', 'pay_amount': 'TransactionAmt', 'user_id': 'card1', 'merchant_id': 'card2', } train = train.rename(columns=field_map)

映射完先跑 01_eda 看分布，确认金额、时间两列的语义一致再往下走。第二步是把特征工程代码从 Notebook 里抽成独立模块，训练和预测共用同一份feature_engineering.py，避免两个 Notebook 各写一套特征逻辑。第三步才是换模型——补一个 XGBoost 或 CatBoost，两个模型预测分数做加权平均，用 OOF AUC 决定权重，一般从 0.6/0.4 起步试。

部署上线时我会把训练好的模型用booster.save_model('lgb.txt')导出成文本文件，服务端加载后，在线预测前先把原始请求字段塞进同一个特征工程函数，保证训练和线上特征完全一致。这里最容易翻车的是线上字段缺失——请求里少一个字段，函数要按缺失值逻辑兜底，而不是抛异常返回 500。

从那以后，我每次拿到一个新数据集都会强制走一遍「列名映射 → 特征工程函数化 → 随机/时序双验证」这三步，基本杜绝了训练和线上不一致的翻车。这个项目作为起点已经足够完整，剩下的就是你自己的数据了，希望帮到你。

本文还有配套的精品资源，点击获取