Признаки считаются по-разному при обучении и в проде
В блокноте средний чек считается по всем заказам, а в сервисе — по оплаченным. Модель получает на входе не те данные, на которых училась, и выдаёт ерунду.
ML-модели и MLOps
Модель — это сервис, у которого есть версии и метрики
Разрабатываем модели вместе с инфраструктурой вокруг них: единый Feature Store, воспроизводимые пайплайны обучения, версионирование артефактов, автоматическое переобучение по расписанию и триггерам, мониторинг качества в проде.
Или сразу: +7 (962) 368-39-51 Telegram
MLflow
реестр моделей и экспериментов
Airflow
воспроизводимые пайплайны обучения
drift
контроль деградации после запуска
rollback
откат на предыдущую версию за минуты
Почему модели не доживают до продакшена
Типовые причины, по которым ноутбук аналитика остаётся единственным местом, где модель работает.
Невозможно воспроизвести результат
Через полгода никто не может сказать, на каких данных и с какими параметрами получена модель в проде. Обновить её или откатить — целое расследование.
Качество никто не измеряет после запуска
Метрики посчитали один раз на тестовой выборке перед сдачей. Что происходит с моделью через три месяца, не знает никто.
Переобучение делают вручную
Данные обновились, а модель осталась прежней: никто не помнит, что её пора переучить. Автоматизация процесса отсутствует, и обновление откладывается месяцами.
Обучение и инференс конкурируют за ресурсы
Обучение на той же машине, где работает сервис, приводит к тому, что переобучение модели роняет прод. Разделение контуров не заложено заранее.
Датасеты никто не версионирует
Выгрузка перезаписана, старая выборка утеряна, а вместе с ней — возможность сравнить новую модель с предыдущей на одном наборе данных.
Что входит в разработку
Четыре слоя ML-платформы, которые мы разворачиваем вместе с моделью.
Данные и Feature Store
Создаём единый слой признаков, который используется и при обучении, и при инференсе — это устраняет главный источник расхождений.
- Витрины признаков с ежедневным и почасовым обновлением
- Онлайн-хранилище для быстрого чтения при запросе
- Документирование признаков: смысл, источник, окно расчёта
- Контроль качества данных: пропуски, дубли, аномальные значения
Обучение и эксперименты
Пайплайны обучения оформлены как код и запускаются одинаково на любой машине — от ноутбука разработчика до кластера.
- Конфигурация экспериментов и подбор гиперпараметров
- Кросс-валидация, соответствующая природе данных
- Фиксация версий кода, данных и параметров каждого запуска
- Реестр экспериментов с метриками и артефактами в MLflow
Инференс и развёртывание
Модель превращается в сервис с понятным контрактом: HTTP или gRPC, батчевый режим, предсказуемая задержка.
- Упаковка модели в контейнер с зафиксированными зависимостями
- Батчевый инференс для больших выгрузок
- Канареечный выпуск новой версии на часть трафика
- Мгновенный откат при ухудшении метрик
Мониторинг и переобучение
После запуска система сама сообщает, когда качество падает или входные данные меняются.
- Дашборд фактических метрик качества по периодам
- Контроль дрейфа признаков и целевой переменной
- Триггеры переобучения: по расписанию и по деградации
- Журнал версий модели в проде и причинах переключения
Порядок работ
Сначала инфраструктура и данные, затем модель: обратный порядок приводит к переделке.
-
01 1–2 недели
Аудит данных и требований
Определяем целевую метрику, допустимую задержку, объём запросов и требования к среде исполнения.
-
02 3–5 недель
Витрины и признаки
Собираем данные в витрины, описываем признаки, настраиваем их регулярный пересчёт и контроль качества.
-
03 3–4 недели
Модель и валидация
Обучаем модель, сравниваем с бейзлайном, проверяем на отложенном периоде и фиксируем версию в реестре.
-
04 2–4 недели
Прод и сопровождение
Разворачиваем сервис, подключаем мониторинг, настраиваем переобучение и передаём регламент эксплуатации.
Why Feature Store решает проблему расхождения признаков
Классическая причина деградации модели после вывода в прод — training-serving skew: признаки при обучении считаются одним кодом и по одним правилам, а при инференсе — другим кодом и по другим. Разница может быть незаметной: иначе обработанные пропуски, другой часовой пояс, иная фильтрация отменённых заказов. Модель получает на входе не то, на чём училась.
Feature Store устраняет расхождение тем, что и обучение, и инференс читают одни и те же заранее рассчитанные признаки. Дополнительный плюс — переиспользование: признак, посчитанный для одной модели, доступен для другой, и команда не тратит время на повторную реализацию одной и той же логики.
Как мы контролируем дрейф модели
Дрейф бывает двух видов. Data drift — изменение распределения входных данных: например, в систему начали приходить заявки нового типа, которых не было при обучении. Concept drift — изменение самой зависимости между признаками и целевой переменной: поведение клиентов изменилось, и старая закономерность больше не работает.
Первый тип отслеживается без разметки: сравниваем распределения признаков с обучающей выборкой статистическими тестами и следим за долей значений вне наблюдаемого диапазона. Второй требует фактических исходов, которые узнаются с задержкой, поэтому мы строим мониторинг на отложенных метриках и настраиваем алерт, когда расхождение между прогнозом и фактом превышает согласованный порог.
Сколько стоит содержать ML-систему в год
Стоимость эксплуатации складывается из трёх частей: инфраструктура, сопровождение и переобучение. Инфраструктура зависит от объёма запросов и требований к задержке: батчевый ночной пересчёт на обычном сервере стоит несопоставимо дешевле онлайн-инференса на GPU. Сопровождение — это мониторинг, разбор инцидентов и текущие доработки.
Отдельная статья — переобучение и повторная валидация. Если правила меняются часто или поведение клиентов нестабильно, обновлять модель приходится ежемесячно, и это нужно планировать как регулярную работу, а не как разовый проект. Мы всегда закладываем эти расходы в бизнес-кейс, чтобы решение принималось по полной стоимости владения.
Частые вопросы
MLOps — это набор практик, которые делают работу модели воспроизводимой и управляемой: версионирование данных и моделей, автоматизация обучения, мониторинг качества, контролируемое развёртывание. Небольшой команде он нужен ровно так же, как и крупной: без него обновление модели превращается в рискованный ручной процесс, а понять, почему вчерашний прогноз отличался от сегодняшнего, не удаётся.
Зависит от скорости изменения данных. Для задач с сезонностью и стабильным поведением достаточно ежемесячного переобучения по расписанию. Там, где поведение меняется быстро, добавляются триггеры: падение метрики ниже порога, значимый дрейф входных данных, появление нового сегмента клиентов. Каждое переобучение обязательно сопровождается проверкой на отложенном периоде — обновление без валидации опаснее устаревшей модели.
Можно, если данные допускают передачу внешнему провайдеру и стоимость запросов укладывается в бюджет. Облачные сервисы выигрывают на старте: не нужно разворачивать инфраструктуру, доступны управляемые хранилища признаков и реестры моделей. Собственный контур выигрывает при больших объёмах однотипных запросов и при жёстких требованиях к защите данных. Часто оптимален гибрид: обучение в облаке, инференс в закрытом контуре заказчика.
Три сигнала, которые мы настраиваем сразу: рост доли отказов сервиса или таймаутов, изменение распределения входных данных относительно обучающей выборки и снижение фактического качества на размеченных данных, которые поступают с задержкой. Первые два видны без разметки и срабатывают быстро, третий подтверждает проблему. Все три выводятся на один дашборд с алертами, чтобы деградацию замечала система, а не клиент.
Разработка AI-решений: другие направления
Смежные задачи, которые обычно решаются в одном проекте с этой.
Модель уже есть, но в прод не попадает?
Опишите задачу и текущее состояние данных — предложим план: что нужно доделать, чтобы модель работала как сервис, и сколько это займёт.