Машинное обучение Kubeflow Times - воспроизводимость шаг за шагом

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

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

Исследования в предметной области;
Предположим, у нас уже есть задача, которую нужно решить. Нам необходимо провести исследование в предметной области, определить требования к решению, определить источники данных, определить инструменты, которые мы собираемся использовать, и методы, которые мы собираемся применить.
Подготовка данных;
Мы начинаем со сбора данных, преобразования их в желаемую форму и версии.
Обучение модели;
Строим модель и обучаем ее на подготовленных данных. Мы экспериментируем с использованием разных архитектур, проводим обучение несколько раз, настраивая гиперпараметры и оценивая производительность модели.
Каталогизация;
После обучения модели мы экспортируем ее в самодостаточный формат. Это означает, что артефакт модели можно независимо использовать в других инфраструктурах без передачи исходного кода и всех зависимостей. Мы занимаемся управлением версиями модели, а также извлечением входных и выходных данных модели для использования при развертывании.
Развертывание модели;
После экспорта модели мы развертываем ее в подготовленной инфраструктуре и предоставляем ей конечные точки HTTP / gRPC.
Интеграционное тестирование;
Мы проводим интеграционное тестирование, чтобы убедиться, что модель правильно работает в подготовленной среде.
Производственный вывод;
Мы начинаем делать выводы по нашей модели, собирая все запросы и прогнозы в течение всего срока службы модели. Мы предлагаем различные варианты развертывания, такие как развертывание A / B или Canary для разных версий модели.
Мониторинг производительности;
Во время вывода мы автоматически отслеживаем поведение модели в производственной среде; как данные, проходящие через модель, меняются с течением времени, включая понимание дрейфа концепций, изменений предметной области и обнаружения аномалий.
Сопровождение модели;
Этот этап посвящен долгой жизни модели. Мы интерпретируем прогнозы модели и объясняем, почему модель ведет себя именно так. Мы используем эти знания, чтобы улучшить модель, переобучая ее дальше в производственном трафике, чтобы повысить ее производительность.

Мы рассмотрим каждый из этих шагов на протяжении всей статьи.

Инструменты

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

Kubeflow - это набор инструментов машинного обучения для Kubernetes. Он начинался как простой способ запуска заданий TensorFlow в Kubernetes, но с тех пор расширился до многоархитектурной / многооблачной инфраструктуры для запуска и автоматизации конвейеров машинного обучения.
Hydrosphere.io - это платформа управления моделями с открытым исходным кодом для развертывания, обслуживания и мониторинга моделей машинного обучения и специальных алгоритмов.

Чтобы получить представление о будущем конвейере, давайте посмотрим, как различные инструменты в наборе инструментов Kubeflow и платформе Hydrosphere.io сопоставляются с этапами рабочего процесса.

Основное внимание в экосистеме Kubeflow уделяется обучению моделей машинного обучения, построенных в различных фреймворках, распределенным образом с использованием базового кластера Kubernetes. Это дает Kubeflow заметное преимущество перед ручной настройкой такой инфраструктуры обучения. Развертывание модели - это еще одна часть, которую Kubeflow удается покрыть нишей (в отношении фреймворков) и инструментами развертывания. Кроме того, есть новый сервис под названием Kubeflow Pipelines, основная цель которого - объединить различные этапы рабочего процесса в один прогон обработки.

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

Предпосылки

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

Локально:

В кластере Kubernetes:

По умолчанию Kubeflow будет установлен в пространстве имен kubeflow. В этом руководстве я предполагаю, что Hydrosphere.io установлен в том же пространстве имен, что и Kubeflow.

PersistentVolumeClaims

Нам дополнительно потребуется предоставить постоянное хранилище для модулей рабочего процесса, чтобы хранить промежуточные файлы и передавать их между этапами.

$ kubectl apply -f - <<EOF 
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: data
spec:
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 20Gi
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: models
spec:
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 20Gi
EOF

Манифест трубопроводов Kubeflow

Весь рабочий процесс будет выполняться поверх конвейеров Kubeflow. Конвейеры построены на Argo Workflows - контейнерном движке рабочих процессов. Чтобы выполнить такой рабочий процесс, вам нужно создать план Kubernetes, а затем применить его в кластере, чтобы запустить задание. Чтобы упростить процесс создания таких .yaml определений, Kubeflow выпустил библиотеку Python SDK, которая позволяет вам определять ваши рабочие процессы как функции, а затем компилировать их в DSL.

Прежде всего, мы определим фрейм этой функции. Создайте корневой репозиторий для этого руководства и определите в нем сценарий pipeline.py.

$ mkdir mnist  # create a root directory for this tutorial
$ touch pipeline.py

