Что такое MLOps

Модель как часть сервиса

ML-модель — программа, которую не пишут руками, а получают из данных. Возьмём пример, который пройдёт через весь трек: интернет-магазин хочет заранее знать, какие клиенты скоро перестанут покупать. Такой уход клиентов называют churn (отток).

Data scientist, специалист по анализу данных, берёт историю клиентов за два года. По ней он обучает модель: алгоритм подбирает внутренние числа модели, её веса, так, чтобы модель угадывала, кто из клиентов в прошлом ушёл. Результат сохраняется в файл, например model.pkl.

Сервис загружает этот файл и для каждого клиента считает ответ: «уйдёт с вероятностью 0.82». Работу модели на новых данных называют inference.

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

Feature

Модель не читает строку из базы целиком. Ей на вход подают числа, которые описывают клиента: число заказов за 30 дней, средний чек, дней с последней покупки. Каждое такое число называют feature (признак).

Feature считают из сырых данных кодом. Из таблицы заказов получается orders_30d = 3, avg_check = 1850, days_since_last = 12. Этот код важен не меньше самой модели, дальше будет видно почему.

MLOps

Data scientist обычно обучает модель в Jupyter notebook. Это файл, в котором код разбит на ячейки, и результат каждой ячейки виден сразу под ней. Удобно для экспериментов, но notebook не сервис.

MLOps — набор практик, которые доводят модель из notebook до прода (production, рабочего окружения с настоящими пользователями) и держат её там в рабочем состоянии. В статье Google об MLOps он определён как объединение разработки ML-систем (Dev) и их эксплуатации (Ops), по аналогии с DevOps. Отсюда те же инструменты: автоматизация, CI/CD, мониторинг. У ML-сервиса при этом есть проблемы, которых у обычного сервиса нет.

Код, данные и модель

В обычном сервисе поведение определяет код. Собрал коммит a1b2c3, получил тот же бинарник и то же поведение.

В ML-сервисе поведение определяют три вещи:

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

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

Data drift

Обычный сервис без релизов работает так же, как вчера. Модель без релизов может начать ошибаться чаще: код не менялся, поменялись данные.

Пример. Модель churn обучили на данных прошлого года. В этом году конкурент запустил доставку за час, и клиенты, которые раньше заказывали раз в неделю, стали заказывать раз в месяц. Модель видит незнакомые значения days_since_last и ошибается. В логах ошибок нет, сервис отдаёт 200 OK.

Такое изменение называют drift (дрейф). Data drift: изменились сами входные данные. Например, раньше у 80% клиентов было больше двух заказов в месяц, а теперь у 50%. Доли значений по диапазонам называют распределением feature. Drift ищут именно по изменению распределений. Concept drift: изменилась связь между входом и правильным ответом.

Мониторинг по CPU и кодам ответа drift не видит. Нужны отдельные метрики, о них урок про мониторинг.

Training-serving skew

Ещё одна поломка из той же статьи Google. Feature при обучении и в проде считают разным кодом, и значения расходятся. Это называют training-serving skew, расхождение между обучением и продом.

Пример. Data scientist при обучении считал days_since_last в Python от даты выгрузки данных. Бэкенд в проде считает его на Go от текущего момента и округляет иначе. Модель получает в проде не те числа, что видела при обучении, и ошибается чаще. От skew защищает общий код расчёта feature для обучения и для прода.

Код модели занимает мало места

В 2015 году инженеры Google опубликовали статью «Hidden Technical Debt in Machine Learning Systems». В ней есть схема: код самой модели нарисован маленьким прямоугольником, вокруг крупно нарисовано остальное. Сбор и проверка данных, расчёт feature, инфраструктура, inference, мониторинг, конфигурация. В статье Google об MLOps она приведена как рисунок 1.

Большая часть «остального» знакома DevOps-инженеру: контейнеры, Kubernetes, CI/CD, мониторинг. Новое в MLOps то, что вокруг данных и моделей.

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

Feature это число, которое подают модели на вход. Его считают из сырых данных кодом. Inference это работа обученной модели на новых данных.

Поведение ML-сервиса задают код, данные и модель. Версии нужны всем трём, Git покрывает только код.

Модель деградирует без изменений в коде из-за drift, обычный мониторинг этого не видит. Training-serving skew возникает, когда feature при обучении и в проде считают разным кодом.