Моніторинг продуктивності моделі в продакшені
Уявіть: ваша ML-модель на рекомендаціях приносить 15% виручки. Раптово CTR падає на 40%, але ви помічаєте це лише через добу — за звітами бізнесу. Причина: data drift після релізу нового UI. Без моніторингу інженери витрачають години на пошук проблеми, а revenue втрачається щохвилини. Ми вирішували такі кейси десятки разів за 5 років роботи з production ML. В іншому проєкті latency інференсу зросла з 50 ms до 1.2 с через збільшення розміру батча — алерт спрацював за 2 хвилини, і ми відкотили конфіг.
Моніторинг моделі — не просто дашборд з AUC. Це система, яка ловить деградацію на ранній стадії: latency зросла, ембеддінги змістилися, батчі таймаутяться. Комплексний підхід покриває інфраструктуру, дані, модель та бізнес-метрики. Зв'яжіться з нами для аудиту вашого поточного моніторингу — ми запропонуємо конкретні покращення.
Чому моніторинг ML-моделей критичний для бізнесу?
На production моделі впливають сотні факторів: зміна розподілу вхідних ознак, стрибки навантаження, баги в пайплайні фіч, застарілі ембеддінги. Без системи метрик ви сліпі. Приклад з нашого досвіду: у клієнта-рітейлера модель скорингу почала давати 90% позитивних відповідей — помилка в ETL, але виявили лише через 3 дні, коли approval rate злетів. З моніторингом таких проблем не трапляється.
Рівні моніторингу та їх метрики
Ми виділяємо три шари метрик. Нижче таблиця з прикладами порогів:
| Рівень | Приклади метрик | Критичні пороги |
|---|---|---|
| Інфраструктура | latency (p50/p95/p99), throughput, GPU utilization | p99 > 2s, GPU util < 30% |
| Дані та модель | prediction distribution, PSI, KS-тест | PSI > 0.2, KS > 0.1 |
| Бізнес | CTR, конверсія, revenue impact | Відхилення > 5% від baseline |
Рівень 1 — Інфраструктура: latency (p50, p95, p99), throughput (RPS), error rate (5xx, таймаути), GPU utilization (куди важливіше CPU в inference), queue depth при батчингу. Ці метрики першими сигналізують про проблеми.
Рівень 2 — Дані та модель: feature statistics (mean, std, null rate), prediction distribution (гістограма score), confidence distribution, data drift (KS-тест, PSI). Дрифт — головна причина мовчазної деградації. Згідно з Data drift, контроль дрифту — ключовий елемент MLOps.
Рівень 3 — Бізнес-метрики: proxy-метрики (CTR, конверсія, engagement) до отримання ground truth, downstream KPIs (revenue impact, churn rate). Вони показують реальну цінність моделі.
Як налаштувати алертинг для production ML?
Алерти повинні бути багаторівневими. Ось типова схема:
| Рівень | Метрика | Поріг | Канал |
|---|---|---|---|
| Warning | data drift PSI | > 0.15 | Slack |
| Warning | latency p99 | > 500 ms | Slack |
| Critical | error rate | > 1% | PagerDuty |
| Critical | latency p99 | > 2 s | PagerDuty |
| Fatal | service unavailable | - | phone on-call |
З налаштуванням таких алертів середній час виявлення проблеми — 5–10 хвилин проти кількох годин вручну. У наших проєктах ми гарантуємо, що критичні метрики доходять до чергового за <30 секунд.
Стек моніторингу
Prometheus + Grafana — стандарт для інфраструктурних метрик. ML-специфічні метрики експортуються через prometheus_client:
Приклад коду експорту метрик
from prometheus_client import Histogram, Counter, Gauge REQUEST_LATENCY = Histogram( 'ml_inference_latency_seconds', 'Inference request latency', buckets=[0.01, 0.05, 0.1, 0.25, 0.5, 1.0, 2.5] ) PREDICTION_DISTRIBUTION = Histogram( 'ml_prediction_score', 'Distribution of model prediction scores', buckets=[0.1 * i for i in range(11)] ) @REQUEST_LATENCY.time() def predict(features): score = model.predict_proba(features)[0][1] PREDICTION_DISTRIBUTION.observe(score) return score Evidently + Grafana — для моніторингу дрифту з візуалізацією. Evidently виявляє дрифт у 10 разів швидше порівняно з ручним аналізом гістограм. Інтеграція з Prometheus дозволяє будувати дашборди в реальному часі.
OpenTelemetry — стандартизований спосіб інструментування для трасування, метрик і логів. Особливо корисний у мікросервісних архітектурах, де інференс — один із багатьох сервісів.
Найкращі практики prediction logging
Для відкладеного обчислення метрик якості (коли ground truth з'являється пізніше) необхідно логувати пари (запит, передбачення) з унікальним ID:
import uuid def predict_and_log(request_features): prediction_id = str(uuid.uuid4()) prediction = model.predict(request_features) # Логування в ClickHouse/BigQuery/Kafka prediction_store.log({ 'prediction_id': prediction_id, 'timestamp': datetime.utcnow(), 'features': request_features.to_dict(), 'prediction': float(prediction), 'model_version': MODEL_VERSION }) return prediction, prediction_id Зазначимо: коли ground truth стає відомим (наприклад, користувач здійснив або не здійснив покупку), він записується з тим же prediction_id, і система обчислює актуальні метрики якості.
Дашборди
Рекомендована структура Grafana-дашбордів:
- Operational Overview — latency, throughput, error rate в реальному часі
- Model Health — prediction distribution, feature statistics, drift metrics
- Business Impact — proxy-метрики та downstream KPIs
- Model Comparison — порівняння поточної та попередньої версії при canary deployment
Кожен дашборд супроводжується анотаціями деплоїв — це допомагає зіставляти зміни метрик з релізами.
Що входить в роботу з налаштування моніторингу
Зазначимо: коли ви замовляєте у нас моніторинг production ML, ми:
- Аналізуємо поточні метрики, модель та інфраструктуру
- Проєктуємо систему метрик (інфраструктура + ML + бізнес)
- Впроваджуємо збір метрик (Prometheus client, Evidently, OpenTelemetry)
- Налаштовуємо дашборди в Grafana (4+ панелей)
- Конфігуруємо алерти з ескалацією (Slack/PagerDuty/телефон)
- Навчаємо вашу команду роботі з системою
- Надаємо документацію та доступи
Терміни: від 5 до 15 робочих днів залежно від складності пайплайну. Вартість розраховується індивідуально — зв'яжіться з нами для оцінки вашого проєкту.
Наші інженери мають сертифікати AWS ML, ми реалізували моніторинг для 10+ production моделей у рітейлі та фінтеху. Гарантуємо SLA на час реакції алертів — <30 секунд до чергового. Замовте аудит вашої системи моніторингу — ми знайдемо слабкі місця за 2 дні.