Искусственный интеллект в строительстве: как масштабировать видеоаналитику с 5 камер до 500

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

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

Что понадобится

• FFmpeg и GStreamer для работы с видеопотоками (оба бесплатны и открыты)
• CVAT (открытый инструмент разметки данных для машинного зрения, поддерживает командную работу и автоматическую предразметку)
• Модель YOLO (семейство моделей для обнаружения объектов в реальном времени) с возможностью дообучения (fine-tuning, обучение модели на ваших примерах под узкую задачу)
• Доступ к RTSP-потокам камер (RTSP, протокол передачи видео в реальном времени, стандарт для IP-камер)
• Облачный сервер с GPU или локальное оборудование на объекте
• Объектное хранилище (S3 или аналог) для видеоархива
• Время: от 2 до 4 недель на MVP, от 2 до 3 месяцев на переход к микросервисной архитектуре

Как масштабировать видеоаналитику на стройке: пошаговая инструкция

1. Начните с монолита, не с микросервисов

При 5 до 7 камерах монолитная архитектура работает лучше. Микросервисы на старте лишь добавляют сложность разработки и съедают время. Задача первого этапа: быстро собрать MVP.

Базовый пайплайн (последовательность обработки данных) выглядит так: получили RTSP-поток, прогнали кадры через ML-модель (модель машинного обучения), сформировали инцидент.

2. Следите за порогом в 20 камер

Это точка, после которой монолит начинает разваливаться. По опыту источника, симптомы выглядят так:

• Часть потоков перестаёт загружаться
• Загрузка отдельных камер занимает до 2 минут
• Растёт задержка от детекторов
• Приходится перезапускать весь сервис, чтобы восстановить работу одной камеры

Если вы видите эти признаки, пора пересобирать архитектуру, а не ставить заплатки.

3. Разделите пайплайн на независимые компоненты

Ключевое архитектурное решение: жёстко разграничить четыре слоя уже на старте.

• Получение видеопотока (захват с камер)
• Инференс (inference, прогон кадров через нейросеть для распознавания объектов)
• Бизнес-логика (формирование инцидентов, алертов)
• Хранение (метаданные, короткие фрагменты событий, изображения)

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

4. Создайте промежуточный слой для нормализации видео

Камеры разных производителей отдают видео в разных форматах. По словам разработчиков из источника, тому, что написано в паспорте камеры, быстро перестаёшь верить.

На реальном объекте встречаются одновременно:

• Разные кодеки (H.264 и H.265)
• Разница в FPS (количество кадров в секунду)
• Нестандартный GOP (Group of Pictures, структура последовательности кадров в видеопотоке)
• Нестабильный RTSP-сервер

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

5. Внедрите буферизацию, но с ограничениями

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

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

6. Измеряйте задержку по всему пайплайну, не одной цифрой

Задержка между событием на камере и алертом (уведомлением) оператору складывается из нескольких участков. Измерять нужно каждый отдельно:

• Камера
• Получение кадров
• Очередь
• Инференс
• Бизнес-логика
• Отправка события

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

7. Мониторьте каждый поток отдельно

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

• Когда пришёл последний кадр
• Когда был последний успешный инференс
• Есть ли реконнекты
• Каков FPS и есть ли задержка

8. Обновляйте модели без остановки сервиса

Модели нужно отделить от остальной логики системы. Схема безопасного обновления:

1. Параллельно поднимаете новую версию модели
2. Проверяете её на части потоков
3. Переключаете нагрузку

Этот подход надёжнее, чем остановка всего сервиса и замена файла модели.

9. Решите: облако или edge-вычисления на объекте

Если на стройке плохой внешний канал связи и много камер, имеет смысл делать вычисления прямо на объекте. Гонять сотни исходных видеопотоков в облако не всегда разумно ни технически, ни экономически. Но когда канал хороший, облачная обработка удобнее.

10. Используйте CVAT для разметки данных

Для дообучения YOLO под задачи стройки (каски, жилеты, техника) потребуется разметка. CVAT поддерживает разные типы разметки, командную работу и ускоряет процесс за счёт трекинга и автоматической предразметки. Начинайте с людей и СИЗ (средств индивидуальной защиты), затем переходите к технике и сложным событиям.

Что делать с этим прямо сейчас, по ролям

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

Автору Дзена, который пишет про стройку или технологии. Тема искусственного интеллекта в строительстве набирает поисковый спрос, но контент по ней поверхностный. Разбор реальных архитектурных решений выделит ваш канал среди общих обзоров «ИИ придёт на стройку».

Предпринимателю, который внедряет видеонаблюдение на объектах. Перед закупкой камер проверяйте не паспортные характеристики, а реальные параметры потока. Заложите в бюджет слой нормализации и мониторинг каждого потока отдельно. Из инструментов разметки в РФ доступен CVAT (опенсорс, ставится локально), для инференса можно использовать YOLO с дообучением на данных именно вашей стройки.

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