Большинство проектов машинного обучения не доходят до боевой эксплуатации. Дата-сайентист обучает модель в Jupyter-ноутбуке, показывает заказчику метрику точности и на этом всё останавливается. Между прототипом на ноутбуке и сервисом, который ежедневно обрабатывает заявки клиентов или документы ведомства, лежит пропасть. Закрывает её дисциплина, которую сейчас называют MLOps: перенос практик DevOps на жизненный цикл моделей.

Почему модель ломается по дороге в продакшн

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

Типичные точки отказа, которые мы видим в проектах:

  • Несовпадение окружений. Модель училась на одной версии библиотек, а на сервере стоит другая – предсказания «плывут».
  • Расхождение данных обучения и боевых данных. В ноутбуке признаки считались одним скриптом, в продакшене – другим. Это классическая training-serving skew.
  • Отсутствие версий. Никто не знает, на каком датасете и с какими гиперпараметрами получена модель, которая сейчас крутится в бою.
  • Деградация качества. Реальные данные дрейфуют, а модель не переобучается, и точность тихо падает месяцами.

Что выстраивает MLOps-конвейер

Зрелый процесс собирает разрозненные шаги в воспроизводимый конвейер. Опорные элементы такие.

Версионирование всего. Не только код в Git, но и данные, и сами модели. Для этого появились инструменты вроде DVC и MLflow – они фиксируют, какой датасет и какой запуск обучения дали конкретный артефакт.

Автоматизация обучения и упаковки. Обучение запускается по триггеру, модель упаковывается в контейнер с зафиксированными зависимостями. Docker и оркестрация в Kubernetes снимают проблему «у меня на машине работало».

Сервис предсказаний. Модель выставляется как API. В архитектуре с событийной шиной запросы на скоринг удобно гонять асинхронно – здесь помогает событийно-ориентированный подход и ESB, когда модель подписывается на поток данных и публикует результаты обратно.

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

Для госсектора добавляется ещё одно требование – прослеживаемость. Регулятору и внутреннему аудиту нужно показать, на каких данных принято автоматическое решение и кто отвечает за модель. Это близко к задачам, которые решает переход на электронный документооборот: фиксируется полная история и ответственность за каждый артефакт.

С чего начать

Не стройте платформу целиком сразу. Возьмите одну модель, доведите её до боевого сервиса со всем конвейером – версии, контейнер, API, мониторинг и масштабируйте подход на остальные. Промышленное внедрение ИИ закономерно попало в ключевые ИТ-тренды 2019 года: рынок переходит от экспериментов к эксплуатации, и выигрывают те, кто умеет держать модели в продакшене стабильно.

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

Вывод

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