简介面向智能仓储网络库存管理赛题的初赛数据包聚焦电商“211”时效下的销量预测与区域配送中心、前置仓多级库存调拨决策适合物流供应链、机器学习及运筹优化方向学生、参赛者与研究者复现赛题、支撑论文实验。资源共15个文件以10个数据表格文件为主涵盖商品属性、历史销量、促销信息、库存分布、补货记录及需求分位等字段另有3个脚本程序、1个字节码文件和1个说明文档分别承担数据处理、仿真模拟与提交示例功能。压缩包总大小16.62MB轻量但覆盖完整建模链路。目前已有1151人学习使用。利用这份数据可先训练第一阶段销量预测模型再基于预测结果设计第二阶段调拨与补货策略通过多轮仿真评估各仓库存平衡效果完整还原从需求预测到运筹优化的全过程非常适合物流算法入门与进阶实战。1. JDGOC初赛数据不只是给你一张库存表而是一个仓储网络决策问题JDGOC初赛数据仓储网络智能库存管理很多人第一次打开压缩包时以为就是几张大表——仓库ID、商品ID、日期、库存量跑个回归就能提交。实际做进去你会发现这是一张把“多仓、多门店、多时间段”压在一起的后勤决策网络每个仓库的期初库存、到货计划、销量、退货混在一起模型要给出的不是下一时刻的库存数值而是每个仓库每种商品该在什么时点补多少货。这个赛题更适合被当成一个“决策优化 预测”的组合题而不是纯表格回归。适合三类人想拿名次的竞赛选手、做供应链计划但只看过报表的业务分析师、以及准备把库存管理做成数据产品的后端工程师。先别急着调参把数据里的网络结构看清比模型换什么更重要。2. 先搞懂仓储网络智能库存管理的数据故事从网络结构到库存记录的字段含义2.1 拆解初赛数据里的网络拓扑仓库、门店、配送关系怎么表达仓储网络这个词不是白给的。初赛数据里通常会出现两类主表一类是“仓库-门店-商品”的配送关系表另一类是每天的库存与销售流水表。关系表里每个仓库不一定服务所有门店而是有固定的覆盖范围这个范围就是网络拓扑。处理时第一步就是把这张关系表画成邻接矩阵或者字典别用Excel筛选代码更可靠。import pandas as pd # 读取配送关系表warehouse_id 是仓库store_id 是门店lead_time 是到货天数 rel pd.read_csv(data/warehouse_store_rel.csv) rel rel.drop_duplicates([warehouse_id, store_id]) # 构建仓库-门店的映射后续算网络级指标用 wh_to_stores rel.groupby(warehouse_id)[store_id].apply(list).to_dict() print(f仓库数量: {rel[warehouse_id].nunique()}, 门店数量: {rel[store_id].nunique()})逻辑说明这段代码先把配送关系表读进来并去重防止同一条配送线路在数据里被多次计数。然后用 groupby 把每个仓库覆盖的门店聚合成列表后续在特征工程阶段可以直接计算“一个仓库要服务多少门店”“某门店由几个仓库供货”。lead_time到货天数是库存决策里最关键的参数之一后面做补货阈值时要反复用到。参数说明如果关系表里没有 lead_time可以默认所有仓库到货周期一致但建议先查一下字段字典。表格里如果存在仓库覆盖门店的重叠就意味着一个门店可以从多个仓库补货这时“就近履约”的策略就不适用要把仓库维度合并成“仓库组”来建模。2.2 库存记录与需求序列哪些字段是“果”哪些字段是“因”库存流水表通常至少包含日期、仓库ID、商品SKU、期初库存、入库量、出库量销量或发货量、期末库存。很多选手直接拿期末库存当预测目标这是常见的坑。期末库存是由期初库存 入库 - 出库计算出来的它本身不是一个独立事件而是前序决策的结果。真正需要预测的是需求出库量库存值是“状态”而不是“目标”。我的处理方法是把数据拆成三个不同性质的序列需求序列出库量、补货到达序列入库量、库存状态序列期末库存。其中需求序列是模型输入输出都要用的核心补货到达序列是你算法可以控制的决策库存状态序列是验证约束是否被满足的检查项。三者的时间对齐很容易出错建议每次都在合并前先看一眼时间范围。# 读取库存流水并拆出关键序列 inv pd.read_csv(data/inventory_daily.csv, parse_dates[date]) inv[demand] inv[out_qty] # 出库量近似市场需求 inv[arrival] inv[in_qty] # 到货量即我们可控的补货 inv[stock_end] inv[stock_start] inv[arrival] - inv[demand] # 验证等式是否成立不成立说明有退货或损耗字段被忽视 check ((inv[stock_end] - inv[stock_start] - inv[arrival] inv[demand]).abs() 0.001).mean() print(f不匹配比例: {check:.4f})逻辑说明这段代码把库存流水拆出需求、到货、期末库存三个序列并利用恒等式做校验。如果 check 值大于 1%说明原始数据存在退货、盘点调整或损耗字段你没有纳入计算后续特征会带噪。这种数据审计动作必须在特征工程前完成否则模型学到的“规律”很多是数据录入错误造成的假象。参数说明out_qty 字段在部分初赛数据里可能叫 sale_qty 或 ship_qty含义可能是销量也可能包含调拨出库需要结合门店的销售记录判断。如果只想做网络级库存管理可以把同一天同一个仓库同一个SKU的多条记录聚合通常按“仓库SKUdate”汇总出库量和入库量。2.3 数据集的规模与时间切片训练集合测试集合怎么切用透视表快速验证比赛给的初赛数据一般会分成训练期和预测期。训练期给你完整的历史需求、库存、补货记录预测期只给到某个截止日之前的库存状态要求你提交从截止日后若干天的补货计划。很多人直接把最后 30% 时间当验证集这样会破坏时序。我建议按时间顺序切前 70% 时间做训练第 70%~85% 做验证调参最后的 15% 模拟测试集但这个比例要按总时间长度调整。inv[date] pd.to_datetime(inv[date]) train_end inv[date].quantile(0.7) val_end inv[date].quantile(0.85) train inv[inv[date] train_end] val inv[(inv[date] train_end) (inv[date] val_end)] test inv[inv[date] val_end] # 按仓库SKU检查时间覆盖度 coverage inv.groupby([warehouse_id, sku_id])[date].agg([min, max]) coverage[days] (coverage[max] - coverage[min]).dt.days print(coverage[days].describe())逻辑说明用 quantile 按时间切分能避免单仓库冷启动造成的偏差。输出 coverage 描述性统计是为了确认每个仓库和SKU组合是否在三个集合内都有数据如果部分组合只出现在训练期后面做预测时就没法为它们生成特征需要在特征工程里用全局数据兜底。参数说明0.7 和 0.85 只是常见划分如果总天数少于 60 天建议改为 0.6 和 0.8至少保证验证集有 12 天以上能覆盖一个补货周期。划分完之后把所有提交需要的时间窗口比如未来 7 天或 14 天锚定到测试集的最后一天不要忽略预测起点不同带来的特征差异。3. 把库存管理问题翻译成机器学习任务预测、优化还是仿真3.1 预测型做法需求预测 库存策略最常见的参赛方案是两段式先用梯度提升树或者时序模型预测未来一段时间的需求然后基于预测值套用安全库存公式计算出补货量。这个路线的保护在于它把所有复杂逻辑拆开每一步都能验证。需求预测部分可以沿用你熟悉的时间序列特征库存策略部分则是一个带阈值的规则——当预测库存低于安全库存时补到一个目标水平。def reorder_by_safety_stock(y_pred, current_stock, lead_time, service_level0.95): 基于预测需求的安全库存补货逻辑 y_pred: 未来 lead_time 天的逐日需求预测numpy数组 current_stock: 当前库存 forecast_demand y_pred.sum() safety_stock y_pred.std() * 1.65 # 95% 服务水平对应的安全系数 target_stock forecast_demand safety_stock reorder_qty max(0, target_stock - current_stock) return reorder_qty, safety_stock逻辑说明函数里 y_pred 是未来一个补货周期内每天的需求预测需要累加得到总需求。安全库存用预测标准差乘 1.65对应服务水平的 Z 值这个系数对结果影响很大调大安全库存会让缺货率下降但库存持有成本上升JDGOC 这类比赛的评分通常二者都要看不能只看缺货。返回的 reorder_qty 就是最终的补货量还需结合仓储上限截断。参数说明lead_time 来自配送关系表如果到货需要 3 天预测窗口就是 3 天。service_level 的取值最需要根据分数反馈来调常见范围在 0.90~0.98。这个函数没有考虑仓库容量后续需要在批次层面加约束。3.2 优化型做法安全库存与补货量直接回归另一种思路是把补货量当作监督学习的标签用历史补货决策和对应的成本结果来训练。但这条路径依赖一个前提历史补货决策是接近最优的。初赛数据里如果补货是人工制定的会有大量非理性操作比如促销日疯狂补货、月底为了考核清库存等直接回归会学到这些噪音。更可靠的做法是用模拟器给每个补货方案打分再用贝叶斯优化或网格搜索去寻找每个“仓库SKU”的最优补货参数。from scipy.optimize import minimize def cost_func(params, history): reorder_point, reorder_qty params # 模拟当库存低于 reorder_point 时补 reorder_qty total_shortage 0 total_inventory 0 stock history[stock_start].iloc[0] for d in range(len(history)): demand history[demand].iloc[d] stock - demand if stock 0: total_shortage -stock stock 0 total_inventory stock if stock reorder_point: stock reorder_qty return total_shortage * 10 total_inventory # 缺货惩罚10倍 # 用历史数据的一段做参数寻优 res minimize(cost_func, x0[20, 50], args(train.groupby(sku_id).head(200),), methodNelder-Mead) print(res.x)逻辑说明这里用一个很轻量的模拟器评估每个补货参数的效果缺货惩罚设为10持有成本为1这个比例可以根据赛题评分公式调整。minimize 找到的 reorder_point 和 reorder_qty 是该SKU历史片段上的局部最优参数。这种方法的缺点是不可推广到没出现过的SKU所以实际比赛中更适合对头部 SKU 做精细优化长尾 SKU 用预测型统一处理。参数说明惩罚比例 10 只是起点如果评分公式里缺货成本与持有成本权重是 5:1就改成 5。模拟器没有考虑补货到货延迟如果要更贴近现实需要把补货量加进一个 pending 队列N 天后再进入库存。3.3 我的选型把问题拆成“需求预测”和“库存参数寻优”两段在实际比赛里我一般不会只走一条路。我的做法是先用 3.1 的预测型方案跑通全流程拿到一个稳定可提交的基线然后针对预测误差比较大的仓库或SKU用 3.2 的模拟优化去调整库存参数最后把两套方案的结果按“仓库SKU日期”做融合规则很简单如果该组合历史需求波动小用安全库存法波动大用优化型参数。这样做的原因是JDGOC 初赛数据里不同SKU的需求模式差异悬殊有些是平稳快消品有些是长尾慢销品单一模型很难通吃。这个选型的核心收益是快速拿到第一个可提交结果同时保留进一步迭代的空间。对于新手我强烈建议先别碰深度强化学习那个需要写模拟环境而且调参的脾气不好捉摸。把梯度提升树和简单规则先用起来能解决这个赛题 80% 的分数空间。4. 特征工程与基线模型用最小代码把一个能提交的方案跑起来4.1 构建需求预测的最小特征集时间滑窗、趋势、季节性、仓库属性需求预测的特征不用过于复杂关键是能捕捉周期性和近期趋势。我会为每个“仓库SKU”生成过去 7 天、14 天、30 天的需求均值与标准差再加星期几、月份、是否月初/月末、仓库覆盖门店数等静态特征。def make_features(df): df df.sort_values([warehouse_id, sku_id, date]) g df.groupby([warehouse_id, sku_id])[demand] df[demand_lag1] g.shift(1) df[demand_lag7] g.shift(7) df[rolling_mean_7] g.transform(lambda x: x.rolling(7, min_periods3).mean().shift(1)) df[rolling_std_14] g.transform(lambda x: x.rolling(14, min_periods5).std().shift(1)) df[dow] df[date].dt.dayofweek df[is_month_end] (df[date].dt.is_month_end).astype(int) df[store_count] df[warehouse_id].map( rel.groupby(warehouse_id)[store_id].nunique() ) return df train_feat make_features(train.copy()).dropna()逻辑说明特征生成的关键是避免未来信息泄漏。shift(1) 确保用前一天及之前的数据预测当天需求rolling_mean 后面又加了一次 shift(1)因为 rolling 计算时包含了当天的需求如果不平移模型会偷看当天的答案。store_count 是仓库覆盖门店数反映网络规模对需求的影响。dropna 会把启动期数据丢掉只保留有足够历史的时间点。参数说明rolling_mean_7 的 min_periods3 表示不足 3 天时用可用数据计算适合数据存在零值缺口的场景。is_month_end 在做月末清仓或考核时很有效如果赛题评分不涉及月度周期可以去掉。这个特征集是基线用的后续加入更多特征时建议先做特征重要性排序别一上来就灌几十个维度。4.2 基线模型用 LightGBM 预测需求 固定补货阈值特征做好后模型部分直接使用 LightGBM它对数值特征和缺失值都很宽容速度也快。我通常把训练集的最后一段作为验证集来观察预测误差然后预测未来 N 天生成补货计划。补货阈值用“预测需求 0.5 倍预测标准差”这种保守设定。import lightgbm as lgb from sklearn.metrics import mean_absolute_error feat_cols [demand_lag1, demand_lag7, rolling_mean_7, rolling_std_14, dow, is_month_end, store_count] X train_feat[feat_cols] y train_feat[demand] model lgb.LGBMRegressor(n_estimators300, learning_rate0.05, num_leaves31, random_state42) model.fit(X, y) # 用最后 20 天做简单验证 valid train_feat[train_feat[date] train_feat[date].max() - pd.Timedelta(days20)] mae mean_absolute_error(valid[demand], model.predict(valid[feat_cols])) print(fMAE: {mae:.3f})逻辑说明LightGBM 的参数是经过权衡的n_estimators 300 配合 0.05 学习率能在欠拟合和过拟合之间找一个平衡点num_leaves 31 防止叶子过多导致模型记住训练集中的补货噪声。MAE 只是参考最终分数取决于补货后的库存总成本所以 MAE 低不代表方案得分高还需要走完补货评估流程。参数说明如果想更快可以把 n_estimators 降到 100学习率升到 0.1分数可能略降。random_state 固定是为了实验可复现。这个模型对零需求很多的长尾商品会输出很小的非零值容易造成过度补货建议在模型输出后做一步若预测需求小于 0.2直接置为 0。4.3 提交格式与评估函数先保证能跑通再谈精度很多选手在模型上投入大量精力最后卡在提交格式对不上。JDGOC 初赛通常要求提交一张补货计划表包含仓库ID、SKU、日期、补货量。有些赛题还要求按“发货日期”提交并限制每次补货只能有一个到货日。我建议先写一个能生成模拟提交的脚本跑通官方评估或本地评估再继续调优。test_latest inv[inv[date] inv[date].max()] submission [] for (wh, sku), grp in test_latest.groupby([warehouse_id, sku_id]): cur_stock grp[stock_end].iloc[0] # 简单用该组合历史均值作为预测 history train[(train[warehouse_id] wh) (train[sku_id] sku)] pred_daily history[demand].mean() if len(history) 0 else 0 pred_7d pred_daily * 7 reorder_qty max(0, pred_7d - cur_stock * 0.8) # 保留 80% 库存作为安全边际 submission.append({warehouse_id: wh, sku_id: sku, date: test_latest[date].max() pd.Timedelta(days1), reorder_qty: reorder_qty}) sub_df pd.DataFrame(submission) # 建议只保留补货量大于 0 的行测试集上全 0 也可以提交 print(sub_df.head())逻辑说明这个脚本用历史均值作为需求预测cur_stock * 0.8 表示不补到满库存留 20% 缓冲。它不优秀但能生成一个格式正确的提交文件。重点在于让提交的字段名与官方要求一致特别是 date 字段如果必须填多个日期需要循环生成。参数说明0.8 这个比例没有理论依据只是基线安全的习惯值。提交后再看反馈分数如果分数过低或出现负库存就调整这个比例或改为 0。做这一步的目标不是得高分而是确认整个管线——特征、模型、补货生成、提交——没有断点。5. JDGOC初赛避坑指南数据泄漏、超参数与补货策略的边界5.1 现象训练时的验证损失很低测试集分数却崩了原因用未来的数据构造了特征。常见错误是 rolling_mean 没有 shift或者使用了测试集时期的静态统计量。我记得有一次把安全库存里的标准差算成了全样本标准差导致验证集分数异常高因为系统偷看了未来的波动范围。解决所有时间窗口聚合函数都必须带 shift(1)且保证只使用截止到前一天的数据。写代码的时候可以把特征生成封装成一个函数测试时单独传入训练期和验证期避免数据集合并后再算特征。5.2 现象模型预测需求很准但库存成本分数不佳原因评分公式里缺货成本与持有成本不是 1:1你没有对齐权重。比如某 SKU 缺货一次罚 20每天持有一件商品成本 1你按缺货罚 10 去寻优补货就会偏少。解决先仔细看赛题说明里的成本系数如果没有说明用 baseline 的反推法跑一次固定补货量的提交观察线上分数波动幅度估算两种成本的比例。然后把这个比例代入 3.2 的模拟器重新寻优。5.3 现象补货量出现负数或超出仓储容量原因你的补货规则把 target_stock 减 current_stock 得到负数时没有截断或者忽略了仓库容量字段。初赛数据里仓库容量可能是一个独立表也可能标注在仓库属性里不读它就会产生不合法结果。解决补货量统一用 max(0, target - current) 截断再对每个仓库的 SKU 补货总量做缩放。如果仓库容量是 capacity可以把所有 SKU 的目标库存按比例压缩使得 sum(重补后库存) capacity。5.4 现象同一天同一个仓库同一个SKU出现多条记录原因原始流水是明细级别比如每个订单一行日期出现在下单、出库、退仓等多个环节直接合并会把需求翻倍。解决做题前先按“仓库SKU日期”检查重复度。如果有重复先按业务语义取 max出库量取最大量或 sum转储与销售分开记录时求和。最稳妥的方式是画出不同字段的数值分布若出现明显的双峰很可能包含退货单。5.5 现象本地验证分数和线上提交分数总是对不上原因本地评估脚本自己写的和官方评估逻辑不一致。比如本地缺货是按“当天需求量超过期初库存”来计算官方可能是按“补货计划全部执行完成后一天一次结算”二者在时点定义上有偏差。解决严格按照官方给出的评估公式实现一套本地评估并用样例输出验证。如果官方没有给就写一个最保守版本假设所有补货都在未来第一天到达需求按天消耗库存不足时记录缺货然后把两种方案的每日总成本加总。这个对齐过程值得花半天否则后面所有调参都像在瞎猜。6. 把分数再往上推的两个实操技巧滚动预测与滞后特征容错初赛分数到一个平台期后通常不是模型复杂度不够而是预测与执行之间的误差被放大。这里给出两个我常用的实操技巧都能直接补到现有代码里。第一个技巧滚动预测代替一次性预测。很多选手一次性预测未来 7 天需求然后直接算补货量。但 LightGBM 的误差会随预测时长累积。更好的做法是只预测未来 1 天把预测结果当作今天的需求模拟消耗然后更新库存状态再预测下一天逐步滚动到补货到货日。这个过程的计算开销大一些但对于波动大的 SKU 能明显减少过度补货。def rolling_forecast(model, features_fn, init_stock, horizon7): stock init_stock plan [] temp_df pd.DataFrame() for i in range(horizon): # 每步生成当天的滞后特征需用真实的 lag 值 feat features_fn(temp_df, stock) pred_y model.predict(feat[feat_cols])[0] pred_y max(0, pred_y) # 需求非负 stock max(0, stock - pred_y) plan.append(pred_y) temp_df temp_df.append({demand: pred_y}, ignore_indexTrue) return np.array(plan)逻辑说明滚动预测的要点是每步都要用前一步的预测结果来更新滞后特征否则还是静态预测。第 i 天的预测会作为 temp_df 中的 demand用于计算滞后一天的特征。stock 同时被消耗更新补货量可以放到到货日当天直接加库存。这个技巧对误差较大的长尾 SKU 特别明显因为单看一步的误差很小滚动起来不会叠加到爆。第二个技巧给滞后特征做容错。如果数据里某些天数缺失lag1 会变成空值模型会用全局均值填充导致预测偏高。解决方法是把 shift 得到的数列按“最近一天有值”来构造比如 lag1_missing 标记是否为缺失并把缺失时的 lag1 填成 lag7 的值。这个细节能让模型在遇到稀疏 SKU 时不至于乱来。df[lag1_raw] g.shift(1) df[lag7_raw] g.shift(7) df[lag1] df[lag1_raw].fillna(df[lag7_raw]).fillna(0) df[lag1_is_na] df[lag1_raw].isna().astype(int)逻辑说明fillna 的顺序决定了容错路径先用 lag7 填充能保持一定时序信息再用 0 兜底。lag1_is_na 让模型知道这个值是补出来的可以在训练时学习到“缺少数据”这一状态本身的含义。这个技巧在初赛数据出现长周末或节假日时很管用能避免一个零值拉低整段预测。我用这两个技巧把初赛线的分数稳定提升过几个百分点但都不是来自新增模型而是把执行细节做扎实。JDGOC 初赛数据里的坑大多是时序数据与决策输出之间的缝隙真正花时间的也在这里。竞赛之外这套滚动预测加容错特征的做法可以直接平移到真实的仓储网络补货系统里甚至比一部分商用库存软件的默认参数更稳。希望帮到你。本文还有配套的精品资源点击获取