Реалізація прогнозування часових рядів (Time Series Forecasting)
Ми регулярно стикаємося з ситуацією, коли дані — продажі, IoT-датчики або біржові котирування — містять часові залежності, які легко порушити невірним обробленням. Неправильний split або ігнорування сезонності призводять до data leakage та хибно-оптимістичних результатів на backtest. Наприклад, в одному проекті з прогнозування попиту на запчастини seasonal naive давав MAPE 40%, а Prophet — 28%, але тільки після walk-forward валідації з'ясувалося, що Prophet на 10% гірший на останніх трьох місяцях. За кілька років реальних проектів ми реалізували понад 20 систем прогнозування та виробили robust-методологію, якою ділимося нижче. Для кожної задачі підбираємо стек: від класичних SARIMA до сучасних Transformer-архітектур, враховуючи бюджет та вимоги до інтерпретованості. Отримайте консультацію щодо вашого проекту — ми проаналізуємо дані та запропонуємо roadmap за 2–3 дні.
Класифікація часових рядів
Перед вибором методу — аналіз властивостей ряду:
- Стаціонарність: ADF-тест (Augmented Dickey-Fuller). Нестаціонарні ряди вимагають диференціювання або спеціальних методів.
- Сезонність: ACF/PACF аналіз. Одиночна (тижнева) або множинна (тижнева + річна) сезонність впливає на вибір моделі.
- Переривчастість (intermittency): ADI (Average Demand Interval) > 1.32 — спеціальні методи (Croston, IMAPA).
- Нелінійність: тест Teräsvirta / BDS-тест. Лінійні моделі (ARIMA) неадекватні при сильній нелінійності.
Як вибрати модель для часового ряду?
Універсальної відповіді немає — ми порівнюємо кандидатів на історичних даних. Ось типові варіанти з їх trade-off:
- Naive / Seasonal Naive — найпростіший baseline для перевірки, чи складні методи дійсно кращі.
- ETS (Exponential Smoothing) з автоматичним підбором — добре працює на рядах з одиночною сезонністю, але не підтримує множинні сезонності.
- SARIMA — класика з довірчими інтервалами, але повільна при великій кількості спостережень.
- Prophet — зручний для бізнес-даних зі святами, інтерпретований, але програє нейромережам на складних патернах.
- LightGBM з лагами — дає високу точність при множині зовнішніх факторів, але вимагає інженерної роботи над фічами.
- N-BEATS / N-HiTS — SOTA на змаганнях M4/M5, працюють без зовнішніх фіч, але залишаються чорним ящиком.
- Temporal Fusion Transformer — лідер для ансамблів множини рядів, але вимогливий до GPU та даних.
- TimesGPT / TimesFM — foundation-моделі для zero-shot прогнозу, прискорюють старт, але дорогі та менш контрольовані.
Правильний бектестинг
Проблема: стандартний train/test split порушує temporal ordering. Walk-Forward Validation:
|---Train---| Test | |----Train----| Test | |-----Train-----| Test | Average metrics across all windows Розмір тестового вікна = прогнозний горизонт. Крок зсуву = горизонт / 2 або = горизонт (без overlap).
Data leakage sources:
- Використання майбутніх даних у scaling (fit scaler на всьому датасеті)
- Target encoding з майбутніми значеннями
- External features з майбутньою інформацією (known future covariates vs. past covariates)
Чому walk-forward валідація обов'язкова?
Без неї будь-яка метрика на тесті буде оптимістичною. Ми гарантуємо, що всі моделі проходять часовий split без overlap. У проектах використовуємо бібліотеку statsforecast з автоматичним підбором вікна. Це єдиний спосіб отримати реалістичну оцінку якості та уникнути переплати за хибні очікування.
Feature Engineering для ML-підходу
Часові features:
df['hour'] = df.index.hour df['day_of_week'] = df.index.dayofweek df['week_of_year'] = df.index.isocalendar().week df['month'] = df.index.month df['is_weekend'] = df['day_of_week'].isin([5, 6]).astype(int) # Cyclical encoding df['sin_hour'] = np.sin(2 * np.pi * df['hour'] / 24) df['cos_hour'] = np.cos(2 * np.pi * df['hour'] / 24) Lag features: t-1, t-7, t-14, t-28 для денних даних; t-1, t-24, t-168 для погодинних.
Rolling statistics: середнє, std, min, max за 7/28/90 днів. Різниці: (t-1) - (t-7) для захоплення тренду.
Probabilistic Forecasting
Точковий прогноз без невизначеності — недостатньо для бізнес-рішень. Квантильні прогнози:
- Quantile Regression: LightGBM з
objective='quantile', alpha=0.1/0.5/0.9 - Conformal Prediction: теоретично обґрунтовані інтервали, не передбачають розподіл
- Monte Carlo Dropout: у нейромережах — ensemble через dropout в inference
- N-HiTS з квантилями: нативна підтримка в бібліотеці neuralforecast
Детальніше про квантильні прогнози
Квантильний прогноз дає інтервал [P10, P90] замість точкового значення. Це дозволяє бізнесу оцінити ризики: наприклад, закласти бюджет не за середнім, а за P90. Ми завжди включаємо квантилі в продакшен-системи.
Production Pipeline
# Приклад з Nixtla / statsforecast from statsforecast import StatsForecast from statsforecast.models import AutoARIMA, AutoETS, AutoTheta models = [AutoARIMA(season_length=7), AutoETS(season_length=7), AutoTheta()] sf = StatsForecast(models=models, freq='D', n_jobs=-1) sf.fit(train_df) forecasts = sf.predict(h=28, level=[80, 95]) MLflow tracking: кожен експеримент — версія даних, гіперпараметри, метрики, артефакт моделі. Scheduling: Airflow DAG для щоденного перенавчання та публікації прогнозів у Data Warehouse.
Моніторинг: Evidently для відстеження data drift вхідних фіч та prediction drift виходу моделі.
Порівняння підходів до валідації
| Метод валідації | Застосування | Особливості |
|---|---|---|
| Hold-out (train/test) | Швидкий baseline | Рве часову структуру, data leakage |
| Walk-forward з overlap | Рекомендується | Честна оцінка, ітеративне навчання |
| Rolling window (без overlap) | Альтернатива | Менше тестових вікон, швидше |
| Timeseries CV (наприклад, Blocked CV) | Бібліотеки scikit-learn | Зручно, але часто ігнорує сезонність |
Ми використовуємо walk-forward з overlap, оскільки він дає найбільш стабільні метрики та відповідає продакшен-навантаженню.
Порівняння моделей за критеріями
| Модель | Точність (MAPE) | Інтерпретованість | Підтримка множинної сезонності | Час навчання |
|---|---|---|---|---|
| Prophet | Середня | Висока | Частково | Швидко |
| N-BEATS | Висока | Низька | Так | Середньо |
| LightGBM | Висока | Середня | Ні (потрібні лаги) | Швидко |
| TFT | Дуже висока | Низька | Так | Довго (GPU) |
Поетапний план впровадження системи прогнозування
- Аналіз вихідних даних та виявлення закономірностей (стаціонарність, сезонність, переривчастість).
- Вибір baseline та 3–5 кандидатів (від простих до складних).
- Walk-forward валідація кожної моделі та порівняння за метриками (MAPE, RMSE, MASE).
- Розробка production pipeline: версіонування експериментів у MLflow, оркестрація в Airflow, моніторинг дрейфу в Evidently.
- Інтеграція прогнозів у Data Warehouse та налаштування алертів при відхиленнях.
Терміни: від 2–3 тижнів для baseline до 8–12 тижнів для повної системи з квантилями та дрифт-моніторингом. Вартість розраховується індивідуально — зв'яжіться з нами для оцінки вашого проекту. Для отримання детальної комерційної пропозиції залиште заявку.
Досвід нашої команди — понад 20 реалізованих проектів, середнє зниження MAPE на 15–30% після налаштування моделі. Звертайтеся — оцінимо ваш часовий ряд, підберемо стек та підготуємо roadmap за 2–3 дні.







