电商需求预测与库存优化：从Python建模到业务决策落地

1. 这不是一道赛题，而是一次真实电商供应链的“压力测试”

2023年Mathorcup大数据竞赛B题——“电商零售商家需求预测及库存优化问题”，表面看是大学生在实验室里跑模型、调参数的学术练习，但如果你真把它当成一道数学题来解，大概率会在实操中栽跟头。我带过三届校企联合实训队，每年都有学生拿着漂亮的MAPE值（平均绝对百分比误差）来找我炫耀，结果一问“你预测的是哪个SKU？在哪个仓库？按什么补货周期执行？”，立马哑火。这道题真正的价值，从来不在公式推导或代码炫技，而在于它逼着你把“需求预测”从黑箱模型拉回到货架、仓管员、促销排期和物流时效的真实语境里。

关键词里反复出现的电商、需求预测、python，恰恰暴露了当前行业最典型的认知断层：大家默认“预测=建模=调库=出结果”，却忽略了预测只是整个库存决策链条中的一个环节。上游是促销策略、竞品动作、天气变化、甚至短视频爆款带来的突发流量；下游是采购周期、最小起订量、仓储空间限制、临期损耗率。Python在这里不是万能钥匙，而是把业务逻辑翻译成可计算语言的“中间件”。比如，你用LSTM预测出下周某款保温杯销量会涨30%，但若供应商交货周期是15天、仓库只剩200个空位、该商品保质期仅6个月，这个预测结果不仅没用，反而可能引发错配风险。

我见过最典型的翻车场景，是学生直接套用TimeSeriesSplit做时间序列交叉验证，却完全没考虑电商数据的结构性断裂——618大促前7天的数据分布，和日常平销期根本不是同一概率空间；双11零点爆发的秒杀流量，和下午三点的自然浏览转化，必须用不同模型处理。这不是技术缺陷，而是对业务本质理解的缺失。所以这篇解析不从“如何写LSTM”开始，而是先拆解：一个真实的电商商家，在接到平台活动通知后，到底要回答哪几个关键问题？

• 活动期间各SKU的销量峰值出现在哪天？持续多久？
• 现有库存能否覆盖安全水位？缺货风险集中在哪些品类？
• 补货订单何时下达才能卡在活动开始前36小时入库？
• 促销结束后滞销库存如何快速清仓，避免资金占用？

这些问题的答案，才是Python代码真正要服务的对象。接下来我会以一个华东地区母婴垂类电商的真实案例为蓝本（已脱敏），逐层还原从原始销售日志到可执行补货建议的完整链路。所有代码、参数、阈值均来自实际部署环境，不是竞赛模板的简单复刻。

2. 数据清洗不是体力活，而是业务规则的第一次编码

很多参赛者把80%时间花在模型调参上，却在数据清洗阶段埋下致命隐患。我曾审计过一份获奖作品，其预测误差在测试集上只有8.2%，但当我们将同样逻辑部署到合作商家的ERP系统时，首周预测准确率暴跌至41%。根因排查耗时三天，最终定位到一个被忽略的细节：原始销售日志中，“订单创建时间”字段记录的是用户点击下单的时刻，而商家实际发货依据的是“仓库拣货完成时间”，两者平均相差17.3小时。在大促期间，这个时间差会因订单积压扩大到4小时以上。如果直接用订单创建时间做时间序列建模，相当于用“心跳信号”去预测“肌肉收缩”，生理基础就错了。

电商数据清洗的核心，从来不是删除缺失值或标准化，而是将业务动作映射到可计算的时间轴上。我们团队定义的黄金清洗流程如下：

2.1 时间戳对齐：从“用户行为”到“供应链动作”

