Что такое MLOps и зачем он нужен

Почему обученная в ноутбуке модель — это ещё не продукт, и что между ними стоит.

MLOps — это набор инженерных практик, которые превращают одноразовый эксперимент в ML-системе в воспроизводимый, автоматизированный и наблюдаемый сервис в продакшне.

Разрыв между ноутбуком и продом

Дата-сайентист открывает Jupyter, читает CSV, обучает RandomForest, видит accuracy 0.93 и радостно пишет в чат: «модель готова». На самом деле готов лишь крошечный кусок системы. Между этим ноутбуком и работающим в продакшне сервисом лежит пропасть: откуда возьмутся свежие данные, как их провалидировать, где будет жить модель, как её обновлять, кто заметит, что она деградировала, и как откатиться, если новая версия хуже старой.

Знаменитая диаграмма из статьи Google «Hidden Technical Debt in Machine Learning Systems» показывает: собственно ML-код (маленький чёрный квадрат «ML») — лишь несколько процентов реальной системы. Всё остальное — сбор данных, инфраструктура, конфигурация, мониторинг, обслуживание.

+-----------+ +------------+ +-------------+ +-------------+
|  Сбор     | |  Валидация | |  Признаки   | |  Машинные   |
|  данных   |->|  данных    |->|  (features) |->|  ресурсы    |
+-----------+ +------------+ +-------------+ +-------------+
                                                    |
   +------------------------------------------------+
   v
+-------+   +-------------+   +------------+   +-------------+
|  ML   |->|  Анализ     |->|  Сервинг   |->|  Мониторинг |
| код   |   |  процесса   |   |  модели    |   |             |
+-------+   +-------------+   +------------+   +-------------+

Что такое ML-долг

ML-долг (technical debt) — это скрытая цена быстрых решений в ML-системе, которую приходится платить позже. У ML-систем долг копится в местах, которых нет в обычном софте:

• Связанность данных. Модель зависит от входных признаков, а те — от чужих пайплайнов. Изменили формат поля в соседней команде — модель тихо сломалась.
• Каскады поправок. Чтобы исправить ошибку модели, добавляют правило-костыль, потом ещё одно. Через год это клубок, который никто не трогает.
• Невидимые потребители. На выход модели подписались сервисы, о которых вы не знаете. Меняете модель — ломаете их.
• Дрейф. Реальный мир меняется, а модель — нет. Качество падает само по себе, без единого изменения кода.

Чем MLOps отличается от DevOps

DevOps автоматизирует доставку кода. MLOps добавляет ещё две движущиеся части: данные и модель. В обычном сервисе поведение задаётся кодом — он детерминирован. В ML поведение задаётся данными, на которых модель обучилась, а данные меняются. Поэтому в MLOps версионируют не только код, но и данные, и веса модели; тестируют не только функции, но и распределения; мониторят не только латентность, но и качество предсказаний.

Как работает под капотом

MLOps — это не один инструмент, а цикл из автоматизированных этапов. Грубо: триггер (новые данные или код) запускает пайплайн обучения, который читает версионированные данные, обучает модель, прогоняет её через набор проверок качества, и если она лучше текущей — пакует в артефакт и регистрирует в реестре. Отдельный пайплайн деплоя забирает одобренную модель, оборачивает в сервис, выкатывает канареечно и подключает мониторинг. Мониторинг, обнаружив дрейф или падение качества, снова дёргает триггер обучения — круг замыкается.

Частые ошибки

• «Модель готова» = конец проекта. На деле обучение — это 10% работы; 90% — доставка и сопровождение.
• Внедрять все инструменты сразу. Команде из трёх человек не нужен Kubeflow на старте. MLOps масштабируется по уровням зрелости.
• Игнорировать данные как артефакт. Если вы не знаете, на какой версии данных обучена прод-модель, вы не сможете её воспроизвести.

Итог

• MLOps закрывает разрыв между экспериментом в ноутбуке и надёжным сервисом в продакшне.
• ML-код — малая часть системы; основное — данные, инфраструктура и мониторинг.
• В отличие от DevOps, MLOps версионирует и тестирует ещё и данные с моделью, потому что качество деградирует само.