Технический директор BPA Вадим Медяник принял участие в отраслевом вечере «Где ИИксы?» в кластере «Ломоносов». Рассказываем, как заказчику оценить ИИ-проект, систему компьютерного зрения или видеоаналитику до внедрения.
На площадке собрались технологические предприниматели, инвесторы и AI-команды, чтобы обсудить, как инструменты искусственного интеллекта меняют разработку продуктов, ускоряют команды и какие проекты действительно могут вырасти в устойчивый бизнес.
Один из важных вопросов дискуссии: как отличить сильный AI-проект от продукта, где ИИ добавлен скорее для презентации?
Для заказчика это не абстрактный вопрос. Сегодня почти любая технологическая компания может показать демо: распознавание объектов на видео, чат-бота, генерацию текста, интерфейс с красивыми графиками. Но между демонстрацией и рабочим внедрением ИИ в бизнес есть большая дистанция.
Зрелая команда спокойно рассказывает не только о том, что система умеет распознавать, но и о том, в каких условиях качество модели может снижаться. Это не означает, что решение будет работать нестабильно. Наоборот, такой анализ нужен, чтобы заранее учесть реальные условия объектаа. Без такой доработки модель, хорошо показавшая себя в тесте или демо, часто не готова к промышленной эксплуатации.
Такое понимаеи критично для компьютерного зрения и видеоаналитики. На реальном объекте почти всегда есть факторы, которые влияют на качество работы модели: тени, засветы, плохие ракурсы, загрязненная камера, нестандартная спецодежда, частично перекрытые объекты, нестабильный видеопоток, изменение освещения в течение дня.
Если эти сценарии не обсуждаются на старте, значит проект, скорее всего, еще не дошел до уровня промышленного внедрения. В рабочем ИИ-решении важно заранее определить, какие условия считаются штатными, какие требуют дообучения модели, а какие нужно выносить в отдельную логику обработки.
Например, в системе компьютерного зрения для стройки нужно заранее понимать, как модель будет различать каску при частичном перекрытии, плохом ракурсе или загрязненной камере. В видеоаналитике на складе — как отличать простой техники от нормальной технологической паузы. На производстве — как система будет реагировать на нестандартное положение изделия, изменение освещения или появление нового типа дефекта. В транспортной инфраструктуре — как обрабатывать ночные сцены, засветы фар, плотный поток и частично перекрытые объекты. Именно такие детали показывают, готово ли ИИ-решение к эксплуатации
В сильном ИИ-проекте данные не появляются «сами» и не сводятся к нескольким удачным примерам для демонстрации. Для рабочей системы важно собрать данные, которые действительно похожи на условия будущей эксплуатации: с тех же камер, с похожими ракурсами, освещением, сезонностью, типами объектов, помехами и нестандартными ситуациями.
После этого начинается отдельный инженерный этап: данные нужно отфильтровать, разметить, проверить разметку, убрать дубли и нерелевантные кадры, отдельно разобрать редкие и спорные случаи. Для компьютерного зрения это особенно важно, потому что модель учится не на абстрактной задаче, а на конкретной визуальной среде. Одна и та же каска, техника, труба, паллета или дефект могут выглядеть по-разному в зависимости от камеры, расстояния, угла обзора и условий съемки.
Поэтому иногда работа с данными занимает больше времени, чем выбор архитектуры нейросети. Сама модель может быть достаточно стандартной, но качество результата будет определяться тем, насколько правильно собрана обучающая выборка, как учтены пограничные случаи и как система дообучается после первых тестов на объекте.
Для заказчика это важный маркер. Если подрядчик показывает интерфейс, но не может объяснить, на каких данных тестировалась модель компьютерного зрения, как формировалась выборка, что считалось ошибкой, какие классы объектов размечались и как будут обрабатываться ложные срабатывания, риски внедрения резко возрастают.
В реальном проекте вопрос данных должен обсуждаться так же подробно, как сроки, стоимость и функциональность. Именно по данным обычно видно, можно ли масштабировать решение на несколько объектов или оно хорошо работает только в рамках одной демонстрации.
Третий признак — наличие инженерной части.
На практике ИИ-решение должно работать не отдельно от объекта, а внутри инфраструктуры заказчика: подключаться к существующим камерам, получать видеопотоки, обрабатывать их с нужной задержкой, отправлять события в интерфейс или внешние системы, хранить результаты, выдерживать сбои связи и не требовать постоянного ручного контроля со стороны разработчиков.
Для интеллектуальной видеоаналитики это один из ключевых этапов. Сама модель может корректно определять объект или событие на тестовых данных, но в реальной эксплуатации появляется много технических ограничений: пропускная способность сети, качество RTSP-потоков, нагрузка на сервер видеоаналитики, требования к хранению архива, права доступа, интеграция с VMS, СКУД, ERP, BI-системами или внутренними сервисами заказчика.
Отдельно нужно понимать, где будет выполняться обработка: на локальном сервере, edge-устройстве, в контуре заказчика или в облаке. От этого зависят скорость реакции, стоимость инфраструктуры, требования к безопасности данных и возможность масштабирования системы на несколько объектов.
Поэтому при внедрении видеоаналитики важно обсуждать всю цепочку эксплуатации.
Еще один важный момент — метрики эффективности. До начала проекта нужно понимать, что именно считается результатом и как этот результат будет измеряться в реальном процессе заказчика.
Для ИИ-решения недостаточно зафиксировать общую точность модели в процентах. В прикладной видеоаналитике важнее понять, какую операционную задачу система должна закрыть: снизить объем ручного контроля, сократить простой техники, уменьшить количество нарушений, ускорить реакцию на событие, повысить прозрачность процессов или дать руководителю объективные данные для управленческих решений.
Отдельно нужно заранее определить технические и бизнес-метрики.
Например, для видеоаналитики на производстве важны не только показатели распознавания. Нужно понимать, сколько событий система корректно фиксирует за смену, как быстро оператор получает уведомление, какие инциденты требуют немедленной реакции, какие могут уходить в отчетность, а какие должны использоваться для анализа процессов за период.
То же самое касается систем компьютерного зрения на складе, стройке или промышленном объекте. Если система фиксирует нарушение, простой техники или отклонение от регламента, важно заранее определить, что происходит дальше: событие попадает в журнал, отправляется ответственному сотруднику, подтверждается оператором, попадает в BI-отчет или используется для корректировки внутренних процессов.
Без таких метрик внедрение ИИ легко превращается в техническую демонстрацию без понятной бизнес-ценности.
Готовые модели и AI-инструменты хорошо ускоряют разработку, но в прикладных проектах они закрывают только часть задачи. Особенно если речь идет о компьютерном зрении, видеоаналитике, промышленной безопасности, контроле качества или мониторинге процессов на реальном объекте.
Причина в том, что готовая модель обычно обучалась на обобщенных данных и не знает контекст конкретной площадки. Она может распознавать людей, технику, предметы или дефекты в типовых условиях, но не учитывать ракурсы камер заказчика, особенности освещения, регламенты работы, типы спецодежды, расположение зон, качество видеопотока, ограничения сети и то, что именно для бизнеса считается значимым событием.
В BPA такие проекты часто находятся на стыке машинного обучения, НИОКР, инженерных изысканий и внедрения. Здесь недостаточно собрать прототип на готовом инструменте. Нужно разобраться в объекте, понять ограничения инфраструктуры, проверить гипотезы на реальных данных, адаптировать модель под условия площадки и связать результат с понятной пользой для бизнеса.
Именно поэтому ИИ-консалтинг в таких проектах — это разбор процесса заказчика. Для клиента это хороший фильтр при выборе подрядчика по внедрению ИИ в бизнес под ключ. Стоит смотреть не только на интерфейс и заявленную точность, а на более практичные вещи:
Если команда может подробно ответить на эти вопросы, перед заказчиком, скорее всего, не просто демо, а разработчик, который понимает путь от модели до работающей системы.
