Мотивация

«Развертывание модели машинного обучения — это просто»

Это миф, который я слышал так много раз. Как специалист по данным с инженерным образованием, я тоже придерживался этой точки зрения, пока фактически не разработал проект развертывания машинного обучения (или MLOps). Технически развертывание модели машинного обучения (ML) может быть очень простым: запустить сервер, создать API вывода ML и применить API к существующему приложению. К сожалению, этот рабочий процесс настолько прост, что люди склонны недооценивать его сложность. На самом деле, некоторые из моих друзей-инженеров машинного обучения жаловались, что их работу не понимает так много людей, таких как инженеры из разных команд, менеджеры по продукту, исполнительные команды и даже клиенты.

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

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

Фаза 1: когда модель только что передана инженерам машинного обучения.

"Модель буквально не работает на рабочих серверах"

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

Контейнеры, такие как Docker и K8s, способны решить большинство проблем с воспроизведением путем согласования программных сред на разных машинах. Однако контейнеризация модели — это не набор навыков, которым обладает каждый специалист по данным (DS). Если бы это произошло, инженерам DS и ML потребовалось бы дополнительное время для обмена знаниями.

С другой стороны, компиляция между сервером и платформами машинного обучения также может привести к системным ошибкам. Например, несмотря на то, что Flask + Tensorflow — это комбинация, используемая во многих руководствах, было время, когда мы обнаружили, что среда сервера flask не подходит для Tensorflow 2, поскольку среда становится все более сложной. Нам потребовалось некоторое время, чтобы найти обходной путь.

Специалисты по обработке данных — не программисты. Следование рекомендациям PEP 8 при написании кода не является обязательным для науки о данных. Низкое качество кода, о котором заявляет инженер машинного обучения, может быть связано с разными привычками программистов и ученых. Вместо традиционной IDE, такой как VS Code, Jupyter Notebook является более популярным инструментом редактирования кода для специалистов по данным. Логика программирования в Notebook сильно отличается от обычной разработки программного обеспечения. Поэтому, когда модель кода переносится из Jupyter Notebook, в ней могут возникнуть ошибки.

Если бы рабочие серверы использовали машины с другими характеристиками (например, ОС, типы ЦП, графические процессоры), чем серверы разработки, проект MLOps поднялся бы до более высокого уровня сложности.

Фаза 2: когда команды начинают сотрудничать

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

"Почему нас это должно волновать..."

Коммуникация между командами сопряжена со многими проблемами из-за рассеянной ответственности и приоритетов. Инженеры заботятся об эффективности программного обеспечения, стабильности системы и простоте обслуживания. Тем не менее, большинство DS больше заботятся о производительности и точности модели ML. Чтобы максимизировать производительность модели, они всегда используют преимущества различных инструментов обработки данных. Я видел, как мои коллеги из DS предварительно обрабатывали данные с помощью SQL, запускали конвейер модели с помощью R, затем Sklearn и заканчивали с помощью Pytorch. Конечно, такая структура не понравится инженерам.

Пока инженеры DS и ML спорят, что должно быть более приоритетным, менеджеры по продукту (PM) выходят на сцену и просят две команды следить за планом, поскольку ответственность PM заключается в своевременном выпуске продуктов. .

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

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

Фаза 3: когда модель вот-вот будет выпущена

Команды, наконец, пошли на компромисс ради нужд друг друга. Команда инженеров также успешно добавила в приложение функцию вывода модели. Все выглядит хорошо, не так ли?

"Подождите, какой объем трафика должен поддерживать сервер размещения модели?"

Когда дело доходит до проблем с пропускной способностью пользователей, и если компания находчива, наиболее рекомендуемым решением является приобретение кластера мощных серверов, способных справляться со всей нагрузкой трафика даже на пике. Однако машин, используемых для хранения моделей ML, мало и они дороги. Сервер AWS p3.16xlarge по запросу с 8 ядрами V100 стоит 24,48 доллара в час, что составляет 17 625,6 доллара в месяц.

