Почему мы создали платформу для инженерии машинного обучения, а не науки о данных

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

Несмотря на то, что мы очень гордимся нашей работой над Cortex, он является лишь частью тенденции, которая наблюдалась в течение последнего года, а именно — рост инженернойэкосистемы машинного обучения. Компании нанимают инженеров МО быстрее, чем когда-либо, а выпускаемые проекты становятся все лучше и лучше.

Хотя все это очень интересно для нас, мы все еще часто слышим вопрос: “Что такое инженерия машинного обучения?”

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

Что такое инженерия машинного обучения и почему это не наука о данных?

Давайте начнем с определения инженерии МО в контексте чего-то более знакомого людям: науки о данных.

Это трудно сделать, так как кто-то обязательно будет недоволен, но я попробую:

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

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

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

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

Smart Compose от Gmail с точки зрения ученого по данным и инженера по машинному обучению

Smart Compose (умный ввод) от Gmail — это один из самых распространенных примеров машинного обучения в продакшене и для наших целей он четко иллюстрирует проблемы инженерии машинного обучения.

Источник: Google’s The Keyword

Представьте себе, что вы создаете Smart Compose. Для начала мы бы обозначили наши ограничения, которые, согласно Gmail, являются:

• Smart Compose должен интегрироваться с UI редактора Gmail.
• Прогнозы должны быть отправлены в редактор Gmail менее чем за 100 мс.
• Smart Compose должен масштабироваться до 1,4 миллиарда пользователей Gmail.

Единственное из этих ограничений, которое в значительной степени связано с наукой о данных — это требование к задержке.

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

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

1. Определение архитектуры

Как модель должна быть интегрирована с клиентом Gmail? Есть несколько вещей, которые следует принять во внимание:

• Модель слишком велика, чтобы ее можно было развернуть локально на клиенте.
• Вывод результата сравнительно дорог с точки зрения вычислений.
• Опять же, и не будет напомнить лишним, Gmail имеет 1,4 миллиарда пользователей.

Учитывая этот контекст, наилучшим подходом является архитектура микросервиса, в которой модель развертывается как веб-API, который может быть запрошен клиентом Gmail. Таким образом, вычислительные затраты на вывод могут быть изолированы от остальной части приложения, а сервис может быть масштабирован горизонтально.

Однако в рамках этой архитектуры существуют определенные проблемы.

2. Масштабирование модели-микросервиса

Представить эту архитектуру модели-как-микросервиса интуитивно просто, но реализовать ее на деле — непростая задача. Для контекста, автоматизация этого процесса была нашей основной мотивацией в построении Cortex.

Команда Gmail не поделилась подробностями о своей инфраструктуре вывода, но стандартный для отрасли подход будет заключаться в следующем:

• контейнеризовать микрослужбу;
• развернуть её в кластере Kubernetes, подготовленном для вывода;
• раскрыть её как веб-службу, поместив за балансировщик нагрузки.

Источник: Архитектура разработки Cortex

В рамках этого существует ряд инфраструктурных проблем, которые необходимо решить. Kubernetes должен быть интегрирован с плагинами устройств для распознавания GPU / ASIC, что может привести к проблемам с автоматическим масштабированием. Производительность модели должна контролироваться. Обновления должны происходить без сбоя API.

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

Источник: Репозиторий Cortex

3. Достижение целевой задержки

Даже при развертывании масштабируемой модели задержка все еще остается проблемой. Гибридная модель, разработанная командой Gmail, была быстрой, но у микросервиса все еще была средняя задержка в несколько сотен миллисекунд.

Чтобы уменьшить задержку до < 100 мс, инженеры должны были улучшить свое оборудование. В частности, они использовали TPU, ASIC, разработанный Google для машинного обучения, вместо CPU. На TPU средняя задержка снизилась примерно до 10 мс.

Хотя концептуально это просто, на самом деле сама реализация довольно трудная. Развертывание на ASIC, таких как TPU Google или Infernentia Amazon, требует приличного количества мощности.

Например, недавно мы разработали поддержку Inferentia в Cortex и столкнулись с двумя проблемами:

• Чтобы обслуживать модели на экземплярах Inferentia, Cortex необходимо было интегрировать с API-интерфейсами нейронов AWS. Нейрон — это механизм, используемый для компиляции моделей для запуска на “NeuronCores” (нейронных ядрах) Infernentia, а также для обслуживания предсказаний из скомпилированной модели.
• Kubernetes не признает Infernentia (или любой ASIC, если уж на то пошло) в качестве ресурса по умолчанию. Мы должны были найти плагин устройства, чтобы позволить им работать вместе. Будучи очень новым, плагин устройства Infernentia находится в глубокой бета-версии, и нам потребовалось много циклов, чтобы разработать стабильную интеграцию.

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

Почему пересечение программной инженерии и науки о данных так интересно

Читая статью, большинство проблем может показаться вам связанными с разработкой ПО. Проектирование систем, написание API, настройка облачной инфраструктуры — все это не является сутью работы машинного обучения.

Все это, однако, по-прежнему специфично для МО.

Настройка автоматического масштабирования для развернутой модели концептуально аналогична и для любого микросервиса, но из-за особенностей вывода она требует различных ресурсов и подходов. Аналогично, написание REST API на Python знакомо большинству инженеров-программистов, но написание такого, который будет использовать фильтрацию top-k для анализа прогнозов моделей, является специфичной для МО задачей.

Иначе говоря:

• Рабочие процессы науки о данных позволяют получать информацию, делая акцент на инструментах, которые предпочитают экспериментирование производству, например ноутбуках (Jupyter, Docker).
• Рабочие процессы разработки ПО, с другой стороны, были ориентированы на производство, но не на МО-специфику.

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

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

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

В восторге от будущего прикладного машинного обучения? Нравится работать над инфраструктурой? Подумайте о том, чтобы внести свой вклад в Cortex!

---

Перевод статьи Caleb Kaiser: Why we built a platform for machine learning engineering — not data science