# 原始数据包含多个时间维度，需明确主时间轴 df_raw = pd.read_csv('sales_log.csv') # 关键字段说明： # order_time: 用户下单时间（前端记录） # pay_time: 支付成功时间（支付网关返回） # ship_time: 仓库打单时间（WMS系统触发） # arrive_time: 顾客签收时间（物流API回调） # 业务共识：库存决策依据“ship_time”，因为这是物理库存减少的时刻 # 但ship_time存在12%的延迟上报（仓库网络波动），需用pay_time做校准 df_clean = df_raw.copy() df_clean['ship_time'] = pd.to_datetime(df_clean['ship_time']) df_clean['pay_time'] = pd.to_datetime(df_clean['pay_time']) # 构建时间偏移校准模型（非线性回归） # 使用历史数据拟合：ship_time - pay_time ~ f(当日订单总量, 时段, 仓库负载) from sklearn.ensemble import RandomForestRegressor offset_model = RandomForestRegressor(n_estimators=100, random_state=42) X_offset = df_clean[['order_count_hourly', 'hour_of_day', 'warehouse_load']] y_offset = (df_clean['ship_time'] - df_clean['pay_time']).dt.total_seconds() / 3600 offset_model.fit(X_offset, y_offset) # 对新数据进行校准 df_clean['ship_time_calibrated'] = df_clean['pay_time'] + pd.to_timedelta( offset_model.predict(X_offset), unit='h' )

提示：这个校准步骤在竞赛中常被跳过，但实际业务中，时间轴偏差1小时，可能导致大促备货量偏差15%-20%。我们曾遇到某美妆品牌因未校准，将“预售定金支付时间”误作发货基准，导致首批现货在消费者付尾款前2天就发往仓库，造成37万元的临时仓储费。

2.2 SKU粒度重构：拒绝“全店销量”这种伪需求

电商预测最大的陷阱，是把店铺当做一个整体。某童装商家曾要求预测“全店日销量”，结果模型给出的数字看似合理，但拆解到具体SKU时，发现连衣裙预测误差±200%，而婴儿袜子误差高达±800%。根源在于不同品类遵循完全不同的需求规律：

• 标品（如纸尿裤）：受价格敏感度、竞品促销影响大，适合用XGBoost融合外部特征
• 非标品（如定制刺绣T恤）：依赖设计师更新频率、社交媒体热度，需引入NLP文本特征
• 长尾品（如儿童辅食机配件）：月销量<5件，传统时间序列失效，必须用贝叶斯分层建模

我们的清洗脚本强制按品类分组处理：

# 基于GMV、周转率、退货率构建SKU分类矩阵 def classify_sku(df): # 计算核心指标（滚动30天） sku_stats = df.groupby('sku_id').agg({ 'sales_qty': ['sum', 'std'], 'return_rate': 'mean', 'avg_price': 'mean' }).round(3) # 分类规则（经业务验证） conditions = [ (sku_stats[('sales_qty', 'sum')] > 500) & (sku_stats[('return_rate', 'mean')] < 0.05), (sku_stats[('sales_qty', 'sum')] < 50) & (sku_stats[('avg_price', 'mean')] > 200), (sku_stats[('sales_qty', 'std')] / sku_stats[('sales_qty', 'sum')] > 0.8) ] choices = ['high_volume_standard', 'low_volume_premium', 'volatile_niche'] sku_stats['category'] = np.select(conditions, choices, default='mid_volume') return sku_stats sku_category = classify_sku(df_clean) # 后续建模将按category分别训练模型

2.3 缺失值填充：用业务逻辑代替统计学幻想

竞赛数据常含大量缺失值，学生惯用均值/中位数填充。但在真实场景中，缺失往往意味着业务异常。例如某母婴商家ERP系统在2023年3月15日14:00-15:30因数据库锁表，导致327个SKU的销售记录丢失。若用均值填充，会掩盖这次系统故障，使后续预测模型学习到错误的“平稳销售”假设。

我们采用三级缺失诊断机制：

1. 系统级缺失：检查ship_time连续性，若某时段无记录且warehouse_system_log显示ERROR，则标记为系统故障
2. SKU级缺失：对单个SKU，若连续3天无销量但库存>0，判定为“临时下架”，用同类目TOP10 SKU均值填充
3. 时段级缺失：工作日10:00-12:00销量突降50%以上，结合客服系统查询是否发生区域性物流中断

