Привет, меня зовут Вадим Медяник, я технический директор ИТ-компании BPA. Я регулярно участвую в реализации проектов, где используется машинное обучение и компьютерное зрение — от первых обсуждений с заказчиком до вывода решения в прод. Со временем накопилось достаточно практики, чтобы выделить повторяющиеся этапы, типичные ошибки и решения, которые реально работают.
Это практическое руководство собрал для коллег и команд, кто работает с подобными проектами — или только планирует. Здесь нет задач про state-of-the-art или подбор идеальных архитектур. Скорее хочу пройтись по каждому этапу — с чего начать, о чём спросить бизнес, где обычно «сыпется» проект, и что помогает пройти до конца. Рассчитано на тех, кто хочет разобраться в базовой структуре CV/ML-проекта, будь то инженер, аналитик или управленец. Если понадобится — можно будет углубиться в технические детали отдельно. Для удобства разделил весь путь подготовки CV-проекта на несколько основных этапов.
Этап 1. Инициация и постановка задачи
На первом этапе (возможно его в принципе надо бы выделить в нулевой, потому что сейчас речь пойдет о том – нужен ли вам вообще CV-проект, но пусть будет первым) важно понять, действительно ли задача требует применения машинного обучения и компьютерного зрения.
Универсального ответа нет — это всегда зависит от конкретного кейса и детально обсуждается с заказчиком. На практике чаще всего CV применяется там, где есть визуально фиксируемый физический процесс: движение человека, работа оборудования, охрана, доступ, контроль чего-либо в кадре. Важно, чтобы процесс можно было захватить камерой — не обязательно стандартной. Это может быть инфракрасная или тепловизионная камера. Камерой нужно просто «видеть» нужное поведение или событие.
Важно понимать: CV — это не волшебная палочка, и его не нужно применять везде, где можно. Бывают задачи, которые проще, быстрее и дешевле решить обычной логикой, без ML. Но есть задачи, где без компьютерного зрения просто не обойтись. Это чаще всего задачи постоянного мониторинга, в которых человек физически не может обеспечить требуемый уровень внимания: глаз замыливается, человек устаёт, начинает ошибаться. Или задачи, когда объектов, за которыми нужно следить, слишком много — например, большое количество камер, необходимость точного подсчёта объектов, постоянный поток людей или техники.
Модель же не устаёт, не теряет концентрацию и не допускает накопленной ошибки. Поэтому в таких случаях CV — абсолютно оправданный подход.
Самое главное — начать разговор с бизнесом не с технологий. Не спрашивать: «почему вы хотите использовать компьютерное зрение», а спрашивать: «какую боль вы хотите устранить?». Какая проблема в вашем процессе мешает работать эффективнее, безопаснее или надёжнее? Что вы хотите улучшить и почему?
Пример из практики:
Делал кейс для крупной металлургической компании, которая обратилась за решением. Мы выехали к ним на производство, провели аудит и осмотр. Речь шла о длинной (больше 50 метров) вращающейся печи. Задача заключалась в том, чтобы установить вдоль печи тепловизионные камеры, которые будут отслеживать тепловую карту стенок и выявлять аномалии. Одна из камер должна была быть установлена внутри печи и требовала специальной системы воздушного и водяного охлаждения. Здесь всё было понятно: зачем нужна система, какова боль, как её решать. В итоге оказалось, что похожие решения есть на рынке, но компании была нужна отечественная разработка. Это абсолютно оправданный CV-кейс.
В другом случае заказчик пришёл с задачей, которую можно было легко решить человеком. Она была нечастой, не требовала высокой скорости или точности, и при этом полностью укладывалась в человеческий рабочий процесс. Мы честно попытались отговорить заказчика от внедрения CV. Не всегда это получается — но всегда стоит попробовать.
Этап 2. Анализ требований и бизнес-метрик
После того как сформулирована проблема, которую необходимо решать, следующий шаг — разобраться, как именно модель будет использоваться и какие требования предъявляет к ней бизнес. Это критично: нельзя просто «обучить хорошую модель» в вакууме — нужно заранее понимать, какую архитектуру строим, откуда берём данные, как отдаём результаты, и что именно считается «успешной» работой системы.
На этом этапе стоит наметить предполагаемую архитектуру: какие технологии будем использовать, как будет организован сбор данных (например, RTSP-потоки, видеоархивы, API), в каком формате будут передаваться предсказания, будет ли система работать в real-time или в пакетном режиме, где развёртывается — в облаке, на edge-устройстве или в закрытом контуре. Эти детали сильно влияют на выбор инструментов и на сам способ обучения модели.
Важно также понимать, что бизнесу чаще всего не нужна сама модель. Ему нужны ответы. А они — это уже продукт работы модели: например, триггерные события, визуальные отчёты, обновлённая статистика, сигнал тревоги или просто запись в лог. Отсюда — частота обновлений, SLA, форматы вывода, требования к воспроизводимости результат. Всё это надо выяснить до начала разработки, иначе решение может оказаться формально «работающим», но практически бесполезным.
Отдельно нужно проговорить метрики качества. Не с позиции ML-инженера, а с точки зрения пользы для бизнеса. Метрик десятки: precision, recall, F1-score — но какая из них важна, зависит от задачи. Например, в медицине гораздо важнее не пропустить случай заболевания, чем ошибочно выдать предупреждение. Поэтому приоритет отдаётся высокой чувствительности (recall): модель должна «перебдеть», даже если это даст больше ложноположительных результатов. В других задачах, наоборот, важна точность (precision) — например, при запуске автоматических действий или штрафов.
Здесь главное — не навязывать ML-термины, а говорить на языке бизнес-процесса:
• Что случится, если модель ошибётся?
• Что важнее: не пропустить или не дать лишнюю тревогу?
• Нужно ли подтверждение человеком?
• Какие действия запускает результат?
Так формируется не просто модель, а решение. И чем точнее на этом этапе заданы ожидания, тем меньше разочарований будет потом — и у заказчика, и у команды.
Этап 3. Сбор и подготовка данных
Подготовка данных — самый важный и самый трудоёмкий этап. Чем чище, разнообразнее, точнее и релевантнее данные, тем стабильнее будет работать модель.
«Мусор на входе — мусор на выходе» — это не метафора, а технический факт, проверенный десятками проектов и бессонными ночами за валидацией разметки :)
Объём и сложность сбора данных напрямую зависят от типа задачи. Если задача узкоспециализированная и работает в фиксированных условиях — например, одна камера с одним ракурсом — задача проще. В других случаях придётся собирать данные из разных ракурсов, при разных условиях освещения, на разных типах камер.
Источники данных для обучения и проверки могут быть любыми:
• RTSP-потоки с камер
• видеоархивы
• скриншоты
• открытые датасеты
• собственные парсеры и тд
Сбор и подготовку данных можно автоматизировать. Обычно с этим нет проблем, если поток видео стабилен и известен формат. Однако перед обучением важно выявить дисбаланс классов: например, если большинство изображений — только с одним типом объектов. Это решается дополнительной разметкой недостающих классов или аугментацией данных.
Нужно выбрать тип (или группу) CV-задач:
• object detection
• сегментация
• классификация
• OCR
• поза
• трекинг и т. д.
Под каждую категорию подбирается соответствующий тип модели и разметки.
Пример
Задача отличать мужчин от женщин. Это, казалось бы, простая классификация. Но на практике удобнее сначала размечать общий класс «человек», а потом уже классифицировать по полу. Также важно учитывать анти-классы — объекты, которые похожи на целевые, но не являются ими.
Антикласс — это вспомогательный класс в обучающем датасете, который представляет объекты, визуально или контекстно схожие с целевыми, но не относящиеся к ним. Он вводится для того, чтобы снизить количество ложноположительных срабатываний модели. По сути, антикласс помогает модели научиться не путать «похожее» с «целевым» и лучше различать между ними на уровне признаков. Технически антиклассы размечаются так же, как обычные классы, но при инференсе они могут скрываться или агрегироваться в отдельный негативный класс.
Если задача типовая (одна камера, один цех, фиксированный ракурс, одинаковые объекты) — достаточно 2000–3000 примеров. Если же нужно определять, например, кошку на изображениях с разных камер и ракурсов — придётся собирать сотни тысяч разноплановых снимков, чтобы добиться обобщающей способности модели. Однако рост точности при увеличении датасета — не линейный: после определённого объёма вклад новых резко снижается.
Чтобы сократить расходы и повысить устойчивость модели, используют аугментацию (геометрические, цветовые, шумы, искажения и т.д.). Объем и набор дополнительной аугментации может варьироваться от проекта к проекту и зависит от количества и разнообразия исходных данных и размера модели. Важно, чтобы аугментация не плодила однотипные кадры (в этом нет смысла), а давала новую информацию. На практике мы чаще всего используем аугментацию датасета в 5-10 раз, но все индивидуально.
Важно визуально проверять какие данные получились после увеличения датасета, иногда бывает ситуация, когда неправильная аугментация полностью убивает модель. Например, у нас был случай, когда из-за параметра аугментации erasing (случайное перекрытие кусочка кадра черным прямоугольником) на части изображений перекрылся полностью целевой объект и модель классификации начала путать его с фоном.
Также в ряде случаев эффективны синтетические данные: либо полностью сгенерированные сцены, либо докомпоновка реальных изображений (например, наложение объектов на разнообразный фон). Это особенно актуально, когда собрать реальные данные сложно или дорого. Из общей практики не рекомендую злоупотреблять синтетикой, но и недооценивать ее вклад не стоит.
Стоимость разметки зависит от задачи, количества и сложность классов, среднего количества объектов на кадре и размеров целевых объектов. Можно выделить три самых популярных типа аннотации в компьютерном зрении, выбор которой также влияет на итоговую стоимость разметки.
Bounding box — это способ разметки, при котором объект на изображении обводится прямоугольником. Такой прямоугольник задаётся координатами центра (или угла) и размерами по ширине и высоте. Этот тип аннотации широко используется в задачах object detection, например, в таких моделях как YOLO или Faster R-CNN. Он даёт приблизительное положение объекта в кадре, но не захватывает точную форму. Его основное преимущество — простота и высокая скорость разметки: достаточно кликнуть две точки. Однако он плохо подходит, если объекты перекрываются или имеют сложную форму. Средняя цена за бокс сейчас порядка 2–3 рублей.
Сегментация (маска) предполагает, что аннотатор закрашивает или выделяет каждый пиксель, принадлежащий объекту. Такой тип разметки используется в задачах семантической или инстанс-сегментации. Он позволяет точно определить форму и границы объекта, что особенно важно в медицине, дефектоскопии, дорожной разметке и других областях, где критично точное позиционирование. Чаще всего используют SAM2 которая умеет выделять границы объектов и очень упрощает разметку. Средняя цена на такую разметку порядка 5-8 рублей.
Оценка позы (pose estimation) — это разметка, при которой для объекта указываются ключевые точки. В случае человека это могут быть суставы: локти, колени, плечи, голова и т.д. Каждая точка имеет координаты (x, y), и они вместе образуют скелетную структуру. Такой тип разметки используется в задачах анализа движений, биомеханике, видеоаналитике поведения и т.п. Примеры моделей — OpenPose. Это дорогая и трудоёмкая разметка, так как требует точного позиционирования десятков точек вручную, и используется реже других. Средняя цена за оценку позы человека (17 точек) порядка 10-15 рублей.
Лайфхак
Если задачка типовая (например, определение человека) можно использовать предварительно обученные модели для автоматической разметки и потом корректировать ее в ручную – так получается существенно быстрее, а значит дешевле.
Итог:
• Bounding box — подходит почти для любых объектов, быстро размечается.
• Маска — нужна, когда важна точная форма (медицина, дефекты, дороги).
• Поза — применяется в узких задачах, где нужно анализировать структуру или движение.
Кстати, заметили в чем ошибка? Картинку выше рисовал с помощью нейросетки. И разметку она нарисовала неправильную. Bounding Box должен полностью вмещать объект внутри, а у этого торчит пятка. Да и к позе есть вопросы… Такие неточности могут привести к ухудшению качества модели.
А вот еще живой пример разметки из Roboflow:
Стоимость разметки определяется временем, которое тратит аннотатор на один объект. Чем мельче объекты, чем больше классов и перекрытий, тем дороже разметка.
Из инструментов. Мы часто используем CVAT, потому что его можно развернуть локально, в изолированной инфраструктуре заказчика, без доступа к интернету и сторонним API. Это критично в проектах с NDA, ограничениями на передачу данных и высокими требованиями к безопасности: например, в госсекторе, на объектах критической инфраструктуры, в промышленности, транспорте или при работе с персональными данными. В отличие от облачных решений, таких как Roboflow, позволяет гарантировать, что всё, и изображения, и разметка, остаётся строго внутри периметра заказчика.
Этап 4. Обучение модели и первые эксперименты
После подготовки данных начинается фаза экспериментов. На этом этапе важно не строить идеальную модель с первого раза, а протестировать гипотезу: работает ли идея вообще?
Рекомендуется начинать с маленьких моделей. Они требуют меньше данных, обучаются быстрее. Достаточно разметить 1000 кадров, посмотреть на метрики, понять, есть ли динамика. Если есть — масштабируем датасет, дорабатываем архитектуру, настраиваем гиперпараметры подбираем размер модели.
Обучение — итеративный процесс. Можно менять аугментации, расширять классы, играться с параметрами, делать предварительную обработку и тд. Модель можно «дотягивать» и логикой на этапе постобработки — если не хватает точности.
Производительность зависит от модели. Маленькую модель можно обучить на ноутбуке с RTX 3060: одна эпоха — займет минут 10. Большие модели (например, 3 млн. примеров) могут обучаться по 25 дней на четырёх A100 (180 ГБ). Это дорого, но иногда необходимо.
Следующий важный момент — воспроизводимость. Даже если вы зафиксировали random seed, результат может немного отличаться от запуска к запуску. Это связано с тем, что сетки работают на вероятностных механизмах, и даже одинаковые входные данные могут дать чуть разные выходы. Это нормально и не должно пугать. Но это можно контролировать по мере необходимости, изменяя архитектуру и функцию потерь.
Этап 5. Интеграция, инфраструктура и вывод в прод
После того как модель обучена и протестирована, наступает критически важный этап — организация всей инфраструктурной обвязки и интеграция в продакшн-среду. Это не просто «вывод модели», а построение всей цепочки, через которую она будет стабильно и воспроизводимо работать.
Первое — необходимо организовать приём входных данных. Это может быть поток с камер (видеострим), отдельные кадры или статичные изображения. Нужно продумать, откуда и как данные поступают: с какой периодичностью, в каком формате, с каким уровнем буферизации. Важно обеспечить поддержку параллельной обработки — например, через очереди сообщений (RabbitMQ, Kafka) или асинхронные задачи.
Далее — инференс: как и где запускается модель, как обрабатываются кадры (в онлайне, батчами, по расписанию), используются ли несколько моделей одновременно (каскады), как сочетается логика между ними. Например, одна модель может детектировать человека, а вторая — оценивать его позу. Здесь уже появляется логика маршрутизации данных между компонентами.
Результаты инференса необходимо куда-то сохранять или отправлять — например, в базу данных, систему уведомлений или отчётности. Всё это нужно упаковать в инфраструктурное решение: чаще всего это контейнеры (Docker), orchestrated-среда (например, Kubernetes) или нативные инсталляции в инфраструктуре заказчика.
И только после того, как вся связка отлажена, можно переходить к настройке CI/CD пайплайна. Это отвечает за стабильные обновления: как выкатываются новые версии модели, как они валидируются перед продом, как откатываются в случае проблем.
Формат развёртывания зависит от среды:
• облако — чаще всего REST API или gRPC;
• edge-устройства — ONNX, RKNN и другие оптимизированные форматы;
• офлайн-контур — локальное развёртывание на серверах заказчика.
Наконец, обязательный компонент — мониторинг. Нужно отслеживать как технические метрики (нагрузка, задержки, OOM), так и поведение модели (статистика предсказаний, динамика по классам, частота срабатываний). Используются Grafana, Zabbix, Prometheus, кастомные панели и логи.
Важно понимать: сами модели не «устают» со временем, но после вывода модели в прод её жизненный цикл не заканчивается — начинается этап поддержки. Даже если модель хорошо работает при запуске, внешние условия со временем могут измениться. Появляется новый тип объектов (например, белые каски вместо красных), меняется освещение, сцена перестраивается. Всё это может привести к ухудшению качества распознавания, особенно если модель не была обучена на таких условиях.
Поэтому раз в полгода или год рекомендуется собирать небольшой тестовый набор данных — свежих, из актуальной рабочей среды. Этот набор размечается по тем же правилам, что и изначальный, и используется для повторной валидации модели. Если качество просело — нужно принять решение: дообучить модель на новых примерах, переобучить полностью, либо ввести изменения на этапе препроцессинга (например, перевод изображения в ЧБ, чтобы исключить зависимость от цвета).
Если вы работаете в этой области — скорее всего, многое из описанного вы и так знаете. Эта статья — чтобы свериться, вспомнить, где обычно «сыпется» пайплайн, и как выстроить CV/ML-проект без лишних недосказанностей, пересборок и выгоревшей команды.
Такой материал удобно использовать как опору — для планирования, для обсуждения с командой или заказчиком, чтобы не упустить что-то важное. Если вы только начинаете — пусть это будет базовая карта: на какие этапы смотреть, какие вопросы задавать, где обычно возникают сложности, и что действительно критично.
Больше про ИИ-проекты, технологии, свою экспертизу пишу на канале
