简介本资源是2021年科大讯飞主办的车辆贷款违约预测挑战赛完整Python实现方案面向金融风控、机器学习入门及进阶学习者适用于课程设计、毕设选题、工程实训等实践场景。项目基于真实业务数据构建端到端建模流程涵盖特征工程gen_feats.py、多模型融合XGBoost/LightGBM、概率校准与结果生成提供可复现的违约风险预测能力。压缩包共18个文件含5个CSV数据集train_final.csv/test_final.csv等、4个核心Python脚本、3个训练好的模型pkl文件、2个Shell执行脚本及README.md说明文档整体大小为59.41MB结构清晰、模块解耦便于理解建模逻辑与调试优化。目前已有226人下载学习读者可直接运行train.sh/test.sh完成全流程训练与预测并获取完整特征构造思路、模型保存加载机制及结果提交格式规范。 先说个前提我是以参赛者的视角来复盘这场比赛不是官方复盘也不代表科大讯飞那边的口径。2021年科大讯飞办的这个车辆贷款违约预测挑战赛本质上是金融机构最典型的贷后风控问题只是在公开数据集上以竞赛的形式呈现。当年我花了两个周末完整跑了一遍从最开始的baseline到后面的特征工程、模型调优踩了不少坑也拿到了一个还算能看的排名。这篇文章就把我当时完整的思路、代码、踩坑记录全部翻出来给你一份可以照着抄的完整方案。这个项目适合谁如果你是刚入门机器学习、想找一个真实数据集练手的人或者你已经在做风控建模、想看看公开赛题和实际业务的差距再或者你准备参加类似的金融风控类竞赛但不知道从哪下手这篇都能帮到你。我会把每一步的“为什么这么做”也讲清楚而不是简单丢给你一段代码。1. 赛题解读先搞清楚这场比赛在考什么1.1 车辆贷款违约预测的业务本质车辆贷款违约预测说白了就是银行或者汽车金融公司在放贷之前需要判断“这个人将来会不会按时还钱”。放在机器学习里这是一个标准的二分类问题目标变量就是“是否违约”通常是0和11表示违约。但业务上远不止训练一个分类器那么简单因为金融风控对模型的解释性、稳定性、误判成本都有极高的要求。实际风控业务里一个违约预测模型要考虑的东西很多拒绝率、通过率、坏账率、利率定价、催收优先级等等。竞赛场景虽然简化了这些业务约束但核心目标没变——尽可能准确地识别出“可能会违约”的样本。这场比赛的数据集是典型的信贷业务数据包含借款人的个人信息年龄、职业、学历、收入等、贷款信息贷款金额、期限、利率、首付比例等以及历史行为数据逾期记录、查询次数等。但我得提醒你竞赛数据是脱敏和清洗过的和我们平时在公司里看到的原始数据库表差别很大你拿竞赛的思路直接套业务数据大概率会水土不服。1.2 从数据表反推赛题设计思路拿到比赛数据之后我习惯先看字段数量和类型再猜主办方到底想考察什么。这个赛题给到的训练集大概有20多个特征不算多但每列都有讲究。按业务含义可以分成几组个人信息类年龄、性别、职业、教育程度、婚姻状况、是否有房、是否有车贷款申请类贷款金额、贷款期限、利率、首付比例、车辆价格、车辆品牌历史行为类信用评分、历史逾期次数、信用卡使用率、贷款查询次数特殊标识类申请时间、贷款发放时间、订单ID、用户ID字段设计其实暗含了很多业务逻辑。比如“车辆价格”和“贷款金额”放在一起就可以算出贷款成数LTVLoan to Value风控里这是非常核心的指标车价越高、首付越少违约风险通常越高因为车贬值速度太快借款人可能直接选择弃车不还。再比如“贷款利率”这个字段利率定得高往往意味着借款人的信用资质本身就差是风险定价的结果所以利率和违约率天然就是正相关的。我当时看到这样的字段结构第一反应就是这场比赛的重点不在深度学习而在特征工程。数据量不大、字段有业务含义、类目型特征居多这种场景下树模型是绝对的主流LightGBM、XGBoost、CatBoost三件套基本上都能搞定关键是看你怎么从原始字段里挖出有效信息。1.3 评价指标与baseline的重要性竞赛页面明确了评价指标是AUC这一点非常重要。AUC衡量的是模型把正样本排在负样本前面的概率它不依赖具体的分类阈值所以对样本不平衡不敏感。车辆贷款违约率通常在10%到20%之间属于典型的类别不平衡场景如果你用准确率当指标模型就算全预测成“不违约”准确率也能有80%以上但一点用都没有。AUC的优势还在于它的稳定性它不会因为阈值微调而产生剧烈波动更适合比较不同模型之间的优劣。不过AUC也有一个坑它只看排序不看绝对概率值。也就是说一个模型预测的违约概率普遍偏高或普遍偏低只要排序不变AUC几乎不受影响。这在调参的时候会让很多人困惑明明概率分布变了很多AUC怎么纹丝不动。所以拿到赛题的第一件事不是急着做特征工程而是先跑通一个最朴素的baseline把数据读进来用默认参数训练一个LightGBM提交一次看分数大致在什么水平。我记得当时直接跑默认参数用所有原始特征AUC大概是0.72左右。这个分数就是你的起点后面的所有工作都是在这个基础上往上加。2. 环境准备与数据初探2.1 Python环境搭建的关键细节比赛用的是Python这个没什么悬念。但环境搭建里有一个小细节容易忽略不是所有机器都装了LightGBM也不是所有人都会配置Anaconda。结合那段时间很多人搜索“python安装”、“python环境变量的配置”、“vscode python环境配置”我猜有不少新手卡在了环境这一步。我的建议是直接用Anaconda不要自己手动装Python再配一堆依赖。Anaconda自带conda管理工具和常见的数据科学库一次性解决Python解释器、pip、包管理的问题。装好之后创建一个干净的虚拟环境这非常重要因为不同项目依赖的包版本可能冲突虚拟环境就是用来隔离的。conda create -n risk_model python3.8 conda activate risk_model pip install pandas numpy scikit-learn lightgbm catboost matplotlib seaborn注意Python版本我用的是3.8不是最新版。原因是LightGBM和CatBoost对Python 3.10以上的支持在当时还不算特别稳定而且很多老代码在3.8上跑得最顺。如果你用最新版Python遇到奇怪的问题先想想是不是版本兼容性问题不要一上来就怀疑代码写错了。VSCode是最好用的编辑器配置Python环境时记得在右下角选择你创建的那个conda环境。有个很常见的坑你在终端里用conda activate切了环境但VSCode里的Jupyter Notebook用的还是默认的base环境导致import lightgbm报错。解决方法是打开命令面板输入“Python: Select Interpreter”手动选中你创建的虚拟环境。2.2 用pandas快速摸清数据底细环境准备好之后第一件事是加载数据看看整体结构。我习惯用的代码如下这算是我的标准起手式import pandas as pd import numpy as np import matplotlib.pyplot as plt import seaborn as sns train pd.read_csv(train.csv) test pd.read_csv(test.csv) print(train.shape) print(test.shape) print(train.info()) print(train.describe()) print(train.head(10))train.info()能看出每列的数据类型和非空值数量这是了解缺失情况最快的方式。describe()能看数值列的分布包括均值、标准差、最小值、最大值、分位数异常值在这里一眼就能看出来。我印象很深的是当时有一个字段叫“工作年限”正常范围应该是0到50年但数据里最大出现了99年这明显是异常值。这种异常值不处理会让模型产生很大的偏差因为树模型的切分点会被严重拉偏。后来我还发现这个字段的99年其实代表的是“缺失或未知”主办方在数据脱敏的时候用99做了占位符数据处理时应该先把这个值替换成NaN再做缺失值填充。2.3 缺失值处理的经验选择缺失值处理是数据清理里的重头戏。我得先纠正一个常见的错误认知很多人以为缺失值处理就是“填均值”或“填中位数”但填哪个、怎么填完全取决于特征本身的含义和数据分布。我当时的处理策略分几个层次连续型变量的缺失优先用中位数填充而不是均值。因为信贷数据里的收入、贷款金额这类字段往往有明显的长尾分布个别极端值会把均值拉高用均值填充等于给所有缺失样本统一加了一个偏大或偏小的偏置。类别型变量的缺失单独用一个“未知”类别填充不要随便去掉。比如“职业”字段如果缺失它本身可能暗示着信息审核有问题在风控里反而是一个有信号的特征。占比超过30%的缺失字段我会先保留但会额外做一个布尔特征标记“该字段是否缺失”。因为很多时候字段缺失本身就是一种模式比如征信分缺失往往意味着用户没有足够的信用记录这类人群违约率往往更高。# 缺失值占比统计 missing_ratio train.isnull().mean().sort_values(ascendingFalse) print(missing_ratio[missing_ratio 0]) def fill_missing(df): for col in df.columns: if df[col].isnull().any(): if df[col].dtype object: df[col] df[col].fillna(未知) else: df[col] df[col].fillna(df[col].median()) return df这个函数是简化版实际比赛里我会根据每个字段观察缺失特征再决定填充方式而不是一把梭。但作为初版baseline中位数填充加未知类别填充足够用了。另外千万不要用整个数据集的均值或中位数去填充训练集正确的做法是先只基于训练集计算统计量再把它应用到训练集和测试集。否则你的验证集结果会虚高因为你在填充里用到了验证集的信息这是一种很隐蔽的数据泄漏。3. 特征工程这个比赛真正拉开差距的地方3.1 原始字段的清洗与类型修正特征工程的第一步是清理原始字段这一步决定了后面所有特征的质量。我记得当时数据里有几个字段的类型明显有问题“申请时间”和“贷款发放时间”被读成了字符串需要转成pandas的datetime类型才能做日期差计算。“身份证所在地”这种字段看似是类别但它包含的是省份、城市等多级信息需要拆开使用。“车辆品牌”包含一大堆低频品牌直接做独热编码会把特征空间撑爆需要把低频品牌合并成一个“其他”类别。类型修正的代码如下train[apply_time] pd.to_datetime(train[apply_time]) train[loan_time] pd.to_datetime(train[loan_time]) train[id_province] train[id_no].str[:2] # 身份证前两位代表省份这一步看起来简单但很多人会漏掉。尤其是日期字段不转成datetime类型后面做天数的加减运算时会直接报错或者得到一堆毫无意义的结果。另外字段里如果有空字符串pandas会把它当成非空值但实际上是缺失需要用replace将空字符串替换成NaN。3.2 派生特征从业务角度构造有效变量特征工程的核心不是堆特征数量而是从业务逻辑出发构造有意义的变量。我当时构造的派生特征大概分这几类每一条背后都有风控业务的考量贷款成数 贷款金额 / 车辆价格。这个值越高说明借款人首付越少违约成本越低风险越高。这个特征在模型里的重要性排进了前三。月收入与月供比 月收入 / (贷款金额 / 贷款期限)。衡量借款人的还款压力小于1意味着月供超过月收入风险极高。年龄分段。原始年龄是连续值但信贷业务中一般会按年龄段划分比如25岁以下、25-35、35-45、45以上不同年龄段的还款能力和负债情况差异很大。车辆价格分段。车价本身不是一个线性变量我按业务经验划分为经济型、中端、豪华型、超豪华型然后做类别编码。信用评分是否有缺失的布尔特征。这个特征的重要性出乎意料地高我分析下来是因为信用评分为空的用户往往是信用记录空白的“白户”这类人群的违约风险处于两个极端需要单独建模处理。构造特征的代码大概是这样的train[ltv] train[loan_amt] / train[car_price] train[monthly_payment] train[loan_amt] / train[loan_period] train[payment_to_income] train[monthly_payment] / train[monthly_income] train[age_bin] pd.cut(train[age], bins[0, 25, 35, 45, 100], labels[0, 1, 2, 3]) train[credit_missing] train[credit_score].isnull().astype(int)这里有一个细节比率型特征在构造时要防止分母为零或极小值。比如车辆价格如果出现0贷款成数就会变成无穷大需要先处理这类极端值或者在计算时给分母加上一个很小的平滑项。我当时直接用0了但后面做异常值处理的时候专门把车辆价格为0的样本剔除了一部分因为它们明显是数据录入错误不是真实的0元车价。3.3 时间特征的深度挖掘时间字段是信贷数据里非常容易被低估的信息来源。原始数据只给了“申请时间”和“贷款发放时间”但两者之间的距离就很有意义——申请到放款的时间间隔短说明审批流程快可能意味着借款人的资质好、之前有良好信用记录走了快速通道间隔长可能意味着审批过程反复核查背后可能有风险点。我构造的时间特征包括申请到放款的天数间隔申请时间所在月份用来捕捉季节效应。年底和春节前贷款购车的人往往资金压力大违约率会偏高放款时间是否在节假日期间这个特征让我最多提升了约0.01的AUC虽然不多但已经是很大的边际贡献了。在AUC提升到0.78以后每提升0.001都很难0.01相当于好几个高强度特征。train[apply_to_loan_days] (train[loan_time] - train[apply_time]).dt.days train[apply_month] train[apply_time].dt.month train[is_holiday_loan] train[loan_time].dt.dayofweek.isin([5, 6]).astype(int)时间特征里还有一个容易踩的坑直接用时间戳数值当特征。比如把“申请时间”转成浮点数喂给模型这基本没有信息量还会增加过拟合风险。模型学到的是某个特定时间点与违约的关系这个规律在测试集上完全不存在属于伪特征。3.4 特征筛选与共线性处理特征构造完之后特征数量可能膨胀到50-60个这时候不能一股脑全喂给模型。LightGBM对特征共线性有一定的容忍度但过多无关特征会稀释有效特征的权重还会增加训练时间。我先用LightGBM做一次初筛看特征重要性排序再结合业务逻辑人工判断。特征重要性的结果有时候会出乎意料比如“职业”这种业务上很重要的字段因为类别太多、每个类别的样本量太少重要性可能不如一个简单的“历史逾期次数”。这是正常的类别型特征在树模型里容易被低估可以考虑用Target Encoding之类的编码方式增强它。对于相关性极高的特征对比如贷款金额和车辆价格相关系数超过0.9我选择保留LTV贷款成数而删掉原始的两个字段。因为LTV的信息量更大也更有业务解释性。当然树模型其实不太怕线性相关的特征但如果特征数量太多删掉冗余特征可以显著降低过拟合风险。4. 模型训练与调优的核心操作4.1 数据划分与交叉验证模型训练的第一步是合理的验证方案。金融风控竞赛里最忌随机划分布尔类型的验证集因为信贷数据有时间顺序用未来的数据预测过去的事件会造成数据泄漏。虽然比赛主办方提供的训练集和测试集可能已经做了随机打乱但我在自己验证时还是会加上时间维度来参考。我当时的方案是5折分层交叉验证shuffleTrue保证每折的违约率接近总体。注意要加stratify参数让正负样本比例在每折中保持一致否则在数据不平衡的情况下某些折可能只包含极少量违约样本导致验证集AUC出现剧烈波动。from sklearn.model_selection import StratifiedKFold skf StratifiedKFold(n_splits5, shuffleTrue, random_state42)random_state设成固定值也是一个值得强调的细节。如果不固定随机种子每次运行得到的交叉验证结果都会有波动你根本分不清某次调参是真正带来了提升还是只是随机波动。我习惯在训练模型时同时固定LightGBM内部的random_state和特征采样的种子。4.2 LightGBM核心参数解读与调优顺序LightGBM是我在这个比赛里最常用的模型。它训练快、内存占用小、对类别特征有原生支持而且在中小规模数据集上表现非常稳定。这里把核心参数按调优优先级整理一下方便你对照调整n_estimators迭代轮数我用early_stopping配合早停确定而不是手动指定learning_rate学习率从0.05起步如果过拟合就调低到0.01会带来更好的泛化但训练时间更长num_leaves叶子节点数这是控制模型复杂度的关键参数默认31调大能提升拟合能力但过拟合风险也上升max_depth树深度默认-1表示不限但配合num_leaves一起用时要小心min_child_samples叶子节点的最小样本数调大可以抑制过拟合subsample和colsample_bytree行采样和列采样这两个参数用于增加随机性我在调好前几个参数之后才动reg_alpha和reg_lambdaL1和L2正则化系数过拟合时优先调这个scale_pos_weight处理正负样本不平衡的参数后面会详细讲调参顺序有讲究我通常遵循“先粗后细、先整体后局部”的原则。首先确定一个较低的学习率0.01或者0.05得到一个基本合理的n_estimators然后固定学习率调整num_leaves和max_depth来拟合数据再调整min_child_samples避免过拟合最后才动subsample和colsample以及正则化参数。一个很容易犯的错误是上来就调learning_rate到0.001然后发现训练巨慢无比而且AUC还没有明显提升。学习率太低会导致模型在有限迭代轮数内欠拟合太高则容易过拟合需要结合早停轮数选择。我一般用0.05起步配合2000轮迭代基本能覆盖大多数情况。import lightgbm as lgb params { objective: binary, metric: auc, learning_rate: 0.05, num_leaves: 31, max_depth: -1, min_child_samples: 20, subsample: 0.8, colsample_bytree: 0.8, reg_alpha: 0.1, reg_lambda: 0.1, random_state: 42, n_jobs: -1 } lgb_train lgb.Dataset(X_train, y_train) lgb_valid lgb.Dataset(X_valid, y_valid) model lgb.train( params, lgb_train, num_boost_round1000, valid_sets[lgb_valid], callbacks[lgb.early_stopping(100), lgb.log_evaluation(100)] )4.3 类别不平衡到底要不要处理车辆贷款违约率一般在10%-20%之间这个不平衡比例其实不算极端。但很多人一看到正负样本不均衡第一反应就是上SMOTE过采样或者随机欠采样我在这里要泼一盆冷水不要盲目做过多处理尤其是在用AUC做指标的时候。AUC关注的是排序能力不是绝对阈值。即使正样本只有10%模型也能得到不错的AUC。过采样和欠采样反而会破坏原始数据的分布可能引入噪声或丢失重要信息。我做过实验在这个赛题上SMOTE之后的AUC反而比原始数据训练低了0.01左右。更有效的方法有两个一是用scale_pos_pos_weight参数。LightGBM提供scale_pos_weight来给正样本加权计算公式是负样本数除以正样本数。如果违约率是15%那么scale_pos_weight约等于85/15也就是5.7左右。二是直接不处理类别不平衡把重点放在特征工程和调参上。很多情况下模型对不平衡的适应能力比我们想象中要强。但“不处理”不等于“完全不管”。如果最终业务要求你输出一个具体的违约概率阈值比如超过0.5就拒绝贷款那类别不平衡的问题就会暴露出来因为模型预测的概率会整体偏低。竞赛一般只看AUC不会卡阈值所以可以先不做特殊处理。我在实际比赛中先跑了一个完全不做类别处理的版本作为baseline再用scale_pos_weight版本对比发现AUC几乎没有变化最终选择了不加权版本避免引入额外的复杂度。4.4 模型融合用简单方法拿到稳定提升模型融合是竞赛提分的必经之路。最常用的方法是加权平均把LightGBM、XGBoost、CatBoost三个模型的预测概率按一定权重相加。权重的初始值可以按各模型单独提交的AUC比值来确定比如AUC高的模型给更高的权重然后在验证集上微调。另一种更轻量的融合是Ranking平均也叫排序平均。先把每个模型预测的违约概率转换成排名然后对排名取平均。这样做的优势是消除了不同模型概率分布尺度不一致的问题AUC指标天然关注排序所以排序平均往往比直接对概率值平均更稳健。我当时用LightGBM和CatBoost做排序平均AUC提升了约0.005这在竞争激烈的情况下已经算很大提升了。还有一种思路是做Stacking用第一层模型的输出概率作为第二层模型的特征。但Stacking在数据量小的时候容易过拟合还要额外维护一层验证方案收益通常抵不上复杂度。如果只是打比赛优先尝试加权平均和排序平均这两种简单方法。5. 常见问题与坑位实录5.1 数据泄漏最容易忽视却最致命的坑数据泄漏是我印象最深的坑。当时我在做特征工程时用全量数据包括训练集和测试集算了一个全局均值和标准差做标准化然后用这个统计量去处理训练集和测试集。当时验证集AUC显示0.83心里还挺高兴结果提交到线上实际分数只有0.76差了将近0.07。这就是典型的数据泄漏。你用测试集算的统计量会让模型的AUC在验证集上虚高因为验证集的信息已经在训练过程中被间接使用过了。正确的做法是先在训练集上fittransformer再transform训练集和测试集或者用类KF折分别计算每一折的统计量。from sklearn.preprocessing import StandardScaler scaler StandardScaler() X_train_scaled scaler.fit_transform(X_train) X_test_scaled scaler.transform(X_test)另一个容易被忽略的泄漏点是Target Encoding。类别特征用Target Encoding时需要用交叉验证来避免直接使用目标变量。如果简单地用全量数据的target均值去编码类别模型在验证集上的表现会虚高因为编码过程包含了验证集样本的标签信息。我当时用Target Encoding编码“职业”字段的时候差点掉进这个坑。时间泄漏也要留意。如果训练集和测试集来自不同时间段而你用测试集时间段内的信息构造特征比如用放款后30天内的行为数据判断违约这在真实业务里不可行在竞赛里更不可能。竞赛提供的数据基本都是静态快照不太会遇到这种问题但养成检查特征是否包含“未来信息”的习惯很重要。5.2 训练速度与内存优化LightGBM训练速度已经很快了但特征工程阶段如果构造了大量高基数类别特征内存消耗会很大训练时间也会明显上升。我记得当时不小心把“用户ID”直接当成特征放进了模型LightGBM立刻开始疯狂吃内存训练时间长到无法接受而且模型效果极差。ID类特征对泛化没有任何帮助必须在特征工程阶段就删除。train train.drop([user_id, loan_id], axis1)如果确实需要用到这类标识信息可以衍生出其他特征比如“该用户历史贷款次数”“该用户历史违约次数”等聚合统计但原始ID本身不能作为特征。5.3 提交格式与精度校验竞赛里因为提交格式错误丢分是最冤枉的。赛题要求提交测试集中每个样本的违约概率而不是预测类别。很多新手会直接把预测结果取整成0或1然后提交AUC直接暴跌到0.5左右。因为AUC只看概率排序取整相当于把所有概率变成了0和1两个值完全丢失了排序信息。result pd.DataFrame({id: test[id], prob: y_pred}) result.to_csv(submission.csv, indexFalse)提交前我会做几项检查检查CSV文件的行数是否等于测试集的行数检查是否有缺失值或NaN检查预测概率的范围是否在0到1之间检查提交前后的验证集AUC和线上AUC是否差距很大。如果验证集AUC是0.84但线上只有0.78说明存在数据泄漏或者过拟合需要回头检查特征工程和模型参数。5.4 复盘思考竞赛之外真正值得沉淀的东西打完这场比赛对我来说收获最大的不是排名而是对“特征工程是从业务理解开始的”这句话有了更深的体会。同样一份数据有人只能做LightGBM默认参数跑一遍拿0.72的AUC有人能在理解业务的基础上构造出贷款成数、还款压力比、时间间隔这类派生特征把AUC推到0.80以上。人跟人的差距不在模型技巧在于是否愿意花时间理解“这些数据到底在记录什么”。比赛是结束了但车辆贷款违约预测的思路完全可以迁移到其他金融场景。信贷申请评分卡、信用卡逾期预测、小微企业贷款违约预测本质上都是同一类问题给定一个申请人的静态信息预测他未来会不会违约。模型框架是通用的特征工程和数据处理思路也是相似的。唯一不同的是替换业务相关的字段即可。所以如果你已经跑完了这个赛题不妨举一反三找个消费金融的数据集再练一遍你会发现自己上手快了很多。最后再分享一个我个人的小习惯每次跑完一个特征工程版本我都会把特征列表、验证AUC、线上AUC、备注这四行信息记录在一个表格里。这样做的好处是避免重复劳动也方便回溯。哪怕过了几个月再回来也能很快知道哪种特征组合最有效。竞赛打到最后拼的就是谁更细致、更有耐心。本文还有配套的精品资源点击获取