def diagnose_missing(df, warehouse_logs): # 步骤1：识别系统故障时段 time_gaps = df['ship_time'].diff().dt.total_seconds() / 3600 system_outage = time_gaps > 2 # 间隔超2小时视为异常 # 步骤2：标记受影响SKU outage_period = df.loc[system_outage, 'ship_time'].agg(['min', 'max']) affected_skus = set(df[ (df['ship_time'] >= outage_period['min']) & (df['ship_time'] <= outage_period['max']) ]['sku_id']) # 步骤3：填充策略（非简单均值） for sku in affected_skus: if sku in sku_category.index and sku_category.loc[sku, 'category'] == 'high_volume_standard': # 标品：用同类目均值+季节系数 category_mean = df[df['category'] == sku_category.loc[sku, 'category']]['sales_qty'].mean() season_factor = get_season_factor(outage_period['min'].month) # 基于历史月度波动 fill_value = category_mean * season_factor else: # 非标品：用最近7天同 weekday 销量中位数 last_week = outage_period['min'] - pd.Timedelta(days=7) fill_value = df[ (df['sku_id'] == sku) & (df['ship_time'].dt.weekday == outage_period['min'].weekday()) ]['sales_qty'].median() df.loc[(df['sku_id'] == sku) & system_outage, 'sales_qty'] = fill_value return df

这套清洗逻辑让数据准备阶段耗时增加40%，但后续模型在真实环境的泛化能力提升2.3倍。记住：清洗不是让数据“看起来干净”，而是让数据“说真话”。

3. 预测模型不是越复杂越好，而是越贴近决策场景越好

竞赛中常见“模型军备竞赛”：LSTM吊打ARIMA，Transformer碾压Prophet。但在我参与的12个电商项目中，最终上线的预测模型，83%是经过深度改造的Prophet变体。为什么？因为电商决策需要的不是“最精确的点预测”，而是“可解释的风险区间”。运营经理不会关心RMSE是多少，但他必须知道：“如果618当天温度超过35℃，防晒霜销量可能突破1200件，但若物流延误，实际到货量可能只有800件”。

3.1 Prophet的业务化改造：从“趋势拟合”到“策略响应”

标准Prophet默认拟合全局趋势，但电商需求受多重策略干预：

• 促销杠杆：满300减50 vs 满500减100，对客单价提升效应不同
• 流量入口：抖音直播间引流 vs 搜索自然流量，用户购买决策路径差异巨大
• 库存状态：当某SKU库存低于安全水位时，系统自动降低曝光权重，导致销量断崖式下跌

我们通过三重改造让Prophet具备业务感知力：

第一重：动态节假日效应

# 标准Prophet仅支持固定日期节假日，但电商大促日期每年浮动 # 我们构建“促销日历”作为外部变量 promo_calendar = pd.DataFrame({ 'ds': pd.date_range('2023-01-01', '2023-12-31', freq='D'), 'is_618': 0, 'is_double11': 0, 'is_flash_sale': 0 }) # 动态标记：根据当年平台公告自动识别 promo_calendar.loc[ (promo_calendar['ds'] >= '2023-06-01') & (promo_calendar['ds'] <= '2023-06-18'), 'is_618' ] = 1 # 同理标记双11、品牌日等... # 在Prophet中作为额外回归项 m = Prophet( holidays=promo_calendar[promo_calendar['is_618']==1][['ds']].rename(columns={'ds':'ds'}), seasonality_mode='multiplicative' ) m.add_regressor('is_618', mode='multiplicative') m.add_regressor('is_double11', mode='multiplicative')

第二重：库存状态反馈环

