Model Monitoring

В 2020 году ML-модель Zillow для прогнозирования цен на недвижимость привела к убыткам в 500 миллионов. Модель была идеально точной на момент деплоя - но рынок жилья резко изменился, а модель осталась прежней. Zillow покупал дома по завышенным ценам, потому что модель не знала, что мир вокруг неё изменился. Компания уволила 2000 сотрудников и закрыла направление. Проблема была не в алгоритме - проблема была в отсутствии мониторинга.

• **Финансовый скоринг** - банки обязаны мониторить drift кредитных моделей по требованиям регуляторов (Basel III, SR 11-7). Модель, не обновлявшаяся после экономического кризиса, одобряет рискованных заемщиков по старым правилам
• **Рекомендательные системы** - Netflix и Spotify непрерывно мониторят engagement-метрики своих рекомендательных моделей. Вкусы пользователей меняются, появляется новый контент - модель, обученная на данных прошлого года, рекомендует устаревший контент
• **Автономное вождение** - Tesla и Waymo используют shadow mode для тестирования новых моделей восприятия: новая модель работает параллельно с текущей, но не управляет автомобилем, пока не докажет свою надёжность на миллионах километров

Предварительные знания

• Model Serving: Delivering Predictions to Users

Почему модели тихо устаревают

Модель, прекрасно работающая в день запуска, может месяцами деградировать так, что этого никто не замечает, и причина почти никогда не в баге в коде. Мир, на котором она училась, продолжает двигаться. В 1986 году Джеффри Шлиммер и Ричард Грейнджер дали этому имя в работе 'Incremental Learning from Noisy Data', описав concept drift: статистическая связь между входами и целевой переменной со временем смещается, и вчерашние закономерности перестают работать. Позже практики разделили два явления. Data drift это изменение распределения входов (новый сегмент пользователей, другой датчик, праздничный сезон), даже если сама зависимость осталась прежней. Concept drift это изменение самой зависимости (тактики мошенничества эволюционируют, вкусы клиентов меняются). В любом случае модель деградирует в продакшене, пока её веса остаются замороженными. В 2014 году Гама с коллегами опубликовали обзор 'A Survey on Concept Drift Adaptation' в ACM Computing Surveys, систематизировав десятилетия методов обнаружения и адаптации в один справочник. Практический вывод неприятен: выкатить модель это начало её жизненного цикла, а не конец. Без мониторинга дрейфа точность тихо размывается, пока какая-нибудь метрика ниже по потоку наконец не закричит.

Data Drift: сдвиг входных данных

Модель обучена на данных определённого распределения: средний возраст клиентов 35 лет, средний чек 2000 рублей, 70% покупок с мобильного. Но мир меняется. Через полгода средний возраст сдвинулся к 28 (пришла молодая аудитория), средний чек вырос до 3500 (инфляция), а доля мобильных покупок стала 85%. Модель получает данные, **которых не видела при обучении**. Это и есть **data drift** - изменение распределения входных признаков P(X) со временем. Модель может продолжать работать, но её предсказания становятся менее надёжными.

Для обнаружения data drift используют **статистические тесты**, сравнивающие распределение данных при обучении и в production. Два основных: **Kolmogorov-Smirnov test (KS-test)** - измеряет максимальное расстояние между двумя кумулятивными функциями распределения. Если p-value < 0.05, распределения статистически различаются. **Population Stability Index (PSI)** - разбивает данные на бакеты и сравнивает доли: PSI < 0.1 - нет drift, 0.1-0.25 - умеренный drift, > 0.25 - значительный drift.

В 2020 году COVID радикально изменил поведение пользователей: онлайн-покупки выросли в разы, паттерны мобильного трафика перевернулись, финансовые привычки сместились. Модели, обученные на данных 2019 года, получили **внезапный data drift** и начали выдавать бессмысленные предсказания. Компании, у которых был мониторинг drift, обнаружили проблему за дни. Остальные - за месяцы убытков.

