Внедрение ИИ на строительных объектах имеет свою специфику, которая проявляется при масштабировании системы видеонаблюдения. Один из проектов, описанный на Habr, показывает, как архитектура эволюционирует от монолита к микросервисам, когда количество камер растет с 5 до 500. На старте, при 5–7 камерах, монолитная архитектура оказывается оптимальной: она позволяет быстро собрать MVP, вставить RTSP-поток, прогнать кадры через ML-модели и формировать инциденты. Микросервисы на этом этапе только усложнили бы разработку.

Когда число камер превысило 20, монолит начал давать сбои: часть потоков отваливалась, загрузка длилась до 2 минут, росла задержка от детекторов, иногда приходилось перезапускать сервис. Ожидалось, что первым не справится GPU, но он продолжал работать, а вот CPU не выдержал нагрузки из-за большого потока данных: ломалась запись потоков, декодирование видео и подготовка кадров. Это привело к решению пересобрать архитектуру, разделив получение потока, декодирование и инференс. Стек построили на FFmpeg и GStreamer, что позволило независимо масштабировать части пайплайна и изолировать проблемы.

Одной из ключевых проблем стала разнородность камер: разные кодеки (H.264, H.265), разрешения, FPS, нестандартный GOP и нестабильные RTSP-серверы. Для решения создали промежуточный слой обработки видеопотока, который нормализует параметры входных данных, передавая в систему предсказуемый поток кадров. Также пришлось ограничить размер очередей задач, чтобы не накапливать устаревшие кадры: если система перегружена, кадр пятиминутной давности теряет ценность, поэтому его отбрасывают.

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

Задержка между событием на камере и алертом оператору стала отдельной проблемой. Вместо одной цифры latency начали измерять по всему пайплайну: камеры, получение кадров, очередь, инференс, бизнес-логика, отправка события. Это позволило выявить, что в большинстве случаев нейросеть не является источником задержки. Часто камера продолжает отвечать по RTSP, но отдает зависший кадр, поэтому мониторинг данных внутри потока стал обязательным.

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

Отдельная тема — дообучение моделей YOLO под российские реалии. Модель YOLO (You Only Look Once) — популярная архитектура для обнаружения объектов в реальном времени. На стройке она используется для распознавания людей, техники, нарушений техники безопасности. Российская специфика включает особенности освещения, погодные условия, типы строительной техники и спецодежды, которые могут отличаться от зарубежных датасетов. Поэтому требуется сбор данных с реальных объектов и разметка, что занимает значительное время и ресурсы.

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