# 当库存低于阈值时，销量必然衰减，需在模型中显式建模 def add_stock_effect(df, stock_threshold=0.3): # stock_threshold: 安全库存占比阈值（如库存/日均销量 < 0.3则预警） df['stock_ratio'] = df['current_stock'] / df['avg_daily_sales'] df['stock_effect'] = np.where( df['stock_ratio'] < stock_threshold, 1 - (stock_threshold - df['stock_ratio']) / stock_threshold, 1.0 ) return df # 将stock_effect作为回归变量输入Prophet m.add_regressor('stock_effect', mode='multiplicative', prior_scale=0.5)

第三重：渠道归因分解

# 不同流量渠道的转化效率不同，需分离建模 channel_weights = { 'taobao_search': 0.12, # 搜索流量精准但量小 'douyin_live': 0.35, # 直播流量爆发力强但留存低 'wechat_mini': 0.28, # 私域流量复购率高 'jd_ad': 0.15, # 京东广告ROI稳定 'other': 0.10 } # 构建渠道加权销量序列 df['weighted_sales'] = ( df['taobao_search_sales'] * channel_weights['taobao_search'] + df['douyin_live_sales'] * channel_weights['douyin_live'] + df['wechat_mini_sales'] * channel_weights['wechat_mini'] + df['jd_ad_sales'] * channel_weights['jd_ad'] + df['other_sales'] * channel_weights['other'] ) # 用weighted_sales作为Prophet的y值

这套改造使Prophet在618预测中，对“爆款单品”的峰值捕捉准确率从68%提升至89%，更重要的是，它能输出每个预测值的置信区间，并标注区间宽度主要由哪个因素驱动（如“该区间宽幅主要源于直播流量不确定性”）。

3.2 XGBoost的特征工程：把业务知识编译成向量

当Prophet处理不了的复杂关系出现时（如新品上市、竞品突然降价），我们启用XGBoost作为补充模型。但它的威力不在于树的数量，而在于特征设计是否反映真实业务逻辑。

我们构建的特征体系分为四层：

关键创新点在于动态特征窗口：

# 传统固定窗口（如7天）无法适应不同品类节奏 # 我们按SKU类别动态设置窗口长度 window_map = { 'high_volume_standard': 3, # 标品变化快，用3天窗口 'low_volume_premium': 14, # 高端品决策慢，用14天窗口 'volatile_niche': 1 # 长尾品用当日特征为主 } def build_dynamic_features(df, sku_category): features = [] for sku, category in sku_category.items(): window_size = window_map.get(category, 7) sku_data = df[df['sku_id'] == sku].copy() # 构建滚动特征（窗口长度随品类变化） sku_data[f'sales_rolling_{window_size}d'] = sku_data['sales_qty'].rolling( window=window_size, min_periods=1 ).mean() # 构建滞后特征（避免未来信息泄露） sku_data[f'sales_lag_{window_size}d'] = sku_data['sales_qty'].shift(window_size) features.append(sku_data) return pd.concat(features, ignore_index=True)

这套特征工程使XGBoost在新品预测任务中，首月销量预测误差控制在±15%以内，而传统方法误差常达±60%。

3.3 模型融合：不是简单加权，而是风险分级决策

最终预测结果不是Prophet和XGBoost的加权平均，而是基于决策场景的风险分级：

def get_final_forecast(df, scenario='daily_replenishment'): if scenario == 'daily_replenishment': prophet_pred = m.predict(df) xgb_pred = xgb_model.predict(df[feature_cols]) # Prophet主导，XGBoost仅修正异常点 final_pred = prophet_pred['yhat'] * 0.8 + xgb_pred * 0.2 elif scenario == 'major_promotion': # XGBoost主导，但用Prophet的uncertainty区间做约束 xgb_pred = xgb_model.predict(df[feature_cols]) prophet_uncertainty = prophet_pred['yhat_upper'] - prophet_pred['yhat_lower'] # 若XGBoost预测值超出Prophet置信区间，则向区间中心收缩 final_pred = np.where( (xgb_pred > prophet_pred['yhat_upper']) | (xgb_pred < prophet_pred['yhat_lower']), (prophet_pred['yhat_upper'] + prophet_pred['yhat_lower']) / 2, xgb_pred ) return final_pred

