Разработка AI-системы мониторинга качества воздуха

Почему разработка AI-системы мониторинга воздуха упирается в данные

Классический сбой на старте — потеря калибровки постов. Электрохимический сенсор за несколько месяцев уходит от заводской настройки, показания смещаются, но ряд остаётся гладким: ни скачков, ни обрывов, которые заметил бы оператор. Модель, обученная на такой шкале, воспроизводит смещение как норму — и «тихий» район выглядит грязнее соседнего без всяких оснований.

Второй источник ошибок — пропуски в телеметрии. Севшая батарея, перезапуск шлюза, обрыв канала — и в ряду появляются дыры, которые при подготовке данных закрывают интерполяцией. Модель перестаёт различать «данных нет» и «воздух чистый», а на выходе получаем ложные срабатывания или, что хуже, пропущенный эпизод загрязнения.

Дальше — рассинхрон постов и разрозненные источники. Локальные датчики, городские станции и метеосводки приходят с разным интервалом опроса и разными метками времени, часть — с запаздыванием. Пока всё это не приведено к общей временной оси и пространственной привязке, сравнение постов между собой и перенос закономерностей с одного на другой не дают ничего.

Шум и дрейф датчиков, пропуски, рассинхрон — три разные поломки, и лечатся они по-разному: перекрёстной сверкой постов, отдельным статусом «нет данных» вместо интерполяции, единой сеткой времени. Именно поэтому разработка AI-системы мониторинга воздуха начинается не с выбора модели, а с контура подготовки данных — разбираем, как это закрывается.

Что даёт предиктивный мониторинг качества воздуха

Пороговая сигнализация срабатывает, когда датчик уже набрал концентрацию: фиксируем пик, а не предотвращаем его. Предиктивная модель работает на совместном поведении постов, метеорядов и календаря городских событий — реагирует на наклон кривой и перенос загрязнения с соседних районов, а не на одиночный скачок значения.

Доля ложных срабатываний падает с 30–40%, типичных для жёстких порогов, до единиц процентов при том же уровне обнаружения реальных превышений. Время до обнаружения превышения сокращается с десятков минут до 2–5: сигнал приходит до выхода концентрации на максимум, и у ответственного остаётся запас на действие.

Горизонт прогноза — от нескольких часов до суток, с ожидаемым ростом ошибки к концу окна. Этого достаточно, чтобы приостановить работы на площадке, изменить маршруты полива и уборки или предупредить школы, не дожидаясь подтверждения по измерениям.

Полнота данных после очистки — предпосылка, а не косметика: связь с постами пропадает, датчики дрейфуют между калибровками, часть значений — выбросы от локальных источников. Конвейер проверки и восстановления рядов поднимает долю точек, пригодных для обучения и расчёта, с 70–80% до более 95%; без него модель учится на шуме и теряет точность именно на резких эпизодах.

Отдельно закрывается класс отказов, который в пороговых схемах не лечится: ложная тревога снижает доверие оператора, уведомления отключают — и настоящее превышение проходит незамеченным. Поведение модели сверяем с независимыми измерениями, включая открытые городские архивы OpenAQ и данные референсных постов, чтобы метрики оставались проверяемыми, а не декларативными.

Способы сбора и калибровки данных: сравнение подходов

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

Гибридная схема работает только при наличии опорных станций сравнения: по ним строится коррекция показаний дешёвых сенсоров, а сама модель калибровки переобучается по сезону и после замены датчиков. Критерий приёмки здесь — доля валидных измерений и воспроизводимость суточного профиля, а не количество точек на карте.

Этапы внедрения: от аудита данных до опытной эксплуатации

Опытная эксплуатация — не разовый запуск модели, а последовательность работ, где каждый этап оставляет проверяемый артефакт: реестр источников, схему потоков, конфигурацию моделей, протокол проверки. Порядок важен: модель, обученная на неизученных источниках, аккуратно воспроизводит ошибки датчиков и выдаёт правдоподобный, но неверный прогноз.

