Прогнозування Часових Рядів: Від Prophet до Трансформерів

Фінансовий директор хочет прогноз продажів на квартал. Аналітик будує SARIMA, отримує MAPE 8.3% на тесті. Розгортає. Через два місяці MAPE у production 23%. Причина: модель навчена до COVID, тестована на стабільному періоді, а production потрапив на період з промо-акціями та збоями поставок. Data leakage + distribution shift = гарні числа у ноутбуці та неробоче прогнозування у production.

Типові Проблеми Прогнозування

Неправильна кросс-валідація. Стандартний train_test_split для часових рядів — помилка. Випадковий split створює data leakage: модель бачить "майбутні" дані при навчанні. Правильно — TimeSeriesSplit або walk-forward validation з expanding window.

Множественна сезонність. Почасові дані споживання електроенергії мають три сезонності: добову (24 ч), тижневу (168 ч), річну (8760 ч). SARIMA справляється тільки з однією. Prophet обробляє кілька, але повільно масштабується на тисячі рядів.

Пропуски та аномалії в даних. Пропуск у сенсорних даних — це інформація (датчик вимкнулся), а не просто NaN. Лінійна інтерполяція вбиває цей сигнал. Правильна обробка залежить від природи пропуска.

Cold start при ієрархічному прогнозуванні. Новий SKU у ассортименті з 50 000 позицій: історичних даних немає, потрібен прогноз. Стандартні моделі тут не працюють — потрібні cross-learning підходи або feature-based методи.

Інструменти та Коли Їх Застосовувати

Prophet (Meta) — чудовий старт для бізнес-даних з зрозумілою сезонністю та святами. Швидко налаштовується, інтерпретуємо, вбудована обробка викидів та пропусків. Падає на нерегулярних паттернах та не масштабується на десятки тисяч рядів без паралелізації. neuralprophet додає AR-компоненти та AutoML, але теряет інтерпретуємість.

Gradient boosting на features (LightGBM, XGBoost) — часто недооцінений підхід. Створюєте features вручну: лаги (t-1, t-7, t-28), скользящі середні, категоріальні ознаки (день тижня, місяць), екзогенні змінні. Модель учиться на всіх рядах одночасно — розв'язує cold start через схожі ряди. MAPE на ритейл-прогнозуванні часто краще нейронних сітей при правильній feature engineering.

TFT (Temporal Fusion Transformer) — трансформер, спеціально розроблений для інтерпретуємого прогнозування з коваріатами. Вбудовані механізми: variable selection (які features важливі), temporal self-attention (які часові точки впливають на прогноз), квантильні передсказання. Доступен у pytorch-forecasting. Потребує ~10 000+ записів на ряд для стабільного навчання.

PatchTST — трансформер, що ділить часовий ряд на патчи (аналогічно ViT для зображень). Краще захоплює локальні паттерни ніж класичні трансформери. Добре працює для long-horizon forecasting (96–720 кроків). Реалізація у neuralforecast від Nixtla.

N-HiTS, N-BEATS — нейронні архітектури без attention, швидше TFT, конкурентна точність. N-BEATS виграє на M4/M5 benchmark для задач без коваріат.

Глибше: TFT у Production

TFT потребує ретельної підготовки даних. Типовий pipeline через pytorch-forecasting:

training = TimeSeriesDataSet(
    data,
    time_idx="time_idx",
    target="sales",
    group_ids=["store", "sku"],
    min_encoder_length=max_encoder_length // 2,
    max_encoder_length=max_encoder_length,  # 120 днів
    min_prediction_length=1,
    max_prediction_length=max_prediction_length,  # 28 днів
    static_categoricals=["store_type", "category"],
    time_varying_known_reals=["price", "promo_flag"],
    time_varying_unknown_reals=["sales"],
    target_normalizer=GroupNormalizer(groups=["store", "sku"], transformation="softplus"),
)

Частая помилка: дефолтний target_normalizer (StandardScaler) ломає передсказання для рядів з нульовими значеннями (нет продаж у вихідні). GroupNormalizer з transformation="softplus" — правильний вибір для count-даних.

Кейс: прогноз спроса в ритейлі. Мережа з 120 магазинів, 8000 SKU, горизонт прогнозу 28 днів. Оригінальна система: SARIMA окремо для кожного ряду, MAPE 18.4%, повний цикл переучування — 6 годин. TFT на PyTorch + pytorch-forecasting: одна модель на все ряди, MAPE 11.2%, переучування — 40 хв на A10G. Додатковий бонус: feature importance через variable selection — виявилось, що day_before_holiday впливає сильніше, ніж саме свято.

Оцінка Якості Прогнозів

Не використовуйте RMSE як єдину метрику — вона сильно штрафує за великі помилки на великих значеннях. Для ритейл-прогнозування:

• MAPE — інтерпретуємо, але нестабільна при значеннях близько нуля
• sMAPE — симетрична версія, уникає ділення на малі числа
• MASE — нормалізована порівняно з наївним сезонним прогнозом, відмінно підходит для порівняння між рядами з різними масштабами
• Quantile loss / Pinball loss — для вероятностного прогнозування, оцінка покриття інтервалів

Процес Роботи

Починаємо з EDA: візуалізація, ADF тест на стаціонарність, STL-декомпозиція, аналіз пропусків та викидів. Це 2–3 дні, але часто виявляє системні проблеми даних, що блокують прогнозування.

Далі: baseline (наївний сезонний, Prophet), feature engineering для LGBM, вибір архітектури нейронної сіті якщо потрібно. Walk-forward validation з реалістичним горизонтом. Деплой через API з автоматичним переученням за розкладом через Airflow або Prefect.

Терміни: MVP-прогноз на одному типі даних — 3–6 тижнів. Ієрархічна система прогнозування з автоматизацією — 2–5 місяців.