За последние годы мы провели довольно много пилотных проектов по компьютерному зрению на разных производствах. И со временем мы перестали считать, что успех пилота в первую очередь зависит от качества нейросети. Гораздо чаще результат определяет то, насколько грамотно организован сам процесс запуска.
Двухнедельный пилот — это не про то, чтобы за 14 дней сделать готовое промышленное решение. Это инструмент, который позволяет относительно быстро понять, есть ли смысл двигаться дальше и что для этого потребуется.
Зачем нужен пилот и почему именно две недели
Многие заказчики до сих пор воспринимают пилот как уменьшенную версию внедрения. От него сразу ждут высокой точности, удобного интерфейса и глубокой интеграции. Такой подход обычно приводит к тому, что пилот превращается в долгий и дорогой проект, который не даёт нужной ясности.
На наш взгляд, главная задача пилота — снизить неопределённость. За две недели почти никогда не удаётся довести систему до промышленного уровня. Зато можно получить ответы на важные вопросы:
- Реально ли решить задачу в существующих производственных условиях
- Какие основные сложности скорее всего возникнут при полномасштабном внедрении
- Какие доработки и ресурсы потребуются
- Есть ли смысл продолжать работу в выбранном направлении
Бывает и так, что уже по итогам пилота становится понятно — задача в текущих условиях решается плохо. Это тоже полезный результат. Он позволяет не вкладывать значительные средства в проект, который с высокой вероятностью не оправдает ожиданий.
Что чаще всего создаёт проблемы в начале
Одна из самых частых сложностей — это недостаточно чёткая постановка задачи на старте. Приходят с формулировкой «хотим контролировать качество» и только в процессе выясняется, что дефектов много, они разные по характеру, а требования к скорости и точности при этом довольно жёсткие.
Ещё одна распространённая ситуация — когда данные, которые предоставляют до начала работ, заметно отличаются от реальной картины на производстве. Освещение, ракурсы, типы дефектов — всё это может сильно различаться. Поэтому в первые дни мы почти всегда стараемся побывать на участке и собрать данные уже на месте.
Как мы обычно организуем работу на две недели
Первая неделя в основном уходит на понимание задачи и данных.
В первые два-три дня мы стараемся максимально быстро установить камеры и начать собирать материал. Не гонимся сразу за идеальным качеством изображения. Важнее понять, с чем предстоит работать. Часто уже на этом этапе становится видно, какие дефекты будут сложными для распознавания, а какие — относительно очевидными.
Дальше важно посмотреть на данные вместе со специалистами заказчика. То, что для нас выглядит как явный брак, для технолога может быть в пределах допуска. Без такого совместного анализа легко уйти не в ту сторону.
К концу первой недели обычно удаётся получить базовое решение. Оно, как правило, работает неидеально, но уже позволяет понять основные источники ошибок и ограничения.
Вторая неделя в большей степени посвящена проверке в реальных условиях.
Самое важное здесь — это тестирование именно на работающей линии. Модель, которая хорошо показывает себя на заранее собранных фотографиях, часто начинает вести себя иначе, когда продукция движется с нормальной скоростью, меняется освещение или появляются новые ракурсы.
Именно на этом этапе обычно всплывают вещи, которые сложно было предвидеть заранее: вибрация оборудования, периодические изменения фона, влияние соседних участков и так далее.
Что чаще всего мешает уложиться в сроки
Если говорить откровенно, то основная причина, по которой пилоты затягиваются — это не технические сложности, а организационные вопросы.
Пока согласуют доступ на производство. Пока назначат ответственного. Пока разрешат установить оборудование. Пока дадут нормальный доступ к сети. Всё это может занимать значительное время.
Ещё одна частая проблема — когда на пилот пытаются нагрузить слишком много задач одновременно. Хотят и качество проверить, и интеграцию сделать, и отчёт красивый подготовить. В итоге не успевают нормально сделать даже основное.
Что мы считаем важным при проведении пилота
За время работы у нас сложилось несколько принципов, которых мы стараемся придерживаться:
- Не стоит гнаться за высокой точностью именно на этапе пилота. Гораздо важнее понять направление работы и ограничения. Точность в большинстве случаев можно поднять позже.
- Нужно быть готовым к тому, что пилот покажет не самые приятные результаты. Иногда задача в текущих условиях решается плохо, и это лучше признать сразу, чем пытаться «натянуть» результат.
- Очень важно, чтобы со стороны заказчика был человек, который действительно заинтересован в результате и может быстро отвечать на вопросы. Без этого даже технически успешный пилот часто не получает продолжения.
Выводы
Двухнедельный пилот — это не про быстрые чудеса и не про готовые промышленные решения. Это способ относительно недорого и быстро получить достаточно информации, чтобы принять осознанное решение о дальнейшем развитии проекта.
На наш взгляд, главная ценность такого пилота не в финальной точности модели, а в том, насколько чётко после него становится понятно, что делать дальше. Иногда это приводит к решению продолжать работу. Иногда — к тому, чтобы скорректировать подход или остановиться.
И то, и другое можно считать нормальным итогом. Главное, чтобы после пилота у всех участников было примерно одинаковое понимание ситуации и перспектив.
Об авторе
Статья подготовлена на основе практического опыта компании ИТиС ЛАБ, которая занимается внедрением систем компьютерного зрения и видеоаналитики на промышленных предприятиях.
lab-itis.ru
t.me/itis_lab