Supply Chain Demand Forecasting & Inventory Optimization

Two costs that pull in opposite directions

Retailers carry inventory under fundamental uncertainty about future demand. Get it wrong in either direction and you pay:

Getting the balance right requires knowing, as accurately as possible, how much of each product will sell over the next four weeks — and how uncertain that estimate is. This project builds the full system: from raw sales history to a live API that answers both questions on demand.

Walmart M5: one of the hardest public forecasting benchmarks

The M5 Forecasting Competition dataset contains hierarchical daily unit sales from Walmart stores across three U.S. states. The pipeline is demonstrated on CA_1 (California, Store 1) with the option to scale to all 10 stores in parallel.

Raw data arrives in wide format — one column per day, one row per item. The pipeline immediately melts it to long format (item × date rows), merges the calendar and price tables, and applies dtype optimization (categoricals, float32 lags) to keep memory under 2 GB.

Aggregate Sales Trend, 2011–2016

Seasonality Patterns

Event & SNAP Impact

One global LightGBM model for 3,049 SKUs

The global approach has three advantages over per-series models:

• Sparse-item learning — a slow-moving item with 2 years of mostly-zero history borrows signal from similar items with richer histories.
• Cross-item generalization — price sensitivity and event response patterns transfer across the catalog.
• Training speed — one model in ~2 minutes vs 3,049 models in hours.

Objective Function: Tweedie Regression

LightGBM is configured with Tweedie loss rather than squared-error. Retail sales are zero-inflated and right-skewed — most (item, day) pairs sell 0–2 units, but occasionally an item sells 20+. Squared-error gets dominated by those outliers. Tweedie is the proper distribution for compound Poisson count data.

The Tweedie variance power p = 1.231 was found by Optuna (between Poisson p=1 and Gamma p=2), reflecting moderate overdispersion.

Feature Engineering

Feature Importance

Hyperparameter Optimization with Optuna

Rather than grid search, the pipeline uses Optuna TPE (Tree-structured Parzen Estimator) — a Bayesian optimization algorithm that builds a probabilistic model of the loss surface and proposes new configurations intelligently. 20 trials over 7 hyperparameters.

Results: LightGBM vs Naive Seasonal Baseline

The benchmark is Naive Seasonal — which predicts that any day's sales will equal the same weekday from 4 weeks ago. This is a strong baseline for retail data; beating it requires genuinely capturing patterns the calendar can't explain.

RMSE — average forecast error in units, with larger errors penalized quadratically.   MAE — average absolute error in units.   MASE — MAE scaled by the naive baseline on training data; values near 1 mean the model performs like naive on training but outperforms on held-out validation — the expected pattern for a model that generalizes while per-item naive baselines overfit historical noise.

28-day recursive forecasting with uncertainty bands

Prediction Intervals (Phase 4)

A point forecast alone is incomplete for inventory decisions. Three separate LightGBM models are trained with quantile (pinball) loss at the 10th, 50th, and 90th percentiles to bound uncertainty.

Recursive 28-Day Forecast (Phase 5)

The recursive challenge: the model was trained on features like lag_7 (sales 7 days ago). On forecast day 8, "7 days ago" is itself a predicted value. The pipeline handles this with a rolling buffer — each step appends its own output and recomputes all lag/rolling features before predicting the next.

WRMSSE — The M5 Competition Metric

Weighted Root Mean Squared Scaled Error is the official M5 metric. It measures forecast accuracy, normalized by each item's historical variance, then weighted by that item's revenue contribution. A score of 1.0 means the model performs identically to the naïve seasonal baseline. Lower is better.

Translating forecasts into purchasing decisions

A forecast that lives only in a CSV is not useful. Phase 6 converts each item's demand forecast and uncertainty estimate into three concrete purchasing parameters using the continuous-review inventory model — the same framework used by major retailers worldwide.

Safety Stock

Buffer inventory held to absorb demand uncertainty during the replenishment lead time. Higher uncertainty and longer lead times both require more buffer.

σ is derived from Phase 4's quantile spread: for a normal distribution, P90 − P10 ≈ 2.563 × σ. The quantile models do double duty — prediction intervals and volatility estimates for inventory.

Reorder Point

The inventory level at which a replenishment order is triggered. Designed so that, in the average demand scenario, inventory won't reach zero before the order arrives.

Economic Order Quantity

How much to order each time. Balances the cost of ordering frequently (fixed $50 per order) against the cost of holding large quantities (capital tied up, warehouse space).

Inventory Overview — CA_1 (3,049 items)

Store-Level Summary

The median item needs fewer than 4 units of safety stock and triggers an order at 9 units on hand — appropriate for slow-moving SKUs. The top-volume items (ROP = 490) require daily monitoring and represent an operationally different challenge.

Walk-forward validation: proving the model generalizes

Evaluating on a single held-out period can be misleading — maybe the model got lucky on that particular window. Walk-forward (rolling-origin) validation tests the model on four consecutive future windows, retraining from scratch at each origin.

This simulates production: the model is retrained periodically as new data arrives, then evaluated on the next month it has never seen.

The slight upward drift in RMSE in later windows is matched by the baseline's own drift — the relative improvement stays flat. This means signal-to-noise in the data is stable; the model is not degrading.

REST API + Interactive Dashboard

The batch pipeline writes Parquet outputs once (or on schedule). The FastAPI server is the low-latency serving layer on top: reads outputs, caches DataFrames in memory with a 1-hour TTL, and answers queries in milliseconds.

Design note: /forecast reads from Parquet — not from the live model. This means sub-millisecond response times at the cost of freshness (refresh by re-running Phase 5). /inventory computes on-the-fly, letting users query any lead time or service level without re-running Phase 6.

Example: Forecast Response

GET /forecast/CA_1/FOODS_1_001_CA_1_evaluation

{
  "store":    "CA_1",
  "item_id":  "FOODS_1_001_CA_1_evaluation",
  "n_days":   28,
  "forecasts": [
    {
      "date":         "2016-04-25",
      "pred_point":   0.7978,
      "pred_q10":     0.0,
      "pred_q50":     0.9599,
      "pred_q90":     2.5654,
      "actual_sales": 2.0
    },
    ... 27 more days
  ]
}

Example: Inventory Response

POST /inventory
{ "store": "CA_1", "item_id": "FOODS_1_001_CA_1_evaluation",
  "lead_time": 7, "service_level": 0.95 }

{
  "mean_daily_demand":  0.861,
  "demand_std_daily":   0.902,
  "lead_time_demand":   6.02,
  "safety_stock":        3.9,   ← hold this much buffer
  "reorder_point":       9.9,   ← order when stock hits this
  "eoq":                396.3,  ← order this many units
  "days_of_supply_ss":   4.6
}

Tech Stack

Seven-phase pipeline, end to end