Прогнозування попиту передбачає, скільки продукту чи послуги буде потрібно в майбутньому. Воно керує плануванням запасів, штатним розкладом, ціноутворенням та рішеннями supply chain. Помилка означає або stockouts (втрачені продажі), або overstock (заморожений капітал).

Де використовується

Прогнозування попиту критичне в різних індустріях:

Retail: Прогноз на рівні SKU для оптимізації запасів
E-commerce: Стокування складів, планування потужності доставки
Виробництво: Планування виробництва, замовлення сировини
Енергетика: Прогноз навантаження для управління мережею
Транспорт: Попит на поїздки, прогноз бронювань
Hospitality: Завантаженість готелів, резервації ресторанів

Продукти: Amazon fulfillment, Uber surge pricing, Walmart inventory, Starbucks staffing.

Типові дані

Аспект	Типові значення
Гранулярність	Погодинна, щоденна, щотижнева
Довжина історії	2-5 років
Entities	1K до 1M SKUs/локацій
Exogenous features	10-50 змінних
Горизонт прогнозу	1 день до 52 тижнів

Типова структура таблиці:

date | sku_id | location_id | sales_qty | price | promo_flag | stock_level

Зовнішні джерела даних: - Календарні ознаки: свята, події, дні тижня - Погодні дані: температура, опади - Маркетинг: промо-акції, кампанії, рекламні витрати - Економічні індикатори: ВВП, споживча довіра - Дії конкурентів: ціни, запуски

Що робимо на практиці

Визначити scope прогнозу - Які entities, який горизонт, яка частота?
Зібрати історичні дані - Продажі, запаси, stockouts, зовнішні фактори
Обробити проблеми даних - Відсутні дні, нулі vs stockouts, викиди
Ідентифікувати патерни - Тренд, сезонність, ефекти свят, промо
Побудувати ієрархію - Категорії продуктів, регіони, рівні агрегації
Натренувати baseline модель - Просте exponential smoothing або seasonal naive
Додати ML моделі - Gradient boosting з lag features, або deep learning
Узгодити прогнози - Забезпечити консистентність ієрархії (прогнози магазинів сумуються до регіону)
Оцінити правильно - Time-based splits, кілька горизонтів, бізнес-метрики
Задеплоїти та моніторити - Відстежувати точність по сегментах, ретренувати за розкладом

Спочатку Baseline

Два baseline, які потрібні кожному forecasting проекту:

Seasonal naive: Прогноз того ж значення, що й у той же період минулого року
Захоплює річну сезонність
Не потребує тюнінгу
Часто напрочуд конкурентний
Simple exponential smoothing: Зважене середнє недавніх спостережень
Захоплює рівень та тренд
Три параметри для тюнінгу
Швидко обчислюється

Якщо ваша ML-модель не б'є seasonal naive на 10%+, досліджуйте якість даних перед додаванням складності.

Типові моделі та коли їх обирати

Модель	Найкраще для	Обмеження
Exponential Smoothing (ETS)	Один ряд, чіткі патерни	Без зовнішніх ознак
ARIMA/SARIMA	Статистичний аналіз, довірчі інтервали	Складний тюнінг, повільно
Prophet	Бізнес-дані зі святами, кілька сезонностей	Може overfitнути, повільний в масштабі
XGBoost з lag features	Багато ознак, складні взаємодії	Потребує ретельного feature engineering
LightGBM	Великий масштаб, швидке тренування	Те ж, що XGBoost
DeepAR	Багато пов'язаних рядів, learned patterns	Потребує значних даних
Temporal Fusion Transformer	Складний multi-horizon, інтерпретованість	Обчислювально дорогий
N-BEATS	Сильний benchmark, без feature engineering	Black box

Індустріальний стандарт: Почніть з ETS або Prophet для baselines, переходьте до gradient boosting або deep learning для продакшну.

Патерни Feature Engineering

Lag features: - Продажі 1, 7, 14, 28, 364 дні тому - Rolling mean/std за 7, 28, 90 днів - Різниця від того ж періоду минулого року

Календарні ознаки: - День тижня, місяць, квартал (cyclical encoding) - Індикатори свят (з lead/lag ефектами) - Індикатори днів зарплати, шкільних канікул

