Розробка системи детекції вторгнення (Intrusion Detection) за відео

Уявіть: серверна кімната банку, 3:00 ночі. Камера фіксує рух – система піднімає тривогу, охорона виїжджає, а це лише пакет, що впав з полиці. На об'єкті з 20 камерами до 30% усіх тривог — хибні. Оператори звикають ігнорувати попередження, і реальне вторгнення залишається непоміченим. Кожне таке хибне спрацьовування — потенційний збиток або адміністративні штрафи. Ми вирішуємо цю проблему дворівневою архітектурою детекції, яка відсіває 90% порожніх кадрів і дає recall >95% при <1 хибній тривозі на годину на камеру. Нижче розберемо технічні деталі.

Як дворівнева архітектура відсіває 90% порожніх кадрів?

Перший рівень — motion pre-filter на основі background subtractor MOG2. Він швидший за нейромережу — latency <5 мс на кадр. Якщо motion_level нижче порогу (0.001), кадр пропускається: ML-інференс не запускається. Це економить GPU — навантаження падає в 3-5 разів. Другий рівень — YOLO детекція з фільтрацією за зоною.

import cv2
import numpy as np
from ultralytics import YOLO

class IntrusionDetector:
    def __init__(self, model_path: str, zone_polygon: list,
                 sensitivity: str = 'medium'):
        self.detector = YOLO(model_path)
        self.zone = np.array(zone_polygon, dtype=np.int32)
        self.bg_subtractor = cv2.createBackgroundSubtractorMOG2(
            history=500,
            varThreshold=16,
            detectShadows=True
        )
        self.conf_thresholds = {'low': 0.7, 'medium': 0.5, 'high': 0.3}
        self.conf = self.conf_thresholds[sensitivity]
        self.confirmed_tracks = {}
        self.confirmation_frames = 3

    def detect(self, frame: np.ndarray) -> dict:
        result = {'intrusion_detected': False, 'intruders': [], 'motion_level': 0.0}
        fg_mask = self.bg_subtractor.apply(frame)
        fg_mask[fg_mask == 127] = 0
        motion_level = float(fg_mask.sum()) / (frame.shape[0] * frame.shape[1])
        result['motion_level'] = motion_level
        if motion_level < 0.001:
            return result
        detections = self.detector(frame, conf=self.conf, classes=[0,2,3,5,7])
        for box in detections[0].boxes:
            x1,y1,x2,y2 = map(int, box.xyxy[0])
            cx,cy = (x1+x2)//2, (y1+y2)//2
            in_zone = cv2.pointPolygonTest(self.zone, (float(cx),float(cy)), False) >=0
            if in_zone:
                result['intruders'].append({
                    'class': self.detector.model.names[int(box.cls)],
                    'confidence': float(box.conf),
                    'bbox': [x1,y1,x2,y2],
                    'center': (cx,cy)
                })
        if result['intruders']:
            result['intrusion_detected'] = True
        return result

Такий підхід дозволяє задіяти нейромережу тільки на кадрах з рухом. На практиці це знижує навантаження на GPU з 100% до 20–30%, що особливо важливо при паралельній обробці 8–16 камер на одному сервері.

Чому фільтрація за площею та підтвердженням кадрів знижує false alarm до <1?

Хибні спрацьовування найчастіше викликані дрібними тваринами, листям, що падає, або тінями. Для їх відсіву застосовуються два фільтри. Перший — мінімальна площа bounding box (2000 пікселів): об'єкти менші за цю площу не вважаються вторгненням. Другий — підтвердження на 3 послідовних кадрах: якщо об'єкт зник на наступному кадрі, тривога не піднімається.

class FalsePositiveFilter:
    def __init__(self):
        self.event_buffer = []
        self.cooldown_seconds = 30

    def should_trigger_alarm(self, intrusion_event: dict, current_time: float) -> bool:
        for intruder in intrusion_event.get('intruders', []):
            x1,y1,x2,y2 = intruder['bbox']
            area = (x2-x1)*(y2-y1)
            if area < 2000:
                return False
        if self.event_buffer:
            last_event_time = self.event_buffer[-1]
            if current_time - last_event_time < self.cooldown_seconds:
                return False
        self.event_buffer.append(current_time)
        self.event_buffer = self.event_buffer[-10:]
        return True

