Пайплайн обучения

Шаги пайплайна

Пайплайн обучения превращает свежие данные в проверенную модель. Статья Google об MLOps раскладывает его на такие шаги:

1. Извлечение данных из базы или хранилища.
2. Проверка данных: схема и значения такие, как ожидалось.
3. Подготовка данных: очистка, расчёт feature, разбиение на части для обучения и для проверки.
4. Обучение модели.
5. Оценка: метрики качества на данных, которые модель не видела.
6. Проверка модели: новая модель годится для выкатки.

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

Train и test

На шаге подготовки данные делят на две части. На train set модель обучается. На test set её потом проверяют.

Проверять на тех же данных, что были в обучении, бессмысленно: модель могла их запомнить. Test set показывает, как модель поведёт себя на клиентах, которых она ещё не видела.

Проверка данных

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

Для модели churn проверки могут быть такими:

• схема: колонки user_id, orders_30d, avg_check на месте, типы совпадают;
• значения: avg_check не отрицательный;
• полнота: пустых avg_check не больше 1%;
• распределение: средний чек не вырос втрое за неделю.

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

Для таких проверок есть библиотеки, например Great Expectations, Pandera и TensorFlow Data Validation.

Проверка модели

Модель оценивают метриками качества на test set. Самая простая метрика accuracy: доля верных ответов. Модель ответила правильно для 870 клиентов из 1000, значит accuracy 0.87.

По статье Google новую модель перед выкаткой проверяют так:

• метрики на test set не хуже заданного порога;
• метрики не хуже, чем у текущей модели в проде;
• качество приемлемое на отдельных частях данных, например по каждому региону;
• модель совместима с инфраструктурой и API сервиса.

Проверка по частям данных нужна, потому что общая accuracy может вырасти, а для одного региона упасть вдвое.

Model registry

Model registry — хранилище версий моделей. Container registry хранит образы с тегами, model registry хранит модели с номерами версий.

У каждой версии есть:

• файл модели;
• ссылка на запуск обучения, который её сделал;
• метрики оценки.

Версии можно дать alias, именованную ссылку на версию, например champion для модели, которая работает в проде. Так это называется в MLflow, о нём урок 5. Сервис загружает не конкретный файл, а «текущую champion модели churn». Чтобы выкатить новую модель, alias переносят на новую версию. Откат устроен так же: alias возвращают на старую.

Метаданные

На каждый запуск пайплайн записывает метаданные:

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

По этим записям можно ответить, откуда взялась модель версии 14, и повторить её обучение. Статья Google называет метаданные условием воспроизводимости и отладки пайплайна.

Что важно запомнить

Пайплайн обучения: извлечь данные, проверить, подготовить, обучить, оценить, проверить модель. Шаги независимы и перезапускаются по отдельности.

Данные проверяют до обучения. Модель оценивают на test set, который она не видела, сравнивают с текущей и проверяют по частям данных.

Model registry хранит версии моделей, alias указывает на версию в проде. Выкатка и откат это перенос alias. Метаданные каждого запуска делают обучение воспроизводимым.