Урок 3: CV-конвейер для ОТК — от разметки до деплоя на Jetson

Чему вы научитесь

• Собирать полный CV-конвейер для ОТК: от разметки до деплоя и интеграции с MES
• Различать detection и anomaly detection и не пытаться лечить one-class задачу обычным detector’ом
• Выбирать инструменты без лицензионной мины под ногами: где можно YOLO, а где лучше Detectron2 или MMDetection
• Понимать, когда нужен OpenVINO, когда TensorRT, а когда достаточно ONNX Runtime
• Использовать открытые промышленные датасеты для первичной проверки пайплайна до выхода на свои данные

В производственном CV главное не «какую нейросеть выбрать», а как собрать конвейер так, чтобы он выжил после пилота. Разметка, чистка датасета, обучение, экспорт, runtime, edge-устройство, интеграция с MES и SLA на ложные срабатывания — всё это одна система. Если собрать только середину, проект умрёт на стыке.

Из каких слоёв состоит production-grade CV-стек

Сначала ответьте на один вопрос: это detection или anomaly detection

На реальном заводе половина ошибок возникает ещё до выбора фреймворка. Команда видит дефекты, открывает YOLO и начинает детекцию. А потом выясняется, что размеченных дефектов почти нет, новые типы брака появляются раз в два месяца, а исторический архив состоит в основном из хороших изделий.

Тут и проходит развилка.

Официальный репозиторий Anomalib описывает библиотеку как collection state-of-the-art anomaly detection algorithms и прямо подчёркивает готовность к training, inference, benchmarking и edge deployment; на 10 апреля 2026 года актуальный релиз — v2.3.3 (open-edge-platform/anomalib). Это уже не «академическая игрушка», а вполне зрелый production-инструмент для one-class сценариев.

YOLO: технически сильный, юридически опасный

Research-пак часто оперирует ярлыками YOLO v11 и YOLO v12. Но в enterprise для вас важнее не маркетинговый номер версии, а то, что официальный репозиторий ultralytics/ultralytics лицензирован под AGPL-3.0, а сама компания отдельно продаёт enterprise license для коммерческого использования (ultralytics/ultralytics).

Detectron2 и MMDetection дают более безопасную юридическую базу для промышленного контура. Detectron2 хорошо подходит там, где важна точность и сложные двухстадийные архитектуры. MMDetection удобен, когда нужна большая библиотека моделей, единый API и нормальный deployment path через ONNX/TensorRT/OpenVINO (detectron2 repo, mmdetection repo).

Реальный pipeline: как это выглядит вживую

flowchart LR
    A[Камеры / архив изображений] --> B[CVAT или Label Studio]
    B --> C[FiftyOne: чистка и ревью датасета]
    C --> D{Тип задачи}
    D -->|Классы дефектов известны| E[Detectron2 / MMDetection]
    D -->|Дефектов мало| F[Anomalib]
    E --> G[Экспорт в ONNX]
    F --> G
    G --> H{Куда деплой?}
    H -->|Intel IPC| I[OpenVINO]
    H -->|Jetson / NVIDIA| J[TensorRT]
    H -->|Универсально| K[ONNX Runtime]
    I --> L[MES / журнал дефектов / HMI]
    J --> L
    K --> L

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

• на части кадров размечен не весь объект;
• есть дубли из камеры;
• у ночной смены отдельный lighting profile;
• половина ложных срабатываний связана не с моделью, а с данными.

FiftyOne как раз силён в data curation, визуализации ошибок и поиске выбросов до того, как вы начнёте бесконечно «тюнить нейронку» (voxel51/fiftyone).

Что брать на deployment

ONNX Runtime

Это базовый нейтральный runtime. Он кроссплатформенный, под MIT, умеет разные hardware backends и обычно является лучшей отправной точкой, если вы хотите сохранить переносимость (microsoft/onnxruntime).

OpenVINO

Если ваш промышленный ПК живёт на Intel CPU/Arc и вы хотите санкционно более устойчивый контур без зависимости от NVIDIA, OpenVINO часто оказывается самым практичным вариантом. Официальный проект открытый, под Apache-2.0, и заточен именно под оптимизацию и deployment AI inference (openvinotoolkit/openvino).

TensorRT

Если линия сидит на Jetson или на NVIDIA edge GPU, TensorRT почти всегда даёт лучший runtime. Но надо помнить две вещи.

Во-первых, открытым является репозиторий компонентов TensorRT, а не весь коммерческий мир NVIDIA вокруг него (NVIDIA/TensorRT). Во-вторых, вы всё равно зависите от поставок NVIDIA-железа — а это уже тема урока p.2/03 про железо и урока p.3/05 про санкции.

Датасеты, на которых удобно собирать MVP

Тут главный совет такой: не пытайтесь доказать production на публичном датасете. Используйте публичный набор, чтобы отладить pipeline, а потом быстро переходите на свой контур и свои камеры.

Как запускать проект без хаоса

1. Сначала соберите правила разметки. Что считается дефектом, кто принимает решение, как размечать спорные кадры.

2. Постройте baseline на открытом датасете. Не для красоты отчёта, а чтобы команда прошла весь путь от annotation до runtime.

3. Решите, нужна ли вам class-based детекция или one-class anomaly. Это главный архитектурный выбор.

4. Экспортируйте модель в нейтральный формат. ONNX почти всегда лучший промежуточный контракт между training и deployment.

5. Подбирайте runtime под железо. Intel — OpenVINO, Jetson — TensorRT, универсальный случай — ONNX Runtime.

6. Интегрируйте результат не только в dashboard, но и в производственный процесс. В журнал дефектов, MES, HMI, сигнал мастеру, статистику линии.