复购预测与LightGBM特征工程：从行为日志到高AUC的完整路径

简介这是一份基于阿里天池大赛学习赛的天猫复购预测案例资源使用Python实现面向正在准备期末大作业或课程设计的学生完整覆盖数据获取、特征工程、模型训练与预测评估等环节代码注释详尽新手也能快速上手是冲刺高分的一份参考。资源包共8个文件大小仅4.64MB包含3个Python脚本数据处理、训练、测试、数据下载说明、项目文档、特征重要性可视化图、训练好的模型文件及预测结果CSV结构紧凑轻量易部署无需复杂环境即可快速复现。目前已有1250人浏览学习同类资源中关注度较高。借助这份资源可以复用数据预处理与特征提取思路结合特征重要性排序辅助调优加载现成模型直接评测再配合高分文档理解完整建模流程适合快速复现赛题方案并迁移到同类预测任务中。1. 天猫复购预测看起来是二分类翻车点全在特征工程里很多人拿到阿里天池学习赛的“天猫复购预测”源码包第一件事就是把 LightGBM 的默认参数直接怼进训练集本地 AUC 跑到 0.75然后对着验证集发呆不知道下一步该干什么。原因很一致复购预测的标签虽然是一个二分类问题但正负样本比可能低到 1:20 甚至更夸张而且原始数据全是用户行为日志不是已经对齐好的表格特征。这个赛题真正吃掉分数的不是模型而是把行为日志变成特征的那条流水线。这套源代码加文档说明的价值恰恰在这里。它给的不是一个“调参神话”而是一条完整的、从原始日志走到提交文件的路径样本怎么定义、负样本怎么采、滑窗特征怎么做、验证集怎么切、提交格式怎么摆。适合两类人一是想在天池学习赛上拿一个像样分数的入门选手二是做用户增长、复购分析想看看经典复购预测是怎么用代码落地的数据从业者。2. 先做对样本定义从行为日志构造“是否会复购”标签2.1 用 pandas 读原始行为日志先确认三件事拿到数据之后第一件事不是跑模型而是确认三个基础信息行为日志有哪几列、时间跨度是几天、行为类型有哪些取值。天池这个复购预测赛题提供的是脱敏后的用户行为日志核心字段一般是 user_id、sku_id具体商品、brand_id品牌、cate_id商品类目、行为时间戳外加一行行为类型常见取值是点击、加购、收藏、购买。不同版本的代码包列名可能略有出入文档说明里会写清楚字段定义这比对着列名猜靠谱得多。import pandas as pd # 读取行为日志时间戳统一转成天粒度 df pd.read_csv(user_log.csv, parse_dates[time_stamp]) df[day_index] (df[time_stamp] - df[time_stamp].min()).dt.days # 确认字段、行为取值分布、时间跨度 print(df.dtypes) print(df[action_type].value_counts()) print(时间跨度/天:, df[day_index].max() - df[day_index].min() 1) print(用户数:, df[user_id].nunique()) print(商品数:, df[sku_id].nunique())这段脚本的目的很直接先确认列名和取值再确认时间跨度。复购预测和普通分类不一样特征全部来自行为日志如果日志跨度只有 30 天“近 7 天行为”这个窗口覆盖的用户比例和 90 天日志是完全不同的跨度足够长时间衰减特征才会真正发挥作用。另外注意 action_type 的取值分布购买行为通常远少于点击行为如果购买占比不到 5%后面构造“购买转化率”时就要先对购买行为单独做聚合而不是把所有行为混在一起算总数。提示脱敏 ID 不要试图还原成真实用户或商品。赛题给出的 ID 是随机映射过的把这类字段当 category 处理就好。2.2 构造复购标签预测窗口内买过算 1没买算 0接下来是标签定义。复购预测的训练集和测试集在时间上是截断的赛题会给出一个预测起始日期要求预测这个日期之后若干天内哪些用户会再次产生购买行为。样本单位是 user_id而不是 user_id 加 sku_id标签是二值预测窗口内买过至少一次算 1一次都没买算 0。有些新手会把“用户 A 买了商品 X 之后又买商品 Y”当成一条样本来预测这是把任务理解偏了复购预测关心的是用户这个人会不会回来不是某件具体商品。# 假设预测窗口起始日期是 train_end_date 1窗口长度 15 天 start_date train_end_date pd.Timedelta(days1) end_date start_date pd.Timedelta(days15) buy_log df[df[action_type] buy] buy_in_window buy_log[ (buy_log[time_stamp] start_date) (buy_log[time_stamp] end_date) ] buy_users set(buy_in_window[user_id].unique()) all_users set(df[user_id].unique()) label_df pd.DataFrame({ user_id: list(all_users), label: [1 if u in buy_users else 0 for u in all_users] }) print(正样本数:, label_df[label].sum(), 负样本数:, (label_df[label] 0).sum(), 正样本占比: %.4f % label_df[label].mean())标签必须只由预测窗口内的购买行为决定不能把观察期内的购买也算进去。同一份行为日志里观察期用来构造特征预测期用来打标签二者在时间上不能重叠否则就是特征穿越本地 AUC 虚高、提交立刻打回原形。另一个细节是如果赛题已经给了训练集和测试集的原始划分直接从训练日志里提取标签就行如果没给就要靠文档说明里的边界日期自己切切错一天整个模型的线下验证都失去意义。2.3 为什么 AUC 是主指标它决定了你能容忍什么样的负采样天池这个赛题用 AUC 作为评估指标这直接改变了样本设计的方式。AUC 衡量的是模型给正样本打分高于负样本的概率它只关心所有样本的相对排序不关心预测概率的绝对值。于是负采样比例对 AUC 的影响相对有限只要采样没有系统性改变正负样本在特征空间里的分布AUC 基本能稳住。这个性质带来三个实践结果第一可以放心对负样本采样训练集正负比压到 1:1 到 1:5训练时间大幅缩短第二不要用准确率、F1 这类阈值相关指标调参因为提交文件只交概率列的排序不交阈值第三模型输出的概率不需要做严格校准可以直接提交原始分数分数只负责排顺序。理解这一点后面做负采样时就不会反复纠结“采样会不会把线上 AUC 打崩”把精力放到特征本身更值。3. 特征工程的三个必做组用户聚合、商品反链、时间滑窗3.1 用户维度统计特征groupby agg 一次做完基础组是 user_id 维度的聚合统计。这一步把所有关于“这个用户平时活不活跃、买不买、爱不爱逛”的信息压缩成几十个数值特征。用 pandas 的 groupby agg 一次性算完比反复 merge 快得多代码也好维护。user_feat df.groupby(user_id).agg( total_actions(action_type, count), # 总行为数 total_buys(action_type, lambda x: (x buy).sum()), # 总购买数 total_carts(action_type, lambda x: (x cart).sum()), # 加购数 total_collects(action_type, lambda x: (x collect).sum()), active_days(day_index, nunique), # 活跃天数 last_action_day(day_index, max), # 最后活跃日 first_action_day(day_index, min), # 首次活跃日 n_unique_sku(sku_id, nunique), # 看过多少商品 n_unique_brand(brand_id, nunique), # 看过多少品牌 ).reset_index() # 购买转化率加购/收藏到购买 user_feat[buy_rate] user_feat[total_buys] / (user_feat[total_actions] 1) user_feat[cart_buy_rate] user_feat[total_buys] / (user_feat[total_carts] 1)三个细节值得说明。第一active_days 用 nunique 而不是直接取 max 减 min用户可能隔几天才来一次活跃天数能反映真实使用节奏不会被极端间隔带偏。第二n_unique_sku 类似“货比三家”的强度在很多复购案例里这个特征的重要性排名非常靠前因为它间接刻画了这个用户是快速决策型还是反复比价型。第三所有涉及除法的特征都加了 1 平滑避免除零也给稀疏行为用户一个合理的小值而不是 NaN。建议先跑这批特征配合 LightGBM 出一个 baseline再往后加特征从 0.75 到 0.82 基本就靠这一组。3.2 商品/品牌反链特征把用户的购买史映射回平均值第二组是反链特征解决的是“用户光顾过的商品本身火不火”这个信息。行为日志里一个用户会接触很多商品每个商品自身又有浏览量、购买量、转化率。把这些商品维度的统计量按用户映射回去就能知道这个用户历史接触的商品里有多少是热销品有多少是无人问津的角落货。sku_feat df.groupby(sku_id).agg( sku_buys(action_type, lambda x: (x buy).sum()), sku_views(action_type, lambda x: (x click).sum()), sku_carts(action_type, lambda x: (x cart).sum()), ).reset_index() sku_feat[sku_buy_rate] sku_feat[sku_buys] / (sku_feat[sku_views] 1) # 每个用户历史购买过的商品热度统计的均值/最大值 user_buy_sku df[df[action_type] buy][[user_id, sku_id]].drop_duplicates() m user_buy_sku.merge(sku_feat, onsku_id, howleft) user_sku_feat m.groupby(user_id).agg( avg_sku_buy_rate(sku_buy_rate, mean), max_sku_buys(sku_buys, max), avg_sku_carts(sku_carts, mean), ).reset_index()反链特征里最常用的聚合是均值和最大值因为用户买过的商品热度分布往往偏态均值会被爆款拉高最大值则能体现用户“吃到了头部爆款的红利”。两个都保留模型自己决定更信哪个。品牌和类目按同样逻辑各做一遍同一个用户反复买同一个品牌的记录在复购预测里是核心信号。这一组做完AUC 通常能往上走 0.01 到 0.02而且特征重要性靠前的往往不是用户本身的活跃度而是他买的商品平均转化率——因为用户再活跃如果逛的都是没人买的东西复购概率也不会高。3.3 时间滑窗和衰减权重最近 7 天比整个训练期更值钱复购预测和时间强相关用户在预测窗口前一周的行为强度远比三个月前的行为有预测力。所以必须做滑窗特征。常见做法是取最近 1、3、7、14 天分别统计行为数、购买数、活跃天数四个窗口并排放进特征表。# day_max 取观察期内全局最大 day_index保证所有用户窗口对齐 for window in [1, 3, 7, 14]: mask (day_max - df[day_index] window) (df[day_index] day_max) w df[mask].groupby(user_id).agg( **{factions_last_{window}d: (action_type, count), fbuys_last_{window}d: (action_type, lambda x: (x buy).sum()), factive_days_last_{window}d: (day_index, nunique)} ).reset_index() user_feat user_feat.merge(w, onuser_id, howleft) user_feat.fillna(0, inplaceTrue)滑窗特征要注意两点。一是窗口边界day_max 取观察期内所有用户的全局最大日保证所有人的窗口对齐如果用每个用户自己的最后活跃日有的用户早退、有的用户持续活跃窗口长度不一致特征就失真了。二是缺失值处理用户近 7 天没来滑窗特征就是 NaN训练前统一 fillna(0)让模型把 0 理解成“这段时间没有行为”这比留空值让树去猜边界更稳定。时间衰减是滑窗的变体。不用截断窗口而是给每个行为按时间距离加权距离越近权重越高。一个常见实现是指数衰减权重等于 0.9 的“天数差”次方然后累计加权行为数。这样既保留了全历史信息又不至于让三个月前的点击和昨天的点击在特征里平起平坐。滑窗加衰减可以同时做滑窗捕捉“近期有没有来”衰减捕捉“整体活跃趋势”二者角度不同不冲突。3.4 负采样比例怎么定1:1 到 1:5 的取舍正样本稀少全量负样本训练一是内存和时间吃不消二是模型会把大量精力花在区分不同负样本上对少数正样本的学习反而不充分。常见做法是按比例采样负样本把训练集正负比压到 1:1 到 1:5。比例没有绝对最优我一般先做 1:3主要看验证集 AUC 和训练时间是否可接受。采样随机种子要固定否则同一天跑两次特征重要性排序都在变没法稳定迭代特征。import numpy as np np.random.seed(42) pos label_df[label_df[label] 1] neg label_df[label_df[label] 0].sample(nlen(pos) * 3, random_state42) train_labels pd.concat([pos, neg]).sample(frac1.0, random_state42) print(train_labels[label].value_counts())一个容易翻车的点负采样会改变验证集的构成所以验证集要单独保留不要在采样的同时把验证集也一并采样。很多人在这一步把训练集和验证集用同一个 sample 函数处理导致验证集正负比失真最后展示的 AUC 和提交线上差一大截。如果硬件允许也可以保留一份全量负样本的验证集专门用来观察采样对 AUC 的影响这样心里更有底。4. 训练与提交验证集怎么切、LightGBM 参数怎么给4.1 按时间切验证集别用 random_split复购预测的数据不是独立同分布的用户行为分布随时间漂移预测窗口前的行为比更早的行为更有指示意义。如果随机切分验证集验证集里会出现大量特征分布和线上不一致的样本导致线下 AUC 虚高。正确做法是按时间切把训练集里时间靠后的用户划成验证集用更早的数据训练模拟“用过去预测未来”的真实场景。# 特征表和标签合并后假设已经保留了每个用户的最后活跃日 split_time train_feat user_feat.merge(train_labels, onuser_id, howinner) cutoff_day train_feat[split_time].quantile(0.85) train_part train_feat[train_feat[split_time] cutoff_day] valid_part train_feat[train_feat[split_time] cutoff_day] X_train train_part.drop(columns[user_id, label, split_time]) y_train train_part[label] X_valid valid_part.drop(columns[user_id, label, split_time]) y_valid valid_part[label]切分的 cutoff 一般取观察期最后 10% 到 20% 的时长。用最后活跃日切分的风险在于验证集会偏向近期活跃用户和线上测试集仍然有一点分布差异但已经比随机切分好得多。更严格的做法是直接用时间戳切比如观察期最后 7 天的用户整体划进验证集不管他们是不是活跃。时间切分牺牲了一部分训练数据换回来的是“验证集更接近线上提交分布”这个核心性质值得。4.2 LightGBM 参数表和早停设置LightGBM 在这个赛题上是性价比最高的模型训练快、对表格特征友好、对 category 字段有原生支持。不推荐一上来就调一堆参数用下面的配置跑通再动 num_leaves 和 min_child_samples。参数初值说明n_estimators2000配合早停给大一点没关系learning_rate0.05调参时固定学习率别两个一起动num_leaves31太小欠拟合太大过拟合先不动feature_fraction0.8每棵树用 80% 的列防过拟合bagging_fraction0.8行采样同时开 bagging_freq1min_child_samples20叶子最小样本数对噪声多的日志很有用categorical_feature列名列表把 cate_id、brand_id 等 ID 声明成分类特征import lightgbm as lgb model lgb.LGBMClassifier( n_estimators2000, learning_rate0.05, num_leaves31, feature_fraction0.8, bagging_fraction0.8, bagging_freq1, min_child_samples20, random_state42, verbose-1, ) model.fit( X_train, y_train, eval_set[(X_valid, y_valid)], eval_metricauc, callbacks[lgb.early_stopping(50), lgb.log_evaluation(100)], )early_stopping 的 patience 设为 50 轮训练会在验证集 AUC 连续 50 轮不涨时自动停下不用手动猜树的数量。调参顺序一般是这样先固定 learning_rate0.05调 num_leaves 和 min_child_samples观察验证集 AUC 和训练时间的平衡再调 feature_fraction 和 bagging_fraction这两个参数对降低方差有明显作用最后尝试降低学习率到 0.01 并放大 n_estimators看是否还有提升。注意 categorical_feature 要传列名列表而不是自动推断LightGBM 不会自动把 object 列当成分类特征默认按数值处理对脱敏 ID 来说就是把随机整数当成了有大小关系的数容易过拟合。4.3 提交文件的格式与两个低级翻车点天池的提交文件一般要求两列user_id 和预测概率第一行是列名行数要等于测试集用户数。概率列不需要归一化到 0 到 1 之间模型输出原样排序也可以但为了保险我会把分数用 predict_proba 取正类概率再写文件。# 假设 test_feat 已经按完全相同的特征工程流程生成 test_user_ids test_feat[user_id].tolist() test_proba model.predict_proba(test_feat.drop(columns[user_id]))[:, 1] sub pd.DataFrame({ user_id: test_user_ids, probability: test_proba, }) sub.to_csv(submission.csv, indexFalse)两个常见翻车点。第一user_id 和测试集顺序不一致提交后平台提示行数不一致或 ID 不匹配解决方法是提交前先 assert 两边 user_id 完全一致或者提交前按测试集的原始顺序重新排序。第二概率写成了科学计数法或带引号的字符串pandas 默认会把 float 写成完整数字但如果之前做过 astype(str) 就会变成字符串列提交时直接报格式错。写入前看一眼 sub.dtypes确认 probability 是 float这比提交后等报错再返工省时间。5. 高频避坑记录本地 0.88 却提交掉分的 5 个原因5.1 本地 0.90、线上 0.72特征穿越现象特征工程做完验证集 AUC 刷到 0.9 以上提交后线上分数不如简单 baseline。原因计算特征时用了预测窗口内的数据比如统计用户全部历史购买数时把预测期内的购买也算了进去。标签和特征共用了一段信息线上自然崩。解决构造特征前先把观察期和预测期按时间切干净所有聚合操作限定在观察期内再做。这个坑最容易发生在“全量行为日志 groupby 后直接 merge”这步日志没有自动切分全靠脚本里手动控制时间范围。检查方法也很简单挑几个特征看预测窗口边界前后的分布有没有突然断层有断层大概率就是穿越了。5.2 全量负样本训练内存先爆了现象训练还没开始内存占用已经 20G 以上或者一个 epoch 跑好几分钟。原因正负样本比接近 1:50几十万正样本配几千万负样本矩阵本身就放不下。解决按 3.4 的负采样做法把负样本压到正样本的 3 倍以内AUC 损失很小训练时间缩短几个量级。如果内存依旧紧张把特征表 dtype 从 float64 转成 float32能省一半内存精度损失在这个赛题上几乎感觉不到。还有一个连带问题负样本量太大时early_stopping 容易失效因为验证集换了分布早停的停止点也变了采样后重新训练一次别直接复用之前的最优迭代数。5.3 user_id 重要性排第一而且高得离谱现象feature_importance 里排第一的是 user_id分数超出第二名几倍。原因脱敏 ID 虽然是数字但本身是随机映射的 category数值大小没有任何含义模型只是在用 ID 做样本记忆。比如一个用户恰好复购了另一个没复购模型记住了这两个 ID 对应的标签验证集上表现还很好因为同一批用户又出现在验证集里。解决把所有 ID 列声明为 categorical_feature或者直接丢弃 ID改用 ID 的统计特征比如这个 ID 对应的历史行为数、购买数、活跃时长。记住一个原则任何 raw ID 都不该成为模型的输入特征特征只应该来自 ID 聚合出来的行为模式。5.4 随机切验证集本地 AUC 和线上差 0.05现象train_test_split 随机切分本地 AUC 0.88提交 0.82反复调参拉不平。原因随机切分让验证集里混入了“未来”的用户行为模型在训练时已经见过这些用户验证集失去时序意义。解决按 4.1 改成时间切分。如果坚持随机切至少要保证验证集中的用户在训练集里完全不存在也就是按用户分组切分而不是按行切分。但更稳妥的还是时间切分因为复购预测的核心场景就是用过去的行为预测未来的购买只有时间切分能模拟这个真实过程。判断验证集是否可靠的简单标准线上分数和你本地验证集分数的差不超过 1 到 2 个点超过这个幅度先怀疑验证集切法。5.5 把点击和加购混在一起统计行为类型没拆开现象所有行为全部 count 进一个总数加了滑窗特征后 AUC 几乎没动静。原因不同行为的购买信号完全不同点击是弱信号加购和收藏是强信号混在一起统计等于把强信号稀释了。解决先按行为类型拆分再分别统计或者用行为权重点击记 1 分、收藏记 2 分、加购记 3 分、购买记 5 分再做滑窗聚合。这个细分在复购预测里普遍能带来 0.01 到 0.02 的 AUC 提升而且实现成本很低就是多写几行 groupby。注意前两个坑是最常见的后三个通常在分数到 0.83 以上才会遇到。判断一个特征是否有效别只看本地 AUC要通过提交分数和特征重要性一起看单一指标容易骗人。6. 把特征从“够用”做到“高分”行为加权与近期窗口融合最后说一个我在这套源码里最常用的提分动作行为加权特征配合近期滑窗做融合。原理是把“距离购买有多近”这个信号量化进特征里加购和收藏比点击离购买近得多对复购的预测力完全不同给它们更高权重让模型在一开始就看到行为强度的差异。weight_map {click: 1, collect: 2, cart: 3, buy: 5} df[action_weight] df[action_type].map(weight_map) # 加权滑窗近 3/7 天的加权行为数保留原始行为数作为对照 for window in [3, 7]: mask (day_max - df[day_index] window) w df[mask].groupby(user_id)[action_weight].sum().reset_index() w.columns [user_id, fweighted_actions_{window}d] user_feat user_feat.merge(w, onuser_id, howleft) user_feat[fweighted_actions_{window}d] user_feat[fweighted_actions_{window}d].fillna(0)权重的选择有一定玄学成分不必追求精确点击 1 分收藏和加购在 2 到 4 之间购买给 5 分基本够用。关键是让模型看到“加购数量很多但最近没动作”和“最近频繁点击但没加购”这两种不同的用户形态。融合时把加权特征和原始行为数同时放进特征表不要互相替代模型会自己决定在不同用户身上更信哪一路信号。验证这个方法有没有效除了看验证集 AUC更推荐看它是否改变了预测结果的排序头部把提交概率按降序排列取前 1000 个用户观察里面正样本占比是否比旧特征更高。如果头部样本质量提升了说明特征真的起作用而不只是平均意义上指标变好。这是我在这套赛题源码上做得最多的一个迭代每次加一组特征先提交一次看看排名变化。有一次想当然地以为滑窗从 7 天改成 14 天一定更好结果 AUC 掉了 0.005查下来是因为 14 天窗口覆盖了太多长期未活跃用户把近期信号稀释了。从那以后养成了一个习惯任何特征改动都先过一遍时间切分的验证集再小步提交验证。希望帮到你。本文还有配套的精品资源点击获取