Promotional features: - Прапор активного промо - Глибина знижки - Дні до/після промо - Кодування типу промо

Зовнішні ознаки: - Погода (температура, ймовірність дощу) - Події (спорт, концерти, локальні події) - Економічні індикатори

Ієрархічні ознаки: - Тренди на рівні категорії - Сезонність на рівні магазину - Cross-series патерни

Оцінка та метрики

Основні метрики:

Метрика	Формула	Use Case
MAPE	Mean Absolute Percentage Error	Легко інтерпретувати, але не працює на нулях
WMAPE	Weighted MAPE	Враховує різницю обсягів
RMSE	Root Mean Squared Error	Штрафує великі помилки
MAE	Mean Absolute Error	Стійка до викидів
Bias	Mean Error (signed)	Виявляє систематичне over/under прогнозування

Бізнес-метрики: - Service level: % попиту задоволеного - Inventory turns: Як швидко обертається запас - Stockout rate: % часу out of stock - Overstock cost: Капітал заморожений у надлишковому запасі

Підводні камені: - Оцінка лише на агрегаті (ховає погану продуктивність на рівні SKU) - Використання MAPE, коли нулі часті - Не оцінювати на горизонті, що важливий для рішень - Ігнорування bias (систематичне over або under прогнозування)

Режими відмови та чеклист дебагу

[ ] Data leakage: Використання майбутньої інформації (наприклад, реальних результатів промо)
[ ] Stockout confusion: Нулі - це stockouts, не низький попит
[ ] Outlier distortion: Black Friday, COVID ефекти домінують у моделі
[ ] Seasonality mismatch: Модель натренована на неправильному сезонному періоді
[ ] Promotion blindness: Модель не захоплює ефекти промо
[ ] New product cold start: Немає історії для нових SKU
[ ] Hierarchy inconsistency: Прогнози магазинів не сумуються до загального
[ ] Regime change: Фундаментальний зсув попиту не захоплений

Продакшн-чеклист

Перед деплоєм: - [ ] Backtesting по кількох часових періодах - [ ] Продуктивність прийнятна на всіх рівнях ієрархії - [ ] Cold start стратегія для нових продуктів - [ ] Обробка викидів визначена - [ ] Forecast intervals генеруються (не лише точкові прогнози)

Після деплою: - [ ] Щоденний моніторинг точності по сегментах - [ ] Відстеження bias (directional errors) - [ ] Автоматичний алерт на деградацію точності - [ ] Щотижневий/щомісячний schedule ретренування - [ ] Feedback loop з даними реальних продажів - [ ] Можливість human override для спеціальних подій

Інструменти та стек

Категорія	Інструменти
Статистичні моделі	statsmodels, Prophet, statsforecast
ML моделі	XGBoost, LightGBM, scikit-learn
Deep learning	PyTorch, GluonTS, Darts, NeuralForecast
Масштабований forecasting	Spark, Ray, Dask
Візуалізація	Plotly, matplotlib
Продакшн	Airflow, MLflow, cloud ML platforms

Приклад міні-кейсу

Сценарій: Grocery retailer потребує щоденних прогнозів на рівні SKU для 10K продуктів у 200 магазинах.

Дані: 3 роки щоденних продажів, промо, свята, погода.

Підхід: 1. Baseline: Seasonal naive (той же день минулого року) - WMAPE 35% 2. Feature engineering: Lag features, промо індикатори, ефекти свят 3. Модель: LightGBM з 28-денним горизонтом 4. Ієрархія: Тренування на рівні SKU-магазин, узгодження до категорії та магазину 5. Результат: WMAPE 22%, покращення 37%

Продакшн setup: - Нічний batch job обчислює наступні 28 днів - Щотижневий model refresh - Щоденний accuracy dashboard - Алерти на WMAPE > 30% для будь-якої категорії

Бізнес-вплив: 15% зменшення stockouts, 8% зменшення overstock.

Пов'язані сторінки

Індекс: ML Field Guide
Виявлення аномалій у часових рядах
Фінансові часові ряди
Основи Feature Engineering

Додаткове читання

Спробуйте наживо

Дослідіть пов'язану модель на практиці: відкрийте Demand Forecasting Simulator і змінюйте параметри під час роботи. Усе лишається у вашому браузері.

▶ Відкрити симуляцію Demand Forecasting Simulator