Взгляните на наше собственное решение ML-Ops

Мотивация MLCore - нашей платформы MLOps

Машинное обучение сегодня в моде и становится частью любого бизнеса. Хотя то, на что он способен, просто прекрасно, но все хорошее приходит за свой счет. Если системы машинного обучения не имеют продуманной структуры с самого начала, они могут легко превратиться в уродливую неразбериху при запуске в производство. Вот почему многие компании изо всех сил пытаются управлять этими сложными системами и в конечном итоге нанимают огромные команды специалистов по данным и инженеров, чтобы поддерживать их в рабочем состоянии.

Компании думают, что все волшебство творится благодаря объединению большой команды экспертов. Но простое увеличение размера команды - не решение проблемы машинного обучения. Многие считают, что иметь большую команду специалистов по обработке данных и инженеров вполне логично; чем больше тем лучше. Предполагается, что специалисты по обработке данных разработают модели, а инженеры позаботятся о развертывании. Но здесь начинаются проблемы, потому что это отделяет инженеров от специалистов по обработке данных. Хотя ожидается, что они будут работать как одна команда, их функции не пересекаются, поэтому они остаются изолированными друг от друга, пока что-то не рухнет в производственной среде.

Это внутренняя разница между обязанностями специалистов по обработке данных и инженеров, из-за которой так сложно управлять машинным обучением в производственной среде.

Специалисты по обработке данных не обучены заботиться о производственных проблемах, таких как масштабирование; их сердца лежат в экспериментах с данными. Точно так же инженеры могут не захотеть экспериментировать с машинным обучением или его динамической природой. Итак, сколько бы из них мы ни собрали, это не поможет решить производственный кризис машинного обучения. Это только создает больше трений и бесконечных проблем с сотрудничеством. Нельзя затянуть гайку, набросив на нее несколько гаечных ключей.

«При работе в командах необходимо согласовать общую основу для эффективного сотрудничества».

Основная мотивация Quantum Black при разработке Kedro

Решение этого кризиса требует создания платформы. Эта платформа должна быть спроектирована таким образом, чтобы с самого начала обеспечивать соблюдение производственных стандартов. Такая платформа должна позволить специалистам по данным очень быстро перебирать свои модели, а также решать такие проблемы инженеров, как управление версиями, качество кода, воспроизводимость и т. Д. Такая платформа в конечном итоге становится общим языком, на котором специалисты по данным и инженеры могут говорить, тем самым устраняя любые проблемы с совместной работой.

Фактически, любая научная дисциплина требует контролируемой среды для процветания экспериментов. Это позволяет ученым быстро проверять свои гипотезы на различных данных. Машинное обучение не является исключением из этого правила. Специалисты по обработке данных должны иметь возможность экспериментировать, не беспокоясь о отслеживании результатов в таблицах Google. Вот почему так важно отвести специалистов по обработке данных от блокнотов Jupyter и перенести их на платформу, где они смогут играть с данными в свое удовольствие.

Платформа также становится централизованным местом для развертывания моделей машинного обучения, как браузеры для веб-приложений. Это упрощает отладку конвейеров машинного обучения, поскольку обеспечивает четкую прослеживаемость от обучающих данных до развернутой модели. Браузеры также абстрагируются от деталей того, на каком сочетании оборудования и ОС приложение будет работать для веб-разработчиков. Платформа предоставляет подобную абстракцию для специалистов по данным и избавляет их от беспокойства об аппаратных ограничениях или тратить время на установку пакетов. Все это помогает значительно сократить продолжительность жизненного цикла машинного обучения.

Благодаря автоматизации значительной части рабочего процесса машинного обучения платформа снижает потребность в большой команде для отдельных проектов. Таким образом, платформа высвобождает ресурсы; большие команды могут разбиваться на более мелкие и управлять большим количеством проектов. Это дает компаниям возможность добиваться большего при том же количестве людей.

Так можно масштабировать машинное обучение, давая возможность небольшим командам запускать крупномасштабные проекты машинного обучения.

Команды не должны беспокоиться о проблемах, связанных с управлением увеличивающимся объемом данных, моделей или масштабируемой инфраструктурой, которые связаны с крупномасштабными проектами. Платформа позаботится обо всем, что делает ее лучшим средством достижения масштабирования в области машинного обучения.

Потребность в платформе становится намного более очевидной, когда мы сравниваем программное обеспечение для машинного обучения с традиционным программным обеспечением. Традиционное программное обеспечение поставляется со всеми видами инструментов и фреймворков, которые помогают упростить жизненный цикл разработки программного обеспечения. Однако когда дело доходит до машинного обучения, существует дефицит полезных инструментов.

