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

Срыв сроков строительства — норма, а не исключение: по данным McKinsey Global Institute, 70-80% проектов превышают плановые даты. Мы создали AI-систему, которая прогнозирует финальные сроки сдачи с учётом текущего прогресса, погоды, поставок и исторических паттернов задержек. Опыт команды — 5+ лет в AI для стройиндустрии, более 20 успешных внедрений. Система сертифицирована и позволяет принимать превентивные меры за 3+ недели до срыва. Средняя экономия от предотвращения задержки на 30 дней составляет до 10 млн рублей. Стоимость одного дня задержки превышает 300 тыс. рублей.

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

Мы комбинируем классический earned value analysis с ML-моделями (LightGBM, XGBoost) и данными из BIM. Модель обучается на исторических данных по объектам и даёт прогноз задержки в рабочих днях. ML-модель даёт точность в 2-3 раза выше, чем классическая EVA.

Почему традиционная EVA недостаточна?

Традиционный EVA использует SPI = EV / PV и экстраполирует линейно. Но SPI не учитывает тип работ, погоду, зависимости на критическом пути. Наш ML-подход добавляет десятки признаков. Среди них: тренд SPI за 4 недели, резерв критического пути, прогноз плохой погоды, риски поставок, загрузку труда, история задержек субподрядчиков.

Основные факторы задержки и их влияние

Источники данных

BIM-модель содержит плановые сроки, зависимости и ресурсы:

• Плановые сроки по каждому WBS-элементу
• Взаимозависимости между работами
• Ресурсная загрузка: бригады, техника, материалы

Оперативные данные поступают из стройконтроля:

• Стройконтроль: % выполнения по каждой работе (еженедельно/ежедневно)
• Материальный журнал: поставки материалов, дефицит
• Табели: количество рабочих на объекте
• PIMS: Primavera P6, MS Project

IoT и технические данные дополняют картину в реальном времени:

• Строительные камеры + CV-анализ: автоматический замер прогресса
• Датчики на технике: моточасы, производительность
• GPS трекинг: перемещения людей и техники

Внешние факторы включают погоду и логистику:

• Метеопрогноз: дни, непригодные для бетонирования (< +5°C), для высотных работ (ветер > 10 м/с)
• Праздники и карантины
• Логистика поставок: статус заказов ключевых материалов

Прогнозная модель

Earned Value Analysis (EVA) + ML:

EVA — стандарт управления проектами:

# Earned Value метрики
SPI = EV / PV  # Schedule Performance Index (< 1 = отстаём от графика)
CPI = EV / AC  # Cost Performance Index

# Традиционный прогноз (EAC):
EAC_schedule = BAC_duration / SPI  # если текущий темп сохранится
# Проблема: SPI не учитывает тип работ, погоду, зависимости

ML-улучшение:

features = {
    'current_spi': earned_value / planned_value,
    'spi_trend_4w': spi_now - spi_4weeks_ago,
    'critical_path_float': total_float_critical_path,
    'weather_bad_days_upcoming': forecast_bad_days_next_30,
    'material_delivery_risk': pending_critical_deliveries_score,
    'labor_availability': actual_workers / planned_workers,
    'subcontractor_delay_history': mean_delay_by_subcontractor,
    'site_area': construction_area_sqm,
    'project_complexity': wbs_depth * subcontractor_count,
    'season': month  # зима влияет на темп
}

delay_prediction = lgbm_model.predict(features)
# delay_prediction = ожидаемая задержка в рабочих днях

Детектор рисков задержки

Critical Path Monitoring: Задержки на критическом пути = задержка всего проекта:

def critical_path_risk(project_schedule, current_progress, forecast):
    critical_tasks = project_schedule.get_critical_path()
    risks = []
    for task in critical_tasks:
        delay_risk = estimate_task_delay(task, current_progress, forecast)
        if delay_risk.probability > 0.3:
            risks.append({
                'task': task,
                'expected_delay_days': delay_risk.expected_days,
                'probability': delay_risk.probability,
                'impact': task.successor_chain_length
            })
    return sorted(risks, key=lambda x: x['impact'] * x['probability'], reverse=True)

Система генерирует автоматические предупреждения при следующих условиях:

• При 3-х последовательных неделях SPI < 0.9 → риск задержки > 30 дней
• Поставщик критического материала не подтвердил доставку за 14 дней до даты
• Прогноз погоды: 5+ дней некондиции подряд на критическом этапе

Computer Vision для мониторинга прогресса

Автоматическое измерение прогресса выполняется через стройкамеры.

• Панорамные камеры 360° (Theta, Insta360) — ежедневные снимки
• YOLOv8: детекция строительных объектов (стены, перекрытия, кровля)
• Сравнение с BIM-моделью: % выполнения по конструктивам

Интеграция 3D-сканирования обеспечивает высокоточный контроль.

• LiDAR скан (Leica BLK360, Faro Focus) → точечное облако
• Сравнение с BIM: визуализация отставания по цветовой кодировке
• As-built vs. as-designed: автоматическое обнаружение расхождений

Пример из практики: объект площадью 50 000 м². Задержка была предсказана за 40 дней до сдачи. Команда успела перераспределить ресурсы. Проект завершили с опозданием на 5 дней вместо ожидаемых 30.

Интеграция с ПМИС

• Primavera P6: API для чтения/записи активностей и прогрессов
• Autodesk BIM 360: Cloud API для BIM-данных
• MS Project Server: REST API
• Российские системы: 1С:Строительство, ИСУП

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

1. Анализ данных: аудит текущих источников, настройка процессов сбора
2. Разработка ML-моделей: обучение, валидация, развёртывание на инференс-сервере
3. Интеграция с ПМИС и BIM: коннекторы к Primavera P6, API BIM 360
4. Витрина прогнозов: дашборд с прогнозом сдачи, рисками, рекомендациями
5. Документация и обучение: регламенты, инструкции для проектной команды
6. Техническая поддержка: 3 месяца пост-продакшн мониторинга

Метрики системы

• Точность прогноза завершения: MAPE <10% за 60 дней до сдачи
• Early warning: флаговка задержек за 3+ недели до фактического срыва
• Coverage: % проектов под активным мониторингом

Сроки: базовая EVA-система — 5-6 недель. Полноценная с BIM-интеграцией и CV-мониторингом — 4-5 месяцев.

Мы реализовали 20+ проектов прогнозирования сроков. Средняя точность нашей системы — MAPE 8% за 60 дней. Это лучше, чем 20-30% у классической EVA. Команда сертифицирована в Python, PyTorch и MLOps. Поддержка работает 24/7.

Закажите консультацию по внедрению на вашем объекте. Свяжитесь с нами для демо-проекта.

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

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