"Начиная"

Какая платформа ML от поставщика облачных услуг вам нужна?

AWS Sagemaker, платформа Azure ML или платформа GCP AI? На самом деле это не имеет значения. Не для индустриализации.

Во-первых, я предполагаю, что вы выбрали поставщика облачных услуг (CSP) или можете выбрать его для своей организации. Во-вторых, я также предполагаю, что вам нужно уметь создавать, обучать, настраивать, оценивать и развертывать модель машинного обучения, тогда первое, что вы, скорее всего, сделаете, - это проверить платформу машинного обучения выбранного вами CSP. Или вам стоит взглянуть на всех этих сторонних поставщиков? Как сравнить?

Давайте посмотрим на то, что действительно важно, а именно на картину в целом.

Экспериментирование против индустриализации

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

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

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

Типичные проблемы

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

Скрытый технический долг и MLOps

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

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

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

  1. MLOps level 0 🐣: Создание и развертывание моделей вручную.
  2. MLOps level 1 🤓: развертывание конвейеров вместо моделей.
  3. Уровень 2 MLOps 😎: интеграция CICD, автоматическое переподготовка, обнаружение отклонения концепции.

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

Начните с малого, сосредоточьтесь на экспериментах

Мы предлагаем следующую эволюцию усыновления. В этом есть смысл.

Если ваша организация не имеет опыта работы с облаком, машинным обучением или Python, начните с:

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

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

Во-вторых, вы часто не хотите только обучать и развертывать модель. Типичный трубопровод состоит из

  1. предварительная обработка данных,
  2. тюнинг модели,
  3. модельное обучение,
  4. оценка модели (с более сложными для вычисления метриками),
  5. финальное обучение модели на всех данных,
  6. шаг развертывания модели.

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

В-третьих, до сих пор я предполагаю, что вы выполняли только пакетный вывод (оптимизированный для пропускной способности). Например, запускайте пакетный конвейер каждое утро в 2 часа ночи, который будет выполнять прогноз на основе набора данных, собранных за предыдущий день. Наступит момент, когда вы также захотите иметь возможность делать это все время так называемым онлайн-способом (он же запрос-ответ). Чтобы реализовать эту возможность, можно использовать конечную точку API. Он возвращает прогноз от развернутой модели для каждого полученного сообщения. Затем этот поток оптимизируется для задержки. Вы сводите к минимуму время, необходимое отправителю сообщения для получения действительного ответа от конечной точки API.

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

Круто, но какую платформу ML выбрать?

Ответ: это зависит от обстоятельств.

Платформа GCP AI, Azure ML и AWS Sagemaker имеют множество общих сервисов. Все они обеспечивают функциональность, показанную в сводке ниже.

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

Стоит ли менять платформу машинного обучения?

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

Если вы крупная организация и уже сделали выбор в пользу поставщика облачных услуг, мы советуем остаться с ним. Не меняйте на несколько лишних наворотов. Как и платформы социальных сетей, в конечном итоге все они будут выглядеть и делать то же самое. У Google может быть лучший инструмент AutoML, но я уверен, что они наверняка догонят Azure и AWS (если они еще этого не сделали).

Обратите внимание, что развертывание более 5–10 моделей на любой из этих платформ может стать дорогостоящим.

Общая рекомендация

1. Для экспериментов

Сосредоточьтесь на быстрых итерациях ⚡, самообслуживании 💁 и простой отладке 🐛.

Выберите любой инструмент, с которым вы наиболее продуктивны. AWS Sagemaker, платформа GCP AI или Azure ML определенно помогут ускорить работу

  • исследование,
  • тюнинг модели,
  • обучение,
  • устанавливая ориентир.

2. Для индустриализации

Сосредоточьтесь на надежности 🧘‍♂️, отслеживаемости 🔍 и избегании фрагментации технологий 🧩.

Если вы большая организация, ищите возможность интеграции индустриализации модели с существующей стабильной цепочкой инженерии данных в облаке (например, в Kubernetes).
Если вы новичок, воспользуйтесь возможностями развертывания этих платформ машинного обучения. Это явный ускоритель для вас. Конечно, если количество развернутых моделей субъективно невелико (‹5–10 моделей). Если через некоторое время вы заметите, что

  • затраты высоки,
  • проблемы с доступом к данным или
  • нестабильность сохраняется,

тогда пришло время отказаться от этих платформ машинного обучения. Двигайтесь к стабильной цепочке инженерии данных (как в крупных компаниях).

Наконец, вы также можете посетить наш веб-семинар именно по этой теме.

Бонус: советы по плавному переходу от экспериментов к индустриализации

Разделение научного и инженерного кода
Машинное обучение часто требует добавления большого количества шаблонного кода. Подумайте о циклах обучения, загрузке данных, регистрации… Если вы используете Pytorch, обязательно обратите внимание на Pytorch Lightning.

Принятие шаблонов кода проекта

Каждому проекту внутри вашей организации потребуется код для

  • интегрироваться с системой CICD,
  • интегрироваться с выбранной платформой ML,
  • настроить доступ к данным,
  • настроить ведение журнала и т. д.

Используйте что-то, называемое cookiecutter, чтобы сгенерировать структуру проекта в репозитории git, которая избавит новый проект от всех этих хлопот. Взгляните на https://github.com/drivendata/cookiecutter-data-science, чтобы получить хорошую отправную точку.

Стандартизация

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

Благодарности

Я хотел бы поблагодарить Кристофа Мартенса, Гергели Соти, Паскаля Кнапена и в основном Криса Петерса из Data Minded за их вклад и отзывы. Но также и наших клиентов, которые позволяют работать с множеством различных стеков технологий.