**Мониторинг drift в production - чеклист:** 1. **Сохраняйте reference dataset** - статистики обучающей выборки (среднее, дисперсия, квантили) для каждого признака 2. **Проверяйте drift регулярно** - ежедневно или на каждом батче новых данных 3. **Настройте алерты** - PSI > 0.25 или KS p-value < 0.01 для любого признака 4. **Отслеживайте все признаки** - drift в одном признаке может быть сигналом 5. **Визуализируйте тренды** - Evidently, Grafana, или custom dashboards

Concept Drift: изменение связи X и y

Data drift - это когда меняются входные данные P(X). **Concept drift** - более коварная проблема: меняется **сама зависимость** P(y|X) между входами и выходами. Те же самые входные признаки теперь означают другой результат. Пример: клиент с доходом 100K и возрастом 30 лет в 2019 году с вероятностью 70% одобрялся для кредита. После экономического кризиса тот же профиль имеет вероятность одобрения 40%. Входы не изменились - изменилась реальность, которую моделируем.

**Sudden drift** - резкое изменение правил: COVID, новый закон, смена алгоритма платформы. Accuracy падает мгновенно. **Gradual drift** - медленный сдвиг: вкусы пользователей, экономические тренды. Модель деградирует незаметно, по 0.1% в неделю - за полгода accuracy снижается на 3%, и никто не замечает. **Recurring drift** - циклические паттерны: сезонные изменения, рабочие/выходные дни. Модель, обученная на летних данных, плохо работает зимой - и наоборот.

**ADWIN (Adaptive Windowing)** - продвинутый алгоритм обнаружения drift: - Поддерживает окно наблюдений переменного размера - Автоматически разбивает окно на две части и сравнивает средние - Если разница статистически значима - drift обнаружен, старая часть окна отбрасывается - Не требует настройки размера окна - адаптируется автоматически Библиотеки: **river** (Python), **scikit-multiflow** - содержат ADWIN, DDM, EDDM и другие методы обнаружения drift.

Выбор стратегии зависит от типа drift. При **sudden drift** - triggered retraining с коротким окном, чтобы быстро адаптироваться к новой реальности. При **gradual drift** - sliding window или exponential decay, чтобы плавно смещать фокус на свежие данные. При **recurring drift** - ансамбль моделей, обученных на разных периодах, с автоматическим переключением. Главное правило: **нельзя просто переобучить на всех данных** - старые паттерны разбавят новые.

Shadow Mode: тестирование без риска

Вы обнаружили concept drift, переобучили модель на свежих данных, метрики на тестовой выборке выросли. Можно деплоить? **Не спешите.** Тестовая выборка - это лабораторные условия. Production - это реальный трафик с выбросами, edge cases и непредсказуемым поведением пользователей. **Shadow mode** - способ протестировать новую модель на реальном трафике **без влияния на пользователей**.

Shadow mode - это **A/B-тестирование для ML**, но безопаснее. В классическом A/B-тесте часть пользователей видит результаты новой модели - если модель плохая, эти пользователи пострадают. В shadow mode **ни один пользователь не видит предсказания shadow-модели**. Мы собираем данные, сравниваем, и только убедившись в превосходстве shadow-модели, переходим к следующему этапу - canary deployment.

**Когда shadow mode обязателен:** - **Финансовые решения** - кредитный скоринг, страхование, ценообразование. Ошибка = прямые убытки - **Медицинские модели** - диагностика, прогноз лечения. Ошибка = риск для здоровья - **Рекомендательные системы** - feed, поиск. Плохие рекомендации = потеря пользователей **Когда можно пропустить:** - Внутренние инструменты с низким impact - Модели с простым и быстрым откатом - A/B-тест с маленькой аудиторией (1-2%)

Важный нюанс: shadow mode увеличивает нагрузку на инфраструктуру - каждый запрос обрабатывается **дважды**. Для моделей с высоким latency (например, LLM) это может быть дорого. В таких случаях shadow mode запускают не на 100% трафика, а на выборке (например, 10%). Главное - чтобы выборка была **репрезентативной** и достаточно большой для статистической значимости.