Така комбінація дає стабільно низький false alarm rate — менше 1 хибної тривоги на годину на камеру при збереженні recall >95%.

Налаштування мультизонної конфігурації з розкладом та whitelist

Кожна зона описується полігоном з параметрами alert_level (warning/critical), schedule (always/after_hours) та списком allowed_persons. Наприклад, серверна кімната може бути налаштована як critical, активна лише в неробочий час та ігнорувати авторизованих співробітників.

zones_config = {
    'perimeter': {
        'polygon': [[0,300],[1920,300],[1920,1080],[0,1080]],
        'alert_level': 'warning',
        'schedule': 'always'
    },
    'server_room': {
        'polygon': [[500,200],[900,200],[900,600],[500,600]],
        'alert_level': 'critical',
        'schedule': 'after_hours',
        'allowed_persons': ['id_001', 'id_002']
    }
}

Така гнучкість дозволяє налаштувати систему під будь-які сценарії: від периметра з низьким пріоритетом до критичних зон з whitelist співробітників.

Робота в темний час доби: ІЧ та тепловізори

Стандартні RGB-камери непридатні для детекції в повній темряві. Рішення — використання ІЧ-підсвітки (850/940 нм) з донавченою моделлю на ІЧ-кадрах або теплових камер (FLIR, Axis). Комбінація RGB та теплового каналу дає найкращий результат: detection rate 90–94% при нульовій освітленості.

Що входить в роботу

• Документація: схема архітектури, конфіги зон, інструкція оператора.
• Доступи: до репозиторію з кодом, дашборду метрик, REST API для інтеграції.
• Навчання: 2-годинний вебінар для охорони та адміністраторів.
• Підтримка: 3 місяці безкоштовного супроводу з реакцією на інциденти протягом 24 годин.

Процес впровадження: від аудиту до підтримки

1. Аналітика об'єкта. Візит інженера, заміри освітленості, розташування камер, складання карти зон.
2. Проектування. Вибір архітектури (single-server vs distributed), підготовка конфігів.
3. Розробка. Кастомізація моделі YOLOv8 на ваших кадрах (RGB, ІЧ, тепло). Додаємо data augmentation: ніч, туман, дощ.
4. Інтеграція. Підключення до існуючої системи відеоспостереження та PSIM.
5. Тестування. Прогін сценаріїв: реальні вторгнення, перешкоди, замір recall та false alarm rate.
6. Документація та навчання. Інструкція для операторів, передача коду та конфігурацій.
7. Підтримка. 3 місяці безкоштовного супроводу з реакцією на інциденти протягом 24 годин.

На кожному етапі ви отримуєте звіт та демонстрацію результатів.

Забезпечення стабільної точності: трекінг та data augmentation

Щоб система не втрачала ціль при тимчасових перекриттях, використовується трекінг об'єктів на основі алгоритму SORT. Додатково кожна модель проходить навчання з аугментацією: нічні кадри, туман, дощ, відблиски. Це гарантує стабільну роботу в будь-яких погодних умовах та часі доби. Наша команда має 5+ років досвіду в Computer Vision та реалізувала понад 30 проєктів відеоаналітики різної складності.

Отримайте консультацію по вашому об'єкту – наші інженери підберуть оптимальне рішення. Замовте пілотний проєкт на 2 камери та переконайтеся в ефективності технології. Зв'яжіться з нами для детального аудиту.

Як distribution shift вбиває метрики CV-моделі в промисловості

На виробництві ставлять камеру, контролюють якість продукції. Модель навчена на 10 000 розмічених зображень — точність на тесті mAP 0.84. Запускають у продакшен — і в перший же тиждень пропускають 30% дефектів. Освітлення на лінії змінюється по змінах, distribution shift обнуляє метрики. Це класична історія з Computer Vision у промисловості, де розпізнавання образів дає збій без правильної обробки дрейфу.

Наші інженери з досвідом 60+ проектів з комп'ютерного зору знають, як виключити такі сценарії. Гарантуємо стабільну роботу моделі в реальних умовах.

Які архітектури детекції об'єктів обрати: YOLO, RT‑DETR чи інші?