«Если вы хотите протестировать разработку традиционных приложений Python, вы можете найти как минимум 20 инструментов в течение 2 минут после поиска в Google. Если вы хотите протестировать модели машинного обучения, их не будет ".

Что я узнал, изучив 200 инструментов машинного обучения Чип Хуйен

Несмотря на то, что за последние 3-4 года количество инструментов и платформ для внедрения машинного обучения резко возросло, в этом пространстве еще предстоит проделать большую работу.

Введите MLCore

Видя, как наши проектные команды борются, проблемы, связанные с масштабируемостью, и отмечая пробелы в доступных инструментах для машинного обучения, мы вдохновились на разработку собственного решения этих проблем.

MLCore - это внутренняя платформа BRIDGEi2i, которая выступает в качестве интегрированной основы для любого проекта машинного обучения, включая наши ускорители искусственного интеллекта. Он позволяет нашим специалистам по обработке данных и инженерам легко создавать и развертывать масштабные решения и фактически стал системой для машинного обучения в BRIDGEi2i.

MLCore: устранение разрыва между обучением и развертыванием

К настоящему времени ясно, что подход специалистов по данным, разрабатывающих модели и передающих их инженерам для развертывания, не может быть использован для создания масштабируемых конвейеров машинного обучения. Он изолирует инженеров от специалистов по обработке данных, создавая пробелы в коммуникации внутри команды. Более того, предполагается, что результат тренировочного упражнения, то есть артефакт модели, отделен от процесса, используемого для создания этого артефакта.

« Если обучение проводится изолированно от стратегии развертывания, оно никогда не будет хорошо реализовано в производственных сценариях - что приведет к несогласованности, скрытым сбоям и, в конечном итоге, неудачным развертываниям моделей. »

Почему ML должно быть написано как конвейеры с самого начала Хамза Тахир

С помощью MLCore мы преодолели разрыв между обучением модели и развертыванием и создали автоматизированный рабочий процесс для всего процесса. Это значительно сокращает жизненный цикл машинного обучения. Это также делает перемещение моделей в производство простым нажатием кнопки.

Проблемы, которые мы преодолели при создании MLCore

Создать платформу, подобную MLCore, непросто; это связано с большим набором проблем. Однако хорошая новость заключается в том, что большинство принципов, применяемых для создания традиционных программных платформ, можно применить и к платформам машинного обучения. Просто у машинного обучения гораздо больше движущихся частей. Мы должны думать о доступности данных, перемещении данных, обучении модели и так далее.

В конечном итоге нам помогло более пристальное внимание к рабочему процессу машинного обучения.

Некоторые из выявленных нами проблем перечислены ниже:

  1. Оптимизация экспериментов. Динамический характер данных делает машинное обучение повторяющимся процессом. Специалисты по данным должны изучить различные алгоритмы, опробовать несколько фреймворков и настроить различные гиперпараметры, прежде чем прийти к желаемой модели. При разработке MLCore главной задачей было упростить эксперименты, сделав их более простыми, быстрыми и легко отслеживаемыми.
  2. Воспроизводимые конвейеры. Еще одной проблемой при разработке MLCore была воспроизводимость результатов. Это означало заботу о коде отслеживания, моделях, а также данных, используемых для создания моделей.
  3. Тестирование. Система машинного обучения предполагает рассмотрение не только традиционных концепций тестирования программного обеспечения, таких как модульные тесты, но и проверки моделей.
  4. Более быстрые циклы развертывания. В области машинного обучения данные часто меняются. Мы хотели, чтобы у MLCore был конвейер, который поддерживал бы быстрые циклы переобучения и развертывания.
  5. Мониторинг. По мере изменения данных производительность развернутых моделей снижается. Мониторинг помогает инициировать переподготовку, используя новые данные. Следовательно, крайне важно отслеживать как прогнозы развернутой модели, так и статистику данных, используемых для построения этой модели.
  6. Выбор фреймворков. После определения проблем, которые мы хотели решить с помощью MLCore, нашей следующей задачей было выбрать согласованный набор инструментов, которые составили бы платформу. Вот инструменты, которые мы выбрали:
  • Git для управления версиями кода
  • Праздник как наш магазин функций
  • MLflow для отслеживания экспериментов
  • DVC для управления версиями данных и моделей
  • Docker и Kubernetes для развертывания
  • GoCD для проектирования обучающих и оценочных конвейеров

MLCore: добавляемая ценность

