ML System Design: мониторинг и дрифт

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

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

1. #monitoring_drift1 / 5
   Чем concept drift отличается от data drift и почему различие практично?

   A)Concept drift и data drift — это на самом деле просто полные синонимы одного и того же явления

   B)Data drift — сдвиг P(X) при прежней связи; concept drift — сдвиг P(Y|X)

   C)Concept drift встречается лишь в задачах обработки текста (NLP)

   D)Data drift во всех без исключения случаях опаснее, чем concept drift

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

   +B)Data drift — сдвиг P(X) при прежней связи; concept drift — сдвиг P(Y|X)

   // разбор: Пришли юзеры из нового канала (сдвиг X, скоринг может остаться верным) vs изменилось поведение после кризиса — те же фичи предсказывают другой исход (сдвиг P(Y|X)). Первый детектится без меток (PSI на фичах), второй — в основном по падению качества на свежих метках. Отсюда разные реакции: перекалибровка/довыборка vs полноценное переобучение и пересмотр фичей.

2. #monitoring_drift2 / 5
   Что такое мониторинг ML-модели в проде?

   A)Разовая единичная проверка качества модели ровно один раз перед её самым первым запуском

   B)Постоянное отслеживание здоровья модели: дрейф, качество, ошибки, латентность

   C)Процесс однократного обучения модели на исторических данных

   D)Ручной просмотр кода модели ревьюером перед релизом в продакшн

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

   +B)Постоянное отслеживание здоровья модели: дрейф, качество, ошибки, латентность

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

3. #monitoring_drift3 / 5
   Кредитный скоринг одобряет только «хороших», по отказникам исхода нет. Чем это ломает переобучение на будущих данных?

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

   B)Проблема в объёме данных — одобренных мало, достаточно дождаться, пока их накопится больше

   C)Selection bias: обучающая выборка — лишь одобренные (усечённая популяция); нужен reject inference или разведочные одобрения

   D)Достаточно один раз переобучить модель на исторических данных и больше её не трогать во избежание смещения

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

   +C)Selection bias: обучающая выборка — лишь одобренные (усечённая популяция); нужен reject inference или разведочные одобрения

   // разбор: Модель формирует собственную будущую обучающую выборку: метки (дефолт/возврат) есть только у одобренных, а отклонённые в данные не попадают. Это selection bias — модель учится на усечённой, нерепрезентативной популяции и всё сильнее уверена в своей же зоне комфорта. Борются reject inference (моделирование исхода отказников), придержанной случайной выдачей кредитов для разведки и мониторингом сдвига популяции.

4. #monitoring_drift4 / 5
   Чтобы мониторить точность модели в проде, нужны истинные метки. Как их обычно добывают?

   A)Истинные метки в проде взять неоткуда, поэтому качество модели после выката измерить не получится

   B)Их заменяет уверенность самой модели: если модель уверена в предсказании, оно и считается истинной меткой

   C)Логируют предсказания и позже соединяют их с фактическим исходом (доставлено/вернул/дефолт), когда он становится известен

   D)Берут метки прямо из обучающей выборки — если модель хорошо обучилась, то прод-метки ей после выката уже и не требуются

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

   +C)Логируют предсказания и позже соединяют их с фактическим исходом (доставлено/вернул/дефолт), когда он становится известен

   // разбор: Для замера прод-точности предсказание логируют вместе с идентификатором и ждут наступления реального исхода (заказ доставлен/возвращён, кредит погашен/дефолт, клик/не клик), затем джойнят предсказание с фактом по ключу — так собирается размеченный поток для мониторинга. Исход часто приходит с лагом, поэтому до него следят за прокси и дрейфом входа. Уверенность модели не равна истине, а трейн-метки к проду не относятся.

5. #monitoring_drift5 / 5
   Модель по офлайн-метрике хороша, а бизнес недоволен. Зачем мониторить бизнес-KPI рядом с ML-метрикой?

   A)ML-метрика (AUC, MAE) не равна бизнес-цели (выручка, отток); модель может расти по метрике, не двигая KPI или даже вредя ему

   B)Бизнес-KPI и ML-метрика — это одно и то же число, просто названное по-разному в разных отделах

   C)Бизнес-KPI мониторят строго вместо ML-метрики, потому что технические метрики модели в проде вообще ничего полезного не показывают

   D)Мониторинг KPI нужен для отчётности перед руководством и на решения о самой модели не влияет

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

   +A)ML-метрика (AUC, MAE) не равна бизнес-цели (выручка, отток); модель может расти по метрике, не двигая KPI или даже вредя ему

   // разбор: Офлайн-метрика измеряет предсказательную способность, а не пользу для бизнеса: модель может улучшить AUC, но не сдвинуть выручку/удержание или даже навредить (например, оптимизируя клики ценой качества). Поэтому ML-метрики держат вместе с бизнес-KPI и guardrail'ами, проверяя, что технический рост переходит в целевой эффект. KPI и метрика — разные вещи, KPI не «вместо» и не только для отчёта.