Реализация прогнозирования временных рядов (Time Series Forecasting)

Реализация прогнозирования временных рядов (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

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 выхода модели.

Сравнение подходов к валидации

Мы используем walk-forward с overlap, так как он даёт наиболее стабильные метрики и соответствует продакшен-нагрузке.

Сравнение моделей по критериям

Пошаговый план внедрения системы прогнозирования

1. Анализ исходных данных и выявление закономерностей (стационарность, сезонность, прерывистость).
2. Выбор baseline и 3–5 кандидатов (от простых до сложных).
3. Walk-forward валидация каждой модели и сравнение по метрикам (MAPE, RMSE, MASE).
4. Разработка production pipeline: версионирование экспериментов в MLflow, оркестрация в Airflow, мониторинг дрейфа в Evidently.
5. Интеграция прогнозов в Data Warehouse и настройка алертов при отклонениях.

Сроки: от 2–3 недель для baseline до 8–12 недель для полной системы с квантилями и дрифт-мониторингом. Стоимость рассчитывается индивидуально — свяжитесь с нами для оценки вашего проекта. Для получения детального коммерческого предложения оставьте заявку.

Опыт нашей команды — более 20 реализованных проектов, среднее снижение MAPE на 15–30% после настройки модели. Обращайтесь — оценим ваш временной ряд, подберём стек и подготовим roadmap за 2–3 дня.

Какие проблемы прогнозирования временных рядов встречаются чаще всего?

Финансовый директор запрашивает прогнозирование временных рядов продаж на квартал. Аналитик строит SARIMA, добивается MAPE 8.3% на тестовой выборке — и с гордостью деплоит. Через два месяца в production метрика падает до 23%. Причина классическая: модель обучалась на данных до COVID, тестировалась на стабильном периоде, а production попал на промо-акцию и сбой поставок. Data leakage + distribution shift = красивые цифры в ноутбуке и неработающий прогноз в реальности. Мы сталкивались с этим десятки раз. Наш опыт — 5+ лет в прогнозировании временных рядов для ритейла, финтеха и IoT, более 50 завершённых проектов.

Неправильная кросс-валидация. Стандартный train_test_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) — отличный старт для бизнес-данных с понятной сезонностью и праздниками. Быстро настраивается, интерпретируем, встроенная обработка выбросов и пропусков. Падает в точности при нерегулярных паттернах и не масштабируется на десятки тысяч рядов без параллелизации. Prophet (Facebook) — официальная документация.

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

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

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

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

Как мы разворачиваем TFT в production?

TFT требует тщательной подготовки данных. Типичный пайплайн через 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-данных.

Пошаговая инструкция по настройке TFT

1. Сбор и подготовка данных. Обработать пропуски (маркировать NaN, интерполировать только если это технический сбой), агрегировать до нужной частоты, сформировать ковариаты (праздники, промо, цены).
2. Создание TimeSeriesDataSet. Указать group_ids (например, магазин+SKU), временной индекс, горизонт прогноза. Настроить target_normalizer с учётом распределения таргета.
3. Обучение baseline. Сначала Prophet или LightGBM — чтобы понять, насколько сложнее задача.
4. Тренировка TFT. Запустить TemporalFusionTransformer с loss=QuantileLoss(), подобрать learning rate и размеры hidden слоёв. Использовать pytorch_forecasting или neuralforecast.
5. Валидация и интерпретация. Проверить walk-forward, проанализировать variable selection, построить attention heatmap.

Кейс: прогноз спроса в ритейле. Сеть из 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 влияет сильнее, чем сама дата праздника. Средняя экономия бюджета на инференсе для клиента составила 1.5 млн ₽ в год.

Как правильно оценивать качество прогнозов?

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

• MAPE — интерпретируема, но нестабильна при значениях близких к нулю
• sMAPE — симметричная версия, избегает деления на маленькие числа
• MASE (Mean Absolute Scaled Error) — нормализован относительно наивного сезонного прогноза, отлично подходит для сравнения между рядами с разными масштабами
• Quantile loss / Pinball loss — для вероятностного прогнозирования, оценка покрытия интервалов

Гарантируем: мы предоставляем model card с этими метриками на валидационной выборке и результаты walk-forward теста на истории не менее 6 месяцев.

Что входит в работу

• Документация по выбранной архитектуре, обоснование выбора гиперпараметров.
• Воспроизводимый пайплайн обучения и инференса (Docker + CI/CD + Airflow/Prefect).
• Код с комментариями и модульными тестами на ключевые компоненты.
• Обучение вашей команды: как переобучать модель, как интерпретировать выходы, как деплоить новые версии.
• Поддержка в течение 3 месяцев после сдачи: консультации, фиксы багов, донастройка.

Процесс работы

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

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

Сроки ориентировочно: MVP-прогноз на одном типе данных — 3–6 недель. Иерархическая система прогнозирования с автоматизацией — 2–5 месяцев. Стоимость рассчитывается индивидуально.

Наша команда — сертифицированные ML-инженеры (AWS ML Specialty, GCP Professional ML Engineer). За 5 лет на рынке реализовали более 50 проектов по прогнозированию. Свяжитесь с нами для бесплатного анализа ваших данных — мы оценим задачу и дадим первые рекомендации за 1–2 дня. Закажите консультацию и убедитесь, что ваши прогнозы работают в production, а не только в ноутбуке.