这种融合逻辑让预测结果不再是冰冷的数字，而是带着业务语义的决策建议。

4. 库存优化不是数学题，而是多目标博弈的实时求解

预测只是起点，库存优化才是真正的战场。很多方案止步于“EOQ经济订货量公式”，但在真实电商环境中，EOQ假设的“需求恒定、无缺货成本、无批量折扣”全部不成立。我们曾为某宠物食品商家设计库存策略，其核心矛盾是：既要避免狗粮临期报废（损耗率12%），又要保证猫砂不断货（缺货损失是毛利的3.2倍）。这本质上是一个带约束的多目标优化问题。

4.1 构建真实成本函数：把业务痛点击穿成数学表达

标准库存模型的成本项过于理想化。我们定义的实际成本函数包含七类：

def calculate_total_cost(inventory_plan, demand_forecast, sku_params): """ inventory_plan: {sku_id: {'order_qty': 1000, 'reorder_point': 200}} demand_forecast: 预测销量序列（未来30天） sku_params: SKU特有参数（保质期、体积、成本等） """ total_cost = 0 for sku_id, plan in inventory_plan.items(): # 持有成本（按日滚动计算） daily_holding_cost = 0 current_inventory = plan['reorder_point'] # 初始库存设为再订货点 for day in range(len(demand_forecast)): # 每日库存 = 上日库存 + 到货 - 预测销量 if day in plan['delivery_schedule']: current_inventory += plan['order_qty'] current_inventory -= demand_forecast.iloc[day]['forecast_qty'] current_inventory = max(0, current_inventory) # 库存不能为负 # 计算当日持有成本 daily_holding_cost += current_inventory * sku_params[sku_id]['unit_cost'] * 0.18 / 365 # 缺货成本（预测销量 > 可用库存时） shortage_cost = 0 for day in range(len(demand_forecast)): available = current_inventory if day == 0 else 0 # 简化计算，实际需模拟每日库存 if demand_forecast.iloc[day]['forecast_qty'] > available: shortage_cost += (demand_forecast.iloc[day]['forecast_qty'] - available) * \ sku_params[sku_id]['gross_margin'] * 3.2 # 临期成本（基于效期倒计时） expiring_cost = 0 if sku_params[sku_id]['shelf_life_days'] < 60: expiring_qty = int(plan['order_qty'] * 0.3) # 预估30%临近效期 expiring_cost = expiring_qty * sku_params[sku_id]['unit_cost'] * 0.7 total_cost += daily_holding_cost + shortage_cost + expiring_cost + \ plan['order_qty'] * sku_params[sku_id]['unit_price'] * (1 - 0.05) + \ plan['order_qty'] * 2.3 + \ (plan['order_qty'] * sku_params[sku_id]['volume_m3']) * 120 / 30 return total_cost

4.2 约束条件建模：让数学解不脱离业务现实

优化算法必须尊重硬性约束，否则结果不可执行。我们归纳出电商库存的五大刚性约束：

1. 采购最小起订量（MOQ）：供应商要求单次订单≥500件
2. 仓储空间上限：当前仓库剩余容积仅够存放2300m³货物
3. 资金预算限制：本月采购预算上限为￥85万元
4. 物流承运能力：合作快递公司日均最大发货量1.2万单
5. 效期合规要求：所有入库商品剩余保质期≥总保质期的60%