К сожалению, вышеуказанное решение доступно лишь нескольким компаниям. Для остальных компаний более практичным является масштабирование вычислительной мощности по мере необходимости, но это сложно даже для старших инженеров машинного обучения. Поиск данных, параллелизм, согласованность и скорость — четыре распространенные проблемы в системе масштабирования. Что еще хуже, масштабируемость машинного обучения затруднена из-за нехватки серверных мощностей: если предположить, что наиболее часто используемый облачный сервер в вашем проекте называется сервером А, в традиционной системе масштабирования вам нужно только учитывать количество серверов А, которые вы используете. должен масштабироваться до. Однако в машинном обучении сервер A не всегда имеет достаточно емкости даже на крупных облачных платформах, таких как AWS, потому что ее не хватает. Ваша стратегия масштабирования также должна включать другие типы серверов с большей емкостью. Нагрузочные испытания необходимо проводить для всех комбинаций видов. Также могут быть добавлены новые облачные платформы, так что, если сервер A недоступен на одной платформе, у вас все еще есть возможность получить одну из них, выполнив поиск на других. В результате было несколько проектов машинного обучения, в которых наконец была разработана зрелая система масштабирования.

Фаза 4: когда модель развернута

Поздравляем! Вы наконец развернули модель, но еще не время уходить.

«Что? Испытание еще не завершено?»

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

Ухудшение связано с двумя аспектами: инженерными аспектами и аспектами науки о данных.

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

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

С точки зрения науки о данных сдвиг данных — это БОЛЬШОЙ убийца производительности модели с течением времени. Сдвиг данных определяется как изменение базовой взаимосвязи между входными и выходными данными из модели ML. Если произойдет сдвиг данных, специалистам по данным потребуется переобучить старую модель. Петля обратной связи — одно из решений для преодоления смещения данных. Он обнаруживает изменение производительности и переобучает развернутую модель с помощью вновь собранных данных. Да, ты прав. У решения есть и обратная сторона. Модель может быть сильно смещена, и проблему смещения трудно определить.

"Допустим, продуктовый магазин использовал модель машинного обучения для прогнозирования изменения запасов в следующем месяце. Модель предсказала, что вода в бутылках станет самым популярным товаром в следующем месяце, поэтому владелец магазина принял ее предложение и запасся водой в бутылках. Из-за наличия большего количества бутилированной воды самым продаваемым товаром в следующем месяце действительно является вода в бутылках, и эти данные снова были переданы в модель ML в качестве вновь собранных данных. В результате петля обратной связи сделала модель очень склонной к бутилированной воде и всегда просила владельца принести больше бутилированной воды… конечно, это предсказание не соответствовало действительности».

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

Конец

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

  1. Проблемы на этапе 1: при переходе из среды разработки в рабочую среду модели могут вести себя по-разному.
  2. Проблемы на этапе 2: при добавлении моделей машинного обучения в существующее приложение в рабочей среде сложно удовлетворить требования всех команд.
  3. Задачи на этапе 3: создание масштабируемой вычислительной мощности для обслуживания модели необходимо, но сложно.
  4. Проблемы на этапе 4: система машинного обучения со временем всегда ухудшается; должна быть построена система мониторинга.

Обычная конфигурация команды — 2–3 инженера по данным на одного специалиста по данным, а в некоторых организациях с более сложными задачами по обработке данных это число может достигать 5. Это утверждение согласуется с моим опытом о том, что развертывание модели машинного обучения всегда занимает больше времени, чем разработка модели (за исключением исследований, проводимых академическими кругами, которые стремятся внести кардинальные изменения во весь мир машинного обучения). Чтобы история была краткой, я по-прежнему придерживался высокого уровня при объяснении некоторых проблем. Если вы хотите узнать больше подробностей, пожалуйста, напишите мне, присоединившись к моему сообществу Discord: https://discord.gg/vUzAUj7V.

О нас

Мы из команды Aipaca, создающей бессерверный инструмент MLOps, Aibro, который помогает специалистам по данным обучать и развертывать модели искусственного интеллекта на облачных платформах за 2 минуты. Тем временем Aibro внедрила эксклюзивную стратегию экономии, основанную на машинном обучении, которая снижает затраты на облако на 85%.