Мы уже создали PVC в нашем кластере, поэтому можем предоставить определение конвейера со ссылками на них.

На протяжении всей статьи я буду предоставлять короткие фрагменты кода для этого pipeline.py файла, который будет содержать только отличия от предыдущих версий. Полный код доступен здесь.

Чтобы упомянуть здесь несколько изменений, Kubeflow предоставляет нам возможность настраивать рабочий процесс из пользовательского интерфейса Pipelines. Для этого вам просто нужно предоставить параметры функции, как мы это делаем с переменными data_directory и models_directory. Есть некоторые ограничения на использование этих параметров, но они по сути исчезнут в следующих версиях SDK. На данный момент вы можете использовать эти параметры в своей функции следующим образом: переменная data_directory будет отображаться в строку {{workflow.parameters.data-directory}} при компиляции в DSL, который мы используем при объявлении томов.

Начнем с реальной модели машинного обучения.

Шаг 1. Исследование в предметной области

Чтобы сосредоточиться на части автоматизации, я выбрал хорошо известную задачу распознавания цифр.

Цели:

По изображению рукописной цифры классифицируйте, что это за цифра.

Требования:

Развернутая модель должна иметь возможность прогнозировать пакеты изображений;

Методы:

Полностью подключенная нейронная сеть (для простоты реализации).

Инструменты:

Язык - Python (содержит различные фреймворки глубокого обучения);
Framework - Tensorflow (имеет отличный механизм экспорта моделей; имеет готовые архитектуры классификации).

Источники данных:

MNIST (50000 поездов и 10000 тестовых изображений рукописных цифр в оттенках серого 28x28).

Шаг 2. Подготовка данных

Сценарий реального мира часто заставляет вас получать данные обучения из хранилища данных компании. Дело может состоять из следующего:

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

С выбранной проблемой такой возможности у нас нет. Мы будем использовать исходный общедоступный набор данных MNIST. Давайте создадим первый исполняемый файл, который загрузит данные и сохранит их в нашем PersistentVolumeClaim (PVC).

$ mkdir 01-download; cd 01-download
$ touch download.py

Это загружает все 4 файла, распаковывает их, конвертирует в numpy массивы и сохраняет эти массивы в base_dir каталоге. Каталог в этом случае будет PVC, подключенным к модулю по пути, указанному переменной среды MNIST_DATA_DIR (мы указываем эту переменную ниже).

Чтобы иметь возможность выполнять этот файл в кластере в рамках рабочего процесса, нам нужно упаковать его в контейнер Docker. Создайте для этого Dockerfile.

$ cat > Dockerfile << EOF
FROM python:3.6-slim
RUN pip install numpy==1.14.3 Pillow==5.2.0
ADD ./download.py /src/
WORKDIR /src/
ENTRYPOINT [ "python", "download.py" ]
EOF

Мы используем python:3.6-slim в качестве базового образа, дополнительно устанавливая некоторые зависимости Python.

После создания определения контейнера мы можем создать из него образ Docker и отправить его в общедоступный реестр Docker. В качестве имени пользователя вы можете использовать свою собственную учетную запись Docker Hub или использовать любой доступный для вас реестр Docker.

$ cd ..
$ docker build -t {username}/mnist-pipeline-download 01-download
$ docker push {username}/mnist-pipeline-download

Наконец, давайте обновим определение конвейера.

Здесь мы определяем новую переменную среды (1), которая будет прикреплена к нашему контейнеру, определяем операцию контейнера (2), которая будет выполняться в кластере, и, наконец, присоединяем (3) необходимые ресурсы.

Шаг 3. Обучение модели

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

$ mkdir 02-train; cd 02-train
$ touch train.py

Модель довольно проста, мы просто используем готовый полностью связанный классификатор нейронной сети (tf.estimator.DNNClassifier). Уточняем, что модель состоит из 2 скрытых слоев по 256 и 64 единицы соответственно. learning_rate, num_steps и batch_size - параметры, настраиваемые переменными среды. num_steps отвечает за то, как долго модель будет обучаться.

После завершения обучения модели мы немедленно сохраняем ее в models PVC в формате tf.saved_model, указывая входные данные модели. Результаты будут автоматически выведены.

Давайте создадим образ Docker из этого исполняемого файла.

$ cat > Dockerfile << EOF
FROM tensorflow/tensorflow:1.9.0-py3 
ADD ./train.py /src/
WORKDIR /src/
ENTRYPOINT [ "python", "train.py" ]
EOF 
$ cd ..
$ docker build -t {username}/mnist-pipeline-train 02-train
$ docker push {username}/mnist-pipeline-train

Обновите определение конвейера с помощью определения контейнера обучающей модели.

