Мониторинг и drift на собеседовании ML Engineer
Зачем мониторинг ML на собесе MLE
Модель в production «протухает» со временем: распределение входов меняется (data drift), целевая зависимость меняется (concept drift), performance падает. Без monitoring обнаружим случайно через бизнес-метрики — поздно. На собесе ML Engineer monitoring и drift спрашивают через сценарии: «как заметишь, что модель сломалась».
Слабый ответ — «accuracy на test set». Сильный — про data drift, concept drift, prediction drift, бизнес-метрики, alerts, retraining triggers.
Типы drift
Data drift (covariate shift):
- P(X) меняется. Распределение features.
- Пример: новая категория users, новые источники трафика.
- Detection: PSI, KS, distribution comparisons.
Concept drift:
- P(y|X) меняется. Целевая зависимость.
- Пример: до пандемии customers вели себя так-то, после — иначе.
- Detection: drop в performance metrics.
Prediction drift:
- Distribution outputs меняется.
- Может быть симптомом и data, и concept drift.
Label drift:
- P(y) меняется. Распределение целевой переменной.
Statistical tests для drift
PSI (Population Stability Index):
- Стандарт в credit scoring
- Bins variable, считаем (% baseline - % current) × log(% baseline / % current)
- < 0.1: stable, 0.1-0.25: minor drift, > 0.25: significant drift
KS-тест (Kolmogorov-Smirnov):
- Сравнивает CDF двух distributions
- p-value < 0.05 → significant difference
Chi-square:
- Для categorical features
- Сравнивает observed vs expected frequencies
Wasserstein distance:
- «Earth mover's distance»
- Для непрерывных distributions
В Evidently / WhyLogs / Aporia встроены auto-checks.
Performance monitoring
Online metrics:
- Real-time AUC / accuracy / RMSE
- Computed on rolling window
- Compare vs baseline (training set performance)
Lag для ground truth:
- Часто labels приходят с задержкой (purchase / churn confirmation)
- Proxy-метрики до получения labels (например, CTR для recommendation)
Бизнес-метрики
Самое важное мониторить — business outcome.
- Revenue impact модели
- Conversion / retention
- User engagement
- Alerts на anomaly в этих метриках
ML метрики могут быть «зелёные», бизнес-метрики падают — concept drift.
Tools
Open-source:
- Evidently — Python lib, dashboards, drift detection
- WhyLogs / WhyLabs — profiling, monitoring
- Aporia — managed ML monitoring
- Arize AI — enterprise
Self-hosted:
- Custom scripts + Grafana / Prometheus
- В РФ часто in-house solutions поверх ClickHouse
Alerting
Severity levels:
- P0 (critical): model returning errors / drastic accuracy drop. Page on-call.
- P1 (high): significant drift. Slack alert to team.
- P2 (medium): monitoring trends. Daily digest.
Routing: PagerDuty, Slack, email.
Анти-паттерн: alert на каждое minor отклонение — alert fatigue.
Retraining triggers
Когда переобучить модель?
1. Schedule: weekly / monthly. Простой подход.
2. Performance drop: AUC снизился ниже threshold.
3. Significant drift: PSI > 0.25 на key features.
4. Major data change: новая категория / новый источник.
5. Manual: business stakeholders ask.
Best practice: combine schedule + triggers.
Типичные вопросы
«Model в проде — как заметишь, что протухла?»
Multi-layered monitoring: data drift (PSI / KS на features), prediction drift, performance metrics с lag for labels, business metrics. Alerts на anomalies в каждом layer.
«PSI = 0.3 — что делаешь?»
Significant drift. Не паника, но investigate: какие features сдвинулись, почему, нужна ли retrain. Trigger retraining pipeline → A/B тест новой модели.
«Concept drift — как detect без ground truth?»
Proxy-метрики (CTR, downstream conversion). Prediction distribution shift. Population statistics. Eventually — ground truth label придёт, тогда подтвердишь.
«Каждую неделю retrain — нормально?»
Зависит. Если data меняется быстро (fraud, recommendation) — да. Если стабильная domain — overkill, ресурсы зря. Best: trigger-based + schedule fallback.
«Alert fatigue — как избежать?»
Severity levels. Strict thresholds (PSI > 0.25, не 0.1). Aggregate (daily digest вместо per-event). Test alerts на retrospective data — false positive rate?
Частые ошибки
- Только train-set performance. В проде неактуально.
- Без data drift monitoring. Модель пытается работать на distrib, которое не видела.
- Alert fatigue. Все становятся слепы к notifications.
- Без retraining pipeline. Drift детектится, но retraining manual → задержка.
- Без бизнес-метрик. ML-метрики OK, business broken.
FAQ
Evidently или WhyLogs?
Evidently — простой, batch reports. WhyLogs — streaming-friendly. В небольших проектах Evidently достаточно.
PSI или KS — какой использовать?
PSI — стандарт в banking. KS — более universal. Часто используют оба.
Ground truth задержка — как handle?
Proxy-метрики до получения labels. Дашборды с two views: leading (proxy) + lagging (real labels).
Retraining cost?
Зависит от модели. Простая LightGBM — минуты. Большая deep model — часы / дни. Cost важен для retraining cadence.
Drift detection на real-time?
Streaming aggregations через Spark / Flink. Compare rolling window vs baseline. Alert при threshold.