Запуск проекта с искусственным интеллектом часто воспринимается как финишная черта. Модель обучена, тесты пройдены, ИИ-система интегрирована в бизнес-процессы. Однако в реальности это лишь старт. Рынок меняется, появляются новые сценарии использования, а реальный мир неизбежно вносит свои коррективы в идеальные условия «лабораторных» датасетов. Именно здесь начинается самый важный и не всегда очевидный этап — поддержка и итеративное развитие модели с точки зрения данных.

В этой статье мы раскроем, что происходит с моделью после релиза, как бизнес принимает решение о необходимости её «прокачки» и почему работа с данными — важный аспект любого ИИ-проекта.

Жизненный цикл ML-модели: от эйфории к суровой реальности

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

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

• Эксплуатация и сбор метрик. Система работает в реальных условиях, а бизнес отслеживает её ключевые показатели эффективности (KPI): точность, количество ложных срабатываний, полноту детекции и, в конечном счёте, влияние на бизнес-процессы (например, снижение числа инцидентов).
• Анализ и выявление «слепых зон». Раз в месяц или квартал команда анализирует собранные метрики. Если точность падает или появляются систематические ошибки в определенных сценариях, это сигнал — модель нуждается в доработке.
• Формулирование гипотезы. Проблема не решается простым «улучшением модели». Сначала выдвигается гипотеза, связанная с данными. Например: «Модель ошибается, потому что не "видела" погрузчики ночью под дождём. Если мы добавим 2000 таких изображений в датасет и переобучим модель, точность в этих условиях вырастет на 15%».
• Сбор и подготовка нового датасета. На этом этапе снова возникает задача по сбору, разметке и валидации данных. Это может быть как доразметка существующих архивов, так и сбор абсолютно новых материалов для проверки гипотезы.
• Дообучение и тестирование. Модель дообучается на расширенном датасете, после чего проходит строгую проверку, чтобы убедиться, что новые знания не «сломали» её умение работать со старыми сценариями.
  Этот цикл повторяется снова и снова, превращая ИИ-проект из статичного продукта в развивающийся сервис.

Кейс: как обеспечить стабильную работу ML-модели в динамичной среде

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

Этап 1: Первоначальное обучение и первые сложности

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

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

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

Этап 2: Методология тестирования как основа для улучшений

Чтобы процесс доработки был управляемым, мы разработали строгую методологию тестирования. Из 720 часов архивных записей и специально созданных синтетических сценариев мы отобрали 1000 эталонных кадров. Этот «золотой» датасет был тщательно сбалансирован по:

• Времени суток: утро, день, вечер, ночь.
• Погодным условиям: сухо, дождь, туман.
• Типам препятствий: 7 классов, включая статичные и динамические объекты.

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

Этап 3: Проверка в «бою»

Самые ценные инсайты дало подключение к объекту в реальном времени. Мы провели тесты непосредственно в рабочей зоне, организуя интерактивные сценарии во всех сменах (утро, день, вечер, ночь). Это позволило охватить разные уровни освещения, рабочей загруженности и проверить, как система реагирует на реальное поведение людей и техники. Практическая проверка дала немедленный результат: уже в первые сутки тестов количество конфликтных ситуаций между людьми и техникой снизилось на 10%.

Почему не стоит менять подрядчика по разметке данных?

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

1. Потеря контекста. Подрядчик, который работал над проектом с самого начала, уже погружён в его специфику. Команда знает техническое задание (ТЗ), понимает нюансы классов, сталкивалась с пограничными случаями и знает, как их правильно интерпретировать. Новому подрядчику придётся изучать всё с нуля, что неизбежно приведёт к ошибкам и затянет сроки.
2. Скрытые затраты. Экономия на часовой ставке разметчика может обернуться дополнительными расходами на менеджмент, исправление ошибок и повторную валидацию данных. Время, потраченное на онбординг новой команды — это тоже деньги.
3. Операционная выгода. Для клиента, у которого нет штата собственных разметчиков, работа с проверенным партнёром в проектном формате — это прямая операционная выгода. Не нужно нанимать людей, обучать их и обеспечивать загрузкой. Вы просто обращаетесь к внешней команде, когда это необходимо, и получаете предсказуемый результат.

Держать проверенного партнёра по работе с данными «на карандаше» — это не просто удобно, это стратегически верное решение, которое экономит ресурсы и снижает риски в долгосрочной перспективе.

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

Нужна качественная разметка данных с прозрачной оценкой?

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

[Получите бесплатный расчет стоимости вашего проекта в NeuroCore]