YOLO — стандарт для real‑time детекції. YOLOv8 та YOLOv11 від Ultralytics — найбільш використовувані версії у виробництві: простий API, активна спільнота, вбудована валідація та експорт в ONNX/TensorRT. Для задач з високими вимогами до точності та коли latency менш критична — RT‑DETR, transformer‑based архітектура без NMS, дає кращий mAP на COCO при порівнянній швидкості з YOLOv8l.

Типова помилка при навчанні детектора: датасет 8000 зображень, 3 класи, fine‑tune YOLOv8m — F1 0.73 на валідації. Дивимося confusion matrix — один клас майже ніколи не детектується. Причина: дисбаланс 1:23. Рішення: oversampling рідкісного класу, focal loss для objectness, аугментації (Mosaic, MixUp вимкнути для рідкісного класу — вони його «розмивають»). Transfer learning обов'язковий: передтреновані на COCO ваги скорочують потребу в даних у 10 разів. Fine‑tune на 500–2000 доменних зображеннях дає робочу модель за 1–2 дні на одній GPU.

Для edge deployment: експорт в ONNX → TensorRT engine. YOLOv8n в TensorRT FP16 на Jetson AGX Orin дає 150+ FPS при P99 latency < 8 ms — це в 3 рази швидше, ніж ONNX Runtime без TensorRT. На сервері A10G: 700+ FPS для YOLOv8n в TensorRT INT8.

Як fine‑tuning YOLO допомагає в розпізнаванні образів?

Припустимо, потрібно знаходити мікродефекти на поверхні металу — задача з високою роздільною здатністю та перекосом класів. Використовуємо YOLOv8m, передтренований на COCO (документація Ultralytics), і донавчаємо на 2000 власних зображень. Застосовуємо аугментації Mosaic, MixUp, random perspective. Після 200 епох mAP 0.5 досягає 0.93. Ключові прийоми:

• focal loss для objectness голови — зменшує внесок легко класифікованих прикладів.
• class‑balanced sampling — вирівнює представництво рідкісних класів.
• Test Time Augmentation (TTA) — підвищує recall на 5–7% за рахунок усереднення по фліпах та масштабах.

Отримайте консультацію з підбору архітектури для вашого завдання — зв'яжіться з нами.

Які архітектури сегментації обрати: SAM, Mask R‑CNN чи інші?

SAM (Segment Anything Model) від Meta змінив підхід до сегментації. SAM 2 працює з відео, підтримує трекінг об'єктів через кадри — для інтерактивного виділення об'єкта по точці або bbox це найкращий вибір з коробки. Для production instance segmentation без інтерактивного промпту — Mask R‑CNN або YOLOv8‑seg. YOLOv8‑seg навчається як звичайний детектор з додатковими масками, зручний у тих же пайплайнах. Семантична сегментація (кожен піксель — клас) — SegFormer, DeepLabV3+. SegFormer‑B5 дає хороший баланс точності та швидкості для аналізу супутникових знімків або медичної сегментації.

Кейс: сегментація клітин на мікроскопічних зображеннях. Датасет 400 зображень з ручною розміткою. Навчання Mask R‑CNN на ResNet‑50 backbone дало IoU 0.61 — погано. Проблема: об'єкти (клітини) перекриваються, стандартний NMS вбиває перекриваючі передбачення. Рішення: перехід на cellpose (спеціалізована архітектура для біомедичних задач) + soft‑NMS. IoU зріс до 0.79.

Коли Tesseract не справляється з OCR?

Tesseract — відправна точка для простих задач: друкований текст, хороше освітлення, рівне розташування. Як тільки з'являються рукописні елементи, нестандартні шрифти, перспективні спотворення або багатоколоночний макет — Tesseract деградує швидко.

PaddleOCR — production‑grade рішення: виявлення текстових блоків + розпізнавання + структурний аналіз. Працює з коробки для 80+ мов, включаючи українську. Підтримує таблиці та документи зі складною структурою. Wikipedia: Оптичне розпізнавання символів. TrOCR (Microsoft) — трансформерний OCR з сильними результатами на рукописному тексті. Для українського рукописного тексту потрібен fine‑tuning: базова модель навчена переважно на латиниці.

Що робити, якщо Tesseract не справляється з розпізнаванням образів на документах?

