Разработка системы компьютерного зрения (CV) под ключ

Разработка компьютерного зрения: где ломается пилот

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

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

Вторая — редкий класс дефекта. Брака мало, он занимает доли процента выборки: средняя точность по всем классам остаётся высокой, а конкретно редкий класс система не ловит. Его маскирует общая метрика, поэтому нужен отдельный замер по каждому классу и план добора примеров, а не просто рост объёма разметки.

Третья — нестабильная разметка. Пока критерий брака держится в голове оператора, один и тот же кадр размечается по-разному, и модель учится на противоречиях. Лечится это регламентом: описание классов, разбор спорных кадров, повторная проверка части выборки и контроль согласованности между разметчиками.

Четвёртая — отсутствие приёмки на реальном потоке. Если заранее не зафиксировано, какую долю пропусков и ложных срабатываний считаем приемлемой и как система ведёт себя при отказе, принять пилот нечем. Разбираем, как это закрывается на каждом этапе.

Эффект внедрения: контроль качества и разгрузка операторов

Метрики считаем до запуска, на пилотной выборке кадров с линии: доля пропущенного брака, число ложных срабатываний на смену, время разбора спорного кадра и сколько решений оператор принимает вручную. Это четыре величины, по которым видно, работает ли система, — а не общая «точность модели» в отчёте.

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

Вычисления идут на ускорителях NVIDIA: кадр обрабатывается быстрее, чем конвейер выдаёт следующий, поэтому темп линии снижать не приходится. Разгрузка оператора — следствие: большую часть решений принимает система, человек разбирает только спорные кадры и подтверждает смену.

Время разбора спорного кадра падает с минут до секунд: рядом лежат кадр, выделенная зона дефекта и версия модели, которая его вынесла. Стабильность качества даёт не пик, а разброс: оператор к концу смены реагирует иначе, чем в начале, модель — одинаково, поэтому расхождение между сменами и площадками сокращается.

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

Готовые модели, дообучение или обучение с нуля

К рабочей модели ведут три пути, и выбор подхода определяется не модой, а данными: сколько размеченных примеров есть на руках, насколько однородна сцена и какую долю ошибок заказчик считает допустимой. Готовая модель закрывает задачу за считанные дни — но только если ваши классы и условия съёмки совпадают с теми, на которых она обучалась.

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

Путь проекта: постановка задачи, разметка, обучение, приёмка

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

1. Постановка задачи. Описываем, что считается событием на кадре, в каких условиях работает камера и какую долю пропусков и ложных срабатываний считаем допустимой. Итог этапа — критерий годности в измеримых величинах.
2. Разметка данных. Берём реальные записи объекта, включая трудные кадры: ночь, дождь, перекрытия, блики. Разметка идёт по письменному регламенту, спорные случаи разбирает арбитр, пятую часть кадров проверяет второй разметчик.
3. Обучение модели. Дообучаем базовую модель, отдельно держим отложенную выборку, которая не участвует в настройке. Смотрим не на среднюю точность, а на редкие классы — обычно именно они ломают эксплуатацию.
4. Валидация на потоке. Запускаем модель в теневом режиме рядом с рабочим процессом и сверяем её решения с фактом. Здесь видны расхождения лабораторных метрик с реальностью: смена освещения, сдвиг камеры, новый тип объекта.
5. Пороги и устойчивость. Порог срабатывания подбираем под цену ошибки, описываем поведение при потере кадра или недоступности камеры — система должна деградировать предсказуемо.
6. Приёмка и передача. Прогон на контрольном отрезке, не использованном ни при обучении, ни при настройке, и сверка с критерием годности из первого шага. Отдаём модель, конфигурацию, регламент разметки и порядок возврата к предыдущей версии.

Комплект поставки: модель, разметка, документация, регламенты

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