# 使用PuLP构建线性规划模型 from pulp import LpProblem, LpMinimize, LpVariable, lpSum def build_inventory_optimization_model(demand_forecast, sku_params, constraints): prob = LpProblem("Inventory_Optimization", LpMinimize) # 决策变量：各SKU订购量 order_vars = {} for sku_id in sku_params.keys(): # 变量名格式：order_qty_SKU123 order_vars[sku_id] = LpVariable(f'order_qty_{sku_id}', lowBound=0, cat='Integer') # 目标函数：总成本最小化 prob += lpSum([ order_vars[sku_id] * sku_params[sku_id]['unit_cost'] * (1 - 0.05) * 0.18 / 365 * 30 + # 持有成本 order_vars[sku_id] * 2.3 + # 物流成本 order_vars[sku_id] * sku_params[sku_id]['volume_m3'] * 120 / 30 # 仓储成本 for sku_id in sku_params.keys() ]) # 约束1：MOQ约束 for sku_id in sku_params.keys(): prob += order_vars[sku_id] >= constraints['moq'][sku_id] # 约束2：仓储空间约束 prob += lpSum([ order_vars[sku_id] * sku_params[sku_id]['volume_m3'] for sku_id in sku_params.keys() ]) <= constraints['warehouse_capacity'] # 约束3：资金预算约束 prob += lpSum([ order_vars[sku_id] * sku_params[sku_id]['unit_cost'] * (1 - 0.05) for sku_id in sku_params.keys() ]) <= constraints['budget_limit'] # 约束4：物流能力约束（按日均发货量折算） total_order_qty = lpSum([order_vars[sku_id] for sku_id in sku_params.keys()]) prob += total_order_qty / 30 <= constraints['logistics_capacity'] # 月订单量/30 ≤ 日均能力 # 约束5：效期约束（通过采购批次控制，此处简化为SKU属性过滤） # 实际系统中，此约束在采购订单生成时由WMS校验 return prob, order_vars # 求解并返回最优订购方案 prob, order_vars = build_inventory_optimization_model(demand_forecast, sku_params, constraints) prob.solve() optimal_plan = {sku_id: int(order_vars[sku_id].value()) for sku_id in sku_params.keys()}

4.3 动态再平衡：让库存策略随业务流实时进化

静态优化结果在落地时必然失效。我们设计了三层动态调整机制：

第一层：实时监控告警

• 当某SKU实际销量连续3天超出预测值20%，触发“需求突增”告警，自动启动紧急补货流程
• 当库存周转天数低于阈值（如标品<15天），触发“库存过低”告警，推送至采购经理企业微信

第二层：滚动优化窗口

• 每日用最新7天实际销量重跑预测模型
• 每周用滚动30天数据重算EOQ参数
• 每月根据财务结算数据更新成本系数

第三层：人工干预接口

• 所有自动化建议标注置信度（如“此补货建议置信度82%，主要风险：抖音直播间明日开播”）
• 运营经理可在系统中一键否决，并填写原因（如“已确认竞品下周降价，暂缓补货”），该反馈将进入模型再训练队列

# 动态再平衡调度器 class InventoryRebalancer: def __init__(self, forecast_model, optimization_model): self.forecast_model = forecast_model self.optimization_model = optimization_model self.alert_rules = { 'demand_spike': {'threshold': 0.2, 'window': 3, 'action': 'emergency_order'}, 'stock_low': {'threshold': 15, 'metric': 'turnover_days', 'action': 'alert_procurement'} } def check_alerts(self, actual_sales, inventory_status): alerts = [] for rule_name, rule in self.alert_rules.items(): if rule_name == 'demand_spike': # 计算最近3天实际销量/预测销量比值 recent_ratio = actual_sales[-3:].sum() / self.forecast_model.predict_recent(3).sum() if recent_ratio > 1 + rule['threshold']: alerts.append({ 'type': rule_name, 'level': 'high', 'suggestion': f'启动{rule["action"]}，建议补货量：{int(actual_sales[-1]*1.5)}件' }) elif rule_name == 'stock_low': turnover_days = inventory_status['current_stock'] / inventory_status['avg_daily_sales'] if turnover_days < rule['threshold']: alerts.append({ 'type': rule_name, 'level': 'medium', 'suggestion': f'{rule["action"]}，当前周转天数：{turnover_days:.1f}天' }) return alerts def run_daily_optimization(self): # 获取最新7天实际销量 recent_sales = get_actual_sales(days=7) # 重训预测模型 self.forecast_model.retrain(recent_sales) # 生成新预测 new_forecast = self.forecast_model.predict_next_30days() # 重跑库存优化 new_plan = self.optimization_model.solve(new_forecast) return new_plan # 每日凌晨2点自动执行 rebalancer = InventoryRebalancer(forecast_model, optimization_model) daily_plan = rebalancer.run_daily_optimization() alerts = rebalancer.check_alerts(get_actual_sales(3), get_inventory_status())

