PPD拍拍贷风控大赛数据集全流程复盘:从表格数据到风控模型

发布时间:2026/9/2 3:15:27
PPD拍拍贷风控大赛数据集全流程复盘:从表格数据到风控模型
简介拍拍贷风控大赛数据集是一份面向金融风控建模学习与竞赛实战的数据包适合数据科学初学者、信贷风控从业者及参加科赛类比赛的研究者。压缩包共176个文件主要包含csv训练集和日志数据、ipynb分析脚本、xlsx字段说明、png/jpg可视化图以及html/js/css展示页面整体大小37.37MB便于快速下载和本地建模。目前已有1120人学习下载。数据涵盖借款人基本信息、借款历史、信用评分、行为日志等维度可围绕特征工程、模型训练、AUC评估与风险策略进行完整演练包内PPD_Training_Master_GBK_3_1_Training_Set.csv、PPD_LogInfo_3_1_Training_Set.csv等文件还原了赛题主表与日志表结构配合ipynb脚本可快速上手数据清洗和基线模型搭建针对高风险识别可尝试逻辑回归、随机森林、神经网络等模型并结合AUC-ROC、精确率、召回率等指标评价效果帮助读者复现风控建模全流程并积累实战经验。 很多年前我下载到这个 ppd 拍拍贷风控大赛数据集时内心还带着一丝“拿到真实业务数据就能起飞”的错觉。解压完那个 .7z 之后面对一堆 CSV我很快意识到这个赛题的价值不在于数据集本身有多神秘而在于它把金融风控里面最典型的表格数据建模流程完整摊开了有借款标的信息、用户画像信息、历史行为信息还有明确的二分类目标和线上评估口径。对于想进入数据科学、机器学习方向的人来说它几乎是练习商业表格数据建模最好的起点之一。这篇文章我会围绕这个数据集的完整使用路径做一次详细复盘从解压数据到特征构建、模型验证和调优尽量把每一步为什么要这样做讲清楚。需要先说明的是数据字段细节在不同来源版本里会有差异如果你拿到的文件结构不完全一致思路照样可以复用。1. 解压 .7z 之后数据表结构与赛题目标确认1.1 压缩包里到底有什么用 Windows 环境下 7-Zip 工具解压后目录里通常会有若干张 CSV 表。不同来源的字段命名可能略有差异但大体上逃不出这几类借款列表信息、用户基础信息、用户信息更新记录、用户历史借款行为记录。我用一个表来概括最常见的角色数据角色典型字段主要用途借款列表主表借款ID、用户ID、借款金额、借款利率、借款期限、借款评级构成样本主体每个借款订单对应一行用户基础信息性别、年龄、学历、工作年限、婚姻状况、房产/车产情况描述借款人基本画像用户资料更新更新字段、更新时间、更新前/后值刻画用户信息稳定程度历史行为记录历史借款、还款、逾期记录、额度使用情况计算用户历史还款能力和意愿第一次拿到数据时我最想提醒的一件事是先确认每张表的粒度。比如借款列表主表里面一行到底是一笔借款还是一个用户有的脱敏版本会把同一用户的多次借款合并到一行有的版本则保留每一笔独立借款。这个粒度直接决定你后续怎么合并数据也决定标签怎么构造。建议先用df.shape和df[user_id].nunique()把样本数和用户数统计出来再动手做特征。读 CSV 时也容易踩编码的坑。这个数据集的 CSV 有时候并不是默认的 UTF-8 编码直接pd.read_csv会报 UnicodeDecodeError。我通常这样处理import pandas as pd df_list pd.read_csv(ListInfo.csv, encodinggbk)如果 gbk 也报错就加enginepython或者encodinggb18030。这种编码细节听起来很小但卡住新手半小时也很常见。1.2 赛题目标与评估口径在动手写任何模型之前先把任务和目标确认下来。典型任务是二分类预测借款人是否会发生逾期或违约。标签通常是一个 0/1 字段比如是否逾期超过某个天数。这个“超过某个天数”的定义非常关键它决定了你建模的到底是早期逾期风险还是坏账风险两种标签对应的特征重要性很可能完全不同。另一个要确认的是评估指标。拍拍贷风控大赛这类比赛线上常用 AUC 作为排序能力指标有时也会关注 KS。如果线下复现时没有和线上完全相同的口径调参调到最后很可能是在自嗨。我见过不少人线下用准确率调出一套“完美”参数一上线下发现 AUC 纹丝不动因为线下关注的根本不是同一个东西。所以第一步就应该明确目标列是什么、正样本定义是什么、评估用哪个指标。2. 数据清洗里最容易翻车的三个地方2.1 缺失值不是非填不可很多人在拿到表格数据后有一个惯性动作对缺失值先 fillna。但在风控场景里某个字段缺失本身就可能包含信息。比如年龄缺失率高你用均值填充所有缺失样本的年龄都变成同一个中年数值特征区分度直接归零更合理的做法是填充中位数并额外加一列“年龄是否缺失”的 0/1 标记让模型自己去决定这个缺失信号有没有用。借款评级这类业务字段如果缺失可能代表该笔借款没有进入完整审核流程或者信息不完备。这种情况下缺失并不是随机发生的可以单独作为一个类别处理。缺失值处理的核心原则不是“把洞补上”而是“保留缺失的结构化信号”。我不建议在这一步对连续变量做过于复杂的插补比如多重插补或者 KNN 插补。树模型对缺失值本身就有一定的容忍能力LightGBM 和 XGBoost 在训练时会自动学习缺失值的最优划分方向。你花大力气插补出来的数据对树模型线下指标的提升往往非常有限反而增加了代码复杂度和过拟合风险。2.2 时间穿越最隐蔽的过拟合这个坑我付出过不小的代价。金融风控数据天然带时间维度每一笔借款都有申请时间每一个用户行为都发生在某个时点。在构造历史行为特征时很容易犯一个错误用样本点之后的“未来数据”去预测样本点本身。举一个具体的例子。如果你想构造“用户历史逾期总次数”这个特征正确做法是只统计该笔借款申请时间之前已经发生的逾期记录。如果不做时间截断把用户全量历史逾期记录都统计进去那就等于把未来要发生的事提前告诉模型。这样做线下 AUC 会异常漂亮但一旦到了真正预测未来样本的场景准确率立刻崩塌。我当时的处理方式是对于每个训练样本根据借款申请时间对历史行为表做条件过滤只保留behavior_time apply_time的记录再做聚合。虽然代码跑起来慢了一些但至少保证了特征在时间上不泄漏。判断一个特征是否时间穿越可以问自己一个问题如果我现在站在这个借款人申请借款的那一刻这个字段的值我能知道吗如果答案是不能这个特征就不应该出现在模型里。2.3 表合并时的行数膨胀与标签泄漏把多张表合并到一起时最常见的低级错误是行数膨胀。比如用户基础信息表一个用户只有一行但借款列表表一个用户有多笔借款直接merge没问题因为用户表被扩到借款粒度。但如果你在用户表和借款表之间又合并了一张历史行为明细表而历史行为明细表本身又是一个用户多条记录那么结果行数会瞬间翻好几倍样本不再是原来的一行一借款。检查方法很简单每次合并后都打印一下len(df)如果比合并前的主表行数多就要想清楚是逻辑上的多发生在哪。按用户聚合历史行为后再 join 回来一般可以避免这个问题。多对多合并是最危险的因为看起来行数暴增但业务上完全讲不通。标签泄漏也是风控建模里不得不防的。有些字段和标签有直接因果联系比如“催收次数”“当前还款状态”这类信息本质上已经是结果的一部分不能作为训练特征。我在初期建特征时会把所有字段列出来逐个问这个字段是在借款申请时就确定了的吗如果它依赖于借款之后发生的事就坚决不加进模型。3. 特征工程的主线从用户历史行为到风险画像3.1 借款标的维度特征借款列表本身的信息是最直观的特征基础。借款金额、借款利率、借款期限、借款评级这几个字段每一个单独看都对风险有解释力借款人借的金额越大、利率越高可能说明其资金需求越急迫或信用状况越一般期限越长不确定性越大评级则是平台内部风控给出的一个综合评分往往是强特征。除了直接使用这些字段我还做了一些交叉和变形比如借款金额与借款期限的比值可以理解成月供压力借款评级与利率的组合比如“高评级高利率”这种异常组合可能意味着数据录入异常或特殊业务场景借款金额的 log 变换连续变量在树模型里不一定需要但偶尔能让特征更平滑。这一步我通常不做太多花活重点是把原始字段理解透再考虑分箱和交叉。3.2 用户历史行为聚合特征历史行为是金融风控里最有信息量的特征来源。一个用户的还款记录、逾期记录、借款频次直接反映了还款能力和还款意愿。我用groupby按用户聚合常用统计量包括agg_dict { loan_id: count, # 历史借款总笔数 loan_amount: [sum, mean, max], # 历史借款总额、均值、最大单笔 overdue_days: [sum, mean, max], # 历史逾期天数总和、均值、最大 } user_feat history_df.groupby(user_id).agg(agg_dict) user_feat.columns [_.join(c) for c in user_feat.columns]这类聚合特征通常会在特征重要性排行里排到前面尤其是“历史逾期次数”“历史最大逾期天数”这种直接刻画用户信用污点的字段。除了全量聚合我还会加时间窗口特征比如近 3 个月、近 6 个月的借款笔数和逾期情况。窗口太长会和全量统计重叠窗口太短又会带来大量零值稀疏特征我一般会先算全量再挑一两个业务上说得通的窗口做增量。窗口特征能捕捉近期资金紧张程度同一个用户如果近期高频借款通常意味着还款压力在增大。3.3 认证与授权信息容易被忽略的强特征在互联网金融场景里实名认证、手机认证、视频认证、银行卡认证这类“认证类特征”往往很有区分度。认证数量越多说明用户通过了越多的核验环节欺诈风险相对更低。把认证方式做成一个计数特征或者把每一种认证做成 0/1 稀疏列都能给模型提供稳定信息。另外用户信息更新频率也是我后来才注意到的点。正常的借款人不会频繁修改自己的手机号、工作单位或居住地址频繁修改个人信息可能意味着用户信息不稳定甚至存在伪装身份的嫌疑。可以从用户更新记录表里统计“近 X 个月内更新次数”“最近一次更新距今的天数”“更新字段类型数”等。这类特征不需要复杂计算但对识别异常用户有奇效。4. 模型选型与验证策略单靠默认 XGBoost 远远不够4.1 为什么树模型在这个场景是主力表格数据上树模型依然是性价比最高的选择。原因主要是风控特征之间通常是非线性关系树模型天然适合捕捉这种非线性表格特征里缺失值多、离散值多树模型不需要对缺失值做复杂处理训练速度上 LightGBM 比传统 GBDT 快很多调参迭代效率高。神经网络在这个任务上不是不能用但想超过树模型需要更强的特征工程和调参功底。对于大多数刚接触风控数据的人来说从 LightGBM 或 XGBoost 起步是最稳妥的路径。如果追求稳健可以先把这两个模型都跑一遍基线再考虑融合。4.2 验证集的切分方式随机还是按时间验证集切分方式直接决定你评估出的指标可不可信。最容易被忽视的问题是同一个用户的多笔借款记录如果被随机分到了训练集和验证集就存在用户级的信息泄漏。模型在训练时见过这个用户的其他借款行为验证时候等于遇到了“半熟”样本指标会虚高。我建议至少按user_id分组切分保证同一个用户的所有借款要么全在训练集要么全在验证集。更贴近真实线上场景的是按时间切分比如用前 80% 时间的样本训练后 20% 时间的样本验证。时间切分的缺点是如果某一时间段外部环境变化太大评估方差会比较大。比赛环境通常用随机切分更多但如果你要评估模型上线后的真实表现时间切分更有参考价值。4.3 样本不均衡与评估指标金融风控数据集的正样本占比通常非常低可能只有 2% 左右。这意味着即使模型什么都不学把所有样本都预测为负样本准确率也能到 98%。所以准确率在这个场景下毫无意义你应该关注 AUC、KS 这类排序指标。训练时我习惯给少数类加权LightGBM 的scale_pos_weight参数可以直接设置通常是负样本数除以正样本数。这个值过大可能会让模型过于激进地输出高违约概率导致 KS 下降过小又可能学不到正样本的模式。我在调参时会把scale_pos_weight作为超参之一配合早停一起搜索。5. 一次调优记录从 0.71 到 0.74 的踩坑复盘5.1 第一版基线与第一次特征增补我先用最朴素的字段跑了 LightGBM 基线借款金额、利率、期限、评级、用户年龄、学历等参数基本默认线下五折 AUC 大约 0.71。这个基线虽然不高但验证了整个数据管道是通的标签和特征对齐没有问题。第一次特征增补我加了用户历史行为聚合特征和认证类特征AUC 从 0.71 提升到 0.72 左右。这个过程让我确认了历史行为和认证信息才是这个数据集里最有信息量的部分基础画像特征反而贡献有限。5.2 时间穿越特征带来的虚假提升紧接着我犯了一个典型错误。在构造用户历史逾期类特征时我一开始图省事直接用全量历史行为表做聚合没有按借款申请时间做截断。结果线下 AUC 直接飙到 0.79。当时我还开心了一下以为发现了什么关键特征。冷静下来之后我检查了特征构造代码发现自己把借款之后才发生的逾期记录也统计进去了。这个特征在训练时看起来无所不能但实际上泄漏了未来信息。我把时间截断逻辑修正后重新训练AUC 回落到 0.73 左右。这个 0.79 到 0.73 的落差让我记住了“时间穿越是所有风控建模里最坑的问题”这句话。之后我每次构造历史行为特征都会强制加入时间筛选条件并且用特征重要性里的“可疑高分特征”反向排查是否有泄漏。5.3 参数调整与最终效果在修正了时间泄漏之后我开始系统调参。主要方向是降低学习率、增加迭代轮数配合早停防止过拟合。比较有效的一组参数大致是lgb_params { objective: binary, metric: auc, learning_rate: 0.03, max_depth: 6, num_leaves: 31, scale_pos_weight: 10, feature_fraction: 0.8, bagging_fraction: 0.8, bagging_freq: 1, verbose: -1, }把learning_rate从 0.1 降到 0.03配合n_estimators提升和早停AUC 稳定在 0.74 附近KS 也到了 0.35 左右。为了提升一点稳定性我还把五折交叉验证的均值作为最终评估结果。再往后尝试过一些复杂操作包括特征选择、模型融合、样本采样收益都没有特别大。最终排名并不算靠前但整个过程让我把风控表格数据的完整链路走通了。6. 这个数据集还能用来做什么边界与扩展6.1 一个完整的竞赛闭环学习样本这个数据集最大的价值是给你提供了一个完整的闭环数据清洗、合并、特征工程、模型训练、验证、调优、复盘。你可以按照比赛流程走一遍也可以把它当作练习自动化建模工具的标准数据集。比如用 Optuna 做参数搜索、用 SHAP 做特征解释都挺合适。它和 CV、NLP 数据集不一样的地方在于没有现成的图像或文本完全是业务表格数据。这种数据更考验对业务逻辑的理解能力而不是算力。很多时候你花时间做的特征比换一个更复杂的模型提升更大。6.2 用表格数据验证新模型和工具如果你在研究新的表格模型架构或特征处理工具这个数据集也是一个不错的测试场。它包含类别特征、数值特征、缺失值、时间维度、样本不均衡等问题比纯随机生成的数据更能反映真实场景的复杂度。另外这类风控建模思路也不只局限在金融领域。日常遇到的账号安全风控、异常交易检测、注册欺诈识别等场景本质上还是在做同一件事用用户历史行为数据判断当前这个事件是正常还是异常。你在这个数据集上学到的“先确认时间边界、再构造行为特征、最后建模评估”的流程完全可以迁移过去。回头看这个数据集我最大的收获不是最终排名而是它让我养成了一个习惯在建模前先确认数据的时间边界和业务含义。我现在每次拿到一个新的数据源都会先问自己一句这一列数据在预测时刻真的知道吗你把这个习惯养成了再回头处理其他风险建模或者表格型业务数据会顺手很多。本文还有配套的精品资源点击获取