Аналогично предыдущему шагу мы дополнительно определяем новые переменные среды (1) и определяем операцию контейнера (2). Дополнительно указываем, что эта операция должна быть выполнена после завершения предыдущей операции download. В противном случае они будут запускаться параллельно. Внизу мы определяем, сколько ресурсов требуется этому контейнеру в кластере (5). Это указывает Kubeflow запускать этот контейнер только при соблюдении необходимых условий.

Шаг 4. Каталогизация моделей

Каталогизация моделей - это термин, который я хотел бы использовать для понимания следующего:

Извлечение метаданных:
- определение и веса графика;
- определения входов и выходов;
- версия / статистика обучающих данных;
- другие зависимости (словари поиска и т. Д.);
Управление версиями артефактов модели;
Сохранение модели в репозитории;

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

Мы уже сделали половину этого на предыдущем шаге, когда экспортировали модель в формат tf.saved_model. Однако другие шаги требуют действий. Если мы будем делать это вручную, нам нужно будет создать репозиторий, в котором будут храниться все наши модели и управлять версиями. Наряду с этим нам также потребуется обрабатывать метаданные, которые не были предоставлены в модели.

$ mkdir 03-upload; cd 03-upload
$ touch execute.sh

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

Если вам интересно, зачем нам хранить версию построенной модели в файле внутри модуля (ii) → мы можем указать Kubeflow получить содержимое этого файла и использовать его на последующих этапах конвейера (мы будем нужно).

Давайте создадим образ Docker из этого исполняемого файла.

$ cat > Dockerfile << EOF
FROM python:3.6-slim
RUN apt update && apt install -y jq
RUN pip install hs==0.1.5
ADD ./execute.sh /src/
WORKDIR /src/
ENTRYPOINT [ "bash", "execute.sh" ]
EOF 
$ cd ..
$ docker build -t {username}/mnist-pipeline-upload 03-upload
$ docker push {username}/mnist-pipeline-upload

Обновите определение конвейера.

Одно небольшое отличие от фрагментов кода - мы говорим Kubeflow хранить содержимое /model_version.txt под ключом model_version во внутреннем репозитории значений ключей (строка 26). Мы будем использовать это на следующем шаге.

Шаг 5. Развертывание модели

Следующим шагом является фактическое развертывание модели. На этом этапе у нас есть построенный артефакт модели, хранящийся в нашем репозитории, который еще не открыт миру. Типичный способ раскрытия модели вне кластера состоит из создания среды выполнения для модели и ее развертывания в кластере (веб-сервер REST API, который будет делать выводы по модели и возвращать прогнозы). Есть нишевые решения, такие как Tensorflow Serving, TensorRT, но они ориентированы на конкретные фреймворки. Их невозможно использовать для моделей, построенных на различных платформах, таких как scikit-learn или MXNet.

Наряду с реализацией среды выполнения возникнет необходимость реализации объединения сервисов между версиями модели для создания развертываний Canary (например, когда вы развертываете три версии модели и позволяете потоку трафика проходить через них в разных пропорциях, например 30/30/40. , открывая только одну конечную точку). Возможно, вы захотите связать свои модели в цепочку, где одни модели извлекают функции, а другие делают выводы на основе этих функций.

Реализация таких сред выполнения, настройка базовой инфраструктуры, управление взаимодействием моделей - нетривиальная задача. Используя Hydrosphere.io, вам нужно только создать приложение.

Приложение - это микросервис с открытой конечной точкой API для взаимодействия с вашей моделью. Он позволяет использовать ваши самые последние развернутые производственные модели через HTTP-запросы, вызовы API gRPC или настраивать их как часть потоков Kafka. Он использует предопределенные среды выполнения для запуска артефактов модели и помогает настроить многоэтапное выполнение от модели к модели. Внутри приложения вы можете спроектировать установку с использованием канареечных развертываний или моделей A / B.

$ mkdir 04-deploy; cd 04-deploy
$ touch execute.sh

Давайте быстро проанализируем манифест и его основные части:

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

Вот и все. После последней команды модель будет развернута в приложении и представлена миру.

Давайте создадим образ Docker из этого шага.

$ cat > Dockerfile << EOF
FROM python:3.6-slim
RUN pip install hs==0.1.5
ADD ./execute.sh /src/
WORKDIR /src/
ENTRYPOINT [ "bash", "execute.sh" ]
EOF 
$ cd ..
$ docker build -t {username}/mnist-pipeline-deploy 04-deploy
$ docker push {username}/mnist-pipeline-deploy

Обновите определение конвейера.

Незначительное различие здесь находится в строке 19. Мы используем выходное значение из предыдущего контейнера upload (ключ model_vesion) и передаем его в качестве аргумента в точку входа операции контейнера deploy.

Шаг 6. Тестирование интеграции модели

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

