6.2 Инженерия машинного обучения (MLOps)

Обзор и мотивация

Инженерия машинного обучения, обычно называемая MLOps, это дисциплина вывода машинного обучения из блокнотов и экспериментов в надёжные, наблюдаемые, сопровождаемые производственные системы. Традиционная программа ведёт себя так, как говорит её код. Система ML ведёт себя так, как вместе говорят её код, её данные и её выученные параметры модели. Это делает системы ML труднее для тестирования, труднее для воспроизведения и склонными тихо отказывать по мере того, как мир уходит от данных, на которых они обучались. MLOps привносит строгость программной инженерии (контроль версий, тестирование, непрерывную поставку и мониторинг) в эту трёхчастную реальность кода плюс данных плюс моделей.

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

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

См. также: глава 8.1 (CI/CD и поставка), глава 9.2 (наблюдаемость и мониторинг) и глава 6.6 (инфраструктура и эксплуатация ИИ).

Ключевые принципы

Воспринимайте данные, код и модели как совместно версионируемые артефакты; изменение любого меняет поведение системы.
Автоматизируйте путь от данных к обученной модели и развёртыванию, чтобы он был повторяем и проверяем.
Делайте каждую модель прослеживаемой до точных данных, кода и конфигурации, которые её произвели.
Оценивайте модели на репрезентативных отложенных данных до развёртывания и продолжайте оценивать после.
Предполагайте, что модели деградируют; мониторьте дрейф (постепенное расхождение живых данных или зависимостей вход-выход с тем, на чём модель обучалась), проблемы качества данных и падение производительности с первого дня.
Предпочитайте скучные воспроизводимые конвейеры хитроумным невоспроизводимым экспериментам.
Разделяйте заботы скорости экспериментов и надёжности эксплуатации и соединяйте их намеренно.

Компромиссы: плюсы и минусы

Решение	Вариант A	Вариант B	Компромисс
Шаблон обслуживания	Пакетный	Онлайн	Простота и цена против свежести и задержки
Вычисление признаков	Хранилище признаков	Конвейеры на модель	Согласованность и повторное использование против накладных расходов настройки
Платформа	Купить управляемую платформу MLOps	Собрать инструменты с открытым кодом	Скорость и поддержка против гибкости и привязки
Переобучение	По расписанию	По триггеру дрейфа	Предсказуемость против отзывчивости и сложности
Строгость воспроизводимости	Полное версионирование данных	Лёгкое отслеживание	Сила аудита против хранилища и усилий

Всеобъемлющий компромисс это вложения сейчас против хрупкости позже. Тяжёлая инфраструктура воспроизводимости и мониторинга стоит усилий заранее, но предотвращает гораздо большую цену необъяснимых отказов, невоспроизводимых моделей и подорванного доверия. Управляемые платформы ускоряют команды, но могут создавать привязку; стеки с открытым кодом дают контроль ценой работы по интеграции. Большим организациям обычно полезна общая платформенная команда, скрывающая эту сложность за умолчаниями «проторённой дороги».

Вопросы для обсуждения с командой

