Дрейф модели: почему ML-система деградирует без видимых сбоев
Модели машинного обучения в продакшне теряют точность со временем - тихо, без ошибок и алертов. Что такое дрейф и как за ним следить.
Одно из самых неприятных свойств ML-систем в продакшне - они могут деградировать без единого инцидента в системе мониторинга. Сервис отвечает, latency в норме, ошибок нет. Просто рекомендации становятся хуже, скоринг - менее точным, прогнозы - менее релевантными. Пока это не начнёт сказываться на бизнес-метриках, никто может не заметить.
Это явление называется дрейфом модели. Оно системное, и с ним сталкивается большинство команд, которые переводят ML из пилота в эксплуатацию.
Откуда берётся дрейф
Модель обучается на исторических данных. Когда мир меняется - меняется и распределение данных, на которых модель должна работать. Есть два основных типа:
Data drift - изменились входные данные. Пользователи стали вести себя иначе, изменился ассортимент, сезон, внешние условия. Модель видит данные, которые отличаются от обучающей выборки, и начинает работать хуже.
Concept drift - изменилась сама зависимость между признаками и целевой переменной. Например, модель скоринга кредитов обучалась до периода роста процентных ставок. После ставки изменились - то, что раньше предсказывало платёжеспособность, уже не работает так же.
Оба типа дрейфа случаются постепенно и без явных маркеров.
Почему стандартный мониторинг не помогает
Классический мониторинг приложений отслеживает системные метрики: доступность, время ответа, количество ошибок. Для ML этого недостаточно.
Качество модели - это не системная метрика, это статистическая характеристика. Чтобы её отслеживать, нужно:
- знать «правильный ответ» для части предсказаний (ground truth);
- сравнивать распределение входных данных с обучающей выборкой;
- считать метрики качества на живом трафике, а не только на тестовой выборке.
Многие команды делают последнее только в момент выкатки новой версии модели - и пропускают то, что происходит в промежутке.
Что помогает обнаружить дрейф раньше
Практические подходы, которые я видел в работающих системах:
Shadow scoring. Новая версия модели работает параллельно со старой на реальных данных без влияния на результат. Расхождение предсказаний - сигнал для анализа.
Мониторинг распределения признаков. Следить за статистическими характеристиками входных данных - средними, квантилями, долями категорий. Значимое отклонение от обучающей выборки - повод пересмотреть модель.
Отложенная разметка. Для части предсказаний собирать фактический исход через время и считать точность на этой выборке. Требует дисциплины в процессе сбора данных, но даёт прямую меру качества.
Бизнес-метрики как косвенный сигнал. Конверсия, возвраты, уровень жалоб - всё это может косвенно отражать деградацию модели до того, как она станет очевидной в технических метриках.
Организационный вопрос
Дрейф модели - это не проблема, которую решают один раз при деплое. Это постоянная операционная задача. Кто за неё отвечает - ML-инженер, дата-аналитик или продуктовая команда - зависит от устройства конкретной компании.
Важно только, чтобы этот вопрос был поставлен до того, как модель уйдёт в продакшн. «Мы переобучим, когда заметим деградацию» - это план без метрик и без триггеров. Такой план часто срабатывает с опозданием в несколько месяцев.