Чому розробка AI-системи моніторингу повітря впирається в дані
Класичний збій на старті — втрата калібрування постів. Електрохімічний сенсор за кілька місяців відходить від заводського налаштування, показання зміщуються, але ряд залишається гладким: ні стрибків, ні обривів, які помітив би оператор.
Модель, навчена на такій шкалі, відтворює зміщення як норму — і «тихий» район виглядає бруднішим за сусідній без жодних підстав.
Друге джерело помилок — пропуски в телеметрії. Сіла батарея, перезапуск шлюзу, обрив каналу — і в ряду з'являються дірки, які під час підготовки даних закривають інтерполяцією.
Модель перестає розрізняти «даних немає» і «повітря чисте», а на виході отримуємо хибні спрацювання або, що гірше, пропущений епізод забруднення.
Далі — розсинхронізація постів і розрізнені джерела. Локальні датчики, міські станції та метеозведення надходять з різним інтервалом опитування й різними мітками часу, частина — із затримкою.
Поки все це не приведено до спільної часової осі та просторової прив'язки, порівняння постів між собою й перенесення закономірностей з одного на інший не дають нічого.
Шум і дрейф датчиків, пропуски, розсинхронізація — три різні поломки, і лікуються вони по-різному: перехресною звіркою постів, окремим статусом «немає даних» замість інтерполяції, єдиною сіткою часу.
Саме тому розробка AI-системи моніторингу повітря починається не з вибору моделі, а з контуру підготовки даних — розбираємо, як це закривається.
Що дає предиктивний моніторинг якості повітря
Порогова сигналізація спрацьовує, коли датчик уже набрав концентрацію: фіксуємо пік, а не запобігаємо йому.
Предиктивна модель працює на спільній поведінці постів, метеорядів і календаря міських подій — реагує на нахил кривої та перенесення забруднення із сусідніх районів, а не на одиничний стрибок значення.
Частка хибних спрацювань падає з 30–40%, типових для жорстких порогів, до одиниць відсотків за того самого рівня виявлення реальних перевищень.
Час до виявлення перевищення скорочується з десятків хвилин до 2–5: сигнал надходить до виходу концентрації на максимум, і в відповідального залишається запас на дію.
Горизонт прогнозу — від кількох годин до доби, з очікуваним зростанням помилки до кінця вікна. Цього достатньо, щоб призупинити роботи на майданчику, змінити маршрути поливу й прибирання або попередити школи, не чекаючи підтвердження за вимірюваннями.
Повнота даних після очищення — передумова, а не косметика: зв'язок із постами зникає, датчики дрейфують між калібруваннями, частина значень — викиди від локальних джерел.
Конвеєр перевірки та відновлення рядів піднімає частку точок, придатних для навчання й розрахунку, з 70–80% до понад 95%; без нього модель навчається на шумі й втрачає точність саме на різких епізодах.
Окремо закривається клас відмов, який у порогових схемах не лікується: хибна тривога знижує довіру оператора, повідомлення вимикають — і справжнє перевищення проходить непоміченим.
Поведінку моделі звіряємо з незалежними вимірюваннями, включно з відкритими міськими архівами OpenAQ та даними референсних постів, щоб метрики залишалися перевірюваними, а не декларативними.
Способи збору та калібрування даних: порівняння підходів
Стелю точності всієї системи задає не модель, а вхідні дані: невідкалібрований датчик іде в дрейф за лічені тижні, а крос-чутливість до вологості й окисників дає хибні піки там, де фон чистий. Нижче — реальні варіанти збору, між якими обирають на старті, та їхні межі.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Стаціонарні пости | Міський фон, контроль санітарних зон, довгі ряди спостережень | Вартість майданчика й живлення обмежує щільність мережі; покриття точкове |
| Мобільні сенсори | Картування вулиць, пошук локальних джерел, разові викиди | Потрібна прив'язка до геолокації та поправка на швидкість руху; дрейф швидший |
| Супутникові знімки | Великі території, перенесення шлейфів, багаторічні тренди | Великий крок сітки, залежність від хмарності, лише інтегральна концентрація по стовпу |
| Гібридна схема | Місто цілком: фон, деталізація за районами та взаємна перевірка | Складніша зшивка різнорідних рядів і побудова моделі корекції |
Гібридна схема працює лише за наявності опорних станцій порівняння: за ними будується корекція показань дешевих сенсорів, а сама модель калібрування перенавчається за сезоном і після заміни датчиків.
Критерій приймання тут — частка валідних вимірювань і відтворюваність добового профілю, а не кількість точок на карті.
Етапи впровадження: від аудиту даних до дослідної експлуатації
Дослідна експлуатація — не разовий запуск моделі, а послідовність робіт, де кожен етап залишає перевірюваний артефакт: реєстр джерел, схему потоків, конфігурацію моделей, протокол перевірки.
Порядок важливий: модель, навчена на невивчених джерелах, акуратно відтворює помилки датчиків і видає правдоподібний, але неправильний прогноз.
- Аудит джерел даних. Інвентаризуємо пости моніторингу та зовнішні фіди, дивимося частоту надходження, пропуски, дрейф калібрування, дублі й розбіжності одиниць вимірювання. Результат — таблиця придатності джерел: що йде в модель, що потребує повірки, а що виключаємо.
- Схема потоків даних. Описуємо шлях від датчика до сховища й вітрин: буферизація під час обриву зв'язку, мітки часу, перерахунок одиниць, повторна обробка «пізніх» записів. Схема узгоджується до налаштування моделей — інакше ознаки рахуються по-різному на навчанні та в роботі.
- Підготовка ознак і налаштування моделей. Збираємо історичні ряди, синхронізуємо метеодані та календар, чистимо викиди. Окремо налаштовуємо модель прогнозу концентрацій і модель виявлення аномалій — у них різні вимоги до чутливості та різна ціна хибного спрацювання.
- Перевірка на історичних даних. Проганяємо моделі на відкладеному періоді, включно з епізодами з пожежами, інверсією та збоями обладнання. Порівнюємо з референсними вимірюваннями й дивимося не середню помилку, а поведінку на піках — саме там рішення приносить користь.
- Дослідна експлуатація. Запускаємо паралельно з поточним контуром спостережень, звіряємо оповіщення з фактичними подіями, налаштовуємо пороги, щоб повідомлення не перетворювалися на шум.
- Передача та навчання команди. Віддаємо документацію, регламент перенавчання, порядок додавання нових постів і розбір типових відмов. Інженери замовника проводять типове оновлення моделі самостійно.
Кожен етап закінчується короткою демонстрацією, тому розбіжності в даних і очікуваннях спливають на початку робіт, а не на запуску.
Що залишається у вас після здачі системи: артефакти та регламенти
Працююча система — це не лише сервіс, який відповідає на запити. Разом із нею ви отримуєте комплект, за яким ваша команда зможе експлуатувати, донавчати й розвивати її без нас: від схеми потоків даних до регламентів, що визначають, хто і коли має право змінювати налаштування.
- Схема архітектури: шлях вимірювання від датчика до вітрин і звітів, межі сервісів, точки відмови та режими деградації — новий інженер розбирається за документом, а не за листуванням.
- Конфігурації конвеєра обробки: правила очищення, агрегації та перерахунку, пороги тривог, розклади — винесені з коду, тому правляться без випуску нової версії.
- Політики доступу до даних: ролі, розмежування за майданчиками й типами вимірювань, журналювання звернень, порядок надання та відкликання прав.
- Регламент калібрування: періодичність звірки з еталоном, фіксація дрейфу, допуски й дії в разі виходу за них, відповідальний за підпис.
- Інструкції з експлуатації: типові сценарії, діагностика пропусків у потоці, поведінка при деградації показань, порядок ескалації.
- Набори для перевірки якості та еталонні метрики: за ними приймається кожне перенавчання — модель не йде в роботу, якщо просіла на контрольній вибірці.
- Журнал інженерних рішень: чому вибрано саме такі пороги й фільтри — під час розбору інциденту логіка відновлюється за записом, а не за пам'яттю.
Комплект влаштований так, щоб система залишалася керованою без нас: правки конвеєра не потребують випуску версії, калібрування йде за регламентом, доступи — за політикою.
Кейс: міська мережа постів — від хибних тривог до прогнозу
Мережа міських постів збиралася зі станцій різних постачальників: частина віддавала вимірювання раз на годину, частина — раз на п'ять хвилин, в окремих постів траплялися добові провали зв'язку.
Диспетчер бачив потік, у якому значення не можна було порівняти напряму, а порогові правила спрацьовували на будь-якій аномалії датчика.
Зшивку різнорідних постів ми почали з приведення всіх вимірювань до єдиної схеми: спільний набір показників, єдина шкала часу та явна ознака якості для кожного запису.
Валідацію звіряли з відкритим архівом OpenAQ — так реальні епізоди забруднення відокремлювалися від збоїв обладнання.
Що змінилося в мережі
| Метрика | До | Після |
|---|---|---|
| Хибні спрацювання | більше половини тривог — збої датчиків | одиничні, підтверджені сусідніми постами |
| Повнота даних | ряди з пропусками, частина станцій поза аналізом | до аналізу придатні практично всі пости |
| Час відгуку | години від сплеску до сигналу | хвилини |
| Прогноз перевищень | був відсутній | попередження за кілька годин до епізоду |
Прогноз перевищень спирається на зв'язку сусідніх постів і метеопараметри: якщо зростання фіксують дві-три станції в одній зоні, система видає попередження заздалегідь. Чергова зміна встигає оповістити відповідальних і виїхати на джерело замість розбору епізоду постфактум.
Визначальною виявилася не заміна обладнання, а зшивка: крос-перевірка постів дає більше, ніж окремий точний датчик. Контур масштабується на нові станції без перенавчання з нуля — новий пост включається в загальну логіку перевірок.
Що робити, якщо мережа датчиків уже розгорнута, а дані брудні?
Мережа вже стоїть і працює, дані йдуть у звіти, на них зав'язані рішення — зупиняти збір заради «переробити все правильно» ніхто не погодиться. При цьому в частини постів поїхало калібрування, десь пропуски за годинами, у різних виробників свої формати часу й одиниці.
Тому перший крок — підписатися на мережу в режимі читання, не змінюючи працюючий контур. Поруч з'являється другий шар обробки: сирі значення пишуться як і раніше, а поверх іде перевірка на пропуски, викиди, завислі показання й дрейф щодо сусідніх постів.
Експлуатація не зупиняється ні на годину, кожне виправлення фіксується в журналі із зазначенням правила.
Ретроспективне очищення архіву йде за тими самими правилами, що й потік. Проганяємо історію через ті самі перевірки й отримуємо єдину шкалу: записи за минулий період і нові дані рахуються однаково та перестають сперечатися одне з одним.
Вихідні значення зберігаються поруч, тому під час розбору видно, що прийшло з датчика, а що підставили.
Зшивка різнорідних даних — найкопіткіша частина. Пости опитуються з різною частотою, мітки часу надходять у різних поясах, у газоаналізаторів і пиломірів непорівнювані одиниці.
Приводимо все до спільного часу й шкали, прив'язуємо до метеопараметрів і еталонної перевірки — так одиничний пік можна відрізнити від реальної події, а не гадати, збій це чи викид.
Поступове підключення знижує ризик. Починаємо з одного поста або типу датчиків: дивимося частку відбракованих значень і розходження з контрольними вимірюваннями, лише потім розширюємо на наступну групу.
У підсумку замовник отримує чистий архів заднім числом і передбачувані дані наперед, не виводячи з ладу жоден вузол і не зупиняючи моніторинг.
Часті сумніви інженерів: відповідаємо на технічні питання
Нижче — питання, які найчастіше ставлять інженери експлуатації та служби якості, коли рішення переходить з дослідної експлуатації в постійну. За кожним пунктом є робоча процедура, а не обіцянка: її можна перевірити на ваших даних до запуску.
Чи вистачить історичних даних, якщо пости спостереження стоять недавно?
Ряд коротший за повний сезон не дає моделі побачити річну динаміку.
У цьому разі навчання йде на відкритих архівах сусідніх територій із перенесенням на ваші дані, а метеопараметри — напрямок і швидкість вітру, вологість, температура — працюють як ознаки, що пов'язують чужий ряд із вашим.
Перші місяці система йде в режимі радника: вона позначає події, але рішення залишається за оператором. Щойно набирається власний безперервний ряд, модель перенавчають на ньому й перемикають у робочий режим.
Чим викид відрізняється від перевищення — чи не буде хибних тривог?
Це два різні класи подій, і поріг у них різний.
Викид — одиничний стрибок, його ловлять порівнянням із медіаною ковзного вікна та крос-перевіркою за сусідніми постами: одночасне зростання на кількох точках говорить про реальне перенесення, одиничний пік — про перешкоду або збій датчика.
Перевищення — стійкий рівень вище норми протягом вікна усереднення, заданого регламентом. Повідомлення, журнали й звітність за ними роздільні, тому шум датчика не потрапляє в офіційні зведення.
Що відбувається, якщо пост перестає виходити на зв'язок?
Пости віддають телеметрію через MQTT, і ми стежимо не лише за корисними показаннями, а й за службовими: напруга живлення, струм, витрата повітря через вимірювальну камеру.
Пропуск у ряду, завмерлий рівень або зростання шуму переводять пост у статус недостовірного — він позначається на карті, а не мовчки спотворює картину. Оцінку за ділянкою модель будує за сусідніми постами з поправкою на метеоперенесення і чесно показує зону, де даних не вистачає.
Де зберігаються дані та хто має до них доступ?
Сирі ряди, результати розмітки й версії моделей живуть у вашому контурі, назовні йде лише знеособлене зведення, якщо воно потрібне для публікації.
Доступ розмежовано за ролями — оператор, аналітик, адміністратор бачать різне, дії пишуться в журнал, відкликати доступ можна без зупинки системи. Вивантаження архіву для перевірних органів збирається окремим звітом за заданий період.
Як часто доводиться перенавчати модель?
Планово — за сезоном: змінюються джерела, режими опалення, напрямок переважальних вітрів. Достроково — за дрейфом: якщо якість на контрольній вибірці тримається нижче узгодженого порогу кілька днів підряд, навчання запускається автоматично.
Версія моделі фіксується, рішення можна відкотити до попередньої, а порівняння двох версій на одному відрізку історії показує, що саме змінилося.
Обговоримо задачу: що надіслати, щоб отримати оцінку та план
Щоб повернутися з оцінкою строків і планом, нам не потрібен готовий технічний проєкт — достатньо вихідних даних і відповідей на кілька запитань.
Вартість і складність системи моніторингу повітря визначає не розмір території, а щільність постів, якість накопиченої телеметрії та те, які рішення щодо забруднення ухвалюються сьогодні.
- Склад постів. Скільки точок, де вони стоять, які датчики на борту (пил, діоксид азоту, озон, оксид вуглецю), на якій висоті забирається повітря і чим забезпечені живлення та зв'язок на майданчику.
- Вивантаження телеметрії. Файл або доступ до сховища за кілька місяців: мітки часу з часовим поясом, одиниці вимірювання, позначки про калібрування та простої. За цими даними ми оцінюємо, чи вистачає історії для навчання.
- Перелік завдань моніторингу. Що система має робити: сигналити про перевищення, будувати карту забруднення по місту, розбирати ймовірне джерело чи рахувати прогноз.
- Вимоги до прогнозу. Горизонт і крок прогнозу, допустима помилка на горизонті, за якими постами й речовинами рахуємо — від цього залежить і модель, і обсяг робіт.
- Опорні вимірювання. Дані референсної станції або лабораторних замірів — за ними налаштовується поправка на вологість і температуру, інакше дешеві датчики дають зміщення.
- Порядок погодження етапів. Хто приймає результат, чи потрібна інтеграція з диспетчерською або екологами, чи готові ви до дослідної експлуатації на частині постів перед масштабуванням на всю мережу.
Із цього набору збирається план: підготовка даних, навчання та перевірка моделі, сигнали оператору, регламент звірки з референсними замірами. Опишіть задачу й надішліть те, що вже є, — повернемося з оцінкою строків і складом етапів.
