Это сложнее, чем многие думают
Сегодня мы живем в мире беспрецедентного открытого кода. Такие компании, как Google и Facebook, сделали свои внутренние ИИ-решения достоянием общественности, что ранее было неслыханным шагом. Сегодня также есть много ресурсов о том, как быстро и легко создавать решения на основе ИИ. Несмотря на это, по-прежнему требуется огромный объем работы по разработке реального приложения ИИ до уровня качества и надежности, обычно необходимого для производственных развертываний, а объем требуемой работы часто недооценивается даже опытными разработчиками и менеджерами. Говорят, что «последние 20% работы отнимают 80% времени», и нигде это не вернее, чем системы искусственного интеллекта.
В этом посте я расскажу о некоторых ключевых причинах, по которым системы ИИ требуют так много усилий для создания и почему зачастую лучше купить существующую систему. Лучше всего это пояснить на примере, для которого я буду ссылаться на систему распознавания дорожных знаков (TSR), над которой я когда-то работал для автопроизводителя. TSR звучит просто, правда? Он также часто используется в сообщениях «Создайте свой собственный классификатор за 5 минут». Ну что ж, приступим!
Данные
Edge Cases. Повсюду крайние случаи.
Вы, наверное, догадались, но данные обычно являются потребителем времени и денег номер один. Это происходит из-за того, что мы постоянно недооцениваем сложность реального мира и количество крайних случаев даже для самых простых задач.
В моем проекте TSR мы сталкивались со множеством вещей. Например, на многих автомагистралях используются светодиодные знаки, которые, помимо того, что выглядят совершенно не так, как обычные знаки, трудно запечатлеть с помощью камеры (попробуйте снять видео с экрана компьютера). Чтобы решить эту проблему, мы создали модуль, который будет наложить несколько кадров для получения полного изображения знака. Системе также приходилось работать в самых разных условиях. Ночью знаки с высокой отражающей способностью намного ярче, чем окружающая среда, в то время как знаки едва видны при движении в тумане, под дождем или на солнце.
Европейские знаки часто имеют красную рамку, но на старых знаках она может быть почти полностью стерта. Кроме того, во многих европейских городах стало модным наклеивать наклейки на вывески. Знаки также часто закрывались растениями или другими придорожными препятствиями.
Даже если знаки хорошо видны в хороших условиях, их бывает сложно идентифицировать среди всего шума. Например, грузовики в Европе имеют наклейки с ограничением скорости сзади, которые идентичны дорожным знакам, но указывают, насколько быстро им разрешено двигаться. На перекрестках с шоссе все усложняется, поскольку знаки ограничения скорости на выезде хорошо видны с самого шоссе. А что, если знак засыпан снегом, который бывает такого же цвета, как и большинство дорожных знаков?
Сложность реального мира не ограничивается компьютерным зрением, я недавно написал дополнительную статью о регулярных выражениях в реальном мире.
Трудно найти хороший набор данных
Многие модели опубликованы и имеют открытый исходный код, но наборы данных, на которых они обучаются для производственных приложений, обычно хранятся под замком. Некоторые данные (например, номера кредитных карт) получить особенно сложно. Фактически, «ров данных» - главное конкурентное преимущество многих компаний, занимающихся ИИ.
Но что насчет всех тех сочных наборов данных, которые используют исследователи, спросите вы? К сожалению, производственные приложения плохо справляются с исследовательскими задачами. И даже если бы они это сделали, наборы исследовательских данных обычно не допускают коммерческого использования (например, ImageNet). Также часто бывает много ошибок маркировки в наборах исследовательских данных, что мешает разработке высококачественных моделей. Хорошим примером является набор данных обнаружения объектов OpenImages от Google. Состоящий из 1,7 миллиона изображений с 600 различными классами, он может быть полезен для обучения моделей обнаружения объектов. К сожалению, в обучающей группе меньше половины меток на изображение, чем в проверочной группе, что означает, что значительное количество примеров не имеет меток.
Наборы данных для TSR также становятся жертвой этих проблем. Свободно доступные наборы данных TSR не допускают коммерческого использования, содержат слишком мало примеров для реального использования и имеют значительные ошибки маркировки. Кроме того, они используют только примеры, снятые при хорошем освещении в одной стране. А автомобили имеют досадную привычку путешествовать в новые юрисдикции с другими правилами дорожного движения и другим дизайном дорожных знаков.
Создание настраиваемого набора данных дорого и требует много времени.
Вы говорите, почему бы не создать свой собственный набор данных? Что ж, давай посмотрим на это. Первый шаг - выбрать метки / выходы и собрать данные, убедившись, что улавливаются все граничные случаи. Затем важно убедиться, что у вас есть хорошие наборы для проверки и тестирования, которые обеспечивают надежный и сбалансированный снимок вашей производительности.
Затем следует гигиена данных и форматирование, что может занять много времени. Очень важно сделать этот шаг правильно. Например, модели трансформаторов страдают неожиданно большим падением производительности, если этот шаг не выполнен правильно.
Для большинства задач данные необходимо пометить. Для проектов, над которыми я работал, мы всегда создавали собственный инструмент маркировки или модифицировали инструменты с открытым исходным кодом, поскольку существующие готовые инструменты никогда не подходят для решения поставленной задачи. Вам также понадобится инфраструктура данных для управления, версии и обслуживания вашего нового набора данных.
Затем вам нужно будет привлечь людей для аннотирования вашего набора данных. Если вам повезло, и вы можете обмениваться данными за пределами своей организации, и ваша задача не требует особых знаний в предметной области, вы можете передать задачи аннотации на аутсорсинг. В противном случае потребуется много работы, чтобы нанять новую команду аннотаторов и управлять ею. В любом случае обучение аннотатора может потребовать некоторой работы, поскольку большинство задач требует определенных знаний в предметной области и обычно более сложны, чем щелчок по объектам на изображении. А поскольку текучесть кадров на этом типе должности высока, вы можете ожидать, что окажетесь на колесе хомяка больше, чем вы ожидали. Один из лучших способов поддержать ваших аннотаторов - иметь руководство по аннотациям, с которого они могут начать чтение, прежде чем вы перейдете к циклу обучения аннотациям и обратной связи. Само создание руководства по аннотациям - это большая работа, так как многие метки неоднозначны, если не определены правильно, часто необходимо включать исчерпывающий список примеров, а также живой раздел часто задаваемых вопросов, который необходимо добавлять, когда вы обнаруживаете, что все больше и больше необходимы разъяснения, чтобы учесть разнообразие представлений людей о единой концепции.
Наконец, важно проверить свой процесс, чтобы гарантировать высокое качество вывода. Аннотаторам также необходимо последовательно маркировать крайние случаи, чтобы модель работала правильно. Например, в Private AI мы часто сталкиваемся с тысячами крошечных вопросов о том, что представляет собой конфиденциальная информация. Например, фраза «Мне нравится Игра престолов», вероятно, никого не идентифицирует, но фраза «Мне нравится исполнение Дюны 1984 года Дэвидом Линчем» немного сужает круг вопросов.
Таким образом, хотя аннотаторы данных можно найти довольно дешево, для создания набора данных требуется большое количество ценного времени разработки / управления. В качестве альтернативы вы можете обратиться к таким сервисам, как Amazon Mechanical Turk, чтобы передать часть процесса на аутсорсинг. Однако, по моему опыту, эти услуги довольно дороги и не обеспечивают высокое качество этикеток. Кроме того, в реальных проектах требования / спецификации обычно меняются. Это означает многократный просмотр данных по мере изменения внутренних и внешних требований (например, правил защиты данных).
Процесс создания набора данных также усложнился за последние 5 лет. Проект TSR, над которым я работал, был до GDPR, и в настоящее время конфиденциальность является обязательной при сборе данных.
Модельные вещи
У вас есть данные. Что теперь?
Теперь мы подошли к самой видимой части процесса: построению модели. Мы можем использовать множество решений с открытым исходным кодом, но, как правило, необходимо проделать большую работу по исправлению небольших ошибок, влияющих на точность, с учетом большого разнообразия возможных реальных типов ввода, гарантируя, что код работает так же хорошо, как и он может выдавать новые данные, добавленные вами метки и т. д. Некоторое время назад я написал свою собственную реализацию MobileNet V3, так как ни одна из реализаций, которые я не мог найти, не соответствовала статье - даже реализация keras-приложений. Точно так же и в Private AI заставить современные модели работать на 100% их мощности было большой работой. Вы также должны убедиться, что код допускает коммерческое использование - это обычно выбивает из множества реализаций исследовательских работ.
Производственная система часто полагается на комбинацию специфичных для предметной области методов для повышения производительности, что требует интеграции множества различных кодовых баз. Наконец, все должно быть протестировано, что-то, что обычно не касается открытого исходного кода. В конце концов, кому нравится писать тесты?
Развертывание
Итак, вы получили данные и построили свою модель - теперь пора запустить ее в производство. Это еще одна область, в которой открытый исходный код обычно не освещается, хотя за последние несколько лет ситуация значительно улучшилась. Если ваше приложение должно запускаться в облаке, это может быть довольно просто (просто поместите свою модель Pytorch в контейнер Docker), но с оговоркой: запуск машинного обучения в облаке может стать действительно дорогим. . Запуск всего нескольких инстансов с графическим процессором легко обходится в десятки тысяч долларов в год. И вы обычно работаете в нескольких разных зонах, чтобы уменьшить задержку.
Ситуация значительно усложняется при интеграции в мобильные приложения или встроенные системы. В таких ситуациях вам обычно приходится работать на CPU из-за фрагментации оборудования (я смотрю на вас, Android) или проблем с совместимостью. Этот проект TSR, над которым я работал, требовал, чтобы весь код был написан в соответствии со стандартом C 30-летней давности и занимал всего несколько мегабайт! Использование внешних библиотек также было запрещено из-за проблем, связанных с сертификацией безопасности.
В любом случае обычно необходима оптимизация модели. Проблема в том, что пакеты вывода Deep Learning находятся в гораздо более низком состоянии готовности и намного сложнее в использовании, чем обучающие инструменты, такие как Tensorflow или Pytorch. Недавно я преобразовал модель трансформатора в пакет Intel OpenVINO. За исключением того, что демонстрационный пример Intel больше не работал с последней версией Pytorch, поэтому мне пришлось обратиться к исходному коду OpenVINO и самому внести некоторые исправления.
Реальные приложения также включают в себя нечто большее, чем просто запуск модели искусственного интеллекта. Обычно требуется много предварительной и последующей обработки, и все они также должны быть обработаны. В частности, для интеграции в приложение может потребоваться перенос на язык приложения (например, C ++ или Java). В этом проекте TSR требовался большой объем кода, чтобы сопоставить обнаруженные знаки вместе с навигационной картой.
Наконец, стоит отметить, что людей с опытом в этой области ДЕЙСТВИТЕЛЬНО трудно найти.
Текущие задачи
Итак, мы на финише! Ваше приложение сейчас находится в производстве, оно выполняет свою работу по сортировке / идентификации / взаимодействию с виджетами. Теперь идет текущее обслуживание.
Как и в любом программном обеспечении, будут ошибки и сбои в прогнозировании моделей. В частности (и несмотря на все ваши усилия) предстоит много работы по сбору данных, необходимых для заполнения крайних случаев, которые были упущены на начальном этапе сбора данных. Мир, в котором мы живем, не статичен, поэтому данные необходимо постоянно собирать и передавать через систему. Хороший пример - Covid-19. Попробуйте спросить любого чат-бота до 2019 года, что это такое.
Наконец, хотя это и не является строго необходимым, рекомендуется периодически оценивать и интегрировать последние достижения исследований.
Резюме
Вот что на самом деле требуется для создания производственного приложения машинного обучения. Как видите, для создания полной системы обычно требуется команда с различными специальностями, такими как наука о данных, развертывание моделей и опыт в области приложений. дорогостоящее упражнение. Еще больше усложняет ситуацию текучесть кадров, которая может означать, что система, на создание которой ваша компания потратила много времени и денег, внезапно становится не обслуживаемой, что представляет собой очень реальный бизнес-риск.
Надеюсь, это поможет вам подойти к своему решению «покупать или строить», вооружившись дополнительной информацией. Это значительно сложнее, чем «давай возьмем модель X и включим». Я видел воочию и слышал множество рассказов компаний, не моргнув глазом, жертвуя сотни тысяч долларов в год Amazon / Microsoft / Google на облачные вычисления, несмотря на то, что сторонние решения предлагают небольшую часть общей стоимости владения. Если вы решили строить сами, убедитесь, что у вас много непредвиденных обстоятельств! И учтите все затраты, такие как облачные вычисления, найм и управление.
А это приложение TSR? Могу сказать, что очень гордился тем, насколько хорошо работает наша система, но на это потребовалось много-много десятилетий разработчика.
