Итак, у вас есть отличная идея для применения ИИ, но что теперь? Как вы его тренируете, строите и позволяете миру использовать ваше чудесное творение?

В этой статье мы обсудим именно это.

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

Что такое Tensorflow?

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

Перевод. Tensorflow можно использовать по-разному. В настоящее время одним из самых популярных применений является создание моделей глубокого обучения. Хотя это была библиотека, изначально созданная для больших числовых вычислений, Google открыл ее исходный код для использования в качестве библиотеки глубокого обучения.
Он предоставляет API для нескольких разных языков, из которых Python является наиболее широко используемым и поддерживаемым.

В рамках экосистемы Tensorflow Google также представил Tensorflow Serving, который позволяет вам взять вашу модель, экспортировать ее в формат protobuf и создать grpc или rest API.

Основные блоки

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

Servables
Servables — это наименьшая единица в обслуживающей экосистеме TF. Это объекты, которые используются для выполнения различных вычислений. Эти объекты бывают разных размеров, сложности и типов. Для целей этого поста мы будем говорить о том, что servables являются моделями в формате SavedModel.

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

В мире обслуживания TF модели на самом деле просто служат. Обычно он содержит алгоритм, изученные веса и таблицы поиска.

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

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

Техническая архитектура TF Serving

В общих чертах происходят следующие шаги:

Источник создает загрузчик для определенных версий модели или обслуживаемого объекта.
Источник уведомляет менеджера о версии.
Менеджер определяет, безопасна ли она (например, достаточно ли ресурсов) и дает загрузчику необходимые ресурсов и позволяет загрузчику загружать определенную версию.
Затем клиент может запросить у менеджера конкретную версию подаваемого объекта или запрашивает последнюю версию по умолчанию.

Конвейер машинного обучения

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

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

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

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

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

Следующий конвейер — это фактическое обслуживание и использование модели. Здесь мы используем архитектуру тензорного потока, которая управляет загрузкой, выгрузкой и обслуживанием модели. Мы просто указываем источник (сегмент S3) и оборачиваем полученный API в веб-приложение Python. После этого клиенты смогут делать запросы к этому новому приложению.

У вас может возникнуть вопрос: зачем оборачивать API в другое приложение? Что ж, мое внимание в этой конкретной установке было сосредоточено на компьютерном зрении и обработке изображений. При работе с изображениями необходимо выполнить несколько шагов для предварительной обработки изображения и последующей обработки результатов. Обернув его в приложение Python, мы получаем все инструменты Python, которые хорошо работают с изображениями и наукой о данных в целом, а также гарантируем, что приложения, использующие нашу модель, не привязаны к Python. т.е. нашим клиентом может быть приложение Node, приложение Go или любая другая технология по вашему выбору.

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

1. Запуск на Kubernetes (используется Kubeflow)
2. Мониторинг (в разработке)
3. Автоматическое переобучение моделей