Мониторинг производительности модели в продакшене
Представьте: ваша 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 дня.