1. Аудит источников данных. Инвентаризуем посты мониторинга и внешние фиды, смотрим частоту поступления, пропуски, дрейф калибровки, дубли и расхождения единиц измерения. Результат — таблица пригодности источников: что идёт в модель, что требует поверки, а что исключаем.
2. Схема потоков данных. Описываем путь от датчика до хранилища и витрин: буферизация при обрыве связи, метки времени, пересчёт единиц, повторная обработка «поздних» записей. Схема согласуется до настройки моделей — иначе признаки считаются по-разному на обучении и в работе.
3. Подготовка признаков и настройка моделей. Собираем исторические ряды, синхронизируем метеоданные и календарь, чистим выбросы. Отдельно настраиваем модель прогноза концентраций и модель обнаружения аномалий — у них разные требования к чувствительности и разная цена ложного срабатывания.
4. Проверка на исторических данных. Прогоняем модели на отложенном периоде, включая эпизоды с пожарами, инверсией и сбоями оборудования. Сравниваем с референсными измерениями и смотрим не среднюю ошибку, а поведение на пиках — именно там решение приносит пользу.
5. Опытная эксплуатация. Запускаем параллельно с текущим контуром наблюдений, сверяем оповещения с фактическими событиями, настраиваем пороги, чтобы уведомления не превращались в шум.
6. Передача и обучение команды. Отдаём документацию, регламент переобучения, порядок добавления новых постов и разбор типовых отказов. Инженеры заказчика проводят типовое обновление модели самостоятельно.

Каждый этап заканчивается короткой демонстрацией, поэтому расхождения в данных и ожиданиях всплывают в начале работ, а не на запуске.

Что остаётся у вас после сдачи системы: артефакты и регламенты

Работающая система — это не только сервис, который отвечает на запросы. Вместе с ней вы получаете комплект, по которому ваша команда сможет эксплуатировать, дообучать и развивать её без нас: от схемы потоков данных до регламентов, определяющих, кто и когда вправе менять настройки.

• Схема архитектуры: путь измерения от датчика до витрин и отчётов, границы сервисов, точки отказа и режимы деградации — новый инженер разбирается по документу, а не по переписке.
• Конфигурации конвейера обработки: правила очистки, агрегации и пересчёта, пороги тревог, расписания — вынесены из кода, поэтому правятся без выпуска новой версии.
• Политики доступа к данным: роли, разграничение по площадкам и типам измерений, журналирование обращений, порядок выдачи и отзыва прав.
• Регламент калибровки: периодичность сверки с эталоном, фиксация дрейфа, допуски и действия при выходе за них, ответственный за подпись.
• Инструкции по эксплуатации: типовые сценарии, диагностика пропусков в потоке, поведение при деградации показаний, порядок эскалации.
• Наборы для проверки качества и эталонные метрики: по ним принимается каждое переобучение — модель не уходит в работу, если просела на контрольной выборке.
• Журнал инженерных решений: почему выбраны именно такие пороги и фильтры — при разборе инцидента логика восстанавливается по записи, а не по памяти.

Комплект устроен так, чтобы система оставалась управляемой без нас: правки конвейера не требуют выпуска версии, калибровка идёт по регламенту, доступы — по политике.

Кейс: городская сеть постов — от ложных тревог к прогнозу

Сеть городских постов собиралась из станций разных поставщиков: часть отдавала измерения раз в час, часть — раз в пять минут, у отдельных постов случались суточные провалы связи. Диспетчер видел поток, в котором значения нельзя было сравнить напрямую, а пороговые правила срабатывали на любой аномалии датчика.

Сшивку разнородных постов мы начали с приведения всех измерений к единой схеме: общий набор показателей, единая шкала времени и явный признак качества для каждой записи. Валидацию сверяли с открытым архивом OpenAQ — так реальные эпизоды загрязнения отделялись от сбоев оборудования.

Что изменилось на сети

Прогноз превышений опирается на связку соседних постов и метеопараметры: если рост фиксируют две-три станции в одной зоне, система выдаёт предупреждение заранее. Дежурная смена успевает оповестить ответственных и выехать на источник вместо разбора эпизода постфактум.

Определяющей оказалась не замена оборудования, а сшивка: кросс-проверка постов даёт больше, чем отдельный точный датчик. Контур масштабируется на новые станции без переобучения с нуля — новый пост включается в общую логику проверок.

Что делать, если сеть датчиков уже развёрнута, а данные грязные?

Сеть уже стоит и работает, данные идут в отчёты, на них завязаны решения — останавливать сбор ради «переделать всё правильно» никто не согласится. При этом у части постов уехала калибровка, где-то пропуски по часам, у разных производителей свои форматы времени и единицы.

Поэтому первый шаг — подписаться на сеть в режиме чтения, не меняя работающий контур. Рядом появляется второй слой обработки: сырые значения пишутся как прежде, а поверх идёт проверка на пропуски, выбросы, зависшие показания и дрейф относительно соседних постов. Эксплуатация не встаёт ни на час, каждое исправление фиксируется в журнале с указанием правила.

Ретроспективная очистка архива идёт по тем же правилам, что и поток. Прогоняем историю через те же проверки и получаем единую шкалу: записи за прошлый период и новые данные считаются одинаково и перестают спорить друг с другом. Исходные значения сохраняются рядом, поэтому при разборе видно, что пришло с датчика, а что подставили.