Как мы узнаем, что развёрнутая модель тихо деградировала, до того как пострадал клиент или гражданин, и кто владеет этим оповещением? Молчаливый распад классический режим отказа ML: код по-прежнему работает, модель по-прежнему возвращает уверенные оценки, а качество сползает по мере ухода мира от обучающих данных. Для большой команды, ведущей много моделей, это нужно ответить на модель, а не раз для парка, потому что у каждой свой профиль дрейфа и своя задержка эталонной истины. Принесите ваши текущие мониторы дрейфа данных, дрейфа концепции и поломок качества данных, пороги оповещений и ранбук, говорящий, кто откликается. В регулируемой среде, где метки приходят неделями позже, обсудите косвенные сигналы, за которыми можно следить в промежутке, потому что ожидание отложенной эталонной истины означает ожидание обнаружения вреда. Если ни один владелец не назван для оповещения о дрейфе модели, эта модель фактически не мониторится.
Если бы аудитор попросил нас воспроизвести конкретное предсказание восемнадцатимесячной давности, смогли бы мы действительно сделать это от конца до конца? Воспроизводимость это требование соответствия, прячущееся внутри хорошей инженерии: оно позволяет ведомству ответить, какая именно модель, обученная на каких данных, каким кодом произвела решение, затронувшее кого-то. Принесите настоящий пример и попытайтесь проследить его: неизменяемый снимок данных, коммит git, зафиксированные зависимости и образ контейнера, записанные начальные значения и происхождение от сырых данных через признаки к развёрнутой модели. Сигнал в том, отсутствует ли или ручное какое-либо звено цепочки. Для государства и регулируемых отраслей решите срок хранения, которого закон действительно требует, и подтвердите, что ваше хранилище сохраняет происхождение отвечаемым весь это период, поскольку пробел превращает рутинный запрос в криминалистическую аварию.
Каково наше правило вывода модели в эксплуатацию и отката и принуждается ли оно реестром или только доверием? Неуправляемое продвижение то, как эксперименты из блокнотов просачиваются в эксплуатацию и как плохая модель задерживается, потому что никто не может чисто откатить. Для многих команд разница между зрелыми и хрупкими в том, управляет ли реестр моделей продвижением с обязательным утверждением и оценкой или инженер может выкатить веса вручную. Принесите ваш текущий путь продвижения, механизм отката и свидетельства того, что теневые развёртывания или канарейки действительно работают до полного трафика. Обсудите, переобучение по расписанию или по триггеру дрейфа и проходят ли переобученные модели барьеры проверки до развёртывания, потому что переобучение на живых данных без проверки усиливает дрейф или отравление. Ответ должен принуждаться платформой, а не страницей вики, которой людям предлагается доверять.
Строим ли мы нашу платформу MLOps на инструментах с открытым кодом, покупаем управляемую или смешиваем и кто взвесил привязку? Этот выбор задаёт потолок того, как быстро выходит каждая будущая модель и сколько контроля над данными и конвейерами вы сохраняете. Управляемая платформа быстро доводит команды до эксплуатации и несёт поддержку, но может запереть ваши определения признаков, записи происхождения и артефакты моделей в проприетарном формате, который трудно покинуть; собранный стек с открытым кодом сохраняет переносимость ценой реального труда интеграции и сопровождения. Принесите совокупную стоимость владения для каждого пути (лицензия или построение, хранилище, вычисления для переобучения и платформенный персонал для эксплуатации), честную оценку способности вашей команды вести инфраструктуру и конкретный тест выхода: могли бы вы экспортировать ваш реестр, хранилище признаков и происхождение и перестроить в другом месте? В корпоративной и государственной среде добавьте ограничения закупок и правила суверенитета данных, поскольку платформа, хранящая обучающие данные в регионе или формате, который запрещает ваш регулятор, дисквалифицирована независимо от удобства.
Должны ли наше хранилище признаков и реестр моделей быть одной централизованной платформой или федеративными по командам и чего нам сегодня стоит перекос обучения и обслуживания? Централизация определений признаков устраняет перекос, когда признак вычисляется в обучении одним способом, а в обслуживании другим, что молчаливый и дорогой источник потери точности, но единая платформа может стать узким местом, замедляющим каждую команду. Федерация даёт командам автономию, умножая сантехнику и шансы, что две команды определят один признак несогласованно. Принесите свидетельства того, где перекос уже вас укусил, сколько команд повторно используют признаки против перестроения и умолчания «проторённой дороги», которые могла бы предложить общая платформенная команда. Для большой организации взвесьте выгоду управления от одной проверяемой системы учёта против цены поставки центральной очереди, а в регулируемой среде отдавайте предпочтение централизованному происхождению, позволяющему аудитору проследить любое предсказание до точного кода признака, который его произвёл.
Подобрали ли мы шаблон развёртывания каждой модели под её реальные потребности задержки, свежести и суверенитета или по умолчанию свели всё к одной форме? Пакетный, онлайн, потоковый и на краю несут очень разные эксплуатационные цену и сложность, и выбор неверного либо перерасходует на инфраструктуру реального времени, которая ночному отчёту никогда не была нужна, либо лишает оценщика мошенничества свежести, от которой он зависит. Решите по нагрузке, какой шаблон на самом деле оправдывает требование, и сопротивляйтесь стандартизации на самом сложном варианте потому, что он ощущается современным. Принесите бюджет задержки, объём, цену устаревшего ответа и задержку эталонной истины для каждой модели. В государственных и полевых условиях взвешивайте развёртывание на краю и локальное намеренно, потому что правила суверенитета данных или прерывистая связь могут вынудить модели на локальное оборудование, а этот выбор перестраивает то, как вы версионируете, мониторите и откатываете каждую выкатываемую туда модель.

Взгляд по секторам

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

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

