Разметка данных для компьютерного зрения: узкие места
Модель показывает на валидации mAP под 0.9 и уверенный recall по редким классам, а в работе пропускает дефекты на новом освещении и путает похожие категории. Причина обычно не в архитектуре: выборки собраны одним подрядчиком по одной инструкции, а в продакшене приходят кадры с другой камеры, другого сезона и другой смены. Качество разметки на валидации держится ровно потому, что в ней нет тех пограничных случаев, где разметчик ошибался.
Чаще всего виновато расхождение валидации и продакшена: обучающий датасет собран с одной партии оборудования и в одном сценарии, а тестовая часть просто повторяет его распределение. Дополнительно накапливаются ошибки разметки — обрезанные или сдвинутые боксы, потерянные мелкие объекты, метки на фоне, разные определения класса у разных исполнителей при IoU 0.3–0.5. Ни loss, ни метрики такие дефекты не ловят: модель выучивает шум как закономерность.
Отраслевые оценки сходятся: до трёх четвертей времени в проектах компьютерного зрения уходит не на обучение, а на подготовку, прелейблинг и перепроверку данных — по данным AI Index. Пропущенная ошибка разметки стоит дороже на этапе внедрения, чем на этапе сбора: разбираем, как это закрывается дисциплиной процесса, а не расширением выборки.
Что даёт прелейблинг и контроль качества на потоке
Прелейблинг — это предварительная разметка кадра моделью до того, как его увидит оператор: детектор ставит рамки и классы, трекер протягивает объекты между соседними кадрами. Оператор не рисует с нуля, а подтверждает или правит. Разметку ведём в CVAT с собственными расширениями под прелейблинг и проверку — поэтому оба эффекта ниже измеряются на каждом проекте, а не остаются обещанием.
Прелейблинг: во сколько раз падает объём ручной работы
На видео трекинг снимает с оператора рутинную протяжку объектов между кадрами — остаётся правка границ на смене сцены и контроль появления новых объектов. На статичных кадрах детектор предзаполняет рамки с классами, и оператор работает в режиме подтверждения, а не разметки с чистого листа. У прелейбла есть порог уверенности: ниже него объект уходит как «неуверенный», выше — попадает в выборочную проверку.
Это сокращает ручную работу не «в среднем», а предсказуемо: доля кадров, уходящих на полную правку, падает в разы, а разброс качества между исполнителями сужается, потому что правила интерпретации задаёт модель, а не каждый разметчик по-своему.
Сквозной контроль качества и разбор спорных кадров
Кадр проходит не одну вычитку, а цепочку: автопроверка геометрии и классов → выборочная перекрёстная проверка → разбор спорных случаев отдельным составом. Спорные кадры не «замазываются» большинством голосов, а уходят в очередь с эталонным решением — оно становится правилом для похожих ситуаций и фиксируется в инструкции. Контроль качества разметки даёт измеримый результат: доля правок после вычитки падает от итерации к итерации, а метрика модели на отложенной выборке перестаёт прыгать между переобучениями.
Сравнение режимов разметки данных: штат, подрядчик, гибрид
Выбор исполнителя разметки решает не вопрос цены, а вопрос класса объектов и объёма потока. Свой штат разметчиков держит спорные классы и правки инструкции под контролем, но плохо переносит пики: найм и обучение занимают недели, а между проектами люди простаивают.
Разметка данных подрядчиком закрывает пиковую нагрузку и приносит готовые регламенты контроля качества, зато каждая правка инструкции идёт через цикл согласования. Гибридная схема разметки оставляет ядро и приёмку у себя, а массовый объём отдаёт внешней команде.
| Вариант | Когда подходит | Ограничения |
|---|---|---|
| Свой штат разметчиков | Узкие классы с высокой ценой ошибки, закрытые данные, частые правки инструкции | Медленно масштабируется, дорого держать простой между проектами |
| Внешняя команда | Массовый поток однотипных кадров, стабильная инструкция на месяцы | Зависит от качества инструкции и ротации исполнителей |
| Гибридная схема с прелейблингом | Пик по объёму вместе со спорными классами, нужен быстрый старт | Требует своего ядра для проверки и приёмки |
Ограничения по типам объектов
Рамки и точки размечаются быстрее и почти без потерь уходят внешней команде. Полигоны, маски и скелеты требуют единых правил на границах и перекрытиях: здесь подрядчика подключают через прелейблинг модели, а спорные случаи разбирает своё ядро.
Что меняется при росте объёма кадров
На потоке в разы растёт доля пропущенных объектов и двойных рамок — узким местом становится контроль качества, а не сама разметка. Гибрид переживает этот перелом легче: прелейблинг снимает рутину, выборочная проверка ловит расхождения, а согласие между разметчиками показывает, когда инструкцию пора переписать.
Как устроен процесс: аудит, схема, пилот, передача
Процесс строим так, чтобы разметка не превращалась в чёрный ящик: на каждом этапе остаётся проверяемый артефакт и метрика качества. Так видно, на каком шаге какой результат появляется.
- Аудит исходного набора. Состав кадров, условия съёмки, дубликаты, доля кадров без целевых объектов, битые выгрузки.
- Схема классов и атрибутов. Список классов, версия схемы, правила для пограничных случаев: перекрытия, частично видимые объекты, блики.
- Предварительная разметка моделью. Черновик от сети разметчик правит вручную — проход ускоряется в разы, но контроль остаётся.
- Контроль качества. Перекрёстная проверка спорных кадров, метрика согласия между исполнителями, разбор расхождений с обновлением инструкции.
- Пилотная партия. Небольшой срез проходим целиком и считаем долю ошибок — по ней правим инструкцию до старта основного объёма.
- Приёмка и передача. Выгрузка в формате, который принимает ваша модель, реестр версий, инструкции, обучение вашей команды.
Что показывает аудит исходного набора
Чаще всего он вскрывает неочевидное: часть кадров дублируется, у многих нет объектов нужного класса, а разметка разных исполнителей противоречит сама себе. Не увидев этого на входе, ошибку масштабируют на весь набор.
Как устроена приёмка и обучение команды заказчика
На приёмке выборочно проверяем партию по тем же правилам, что и исполнители, и показываем расхождения. Затем передаём документацию по схеме классов и разбираем с вашей командой, как принимать следующие партии самостоятельно.
Комплект поставки: схемы, регламенты, документация
Разметка без документации живёт до первой смены исполнителя: новый человек трактует классы по-своему, и датасет начинает расходиться с исходной схемой. Поэтому комплект поставки — не архив с файлами, а набор документов, по которым следующая команда разметчиков или ваш инженер воспроизводят ту же разметку без нас.
Инструкция разметчика и правила разрешения спорных случаев
Инструкция разметчика — рабочий документ под конкретную схему, а не общий гайд: для каждого класса прописан порядок действий, граничные примеры и типовые ошибки с визуальными эталонами. Спорные случаи не решаются на месте — разметчик ставит флаг на объект, арбитр фиксирует решение в журнале, и оно входит в следующую ревизию инструкции.
- Схема разметки и атрибутов — иерархия классов, типы геометрии, обязательные и опциональные признаки, правила перекрытий и минимальный размер объекта.
- Инструкция разметчика — алгоритм по каждому классу, визуальные эталоны, разбор типичных ошибок.
- Регламент контроля качества — доля повторной проверки, порог согласия между разметчиками, правило отправки задачи на переразметку.
- Правила разрешения спорных случаев — уровни эскалации, роль арбитра, журнал принятых решений.
- Документация по разметке — форматы выгрузки, словарь классов, история версий схемы.
- Проверочный набор для приёмки новых исполнителей и отчёт о качестве: какие классы дают основную долю ошибок и как показатель меняется от итерации к итерации.
Кейс: как пилот снизил долю переделок на проверке
Клиент приносил поток записей с камер: ночные сцены, перекрытия, объекты на границе кадра. Разметку вели в CVAT силами распределённой команды — инструкция на двадцать страниц, приёмка последним уровнем. Стабильно 16–18% кадров возвращались на переделку, среднее время на кадр держалось около 40 секунд, и датасет рос медленнее, чем требовал график обучения.
Что именно поменяли в процессе и почему это сработало
Убрали ручную отрисовку «с нуля»: модель предразметки, обученная на уже принятых кадрах, отдаёт аннотатору готовые рамки, а он их правит. Самый долгий этап — поиск границ объекта — исчез, и время на кадр упало до 12–15 секунд.
Контроль качества перенесли с партии на кадр. Спорные случаи — перекрытия, размытие, объект на границе — уходят в отдельную очередь с явно описанным критерием решения, поэтому повторно проверяется не весь датасет, а 6–8% выборки. Инструкцию заменили коротким чек-листом с эталонными примерами: расхождения между аннотаторами сократились.
Итог по метрикам: доля переделок — с 17% до 4%, время на кадр — с 40 до 14 секунд, объём повторных проверок меньше втрое. Метрики качества разметки — согласованность проверяющих и доля кадров, принятых с первого раза — снимаем на каждой поставке, поэтому рост объёма не размывает качество.
Чем прелейблинг отличается от аннотации с нуля?
Прелейблинг и ручная аннотация приводят к одному результату — корректные боксы, маски или ключевые точки на кадре, — но идут к нему по-разному. При автоматической предразметке модель ставит черновые рамки, а аннотатор их подтверждает, сдвигает или удаляет; при разметке с нуля оператор рисует каждый объект сам. Разница проявляется в трудозатратах на кадр и в том, как ведёт себя качество на плотных сценах.
| Критерий | Прелейблинг | Ручная аннотация с нуля |
|---|---|---|
| Кто рисует объект | модель, человек правит | человек целиком |
| Время на кадр | в разы меньше на однородных классах | растёт линейно с числом объектов |
| Границы объектов | зависят от модели, нужна доводка | стабильнее на нестандартных формах |
| Плотные сцены | слияния и пропуски, нужен контроль | управляемо, но медленно |
| Когда подходит | поток данных, крупные однородные классы | редкие классы, тонкие границы, спорные случаи |
На практике подходы комбинируют: предразметка закрывает основной объём, ручная проверка — классы с высокой ценой ошибки. Граница определяется замером на выборке: если аннотатор правит меньше трети рамок, автоматическая предразметка окупается, если больше — модель протаскивает свои ошибки в датасет, и на этом классе дешевле вернуться к разметке с нуля.
Когда нужна ручная проверка? Там, где объект перекрывается фоном или соседними объектами, где класс визуально неотличим от близкого и где ошибка стоит дорого: медицина, дефектоскопия, учёт транспорта. Здесь контроль сплошной, плюс замер согласованности между аннотаторами — одинаковые случаи должны получать одинаковую метку, иначе модель выучит противоречие.
Технические сомнения: качество, сроки, доступы
Перед стартом техническая сторона вызывает больше вопросов, чем цена. Ниже — пять сомнений, которые чаще всего всплывают на согласовании, и ответы без общих слов: они опираются на регламент приёмки и на то, как устроена проверка разметки.
По каким метрикам вы принимаете разметку?
Согласованность аннотаторов на контрольной подвыборке, доля пересечения масок с эталоном (IoU) и полнота по редким классам. Пороги фиксируем в регламенте заранее: партия не уходит в работу, пока не проходит по всем трём.
Сколько времени займёт разметка?
Срок зависит от плотности объектов на кадре и числа классов. Первую партию размечаем с замером фактической выработки — дальше прогноз строится по реальной скорости, а не по нормативу.
Как передать изображения?
Рабочих схем три: выгрузка в наше хранилище, разметка на вашей инфраструктуре, доступ через защищённый канал с ролевой моделью. Персональные данные обезличиваем на входе, права отзываем после сдачи.
У нас уже есть частично размеченный набор
Проводим инвентаризацию: сверяем схему классов, ищем конфликты и дубли, достраиваем недостающие кадры и приводим всё к одному формату — COCO, YOLO или Pascal VOC.
Можно ли переиспользовать разметку?
Да. Таксономия классов и правила остаются активом: следующий проект стартует не с нуля — схема готова, часть кадров приходит с предварительной разметкой, проверка идёт только по спорным зонам.
Обсудим задачу: с чего начать и что понадобится
Чтобы вернуться с оценкой проекта разметки, а не с общими формулировками, нам нужен минимум стартовых материалов. Оценка держится на трёх величинах: сколько данных, по каким правилам их размечать и как проверять результат. Чем полнее вход, тем точнее объём разметки и сроки — и тем меньше переделок на этапе сдачи.
- Пример сырых данных — 200–500 файлов из реального потока, а не отобранные «удачные» кадры: на них видно шум, дубликаты, битые файлы и редкие классы.
- Список классов объектов и правила аннотации: что считаем отдельным объектом, как размечаем перекрытия, обрезанные объекты и спорные случаи, какой минимальный размер объекта учитываем.
- Ожидаемый объём разметки: число кадров и объектов, доля кадров под сплошную проверку, нужна ли разметка с нуля или достаточно предразметки модели с доразметкой оператором.
- Требования к выгрузке: структура каталогов, формат аннотаций, разбиение на выборки и то, как результат попадёт в обучение модели.
- Критерии приёмки и метрики качества: допустимая доля ошибок на выборке, согласие между разметчиками, порядок переразметки спорных примеров и обработки замечаний заказчика.
- Материалы прошлых итераций, если они есть: старые аннотации, журнал правок, известные проблемные классы — это снимает отдельный цикл калибровки.
Опишите задачу и приложите то, что уже есть, — вернёмся с оценкой и планом работ: этапы, сроки, состав команды и точки контроля качества на каждом шаге.
