补货规则)
简介JDGOC仓储网络智能库存管理初赛数据专为物流供应链、机器学习和运筹优化方向的学习者与参赛者准备。赛题背景源于京东全国近500个仓库的“211”时效履约场景需要在预测各区域商品需求的基础上通过调拨决策让库存合理分布于RDC与FDC完成两阶段建模仿真。包内含15个文件共16.62MB核心为10个CSV数据表覆盖SKU属性、历史销量、库存、促销、量化分位及需求分布等和3个Python脚本含仿真与提交模板另附说明文档与编译模块便于直接复现初赛流程。数据字段粒度细既有预测目标又有调拨约束适合多模型对比与时间序列分析。目前已有1152人学习浏览对想发表物流供应链论文或提升实战技能的同学是一份难得的从数据到仿真的全流程案例。1. JDGOC 初赛数据里的仓储网络库存管理先把赛题拆成看得见的两件事JDGOC 初赛这份仓储网络库存数据给的不是一堆打好标签的图片而是某张网络过去几十周里每个 SKU 在每个仓库的库存、需求、到货和调拨流水。表面看是数据竞赛本质上是让你用真实颗粒度的历史记录回答补多少、什么时候补、放在哪个仓这三个决策问题。对参赛者来说最划算的路径不是一上来就上强化学习而是先把「需求预测 补货规则」这条主链路跑通。适合谁准备冲榜单的选手、刚转供应链数据方向的工程师以及想把手工 Excel 补货表换成可计算策略的计划员。这篇文章就按这份数据把链路拆开讲一遍。2. 先读懂初赛数据的长相字段、粒度与时间边界2.1 仓储网络数据不是一张大宽表而是四张表拼出来的拿到 JDGOC 初赛数据第一件事不是写模型而是把文件解压后逐个看表头。仓储网络智能库存管理的数据通常按实体拆成四类时序主表、SKU 档案、仓库档案和网络参数。时序主表是核心记录每个 SKU 在每个仓库每天或每周的库存量、需求量、到货量和调拨量SKU 档案给的是品类、体积、保质期这类静态属性仓库档案给容量、仓库类型网络参数则藏着提前期、补货周期和各类成本系数。四类表不是生来能直接 join 的。不少初赛队伍把 SKU 档案里的品类维度直接按字符串塞进特征结果模型没学到规律反而把品类 ID 当成噪声。正确的做法是先确认每张表的主键和粒度SKU 档案的主键是 sku_id仓库档案是 warehouse_id时序主表则是 sku_id warehouse_id date 三个字段组成的复合主键。对齐粒度后再做特征才谈得上稳定性。下表是最常见的字段形态字段名在不同赛段可能略改但语义基本一致。我拿到每份新数据都会做一遍映射把字段名、语义、粒度和陷阱写进同一张表。原因很简单初赛数据字段在复赛和实际业务里也可能重命名只记单词不记语义换个壳就不认识。字段语义粒度常见陷阱sku_idSKU 编码SKU不要直接当数值特征warehouse_id仓库编码仓编码是 ID 不是大小date日期日/周时间切分不能乱stock_qty库存量SKU×仓×日日末还是期初要确认demand_qty需求量SKU×仓×日订单量还是出库量inbound_qty到货量SKU×仓×日下单量还是入库量transfer_qty调拨量SKU×仓×日调出为正还是为负2.2 口径检验用等式确认「日末库存」「出库需求」「入库到货」字段名看懂了不等于数据能直接用。同一个叫 stock 的字段可能是当日末结存也可能是次日清晨盘点值同一个 demand_qty可能是顾客订单量也可能是实际出库量inbound_qty 可能是下单量也可能是验收合格后的入库量。口径不同直接决定补货模拟里的订单要在哪一天生效。我的习惯是拿连续几行做等式检验昨日库存 今日到货 今日调出 - 今日需求 今日库存。数据里有调拨入和调拨出双向时公式里要把调拨净额也放进去。对不上的记录占比超过千分之一就得去查是不是漏了退货入、报废出或盘亏盘盈字段如果对得上说明口径严密可以放心用滞回特征。以下代码就是把这条等式落到 pandas 上的标准写法注意必须先按 SKU×仓×日期排序再分组取 shift(1)否则上一行根本不是前一天import pandas as pd df pd.read_csv(inventory_main.csv, parse_dates[date]) df df.sort_values([sku_id, warehouse_id, date]) g df.groupby([sku_id, warehouse_id]) df[last_stock] g[stock_qty].shift(1) # 假设数据已规范化需求为正数调拨量为净流入正为调进负为调出 df[calc_stock] ( df[last_stock] df[inbound_qty] df[transfer_qty] - df[demand_qty] ) df[diff] (df[calc_stock] - df[stock_qty]).abs() bad_ratio (df[diff] 1e-6).mean() print(库存等式不一致占比:, bad_ratio)这段代码里最需要解释的是 shift(1) 之前的排序。groupby 后的 shift(1) 取的是「同一个 SKU×仓组合里上一行的值」只有先按日期排序上一行才等于前一天。等式不平衡的记录占比超过千分之一时先不要急着改模型回头查原始 CSV 里是否有单独字段记录退货和报废把公式补全再做下一步。这一步的花费十分钟后面省下的排错时间是十倍不止。另外注意如果初赛数据把需求记成负数、调出记成正数要先把符号统一否则等式恒不成立。2.3 时间边界与网络参数预测起点、历史窗口、补货节奏时序数据最要紧的是划清两段时间可观测的完整历史期和需要预测的评测期。评测期起始日就是预测起点之后所有真实值都不能进入特征训练集和验证集必须按时间切不能随机打乱。初赛一般给出前几十周要求预测后几周或直接产出补货计划窗口长度直接影响模型能不能学到季节和促销模式。历史窗口的选取有两个极端。窗口太短模型只看到最近一两周遇到季度性品类就测不准窗口太长早期促销和缺货噪声把信号稀释。我一般先用 8~12 周滚动特征做一版 baseline再看验证期分段表现如果头两周准、后面几周差往往不是窗口问题而是模型没见过足够长的节假日形态需要在特征里补上日历字段和滞后若干周的同期对比。数据里如果有补货周期和提前期字段把它们单列出来。补货周期决定多久能下一次单提前期决定下单后多久到货两者直接参与补货模拟不读清这两项后面所有安全库存计算都是空中楼阁。可以把它们当成网络参数中的两个固定值不同的 SKU×仓可能有不同取值建模时先按众数统一处理最后再按分组差异微调。这一节做完你对这份数据的理解就足够支撑后续全部建模。3. 用 LightGBM 做一版需求预测基线特征、训练与回测一次跑通3.1 为什么先做需求预测库存决策的输入是未来需求补货决策依赖三件事当前库存、未来需求、提前期的到货节奏。当前库存从数据里直接读未来需求只能预测所以需求预测是整条链路里最需要花时间的部分。JDGOC 这类赛题评分最终落在缺货率和库存周转上但缺货率不会因为你把补货参数调到极致就消失预测的系统性偏差才是根因。需求预测有两个绕不开的特性。一是长尾大量 SKU 平时没销量偶尔一次性出几十件均值和方差都不可靠。二是层级结构单 SKU×仓的时间序列又短又抖但按 SKU 汇总之后规律明显。常见做法有两条路先做 SKU 级预测再按历史销量占比拆分到仓或者直接做 SKU×仓级预测在特征里带上 SKU 汇总量。我一般选后者因为后续补货模拟就在 SKU×仓粒度上跑直接预测能省去拆分误差树模型也能靠 SKU 汇总特征补上层级信息。选 LightGBM 而不是更花哨的深度模型原因很朴素这个数据规模和特征数量对树模型更友好训练速度快可解释性好初赛阶段一天能迭代十几个版本。深度时序模型在这个粒度上优势不明显还容易出现过拟合性价比不高。等基线跑通、确认瓶颈确实在预测精度之后再换模型不迟。3.2 特征设计滞后、滚动统计与类别特征的取舍树模型对特征工程并不完全免疫。时间序列预测里最稳定的一类特征是滞后序列和滚动统计过去 1 天、7 天、14 天的需求以及过去 7 天、14 天、28 天的滚动均值。滚动窗口的选择要结合补货周期如果数据里补货周期是 7 天过去 7 天的滚动均量就比单日滞后更有业务含义因为它恰好覆盖一个补货周期内的平均消耗。类别特征上SKU 品类、仓库类型、星期几、月份都有用。sku_id 和 warehouse_id 这两个 ID 字段我一般不完全丢弃但不会把 sku_id 这种上千个类别的 ID 直接扔给模型而是保留 warehouse_id同时把 SKU 维度的统计量加工成特征。下面是一段完整特征构造函数关键点在注释里def build_features(df, target_coldemand_qty, windows[7, 14, 28]): # 必须按 SKU×仓×日期排序保证 shift 取到真正的历史值 df df.sort_values([sku_id, warehouse_id, date]).reset_index(dropTrue) g df.groupby([sku_id, warehouse_id])[target_col] # 滞后特征过去第 w 天的需求量不含今天 for w in windows: df[fdemand_lag_{w}] g.shift(w) # 滚动统计先 shift(1) 排除今天再 rolling 平均 for w in windows: df[fdemand_roll_{w}] g.transform( lambda x: x.shift(1).rolling(w).mean() ) # 28 天滚动最大值捕捉近期峰值 df[demand_max_28] g.transform( lambda x: x.shift(1).rolling(28).max() ) # 日历特征星期几、月份对周用品和季节品有效 df[weekday] df[date].dt.weekday df[month] df[date].dt.month return df注释里藏着一个最重要的动作先 shift(1) 再 rolling。如果反过来先 rolling 再 shift窗口里会包含今天的真实需求那就是把答案写进考卷。另一个细节是 lag 特征和 rolling 特征同时存在时树模型会自动选择哪一边信息量更大所以两者都放不用提前做特征选择。运行前先打印 df.isna().sum()滞后窗口会让前面几行出现空值这部分要在训练时去掉而不是把空值填 0 硬喂给模型。3.3 训练与回测时间切分、早期停止和 WAPE 评估训练 LightGBM 本身不复杂复杂的是怎么切验证集。初赛数据的评测期是一个连续时间块验证集就应该模拟同样的形态拿历史数据最后 20% 作为验证期而不是随机打散。随机打散会让模型看到未来数据验证集指标虚高提交后分数立刻崩掉这是时间序列赛题最常见的第一道坎。评估指标我用 WAPE加权绝对百分比误差而不是单纯 MAE。因为不同 SKU 销量差异巨大MAE 会被大 SKU 主导WAPE 用实际需求做分母相当于把误差按销量权重归一更贴近缺货率和库存成本的业务感觉。import lightgbm as lgb cut int(len(df_features) * 0.8) train df_features.iloc[:cut] valid df_features.iloc[cut:] feature_cols [ c for c in df_features.columns if c.startswith(demand_) or c in [weekday, month, warehouse_id] ] model lgb.LGBMRegressor( n_estimators800, learning_rate0.05, num_leaves63, subsample0.8, colsample_bytree0.8, random_state42, ) model.fit( train[feature_cols], train[demand_qty], eval_set[(valid[feature_cols], valid[demand_qty])], callbacks[lgb.early_stopping(100), lgb.log_evaluation(100)], ) valid_pred model.predict(valid[feature_cols]) wape (valid[demand_qty] - valid_pred).abs().sum() / valid[demand_qty].sum() print(WAPE:, wape)这里的参数不是玄学而是有明确逻辑learning_rate0.05 配合 800 棵树是典型的小步长大容量组合配 early_stopping 防止过拟合num_leaves63 控制在几百条序列数据下的模型复杂度数据量大了再往上加subsample 和 colsample_bytree 是两路随机抽样既能防过拟合又能让每棵树看到的数据视角不同对长尾 SKU 稍有帮助。如果验证 WAPE 明显高于训练集先检查特征里是否泄漏了未来信息再决定是否调参顺序不能反。4. 从预测到补货安全库存与 (s, S) 补货规则的三个关键参数4.1 预测均值不是补货量订货点与目标库存的联动把需求预测直接当补货量是初赛新手最典型的第一反应。预测均值只能回答「平均每天卖多少」回答不了「提前期里万一卖超了怎么办」。补货决策里有两个基本动作库存降到什么水平必须下单下单要补到多高。前者叫订货点 s后者叫目标库存水平 S两个值一起构成 (s, S) 规则。经典公式为 SS z × σ_d × sqrt(L)其中 z 是服务水平对应的标准正态分位值σ_d 是需求日标准差L 是补货提前期天数。订货点 s 日均需求 × L SS。当库存低于 s 时触发补货下单量 S - 当前库存。这里的 S 一般取「补货周期 × 日均需求 安全库存」也就是把未来一个完整补货周期的消耗都备上。(s, S) 和固定周期补货的区别在于固定周期到点就下不看库存(s, S) 按水位触发卖得慢的 SKU 自动减少下单频次库存周转更好。初赛数据里如果仓库的补货行为本来就有「低于阈值才下单」的特征用 (s, S) 拟合历史行为比固定周期更贴合。第一次跑通基线时我建议先把 σ_d 用历史标准差估计后面再换更稳的估计方式。4.2 分位数预测代替点预测把不确定性直接喂给补货规则安全库存公式里最难估的输入是 σ_d。用历史数据算标准差遇到需求结构性变化就不准而且 SKU 越多手工调 σ 的成本越高。更稳的做法是用分位数回归直接预测需求的分位值比如分别预测 50% 和 80% 分位然后拿两者的差近似安全库存的波动项。LightGBM 的 objectivequantile 可以直接做这件事alpha 指定分位数。models {} for alpha in [0.5, 0.8]: m lgb.LGBMRegressor( objectivequantile, alphaalpha, n_estimators500, learning_rate0.05, num_leaves31, random_state42, ) m.fit(valid[feature_cols], valid[demand_qty]) models[alpha] m q50 models[0.5].predict(valid[feature_cols]) q80 models[0.8].predict(valid[feature_cols]) volatility q80 - q50 # 波动项替代 σ_d 的估计这个技巧的代价是训练两个模型时间和算力翻倍但换来的是补货模拟里缺货率大幅下降。原因很直接分位数模型对长尾 SKU 更敏感50% 分位给出居中预测80% 分位自动在波动大的 SKU 上抬高库存保护线。对单序列短的初赛数据这比手算标准差稳得多。验证阶段可以多训一个 95% 分位看看缺货率和库存成本之间的曲线再决定服务水平放在哪一档。volatility 这个值在后续 (s, S) 规则里可以直接乘以 sqrt(L) 使用。4.3 补货参数怎么设提前期、补货周期与服务水平的取舍服务水平 z 值通常查正态表但实际调参时我很少看表而是按 90%、95%、98% 三档去扫。三档对应的 z 值大致是 1.28、1.65、2.05。差别看似不大安全库存的增幅却是指数级的从 90% 提到 95%安全库存约涨 30%从 95% 提到 98%再涨 25%。所以初赛数据里如果有成本字段一定要把缺货成本和持有成本都读出来再做取舍。服务水平z 值安全库存倍数相对90%档适用场景90%1.281.00缺货成本低周转优先95%1.651.29缺货与持有均衡98%2.051.60缺货罚款高或服务承诺强补货模拟的顺序对结果影响极大每天先处理到货再扣需求然后检查是否低于 s低于就下单提前期后到货。数据口径可能是「先扣需求再处理到货」两者在边界日期的结果相反必须先用一个简单策略小批量提交对比本地与线上的差异。下面是补齐了补货间隔约束的模拟函数def simulate(seq, s, S, lead_time3, review_interval7): inv 0 queue [] shortage 0 total_inv 0 last_order_day -review_interval # 初始允许下单 n 0 for demand in seq: # 到货先入库口径一入库的是提前期前下的单 if len(queue) lead_time: inv queue.pop(0) inv max(0, inv - demand) if inv 0: shortage 1 # 距上次下单超过 review_interval 天才允许再下 if n - last_order_day review_interval and inv s: queue.append(S - inv) last_order_day n total_inv inv n 1 return shortage, total_inv / n函数里 queue 用先进先出模拟提前期lead_time 天的货到期自动入账review_interval 表示两次下单的最小间隔避免每天都触发补货。缺货时把库存置 0是为了统计缺货天数而不是深挖缺货深度大多数评分脚本也只统计前者。跑完之后打印 shortage 和平均库存和 90%、95%、98% 三档做对比选缺货率与库存成本同时可接受的那组参数。注意如果提前期是 0队列逻辑要单独处理不过初赛数据很少出现这种情况。5. 仓储网络库存赛题的避坑清单五个最常翻车的环节这一章算是这段赛程的血泪经验集合。初赛的时间线很短队伍之间差距往往不来自模型高低而来自谁能少踩坑、早迭代。以下五个问题是类似赛题里真实遇到过、并且每一个都至少浪费过一轮提交机会的坑。列出来不是吓唬人而是让你在写代码前就知道去哪检查。5.1 时间泄漏随机切分让验证集指标虚高现象训练时为了省事把全量数据 random_state 一设直接打乱切 train/valid验证集 WAPE 很漂亮提交线上分数却明显变差。原因库存数据严格按时间演化随机切分会让训练集里的「未来几周」信息在验证期看得到。树模型最擅长背答案验证集等于开卷考试。解决一律按时间分界点切分验证期必须晚于训练期更严格的做法是先切分再做特征工程避免用验证期数据计算滚动均值等统计量。判断是否泄漏有个笨办法把验证集最后一周真实值改成 0 再预测如果预测值跟着大跳水说明特征里带着未来信息的尾巴。5.2 特征错位SKU 级特征喂给 SKU×仓级模型现象模型整体指标还行但错误集中在少数几个大仓按 warehouse 分组看 WAPE 一个天上一个地下。原因特征在 SKU 粒度计算标签却在 SKU×仓粒度。两者是一对多的映射树模型没有「按仓拆分」的能力只能把 SKU 汇总值的误差随机摊到各仓头上。解决所有特征与标签统一到同一粒度。想要保留 SKU 汇总信息可以构造「SKU 汇总量 - SKU×仓自身量」这样的兄弟体量特征再把 warehouse_id 作为类别特征交给模型。粒度错位在初赛数据里很难肉眼发现因为它只表现为某些仓的误差集中所以做特征前先画一张「特征粒度 × 标签粒度」的对照表比事后排查便宜得多。5.3 滞后特征串未来rolling 和 shift 的顺序反了现象训练集 WAPE 极低验证集却突然高出一截重新跑一遍又不稳定换个随机种子指标就变。原因rolling 内包含了当天数据。比如先 rolling(7) 再 shift(1)窗口覆盖的是「昨天到 6 天前」但正确写法是先 shift(1) 再 rolling(7)窗口覆盖「前天到 8 天前」。顺序反了就会把今天的真实需求灌进特征树模型会优先学这条穿上隐形衣的捷径。解决固定写法是先 shift(1) 再 rolling(w)并在代码注释里写清。我在每次特征版本切换后都会用一条历史窗口可视化核对取某个 SKU×仓打印最后一周特征值和原始需求序列对比能一眼看出有没有穿墙。特征工程里的穿墙问题不报错只能靠这种笨办法抓出来。5.4 补货模拟口径不一致到货与扣减顺序对不上评分脚本现象本地模拟缺货天数 2 天线上却报 8 天差异大到无法解释改参数也没用。原因评分脚本可能先扣需求再处理到货本地函数先处理到货再扣需求。当提前期很短、货到当天又有需求时两种顺序结果完全不同订单截止时间点差一个小时缺货统计就差一天。解决先用一个最简单的无脑策略比如每天补满到 S小批量提交对比线下线上缺货天数差定出口径再通过数据反推查看昨日库存 今日到货 - 今日需求与今日库存的等式能够判断到货发生在订单日之前还是之后。确认后把 simulate 函数里的顺序调成和评分脚本一致再谈调参。5.5 模型目标与业务指标脱节对 MAE 但评分看缺货率现象预测模型在验证集 MAE 很低但接入补货模拟后缺货率始终压不下来调补货参数也不见好。原因MAE 对称惩罚高估和低估而缺货率只惩罚低估。当需求预测偏向均值以下的系统性偏差积累安全库存再高也兜不住高估的部分被库存成本惩罚低估的部分被缺货率惩罚两个指标的权重不一样。解决把损失函数换成 pinball loss或直接用 80% 分位预测作为补货输入至少对高销量 SKU 加大损失权重。让模型目标向业务指标靠拢比事后调 (s, S) 参数更治本。这里有一个老生常谈但值得重复的判断标准如果预测模型和补货模拟是两组人在调那最终分数一定不好看因为两边优化的不是同一个东西。6. 进阶从单仓补货走向网络调拨以及交付前的最后验证6.1 多仓之间的调拨逻辑库存冗余可以互相吃掉单仓 (s, S) 跑稳之后初赛的「仓储网络」才真正显形。多仓网络里某个仓缺货时另一个仓可能还有库存调拨能用一个整体的服务水平换更低的库存成本。调拨决策的第一步是看网络拓扑数据里给出的是中心仓到前置仓的星型结构还是仓与仓之间可以任意互调。我的做法是先算出每个 SKU 在外仓的总库存再按补货周期之外的紧急缺口做调拨而不是每次缺货都调调拨本身有成本调得越频繁省下的缺货损失越少。调拨模拟里最怕的是把调出仓自己的订单忘了扣。模拟项目里曾经出现过把调拨量加到调入仓的到货队列却没从调出仓库存里减掉结果整个网络库存凭空多出一截这种只看整体对不上明细的错用汇总表一检查就露馅。所以调拨逻辑上线前先构造一个两仓、两天的假数据手算一遍确认守恒再放开到全量。6.2 交付前的最后验证双指标加分段稳定性检查最后一晚不要只盯榜单位置我会跑两个验证一是累计缺货天数二是平均库存天数周转的倒数。缺货率低但平均库存很高策略没有实用价值库存低但缺货率高服务不达标。两个指标一起看才能判断策略是不是在硬撑。只看一个指标很容易自我安慰双指标才是照妖镜。分段稳定性检查就是把评测期按每周切片分别统计每周的缺货天数和库存天数。如果某周突然恶化去查那周是否遇到节假日或促销结合日历特征回看模型有没有捕捉到。我的习惯是先把这周单独拉出来可视化再决定是改特征还是加规则而不是直接调模型参数。每次提交前按这个流程走一遍心里才有底。这套流程做完一个能打榜单、也能落到实际仓库排期的方案就齐了。希望帮到你。本文还有配套的精品资源点击获取
简介JDGOC仓储网络智能库存管理初赛数据专为物流供应链、机器学习和运筹优化方向的学习者与参赛者准备。赛题背景源于京东全国近500个仓库的“211”时效履约场景需要在预测各区域商品需求的基础上通过调拨决策让库存合理分布于RDC与FDC完成两阶段建模仿真。包内含15个文件共16.62MB核心为10个CSV数据表覆盖SKU属性、历史销量、库存、促销、量化分位及需求分布等和3个Python脚本含仿真与提交模板另附说明文档与编译模块便于直接复现初赛流程。数据字段粒度细既有预测目标又有调拨约束适合多模型对比与时间序列分析。目前已有1152人学习浏览对想发表物流供应链论文或提升实战技能的同学是一份难得的从数据到仿真的全流程案例。1. JDGOC 初赛数据里的仓储网络库存管理先把赛题拆成看得见的两件事JDGOC 初赛这份仓储网络库存数据给的不是一堆打好标签的图片而是某张网络过去几十周里每个 SKU 在每个仓库的库存、需求、到货和调拨流水。表面看是数据竞赛本质上是让你用真实颗粒度的历史记录回答补多少、什么时候补、放在哪个仓这三个决策问题。对参赛者来说最划算的路径不是一上来就上强化学习而是先把「需求预测 补货规则」这条主链路跑通。适合谁准备冲榜单的选手、刚转供应链数据方向的工程师以及想把手工 Excel 补货表换成可计算策略的计划员。这篇文章就按这份数据把链路拆开讲一遍。2. 先读懂初赛数据的长相字段、粒度与时间边界2.1 仓储网络数据不是一张大宽表而是四张表拼出来的拿到 JDGOC 初赛数据第一件事不是写模型而是把文件解压后逐个看表头。仓储网络智能库存管理的数据通常按实体拆成四类时序主表、SKU 档案、仓库档案和网络参数。时序主表是核心记录每个 SKU 在每个仓库每天或每周的库存量、需求量、到货量和调拨量SKU 档案给的是品类、体积、保质期这类静态属性仓库档案给容量、仓库类型网络参数则藏着提前期、补货周期和各类成本系数。四类表不是生来能直接 join 的。不少初赛队伍把 SKU 档案里的品类维度直接按字符串塞进特征结果模型没学到规律反而把品类 ID 当成噪声。正确的做法是先确认每张表的主键和粒度SKU 档案的主键是 sku_id仓库档案是 warehouse_id时序主表则是 sku_id warehouse_id date 三个字段组成的复合主键。对齐粒度后再做特征才谈得上稳定性。下表是最常见的字段形态字段名在不同赛段可能略改但语义基本一致。我拿到每份新数据都会做一遍映射把字段名、语义、粒度和陷阱写进同一张表。原因很简单初赛数据字段在复赛和实际业务里也可能重命名只记单词不记语义换个壳就不认识。字段语义粒度常见陷阱sku_idSKU 编码SKU不要直接当数值特征warehouse_id仓库编码仓编码是 ID 不是大小date日期日/周时间切分不能乱stock_qty库存量SKU×仓×日日末还是期初要确认demand_qty需求量SKU×仓×日订单量还是出库量inbound_qty到货量SKU×仓×日下单量还是入库量transfer_qty调拨量SKU×仓×日调出为正还是为负2.2 口径检验用等式确认「日末库存」「出库需求」「入库到货」字段名看懂了不等于数据能直接用。同一个叫 stock 的字段可能是当日末结存也可能是次日清晨盘点值同一个 demand_qty可能是顾客订单量也可能是实际出库量inbound_qty 可能是下单量也可能是验收合格后的入库量。口径不同直接决定补货模拟里的订单要在哪一天生效。我的习惯是拿连续几行做等式检验昨日库存 今日到货 今日调出 - 今日需求 今日库存。数据里有调拨入和调拨出双向时公式里要把调拨净额也放进去。对不上的记录占比超过千分之一就得去查是不是漏了退货入、报废出或盘亏盘盈字段如果对得上说明口径严密可以放心用滞回特征。以下代码就是把这条等式落到 pandas 上的标准写法注意必须先按 SKU×仓×日期排序再分组取 shift(1)否则上一行根本不是前一天import pandas as pd df pd.read_csv(inventory_main.csv, parse_dates[date]) df df.sort_values([sku_id, warehouse_id, date]) g df.groupby([sku_id, warehouse_id]) df[last_stock] g[stock_qty].shift(1) # 假设数据已规范化需求为正数调拨量为净流入正为调进负为调出 df[calc_stock] ( df[last_stock] df[inbound_qty] df[transfer_qty] - df[demand_qty] ) df[diff] (df[calc_stock] - df[stock_qty]).abs() bad_ratio (df[diff] 1e-6).mean() print(库存等式不一致占比:, bad_ratio)这段代码里最需要解释的是 shift(1) 之前的排序。groupby 后的 shift(1) 取的是「同一个 SKU×仓组合里上一行的值」只有先按日期排序上一行才等于前一天。等式不平衡的记录占比超过千分之一时先不要急着改模型回头查原始 CSV 里是否有单独字段记录退货和报废把公式补全再做下一步。这一步的花费十分钟后面省下的排错时间是十倍不止。另外注意如果初赛数据把需求记成负数、调出记成正数要先把符号统一否则等式恒不成立。2.3 时间边界与网络参数预测起点、历史窗口、补货节奏时序数据最要紧的是划清两段时间可观测的完整历史期和需要预测的评测期。评测期起始日就是预测起点之后所有真实值都不能进入特征训练集和验证集必须按时间切不能随机打乱。初赛一般给出前几十周要求预测后几周或直接产出补货计划窗口长度直接影响模型能不能学到季节和促销模式。历史窗口的选取有两个极端。窗口太短模型只看到最近一两周遇到季度性品类就测不准窗口太长早期促销和缺货噪声把信号稀释。我一般先用 8~12 周滚动特征做一版 baseline再看验证期分段表现如果头两周准、后面几周差往往不是窗口问题而是模型没见过足够长的节假日形态需要在特征里补上日历字段和滞后若干周的同期对比。数据里如果有补货周期和提前期字段把它们单列出来。补货周期决定多久能下一次单提前期决定下单后多久到货两者直接参与补货模拟不读清这两项后面所有安全库存计算都是空中楼阁。可以把它们当成网络参数中的两个固定值不同的 SKU×仓可能有不同取值建模时先按众数统一处理最后再按分组差异微调。这一节做完你对这份数据的理解就足够支撑后续全部建模。3. 用 LightGBM 做一版需求预测基线特征、训练与回测一次跑通3.1 为什么先做需求预测库存决策的输入是未来需求补货决策依赖三件事当前库存、未来需求、提前期的到货节奏。当前库存从数据里直接读未来需求只能预测所以需求预测是整条链路里最需要花时间的部分。JDGOC 这类赛题评分最终落在缺货率和库存周转上但缺货率不会因为你把补货参数调到极致就消失预测的系统性偏差才是根因。需求预测有两个绕不开的特性。一是长尾大量 SKU 平时没销量偶尔一次性出几十件均值和方差都不可靠。二是层级结构单 SKU×仓的时间序列又短又抖但按 SKU 汇总之后规律明显。常见做法有两条路先做 SKU 级预测再按历史销量占比拆分到仓或者直接做 SKU×仓级预测在特征里带上 SKU 汇总量。我一般选后者因为后续补货模拟就在 SKU×仓粒度上跑直接预测能省去拆分误差树模型也能靠 SKU 汇总特征补上层级信息。选 LightGBM 而不是更花哨的深度模型原因很朴素这个数据规模和特征数量对树模型更友好训练速度快可解释性好初赛阶段一天能迭代十几个版本。深度时序模型在这个粒度上优势不明显还容易出现过拟合性价比不高。等基线跑通、确认瓶颈确实在预测精度之后再换模型不迟。3.2 特征设计滞后、滚动统计与类别特征的取舍树模型对特征工程并不完全免疫。时间序列预测里最稳定的一类特征是滞后序列和滚动统计过去 1 天、7 天、14 天的需求以及过去 7 天、14 天、28 天的滚动均值。滚动窗口的选择要结合补货周期如果数据里补货周期是 7 天过去 7 天的滚动均量就比单日滞后更有业务含义因为它恰好覆盖一个补货周期内的平均消耗。类别特征上SKU 品类、仓库类型、星期几、月份都有用。sku_id 和 warehouse_id 这两个 ID 字段我一般不完全丢弃但不会把 sku_id 这种上千个类别的 ID 直接扔给模型而是保留 warehouse_id同时把 SKU 维度的统计量加工成特征。下面是一段完整特征构造函数关键点在注释里def build_features(df, target_coldemand_qty, windows[7, 14, 28]): # 必须按 SKU×仓×日期排序保证 shift 取到真正的历史值 df df.sort_values([sku_id, warehouse_id, date]).reset_index(dropTrue) g df.groupby([sku_id, warehouse_id])[target_col] # 滞后特征过去第 w 天的需求量不含今天 for w in windows: df[fdemand_lag_{w}] g.shift(w) # 滚动统计先 shift(1) 排除今天再 rolling 平均 for w in windows: df[fdemand_roll_{w}] g.transform( lambda x: x.shift(1).rolling(w).mean() ) # 28 天滚动最大值捕捉近期峰值 df[demand_max_28] g.transform( lambda x: x.shift(1).rolling(28).max() ) # 日历特征星期几、月份对周用品和季节品有效 df[weekday] df[date].dt.weekday df[month] df[date].dt.month return df注释里藏着一个最重要的动作先 shift(1) 再 rolling。如果反过来先 rolling 再 shift窗口里会包含今天的真实需求那就是把答案写进考卷。另一个细节是 lag 特征和 rolling 特征同时存在时树模型会自动选择哪一边信息量更大所以两者都放不用提前做特征选择。运行前先打印 df.isna().sum()滞后窗口会让前面几行出现空值这部分要在训练时去掉而不是把空值填 0 硬喂给模型。3.3 训练与回测时间切分、早期停止和 WAPE 评估训练 LightGBM 本身不复杂复杂的是怎么切验证集。初赛数据的评测期是一个连续时间块验证集就应该模拟同样的形态拿历史数据最后 20% 作为验证期而不是随机打散。随机打散会让模型看到未来数据验证集指标虚高提交后分数立刻崩掉这是时间序列赛题最常见的第一道坎。评估指标我用 WAPE加权绝对百分比误差而不是单纯 MAE。因为不同 SKU 销量差异巨大MAE 会被大 SKU 主导WAPE 用实际需求做分母相当于把误差按销量权重归一更贴近缺货率和库存成本的业务感觉。import lightgbm as lgb cut int(len(df_features) * 0.8) train df_features.iloc[:cut] valid df_features.iloc[cut:] feature_cols [ c for c in df_features.columns if c.startswith(demand_) or c in [weekday, month, warehouse_id] ] model lgb.LGBMRegressor( n_estimators800, learning_rate0.05, num_leaves63, subsample0.8, colsample_bytree0.8, random_state42, ) model.fit( train[feature_cols], train[demand_qty], eval_set[(valid[feature_cols], valid[demand_qty])], callbacks[lgb.early_stopping(100), lgb.log_evaluation(100)], ) valid_pred model.predict(valid[feature_cols]) wape (valid[demand_qty] - valid_pred).abs().sum() / valid[demand_qty].sum() print(WAPE:, wape)这里的参数不是玄学而是有明确逻辑learning_rate0.05 配合 800 棵树是典型的小步长大容量组合配 early_stopping 防止过拟合num_leaves63 控制在几百条序列数据下的模型复杂度数据量大了再往上加subsample 和 colsample_bytree 是两路随机抽样既能防过拟合又能让每棵树看到的数据视角不同对长尾 SKU 稍有帮助。如果验证 WAPE 明显高于训练集先检查特征里是否泄漏了未来信息再决定是否调参顺序不能反。4. 从预测到补货安全库存与 (s, S) 补货规则的三个关键参数4.1 预测均值不是补货量订货点与目标库存的联动把需求预测直接当补货量是初赛新手最典型的第一反应。预测均值只能回答「平均每天卖多少」回答不了「提前期里万一卖超了怎么办」。补货决策里有两个基本动作库存降到什么水平必须下单下单要补到多高。前者叫订货点 s后者叫目标库存水平 S两个值一起构成 (s, S) 规则。经典公式为 SS z × σ_d × sqrt(L)其中 z 是服务水平对应的标准正态分位值σ_d 是需求日标准差L 是补货提前期天数。订货点 s 日均需求 × L SS。当库存低于 s 时触发补货下单量 S - 当前库存。这里的 S 一般取「补货周期 × 日均需求 安全库存」也就是把未来一个完整补货周期的消耗都备上。(s, S) 和固定周期补货的区别在于固定周期到点就下不看库存(s, S) 按水位触发卖得慢的 SKU 自动减少下单频次库存周转更好。初赛数据里如果仓库的补货行为本来就有「低于阈值才下单」的特征用 (s, S) 拟合历史行为比固定周期更贴合。第一次跑通基线时我建议先把 σ_d 用历史标准差估计后面再换更稳的估计方式。4.2 分位数预测代替点预测把不确定性直接喂给补货规则安全库存公式里最难估的输入是 σ_d。用历史数据算标准差遇到需求结构性变化就不准而且 SKU 越多手工调 σ 的成本越高。更稳的做法是用分位数回归直接预测需求的分位值比如分别预测 50% 和 80% 分位然后拿两者的差近似安全库存的波动项。LightGBM 的 objectivequantile 可以直接做这件事alpha 指定分位数。models {} for alpha in [0.5, 0.8]: m lgb.LGBMRegressor( objectivequantile, alphaalpha, n_estimators500, learning_rate0.05, num_leaves31, random_state42, ) m.fit(valid[feature_cols], valid[demand_qty]) models[alpha] m q50 models[0.5].predict(valid[feature_cols]) q80 models[0.8].predict(valid[feature_cols]) volatility q80 - q50 # 波动项替代 σ_d 的估计这个技巧的代价是训练两个模型时间和算力翻倍但换来的是补货模拟里缺货率大幅下降。原因很直接分位数模型对长尾 SKU 更敏感50% 分位给出居中预测80% 分位自动在波动大的 SKU 上抬高库存保护线。对单序列短的初赛数据这比手算标准差稳得多。验证阶段可以多训一个 95% 分位看看缺货率和库存成本之间的曲线再决定服务水平放在哪一档。volatility 这个值在后续 (s, S) 规则里可以直接乘以 sqrt(L) 使用。4.3 补货参数怎么设提前期、补货周期与服务水平的取舍服务水平 z 值通常查正态表但实际调参时我很少看表而是按 90%、95%、98% 三档去扫。三档对应的 z 值大致是 1.28、1.65、2.05。差别看似不大安全库存的增幅却是指数级的从 90% 提到 95%安全库存约涨 30%从 95% 提到 98%再涨 25%。所以初赛数据里如果有成本字段一定要把缺货成本和持有成本都读出来再做取舍。服务水平z 值安全库存倍数相对90%档适用场景90%1.281.00缺货成本低周转优先95%1.651.29缺货与持有均衡98%2.051.60缺货罚款高或服务承诺强补货模拟的顺序对结果影响极大每天先处理到货再扣需求然后检查是否低于 s低于就下单提前期后到货。数据口径可能是「先扣需求再处理到货」两者在边界日期的结果相反必须先用一个简单策略小批量提交对比本地与线上的差异。下面是补齐了补货间隔约束的模拟函数def simulate(seq, s, S, lead_time3, review_interval7): inv 0 queue [] shortage 0 total_inv 0 last_order_day -review_interval # 初始允许下单 n 0 for demand in seq: # 到货先入库口径一入库的是提前期前下的单 if len(queue) lead_time: inv queue.pop(0) inv max(0, inv - demand) if inv 0: shortage 1 # 距上次下单超过 review_interval 天才允许再下 if n - last_order_day review_interval and inv s: queue.append(S - inv) last_order_day n total_inv inv n 1 return shortage, total_inv / n函数里 queue 用先进先出模拟提前期lead_time 天的货到期自动入账review_interval 表示两次下单的最小间隔避免每天都触发补货。缺货时把库存置 0是为了统计缺货天数而不是深挖缺货深度大多数评分脚本也只统计前者。跑完之后打印 shortage 和平均库存和 90%、95%、98% 三档做对比选缺货率与库存成本同时可接受的那组参数。注意如果提前期是 0队列逻辑要单独处理不过初赛数据很少出现这种情况。5. 仓储网络库存赛题的避坑清单五个最常翻车的环节这一章算是这段赛程的血泪经验集合。初赛的时间线很短队伍之间差距往往不来自模型高低而来自谁能少踩坑、早迭代。以下五个问题是类似赛题里真实遇到过、并且每一个都至少浪费过一轮提交机会的坑。列出来不是吓唬人而是让你在写代码前就知道去哪检查。5.1 时间泄漏随机切分让验证集指标虚高现象训练时为了省事把全量数据 random_state 一设直接打乱切 train/valid验证集 WAPE 很漂亮提交线上分数却明显变差。原因库存数据严格按时间演化随机切分会让训练集里的「未来几周」信息在验证期看得到。树模型最擅长背答案验证集等于开卷考试。解决一律按时间分界点切分验证期必须晚于训练期更严格的做法是先切分再做特征工程避免用验证期数据计算滚动均值等统计量。判断是否泄漏有个笨办法把验证集最后一周真实值改成 0 再预测如果预测值跟着大跳水说明特征里带着未来信息的尾巴。5.2 特征错位SKU 级特征喂给 SKU×仓级模型现象模型整体指标还行但错误集中在少数几个大仓按 warehouse 分组看 WAPE 一个天上一个地下。原因特征在 SKU 粒度计算标签却在 SKU×仓粒度。两者是一对多的映射树模型没有「按仓拆分」的能力只能把 SKU 汇总值的误差随机摊到各仓头上。解决所有特征与标签统一到同一粒度。想要保留 SKU 汇总信息可以构造「SKU 汇总量 - SKU×仓自身量」这样的兄弟体量特征再把 warehouse_id 作为类别特征交给模型。粒度错位在初赛数据里很难肉眼发现因为它只表现为某些仓的误差集中所以做特征前先画一张「特征粒度 × 标签粒度」的对照表比事后排查便宜得多。5.3 滞后特征串未来rolling 和 shift 的顺序反了现象训练集 WAPE 极低验证集却突然高出一截重新跑一遍又不稳定换个随机种子指标就变。原因rolling 内包含了当天数据。比如先 rolling(7) 再 shift(1)窗口覆盖的是「昨天到 6 天前」但正确写法是先 shift(1) 再 rolling(7)窗口覆盖「前天到 8 天前」。顺序反了就会把今天的真实需求灌进特征树模型会优先学这条穿上隐形衣的捷径。解决固定写法是先 shift(1) 再 rolling(w)并在代码注释里写清。我在每次特征版本切换后都会用一条历史窗口可视化核对取某个 SKU×仓打印最后一周特征值和原始需求序列对比能一眼看出有没有穿墙。特征工程里的穿墙问题不报错只能靠这种笨办法抓出来。5.4 补货模拟口径不一致到货与扣减顺序对不上评分脚本现象本地模拟缺货天数 2 天线上却报 8 天差异大到无法解释改参数也没用。原因评分脚本可能先扣需求再处理到货本地函数先处理到货再扣需求。当提前期很短、货到当天又有需求时两种顺序结果完全不同订单截止时间点差一个小时缺货统计就差一天。解决先用一个最简单的无脑策略比如每天补满到 S小批量提交对比线下线上缺货天数差定出口径再通过数据反推查看昨日库存 今日到货 - 今日需求与今日库存的等式能够判断到货发生在订单日之前还是之后。确认后把 simulate 函数里的顺序调成和评分脚本一致再谈调参。5.5 模型目标与业务指标脱节对 MAE 但评分看缺货率现象预测模型在验证集 MAE 很低但接入补货模拟后缺货率始终压不下来调补货参数也不见好。原因MAE 对称惩罚高估和低估而缺货率只惩罚低估。当需求预测偏向均值以下的系统性偏差积累安全库存再高也兜不住高估的部分被库存成本惩罚低估的部分被缺货率惩罚两个指标的权重不一样。解决把损失函数换成 pinball loss或直接用 80% 分位预测作为补货输入至少对高销量 SKU 加大损失权重。让模型目标向业务指标靠拢比事后调 (s, S) 参数更治本。这里有一个老生常谈但值得重复的判断标准如果预测模型和补货模拟是两组人在调那最终分数一定不好看因为两边优化的不是同一个东西。6. 进阶从单仓补货走向网络调拨以及交付前的最后验证6.1 多仓之间的调拨逻辑库存冗余可以互相吃掉单仓 (s, S) 跑稳之后初赛的「仓储网络」才真正显形。多仓网络里某个仓缺货时另一个仓可能还有库存调拨能用一个整体的服务水平换更低的库存成本。调拨决策的第一步是看网络拓扑数据里给出的是中心仓到前置仓的星型结构还是仓与仓之间可以任意互调。我的做法是先算出每个 SKU 在外仓的总库存再按补货周期之外的紧急缺口做调拨而不是每次缺货都调调拨本身有成本调得越频繁省下的缺货损失越少。调拨模拟里最怕的是把调出仓自己的订单忘了扣。模拟项目里曾经出现过把调拨量加到调入仓的到货队列却没从调出仓库存里减掉结果整个网络库存凭空多出一截这种只看整体对不上明细的错用汇总表一检查就露馅。所以调拨逻辑上线前先构造一个两仓、两天的假数据手算一遍确认守恒再放开到全量。6.2 交付前的最后验证双指标加分段稳定性检查最后一晚不要只盯榜单位置我会跑两个验证一是累计缺货天数二是平均库存天数周转的倒数。缺货率低但平均库存很高策略没有实用价值库存低但缺货率高服务不达标。两个指标一起看才能判断策略是不是在硬撑。只看一个指标很容易自我安慰双指标才是照妖镜。分段稳定性检查就是把评测期按每周切片分别统计每周的缺货天数和库存天数。如果某周突然恶化去查那周是否遇到节假日或促销结合日历特征回看模型有没有捕捉到。我的习惯是先把这周单独拉出来可视化再决定是改特征还是加规则而不是直接调模型参数。每次提交前按这个流程走一遍心里才有底。这套流程做完一个能打榜单、也能落到实际仓库排期的方案就齐了。希望帮到你。本文还有配套的精品资源点击获取
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
