Модель может исправно отвечать на запросы и одновременно терять практическую ценность. Срок деградации заранее неизвестен: в одном процессе изменения накапливаются месяцами, в другом качество меняется после новой тарифной политики, поставщика данных или правила работы с клиентами.
Что меняется после запуска
На тесте модель оценивают по зафиксированной выборке. В эксплуатации меняются входные данные, доли сегментов и сам процесс, который формирует целевое событие. Возможны несколько разных проблем.
Data drift означает изменение распределения признаков. Например, выросла доля новых клиентов или изменилась структура ассортимента. Concept drift возникает, когда прежняя связь между признаками и результатом ослабевает. Training-serving skew появляется при расхождении подготовки данных в обучении и промышленном контуре. Есть и обычные инженерные причины: пропуски, смена схемы, задержка витрины или ошибка преобразования.
Эти случаи требуют разных реакций. Дрейф признаков сам по себе не доказывает падение качества. Стабильное распределение входа тоже не гарантирует правильный прогноз. Нужны технические и бизнес-сигналы.
Что входит в рабочий контур MLOps
Воспроизводимость связывает версию кода, данных, признаков, параметров и модели. Реестр моделей показывает, что находится в эксплуатации и кто согласовал выпуск. Автоматизированная проверка входа ловит пропуски, неожиданные категории и нарушение схемы до расчета прогноза.
Мониторинг сервиса отвечает за доступность, задержку и ошибки. Мониторинг модели следит за распределением признаков, прогнозов и качеством после появления фактического результата. Если метка приходит через два месяца, команда заранее выбирает промежуточные сигналы и не выдает их за итоговое качество.
Для отката нужна предыдущая рабочая версия, совместимая со схемой данных. Сам файл модели без проверенного конвейера и конфигурации отката проблему не решает.
Шесть вопросов до промышленного запуска
- Какая версия данных, кода и модели сейчас работает?
- Какие нарушения входных данных блокируют расчет?
- Когда появляется фактический результат для оценки качества?
- Какие технические и бизнес-метрики контролируются?
- Кто принимает решение об остановке, откате или переобучении?
- Сколько времени процесс может работать в деградировавшем режиме?
Ответ «переобучим, когда качество упадет» неполон. Нужно определить способ расчета качества, окно наблюдения, минимальный объем данных и допустимую задержку метки.
Как задавать пороги
Универсальных значений для drift score или accuracy нет. Порог зависит от цены ошибок и стабильности процесса. В кредитном решении важны ошибки по отдельным группам и юридические ограничения. В прогнозе спроса — потери от дефицита и излишка. В рекомендации контента допустимый риск может быть другим.
Порог фиксируют на исторических данных и проверяют в теневом режиме. Вместе с ним задают действие: уведомление, ручную проверку, переход на резервное правило или откат. Сигнал без владельца и процедуры быстро превращается в шум.
Теневой запуск, canary и резервное правило
При теневом запуске новая модель считает прогнозы, но не влияет на процесс. Команда сравнивает ее с действующей системой на одинаковых данных. Canary-схема направляет на новую версию ограниченную долю потока и позволяет остановить выпуск до того, как ошибка затронет всех пользователей.
Для критичного процесса нужен резервный режим: предыдущая модель, простое правило или ручное решение. Его качество может быть ниже штатного, зато поведение известно. Выбор резервного варианта фиксируют до инцидента вместе с допустимым временем работы.
Модель нужно сравнивать с базовой линией
Сложная модель имеет смысл, если дает устойчивое улучшение относительно простого правила и это улучшение покрывает стоимость эксплуатации. Базовой линией может быть прошлое значение, медиана сегмента, линейная модель или действующее бизнес-правило. Сравнение проводится на одном временном окне и по метрике, связанной с решением.
Как разбирать инцидент
После сбоя команда восстанавливает входные данные, версию признаков, модели и последующего правила. Затем отделяет техническую ошибку от изменения процесса и проверяет, сработали ли контроль и эскалация. Итогом разбора становится изменение теста, порога или процедуры. Формулировка «переобучили модель» сама по себе не предотвращает повторение.
Что измерять после запуска
- долю запросов с нарушением схемы данных;
- задержку и доступность сервиса;
- распределение ключевых признаков и прогнозов;
- качество на данных с известным результатом;
- долю ручных исправлений;
- время от сигнала до решения;
- влияние ошибок на процесс и деньги.
MLOps не обещает, что модель перестанет ошибаться. Он делает изменения наблюдаемыми и позволяет восстановить, какая версия системы приняла конкретное решение.
Источник