Прекрасный набор данных;
Краевые корпуса;
Недавний трафик.

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

$ mkdir 05-test; cd 05-test
$ touch test.py

generate_data функция считывает некоторое количество данных тестирования, сохраненных в нашем PVC. Затем мы используем конечную точку HTTP, чтобы достичь нашей модели, получить прогнозы и сохранить их в списке. Напоследок мы утверждаем, что точность нашей модели выше допустимого уровня. acceptable_accuracy отражает соответствующую переменную среды.

Давайте создадим образ Docker из этого шага.

$ cat > Dockerfile << EOF
FROM python:3.6-slim
RUN pip install scikit-learn==0.20.0 requests==2.21.0 numpy==1.14.3
ADD ./test.py /src/
WORKDIR /src/
ENTRYPOINT [ "python", "test.py" ]
EOF 
$ cd ..
$ docker build -t {username}/mnist-pipeline-test 05-test
$ docker push {username}/mnist-pipeline-test

Обновите определение конвейера. Все похоже на определение конвейера в целом.

Запустить рабочий процесс

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

Теперь мы можем скомпилировать определение конвейера.

$ python pipeline.py

Это создаст файл pipeline.tar.gz. Давайте запустим этот конвейер на нашем кластере.

$ kubectl port-forward deployment ambassador 8085:80

Это позволит вам получить доступ к пользовательскому интерфейсу Kubeflow с вашего локального компьютера. Откройте http: // localhost / pipeline /.

Загрузите pipeline.tar.gz файл с помощью кнопки Загрузить конвейер.

Создайте прогон (вам также нужно будет создать эксперимент, к которому этот прогон будет прикреплен). При создании прогона вы можете указать параметры, которые мы определили ранее.

И, наконец, начнем пробежку.

7. Производственный вывод

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

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

8. Мониторинг производительности модели.

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

Некоторые графические элементы доступны для использования по умолчанию - Количество запросов и Задержка. Их имена говорят сами за себя: первый просто подсчитывает, сколько запросов модель получает за время, второй отслеживает, сколько времени потребовалось для обработки каждого запроса.

Другие метрики используют более сложные методы. Один из возможных показателей - Автоэнкодер. С его помощью вы можете фиксировать «концепцию» ваших данных и отслеживать ошибки их восстановления. Давайте направим трафик на развернутую модель.

Слева на графике показано, как производственные данные были восстановлены, когда в модель были отправлены нормальные изображения MNIST. Оценка реконструкции составила всего 0,1 балла. Для этого рисунка мы также определили пороговое значение, равное 0,15 балла, что означает, что всякий раз, когда оценка реконструкции превышает красную линию, будет сформировано уведомление.

С правой стороны вы можете увидеть, как график увеличился до 60 000 точек оценки реконструкции после того, как данные были преобразованы в буквы (не набор данных MNIST). Как только мониторинг выявил это, он изменил состояние модели на «нездоровое».

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

Первая версия модели (синяя линия) оказалась менее эффективной, судя по диаграммам выше. Он был подвержен ошибкам в пакетах изображений, таким образом, он показал снижение точности до 0,85 процента для пакета. Вторая версия (зеленая линия) выглядит лучше, так как между выпадающими списками точности есть более широкие промежутки (это означает, что все изображения в промежуточных пакетах были классифицированы идеально == 1), а также более высокий показатель точности.

9. Обслуживание модели

Анализ причин

Мы переходим к последнему этапу, где затрагиваем тему обслуживания модели. Вспомните пример с огромным дрейфом концепций:

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

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

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

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

Наша текущая модель в большинстве случаев верна (зеленые прямоугольники), но она смущает изображение пятерки и ошибочно классифицирует ее как тройку. Давайте выясним, почему это произошло. Если мы посмотрим на область важности пикселей для изображения трех и его соответствующего класса (строка 4, столбец 4), мы увидим, что классификатор наблюдает за верхней половиной цифры и, вероятно, принимает во внимание фигурные формы, которые цифра три имеет. Точно так же изображение пятерки (строка 6, столбец 4) имеет похожие фигурные формы, но карта важности более смещена вправо. Карта важности для пятого класса (строка 6, столбец 6) показывает, что для классификации цифры пять модель наблюдает за пустой левой областью.

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

Субдискретизация

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

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

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

Здесь мы загружаем [запросы, ответы] из Hydrosphere.io, ищем метки наземной информации из MNISTTable, а затем готовим новый набор обучающих данных. Строка подвыборки binary_data=reqstore.APIHandler.subsample(addr, name) не загрузит всю историю вывода нашей модели, но вместо этого загрузит репрезентативную подвыборку с распределением производственных данных. Таким образом, мы можем обучить новую модель наиболее актуальным случаям.

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

Заключение

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