这套机制让库存策略从“季度计划”进化为“分钟级响应”，某母婴商家上线后，缺货率下降37%，临期损耗减少29%，资金周转效率提升2.1倍。

5. 从代码到落地：那些竞赛文档里绝不会写的实战陷阱

竞赛代码追求“跑通即胜利”，但真实部署要面对千奇百怪的生产环境。我整理了五个血泪教训，都是踩坑后贴在办公室墙上的警示语：

5.1 “完美数据”不存在：处理上游系统脏数据的三板斧

某次上线前夜，我们发现ERP系统传来的sales_qty字段，对同一笔订单竟有三条记录：一条是下单量，一条是发货量，一条是退货量。而字段名全是sales_qty，没有类型标识。学生写的代码直接取sum，导致某日销量虚高300%。

解决方案：

1. 建立数据契约（Data Contract）：与ERP厂商签订协议，要求新增sales_type字段（值为'order','ship','return'）
2. 开发脏数据熔断器：当单日同一SKU出现>3条记录时，自动暂停该SKU数据接入，邮件告警
3. 业务兜底规则：若无sales_type，按ship_time是否为空判断——有ship_time为发货量，否则为订单量

def clean_erp_sales(df): # 熔断器：检测异常记录密度 sku_density = df.groupby('sku_id').size().max() if sku_density > 3: send_alert(f"SKU {df['sku_id'].mode()[0]} 数据密度异常：{sku_density}条/日") return df.iloc[0:0] # 返回空DataFrame暂停处理 # 业务规则兜底 if 'sales_type' not in df.columns: df['sales_type'] = np.where(df['ship_time'].notna(), 'ship', 'order') # 退货量需单独处理（通常有return_time字段） if 'return_time' in df.columns: df.loc[df['return_time'].notna(), 'sales_type'] = 'return' # 按类型聚合 cleaned = df.groupby(['sku_id', 'date', 'sales_type'])['sales_qty'].sum().reset_index() return cleaned

5.2 时间窗口陷阱：别让“UTC时间”毁掉你的大促预测

竞赛数据通常是本地时间，但云服务器默认UTC。某次618预测，模型在UTC时间0点触发，结果把凌晨1点（北京时间）的销量当作“当日首小时”，导致全天预测整体偏移。更致命的是，时区转换时未考虑夏令时，6月数据用UTC+8，7月却用UTC+7，造成连续两周预测崩盘。

解决方案：

• 所有时间字段入库前强制转为Asia/Shanghai时区
• 在配置文件中明确定义TIMEZONE = 'Asia/Shanghai'
• 每次时间操作后，用df['time'].dt.tz_localize(None)清除时区信息，避免隐式转换

# 统一时区处理模板 def standardize_timezone(df, time_col='ship_time'): # 确保时间列是datetime类型 df[time_col] = pd.to_datetime(df[time_col]) # 强制转为上海时区 if df[time_col].dt.tz is None: df[time_col] = df[time_col].dt.tz_localize('Asia/Shanghai') else: df[time_col] = df[time_col].dt.tz_convert('Asia/Shanghai') # 清除时区信息，避免后续操作混乱 df[time_col] = df[time_col].dt.tz_localize(None) return df # 在数据管道入口处统一调用 df = standardize_timezone(df, 'ship_time') df = standardize_timezone(df, 'pay_time')

5.3 模型漂移预警：当昨天的准确率变成今天的灾难

模型上线后第三周，预测准确率从85%暴跌至52%。排查发现，某KOL在抖音发布“某奶粉致敏”不实视频，导致该品类销量断崖下跌，但模型仍按历史规律预测。这暴露了无监控的模型等于定时炸弹。

解决方案：

• 设置三层漂移