Привет читатели.
Эту статью я пытался написать уже несколько раз, но каждый раз откладывал, так как при мысли о необходимости провести глубокое размышление над накопленным опытом меня охватывало уныние и печаль.
Однако я стал более решительным сделать это, чтобы поделиться своим опытом с теми из вас, кто планирует сделать что-то подобное в области ИИ.
Все описанное ниже относится к весьма специфической сфере деятельности: ИИ с точки зрения компьютерного зрения.
Отказ от ответственности : Я не эксперт в нейросетях, но исполняю роль владельца продукта, в котором ключевую роль играют нейросетевые модели компьютерного зрения.
Эта статья для тех, кто вынужден выполнять одну и ту же работу, а также для тех специалистов по ML, которые хотят понять, как люди со стороны бизнеса видят их деятельность.
Итак, мы делаем продукт на основе компьютерного зрения, включающий обнаружение, отслеживание, идентификацию, переидентификацию людей, определение их пола и возраста.
Мы уже давно делаем разные проекты, в том числе и с элементами ML, но впервые делаем проект, где эта часть занимает центральное место.
За это время, будучи владельцем продукта, я узнал много нового, странного и сформулировал некоторые принципы, важные для достижения успеха при создании таких продуктов.
Риск в продуктах искусственного интеллекта
Риск колоссальный.На самом деле создание продукта ИИ фактически заканчивается, когда все риски устранены.
Если в случае создания продуктов с использованием классических алгоритмов вы тратите от 5 до 20% своего времени на работу с риском, то в случае с продуктами ИИ сам процесс создания продукта — это борьба с риском.
По моим оценкам, время, затрачиваемое на борьбу с рисками, составляет 90–95 % времени с момента создания продукта ИИ.
Из этого наблюдения следуют важные выводы.
Для пищевых компаний
График доставки, а значит и стоимость, скорее всего, будет пропущен много раз, с чем мы и столкнулись.Риск настолько велик, что делать что-то над продуктом до того, как AI-часть будет завершена, протестирована и доставлена, не имеет смысла.
Для подрядчиков
Клиентов в области разработки продуктов искусственного интеллекта в сегменте малого и среднего бизнеса будет мало или вообще не будет. Если вы не можете «зайти» в условный Тинькофф, можете закрыть магазин, хорошего бизнеса не будет. Государство – наиболее вероятный и выгодный клиент. Лучше сосредоточиться на разработке конвейера для решения конкретных задач и предлагать услуги на его основе, чем браться за что-либо в области компьютерного зрения.Тогда вы будете делать стандартные инжиниринговые проекты для клиентов, а не проекты в духе «дайте нам денег, чтобы мы поняли, что это вообще можно сделать».
Для менеджеров
Не соглашайтесь работать над подсистемами ИИ, используя Scrum или другие методологии, с фиксированными сроками продвижения.Мне кажется, Agile не подходит для создания подсистем, использующих ИИ, потому что при его использовании вы будете двигаться в ритме «3 шага вперед, затем 2 назад» с непредсказуемыми сроками сдачи функционала.
Вы не можете доверять никому
Практически все опубликованные материалы о работе моделей не подлежат проверке или получены на нелепых наборах данных.Мы неоднократно сталкиваемся с тем, что научные статьи, описывающие те или иные подходы, грешат искажением фактов и выдачей желаемого за действительное.
Из недавних диалогов с тимлидом: Контекст: YOLOv4 — самая точная нейронная сеть реального времени в наборе данных Microsoft COCO.
Я: почему мы тестируем нейросеть Yolo4 в сравнении с Yolo3; ТЛ: Потому что мы не доверяем создателю модели, даже если он наш соотечественник.В результате, по нашим данным, Y3 местами превосходит Y4, являясь более предпочтительным.
Необходимость все проверять приводит к очень медленному прогрессу в доставке продукции.
Четко документируйте условия труда
Для ML-инженера это не открытие, но вы вряд ли услышите от него это вслух.Идея очень проста и вытекает из природы обучения моделей нейронных сетей: выбрать/обучить модель, которая будет работать в фиксированных условиях, во много раз проще, чем создать модель, которая будет работать в широком диапазоне условий.
.
Простыми словами .
Представьте, что вы делаете конвейеры для куриных яиц.
Хотите поставить на конвейер камеру, чтобы она могла обнаруживать бракованные яйца, цвет, размер, да что угодно.
Вы поручаете отделу ML решить эту проблему для вашего конвейера, для определенной модели камеры, в определенном месте ее установки, при определенном освещении.
С большой долей вероятности проблема будет успешно решена.
А теперь представьте, что вы делаете программное обеспечение для подсчета яиц, которое владельцы конвейеров могут устанавливать по своему усмотрению в неизвестных условиях, на неизвестном расстоянии от ленты, неизвестных моделях камер.
Этот проект гораздо сложнее и в целом, скорее всего, обречен на провал.
Возможно, для вас это будет открытием (как и для меня), но мировоззрение и кругозор инженеров в области ML формируются именно на задачах первого типа.
Задачи второго типа требуют от исполнителя четкой связи с деловой реальностью, постоянного прокручивания в голове различных кейсов и их влияния на модель.
Это доступно немногим; не стоит ожидать этого от всех специалистов.
Используйте метод взгляда для оценки
Метод взгляда заключается в том, что вы, как владелец продукта, смотрите на результат и говорите — ОК или не ОК.Прежде всего, таким образом потребуйте подтверждения функциональности ваших данных.
Если вы не будете требовать доказательств работы таким образом, вы с меньшей вероятностью будете верить в то, что продукт работает самостоятельно, и вам будет еще труднее убедить своих клиентов в том, что он работает. Отличные статистические показатели ценны в первую очередь для самих инженеров, чтобы постоянно понимать, как изменения влияют на результат. Помните, что модель с отличными Precision, Recall, F1 и т. д. при тестировании методом взгляда может сильно разочаровать.
В целом понятно, что хочется сразу 99,99% всего, но зачастую визуальное подтверждение правильности дает гораздо большую степень уверенности и вдохновляет людей, спонсирующих разработку, чем красивые цифры, которые при практическом рассмотрении дадут неоднозначные результаты.
Устраните разрыв с бизнес-требованиями
Большинство нейронных сетей требуют, чтобы изображение имело очень определенное разрешение перед подачей в него.Самый простой вариант, который используется на практике – это приведение исходного изображения к желаемому.
Часто это не является проблемой, но для одиночных детекторов такая операция может быть вообще недопустима.
Ситуация .
Допустим, вы хотите обработать видеопоток в реальном времени с помощью Yolo4. Поставьте задачу инженеру - дайте мне конвейер 60 FPS на Tesla T4. Он выберет размер сетки 416x416 и изменит размер видео с исходного размера на этот, показывая вам, что все работает с заданным FPS. В которой, очевидно что Yolo4 имеет минимальный размер пикселей людей, которых он четко идентифицирует ( К вашему сведению : это ~15% высоты кадра (около 110 пикселей для 720p).
Все люди ниже этого роста будут обнаружены с низким качеством.
Этот вопрос, скорее всего, останется за кадром, если его никто не поднимет в повестке дня.
О важности этого аспекта я узнал в примере ниже.
Нормальный человек думает так: чем выше разрешение видео, тем больше важных деталей и тем лучше все будет работать .
В случае шаблонного стандартного подхода с использованием детекторов одиночных снимков в ML это не так — вообще не имеет значения, какое разрешение вы подадите, так как ваш кадр просто уменьшится до размера входных данных нейронной сети, и вы не получит никаких льгот. Здесь наблюдается явное противоречие между ожиданиями бизнеса и технологическими возможностями.
Самое странное, что я видел, выглядело так:
- целевое видео было отмечено для обнаружения людей;
- это видео было передано в две нейросети Yolo4 размером 320x320, 416x416;
- были получены разные результаты и спокойно записаны в таблицу.
- разметить видео;
- определить порог размера человеческой фигуры, которую может видеть нейронная сеть;
- выполнить масштабирование видео в целевых разрешениях нейронной сети;
- убрать из разметки те цифры, которые стали меньше порога обнаружения;
- провести бенчмарки.
Достичь общения на человеческом языке
Я в IT уже 15 лет, умею программировать на нескольких языках, хорошо знаю железо.Однако каждый раз, когда я общаюсь с отделом ML, самая распространенная фраза, которую я говорю: «Я не понимаю, объясните, пожалуйста, яснее».
Мне не обидно говорить это столько, сколько необходимо, иначе меня просто завалят сверхсложными, конкретными вещами с кучей подробностей, под которыми исчезнет свет истины.
У нас есть прецеденты, когда специалисты из BigData или Backend не могут найти общий язык с людьми из ML, поскольку не все могут и хотят заставить людей общаться на понятном языке.
В общем, используйте «Я не понимаю», когда вам это удобно.
Я вообще часто пользуюсь.
Если мне начинают говорить что-то с точки зрения инструмента исполнителя, я пытаюсь перевести рассуждения в область логического мышления за пределы конкретной области знаний исполнителя, чтобы оценить разумность.
Как только исполнитель начинает говорить о реализации в рамках своего инструмента, это красный флажок для обсуждения задачи.
Если вы, как руководитель, не можете добиться, чтобы ваши специалисты по ML объяснили вам все на понятном вам языке, я думаю, вам следует немедленно сменить работу или своих специалистов.
Инструменты для продуктивного вывода - Terra Incognita
Если вам нужно, чтобы оно быстро работало на платформе Nvidia, вам нужно обратиться в Nvidia DeepStream или аналогичные фреймворки.Однако через DeepStream это точно будет быстрее всего.
Из моего разговора с представителем Nvidia Inception, они настолько заинтересованы в том, чтобы кто-то сделал и продемонстрировал практические кейсы на DeepStream, что кажется, что это не под силу практически никому.
При этом переход от «Работает на PyTorch» к «Работает на DeepStream» — это отдельный большой и сложный проект, который может потребовать как написания чего-то нетривиального на C для расширения Gstreamer, так и изменения моделей, поскольку они, для Например, несовместимы с TensorRT. Отладка приложений в самом DeepStream — это тоже отдельная история, включающая регулярную борьбу с Segmentation Fault, даже если вы программируете на Python с помощью NumPy, а сама отладка весьма нетривиальна из-за архитектуры Gstreamer. Но если вам нужен максимально быстрый вывод на Nvidia, это один из немногих способов добиться эффективного использования ускорителей.
Мне кажется, скоро появится отдельная ветвь разработки — реализация Performance Inference на Nvidia, поскольку требования к знаниям инженеров для реализации таких конвейеров выходят за рамки как ожидаемых требований к знаниям для ML-инженеров, так и требований к знаниям для разработчиков.
Изобретательность и грубая сила
Инженеры ML стремятся оставаться в рамках своих инструментов и склонны к грубому решению проблем с использованием искусственного интеллекта.Они будут пытаться решить задачу в рамках своих инструментов, всячески игнорируя эвристики, логические ограничения бизнес-среды и т. д. Однако сосредоточение внимания на этих аспектах позволяет существенно ускорить производительность и снизить нагрузку на оборудование.
Будет здорово, если вы сможете обеспечить, чтобы ваша команда уделяла должное внимание таким аспектам системы.
Получите четкое понимание цели движения и плана ее достижения.
Никогда раньше я не видел такой большой ценности в диаграммах WBS, как в ML. Каждый аспект конвейера ML требует значительной работы для устранения риска доставки.
В итоге я сделал эту канбан-доску в Trello, чтобы оценить готовность ML-части продукта с точки зрения удовлетворения потребностей бизнеса.
Картинки кликабельны: 
Следите за тем, как задачи, созданные в системе управления задачами, связаны с карточками в WBS.
Используйте инструменты принятия решений при создании задач
Именно в контексте ML я осознал важность различных методов при работе над проблемами.В обычных инженерных проектах этого не требуется — декомпозиция происходит легко и непринужденно, ход выполнения проекта итеративный.
Здесь я предлагаю использовать подход с четким пониманием того, что мы делаем и зачем.
Это позволит вам не погружаться в исследования и ответить на вопросы «почему мы потратили несколько человеко-месяцев, не добившись никакого прогресса в доставке продукта».
Мне кажется, можно начать с заполнения декартова квадрата для каждой исследовательской задачи: 
Четко и подробно фиксируйте критерии успеха, неуспеха каждой исследовательской задачи и их последствия перед началом работы над задачей.
Только так через какое-то время вы сможете проследить, где вы находитесь и почему оказались в этой точке.
Проекты ML не являются проектами разработки программного обеспечения; Нужна другая методология, другой подход к работе с целями, другие способы принятия решений, создание четкого отслеживания целей, решений, задач, последствий.
Предоставьте как можно больше данных как можно раньше
Чем раньше вы предоставите команде ML данные, которые возможны в реальном мире, и установите ожидания для обработки этих данных, тем меньше вероятность того, что команда создаст что-то, что будет работать только при 23 градусах Цельсия, только с 14 до 16 часов.в ретроградном Юпитере.
Данные и их разметка должны генерироваться той частью компании, которая устанавливает ее ожидания.
Данные для обучения и тестирования работы моделей ИИ — это тоже элемент требований, а не тестовая среда, которая появляется, когда что-то готово.
Теги: #Управление проектами #искусственный интеллект #ИИ #Управление продуктами #компьютерное зрение #компьютерное зрение #нейронные сети #разработка продукта
-
Как Была Прикрыта Сеть Кадыр-Хана
19 Oct, 24 -
Сброс Пробега Для Ricoh Sp 150Suw
19 Oct, 24 -
Госаппарат Vs Ос
19 Oct, 24 -
Разбираемся В Консольных Приложениях На C#
19 Oct, 24 -
12-Й Выпуск Подшучека
19 Oct, 24
