机器学习驱动的借贷需求预测：从样本定义到特征工程的完整实践

简介面向机器学习学习者和金融风控从业者这份资料围绕京东平台借贷需求预测任务完整展示了从数据预处理、特征工程、模型选择到评估优化的实践流程。压缩包共8个文件以5个Python脚本为主覆盖LightGBM建模、特征生成、Stacking集成与线性模型融合等关键环节另附Markdown说明文档及特征设计相关表格整体仅575KB轻量且便于快速上手。目前已有223人学习下载适合作为入门级金融预测项目的代码参考。通过阅读和复现读者可以掌握缺失值清洗、特征筛选、交叉验证与指标评估等核心操作并将这套思路灵活迁移到自身的数据分析或借贷风控场景中切实提升机器学习落地能力。1. 京东借贷需求预测先说清楚“需求”到底是什么人工智能和机器学习被当成万能工具的背景下“京东借贷需求预测”真正难的地方不在模型结构而在于把“需求”这两个字从业务数据里剥出来。我第一次做这个方向时拿过去三个月的历史借款金额当标签训练回归模型交叉验证分数很好看策略团队一句话就把我问住了“你这模型测的是用户的需求还是我们给的额度”答案是后者。用户借不借、借多少由额度、利率、券、入口曝光共同决定历史借款是这些策略过滤后的响应不是需求本身。下面这套方案围绕京东借贷需求预测拆解机器学习落地的完整路径样本定义、特征构造、模型选型、指标设计以及上线阶段最常见的坑适合正在做电商消费金融、信贷需求预测、用户资金成长体系的数据科学团队。2. 把借贷需求拆成样本与特征定义、标签构造与特征体系2.1 样本定义从响应样本到潜在需求样本几乎所有需求预测项目的第一个分歧都发生在“哪些用户算有需求”。如果直接把“有额度且借过钱”的用户当正样本等于把授信策略当成上帝视角没额度的用户里也有大量观望者只是从来没有被触达过。我一般会将样本分成三层。第一层是响应样本即历史发生过借款的用户这部分标签最干净但只覆盖“被策略命中后产生反应”的人群。第二层是意愿样本用户在金融频道或借款产品页有过曝光、点击、测算额度、提额申请等行为但最终没有借款这类行为信号可以视为“有需求未被满足”。第三层是潜在需求样本直接从全量用户里抽样用特征预测未来 30 天是否会产生借款或提现行为。实际落地上我很少单独用某一层更多是把意愿样本作为主训练集响应样本作为校准集两个目标分开建模最后在融合层合并。这个设计的核心动机是需求预测模型最终要服务于资金供给、授信额度和营销触达如果只知道“给额度后谁借”就永远无法回答“该给谁提额、该给谁降利率”。因此标签定义本身就是把业务问题翻译成机器学习问题的第一步这一步错了后面所有特征工程都在为错误的信号添砖加瓦。2.2 标签构造从二分类到需求强度借贷需求不完全是“借/不借”的二分类更像一个强度。一个用户可能打开产品页五次、测了三次额度、绑了两张卡另一个用户只是被动收到一次推送两者未来 30 天的需求强度完全不同。构造标签时我会按用户在未来观察窗口内的行为深度给需求强度打分满分为 1.0只要发生借款则直接取最高强度未借款但发生深度行为则按行为层级赋予 0.3 到 0.8 的中间值。给一个我常用的打分规则未来 30 天内发生借款行为为 1.0发生提额申请或额度测算为 0.7发生借款产品页点击或金融频道签到为 0.4仅有曝光或推送到达为 0.1完全没有行为为 0。这套标签在“回归排序”双模式下都能用。直接回归时预测的是需求强度值做排序训练时把强度作为排序权重让模型更关注高需求用户。这个折中方案比硬做二分类要好用的原因在于它把业务里“到底算什么需求”的判断显式地写进了标签而不是让模型在黑匣子里自己猜。数据标注团队和算法团队也能基于这套规则对齐口径后续在特征和模型之间排查问题时多了一个可解释的中间变量。2.3 特征体系四类特征与一套落地代码需求预测的特征可以从四个方向铺开。第一类是用户静态属性性别、年龄、注册时长、会员等级、收货地址数量这些特征稳定且不会穿越用来刻画用户的基本盘子。第二类是电商消费行为历史订单金额、最近 30 天订单频次、品类分布、退款率、客单价趋势借贷需求往往在消费行为的波动里露出苗头比如某个月突然大额消费或者退款猛增。第三类是金融行为特征历史借款次数、额度使用率、历史借还款时间间隔、分期次数、理财持仓规模这类特征直接描述用户在金融侧的状态。第四类是时序统计特征围绕“窗口内均值、最大值、波动率、趋势斜率”做聚合例如近 30 天消费金额相对近 90 天的环比变化、连续三个月消费下降的月数。下面是一个用 Pandas 风格构造特征的需求预测代码骨架在实际生产环境里会换成 Spark 或 Hive 的窗口函数但字段口径是同一套。import pandas as pd import numpy as np def build_demand_features(user_base, order_daily, finance_log): df user_base.copy() # 用户近 30 天消费总额与近 90 天消费总额构造资金波动环比 order_30 order_daily[order_daily[date] 2025-03-01] \ .groupby(user_id)[order_amt].sum().rename(amt_30d) order_90 order_daily[order_daily[date] 2025-01-01] \ .groupby(user_id)[order_amt].sum().rename(amt_90d) df df.merge(order_30, onuser_id, howleft) df df.merge(order_90, onuser_id, howleft) df[amt_30d] df[amt_30d].fillna(0) df[amt_90d] df[amt_90d].fillna(0) df[consume_ratio_30_90] df[amt_30d] / (df[amt_90d] 1e-6) # 金融侧近 90 天额度测算次数与近期借款最长时间间隔 fin_agg finance_log.groupby(user_id).agg( cal_times_90d(is_cal_quota, sum), days_since_last_loan(loan_date, lambda x: (pd.Timestamp(2025-04-01) - x.max()).days) ).reset_index() df df.merge(fin_agg, onuser_id, howleft) # 标签窗口观察未来 30 天是否发生借款行为 df[demand_label] np.where( df[days_since_last_loan].notna() (df[days_since_last_loan] 0), 1.0, 0.0 ) return df代码逻辑先说清楚amt_30d和amt_90d分别统计用户近 30 天和近 90 天的消费总额consume_ratio_30_90的分子分母都加了一个极小值防止除零这个比率在 1 附近说明消费平稳远大于 1 说明近期突然花钱变多模型很容易从这里学到“资金缺口信号”。cal_times_90d统计的是用户主动去测算借款额度的次数这是比点击更深的意图信号。days_since_last_loan用 lambda 里的最大借款日期与当前日期做差得到最近一次借款距今多少天这个字段对“借完短期又急用钱”的用户很有区分度。这里有两个参数需要注意。第一窗口长度的选择我一般以 30 天为需求观察窗口、90 天为特征回溯窗口这个组合在多数电商借贷场景下表现不错如果产品是长周期现金贷可以把回溯窗口拉到 180 天。第二日期必须严格以“用户行为发生的自然日”为准不能把标签窗口里的行为统计进特征否则就是典型的特征穿越。上面代码中特征用的截止日期是 2025-04-01标签也以这一天为起点往后看 30 天生产环境里建议把这个日期做成参数每次训练推进一个自然日。2.4 特征口径上线后的第一条红线特征体系搭建好只是第一步口径一致才是上线后最容易被反噬的地方。离线特征计算通常用 Hive 按天跑批线上服务是实时接口两者的差异一旦变大离线评估多么漂亮都白搭。常见的红线有三条时间戳必须统一到用户所在时区金额字段必须统一币种与分单位缺失值处理逻辑在离线和在线两套代码里必须完全一致。我一般会在特征代码里强制加入一个字段清单文件每个字段注明名称、类型、缺失值填充规则、回溯窗口、来源表用脚本在每日训练前对比线上特征和当前离线特征表是否存在新增枚举值或字段漂移。这个过程听起来琐碎但需求预测模型的性能天花板往往不在模型结构上而在这些没人注意的口径细节上。提示特征口径核对建议做成每日自动任务而不是靠上线前人工检查。等到线上推理分数分布明显变化时再回头查成本往往是提前检查的十倍。3. 用机器学习模型拟合需求LightGBM 为主、深度学习为辅的实战配置3.1 模型选型为什么表格型数据上 GBDT 仍然最稳借贷需求预测的特征经过汇总后大部分是稠密的数值型或低基数的枚举型这类表格数据在工业界的默认选择仍然是 GBDT 系模型而不是深度学习。原因有三点。其一需求预测的特征量级通常在几十到几百LightGBM 对特征数值范围不敏感不需要做标准化省掉一个容易出错的环节。其二GBDT 对缺失值有原生策略用户行为特征缺失本身就是一个有意义的信号很多新用户没有历史数据直接把缺失交给树模型处理远比填充一个固定值合理。其三特征重要性输出对业务团队友好信贷方向天然需要解释性额度调整和利率策略不能只靠一个说不清楚的黑匣子。模型类型优势劣势适用场景LightGBM / XGBoost缺失值友好、特征工程成本低、自带可解释性对高维稀疏行为序列信息利用率低表格式特征为主的需求强度回归、线上低延迟场景LSTM / Transformer能编码订单序列、借款间隔等顺序信息预处理复杂线上需部署序列服务特征体系含长时间序列、样本量百万级以上线性回归 / 逻辑回归稳定、易排查、可快速上线无法处理非线性交互基线模型、新用户冷启动快速回退方案机器学习算法选型时经常有人一上来就上 Transformer但需求预测这种以聚合特征为主的任务深度学习的增量并没有想象中大。深度学习的机会主要出现在行为序列上。如果特征体系里保留了用户近 90 天的订单金额序列、还款时间序列用 LSTM 或 Transformer 编码这一段序列再把序列向量拼接到 GBDT 特征表里通常能带来 2% 到 4% 的 AUC 提升。但这个增益不稳定序列越长数据量要求越高而且线上推理要维护一个序列服务成本和收益要算清楚。我一般先跑一个纯 GBDT 基线再看序列挖掘是否有剩余价值不默认深度学习。3.2 最小可跑通的 LightGBM 配置下面的代码是一个基础但完整的需求预测训练流程覆盖切分、训练、评估三个环节。数据落到feature_df后把特征列和标签列分离用日期按前松后紧切分避免随机切分造成的时间泄漏。import lightgbm as lgb import numpy as np from sklearn.metrics import roc_auc_score, mean_squared_error feature_cols [consume_ratio_30_90, cal_times_90d, days_since_last_loan, member_level, register_days, order_freq_30d, refund_rate_30d] train feature_df[feature_df[date] 2025-03-01] valid feature_df[(feature_df[date] 2025-03-01) (feature_df[date] 2025-04-01)] lgb_params { objective: regression, metric: mae, learning_rate: 0.05, num_leaves: 63, max_depth: 7, min_child_samples: 50, feature_fraction: 0.8, bagging_fraction: 0.8, bagging_freq: 1, lambda_l2: 1.0, verbose: -1, } dtrain lgb.Dataset(train[feature_cols], labeltrain[demand_label]) dvalid lgb.Dataset(valid[feature_cols], labelvalid[demand_label], referencedtrain) model lgb.train( lgb_params, dtrain, num_boost_round500, valid_sets[dvalid], callbacks[lgb.early_stopping(50), lgb.log_evaluation(50)] ) valid[pred] model.predict(valid[feature_cols], num_iterationmodel.best_iteration) print(auc:, roc_auc_score(valid[demand_label] 0.3, valid[pred])) print(rmse:, mean_squared_error(valid[demand_label], valid[pred], squaredFalse))参数说明要拆开讲。objective用regression而不是binary是因为需求标签是 0 到 1 的强度值二分类目标会丢掉中间层的行为强度信息。metric用mae因为需求强度分布严重偏斜大量 0 值会让 MSE 对高需求用户不敏感。num_leaves设为 63 同时max_depth为 7是让树保持中等复杂度需求预测的特征里有许多相关性强的消费指标叶子过多容易学出局部抖动。feature_fraction和bagging_fraction都设为 0.8让每棵树看到的特征和样本不完全一致减少列与列之间的共线性影响。min_child_samples设 50防止高需求用户占比太低时被树当成噪声。lambda_l2设 1.0 做正则表格型特征在样本量几百万时很容易过拟合到一两个强特征。切分逻辑上我用date字段做时间切分而不是随机切分因为需求预测本质是时序任务。验证集取 3 月到 4 月训练集截止到 3 月之前模型从没见过验证集时段里的任何信息。如果你手头的数据跨了多个促销周期建议把验证集扩到两个月避免只验证一个平淡月份。3.3 评估指标AUC 不够还要看业务加权覆盖率需求预测模型上线后业务方最常问的问题是“你预测的需求总和和实际到底差多少”。AUC 回答不了这个问题还需要两个视角。第一个是总量视角把验证集按预测分数从高到低排序取前 10% 用户的需求预测总和除以他们实际需求总和得到 Top10 覆盖率这个指标直接反映资金供给的命中效率。第二个是分布视角看不同需求强度区间上的平均误差如果 0.7 以上的高需求档位误差特别大说明模型对强需求用户的区分能力不足。更严格的做法是直接换损失函数用分位数损失替代 MAE。分位数回归输出的是预测区间的上界和下界而不是一个点估计值。业务上这相当于告诉资金运营团队未来 30 天这批用户的需求量大约在 7.2 亿到 8.8 亿之间比一个孤零零的 8 亿要更有决策价值。LightGBM 支持自定义目标函数我在实际项目中验证过上线后同等业务阈值下资金计划达成率的波动明显变窄。3.4 深度学习补充的触发条件加入序列模型前需要先算一笔账。触发条件通常有三个用户行为序列的覆盖率达到 80% 以上样本量超过 500 万纯 GBDT 的 Top10 覆盖率已经连续两个版本没有提升。三个条件缺一个就不建议上序列模型因为序列特征服务的在线延迟维护成本远超离线训练成本。如果决定引入常见路线是先做“序列特征离线抽取在线缓存”用 LSTM 对订单金额序列和间隔天数序列各走一路编码拼接到 GBDT 的高层特征中。这时候千万不要把序列模型输出直接作为最终预测值而是当作一张新特征表喂给树模型树模型会自行决定这条序列信息的权重。实测这种方式比端到端深度学习更稳定也更容易排查线上问题。4. 需求预测模型上线最容易踩的 5 个坑现象、原因与解法4.1 特征穿越离线 AUC 0.85线上预测全面失灵现象模型在离线验证集上 AUC 达到 0.85RMSE 也明显优于旧模型上线一周后发现预测的需求总量比实际高出 30% 以上策略团队直接回滚模型。原因特征里混进了标签窗口内的信息。最常见的是“近 30 天是否借款”这类本应作为标签的字段被同时当成特征或者时间窗口没有严格截止到训练日把未来 7 天的订单数据统计进了特征。树模型对这种泄漏极其敏感因为泄漏特征的区分度远高于正常特征会迅速成为主导分裂点。解决把特征计算和标签计算拆成两个独立脚本用同一份日期参数控制窗口边界。训练前跑一个泄漏自检把每个特征与标签做单变量相关性排序相关性高于 0.3 且业务上解释不通的字段一律排查。更机械的办法是把特征表里的日期逐列打印出来人工核对每列的最大日期是否在训练日之前。这个检查要写进自动化流水线里靠人去记永远会漏。4.2 标签污染模型学到的是额度策略不是用户需求现象模型分数高的人群和当前授信策略推荐提额的人群高度重合业务方觉得“这模型不过是把现有策略复述了一遍”。原因直接用历史借款行为做标签等于把授信策略对用户的筛选结果当成真值。额度高、利率低的用户借款概率天然高模型学会的是复刻策略而不是识别那些策略给不到但确实有需求的人。解决按前面讲的标签构造思路把无授信但有过产品页深度行为的人群纳入训练。如果历史数据里这类样本太少可以用机会样本加权法给有授信用户乘以小于 1 的权重给无授信但有行为用户乘以大于 1 的权重强制模型去关注那些被策略筛掉的需求。上线后还要持续监控“提额后借出率”是否高于旧模型这是判断模型是否真正找到增量需求的关键指标。4.3 周期性事件缺失大促和发薪日前预测值系统性偏低现象每月 10 日和每月 20 日前后、大促期间模型预测的需求总量与实际借款量偏差最大其他时间段误差正常。原因需求预测模型没有把周期性事件作为显式特征。用户借钱的高峰往往对应消费大促、还信用卡日、发薪日附近这些事件在时间窗口类的统计特征里不像普通行为那样平滑模型无法从均值里推断出峰值。更深层的原因是训练集中这类特殊日期数量太少模型把它当成噪声。解决在特征表里显式加入“距离上次大促天数”“距离下次大促天数”“本月是否发薪周”“是否信用卡还款日”等日历类特征并保持一个足够长的时间跨度让训练集覆盖至少两轮完整的大促周期。另外对特殊日期的样本可以适当加权重或者单独训练一个节假日修正模型用它对主模型的预测值做乘法修正。我在实际项目里用后一种方式将大促当天的预测偏差从 25% 压到了 8% 以内。4.4 新老用户特征分布差异同一套参数对老用户好用、对新用户失效现象分群评估时老用户组的 Top10 覆盖率在 85% 以上新用户组只有 40% 左右新用户需求被严重低估。原因新用户没有历史消费和金融行为特征大量缺失模型在训练时把缺失值默认导向低需求相当于“没数据就被判定为没需求”。而新用户恰恰是借贷需求预测最需要提前触达的人群这个偏差直接削弱模型在增长场景中的价值。解决不要把所有用户塞进同一个模型。我一般按“是否有历史借款记录”分成两个入口新用户单独训练一个模型特征只用注册时长、注册渠道、首单品类、设备信息、地区等静态特征并且把缺失值填充为众数而不是 0避免进一步放大“无行为等于无需求”的偏见。如果样本量不够单独建模也可以在 GBDT 里对缺失值特征增加一个分组节点让缺少历史数据的用户自动落到独立的子树分支而不是被默认值推向低需求方向。4.5 离线线上特征口径漂移评估指标稳定线上分数分布却缓慢偏移现象模型刚上线两周评估指标正常之后每天都变化一点点突然某天线上预测分布整体右移业务侧报警。原因离线特征用 Hive 按 T1 跑批线上接口用的是实时特征缓存两套代码的时间窗口、缺失值填充规则、单位换算不一致。比如离线代码里金额统一用分存储线上接口返回的是元这个量纲差异会导致树模型分裂阈值整体改变预测分布随之漂移。解决在特征平台里做统一的特征计算服务离线批量计算和在线实时计算共用同一份计算逻辑代码通过传入的时间参数来区分计算时机。每次发布新特征时必须同时发布离线和在线两套适配代码并且在灰度期间每日对比离线特征快照和线上实时特征的平均值、分位数、缺失率。一旦发现差异超过预设阈值我通常设 5%立即暂停新特征流量退回旧版本。5. 预测结果怎么验证时间序列交叉验证与反事实回测5.1 用滚动窗口验证时间序列交叉验证替代随机切分随机切分在时序任务里几乎必然高估模型效果因为训练集里包含了验证集时间之前的局部信息模型在“未来”上做预测等于拿到了部分答案。我习惯把前面单次时间切分扩展成滚动窗口以 30 天为步长每次把训练集起点向后推进 30 天得到多折数据每折单独评测 Top10 覆盖率和分位数损失。最后看多折指标的均值与波动范围而不是只盯着一个静态验证集。这样能暴露模型在促销周期、季节变化下的稳定性也能及时发现某个时间段的单点失效。5.2 反事实回测策略变了模型预测还准吗需求预测模型上线后最大的验证缺口是反事实场景。比如信贷策略团队在某一天将最低额度从 3000 元降到 1000 元同一个用户群的需求总量在策略前后一定不同但模型应该捕捉到的是“用户在额度降低后借款意愿反而更强”还是“需求总量被额度压制”。我的做法是把历史上策略明确变动的日期标记出来将模型预测值与实际值按策略变动前后分段画趋势线。如果误差在策略变动点发生断崖式变化说明模型仍然在学策略而不是学需求需要回到标签构造重新审视。如果误差保持平稳说明模型已经捕捉到用户需求层面的稳定信号这比任何离线指标都更可信。5.3 更受业务欢迎的输出分位数区间预测实践里还有一个被低估的技巧把点预测换成区间预测。用 LightGBM 自定义分位数损失分别训练 0.1、0.5、0.9 三个分位模型输出时把三个结果拼成“低、中、高”三段预测区间。资金运营团队看到的是一个带宽而不是孤零零的点可以将区间底部作为保守资金计划值、区间顶部作为弹性资金准备值决策的容错空间明显变大。我在多次需求预测项目里验证过区间预测带来的额外增益不是模型精度而是业务信任度。我自己在每一次需求预测项目里都会把“日期窗口泄漏”作为第一优先级的检查项因为它造成的错误最隐蔽、后果最严重。如果拿到一个新的业务场景也建议你先从标签审计开始再多精彩的特征和模型都无法修正一个被污染的真值。希望这个方案能帮你在做同类需求预测时少走几轮弯路。本文还有配套的精品资源点击获取