Введение

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

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

  • Встроенные модели. При таком подходе модели являются зависимостями приложения и пакетами внутри приложения. Он подходит для приложений, которые имеют дело с конфиденциальными или личными данными и хотят хранить данные на устройстве пользователя, не отправляя их на сервер. Таким образом, приложение может получить прямой доступ к модели, что повышает скорость вывода и позволяет делать выводы в автономном режиме. Однако этот метод также требует повторного развертывания приложения и выпуска новой версии всякий раз, когда необходимо обновить модель. Размер модели также должен быть небольшим. Некоторыми отраслями, которые часто используют подходы к развертыванию встроенных моделей, являются автономное вождение и здравоохранение. Вы можете создать встроенную модель в своем приложении, используя некоторые из существующих фреймворков, таких как T ensorFlow Lite и Core ML.

  • Модель, развернутая как API: этот подход отделяет приложение от модели с помощью API, что упрощает процесс развертывания. Обученная модель становится зависимостью от отдельной службы API, а модель оборачивается службой и может быть развернута независимо. Эта служба использует входной формат (либо отдельный пример, либо пакет) и обслуживает прогнозирование модели, и пока входные данные для модели остаются прежними, модель можно обновлять без серьезных изменений на стороне приложения. Вы можете развернуть свою модель как API, используя некоторые доступные технологии, такие как Flask и FastAPI.

  • Модель публикуется как данные. При таком подходе модель сохраняется как артефакт данных в нужном формате и может быть извлечена из любой платформы реестра моделей. В этом подходе мы можем построить процесс обучения, который публикует модель на потоковой платформе, такой как Apache Kafka или Pulsar, и наше приложение использует модель во время выполнения. Приложение может подписаться на любые обновления модели и получать самые последние версии модели «на лету» без необходимости повторного развертывания. Хотя этот подход обеспечивает большую гибкость, построение инженерной системы является сложным и требует инженерной сложности и зрелости.

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