Сшивка разнородных данных — самая кропотливая часть. Посты опрашиваются с разной частотой, метки времени приходят в разных поясах, у газоанализаторов и пылемеров несопоставимые единицы. Приводим всё к общему времени и шкале, привязываем к метеопараметрам и эталонной проверке — так одиночный пик можно отличить от реального события, а не гадать, сбой это или выброс.

Постепенное подключение снижает риск. Начинаем с одного поста или типа датчиков: смотрим долю отбракованных значений и расхождение с контрольными измерениями, только потом расширяем на следующую группу. В итоге заказчик получает чистый архив задним числом и предсказуемые данные вперёд, не выводя из строя ни один узел и не останавливая мониторинг.

Частые сомнения инженеров: отвечаем на технические вопросы

Ниже — вопросы, которые чаще всего задают инженеры эксплуатации и службы качества, когда решение переходит из опытной эксплуатации в постоянную. По каждому пункту есть рабочая процедура, а не обещание: её можно проверить на ваших данных до запуска.

Чем выброс отличается от превышения — не будет ли ложных тревог?

Это два разных класса событий, и порог у них разный. Выброс — одиночный скачок, его ловят сравнением с медианой скользящего окна и кросс-проверкой по соседним постам: одновременный рост на нескольких точках говорит о реальном переносе, одиночный пик — о помехе или сбое датчика. Превышение — устойчивый уровень выше нормы в течение окна осреднения, заданного регламентом. Уведомления, журналы и отчётность по ним раздельные, поэтому шум датчика не уходит в официальные сводки.

Что происходит, если пост перестаёт выходить на связь?

Посты отдают телеметрию по MQTT, и мы следим не только за полезными показаниями, но и за служебными: напряжение питания, ток, расход воздуха через измерительную камеру. Пропуск в ряду, замерший уровень или рост шума переводят пост в статус недостоверного — он помечается на карте, а не молча искажает картину. Оценку по участку модель строит по соседним постам с поправкой на метеоснос и честно показывает зону, где данных не хватает.

Где хранятся данные и кто имеет к ним доступ?

Сырые ряды, результаты разметки и версии моделей живут в вашем контуре, наружу уходит только обезличенная сводка, если она нужна для публикации. Доступ разграничен по ролям — оператор, аналитик, администратор видят разное, действия пишутся в журнал, отозвать доступ можно без остановки системы. Выгрузка архива для проверяющих органов собирается отдельным отчётом по заданному периоду.

Как часто приходится переобучать модель?

Планово — по сезону: меняются источники, режимы отопления, направление преобладающих ветров. Досрочно — по дрейфу: если качество на контрольной выборке держится ниже согласованного порога несколько дней подряд, обучение запускается автоматически. Версия модели фиксируется, решение можно откатить к предыдущей, а сравнение двух версий на одном отрезке истории показывает, что именно изменилось.

Обсудим задачу: что прислать, чтобы получить оценку и план

Чтобы вернуться с оценкой сроков и планом, нам не нужен готовый технический проект — достаточно исходных данных и ответов на несколько вопросов. Стоимость и сложность системы мониторинга воздуха определяет не размер территории, а плотность постов, качество накопленной телеметрии и то, какие решения по загрязнению принимаются сегодня.

• Состав постов. Сколько точек, где они стоят, какие датчики на борту (пыль, диоксид азота, озон, оксид углерода), на какой высоте забирается воздух и чем обеспечены питание и связь на площадке.
• Выгрузка телеметрии. Файл или доступ к хранилищу за несколько месяцев: метки времени с часовым поясом, единицы измерения, пометки о калибровках и простоях. По этим данным мы оцениваем, хватает ли истории для обучения.
• Перечень задач мониторинга. Что система должна делать: сигналить о превышениях, строить карту загрязнения по городу, разбирать вероятный источник или считать прогноз.
• Требования к прогнозу. Горизонт и шаг прогноза, допустимая ошибка на горизонте, по каким постам и веществам считаем — от этого зависит и модель, и объём работ.
• Опорные измерения. Данные референсной станции или лабораторных замеров — по ним настраивается поправка на влажность и температуру, иначе дешёвые датчики дают смещение.
• Порядок согласования этапов. Кто принимает результат, нужна ли интеграция с диспетчерской или экологами, готовы ли вы к опытной эксплуатации на части постов перед масштабированием на всю сеть.

Из этого набора собирается план: подготовка данных, обучение и проверка модели, сигналы оператору, регламент сверки с референсными замерами. Опишите задачу и пришлите то, что уже есть, — вернёмся с оценкой сроков и составом этапов.