Розробка AI-системи для екологічного моніторингу під ключ
Ми стикалися з ситуаціями, коли промислові підприємства не вкладалися в нормативи ГДК, а існуюча система моніторингу давала дані із запізненням на добу. Це не дозволяло оперативно реагувати на перевищення. AI-система екологічного моніторингу вирішує цю проблему: інтегрує дані стаціонарних постів, супутників та low-cost сенсорів у реальному часі, прогнозує забруднення на 72 години вперед і автоматично надсилає оповіщення при перевищенні порогів.
Ключовий принцип — зниження часу реакції з доби до 15 хвилин. Це досягається за рахунок комбінації IoT-мереж, предиктивних моделей та інтеграції з державними інформаційними системами (ФГІС «Промисловість», АІС «Промислова екологія»). Наш досвід: 5+ років в AI-моніторингу, понад 20 впроваджень на промислових підприємствах.
Чому AI-система екологічного моніторингу ефективніша за класичні пости?
Традиційні пости Росгідромету дають точні, але рідкісні заміри (раз на 20 хвилин або рідше). Ручний відбір проб додає затримку в години. AI-рішення об'єднує різнорідні джерела:
- Стаціонарні пости (висока точність, низька щільність)
- Low-cost сенсори (низька точність, висока щільність) — калібруються за референсними станціями
- Супутникові знімки (Sentinel-5P, MODIS) — глобальне покриття кожні 1-2 дні
Ми використовуємо гібридну архітектуру: дані сенсорів проходять калібрування через еталонні станції, потім просторову інтерполяцію (Kriging) і часове прогнозування (LSTM). Результат — карта забруднень з роздільною здатністю до 1 км і прогнозом на 3 доби.
Як ми будуємо інфраструктуру збору даних?
Інфраструктура включає три рівні: польові пристрої, агрегація на сервері, хмарна аналітика.
Low-cost сенсори — основа щільної мережі. Ми використовуємо Plantower PMS7003 та Sensirion SPS30 для PM2.5/PM10, Alphasense NO2-BE для NO2. Типова вартість вузла — $50-200, що в 100 разів дешевше професійної станції. Точність нижча, але при калібруванні за методом (див. код нижче) похибка знижується до 15-20%.
def calibrate_low_cost_sensor(low_cost_readings, reference_readings, method='linear'):
"""Калібрування LCS за найближчою референсною станцією"""
if method == 'linear':
model = LinearRegression().fit(low_cost_readings, reference_readings)
return model # застосовуємо до майбутніх LCS даних
elif method == 'rf':
model = RandomForestRegressor().fit(low_cost_readings, reference_readings)
return model
Супутникові дані (Sentinel-5P, Landsat, MODIS) використовуються для глобального покриття та детекції аномалій (пожежі, викиди).
Які предиктивні моделі використовуються?
Ми застосовуємо два підходи: детерміновані моделі розсіювання (Gaussian plume, AERMOD) та машинне навчання для часових рядів.
Прогноз якості повітря — LSTM з 24-годинними часовими рядами PM2.5 з усіх станцій регіону + метеопрогноз (NWP). Модель видає прогноз на 24/48/72 години для кожної точки сітки.
# LSTM + просторова інтерполяція
# State: 24-годинні часові ряди PM2.5 для всіх станцій в регіоні
# + NWP метеопрогноз (вітер, температура, змішування атмосфери)
# Вивід: PM2.5 на наступні 24/48/72 години для кожної сітки
model = StackedLSTM(
input_size=n_stations * n_pollutants + n_meteo_vars,
hidden_size=128,
forecast_hours=72
)
Моделі розсіювання забруднень (Gaussian plume) — при відомому джерелі викиду розраховують зону забруднення. Ми використовуємо AERMOD (регуляторна модель US EPA) та російський аналог ОНД-90. ML-поправки збільшують точність на 30% порівняно з чисто детермінованими моделями.
Детекція джерел — обернена задача: за розподілом концентрацій визначити координати джерела. Використовуємо оптимізацію та згорткові мережі (encoder зображення поля концентрацій → координати).
Система оповіщення та звітність
Індекси якості повітря: російський АКІ, WHO 2021 Guidelines, AQI США. Таблиця зіставлення:
| Індекс |
PM2.5 (мкг/м³) |
Рівень небезпеки |
Колір |
| АКІ |
<3 |
Низький |
Зелений |
| АКІ |
3-10 |
Помірний |
Жовтий |
| АКІ |
10-25 |
Високий |
Оранжевий |
| АКІ |
>25 |
Дуже високий |
Червоний |
Автоматичні оповіщення:
- Перевищення ГДК → SMS населенню + мобільний додаток
- Перевищення НДВ → повідомлення Росприроднагляд
- Аварійний скид → МНС + підприємство
Відповідність законодавству: 174-ФЗ, Постанова 205, Наказ Мінприроди 522. Інтеграція з ФГІС «Промисловість» та регіональними ГІС.
Що входить в роботу?
При замовленні AI-системи екологічного моніторингу ми надаємо:
- Обстеження території та підбір обладнання
- Розробку архітектури збору та зберігання даних
- Калібрування low-cost сенсорів та розгортання мережі
- Побудову предиктивних моделей (LSTM, Gaussian plume)
- Інтеграцію з державними системами звітності
- Дашборди та систему оповіщення
- Документацію, навчання персоналу, підтримка 1 місяць
Детальніше про компоненти системи
Система може включати додаткові модулі: мобільний додаток для населення, інтеграція з BIM-моделями підприємств, блок автоматичної подачі звітності в Росприроднагляд. Терміни та вартість залежать від складу модулів.
Терміни: базова система IoT-моніторингу + візуалізація + прогноз AQI — 8-10 тижнів. Повноцінна платформа з source attribution, regulatory reporting та оповіщенням — 5-6 місяців. Вартість розраховується індивідуально після аудиту об'єкта. Гарантуємо відповідність вимогам 174-ФЗ. Понад 7 років досвіду у створенні систем екологічного моніторингу.
Оцінимо ваш проект за 1 день — просто зв'яжіться з нами. Отримайте консультацію з впровадження AI-екологічного моніторингу.
Які проблеми прогнозування часових рядів зустрічаються найчастіше?
Фінансовий директор запитує прогнозування часових рядів продажів на квартал. Аналітик будує 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 для задач без коваріат.
| Метод |
Коваріати |
Масштаб (рядів) |
Інтерпретованість |
Складність |
| Prophet |
Так (регресори) |
До 10k |
Висока |
Низька |
| LightGBM + фічі |
Так |
100k+ |
Середня |
Середня |
| TFT |
Так |
1k–100k |
Висока |
Висока |
| PatchTST |
Ні/обмежено |
Будь-який |
Низька |
Середня |
| N-HiTS |
Ні |
Будь-який |
Низька |
Низька |
Як ми розгортаємо 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
-
Збір та підготовка даних. Обробити пропуски (маркувати NaN, інтерполювати лише якщо це технічний збій), агрегувати до потрібної частоти, сформувати коваріати (свята, промо, ціни).
-
Створення
TimeSeriesDataSet. Вказати group_ids (наприклад, магазин+SKU), часовий індекс, горизонт прогнозу. Налаштувати target_normalizer з урахуванням розподілу таргета.
-
Навчання baseline. Спочатку Prophet або LightGBM — щоб зрозуміти, наскільки складніше завдання.
-
Тренування TFT. Запустити
TemporalFusionTransformer з loss=QuantileLoss(), підібрати learning rate та розміри hidden шарів. Використовувати pytorch_forecasting або neuralforecast.
-
Валідація та інтерпретація. Перевірити 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 впливає сильніше, ніж сама дата свята. Середня економія бюджету на інференсі для клієнта склала значну суму.
Як правильно оцінювати якість прогнозів?
Не використовуйте RMSE як єдину метрику — вона сильно штрафує за великі помилки на великих значеннях. Наш набір метрик для рітейл-прогнозування:
-
MAPE — інтерпретована, але нестабільна при значеннях близьких до нуля
-
sMAPE — симетрична версія, уникає ділення на маленькі числа
-
MASE (Mean Absolute Scaled Error) — нормалізована відносно наївного сезонного прогнозу, чудово підходить для порівняння між рядами з різними масштабами
-
Quantile loss / Pinball loss — для ймовірнісного прогнозування, оцінка покриття інтервалів
| Метрика |
Коли використовувати |
Недолік |
| MAPE |
Бізнес-звітність, ряд без нулів |
Нестабільна при малих значеннях |
| sMAPE |
Порівняння моделей, нульові значення |
Асиметрична інтерпретація |
| MASE |
Різномаштабні ряди, бенчмарки |
Вимагає сезонного наївного прогнозу |
| Pinball loss |
Ймовірнісні моделі, управління запасами |
Багато метрик для різних квантилів |
Гарантуємо: ми надаємо model card з цими метриками на валідаційній вибірці та результати walk-forward тесту на історії не менше 6 місяців.
Що входить в роботу
- Документація щодо обраної архітектури, обґрунтування вибору гіперпараметрів.
- Відтворюваний пайплайн навчання та інференсу (Docker + CI/CD + Airflow/Prefect).
- Код з коментарями та модульними тестами на ключові компоненти.
- Навчання вашої команди: як перенавчати модель, як інтерпретувати виходи, як деплоїти нові версії.
- Підтримка протягом 3 місяців після здачі: консультації, виправлення багів, доналаштування.
Деталі пайплайну інференсу
Модель деплоїться через FastAPI або Triton Inference Server. Перенавчання запускається за розкладом (наприклад, раз на тиждень) через Airflow — з валідацією drift та автоматичним відкатом при погіршенні метрик.
Процес роботи
Починаємо з 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, а не тільки в ноутбуці.