Мониторинг моделей в продакшне

Модель без мониторинга — чёрный ящик, который однажды тихо начинает врать, и никто не замечает.

Мониторинг ML-модели — непрерывное наблюдение за тремя слоями: операционным здоровьем сервиса, статистикой входных данных и качеством предсказаний.

Почему обычного мониторинга мало

Стандартный мониторинг сервиса (латентность, ошибки, нагрузка) скажет, что сервис «жив». Но модель может прекрасно отвечать 200 OK за 20 мс и при этом выдавать всё более плохие предсказания из-за дрейфа. Зелёные дашборды инфраструктуры не видят деградации качества. Поэтому ML-мониторинг трёхслойный.

Это фундаментальное отличие ML от обычного софта. В классическом сервисе «работает» и «правильно» почти синонимы: если эндпоинт отвечает без ошибок, он, скорее всего, делает то, что задумано, потому что логика задана кодом и код не меняется сам. В ML логика задана данными, а данные дрейфуют. Поэтому возникает коварное состояние «зелёный, но неправильный»: все технические метрики в норме, SLA соблюдён, алертов нет — а модель уже месяц принимает всё более ошибочные решения, и узнают об этом, только когда падает выручка или приходят жалобы. Трёхслойный мониторинг существует именно чтобы поймать это состояние раньше, чем оно станет дорогим.

Слой 1: операционный

Здоровье сервиса как у любого бэкенда: латентность (p50/p95/p99), доля ошибок, RPS, использование CPU/GPU/памяти. Это ловит «сервис лёг» и «сервис тормозит», но ничего не говорит о правильности ответов.

Слой 2: данные на входе

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

Слой 3: качество предсказаний

Самое важное и самое трудное: реально ли модель предсказывает верно. Требует обратной связи — настоящих меток (ground truth), которые приходят с задержкой: одобрили ли кредит, кликнул ли пользователь, был ли это мошеннический платёж. Когда метки приходят, считают онлайн-метрики (accuracy, f1, ROC-AUC) и сравнивают с базовыми.

                      приходят с задержкой
предсказание (сейчас) ----------------------> метка (через дни)
                                                     |
                              онлайн-метрика = сравнить предсказание с меткой

Проблема задержки меток

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

Как работает под капотом

Технически сервис при каждом инференсе пишет в лог запись: входные признаки, предсказание, версия модели, время. Эти логи стекаются в хранилище. Отдельные задания периодически считают по ним метрики: операционные — из времён и статусов, дрейф — сравнивая распределения признаков с эталонным окном, качество — джойня предсказания с пришедшими метками. Результаты идут в систему мониторинга (Prometheus/Grafana, Evidently, специализированные ML-observability платформы) с алертами по порогам.

Частые ошибки

• Мониторить только инфраструктуру. Зелёный сервис ≠ хорошие предсказания.
• Ждать только метрики качества. Метки запаздывают; без слоя данных вы узнаете о беде слишком поздно.
• Не логировать версию модели. Тогда не понять, какая версия дала просадку.
• Алерты без базовой линии. Без эталона непонятно, плохое значение или нормальное.

Итог

• ML-мониторинг трёхслойный: операционный (сервис), данные (дрейф входов), качество (предсказания против меток).
• Слой данных работает без меток и служит ранним детектором, пока метки запаздывают.
• Качество требует ground truth с задержкой; всё опирается на логирование входов, предсказаний и версии модели.