Canary Deployment: постепенный rollout

Shadow mode подтвердил: новая модель лучше. Время деплоить. Но переключить 100% трафика мгновенно - рискованно. Shadow mode тестировал модель в режиме "только чтение", а в production модель влияет на реальные решения, и могут вскрыться проблемы, которых не было в shadow. **Canary deployment** - стратегия постепенного развёртывания: сначала 1% трафика, потом 5%, потом 25%, и только потом 100%. На каждом этапе мониторим метрики и откатываемся при деградации.

**Blue-green deployment** - альтернативный подход: два идентичных окружения (blue и green). В любой момент одно из них обслуживает трафик, второе - на паузе. Деплоим новую модель в неактивное окружение, тестируем, и переключаем весь трафик разом. Если проблема - мгновенный откат обратно. Проще canary, но без постепенного наращивания трафика.

**Feature flags для ML-моделей** - удобный инструмент: - **Процентный rollout:** 1% пользователей видят model v2, остальные - v1 - **Сегментный rollout:** новая модель только для premium-пользователей - **Kill switch:** мгновенное отключение без передеплоя - переключаем флаг в конфигурации - **Инструменты:** LaunchDarkly, Unleash, Flagsmith, или самописное решение на Redis Feature flags позволяют разделить **деплой кода** (новая модель в production) и **релиз функции** (модель начинает обслуживать трафик). Код деплоится, но флаг выключен - включаем когда готовы.

Итоги

• **Data drift** - изменение распределения входных данных P(X) со временем. Обнаруживается статистическими тестами: KS-test сравнивает распределения, PSI > 0.25 сигнализирует о значительном сдвиге. Библиотека Evidently автоматизирует мониторинг всех признаков
• **Concept drift** - изменение связи P(y|X) между входами и выходом. Коварнее data drift, потому что входы выглядят нормально, но предсказания деградируют. Обнаруживается мониторингом метрик качества и алгоритмами типа ADWIN. Стратегии переобучения: sliding window, exponential decay, triggered retraining
• **Shadow mode** - безопасное тестирование новой модели на реальном трафике без влияния на пользователей. Обе модели обрабатывают запросы, но пользователь видит только ответ текущей модели. Статистическая значимость через McNemar's test подтверждает, что разница не случайна
• **Canary deployment** - постепенный rollout (1% -> 5% -> 25% -> 100%) с автоматическим откатом при деградации метрик. Feature flags разделяют деплой кода и релиз функции. Помните Zillow: модель без мониторинга и обновления - это не ML-система, это тикающая бомба

Связанные темы

Model monitoring замыкает цикл MLOps - от разработки модели до непрерывного улучшения в production:

• Model Serving — Предыдущий этап pipeline: модель задеплоена и обслуживает трафик. Model monitoring начинается сразу после деплоя - без serving нечего мониторить, без мониторинга serving деградирует со временем
• MLOps Pipeline — Model monitoring - обратная связь в MLOps pipeline: обнаружение drift запускает автоматическое переобучение, которое проходит через весь pipeline (данные, обучение, валидация, деплой) по кругу

Вопросы для размышления

• Почему concept drift опаснее data drift? В каких ситуациях data drift есть, но concept drift отсутствует, и наоборот?
• Компания деплоит ML-модель, которая принимает решения о выдаче кредитов. Какой минимальный pipeline мониторинга вы бы выстроили, и какие метрики отслеживали?
• Shadow mode удваивает нагрузку на инфраструктуру. Как бы вы организовали shadow-тестирование для LLM, где inference стоит 0.01 за запрос при 1 миллионе запросов в день?

Связанные уроки

• ml-46-model-serving — Мониторинг следит за развёрнутыми моделями
• ml-45-mlops-pipeline — Мониторинг замыкает цикл MLOps
• ml-53-ab-testing-ml — Данные мониторинга питают A/B-решения
• stat-05-hypothesis — Детекция дрейфа использует статтесты
• sd-22-observability — ML-мониторинг похож на observability систем