MLOps: выкат и мониторинг

Проверьте себя

Пять вопросов из банка по этой подтеме. Всего их 14, остальные разбираются в тренажёре.

1. #deploy_monitoring1 / 5
   Зачем мониторить распределение входных фич в проде, если можно просто следить за accuracy?

   A)Метки приходят с задержкой или не приходят вовсе; дрифт фич — ранний сигнал до падения качества

   B)Распределение входных признаков не способно меняться после выката модели в продакшен вообще

   C)Accuracy в проде считается мгновенно по каждому запросу, поэтому дополнительный мониторинг фич не нужен совсем

   D)Мониторинг фич заменяет собой необходимость считать метрики качества самой модели

   показать ответ и разбор

   +A)Метки приходят с задержкой или не приходят вовсе; дрифт фич — ранний сигнал до падения качества

   // разбор: Чтобы посчитать accuracy, нужны истинные метки, а они приходят с лагом (кредит «созреет» месяцами) или не приходят совсем — тогда падение качества заметишь слишком поздно. Распределения входных фич и предсказаний доступны сразу: их дрифт (PSI, KS) сигналит о проблеме заранее, ещё до того как метрика формально просядет. Это дополнение к метрике, а не замена.

2. #deploy_monitoring2 / 5
   Истинные метки приходят с лагом в две недели. На что смотреть, чтобы поймать деградацию модели раньше?

   A)Ни на что: остаётся ждать полные две недели до появления настоящих меток и считать метрику

   B)На среднюю загрузку CPU и объём потребляемой сервисом оперативной памяти на серверах

   C)На суммарное число запросов к сервису в секунду без анализа их содержимого и предсказаний

   D)На дрифт входных фич и распределение предсказаний (PSI) плюс бизнес-прокси — они доступны сразу

   показать ответ и разбор

   +D)На дрифт входных фич и распределение предсказаний (PSI) плюс бизнес-прокси — они доступны сразу

   // разбор: Когда метки запаздывают, качество напрямую не посчитать, поэтому опираются на доступные немедленно прокси: дрифт распределений входных фич и самих предсказаний (доля класса, средний скор), ранние бизнес-сигналы (конверсия, жалобы). Резкий сдвиг PSI по ключевым фичам или скачок доли предсказанного класса — повод бить тревогу, не дожидаясь меток. CPU и RPS про здоровье сервиса, а не модели.

3. #deploy_monitoring3 / 5
   PSI по всем входным фичам в норме, но модель в проде явно поехала. Что могло произойти?

   A)Concept drift: сместилась зависимость y|x при тех же распределениях x — мониторинг входов слеп к этому

   B)Ничего не могло произойти: если PSI по фичам в норме, модель работает корректно

   C)Возможная причина — в продакшене закончилось свободное место на диске под логи предсказаний

   D)Обязательно выросло среднее время ответа сервиса, и якобы именно поэтому упало качество предсказаний модели

   показать ответ и разбор

   +A)Concept drift: сместилась зависимость y|x при тех же распределениях x — мониторинг входов слеп к этому

   // разбор: PSI по входам ловит только смену распределения x (covariate shift). Но качество зависит и от P(y|x): связь фичи→таргет могла измениться при тех же распределениях фич (concept drift) — например, поменялось поведение пользователей. Мониторинг входов это не видит. Ещё варианты: битый маппинг категорий в фича-пайплайне, утечка, сместившийся порог. Нужен мониторинг предсказаний и, как метки подъедут, самой метрики.

4. #deploy_monitoring4 / 5
   Что в первую очередь мониторят на ВХОДЕ модели в проде, помимо самих предсказаний?

   A)Загрузку CPU и памяти сервера — качество входных данных на работу самой модели не влияет

   B)Число запросов в секунду; содержимое и корректность самих входных данных проверять не нужно

   C)Версию библиотеки, которой была сериализована модель, — этого достаточно для здоровья сервиса

   D)Качество входных данных: соответствие схемы, доля пропусков и аномалий, диапазоны и распределения фичей

   показать ответ и разбор

   +D)Качество входных данных: соответствие схемы, доля пропусков и аномалий, диапазоны и распределения фичей

   // разбор: Модель молча выдаёт мусор, если на вход пришли битые данные: сменилась схема, подскочила доля NULL, значение вышло за исторический диапазон, распределение фичи уплыло. Поэтому мониторят качество входа — схему и типы, долю пропусков/аномалий, диапазоны и распределения (PSI/KS) — и алертят до того, как это ударит по метрике. Нагрузка сервера и RPS важны для инфраструктуры, но не заменяют контроль данных.

5. #deploy_monitoring5 / 5
   Как различают data drift, prediction drift и concept drift, и зачем это на практике?

   A)Это три разных названия одного явления — деградации модели; разделять их на практике совершенно незачем

   B)Уплыл вход, уплыло распределение предсказаний, изменилась связь X→Y — каждый ловится и лечится по-разному

   C)Все три означают рост задержки инференса и лечатся добавлением новых серверов в кластер

   D)Различаются лишь тем, на каком именно сервере они замечены, но на выбор действий по починке это никак не влияет

   показать ответ и разбор

   +B)Уплыл вход, уплыло распределение предсказаний, изменилась связь X→Y — каждый ловится и лечится по-разному

   // разбор: Data drift — уплыло распределение ВХОДНЫХ фичей; prediction drift — сместилось распределение ВЫХОДОВ модели (ранний косвенный сигнал); concept drift — изменилась сама зависимость таргета от фичей P(Y|X), при этом вход мог не меняться. Различать важно: data drift виден по входу и иногда переживаем, concept drift заметен только по меткам и обычно требует переобучения. Это не про латентность и не про «где замечено».