Как мониторить ML-модель в проде и что делать при дрейфе данных?
Короткий ответ
- Data drift: распределение входов ушло от обучающего
- Concept drift: изменилась сама зависимость таргета от признаков
- Истинные метки часто приходят с задержкой
- Прокси-сигналы: распределение скоров, PSI, KS по признакам
- Мониторить и сервисные метрики: латентность, долю ошибок
- Алерты с порогами и регламент реагирования
- Ответ на дрейф: расследование, переобучение, откат
Мониторинг модели — это слежение за входами, скорами и отложенными метриками качества с алертами, а реакция на дрейф — расследование причины, переобучение или откат.
Как сказать вслух
пример ответаВ проде я слежу за тремя слоями: техника — латентность и ошибки сервиса, данные — не уехали ли распределения признаков и доля пропусков, и качество — метрики модели, когда подъезжают истинные ответы. Так как метки часто запаздывают, между ними смотрю на прокси вроде распределения скоров. Если дрейф подтвердился, сначала разбираюсь в причине — бывает, что просто сломался источник данных, — и только потом переобучаю модель на свежих данных.
Подробный ответ
Основной ответ
Мониторинг ML-сервиса строится слоями. Сервисный: латентность, throughput, доля ошибок, доступность фич в момент запроса. Данные: распределения входных признаков против обучающих (PSI, KS-тест, JS-дивергенция), доля пропусков и новых категорий — это ловит и дрейф, и поломки апстрим-пайплайнов. Выход модели: распределение скоров и доля позитивных решений — дешёвый ранний индикатор. Качество: настоящие метрики считаются, когда приходит ground truth, часто с лагом в дни и недели, поэтому строится пайплайн отложенного джойна предсказаний с фактами. Различают data drift (сместились входы) и concept drift (изменилась зависимость P(y|x)) — второй опаснее и виден только по метрикам качества. Реакция: алерт → расследование причины (сломанный источник, сезонность, реальное изменение мира) → переобучение по расписанию или триггеру, через полный цикл валидации, → при деградации откат на предыдущую версию.
Ключевые моменты
- Data против concept drift. Сместившиеся входы можно увидеть сразу; изменение самой зависимости — только по отложенным меткам.
- Прокси до ground truth. Распределение скоров, PSI по признакам и доля решений сигналят о проблемах задолго до метрик качества.
- Дрейф не равен поломке. Половина «дрейфов» — сломанный источник данных или изменение формата; сначала диагноз, потом переобучение.
- Автоматизация реакции. Регламент: пороги алертов, ответственные, пайплайн переобучения с валидацией и безопасный откат.
Практический контекст
Ключевой вопрос для senior DS и ML-инженеров: модель в проде живёт годами, и умение поддерживать её важнее умения обучить. Интервьюер проверяет системность: слои мониторинга, работа с запаздывающими метками, различение причин дрейфа. Плюсом будет упоминание инструментов (Evidently, собственные дашборды, алерты в мессенджер) и конкретной истории инцидента с моделью.
Частые ошибки
- Сводят мониторинг к «смотрим accuracy», игнорируя задержку истинных меток
- Переобучают модель при каждом алерте, не расследовав причину дрейфа
- Не различают дрейф данных и дрейф концепции и не мониторят сам входной пайплайн