简介：这是一份天池大数据竞赛“菜鸟需求预测与分仓规划”赛题的实操代码包，面向参加数据挖掘竞赛或关注供应链预测的开发者，解决从数据清洗、特征工程到分仓建模与融合预测的完整链路。压缩包共68个文件，包含58个Python脚本、6个SQL查询、2个CSV结果、1个R脚本和1个说明文档，覆盖数据预处理、特征构建、模型训练、结果评估等环节，其中XGBoost、GBDT、随机森林、SVR线性核与RBF核均有对应实现，并按单仓独立建模思路组织目录。资源仅133KB，代码轻量、结构清晰，便于直接运行和二次改造。已有2339人学习下载，适合正在备赛或想复现此类方案的分析师参考。通过该资源可掌握回归模型融合的常用写法、分仓规划的工程化落地方法，以及天池赛题从SQL取数到提交结果的完整流程，是一份实用且浓缩的赛题开源方案。1. 先拆清赛题：需求预测与分仓规划到底在考什么这类智慧供应链赛题我拆过不止一次，表面看是两段式任务——先预测未来某段时间每个站点的包裹需求量，再根据预测结果做分仓规划；实际上，绝大多数参赛者摔跤都摔在同一个地方：把时间序列问题当成普通回归问题来做，随机切分训练集、不做滞后特征、融合只看分数不看相关性。赛题给的原始数据通常是一张订单流水主表加若干维度表，字段不外乎站点ID、品类、日期、需求量、仓库产能上限。你需要输出的东西也清楚：一份逐日逐站点的需求预测量，以及一份满足各仓库产能约束的分配方案。适合谁？想正经打一场数据竞赛、或者在做供应链计划类项目的人。第一眼看上去模型选型决定成败，跑到后面你会发现，特征对齐和验证集设计比模型重要一个量级——这篇就把整条链路的做法拆开讲。2. 数据准备：从主表到训练样本的关键动作2.1 多表合并：先定粒度再定主键拿到原始数据后第一件事不是跑模型，而是把所有表读进来，确认每一张表的粒度。这类赛题通常会有三到四张表：订单明细表（一行一个订单或一行一个站点某日汇总）、站点属性表、仓库产能表，有时还带一个假日表。我先用一个示例把最常见的合并逻辑写出来：import pandas as pd # 订单明细表：站点ID、日期、订单量 orders = pd.read_csv("orders.csv", parse_dates=["date"]) # 站点维度表：站点ID、所属区域、绑定仓库ID stations = pd.read_csv("stations.csv") # 仓库产能表：仓库ID、日期、日产能上限 warehouse = pd.read_csv("warehouse.csv") # 先按站点+日期聚合，得到每日需求量 daily = orders.groupby(["station_id", "date"], as_index=False)["order_qty"].sum() # 关联站点维度，拿到区域和仓库映射 df = daily.merge(stations, on="station_id", how="left") # 关联仓库产能，注意这里两个表都有日期维度 df = df.merge(warehouse, on=["warehouse_id", "date"], how="left") print(df.head())这段代码里有一个关键顺序：先聚合再合并。如果先把订单表和站点表做大笛卡尔积再聚合，数据量会膨胀到没法处理。合并时要注意 how 参数，订单明细表是主表，必须用 left，不能用 inner——如果某天某站点没有订单，inner 会直接把这一行丢掉，预测时就少了对零需求样本的学习。关联仓库产能表时我一般会检查一下df["capacity"].isnull().mean()，因为数据里常出现站点绑定了仓库但产能表缺行的情况。缺失比例超过 5% 时，不要直接 fillna(0)，先看是不是站点和仓库映射关系对不上，对不上的站点如果硬填 0，模型会学到“这个站点没有产能”的错误信号。常见做法是先填一个中位产能，再单独加一列 is_capacity_missing 标记，把缺失信息本身变成特征。2.2 训练与验证切分：按时间窗口切，别按行随机切时序预测任务的验证集切分是翻车重灾区。我见过有人直接用train_test_split(random_state=42)把数据打散，线上分数比本地验证高一大截，原因就是验证集里的“未来”混进了训练集。正确的做法是锁死时间边界，例如用最后 N 天做验证：# 按日期排序后切分 df = df.sort_values(["station_id", "date"]).reset_index(drop=True) cutoff_date = df["date"].max() - pd.Timedelta(days=14) train = df[df["date"] <= cutoff_date].copy() valid = df[df["date"] > cutoff_date].copy() # 检查两个集合的日期是否真的互斥 print(train["date"].max(), valid["date"].min())这里不要用随机种子切分。很多竞赛赛题要求预测未来 14 天，所以验证集也应该是最后连续的 14 天，和测试集的时间长度保持一致。一个容易被忽略的点：验证集的起始日不要选在周一或月初，最好覆盖一个完整自然周，否则节假日特征在验证集上的表现会失真。如果原始数据包含多个站点，切分后还要检查每个站点在验证集里是否都有记录。有些站点在最后 14 天可能完全没有订单，这类站点在训练集里也会缺少近期样本，需要单独标记出来，否则模型对它们的预测会退化成全局均值。3. 特征工程：把时序信号变成监督特征3.1 滞后特征：让前 7 天、前 14 天开口说话时序预测最直接的信号就是过去的值。对站点 i 在日期 t 的需求量，滞后特征就是y_{t-1}、y_{t-7}、y_{t-14}。为什么要选 7 和 14？因为物流需求有强周期，周一是峰值、周日是谷值，7 天前的同一天最像今天。写出来不复杂：for lag in [1, 7, 14]: df[f"lag_{lag}"] = df.groupby("station_id")["order_qty"].shift(lag)shift 是按 groupby 分组的，这一点不能省——如果不分组直接 shift，会把上一个站点的值串到当前站点，模型直接学歪。滞后列生成后要检查空值比例，lag_14在训练集前 14 天一定是 NaN，常见做法是用该站点历史均值填充，同时加一列is_lag_14_missing告诉模型“这里缺值”。滞后特征构造好之后，花点时间看一眼相关性：用df[["order_qty", "lag_1", "lag_7", "lag_14"]].corr()确认 lag_1 和相关性强，而 lag_7 次之。如果 lag_1 相关性弱于 lag_7，说明数据本身波动大、不稳定，这种情况可以考虑对原始序列做 log1p 平滑后再做滞后。3.2 滚动统计：均值、标准差与窗口选择滞后特征只给了离散几个时间点，滚动统计则能刻画近期趋势。最常见的组合是过去 7 天均值、过去 14 天均值和过去 7 天标准差。标准差这个特征很容易被忽略，但它对分仓规划特别有用——站点需求波动大，意味着仓库产能预留不能卡得太死。df["rolling_mean_7"] = ( df.groupby("station_id")["order_qty"] .transform(lambda x: x.shift(1).rolling(7, min_periods=1).mean()) ) df["rolling_std_7"] = ( df.groupby("station_id")["order_qty"] .transform(lambda x: x.shift(1).rolling(7, min_periods=1).std()) )注意这里用了shift(1)再滚动，核心目的是防止信息泄漏：计算 t 日的滚动均值只能用 t 日之前的数据，如果把 t 日本身算进去，模型在训练时“偷看”了当天的答案，验证时就没有这个条件，分数会虚高。min_periods=1用于在序列开头尽量少留空洞，但对前 7 天，滚动均值实际是近 2~6 天的均值，模型会自动学着调整权重，不需要额外处理。窗口选 7 还是 14，看业务节奏。电商大促场景周期拉长，用 14 天更稳；日常备货 7 天足够。也可以同时做两个窗口让模型自己选，代价是特征数量和训练时间涨一截。3.3 日期特征与外部变量：周末、月初和节假日日期特征是成本最低却最有效的信号之一。星期几（周一~周日）、是否为月初/月末、是否为节假日，这些直接决定了需求曲线的形状。代码很直接：df["weekday"] = df["date"].dt.weekday df["is_month_start"] = df["date"].dt.is_month_start.astype(int) df["is_weekend"] = (df["weekday"] >= 5).astype(int) # 节假日表如果有，合并进来 if holiday_df is not None: df = df.merge(holiday_df, on="date", how="left") df["is_holiday"] = df["is_holiday"].fillna(0).astype(int)星期几建议用整数编码而不是 one-hot，树模型对有序整数特征的处理更高效，而且周一和周日对预测的影响是近似的，整数编码可以保留这种近邻关系。节假日要特别注意滞后特征的空洞——大促前一天的需求往往异常高，前 7 天均值被拉高后，节后预测容易整体偏高。解决办法是加一个“距离最近节假日天数”的特征，或者在大促窗口内把滚动窗口强制拉长到 14 天。站点属性表的类别特征，比如站点所属区域、绑定仓库类型，用标签编码即可。如果类别数量多且每个类别的样本量足够，可以试一下目标编码（用历史均值代替类别），但必须要在训练集内部做交叉验证编码，否则同样会泄漏。4. 建模与融合：从单模型基线到加权平均4.1 基线模型：LightGBM 的标准姿势这类表格型时序预测任务，第一梯队仍然是 GBDT 系模型，LightGBM 是应用最顺手的。先搭一个标准基线，不要一上来就调参：import lightgbm as lgb features = [ "lag_1", "lag_7", "lag_14", "rolling_mean_7", "rolling_std_7", "weekday", "is_month_start", "is_weekend", "is_holiday", "区域编码", "仓库编码", ] X_train = train[features] y_train = train["order_qty"] X_valid = valid[features] y_valid = valid["order_qty"] model = lgb.LGBMRegressor( objective="regression", metric="rmse", learning_rate=0.05, max_depth=6, num_leaves=31, n_estimators=2000, verbose=-1, ) model.fit( X_train, y_train, eval_set=[(X_valid, y_valid)], callbacks=[lgb.early_stopping(100), lgb.log_evaluation(200)], )objective用 regression 而不是 regression_l1，因为赛题评分通常落在绝对误差和平方误差的加权组合上，RMSE 更贴近；max_depth=6, num_leaves=31是一个保守起步组合，能避免一开始就过拟合。learning_rate=0.05配合n_estimators=2000和早停，比直接调大学习率更稳。一个实用的习惯：模型训练完用model.feature_importances_看一遍特征重要性排序。如果lag_1排不进前五，说明这个站点的需求没有短期延续性，反而是周几和节假日特征主导——这时候要回头检查是不是聚合粒度出了问题。4.2 多模型加权融合：先看相关性再谈融合单模型调参到一定程度会有天花板，竞赛场景下提分最稳定的手段是融合。融合的前提是模型之间有差异：一个是树模型，一个可以是线性模型或者 MLP。不要融合两个只是参数不同的 LightGBM——它们相关性太高，融合收益趋近于零。# 引入第二个模型：岭回归（对线性趋势敏感） from sklearn.linear_model import Ridge ridge = Ridge(alpha=1.0) ridge.fit(X_train, y_train) pred_ridge = ridge.predict(X_valid) pred_lgb = model.predict(X_valid) # 在验证集上搜索最优权重 from scipy.optimize import minimize_scalar def loss(w): return ((w * pred_lgb + (1 - w) * pred_ridge - y_valid) ** 2).mean() res = minimize_scalar(loss, bounds=(0, 1), method="bounded") best_w = res.x print(f"最优权重: {best_w:.2f}")融合权重不是拍脑袋定的，而是在验证集上最小化误差搜索出来。这里我把权重限制在 0 到 1 之间，避免出现负权重这种不可解释的组合。如果最优权重接近 0.5，说明两个模型各有优势；如果最优权重是 0.95 以上，那第二个模型基本没用，还不如不融合。跑融合前先算两个模型预测的相关系数np.corrcoef(pred_lgb, pred_ridge)[0, 1]。相关系数高于 0.95，大概率融合后分数纹丝不动；低于 0.85 时融合通常有效。我在一个模拟项目里见过，LightGBM 和岭回归的相关系数只有 0.72，融合后验证集误差直接降了 8%，这就是差异化的价值。4.3 预测结果的数值校准树模型输出的是训练集目标分布的拟合值，当目标变量右偏严重（少数大促日拉了均值），预测值会系统性偏低。常见处理是训练时对 y 取 log1p，预测后再 expm1 还原：y_train_log = np.log1p(y_train) model.fit(X_train, y_train_log, eval_set=[(X_valid, np.log1p(y_valid))]) pred = np.expm1(model.predict(X_valid))这个操作对波动大的站点特别有效。用 log1p 之后，模型优化的目标从绝对误差变成了相对误差，大促日的权重被拉低，平时日的预测精度提高。注意还原之后不要忘记对预测值做下限截断，比如np.maximum(pred, 0)，避免出现负需求量这种业务上不可能的值。5. 常见问题与排查：从数据泄漏到融合失效的翻车现场5.1 验证集分数虚高，线上瞬间打回原形现象：本地验证集 RMSE 很低，一提交测试集分数差到离谱。原因：训练集和验证集不是按时间切分，随机打散后模型在训练时已经看到过“未来”的样本；或者滚动统计特征没有 shift，当天值参与了当天预测。解决：强制按时间窗口切分，特征构造统一走同一个函数，并且每次构造完随机抽 50 行人工检查有没有未来信息混入。从那以后我养成一个强迫症：所有特征工程代码只允许输入截止到 t 日的数据，任何涉及 t+1 的操作一律视为 bug。5.2 滞后特征全是 NaN，模型直接学了个寂寞现象：lag_7 和 lag_14 的覆盖率极低，特征重要性第一名的is_lag_14_missing是一个假信号。原因：groupby 列写错，或者原始表的站点 ID 在前后日期不一致，导致 shift 跨站点串行。解决：先用df.groupby("station_id")["date"].count()检查每个站点的日期连续性，如果某站点中间断档，lag_14 实际上是 14 天前另一个站点的值。对断档日期做插值或者直接丢弃该站点的滞后特征，比填 0 更靠谱。检查 groupby 是否正确最简单的方式是看NaN的分布——正常情况下只有每个站点前 14 行为 NaN，如果随机出现在中间行，一定是站点 ID 对齐出了问题。5.3 加权融合后误差反而变大现象：单模型甲 RMSE=10，单模型乙 RMSE=11，融合后 RMSE=12。原因：两个模型错误模式高度一致，且模型乙比模型甲在某个子集上更差，加权平均把这个子集的误差放大了。解决：看两个模型预测值的散点图，x 轴是真实值，y 轴是预测值，如果两模型的偏移方向相同，融合无效；如果偏移方向相反，融合才有空间。更可靠的融合策略是按站点分组做权重：高波动站点用树模型权重 0.7，平稳站点用岭回归权重 0.5。融合不是目的，找到互补的模型才是。5.4 分仓结果频繁触发产能超限现象：预测误差很小，但分仓方案在仿真里每天都有仓库爆仓。原因：模型优化的是整体均方误差，但考核的瓶颈在最差的仓库上；均方误差低不代表极端日期的峰值预测准确。解决：在预测阶段对每个仓库的日总量单独做一层校准，把预测值按仓库维度除以一个系数，让每天各仓库的预测总量不超过其产能总和。具体做法是把仓库日产能也做成特征，拟合时加一个权重列，误差超过产能阈值的样本权重加倍。这个操作用了之后分仓方案的超限次数能降一半。6. 分仓规划落地：把预测值变成可执行的备货方案预测做完，最后一步是把每天每个站点的需求分配到具体仓库。我把这个环节实现成一个贪心分配函数，每一轮优先处理预测需求量最大的站点，把它挂到当天剩余产能最多的仓库：def assign_warehouse(pred_df, capacity_df, station_wh_map): plan = {} for date, group in pred_df.groupby("date"): # 按预测需求降序排，先处理高需求站点 group = group.sort_values("pred_qty", ascending=False) remain_cap = capacity_df.set_index("warehouse_id")["cap"].to_dict() date_plan = [] for row in group.itertuples(): candidates = station_wh_map[row.station_id] # 挑一个剩余产能最大的仓库 best_wh = max(candidates, key=lambda w: remain_cap.get(w, 0)) alloc = min(row.pred_qty, remain_cap.get(best_wh, 0)) date_plan.append((row.station_id, best_wh, alloc)) remain_cap[best_wh] -= alloc plan[date] = date_plan return plan这个函数的核心是“按需排队，找富余产能仓库”。站点和仓库是多对一映射时逻辑简单，一对多时要考虑优先级，我的习惯是优先选距离最近且当天剩余产能不低于需求 80% 的仓库，这样避免出现一个小站点跨三个仓库拆单的场景。验证分仓方案是否合理，我只看两个数字：产能利用率和未满足率。用当天的真实需求（验证集里拿）去对照分配结果，计算每个仓库的利用率分布以及整体未满足率。利用率低于 50% 的仓库说明分配保守，未满足率超过 5% 说明预测低估或者产能模型太死。这两个数字就是分仓方案的体检报告。这条链路走下来，从数据合并、时序特征构造、建模融合到分仓分配，每一环都有它的坑。最值钱的经验是我每次切验证集前都强制走一遍“时间轴对齐检查”——把所有特征构造函数跑在测试集时间范围上，确认没有用到未来任何信息，然后再看分数。赛题资源里给的代码骨架和数据处理脚本，基本上修完这几个坑就能直接跑出可提交的结果。希望帮到你。本文还有配套的精品资源，点击获取
简介：这是一份天池大数据竞赛“菜鸟需求预测与分仓规划”赛题的实操代码包，面向参加数据挖掘竞赛或关注供应链预测的开发者，解决从数据清洗、特征工程到分仓建模与融合预测的完整链路。压缩包共68个文件，包含58个Python脚本、6个SQL查询、2个CSV结果、1个R脚本和1个说明文档，覆盖数据预处理、特征构建、模型训练、结果评估等环节，其中XGBoost、GBDT、随机森林、SVR线性核与RBF核均有对应实现，并按单仓独立建模思路组织目录。资源仅133KB，代码轻量、结构清晰，便于直接运行和二次改造。已有2339人学习下载，适合正在备赛或想复现此类方案的分析师参考。通过该资源可掌握回归模型融合的常用写法、分仓规划的工程化落地方法，以及天池赛题从SQL取数到提交结果的完整流程，是一份实用且浓缩的赛题开源方案。1. 先拆清赛题：需求预测与分仓规划到底在考什么这类智慧供应链赛题我拆过不止一次，表面看是两段式任务——先预测未来某段时间每个站点的包裹需求量，再根据预测结果做分仓规划；实际上，绝大多数参赛者摔跤都摔在同一个地方：把时间序列问题当成普通回归问题来做，随机切分训练集、不做滞后特征、融合只看分数不看相关性。赛题给的原始数据通常是一张订单流水主表加若干维度表，字段不外乎站点ID、品类、日期、需求量、仓库产能上限。你需要输出的东西也清楚：一份逐日逐站点的需求预测量，以及一份满足各仓库产能约束的分配方案。适合谁？想正经打一场数据竞赛、或者在做供应链计划类项目的人。第一眼看上去模型选型决定成败，跑到后面你会发现，特征对齐和验证集设计比模型重要一个量级——这篇就把整条链路的做法拆开讲。2. 数据准备：从主表到训练样本的关键动作2.1 多表合并：先定粒度再定主键拿到原始数据后第一件事不是跑模型，而是把所有表读进来，确认每一张表的粒度。这类赛题通常会有三到四张表：订单明细表（一行一个订单或一行一个站点某日汇总）、站点属性表、仓库产能表，有时还带一个假日表。我先用一个示例把最常见的合并逻辑写出来：import pandas as pd # 订单明细表：站点ID、日期、订单量 orders = pd.read_csv("orders.csv", parse_dates=["date"]) # 站点维度表：站点ID、所属区域、绑定仓库ID stations = pd.read_csv("stations.csv") # 仓库产能表：仓库ID、日期、日产能上限 warehouse = pd.read_csv("warehouse.csv") # 先按站点+日期聚合，得到每日需求量 daily = orders.groupby(["station_id", "date"], as_index=False)["order_qty"].sum() # 关联站点维度，拿到区域和仓库映射 df = daily.merge(stations, on="station_id", how="left") # 关联仓库产能，注意这里两个表都有日期维度 df = df.merge(warehouse, on=["warehouse_id", "date"], how="left") print(df.head())这段代码里有一个关键顺序：先聚合再合并。如果先把订单表和站点表做大笛卡尔积再聚合，数据量会膨胀到没法处理。合并时要注意 how 参数，订单明细表是主表，必须用 left，不能用 inner——如果某天某站点没有订单，inner 会直接把这一行丢掉，预测时就少了对零需求样本的学习。关联仓库产能表时我一般会检查一下df["capacity"].isnull().mean()，因为数据里常出现站点绑定了仓库但产能表缺行的情况。缺失比例超过 5% 时，不要直接 fillna(0)，先看是不是站点和仓库映射关系对不上，对不上的站点如果硬填 0，模型会学到“这个站点没有产能”的错误信号。常见做法是先填一个中位产能，再单独加一列 is_capacity_missing 标记，把缺失信息本身变成特征。2.2 训练与验证切分：按时间窗口切，别按行随机切时序预测任务的验证集切分是翻车重灾区。我见过有人直接用train_test_split(random_state=42)把数据打散，线上分数比本地验证高一大截，原因就是验证集里的“未来”混进了训练集。正确的做法是锁死时间边界，例如用最后 N 天做验证：# 按日期排序后切分 df = df.sort_values(["station_id", "date"]).reset_index(drop=True) cutoff_date = df["date"].max() - pd.Timedelta(days=14) train = df[df["date"] <= cutoff_date].copy() valid = df[df["date"] > cutoff_date].copy() # 检查两个集合的日期是否真的互斥 print(train["date"].max(), valid["date"].min())这里不要用随机种子切分。很多竞赛赛题要求预测未来 14 天，所以验证集也应该是最后连续的 14 天，和测试集的时间长度保持一致。一个容易被忽略的点：验证集的起始日不要选在周一或月初，最好覆盖一个完整自然周，否则节假日特征在验证集上的表现会失真。如果原始数据包含多个站点，切分后还要检查每个站点在验证集里是否都有记录。有些站点在最后 14 天可能完全没有订单，这类站点在训练集里也会缺少近期样本，需要单独标记出来，否则模型对它们的预测会退化成全局均值。3. 特征工程：把时序信号变成监督特征3.1 滞后特征：让前 7 天、前 14 天开口说话时序预测最直接的信号就是过去的值。对站点 i 在日期 t 的需求量，滞后特征就是y_{t-1}、y_{t-7}、y_{t-14}。为什么要选 7 和 14？因为物流需求有强周期，周一是峰值、周日是谷值，7 天前的同一天最像今天。写出来不复杂：for lag in [1, 7, 14]: df[f"lag_{lag}"] = df.groupby("station_id")["order_qty"].shift(lag)shift 是按 groupby 分组的，这一点不能省——如果不分组直接 shift，会把上一个站点的值串到当前站点，模型直接学歪。滞后列生成后要检查空值比例，lag_14在训练集前 14 天一定是 NaN，常见做法是用该站点历史均值填充，同时加一列is_lag_14_missing告诉模型“这里缺值”。滞后特征构造好之后，花点时间看一眼相关性：用df[["order_qty", "lag_1", "lag_7", "lag_14"]].corr()确认 lag_1 和相关性强，而 lag_7 次之。如果 lag_1 相关性弱于 lag_7，说明数据本身波动大、不稳定，这种情况可以考虑对原始序列做 log1p 平滑后再做滞后。3.2 滚动统计：均值、标准差与窗口选择滞后特征只给了离散几个时间点，滚动统计则能刻画近期趋势。最常见的组合是过去 7 天均值、过去 14 天均值和过去 7 天标准差。标准差这个特征很容易被忽略，但它对分仓规划特别有用——站点需求波动大，意味着仓库产能预留不能卡得太死。df["rolling_mean_7"] = ( df.groupby("station_id")["order_qty"] .transform(lambda x: x.shift(1).rolling(7, min_periods=1).mean()) ) df["rolling_std_7"] = ( df.groupby("station_id")["order_qty"] .transform(lambda x: x.shift(1).rolling(7, min_periods=1).std()) )注意这里用了shift(1)再滚动，核心目的是防止信息泄漏：计算 t 日的滚动均值只能用 t 日之前的数据，如果把 t 日本身算进去，模型在训练时“偷看”了当天的答案，验证时就没有这个条件，分数会虚高。min_periods=1用于在序列开头尽量少留空洞，但对前 7 天，滚动均值实际是近 2~6 天的均值，模型会自动学着调整权重，不需要额外处理。窗口选 7 还是 14，看业务节奏。电商大促场景周期拉长，用 14 天更稳；日常备货 7 天足够。也可以同时做两个窗口让模型自己选，代价是特征数量和训练时间涨一截。3.3 日期特征与外部变量：周末、月初和节假日日期特征是成本最低却最有效的信号之一。星期几（周一~周日）、是否为月初/月末、是否为节假日，这些直接决定了需求曲线的形状。代码很直接：df["weekday"] = df["date"].dt.weekday df["is_month_start"] = df["date"].dt.is_month_start.astype(int) df["is_weekend"] = (df["weekday"] >= 5).astype(int) # 节假日表如果有，合并进来 if holiday_df is not None: df = df.merge(holiday_df, on="date", how="left") df["is_holiday"] = df["is_holiday"].fillna(0).astype(int)星期几建议用整数编码而不是 one-hot，树模型对有序整数特征的处理更高效，而且周一和周日对预测的影响是近似的，整数编码可以保留这种近邻关系。节假日要特别注意滞后特征的空洞——大促前一天的需求往往异常高，前 7 天均值被拉高后，节后预测容易整体偏高。解决办法是加一个“距离最近节假日天数”的特征，或者在大促窗口内把滚动窗口强制拉长到 14 天。站点属性表的类别特征，比如站点所属区域、绑定仓库类型，用标签编码即可。如果类别数量多且每个类别的样本量足够，可以试一下目标编码（用历史均值代替类别），但必须要在训练集内部做交叉验证编码，否则同样会泄漏。4. 建模与融合：从单模型基线到加权平均4.1 基线模型：LightGBM 的标准姿势这类表格型时序预测任务，第一梯队仍然是 GBDT 系模型，LightGBM 是应用最顺手的。先搭一个标准基线，不要一上来就调参：import lightgbm as lgb features = [ "lag_1", "lag_7", "lag_14", "rolling_mean_7", "rolling_std_7", "weekday", "is_month_start", "is_weekend", "is_holiday", "区域编码", "仓库编码", ] X_train = train[features] y_train = train["order_qty"] X_valid = valid[features] y_valid = valid["order_qty"] model = lgb.LGBMRegressor( objective="regression", metric="rmse", learning_rate=0.05, max_depth=6, num_leaves=31, n_estimators=2000, verbose=-1, ) model.fit( X_train, y_train, eval_set=[(X_valid, y_valid)], callbacks=[lgb.early_stopping(100), lgb.log_evaluation(200)], )objective用 regression 而不是 regression_l1，因为赛题评分通常落在绝对误差和平方误差的加权组合上，RMSE 更贴近；max_depth=6, num_leaves=31是一个保守起步组合，能避免一开始就过拟合。learning_rate=0.05配合n_estimators=2000和早停，比直接调大学习率更稳。一个实用的习惯：模型训练完用model.feature_importances_看一遍特征重要性排序。如果lag_1排不进前五，说明这个站点的需求没有短期延续性，反而是周几和节假日特征主导——这时候要回头检查是不是聚合粒度出了问题。4.2 多模型加权融合：先看相关性再谈融合单模型调参到一定程度会有天花板，竞赛场景下提分最稳定的手段是融合。融合的前提是模型之间有差异：一个是树模型，一个可以是线性模型或者 MLP。不要融合两个只是参数不同的 LightGBM——它们相关性太高，融合收益趋近于零。# 引入第二个模型：岭回归（对线性趋势敏感） from sklearn.linear_model import Ridge ridge = Ridge(alpha=1.0) ridge.fit(X_train, y_train) pred_ridge = ridge.predict(X_valid) pred_lgb = model.predict(X_valid) # 在验证集上搜索最优权重 from scipy.optimize import minimize_scalar def loss(w): return ((w * pred_lgb + (1 - w) * pred_ridge - y_valid) ** 2).mean() res = minimize_scalar(loss, bounds=(0, 1), method="bounded") best_w = res.x print(f"最优权重: {best_w:.2f}")融合权重不是拍脑袋定的，而是在验证集上最小化误差搜索出来。这里我把权重限制在 0 到 1 之间，避免出现负权重这种不可解释的组合。如果最优权重接近 0.5，说明两个模型各有优势；如果最优权重是 0.95 以上，那第二个模型基本没用，还不如不融合。跑融合前先算两个模型预测的相关系数np.corrcoef(pred_lgb, pred_ridge)[0, 1]。相关系数高于 0.95，大概率融合后分数纹丝不动；低于 0.85 时融合通常有效。我在一个模拟项目里见过，LightGBM 和岭回归的相关系数只有 0.72，融合后验证集误差直接降了 8%，这就是差异化的价值。4.3 预测结果的数值校准树模型输出的是训练集目标分布的拟合值，当目标变量右偏严重（少数大促日拉了均值），预测值会系统性偏低。常见处理是训练时对 y 取 log1p，预测后再 expm1 还原：y_train_log = np.log1p(y_train) model.fit(X_train, y_train_log, eval_set=[(X_valid, np.log1p(y_valid))]) pred = np.expm1(model.predict(X_valid))这个操作对波动大的站点特别有效。用 log1p 之后，模型优化的目标从绝对误差变成了相对误差，大促日的权重被拉低，平时日的预测精度提高。注意还原之后不要忘记对预测值做下限截断，比如np.maximum(pred, 0)，避免出现负需求量这种业务上不可能的值。5. 常见问题与排查：从数据泄漏到融合失效的翻车现场5.1 验证集分数虚高，线上瞬间打回原形现象：本地验证集 RMSE 很低，一提交测试集分数差到离谱。原因：训练集和验证集不是按时间切分，随机打散后模型在训练时已经看到过“未来”的样本；或者滚动统计特征没有 shift，当天值参与了当天预测。解决：强制按时间窗口切分，特征构造统一走同一个函数，并且每次构造完随机抽 50 行人工检查有没有未来信息混入。从那以后我养成一个强迫症：所有特征工程代码只允许输入截止到 t 日的数据，任何涉及 t+1 的操作一律视为 bug。5.2 滞后特征全是 NaN，模型直接学了个寂寞现象：lag_7 和 lag_14 的覆盖率极低，特征重要性第一名的is_lag_14_missing是一个假信号。原因：groupby 列写错，或者原始表的站点 ID 在前后日期不一致，导致 shift 跨站点串行。解决：先用df.groupby("station_id")["date"].count()检查每个站点的日期连续性，如果某站点中间断档，lag_14 实际上是 14 天前另一个站点的值。对断档日期做插值或者直接丢弃该站点的滞后特征，比填 0 更靠谱。检查 groupby 是否正确最简单的方式是看NaN的分布——正常情况下只有每个站点前 14 行为 NaN，如果随机出现在中间行，一定是站点 ID 对齐出了问题。5.3 加权融合后误差反而变大现象：单模型甲 RMSE=10，单模型乙 RMSE=11，融合后 RMSE=12。原因：两个模型错误模式高度一致，且模型乙比模型甲在某个子集上更差，加权平均把这个子集的误差放大了。解决：看两个模型预测值的散点图，x 轴是真实值，y 轴是预测值，如果两模型的偏移方向相同，融合无效；如果偏移方向相反，融合才有空间。更可靠的融合策略是按站点分组做权重：高波动站点用树模型权重 0.7，平稳站点用岭回归权重 0.5。融合不是目的，找到互补的模型才是。5.4 分仓结果频繁触发产能超限现象：预测误差很小，但分仓方案在仿真里每天都有仓库爆仓。原因：模型优化的是整体均方误差，但考核的瓶颈在最差的仓库上；均方误差低不代表极端日期的峰值预测准确。解决：在预测阶段对每个仓库的日总量单独做一层校准，把预测值按仓库维度除以一个系数，让每天各仓库的预测总量不超过其产能总和。具体做法是把仓库日产能也做成特征，拟合时加一个权重列，误差超过产能阈值的样本权重加倍。这个操作用了之后分仓方案的超限次数能降一半。6. 分仓规划落地：把预测值变成可执行的备货方案预测做完，最后一步是把每天每个站点的需求分配到具体仓库。我把这个环节实现成一个贪心分配函数，每一轮优先处理预测需求量最大的站点，把它挂到当天剩余产能最多的仓库：def assign_warehouse(pred_df, capacity_df, station_wh_map): plan = {} for date, group in pred_df.groupby("date"): # 按预测需求降序排，先处理高需求站点 group = group.sort_values("pred_qty", ascending=False) remain_cap = capacity_df.set_index("warehouse_id")["cap"].to_dict() date_plan = [] for row in group.itertuples(): candidates = station_wh_map[row.station_id] # 挑一个剩余产能最大的仓库 best_wh = max(candidates, key=lambda w: remain_cap.get(w, 0)) alloc = min(row.pred_qty, remain_cap.get(best_wh, 0)) date_plan.append((row.station_id, best_wh, alloc)) remain_cap[best_wh] -= alloc plan[date] = date_plan return plan这个函数的核心是“按需排队，找富余产能仓库”。站点和仓库是多对一映射时逻辑简单，一对多时要考虑优先级，我的习惯是优先选距离最近且当天剩余产能不低于需求 80% 的仓库，这样避免出现一个小站点跨三个仓库拆单的场景。验证分仓方案是否合理，我只看两个数字：产能利用率和未满足率。用当天的真实需求（验证集里拿）去对照分配结果，计算每个仓库的利用率分布以及整体未满足率。利用率低于 50% 的仓库说明分配保守，未满足率超过 5% 说明预测低估或者产能模型太死。这两个数字就是分仓方案的体检报告。这条链路走下来，从数据合并、时序特征构造、建模融合到分仓分配，每一环都有它的坑。最值钱的经验是我每次切验证集前都强制走一遍“时间轴对齐检查”——把所有特征构造函数跑在测试集时间范围上，确认没有用到未来任何信息，然后再看分数。赛题资源里给的代码骨架和数据处理脚本，基本上修完这几个坑就能直接跑出可提交的结果。希望帮到你。本文还有配套的精品资源，点击获取