简介这是2019年CCF大数据与计算智能大赛“乘用车市场销量预测”赛道的冠军解决方案面向机器学习竞赛爱好者、数据挖掘工程师及汽车行业数据分析人员。方案采用LightGBM与规则模型融合策略将全部代码整合为单个Python脚本约500行运行时长约3分钟重点展示了特征工程与赛题分析思路。压缩包共11个文件6个CSV文件存放训练集、评估集及预处理数据3个TXT文件提供标签与资源说明1个MD文档为README1个PY文件为完整实现代码整体大小仅745KB。目前已有61人学习浏览。资源保留了初赛与复赛两阶段预测方案包含从数据探索、特征构造到模型融合的完整流程便于快速参考冠军数据处理与建模逻辑也适合作为竞赛入门与进阶的实战范例可直接迁移到同类销量预测任务中。1. 开局销量预测还能这样用上“乘车”热度2019年CCF大数据与计算智能大赛里乘车出行数据被第一次正式放进市场销量预测任务中。很多人拿到赛题后还是老套路拉历史销量序列算几个滞后特征再套一个梯度提升树结果始终卡在同一个误差线上。最终夺冠的那套解决方案点睛之笔恰恰是把“乘车热度”当成城市线下人流的代理变量叠加到零售商超的销量预测里把最终误差又往下压了一个档次。这篇笔记不打算复刻整份方案包里每一行代码而是把其中可复现的核心抽出来数据口径如何对齐、乘车特征怎么构造才不泄露、时序验证怎么做、GBDT参数怎么收口以及我在复现过程中踩过的那些坑。适合正在做零售销量预测、门店备货、区域流量分析的人照着跑完能直接迁移到自己的数据上。2. 问题定义与数据口径先弄清楚要预测什么再谈冠军效果销量预测类的赛题看起来门槛低实际上最耽误时间的不是模型而是数据口径。冠军方案的第一版代码无非是读表、合并、分组、算滞后但人家在口径上花的心思非常多。这一章先把任务边界说清楚。2.1 预测窗口与评估指标为什么 RMSLE 比 MSE 更公平这个赛题的预测目标通常是未来若干天某品类在某门店的销量数据粒度是“店铺 × 品类 × 日期”模型一次预测出一个连续数值。评估指标用的比较多的是 RMSLE根均方对数误差公式可以理解为先对每个样本计算 ln(预测值1) 与 ln(真实值1) 的差求平方均值后再开根。RMSLE 之所以是销量预测的“默认尺子”是因为它关注相对误差。高销量门店的绝对误差天然大如果用 MSE模型会花大量能力去拟合那些大店小店直接放弃。RMSLE 对低销量样本的惩罚更重比如真实值是 5预测 3 的误差和真实值 50 预测 30 的误差在 RMSLE 里是同一个量级。这就倒逼模型照顾好小门店、小品类而不是只把总量压准。加 1 是为了让零销量样本可以参与对数运算。实际预测时经常出现某门店某品类当天没开门、销量为 0 的情况如果不加 1这些样本在取对数后会变成负无穷整个指标直接失效。后续所有特征工程和模型训练都要围绕“低销量样本不能被牺牲”这一条纪律来做。2.2 数据集构成与口径对齐销量表、乘车热度表与天气表的时间陷阱比赛给的数据通常不是一张整表而是分散的多张表至少包含销售明细、乘车出行订单、天气记录。销售表主键一般是日期、城市、门店、品类乘车表往往带小时粒度的时间戳、城市、区域编码天气表则是日期与城市维度。三张表合并前必须先校验三件事。第一是时区。乘车表和天气表可能来自不同采集链路一个存的是服务器 UTC 时间一个存的是本地时间。判断办法很简单看高峰时段出现在几点。正常业务场景下出行早高峰在 7 点到 9 点如果数据里高峰出现在凌晨就要怀疑时区偏移。第二是城市编码。同一座城市在销售表里写“BJ”在乘车表里写“110000”不统一会导致合并后大量空值。第三是粒度。乘车表按小时记录销量表按天记录直接合并会把小时维度丢失或者产生一对多膨胀。我习惯先把乘车表收敛到“日期 城市 小时”聚合再跟销量表对齐。下面的代码给出一个最小可用的口径对齐过程import pandas as pd sales pd.read_csv(sales.csv, parse_dates[date]) traffic pd.read_csv(traffic.csv, parse_dates[timestamp]) weather pd.read_csv(weather.csv, parse_dates[date]) # 统一城市编码挑出数字后缀避免“BJ”和“110000”这种写法差异 sales[city_id] sales[city].str.extract(r(\d)) traffic[city_id] traffic[city].str.extract(r(\d)) # 把乘车表的时间戳归一到日期并抽出小时段 traffic[date] traffic[timestamp].dt.normalize() traffic[hour] traffic[timestamp].dt.hour # 按日期城市小时聚合成一张日维度热力表 traffic_day ( traffic.groupby([date, city_id, hour], as_indexFalse)[order_cnt] .sum() ) # 以销量表为基准左连接缺失特征后面统一补 base sales.merge( traffic_day, on[date, city_id, hour], howleft ) base base.merge(weather, on[date, city_id], howleft) print(base.shape) print(base.isna().mean().sort_values(ascendingFalse).head(5))逻辑很简单但有两个细节决定后续成败。一是 groupby 后必须加 as_indexFalse否则当天特征会整体变成一个多层索引后面 merge 会变得非常痛苦。二是 merge 的 how 只能选 left基准必须是销量表否则会出现某天无销量但乘车表却多出一行的脏数据。hour 字段要不要保留取决于建模粒度。如果目标是预测日销量建议先按小时拆成 24 个特征再观察哪些小时段与销量相关性高。不要一开始就拍脑袋决定“全天求和”乘车数据是分时的信息藏在时段分布里一刀切聚合会丢掉最有价值的峰谷特征。2.3 基线模型先行先跑一个“无脑均值”再谈方案效果很多人拿到数据就开始堆特征、调模型连基线都没有。冠军方案的边界感很强先跑一个两周滞后加移动平均的朴素预测把 RMSLE 记录下来之后所有特征和模型的收益都拿它做参照而不是凭感觉说“效果好”。这里推荐一个足够简单但不太弱的基线同一门店同一品类上周同日的销量加上昨日销量按 7:3 加权平均。背后逻辑是销量同时存在周周期和连续惯性上周同日相当于季节项昨天相当于水平项。import numpy as np from sklearn.metrics import mean_squared_error base base.sort_values([store_id, category, date]).reset_index(dropTrue) base[lag7_sales] base.groupby([store_id, category])[sales_value].shift(7) base[lag1_sales] base.groupby([store_id, category])[sales_value].shift(1) base[blend] 0.7 * base[lag7_sales] 0.3 * base[lag1_sales] def rmsle(y_true, y_pred): y_pred np.maximum(0, y_pred) # 预测值截断为非负 return float(np.sqrt( mean_squared_error(np.log1p(y_true), np.log1p(y_pred)) )) valid base.dropna(subset[blend]) print(baseline rmsle:, rmsle(valid[sales_value], valid[blend]))这里最容易犯的错是 shift 之前没有对日期排序。如果数据按城市混排同一个 store_id 的各行不是连续按时间排列的shift(7) 取的实际上是其他门店或品类的时间错位值。排序的字段顺序必须是分组键在前、日期在后然后用 reset_index 恢复序号再 shift。baseline 算出来的 RMSLE 未必好看但它是后续所有操作的起跑线。如果某个特征加上去之后RMSLE 反而比 baseline 涨了那就说明要么特征本身带噪声要么存在未来信息泄露此时应该先停下来检查数据口径而不是继续调参。3. 特征工程把“乘车热度解读”变成可训练的变量特征工程是这套方案最值钱的部分。销量历史特征决定了模型的上限乘车热度和天气特征负责把上限再顶高一点。这一章按特征类型拆开讲每类都给出能直接复制的生成方式。3.1 时间、滞后与窗口特征销量序列自回归的三种常见写法销量预测里滞后特征是绝对主力。最常用的三组滞后分别是 lag1、lag7、lag14分别对应当天惯性、一周前的星期效应、两周前的长周期。不要只加 1 和 7滞后 14 能捕捉促销等短周期活动的余波有时比 lag1 更重要。窗口统计特征可以分两类一类是过去 N 天的均值、最大值、最小值一类是“同星期历史均值”。比如过去 4 个周一的销量均值比过去 7 天销量均值更贴近本周一的表现。生成时要按门店和品类分组否则不同门店的销量会混在一起互相污染。base base.sort_values([store_id, category, date]).reset_index(dropTrue) grouped base.groupby([store_id, category])[sales_value] base[lag1] grouped.shift(1) base[lag7] grouped.shift(7) base[lag14] grouped.shift(14) base[roll_mean_7] grouped.transform( lambda x: x.shift(1).rolling(7, min_periods3).mean() ) base[roll_max_14] grouped.transform( lambda x: x.shift(1).rolling(14, min_periods3).max() ) base[prev_week_avg] grouped.transform( lambda x: x.shift(1).shift(7).rolling(4, min_periods1).mean() )窗口内为什么都要先 shift(1)因为 rolling 默认包含当前行而当前行的真实销量是我们要预测的标签如果直接把当前值滚进特征里就是典型的未来信息泄露。train 阶段看不出来线上预测时当天销量未发生特征取不到分数会崩得很难看。transform 的作用是让结果保持原始行的长度不需要再 merge比较省事。要注意 groupby 之后直接 shift 的结果如果是多层索引需要看框架版本决定要不要 reset_index代码跑起来后先打印前几行确认日期对齐了再继续。3.2 乘车热度与商圈流量的交叉特征从“人流”到“购买力”的桥乘车热度本质上不是销量指标而是线下人流指标。一座城市当天出行越活跃意味着商圈客流越高对应的快消、餐饮、零售销量都可能被拉动。冠军方案里最核心的处理方式是把乘车数据改造成三类特征。第一类是非泄露的当日累计。假设我们要预测 6 月 10 日的销量特征只能用到 6 月 10 日当天截止到某个时刻之前的乘车订单比如截止 14 点。这样模型才能模拟真实场景。第二类是近 7 日同时段均值代表最近的出行习惯是否在变化。第三类是与销量的交叉比率比如过去 3 天“乘车热度 / 销量”的比值如果比值连续走高说明客流在增加但购买转化还来得及反应。构造前两类特征的代码如下# 先过滤出截止时刻之前的乘车记录防止未来信息进入特征 cutoff_hour 14 traffic_use traffic[ (traffic[date] pred_date) | ((traffic[date] pred_date) (traffic[hour] cutoff_hour)) ] traffic_cut ( traffic_use.groupby([date, city_id, district], as_indexFalse)[order_cnt] .sum() ) traffic_cut traffic_cut.sort_values([city_id, district, date]) traffic_cut[traffic_7d_mean] ( traffic_cut.groupby([city_id, district])[order_cnt] .transform(lambda x: x.shift(1).rolling(7, min_periods1).mean()) )这个代码的核心是那一层过滤条件。很多人直接把当天的全天乘车总量拿来当特征线上跑分时相当于提前看到了结局验证分数虚高换了真实场景模型直接失效。几点经验cutoff_hour 不用卡得太死预测上午生成结果就卡 10 点下午卡 14 点或 17 点具体要看业务中每天几点出预测。district 是商圈或区域编码。如果原始数据里没有这个字段可以把乘车表按城市内的高频热点区域聚类但比赛数据一般已经给了区域编码直接用即可。聚合维度越细特征噪声越大建议至少先试城市级和区域级两个版本对比验证集 RMSLE 后再决定。3.3 天气与节假日特征的编码方式名义变量别直接进树模型天气数据看起来简单温度、降水量、天气类型但处理上有两个分歧点。一个是天气类型这种名义变量直接编码成 0、1、2、3 是错误做法因为树模型会把数字大小当作顺序关系“晴天0暴雨3”会被误解成“暴雨大于晴天三倍”。正确做法是两个选一转成 one-hot或者作为 category 类型传入 GBDT 框架。另一个是节假日。票务、零售、出游数据的共同特征是节前几天就开始波动节中反而趋于平稳。因此只用“是否节假日”一个 0/1 特征是远远不够的。我通常会把每个日期转换成距离下一个节日的天数、距离上一个节日结束后的天数、以及“节日第几天”。import numpy as np holiday_dates np.array(holiday_table[date].dt.normalize().sort_values().values) base[date_norm] base[date].dt.normalize() d base[date_norm].values # 找到每个日期之后的第一个节日位置计算相隔天数 pos np.searchsorted(holiday_dates, d, sideleft) pos np.clip(pos, 0, len(holiday_dates) - 1) base[days_to_holiday] (holiday_dates[pos] - d).astype(timedelta64[D]).astype(int) # 找到每个日期之前的最近一个节日位置 pos_prev np.searchsorted(holiday_dates, d, sideright) - 1 pos_prev np.clip(pos_prev, 0, len(holiday_dates) - 1) base[days_after_holiday] (d - holiday_dates[pos_prev]).astype(timedelta64[D]).astype(int)这段代码用二分查找避免了逐行遍历节日表造成的大规模笛卡尔积。days_to_holiday 在节前是正数节后可能是一个大正数表示离下个节日还有很远days_after_holiday 则表达刚过完节多久。真正要小心的是春节这种按农历计算的节日。如果直接把“春节当天”作为特征训练数据里的日期和测试数据里的日期永远对不上。用相对天数就没有这个问题因为“节前第 5 天”这种模式在每一年都会重复出现。这是跨年度销量预测里少有的几个“免费”特征值得花时间做对。3.4 特征筛选与存储写特征表时最容易翻车的类型问题上百个特征堆在一起后真正会拖垮项目的不是模型而是数据类型和内存。销量表按门店加品类展开后数据量很容易到几百万行如果特征都是 float64内存可能先爆掉。经验做法是统一降成 float32对类别特征转 category 而不是 object。for col in base.select_dtypes(include[float64]).columns: base[col] base[col].astype(float32) cat_cols [city_id, store_id, category, weather_type] for col in cat_cols: base[col] base[col].astype(category)object 类型在 GBDT 里通常会被当成一列字符串很多框架会报错或自动忽略。提前转 category 有两个好处一是内存变小二是传给 LightGBM 的 categorical_feature 参数时可以直接引用列名不用额外做标签编码。缺失值处理也容易翻车。乘车热度在某些早期日期可能完全没有数据如果直接 dropna 会丢掉训练样本如果填 0等于告诉模型“那几天没人出行”干扰后续的特征分布。我常用的处理是分两列原始列保留 NaN额外加一列 is_missing 标记让树模型自己学缺失模式。这样既保留了缺失本身的信息又不会把缺失扭曲成 0。4. 模型训练与集成从 GBDT 到加权融合的可复现流程销量预测场景里LightGBM 和 XGBoost 这种 GBDT 框架依然是性价比最高的选择。冠军方案里模型部分并不复杂关键是验证方式和融合方式比多数人更谨慎。4.1 时间序列交叉验证随机 K 折会让你的分数“虚高”直接使用随机 K 折做交叉验证是时序预测里最普遍的坑。销量数据存在明显的时间趋势和节假日周期随机切分会把同一天的样本一部分放进训练集、一部分放进验证集模型等于提前“见过”了邻近日期的销量分布验证分数通常会虚高 0.01 到 0.05 的 RMSLE这个误差足以改变特征重要性判断。正确做法是使用按时间顺序切分的 TimeSeriesSplit。切分前必须先把数据按门店、品类、日期排序否则相邻行不是时间相邻行切分会混乱。下面是带冷却间隙的时序交叉验证实现from sklearn.model_selection import TimeSeriesSplit import lightgbm as lgb base base.sort_values([store_id, category, date]).reset_index(dropTrue) features [c for c in base.columns if c not in [sales_value, date, store_id, category]] X base[features] y base[sales_value] tscv TimeSeriesSplit(n_splits5, gap7) for fold, (tr_idx, va_idx) in enumerate(tscv.split(X)): X_tr, X_va X.iloc[tr_idx], X.iloc[va_idx] y_tr, y_va y.iloc[tr_idx], y.iloc[va_idx] model lgb.LGBMRegressor(**params) model.fit( X_tr, y_tr, eval_set[(X_va, y_va)], callbacks[lgb.early_stopping(50, verboseFalse)] ) pred model.predict(X_va) print(ffold {fold}, rmsle:, rmsle(y_va.values, pred))gap7 的意思是训练集的最后 7 天和验证集的开始之间留 7 天空窗模拟真实场景中“近几天的特征还没完全到齐”的状态。如果业务系统是 T1 出数据gap 可以设为 1如果数据实时可查gap 设成 0 也没问题。这个参数本质是对数据延迟的建模并不是越大越好。验证集上的 RMSLE 只能用来对比特征和参数效果绝对数值没有参考意义。真正可信的指标是最后单独在最后一个时间周期上做一次长验证验证集至少要包含一个节假日周期否则节日特征有没有用完全看不出来。4.2 GBDT 核心参数这一组够用LightGBM 参数可调项很多但销量预测这种中等规模数据真正影响结果的就那么几个。我常用的起步参数如下params { objective: regression, metric: rmse, learning_rate: 0.05, num_leaves: 63, max_depth: 6, min_child_samples: 20, feature_fraction: 0.8, bagging_fraction: 0.8, bagging_freq: 1, lambda_l2: 1.0, n_estimators: 1000, verbose: -1, }几个关键参数的取向要说清楚。learning_rate 用 0.05 而不是 0.1代价是训练时间变长但验证集分数通常更稳。num_leaves 63 对应深度约 6 的树容量对于几千到几十万样本量的场景已经够用再大会过拟合噪声。feature_fraction 设 0.8 能增加特征多样性对销量这种特征间多重共线性明显的数据特别重要。lambda_l2 加一点正则可以防止高基数类别特征出现极端分裂。训练时一定要配 early_stoppingn_estimators 设得再大也没关系框架会在验证集不再下降时自动停。但要注意早期停止必须基于时序验证集如果基于随机 K 折的验证集提前停止模型容量会被低估因为随机验证集上分数本来就偏乐观。调参顺序上建议先定学习率和迭代数再调树结构参数最后调 bagging 和正则。不要一上来就网格搜索 learning_rate 和 num_leaves那样只会浪费时间。特征没有稳定之前参数微调带来的收益远小于增加一个有效特征带来的收益。4.3 多模型加权融合与剪枝别把几个弱模型直接捆绑融合是冠军方案里稳定提分的最后一步但很多人做成了“盲目平均”。几个模型的验证集分数差不多融合后反而下降这是常见的翻车现场。融合的前提是模型之间有差异性比如一个用 LightGBM一个用 XGBoost一个用带类别特征的版本一个用不带类别特征的版本。加权融合时权重可以用简单网格搜索来确定from sklearn.model_selection import TimeSeriesSplit import itertools # 假设已经训练好 lgb_model 和 xgb_model p_lgb lgb_model.predict(X_va) p_xgb xgb_model.predict(X_va) best_w, best_score 0.5, 1e9 for w in np.arange(0.3, 0.71, 0.05): blend w * p_lgb (1 - w) * p_xgb score rmsle(y_va.values, blend) if score best_score: best_w, best_score w, score print(best w:, round(best_w, 2), score:, round(best_score, 4))权重搜索的步长 0.05 足够没必要细化到 0.01。这里有一个非常重要的纪律权重只能在验证集上选一次选定后不要再回到训练集微调。如果你反复用同一个验证集去挑权重验证集本身就会过拟合最后的融合权重对新的时间段没有任何泛化意义。融合时还要做“剪枝”把验证集上分数明显差于平均线的模型直接剔除。有人喜欢把五六个模型全部融进去结果融合后的分数不如最好的两个模型加权。原因很简单弱模型提供的是噪声而不是信息量。我通常只保留分数前两名的模型做加权最多三个再多收益边际递减维护成本却翻倍。5. 实战避坑销量预测冠军方案里的常见翻车点这部分不是从文档里抄来的是我实际复现和迁移过程中真金白银踩出来的。每一条都按现象、原因、解决三个层次写清楚。5.1 滞后特征跨了门店导致标签泄露现象验证集 RMSLE 很漂亮但换到线上回测就大幅变差而且特征重要性里 lag7 排第一。原因生成滞后特征时没有先按门店分组而是对整个数据集直接 shift(7)。数据如果按城市混排同一行的前 7 行其实是另一家门店的销量标签信息以“错位”的方式混进了特征。解决任何滞后类特征都必须严格基于 groupby([store_id, category]).shift() 生成shift 之前还要用 sort_values 排好日期顺序。写完之后立刻抽查几个 store_id 的连续日期输出确认昨天的销量真的出现在昨天那一行上。5.2 乘车热度特征用了全天总量现象模型验证分数远高于基线线下重放时却失效尤其是下午时段预测失真严重。原因构造当日乘车特征时用了截止当天的全天订单总量但真实业务里预测是在下午生成的当晚的乘车订单还没发生。模型把“当天完整信息”当成了可用特征验证时自然高分上线必崩。解决把乘车表先按 cutoff_hour 过滤保证任何一天的乘车特征最多只用到预测时刻之前的数据。另一个习惯是直接把 cutoff_hour 也作为一个参数写进特征生成函数而不是写死在代码里方便对不同预测时间做敏感性测试。5.3 节假日特征用绝对日期导致跨年错位现象模型在训练集上拟合很好但预测下一年同期时误差突然放大尤其是春节前后。原因直接把“当天日期”或“当年节假日当天标记”作为特征。年份不同农历节假日对应的公历日期完全错开模型学到的是“1 月 25 日有春节效应”这种伪规律跨年份时全部失效。解决改为相对日期特征距离下一个节日的天数、距离上一个节日结束的天数、节日第几天。相对特征在不同年份间保持稳定模型才能学到真正的节日行为模式。顺带提醒国庆这种公历节日在长期预测里也需要用相对偏移因为预测窗口可能落在节日前后边界上。5.4 缺失销量统一填 0 带偏模型现象模型对某些门店的预测长期偏低即使该门店实际销量在增长。原因部分门店历史上有过断货或闭店导致的缺失记录处理时直接 fillna(0)。模型学到的模式是“该门店某些日期特征组合下销量为 0 是常态”于是预测时也倾向输出 0。解决先区分“真实零销量”和“缺失记录”。缺失记录可以用前向填充补上另外加一列 is_missing 标记。如果一个门店连续 3 天没有销售记录说明大概率闭店或停业此时不能简单用前一天的销量填充应该用上一周同日均值填充。5.5 预测负值截断方式悄悄改变 RMSLE现象同一个模型有人跑出 0.42有人跑出 0.45代码几乎一样最后发现是预测值截断方式不同。原因GBDT 在低销量区间可能输出负值。一种处理是 np.maximum(0, pred)把负值直接变成 0另一种是 np.clip(pred, 0.01, None)把负值压到一个很小的正数。在 log1p 空间里0 和 0.01 对应的对数差距很小可以忽略但真实值为 0 时前者误差是 0后者误差是 ln(1.01)差异放大到了指标层面。解决确定一套全流程统一的截断规则训练和验证时用同一套线上推理时也要保持一致。我一般选 np.clip(pred, 0.01, None)因为真实销量为 0 的样本在训练集里占比不高而真实销量为正的样本如果被预测成 0代价极大。6. 落地验证与进阶把“冠军方案”变成生产环境可用的模型比赛方案复现完之后下一步是迁移到自己的业务数据上。这里有几个常规但实用的进阶习惯。6.1 评估分数之外还要看三类特征的重要性不要只看 LightGBM 输出的 feature_importance那是按分裂次数或增益统计的容易偏好高基数特征。我一般用 permutation importance 交叉验证一遍把每个特征随机打乱后看 RMSLE 跌幅。一个特征贡献稳定时打乱后分数会显著变差如果打乱后分数几乎不动说明它在验证集上是冗余的可以考虑删掉。乘车热度特征是否值得保留就看这一步。如果 permutation importance 排名靠前说明它对销量有独立的解释力而不是单纯跟时间趋势共线。这种情况下可以继续深挖比如拆出不同商圈或不同时段版本再测一轮经常还能再挤出一点提升空间。6.2 从日粒度到小时粒度的预测迁移技巧如果业务从预测日销量升级到预测小时销量特征工程不需要推倒重来。把日期相关的滞后和滚动窗口改成“日期 小时”粒度乘车热度特征直接换成对应小时段的订单量。注意小时粒度下 lag 要变成 24 和 168对应昨天同一小时和上周同一小时窗口统计则按过去 3 天同一小时聚合降低单小时抖动。一个常被忽视的细节是小时粒度的销量预测更适合用分位数损失或负二项分布目标而不是纯 MSE。小时销量里零值比例很高分布长尾严重RMSLE 虽然能处理零值但对高波动小时段的惩罚不够直观。可以先用 RMSLE 跑通全流程再验证换目标函数是否有提升。6.3 生产环境的每日回填与监控模型上线后我最看重的是每天回填验证。每天把真实销量拿到手后把模型昨天的预测、基线预测、真实值一起对比记录滚动 RMSLE。不用等月底总结每天扫一眼折线图就能发现异常如果某天的 RMSLE 突然跳升先看当天的节假日特征是不是有偏移再看乘车特征是不是某时段数据延迟。特征分布的监控同样重要。乘车数据的采集口径或上游表结构变化时特征分布会悄悄漂移模型分数可能不会立刻崩但会缓慢恶化。用 PSI 或者简单的均值漂移检测都能发现这类问题。养成每次数据更新后先跑特征分布对比的习惯比任何模型调参都更能避免线上事故。最后说一条我自己的教训有一次做类似方案特征工程全部跑完模型也调得不错结果上线前检查才发现乘车数据的截止时刻写错等于所有预测结果都提前看到了未来。那次的“后悔药”就是回头重新切分口径损失了两天时间。所以做好销量预测先别急着炫技把时间边界和验证逻辑焊死结果自然稳定。希望帮到你。本文还有配套的精品资源点击获取 
长河君 · 2026/10/10 3:06:11 · 阅读 1.2k 乘车热度特征如何提升销量预测？GBDT与特征工程实战
简介这是2019年CCF大数据与计算智能大赛“乘用车市场销量预测”赛道的冠军解决方案面向机器学习竞赛爱好者、数据挖掘工程师及汽车行业数据分析人员。方案采用LightGBM与规则模型融合策略将全部代码整合为单个Python脚本约500行运行时长约3分钟重点展示了特征工程与赛题分析思路。压缩包共11个文件6个CSV文件存放训练集、评估集及预处理数据3个TXT文件提供标签与资源说明1个MD文档为README1个PY文件为完整实现代码整体大小仅745KB。目前已有61人学习浏览。资源保留了初赛与复赛两阶段预测方案包含从数据探索、特征构造到模型融合的完整流程便于快速参考冠军数据处理与建模逻辑也适合作为竞赛入门与进阶的实战范例可直接迁移到同类销量预测任务中。1. 开局销量预测还能这样用上“乘车”热度2019年CCF大数据与计算智能大赛里乘车出行数据被第一次正式放进市场销量预测任务中。很多人拿到赛题后还是老套路拉历史销量序列算几个滞后特征再套一个梯度提升树结果始终卡在同一个误差线上。最终夺冠的那套解决方案点睛之笔恰恰是把“乘车热度”当成城市线下人流的代理变量叠加到零售商超的销量预测里把最终误差又往下压了一个档次。这篇笔记不打算复刻整份方案包里每一行代码而是把其中可复现的核心抽出来数据口径如何对齐、乘车特征怎么构造才不泄露、时序验证怎么做、GBDT参数怎么收口以及我在复现过程中踩过的那些坑。适合正在做零售销量预测、门店备货、区域流量分析的人照着跑完能直接迁移到自己的数据上。2. 问题定义与数据口径先弄清楚要预测什么再谈冠军效果销量预测类的赛题看起来门槛低实际上最耽误时间的不是模型而是数据口径。冠军方案的第一版代码无非是读表、合并、分组、算滞后但人家在口径上花的心思非常多。这一章先把任务边界说清楚。2.1 预测窗口与评估指标为什么 RMSLE 比 MSE 更公平这个赛题的预测目标通常是未来若干天某品类在某门店的销量数据粒度是“店铺 × 品类 × 日期”模型一次预测出一个连续数值。评估指标用的比较多的是 RMSLE根均方对数误差公式可以理解为先对每个样本计算 ln(预测值1) 与 ln(真实值1) 的差求平方均值后再开根。RMSLE 之所以是销量预测的“默认尺子”是因为它关注相对误差。高销量门店的绝对误差天然大如果用 MSE模型会花大量能力去拟合那些大店小店直接放弃。RMSLE 对低销量样本的惩罚更重比如真实值是 5预测 3 的误差和真实值 50 预测 30 的误差在 RMSLE 里是同一个量级。这就倒逼模型照顾好小门店、小品类而不是只把总量压准。加 1 是为了让零销量样本可以参与对数运算。实际预测时经常出现某门店某品类当天没开门、销量为 0 的情况如果不加 1这些样本在取对数后会变成负无穷整个指标直接失效。后续所有特征工程和模型训练都要围绕“低销量样本不能被牺牲”这一条纪律来做。2.2 数据集构成与口径对齐销量表、乘车热度表与天气表的时间陷阱比赛给的数据通常不是一张整表而是分散的多张表至少包含销售明细、乘车出行订单、天气记录。销售表主键一般是日期、城市、门店、品类乘车表往往带小时粒度的时间戳、城市、区域编码天气表则是日期与城市维度。三张表合并前必须先校验三件事。第一是时区。乘车表和天气表可能来自不同采集链路一个存的是服务器 UTC 时间一个存的是本地时间。判断办法很简单看高峰时段出现在几点。正常业务场景下出行早高峰在 7 点到 9 点如果数据里高峰出现在凌晨就要怀疑时区偏移。第二是城市编码。同一座城市在销售表里写“BJ”在乘车表里写“110000”不统一会导致合并后大量空值。第三是粒度。乘车表按小时记录销量表按天记录直接合并会把小时维度丢失或者产生一对多膨胀。我习惯先把乘车表收敛到“日期 城市 小时”聚合再跟销量表对齐。下面的代码给出一个最小可用的口径对齐过程import pandas as pd sales pd.read_csv(sales.csv, parse_dates[date]) traffic pd.read_csv(traffic.csv, parse_dates[timestamp]) weather pd.read_csv(weather.csv, parse_dates[date]) # 统一城市编码挑出数字后缀避免“BJ”和“110000”这种写法差异 sales[city_id] sales[city].str.extract(r(\d)) traffic[city_id] traffic[city].str.extract(r(\d)) # 把乘车表的时间戳归一到日期并抽出小时段 traffic[date] traffic[timestamp].dt.normalize() traffic[hour] traffic[timestamp].dt.hour # 按日期城市小时聚合成一张日维度热力表 traffic_day ( traffic.groupby([date, city_id, hour], as_indexFalse)[order_cnt] .sum() ) # 以销量表为基准左连接缺失特征后面统一补 base sales.merge( traffic_day, on[date, city_id, hour], howleft ) base base.merge(weather, on[date, city_id], howleft) print(base.shape) print(base.isna().mean().sort_values(ascendingFalse).head(5))逻辑很简单但有两个细节决定后续成败。一是 groupby 后必须加 as_indexFalse否则当天特征会整体变成一个多层索引后面 merge 会变得非常痛苦。二是 merge 的 how 只能选 left基准必须是销量表否则会出现某天无销量但乘车表却多出一行的脏数据。hour 字段要不要保留取决于建模粒度。如果目标是预测日销量建议先按小时拆成 24 个特征再观察哪些小时段与销量相关性高。不要一开始就拍脑袋决定“全天求和”乘车数据是分时的信息藏在时段分布里一刀切聚合会丢掉最有价值的峰谷特征。2.3 基线模型先行先跑一个“无脑均值”再谈方案效果很多人拿到数据就开始堆特征、调模型连基线都没有。冠军方案的边界感很强先跑一个两周滞后加移动平均的朴素预测把 RMSLE 记录下来之后所有特征和模型的收益都拿它做参照而不是凭感觉说“效果好”。这里推荐一个足够简单但不太弱的基线同一门店同一品类上周同日的销量加上昨日销量按 7:3 加权平均。背后逻辑是销量同时存在周周期和连续惯性上周同日相当于季节项昨天相当于水平项。import numpy as np from sklearn.metrics import mean_squared_error base base.sort_values([store_id, category, date]).reset_index(dropTrue) base[lag7_sales] base.groupby([store_id, category])[sales_value].shift(7) base[lag1_sales] base.groupby([store_id, category])[sales_value].shift(1) base[blend] 0.7 * base[lag7_sales] 0.3 * base[lag1_sales] def rmsle(y_true, y_pred): y_pred np.maximum(0, y_pred) # 预测值截断为非负 return float(np.sqrt( mean_squared_error(np.log1p(y_true), np.log1p(y_pred)) )) valid base.dropna(subset[blend]) print(baseline rmsle:, rmsle(valid[sales_value], valid[blend]))这里最容易犯的错是 shift 之前没有对日期排序。如果数据按城市混排同一个 store_id 的各行不是连续按时间排列的shift(7) 取的实际上是其他门店或品类的时间错位值。排序的字段顺序必须是分组键在前、日期在后然后用 reset_index 恢复序号再 shift。baseline 算出来的 RMSLE 未必好看但它是后续所有操作的起跑线。如果某个特征加上去之后RMSLE 反而比 baseline 涨了那就说明要么特征本身带噪声要么存在未来信息泄露此时应该先停下来检查数据口径而不是继续调参。3. 特征工程把“乘车热度解读”变成可训练的变量特征工程是这套方案最值钱的部分。销量历史特征决定了模型的上限乘车热度和天气特征负责把上限再顶高一点。这一章按特征类型拆开讲每类都给出能直接复制的生成方式。3.1 时间、滞后与窗口特征销量序列自回归的三种常见写法销量预测里滞后特征是绝对主力。最常用的三组滞后分别是 lag1、lag7、lag14分别对应当天惯性、一周前的星期效应、两周前的长周期。不要只加 1 和 7滞后 14 能捕捉促销等短周期活动的余波有时比 lag1 更重要。窗口统计特征可以分两类一类是过去 N 天的均值、最大值、最小值一类是“同星期历史均值”。比如过去 4 个周一的销量均值比过去 7 天销量均值更贴近本周一的表现。生成时要按门店和品类分组否则不同门店的销量会混在一起互相污染。base base.sort_values([store_id, category, date]).reset_index(dropTrue) grouped base.groupby([store_id, category])[sales_value] base[lag1] grouped.shift(1) base[lag7] grouped.shift(7) base[lag14] grouped.shift(14) base[roll_mean_7] grouped.transform( lambda x: x.shift(1).rolling(7, min_periods3).mean() ) base[roll_max_14] grouped.transform( lambda x: x.shift(1).rolling(14, min_periods3).max() ) base[prev_week_avg] grouped.transform( lambda x: x.shift(1).shift(7).rolling(4, min_periods1).mean() )窗口内为什么都要先 shift(1)因为 rolling 默认包含当前行而当前行的真实销量是我们要预测的标签如果直接把当前值滚进特征里就是典型的未来信息泄露。train 阶段看不出来线上预测时当天销量未发生特征取不到分数会崩得很难看。transform 的作用是让结果保持原始行的长度不需要再 merge比较省事。要注意 groupby 之后直接 shift 的结果如果是多层索引需要看框架版本决定要不要 reset_index代码跑起来后先打印前几行确认日期对齐了再继续。3.2 乘车热度与商圈流量的交叉特征从“人流”到“购买力”的桥乘车热度本质上不是销量指标而是线下人流指标。一座城市当天出行越活跃意味着商圈客流越高对应的快消、餐饮、零售销量都可能被拉动。冠军方案里最核心的处理方式是把乘车数据改造成三类特征。第一类是非泄露的当日累计。假设我们要预测 6 月 10 日的销量特征只能用到 6 月 10 日当天截止到某个时刻之前的乘车订单比如截止 14 点。这样模型才能模拟真实场景。第二类是近 7 日同时段均值代表最近的出行习惯是否在变化。第三类是与销量的交叉比率比如过去 3 天“乘车热度 / 销量”的比值如果比值连续走高说明客流在增加但购买转化还来得及反应。构造前两类特征的代码如下# 先过滤出截止时刻之前的乘车记录防止未来信息进入特征 cutoff_hour 14 traffic_use traffic[ (traffic[date] pred_date) | ((traffic[date] pred_date) (traffic[hour] cutoff_hour)) ] traffic_cut ( traffic_use.groupby([date, city_id, district], as_indexFalse)[order_cnt] .sum() ) traffic_cut traffic_cut.sort_values([city_id, district, date]) traffic_cut[traffic_7d_mean] ( traffic_cut.groupby([city_id, district])[order_cnt] .transform(lambda x: x.shift(1).rolling(7, min_periods1).mean()) )这个代码的核心是那一层过滤条件。很多人直接把当天的全天乘车总量拿来当特征线上跑分时相当于提前看到了结局验证分数虚高换了真实场景模型直接失效。几点经验cutoff_hour 不用卡得太死预测上午生成结果就卡 10 点下午卡 14 点或 17 点具体要看业务中每天几点出预测。district 是商圈或区域编码。如果原始数据里没有这个字段可以把乘车表按城市内的高频热点区域聚类但比赛数据一般已经给了区域编码直接用即可。聚合维度越细特征噪声越大建议至少先试城市级和区域级两个版本对比验证集 RMSLE 后再决定。3.3 天气与节假日特征的编码方式名义变量别直接进树模型天气数据看起来简单温度、降水量、天气类型但处理上有两个分歧点。一个是天气类型这种名义变量直接编码成 0、1、2、3 是错误做法因为树模型会把数字大小当作顺序关系“晴天0暴雨3”会被误解成“暴雨大于晴天三倍”。正确做法是两个选一转成 one-hot或者作为 category 类型传入 GBDT 框架。另一个是节假日。票务、零售、出游数据的共同特征是节前几天就开始波动节中反而趋于平稳。因此只用“是否节假日”一个 0/1 特征是远远不够的。我通常会把每个日期转换成距离下一个节日的天数、距离上一个节日结束后的天数、以及“节日第几天”。import numpy as np holiday_dates np.array(holiday_table[date].dt.normalize().sort_values().values) base[date_norm] base[date].dt.normalize() d base[date_norm].values # 找到每个日期之后的第一个节日位置计算相隔天数 pos np.searchsorted(holiday_dates, d, sideleft) pos np.clip(pos, 0, len(holiday_dates) - 1) base[days_to_holiday] (holiday_dates[pos] - d).astype(timedelta64[D]).astype(int) # 找到每个日期之前的最近一个节日位置 pos_prev np.searchsorted(holiday_dates, d, sideright) - 1 pos_prev np.clip(pos_prev, 0, len(holiday_dates) - 1) base[days_after_holiday] (d - holiday_dates[pos_prev]).astype(timedelta64[D]).astype(int)这段代码用二分查找避免了逐行遍历节日表造成的大规模笛卡尔积。days_to_holiday 在节前是正数节后可能是一个大正数表示离下个节日还有很远days_after_holiday 则表达刚过完节多久。真正要小心的是春节这种按农历计算的节日。如果直接把“春节当天”作为特征训练数据里的日期和测试数据里的日期永远对不上。用相对天数就没有这个问题因为“节前第 5 天”这种模式在每一年都会重复出现。这是跨年度销量预测里少有的几个“免费”特征值得花时间做对。3.4 特征筛选与存储写特征表时最容易翻车的类型问题上百个特征堆在一起后真正会拖垮项目的不是模型而是数据类型和内存。销量表按门店加品类展开后数据量很容易到几百万行如果特征都是 float64内存可能先爆掉。经验做法是统一降成 float32对类别特征转 category 而不是 object。for col in base.select_dtypes(include[float64]).columns: base[col] base[col].astype(float32) cat_cols [city_id, store_id, category, weather_type] for col in cat_cols: base[col] base[col].astype(category)object 类型在 GBDT 里通常会被当成一列字符串很多框架会报错或自动忽略。提前转 category 有两个好处一是内存变小二是传给 LightGBM 的 categorical_feature 参数时可以直接引用列名不用额外做标签编码。缺失值处理也容易翻车。乘车热度在某些早期日期可能完全没有数据如果直接 dropna 会丢掉训练样本如果填 0等于告诉模型“那几天没人出行”干扰后续的特征分布。我常用的处理是分两列原始列保留 NaN额外加一列 is_missing 标记让树模型自己学缺失模式。这样既保留了缺失本身的信息又不会把缺失扭曲成 0。4. 模型训练与集成从 GBDT 到加权融合的可复现流程销量预测场景里LightGBM 和 XGBoost 这种 GBDT 框架依然是性价比最高的选择。冠军方案里模型部分并不复杂关键是验证方式和融合方式比多数人更谨慎。4.1 时间序列交叉验证随机 K 折会让你的分数“虚高”直接使用随机 K 折做交叉验证是时序预测里最普遍的坑。销量数据存在明显的时间趋势和节假日周期随机切分会把同一天的样本一部分放进训练集、一部分放进验证集模型等于提前“见过”了邻近日期的销量分布验证分数通常会虚高 0.01 到 0.05 的 RMSLE这个误差足以改变特征重要性判断。正确做法是使用按时间顺序切分的 TimeSeriesSplit。切分前必须先把数据按门店、品类、日期排序否则相邻行不是时间相邻行切分会混乱。下面是带冷却间隙的时序交叉验证实现from sklearn.model_selection import TimeSeriesSplit import lightgbm as lgb base base.sort_values([store_id, category, date]).reset_index(dropTrue) features [c for c in base.columns if c not in [sales_value, date, store_id, category]] X base[features] y base[sales_value] tscv TimeSeriesSplit(n_splits5, gap7) for fold, (tr_idx, va_idx) in enumerate(tscv.split(X)): X_tr, X_va X.iloc[tr_idx], X.iloc[va_idx] y_tr, y_va y.iloc[tr_idx], y.iloc[va_idx] model lgb.LGBMRegressor(**params) model.fit( X_tr, y_tr, eval_set[(X_va, y_va)], callbacks[lgb.early_stopping(50, verboseFalse)] ) pred model.predict(X_va) print(ffold {fold}, rmsle:, rmsle(y_va.values, pred))gap7 的意思是训练集的最后 7 天和验证集的开始之间留 7 天空窗模拟真实场景中“近几天的特征还没完全到齐”的状态。如果业务系统是 T1 出数据gap 可以设为 1如果数据实时可查gap 设成 0 也没问题。这个参数本质是对数据延迟的建模并不是越大越好。验证集上的 RMSLE 只能用来对比特征和参数效果绝对数值没有参考意义。真正可信的指标是最后单独在最后一个时间周期上做一次长验证验证集至少要包含一个节假日周期否则节日特征有没有用完全看不出来。4.2 GBDT 核心参数这一组够用LightGBM 参数可调项很多但销量预测这种中等规模数据真正影响结果的就那么几个。我常用的起步参数如下params { objective: regression, metric: rmse, learning_rate: 0.05, num_leaves: 63, max_depth: 6, min_child_samples: 20, feature_fraction: 0.8, bagging_fraction: 0.8, bagging_freq: 1, lambda_l2: 1.0, n_estimators: 1000, verbose: -1, }几个关键参数的取向要说清楚。learning_rate 用 0.05 而不是 0.1代价是训练时间变长但验证集分数通常更稳。num_leaves 63 对应深度约 6 的树容量对于几千到几十万样本量的场景已经够用再大会过拟合噪声。feature_fraction 设 0.8 能增加特征多样性对销量这种特征间多重共线性明显的数据特别重要。lambda_l2 加一点正则可以防止高基数类别特征出现极端分裂。训练时一定要配 early_stoppingn_estimators 设得再大也没关系框架会在验证集不再下降时自动停。但要注意早期停止必须基于时序验证集如果基于随机 K 折的验证集提前停止模型容量会被低估因为随机验证集上分数本来就偏乐观。调参顺序上建议先定学习率和迭代数再调树结构参数最后调 bagging 和正则。不要一上来就网格搜索 learning_rate 和 num_leaves那样只会浪费时间。特征没有稳定之前参数微调带来的收益远小于增加一个有效特征带来的收益。4.3 多模型加权融合与剪枝别把几个弱模型直接捆绑融合是冠军方案里稳定提分的最后一步但很多人做成了“盲目平均”。几个模型的验证集分数差不多融合后反而下降这是常见的翻车现场。融合的前提是模型之间有差异性比如一个用 LightGBM一个用 XGBoost一个用带类别特征的版本一个用不带类别特征的版本。加权融合时权重可以用简单网格搜索来确定from sklearn.model_selection import TimeSeriesSplit import itertools # 假设已经训练好 lgb_model 和 xgb_model p_lgb lgb_model.predict(X_va) p_xgb xgb_model.predict(X_va) best_w, best_score 0.5, 1e9 for w in np.arange(0.3, 0.71, 0.05): blend w * p_lgb (1 - w) * p_xgb score rmsle(y_va.values, blend) if score best_score: best_w, best_score w, score print(best w:, round(best_w, 2), score:, round(best_score, 4))权重搜索的步长 0.05 足够没必要细化到 0.01。这里有一个非常重要的纪律权重只能在验证集上选一次选定后不要再回到训练集微调。如果你反复用同一个验证集去挑权重验证集本身就会过拟合最后的融合权重对新的时间段没有任何泛化意义。融合时还要做“剪枝”把验证集上分数明显差于平均线的模型直接剔除。有人喜欢把五六个模型全部融进去结果融合后的分数不如最好的两个模型加权。原因很简单弱模型提供的是噪声而不是信息量。我通常只保留分数前两名的模型做加权最多三个再多收益边际递减维护成本却翻倍。5. 实战避坑销量预测冠军方案里的常见翻车点这部分不是从文档里抄来的是我实际复现和迁移过程中真金白银踩出来的。每一条都按现象、原因、解决三个层次写清楚。5.1 滞后特征跨了门店导致标签泄露现象验证集 RMSLE 很漂亮但换到线上回测就大幅变差而且特征重要性里 lag7 排第一。原因生成滞后特征时没有先按门店分组而是对整个数据集直接 shift(7)。数据如果按城市混排同一行的前 7 行其实是另一家门店的销量标签信息以“错位”的方式混进了特征。解决任何滞后类特征都必须严格基于 groupby([store_id, category]).shift() 生成shift 之前还要用 sort_values 排好日期顺序。写完之后立刻抽查几个 store_id 的连续日期输出确认昨天的销量真的出现在昨天那一行上。5.2 乘车热度特征用了全天总量现象模型验证分数远高于基线线下重放时却失效尤其是下午时段预测失真严重。原因构造当日乘车特征时用了截止当天的全天订单总量但真实业务里预测是在下午生成的当晚的乘车订单还没发生。模型把“当天完整信息”当成了可用特征验证时自然高分上线必崩。解决把乘车表先按 cutoff_hour 过滤保证任何一天的乘车特征最多只用到预测时刻之前的数据。另一个习惯是直接把 cutoff_hour 也作为一个参数写进特征生成函数而不是写死在代码里方便对不同预测时间做敏感性测试。5.3 节假日特征用绝对日期导致跨年错位现象模型在训练集上拟合很好但预测下一年同期时误差突然放大尤其是春节前后。原因直接把“当天日期”或“当年节假日当天标记”作为特征。年份不同农历节假日对应的公历日期完全错开模型学到的是“1 月 25 日有春节效应”这种伪规律跨年份时全部失效。解决改为相对日期特征距离下一个节日的天数、距离上一个节日结束的天数、节日第几天。相对特征在不同年份间保持稳定模型才能学到真正的节日行为模式。顺带提醒国庆这种公历节日在长期预测里也需要用相对偏移因为预测窗口可能落在节日前后边界上。5.4 缺失销量统一填 0 带偏模型现象模型对某些门店的预测长期偏低即使该门店实际销量在增长。原因部分门店历史上有过断货或闭店导致的缺失记录处理时直接 fillna(0)。模型学到的模式是“该门店某些日期特征组合下销量为 0 是常态”于是预测时也倾向输出 0。解决先区分“真实零销量”和“缺失记录”。缺失记录可以用前向填充补上另外加一列 is_missing 标记。如果一个门店连续 3 天没有销售记录说明大概率闭店或停业此时不能简单用前一天的销量填充应该用上一周同日均值填充。5.5 预测负值截断方式悄悄改变 RMSLE现象同一个模型有人跑出 0.42有人跑出 0.45代码几乎一样最后发现是预测值截断方式不同。原因GBDT 在低销量区间可能输出负值。一种处理是 np.maximum(0, pred)把负值直接变成 0另一种是 np.clip(pred, 0.01, None)把负值压到一个很小的正数。在 log1p 空间里0 和 0.01 对应的对数差距很小可以忽略但真实值为 0 时前者误差是 0后者误差是 ln(1.01)差异放大到了指标层面。解决确定一套全流程统一的截断规则训练和验证时用同一套线上推理时也要保持一致。我一般选 np.clip(pred, 0.01, None)因为真实销量为 0 的样本在训练集里占比不高而真实销量为正的样本如果被预测成 0代价极大。6. 落地验证与进阶把“冠军方案”变成生产环境可用的模型比赛方案复现完之后下一步是迁移到自己的业务数据上。这里有几个常规但实用的进阶习惯。6.1 评估分数之外还要看三类特征的重要性不要只看 LightGBM 输出的 feature_importance那是按分裂次数或增益统计的容易偏好高基数特征。我一般用 permutation importance 交叉验证一遍把每个特征随机打乱后看 RMSLE 跌幅。一个特征贡献稳定时打乱后分数会显著变差如果打乱后分数几乎不动说明它在验证集上是冗余的可以考虑删掉。乘车热度特征是否值得保留就看这一步。如果 permutation importance 排名靠前说明它对销量有独立的解释力而不是单纯跟时间趋势共线。这种情况下可以继续深挖比如拆出不同商圈或不同时段版本再测一轮经常还能再挤出一点提升空间。6.2 从日粒度到小时粒度的预测迁移技巧如果业务从预测日销量升级到预测小时销量特征工程不需要推倒重来。把日期相关的滞后和滚动窗口改成“日期 小时”粒度乘车热度特征直接换成对应小时段的订单量。注意小时粒度下 lag 要变成 24 和 168对应昨天同一小时和上周同一小时窗口统计则按过去 3 天同一小时聚合降低单小时抖动。一个常被忽视的细节是小时粒度的销量预测更适合用分位数损失或负二项分布目标而不是纯 MSE。小时销量里零值比例很高分布长尾严重RMSLE 虽然能处理零值但对高波动小时段的惩罚不够直观。可以先用 RMSLE 跑通全流程再验证换目标函数是否有提升。6.3 生产环境的每日回填与监控模型上线后我最看重的是每天回填验证。每天把真实销量拿到手后把模型昨天的预测、基线预测、真实值一起对比记录滚动 RMSLE。不用等月底总结每天扫一眼折线图就能发现异常如果某天的 RMSLE 突然跳升先看当天的节假日特征是不是有偏移再看乘车特征是不是某时段数据延迟。特征分布的监控同样重要。乘车数据的采集口径或上游表结构变化时特征分布会悄悄漂移模型分数可能不会立刻崩但会缓慢恶化。用 PSI 或者简单的均值漂移检测都能发现这类问题。养成每次数据更新后先跑特征分布对比的习惯比任何模型调参都更能避免线上事故。最后说一条我自己的教训有一次做类似方案特征工程全部跑完模型也调得不错结果上线前检查才发现乘车数据的截止时刻写错等于所有预测结果都提前看到了未来。那次的“后悔药”就是回头重新切分口径损失了两天时间。所以做好销量预测先别急着炫技把时间边界和验证逻辑焊死结果自然稳定。希望帮到你。本文还有配套的精品资源点击获取