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%。如果重来一次，会在数据治理上投入更多前期时间。