• Обученная модель и контрольные точки — рабочие веса в формате, который принимает ваш контур исполнения, плюс промежуточные снимки по этапам обучения: откат на предыдущую версию занимает минуты, а не новую итерацию сбора данных.
• Наборы данных и карта разметки — исходные и размеченные выборки, описание классов, правила для пограничных и спорных объектов. Карта разметки снимает главный источник расхождений, когда к аннотированию подключаются новые люди.
• Воспроизводимость обучения — конфигурации, зафиксированные версии зависимостей, порядок перемешивания и протокол контроля качества. Повторный запуск даёт сопоставимую точность, а расхождение объясняется, а не списывается на «магию».
• Схемы интеграции — как модель встраивается в видеопоток, где точки отказа, какие задержки ожидаемы на каждом участке обработки кадра.
• Политики доступа к видео — кто и на каком основании видит поток и архив, сроки хранения, обезличивание, журналирование обращений к записям. Это же снимает вопросы службы безопасности при передаче системы.
• Регламент эксплуатации — что делать при падении точности, как выводится новая версия, кто принимает решение о переобучении, как фиксируются инциденты и деградация на смене освещения или сезоне.
• Комплект документации — инструкции для операторов и дежурных, описание метрик качества, порядок приёмки и передачи смены, словарь терминов предметной области.

Кейс контроля качества: система компьютерного зрения на линии

До внедрения

На линии розлива полимерной упаковки контроль вёлся выборочно: оператор ОТК снимал каждую двадцатую тару и осматривал визуально. Пропуск дефектов доходил до 7% — микротрещины и неполный шов уходили на паллетирование и возвращались рекламациями по партии. Ложные тревоги давали 15%: линию останавливали на перепроверку, выпадал сменный темп.

Итерации модели и изменение схемы съёмки

Первая версия на четырёх тысячах кадров снизила пропуск до 4%, но на редких классах оставалась слепой — меньше сотни примеров на весь набор. Меняли не модель, а съёмку: боковая подсветка под углом к горловине, синхронизация камер с датчиком позиции, отсев смазанных кадров, разметка спорных случаев в CVAT с двойной проверкой инженером.

База выросла до 16 тысяч кадров, редкие классы дополнили до трёх тысяч примеров. Вторая итерация дала пропуск 1,2% и ложные 6%, третья — 0,9% и 1,8%: добавили подтверждение по трём последовательным кадрам, чтобы одиночный блик на этикетке не уходил в брак.

Результат

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

Что делать, если камеры уже стоят и есть архив записей

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

Дальше выбираем один из трёх сценариев старта: они различаются сроком запуска и объёмом данных, который нужен до первой рабочей модели.

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

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

Технические сомнения: свет, разметка, ложные срабатывания

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

Ниже — вопросы, которые чаще всего задают технические руководители перед оценкой проекта.

Как понять, что разметка качественная?

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

Как снижаете ложные срабатывания?

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

Что происходит при деградации модели или сбое камеры?

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

Начнём с вашей задачи: что прислать для оценки

Оценка проекта компьютерного зрения упирается не в алгоритм, а в данные и условия съёмки. Поэтому исходные данные для оценки мы собираем одинаково — по списку ниже. Если пришлёте это, вернёмся не с общими словами, а со схемой решения и планом этапов.

• Видео или архив кадров с площадки: разные часы, освещение, погода, ракурсы.
• Перечень объектов и событий: что нужно находить, что считаем пропуском, а что — ложным срабатыванием.
• Условия съёмки: тип камер, высота подвеса, зона обзора, есть ли поворот и приближение.
• Что должно происходить с событием: запись, сигнал оператору, команда смежной системе.
• Где планируется обработка: на объекте или на ваших серверах, какой доступ к видеопотоку есть.
• Ограничения: требования к хранению данных, приватность, зоны, где съёмка запрещена.
• Критерий приёмки: по какой метрике вы будете считать систему работающей.
• Сроки и этапность: есть ли жёсткая дата запуска и что должно работать первым.

Если части данных нет — не страшно, эти ответы уточняем на обсуждении задачи. Дальше фиксируем схему решения, план этапов и объём работ по каждому.