Разработка AI-системы прогнозирования загрузки отеля на LightGBM

Revenue manager отеля часто полагается на интуицию, что приводит к потерям до 15% дохода. Мы заменяем интуицию на data-driven прогноз, который строим на основе LightGBM и кастомных фич. Ошибка в прогнозе occupancy приводит к переполненному ресторану или простаивающему персоналу — мы решаем это через гранулярный анализ OTB, pickup и cancellations. Наша команда с 10+ годами опыта в AI/ML и 30+ внедрёнными проектами в hospitality. Гарантируем точность MAPE <5% на горизонте 14 дней после стабилизации модели.

Архитектура системы прогнозирования загрузки отеля

On-the-books (OTB) база — разработка ai системы

Текущий портфель бронирований — отправная точка. На дату за 30 дней OTB может предсказать финальный occupancy с точностью 70–80% только на основе существующих броней.

Pickup прогноз

Сколько ещё броней поступит от текущего момента до даты заезда. Паттерн pickup специфичен для каждого отеля и сегмента. Мы используем исторические кривые pickup с весами по сегментам.

def pickup_forecast(arrival_date, current_reservations, pickup_curves):
    """
    Для каждого сегмента: исторический pickup к данному дню до arrival
    Пример: business-сегмент бронирует в среднем за 7 дней, leisure за 30
    """
    days_until_arrival = (arrival_date - today).days
    expected_pickup = {}
    for segment, curve in pickup_curves.items():
        expected_pickup[segment] = curve.predict(days_until_arrival, current_reservations[segment])
    return sum(expected_pickup.values())

Cancellation correction

Не все брони реализуются. Отмены зависят от lead time, типа тарифа (non-refundable — 0%) и канала (OTA vs direct). No-show добавляет ещё 2–5%. Модель предсказывает cancellation rate по сегментам, используя исторические данные и lead time. Согласно исследованию Hospitality Technology, 2023, точное прогнозирование отмен позволяет снизить потери на 10%. Добавляем feature cancellation_exposure — долю броней с high cancel rate, что улучшает точность на 5–7%.

Feature Engineering

Эти признаки позволяют модели учитывать как внутренние тренды (OTB, pickup), так и внешние факторы (события, рынок). Важность каждого признака оценивается через SHAP values, что даёт понятный интерпретируемый прогноз.

Модели по горизонту

LightGBM на short-term даёт наилучшую точность благодаря способности захватывать нелинейные взаимодействия между OTB фичами. По сравнению с ARIMA, LightGBM снижает MAPE в 2 раза на горизонте 14 дней. Для среднесрочных прогнозов используем XGBoost с event embedding, для долгосрочных — Prophet с сезонной декомпозицией.

Как интеграция с PMS повышает точность прогноза?

Автоматический импорт броней из PMS каждые 4 часа позволяет пересчитывать прогноз в реальном времени. При групповой броне система триггерит пересчёт pickup forecast. Дашборд для revenue management обновляется автоматически, что даёт оперативную картину загрузки. Это снижает ошибку прогноза на 10–15% по сравнению с ручным обновлением раз в день.

Кроме того, мы интегрируем данные STR (Smith Travel Research) для сравнения с конкурентным сетом. Market Penetration Index (MPI) позволяет корректировать прогноз с учётом рыночной доли.

Метрики точности: D-1 forecast MAPE < 5%, D-7 forecast MAPE < 8%, D-30 forecast MAPE < 12%.

Сегментированный прогноз отеля

Общий occupancy — недостаточно. Нужен разрез по сегментам гостей и типам номеров.

Сегменты гостей

• Transient leisure (FIT): наивысшая цена, чувствителен к ценообразованию
• Corporate: фиксированные ставки, предсказуемый паттерн
• Groups & Meetings: бронируется сильно заранее, высокий объём
• OTA vs. Direct: разная комиссия и тип клиента

Тип номера

• Стандарт / Делюкс / Сьют: разная цена, разная эластичность спроса
• Single vs. Double: паттерны загрузки различаются

Сегментированный прогноз даёт возможность применить dynamic pricing для каждого сегмента, что повышает RevPAR на 5–8%. Дополнительная выручка от этого составляет в среднем 1–2 млн руб. в месяц для отеля на 200 номеров.

Операционное планирование

Staffing

Housekeeping: occupied_rooms × checkout_stayover_mix × min_per_room / 60
F&B: expected_guests × meal_plan_pct × meals_per_time_slot
Front Desk: check-ins_per_hour / optimal_agent_load

Точные прогнозы occupancy позволяют оптимизировать затраты на персонал и закупки. Например, при прогнозе загрузки 80% housekeeping нужно 12 человек, при 50% — 8. Экономия на персонале может достигать от 200 000 до 500 000 руб. в месяц.

Procurement

Прогноз завтраков → закупка продуктов за 2–3 дня. Amenities — заказ еженедельно по прогнозу.

Maintenance scheduling

При прогнозируемой низкой загрузке → технические работы в номерах без потери revenue.

Почему сегментированный прогноз даёт больше прибыли?

Сегментированный прогноз позволяет применить dynamic pricing для каждого сегмента. Например, если leisure-сегмент показывает высокий pickup, можно поднять цены на стандартные номера. Leisure-сегмент часто бронирует ближе к дате и готов платить больше при высокой загрузке. Сегментированный подход позволяет поднимать цены на стандартные номера, не затрагивая corporate блоки. Наш опыт показывает рост RevPAR на 5–8% после внедрения сегментированного прогноза. Закажите разработку системы прогнозирования загрузки отеля, чтобы получить аналогичные результаты.

Как мы строим модель: пошаговый процесс

1. Анализ PMS-данных и выявление смещений.
2. Feature engineering: OTB, pickup, events, competition.
3. Обучение LightGBM с кросс-валидацией по времени.
4. A/B тест с текущим прогнозом на исторических данных.
5. Деплой модели на Kubernetes через MLflow.
6. Мониторинг точности и автоматический пересчёт при дрейфе данных.
7. Непрерывный мониторинг и ретренинг раз в неделю.

Объём работ и сроки

Входит:

• Анализ PMS-данных и выявление смещений
• Feature engineering: OTB, pickup, events, competition
• Обучение и валидация LightGBM/XGBoost
• Дашборд для revenue management
• Документация по модели и ETL
• Обучение сотрудников
• Поддержка 3 месяца после деплоя

Базовый occupancy forecast с LightGBM + OTB фичами — 4–5 недель. Сегментированная система с событийным календарём и операционным планированием — 3–4 месяца. Стоимость рассчитывается индивидуально после аудита данных. Свяжитесь с нами для предварительной оценки. Получите консультацию по пилотному проекту.

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

Финансовый директор запрашивает прогнозирование временных рядов продаж на квартал. Аналитик строит 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, а не только в ноутбуке.