AI赋能零售行业的项目复盘:智能补货系统的预测模型与工程架构
AI赋能零售行业的项目复盘:智能补货系统的预测模型与工程架构
一、零售补货的"要么太多、要么太少"困境
某连锁零售企业有300家门店,每家门店3000+ SKU。补货决策由门店经理凭经验手动完成,结果是:
- 畅销品经常断货(断货率约8%,每断货一天损失约$200销售)
- 滞销品积压严重(库存周转天数平均45天,行业优秀水平是25天)
- 生鲜损耗率约12%(过期报废)
目标是AI预测每个SKU在未来7天的销量,并自动生成补货建议。
二、预测模型:从简单到复杂的演进
第一版:移动平均(快速上线)
最简单的基线:过去7天的平均销量作为未来7天的预测。对稳定品类的误差约15%,但对促销和季节性品类完全不准确。
第二版:LightGBM + 特征工程
特征工程是核心——零售预测80%的准确率来自特征:
def build_retail_features(df: pd.DataFrame) -> pd.DataFrame: features = pd.DataFrame() # 时间特征 features['day_of_week'] = df['date'].dt.dayofweek features['is_weekend'] = features['day_of_week'] >= 5 features['is_month_start'] = df['date'].dt.is_month_start.astype(int) features['day_of_month'] = df['date'].dt.day # 滞后特征(过去1/3/7/14/28天的销量) for lag in [1, 3, 7, 14, 28]: features[f'sales_lag_{lag}'] = df['sales'].shift(lag) features[f'sales_lag_7_mean'] = df['sales'].shift(1).rolling(7).mean() # 外部特征 features['temperature'] = df['temperature'] features['is_holiday'] = df['date'].isin(HOLIDAYS).astype(int) features['is_promotion'] = df['promotion_flag'] # 品类特征 features['category_avg_7d'] = df.groupby('category')['sales'].transform('rolling', 7).mean() return featuresLightGBM的WAPE(加权绝对百分比误差)约18%。
第三版:时序Transformer + 集成
对于促销期间的销量预测(波动大),LightGBM表现不好。引入Temporal Fusion Transformer处理长时序依赖:
# TFT模型 + 与LightGBM的加权集成 def ensemble_predict(lgb_pred, tft_pred, is_promotion: bool, lgb_weight_regular=0.7, lgb_weight_promotion=0.3): """促销期间,TFT权重更高""" if is_promotion: return lgb_weight_promotion * lgb_pred + (1 - lgb_weight_promotion) * tft_pred else: return lgb_weight_regular * lgb_pred + (1 - lgb_weight_regular) * tft_pred集成后WAPE降到12.5%。特别是促销品类的误差从35%降到18%。
三、补货决策引擎
预测销量后,生成补货建议需要考虑安全库存:
def calculate_reorder_quantity( forecast_7d: float, current_stock: float, in_transit: float, lead_time_days: int, service_level: float = 0.95, ) -> ReorderResult: # 安全库存 = Z分数 × 需求标准差 × sqrt(提前期) z_score = norm.ppf(service_level) # 95%服务水平→z=1.645 daily_demand = forecast_7d / 7 demand_std = daily_demand * 0.3 # 假设变异系数30% safety_stock = z_score * demand_std * np.sqrt(lead_time_days) # 补货量 = 预测需求 + 安全库存 - 现有库存 - 在途库存 reorder_qty = forecast_7d + safety_stock - current_stock - in_transit # 考虑最小起订量和订货倍数 reorder_qty = max(0, reorder_qty) reorder_qty = ceil(reorder_qty / moq) * moq # MOQ倍数 return ReorderResult( forecast=forecast_7d, safety_stock=safety_stock, suggest_order=reorder_qty, urgency='high' if current_stock < daily_demand * 2 else 'normal', )四、落地效果
运行6个月后:
| 指标 | 人工补货 | AI补货 | 改善 |
|---|---|---|---|
| 断货率 | 8% | 3.2% | -60% |
| 库存周转天数 | 45天 | 32天 | -29% |
| 生鲜损耗率 | 12% | 6.5% | -46% |
| 库存金额 | $1200万 | $950万 | -21% |
年化节省库存成本约$250万(减少库存占用资金) + 减少断货损失约$180万。
五、总结
零售智能补货的核心经验:
- 移动平均做基线(1周上线),LightGBM做主力(85%场景),TFT处理促销(15%场景)
- 特征工程占模型精度的80%——滞后特征+外部特征(天气/节假日/促销)是关键
- 集成模型在不同场景用不同权重——促销时TFT权重更高
- 补货量计算需要考虑安全库存+最小起订量+在途库存——预测只是第一步
- 模型需要按品类独立训练——生鲜和耐用品的时间模式完全不同
最大的挑战不是模型训练,而是数据质量。POS系统的历史数据存在大量缺失(系统迁移导致)、异常(促销活动未标注导致销量尖峰被当作误差)和粒度不一致(部分门店按天、部分按小时)。数据清洗占了总工期的45%。如果重来一次,会在数据治理上投入更多前期时间。
