Как инженеры по машинному обучению или специалисты по обработке и анализу данных, мы все доходили до того, что создавали наши красивые модели с замечательными результатами испытаний, чтобы в конечном итоге использовать их только в презентации PowerPoint. Самый стандартный способ взаимодействия с моделью — использовать ее в автономном режиме, когда у нас есть какой-то набор данных для игры. Это нормально для экспериментов и создания начальной модели. Но следующим шагом было бы выпустить нашу драгоценную модель в дикую природу, чтобы люди могли ее использовать. Вот что такое модельное служение. Он представляет собой механизм развертывания модели, чтобы с ней могли взаимодействовать другие люди. Показ моделей позволяет перейти от экспериментов к работе.
Самые распространенные способы показа модели:
- Модель-как-зависимость;
- Модель как услуга.
⚙️ При настройке модели как зависимости модель будет использоваться непосредственно приложением. Например, в проекте Python он будет установлен как пакет через pip или интегрирован в ваш код напрямую из репозитория git. Я думаю, что с концептуальной точки зрения это самый простой способ обслуживать модель, но он имеет некоторые недостатки. Там, где работает приложение, вам необходимо иметь необходимое оборудование для вашей модели, что иногда невозможно. Кроме того, клиенту модели всегда придется пройти через боль управления зависимостями модели, что в некоторых случаях является настоящей болью.
⚙️ Принастройкемодели как услуги доступ к модели будет осуществляться через веб-API (например, RESTful API). Таким образом, клиент может обращаться с моделью как с черным ящиком. Он должен знать только входы и выходы модели. В оставшейся части статьи более подробно объясняется, как работает Модель-как-Сервис.
Модель как услуга
Как мы уже говорили, модель-как-услуга будет использоваться ее клиентами через веб-API. Возможно, для некоторых из вас это звучит пугающе, но основные понятия просты. Его архитектура будет состоять из следующих компонентов:
- Актуальная модель;
- Конвейер предварительной и постобработки;
- веб-слой;
- метод контейнеризации;
- Метод масштабирования.
1️⃣ Фактическая модель является результатом наших экспериментов, которые обычно сохраняются в различных форматах относительно используемой нами платформы (например, Scikit, Pytorch, Tensorflow, Keras и т. д.). Наилучшей практикой является сохранение модели в реестре, поддерживающем какое-либо управление версиями. Таким образом, у нас есть контроль над развитием нашей модели, и мы можем легко загрузить ее из любого места. Кроме того, когда мы хотим обновить нашу модель из производства, нам просто нужно изменить версию модели из конфигурации, и все готово (мы можем легко создать версию нашей модели с помощью таких инструментов, как ClearML).
2️⃣ Практически любой модели нужны входные данные в определенном формате и какая-то интерпретация прогнозов. Вот почему для каждой конкретной проблемы нам нужно будет написать собственный код для предварительной обработки входных данных нашей модели и постобработки прогнозов (например, здесь мы напишем код Python или C++, который интерпретирует ваши данные).
3️⃣ Чтобы получить доступ к нашей модели через веб-API, нам нужно будет написать веб-уровень поверх нашей модели и пользовательского кода. Обычно это можно легко сделать на Python с помощью таких фреймворков, как Flask или FastAPI. Мы создадим веб-сервер, к которому можно будет получить доступ в Интернете через набор конечных точек, как и любое другое серверное приложение. В качестве примечания, мы должны использовать Flask или FastAPI, если мы намерены создать RESTful API, но мы можем легко изменить это на другие типы связи. Например, если мы хотим транслировать прогнозы модели, мы можем использовать ту же концепцию, но просто изменить уровень Flask/FastAPI с помощью Kafka (или другого инструмента потоковой передачи).
4️⃣ Чтобы изолировать ваше приложение и его зависимости, нам придется поместить его в контейнер. Наиболее распространенный способ сделать это с помощью Docker.
5️⃣ Чтобы иметь возможность масштабировать наши запросы API, нам понадобится способ оркестровки наших контейнеров Docker. Это можно сделать с помощью Kubernetes или других подобных инструментов.
Как видите, мы используем технологии, которые нам уже известны или, по крайней мере, нам знакомы. С помощью этого метода мы можем легко развернуть наши модели, просто используя уже существующие инструменты.
Теперь у нас будут прогнозы по запросу, к которым можно будет легко получить доступ из разных клиентов, таких как мобильные устройства, браузеры, микросервисы и т. д.
Если нам удалось контейнеризовать нашу модель, мы можем использовать различных облачных поставщиков, которые могут легко разместить наше приложение. Наиболее распространенными примерами являются Amazon AWS Sagemaker, Google Cloud AI Platform, Azure Machine Learning Studio и IBM Watson Machine Learning.
Кроме того, мы можем создать аналогичную систему на месте с инструментами, которые дают нам возможности обслуживания: ClearML, TorchServe и т. д.
Заключение
Как мы видели, с модельным обслуживанием мы можем перейти от экспериментов к производству. Для деловых дельфинов этот шаг имеет решающее значение, иначе наша модель не будет иметь ценности, если ее будут использовать другие люди. Кроме того, мы увидели, что основные концепции обслуживания моделей просты для понимания и выполнения.
Спасибо, что прочитали мою статью!
Не стесняйтесь связаться со мной по следующему адресу:
- Подпишитесь на Средний
- Подключиться и связаться со мной в LinkedIn
- Напишите мне на мой почтовый адрес: [email protected]
