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