MLCore был разработан с целью изменить подход к машинному обучению в BRIDGEi2i. Самый простой способ понять значение, которое он приносит в таблицу, - это использовать пример использования.

Допустим, компания по доставке такси ведет свой бизнес в десяти разных штатах по всей Индии. Они хотели бы спрогнозировать количество заявок с жалобами клиентов, которые будут сгенерированы для любого данного штата на месяц вперед на основе исторических данных.

Для штата Карнатака наша команда специалистов по данным решила построить конвейер, который включает в себя построение трех разных моделей.

Теперь давайте попробуем понять некоторые способы, которыми MLCore упрощает проектирование конвейеров машинного обучения и управление ими, например, как показано на рисунке (4):

  • Отслеживание и версии моделей: конвейер с тремя моделями отследить несложно. Сложность возникает, когда мы проектируем аналогичные конвейеры для оставшихся девяти состояний, в которых работает клиент. Тогда нам нужно будет отслеживать примерно 30–50 моделей или даже больше одновременно. До MLCore все эти модели обычно находились на дисках аналитиков Google. Но после MLCore не имело значения, производят ли конвейеры для проекта 50 или даже 100 моделей. Он автоматически отслеживает и контролирует версии всех файлов моделей.
  • Автоматическое резервное копирование. На рисунке (4) выше каждый блок может быть настраиваемым сценарием, находящимся в локальных системах специалистов по данным. Если они потеряют код, то эксперимент придется проводить заново с нуля. Таких сценариев можно полностью избежать с помощью MLCore, поскольку выполняется резервное копирование всего.
  • Отслеживает промежуточные выходы: Каждый из блоков на приведенном выше рисунке может иметь связанные с ними промежуточные выходы, которые необходимо отслеживать. Все это обычно выполняется специалистами по обработке данных вручную в своих локальных системах. Но как только мы разработали MLCore, нашим специалистам по данным не нужно было беспокоиться о том, какой результат был произведен на каком этапе конвейера, поскольку он выполняет все отслеживание за них.
  • Создает прослеживаемость. Каждая модель на рисунке (4) может быть разработана разными специалистами по обработке данных. Это означает, что разные компоненты конвейера распределены по локальным системам разных специалистов по данным. Следовательно, нет возможности отслеживания кода или данных, используемых для построения вышеуказанного конвейера. MLCore обеспечивает четкую прослеживаемость между различными компонентами конвейера машинного обучения.
  • Настраиваемые конвейеры. Раньше, если бы наши специалисты по обработке данных хотели обновить конвейер, подобный показанному выше, путем добавления или удаления моделей, они не смогли бы сделать это без нескольких часов ручной работы. Но с MLCore все, что им нужно сделать, это изменить шаблон конвейера, а остальное платформа обрабатывает самостоятельно.

Заключение

С момента своего создания MLCore действительно изменил нас. Это помогло нам достичь масштабируемости наряду с воспроизводимостью и объяснимостью результатов. Это стало общей площадкой для сотрудничества наших специалистов по обработке данных и инженеров. Теперь мы можем запускать большие проекты, используя небольшие команды, потому что MLCore выступает в качестве основы для всех проектов машинного обучения.

MLCore стандартизировал основные компоненты рабочего процесса машинного обучения. Это позволяет нашим специалистам по обработке данных сосредоточиться на построении моделей, не беспокоясь о нюансах инфраструктуры и развертывания. Это также значительно сократило циклы разработки и развертывания модели.

Возможности MLCore не ограничиваются решением проблем со структурированными данными, мы также расширяем его возможности для обработки неструктурированных данных. Это изменило бы то, как мы делаем проекты CV и NLP на BRIDGEi2i.

Как показано на рисунке (2), MLCore выступает в качестве основы для наших ускорителей искусственного интеллекта, включая рекомендации, прогнозы и т. Д. Для получения дополнительной информации о наших ускорителях посетите наш веб-сайт.

Особая благодарность Паван Кумар Т. В., Кишор Кумар Н, Вишванатх Пуппала за их ценные идеи, которые очень помогли при составлении статьи 😄

Ссылки

[1] https://towardsdatascience.com/why-is-machine-learning-deployment-hard-443af67493cd

[2] https://christophergs.com/machine%20learning/2019/03/17/how-to-deploy-machine-learning-models/

[3] https://www.informationweek.com/cloud/scale-your-machine-learning-with-mlops/d/d-id/1339191

[4] https://huyenchip.com/2020/06/22/mlops.html

[5] https://towardsdatascience.com/why-ml-should-be-written-as-pipelines-from-the-get-go-b2d95003f998