Крупная организация. Проблема масштаб по десяткам моделей и многим командам: общее хранилище признаков, отслеживание экспериментов и реестр моделей с управляемым продвижением, чтобы группы перестали изобретать конвейеры заново. Бюджетируйте платформенную команду, предлагающую умолчания «проторённой дороги», стандартизируйте происхождение и мониторинг, чтобы каждая модель была проверяема, а каждый инцидент объясним, и управляйте «построить или купить» и привязкой намеренно за интерфейсом, сохраняющим лежащие в основе инструменты заменяемыми. Принуждайте барьеры проверки и откат в платформе, а не по соглашению.

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

Примеры

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

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

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

Бизнес-обоснование: мотивы, ROI и TCO

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

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

Антипаттерны и ловушки

Скачки от блокнота к эксплуатации. Развёртывание моделей, обученных в неуправляемых блокнотах без воспроизводимости.
Перекос обучения и обслуживания. Разный код признаков в обучении и обслуживании, вызывающий молчаливую потерю точности.
Нет версионирования данных. Версионирование кода, но не данных, так что запуски нельзя воспроизвести.
Развернул и забыл. Поставка модели без мониторинга и обнаружение деградации, только когда пользователи жалуются.
Переобучение на автопилоте. Автоматическое переобучение на живых данных без проверки, усиливающее дрейф или отравление.
Разовая инфраструктура. Каждая команда строит свой конвейер, умножая цену и хрупкость.
Игнорирование отложенных меток. Допущение, что точность можно измерить мгновенно, когда эталонная истина приходит неделями позже.

Модель зрелости

Начальный. Модели строятся стихийно в блокнотах; ручное развёртывание; нет версионирования данных или моделей; нет мониторинга; воспроизведение прошлого предсказания гадание.
Развитие. Появляются некоторое отслеживание экспериментов и реестр моделей, но практики различаются по командам; развёртывание полуавтоматизировано; базовый мониторинг охватывает несколько моделей; версионирование данных частичное, а в происхождении пробелы.
Стандартизация. Общая платформа с хранилищем признаков, реестром, воспроизводимыми конвейерами и сквозным происхождением документирована и принуждается по организации; мониторинг дрейфа и качества данных работает по моделям; продвижение и откат следуют управляемому пути, которым пользуется каждая команда.
Управление. Парк измеряется относительно базовых значений: доли дрейфа, поломки качества данных, точность модели относительно отложенной эталонной истины, перекос обучения и обслуживания, время выхода в эксплуатацию и стоимость эксплуатации на модель отслеживаются как метрики; пороги оповещений и барьеры проверки принуждаются по свидетельствам, а здоровье каждой модели пересматривается с установленной периодичностью с названным владельцем.
Оркестрация. Жизненный цикл полностью автоматизирован, проверяем и адаптивен; переобучение по триггеру дрейфа работает за барьерами проверки; «проторённые дороги» самообслуживания позволяют командам поставлять безопасно; непрерывная оценка связывает производительность моделей с бизнес-метриками, а платформа интегрирована с поставкой, риском и соответствием, так что модели регулярно выводятся, заменяются и пересматриваются по мере сдвигов данных и условий.

Идеи для обсуждения

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

Главные выводы

Поведение ML складывается из кода плюс данных плюс моделей; версионируйте и управляйте всеми тремя вместе.
Хранилища признаков, отслеживание экспериментов и реестры хребет воспроизводимого ML.
Происхождение делает модели проверяемыми, а инциденты объяснимыми: существенно в регулируемой среде.
Выбирайте пакетный, онлайн, потоковый или на краю по потребностям задержки, свежести и суверенитета.
Модели деградируют; мониторинг дрейфа, качества данных и распада не необязателен.

Источники и дополнительное чтение

Chip Huyen, Designing Machine Learning Systems.
Andriy Burkov, Machine Learning Engineering.
D. Sculley et al., Hidden Technical Debt in Machine Learning Systems.
Mark Treveil et al., Introducing MLOps.
Valliappa Lakshmanan, Sara Robinson, and Michael Munn, Machine Learning Design Patterns.
Emmanuel Ameisen, Building Machine Learning Powered Applications.

6.2 Инженерия машинного обучения (MLOps)

Обзор и мотивация

Ключевые принципы

Рекомендации

Управляйте полным жизненным циклом ML явно

Используйте хранилища признаков, отслеживание экспериментов и реестры моделей

Делайте данные и модели воспроизводимыми и версионируемыми с происхождением

Выбирайте шаблоны развёртывания под нагрузку

Мониторьте дрейф, деградацию и качество данных