Для задач «витягни дані з рахунку / договору / паспорта» використовуємо LayoutLMv3 або Donut — ці моделі розуміють layout документа, а не тільки текст. Інтеграція через Hugging Face Transformers, fine‑tuning на 200–500 розмічених документах. Типовий pipeline:

1. Preprocessing: deskew, denoising, binarization через OpenCV.
2. Виявлення текстових блоків: PaddleOCR detection або CRAFT.
3. Розпізнавання: PaddleOCR recognition або TrOCR.
4. Post‑processing: нормалізація, валідація через regex або LLM для структурованих полів.

Для документів з фіксованою структурою template matching + OCR точково по координатах часто надійніше за end‑to‑end рішення.

Face Recognition: ідентифікація та верифікація

Face recognition = detection + alignment + embedding + matching. Кожен етап важливий.

Detection: RetinaFace або InsightFace для точної локалізації обличчя та ключових точок. MTCNN — старіше, але надійне рішення. Embedding: ArcFace (InsightFace) — state‑of‑the‑art для face recognition embeddings. Моделі iresnet50/iresnet100 передтреновані на MS1MV3 (5M ідентичностей). Ембеддинг‑вектор 512 float32, порівняння за cosine similarity. Threshold tuning: поріг рішення — критичний параметр. При threshold 0.6 типовий FPR на LFW benchmark — 0.001, TPR — 0.985. У production threshold потрібно калібрувати під реальний distribution: люди в масках, зі зміненою зовнішністю, в різних умовах освітлення. Liveness detection обов'язковий: MiniFASNet — lightweight модель на CPU, FaceX‑Zoo містить кілька передтренованих liveness‑детекторів.

Відеоаналітика

Відео — послідовність кадрів плюс часовий вимір. Наївний підхід — детектувати на кожному кадрі — дорого.

Трекінг: ByteTrack та BoT‑SORT — стандарт для multi‑object tracking. Працюють поверх будь-якого детектора, додають persistent ID об'єктам між кадрами — це дає підрахунок об'єктів, трекі руху, velocity.

Оптимізація: не потрібно обробляти кожен кадр. Для статичних сцен детекція на кожному 5–10 кадрі, між ними — трекер. Для детекції подій (людина увійшла в зону) background subtraction (OpenCV MOG2) як lightweight pre‑filter перед нейромережевою детекцією. Action Recognition: SlowFast, VideoMAE для класифікації дій. Важкі моделі — для production використовуємо ONNX export + TensorRT або офлайн обробку.

Як виміряти якість моделі розпізнавання образів у продакшені?

Моніторинг якості — ключовий елемент MLOps. Відстежуємо:

• розподіл prediction confidence;
• частку low‑confidence передбачень (індикатор OOD‑даних);
• дрейф вхідних зображень через feature distribution (embeddings з backbone).

Падіння середньої confidence з 0.87 до 0.71 за тиждень — ранній сигнал про distribution shift. NVIDIA Triton Inference Server рекомендує відстежувати ці метрики через Prometheus. Наші сертифіковані інженери налаштовують моніторинг і гарантують SLA по якості інференсу.

Деплой CV‑моделей

Для онлайн інференсу використовуємо Triton Inference Server (NVIDIA) — production‑стандарт для serving CV‑моделей. Підтримує TensorRT, ONNX, PyTorch, dynamic batching, multiple instances. REST та gRPC API. Гарантуємо стабільну роботу під навантаженням.

Edge deployment: ONNX Runtime на ARM/x86 CPU. TensorFlow Lite для мобільних пристроїв. OpenVINO для Intel CPU/GPU/VPU — дає 2–3× приріст швидкості на Intel залізі порівняно з ONNX Runtime. Після деплою передаємо модель з документацією та навчаємо персонал.

Що входить в роботу

Терміни та вартість

Прототип детектора на існуючих даних — 1–2 тижні. Production‑система з оптимізацією під цільове залізо — 4–8 тижнів. Повний цикл включаючи розмітку даних (1000–5000 зображень) — 2–4 місяці. Вартість розраховується індивідуально під кожну задачу. Ми на ринку більше 5 років, реалізували 60+ проектів з комп'ютерного зору. Оцінимо ваш проект під ключ — замовте консультацію, щоб отримати розрахунок та технічну пропозицію.