КабинетПоиск
MLOps

Monitoring

Мониторинг

актуальноТекущий рабочий стандарт

Направления: Инженерия ИИ · MLOps

Наблюдение за инфраструктурой, данными и качеством предсказаний после релиза.

Ключевые тезисы

  • Технические метрики: , ошибки, потребление ресурсов.
  • Продуктовые метрики важнее ML-метрик, но приходят с задержкой.
  • Логируйте входы и предсказания — без них расследовать инцидент невозможно.

Какую задачу решает

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

ML отличается от обычного мониторинга сервисов тем, что здоровье приложения не гарантирует здоровья модели: latency в , ошибок ноль, а качество упало вдвое. Поэтому наблюдение ведётся на нескольких уровнях сразу — от инфраструктуры до бизнес-эффекта, и самый ранний сигнал обычно приходит не от метрики качества, а от распределений входных данных.

Что логировать с первого дня

Минимальный набор: полный , полученный моделью; её предсказание; версия модели; временная метка; идентификатор объекта для последующей склейки с фактическим исходом. Этого достаточно, чтобы позже посчитать любую метрику задним числом, найти расхождение между обучением и продом и разобрать любой инцидент. Добавить логирование потом гораздо дороже: данные за прошедший период уже не восстановить, а именно они нужны, когда что-то пошло не так.

Подробный разбор

2 подтемы — объяснения, формулы, примеры и интерактивные графики.

СлойМетрики сигнала
Инфраструктураlatency, RPS, ошибки, памятьсекунды
Данныедоля пропусков, распределения, новые категорииминуты
Качество моделиметрика на разметке, бизнес-показателидни или недели
На практике

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

  • Пороги ставьте по историческому разбросу метрики, а не «на глаз».
  • Требуйте устойчивости: алерт после N последовательных нарушений, а не первого выброса.
  • У каждого алерта должен быть владелец и понятный первый шаг разбора.
  • Регулярно ревизуйте: алерт, который все игнорируют, хуже отсутствия алерта.

Где применяется

  • Раннее обнаружение деградацииСдвиг распределений предупреждает за недели до того, как упадёт бизнес-метрика.
  • Поиск сломанного источникаРезкий скачок доли пропусков в признаке почти всегда означает поломку в пайплайне, а не изменение мира.
  • Решение о Триггер на по факту деградации вместо календарного расписания.
  • Разбор инцидентовИстория метрик позволяет понять, что изменилось и когда.

Плюсы, минусы и альтернативы

Плюсы

  • Ловит проблемы до того, как их заметит бизнес.
  • входов работает без меток и потому даёт мгновенный сигнал.
  • Превращает деградацию из аварии в плановую работу.
  • История наблюдений — основа для разбора инцидентов.

Минусы

  • Метрики качества запаздывают ровно настолько, насколько запаздывают метки.
  • Сдвиг распределения не всегда означает падение качества — бывают ложные тревоги.
  • Требует инфраструктуры логирования и хранения.
  • Плохо настроенные пороги приводят к усталости от алертов.

Брать, если

  • Модель работает в проде и влияет на решения.
  • Данные могут меняться со временем — то есть практически всегда.

Не брать, если

  • Разовый анализ без эксплуатации.

Чем заменяют

Drift DetectionновинкаДетекция дрейфа · MLOpsНужен разбор конкретных методов обнаружения сдвига.RetrainingактуальноПереобучение моделей · MLOpsДеградация обнаружена — вопрос в том, когда и как переобучать.ObservabilityактуальноНаблюдаемость · Системный дизайн ML-сервисовРечь о наблюдаемости системы в целом, а не только модели.
Тема также относится к главам:Системный дизайн ML-сервисовЭксплуатацияБезопасность ИИЗащита в проде

Видеолекции

Записи университетских курсов, где эта тема звучит. Ссылка открывает запись с той секунды, где о ней говорят, — искать по трёхчасовой лекции не нужно.

1:02:51Создание пользовательских мониторингов с TS QueryБольшие данные · Лекция «Управление инфраструктурой Hadoop» · 1 ч 22 мин36:52Введение в системы мониторингаБольшие данные · Семинар «Планирование и администрирование инфраструктуры» · 1 ч 33 мин

Связанные темы

Инференс и эксплуатация · Безопасность и приватность ML · Продакшен и эксплуатация · Безопасная эксплуатация · Зрелость ML-процесса

Model Deployment97%

Деплой моделей · MLOps

Доставка модели пользователю: онлайн-сервис, батч-скоринг или встраивание в приложение.

Docker97%

Docker · MLOps

Контейнеризация фиксирует окружение целиком: код, зависимости, системные библиотеки.

Kubernetes97%

Kubernetes · MLOps

Оркестрация контейнеров: масштабирование, самовосстановление, обновления без простоя.

Reliability96%

Отказоустойчивость · Системный дизайн ML-сервисов

Что происходит, когда модель недоступна, отвечает медленно или выдаёт мусор.

Observability96%

Наблюдаемость · Системный дизайн ML-сервисов

Логи, метрики и трассировки, по которым можно восстановить, что произошло с конкретным запросом.

Drift Detection96%

Детекция дрейфа · MLOps

Обнаружение расхождения между данными обучения и данными прода.

Retraining96%

Переобучение моделей · MLOps

Регулярное обновление модели на свежих данных по расписанию или по триггеру.

ML Pipelines96%

ML-пайплайны · MLOps

Оформление обучения как воспроизводимой последовательности шагов вместо разрозненных ноутбуков.

Data Contracts93%

Контракты данных · Инженерия данных

Явная договорённость между источником и потребителем: какие поля, каких типов и с какими гарантиями.

Requirements and SLA85%

Требования и SLA · Системный дизайн ML-сервисов

Числа, которые нужно зафиксировать до архитектуры: задержка, пропускная способность, доступность, стоимость запроса.

Serving Architecture85%

Архитектура инференса · Системный дизайн ML-сервисов

Модель внутри приложения, отдельный сервис или платформа инференса — три уровня связанности.

Caching85%

Кеширование · Системный дизайн ML-сервисов

Не считать то, что уже посчитано: кеш предсказаний, признаков и эмбеддингов.

Batching and Queues85%

Батчинг и очереди · Системный дизайн ML-сервисов

Собирать запросы в пачки, чтобы загрузить GPU, и сглаживать всплески нагрузки очередью.

Scaling85%

Масштабирование · Системный дизайн ML-сервисов

Горизонтальное и вертикальное масштабирование инференса и правильные метрики автоскейлинга.

GPU Inference85%

GPU-инференс · Системный дизайн ML-сервисов

Как выжать из видеокарты пропускную способность и не переплачивать.

Cost Model85%

Экономика сервиса · Системный дизайн ML-сервисов

Стоимость одного предсказания и точка, где модель перестаёт окупаться.

LLM Serving85%

Обслуживание LLM · Системный дизайн ML-сервисов

Отдельная инженерная дисциплина: KV-кеш, непрерывный батчинг, потоковая отдача и контроль стоимости.

Production ML80%

ML в продакшене · Практика ML

Модель в проде — это сервис с SLA, мониторингом, версионированием и планом отката.

MLOps Maturity80%

Уровни зрелости MLOps · MLOps

Шкала от ручных ноутбуков до полностью автоматического цикла обучения и выката — способ понять, где команда сейчас.

CI/CD for ML80%

CI/CD для ML · MLOps

Автоматизация проверок и выката: тесты кода, тесты данных, обучение и релиз модели по одной кнопке.

Data Versioning80%

Версионирование данных · MLOps

Данные меняются чаще кода — без их версий эксперимент не воспроизвести.

Secure Inference75%

Защита инференса · Безопасность ИИ

Периметр вокруг работающей модели: что происходит с запросом до того, как он дойдёт до весов, и после того, как ответ получен.

AI Governance75%

Управление рисками ИИ · Безопасность ИИ

Процесс вокруг модели: классификация риска, документация, контроль изменений и ответственность за решения.

Privacy and Security70%

Приватность и безопасность · Системный дизайн ML-сервисов

Персональные данные, доступы и специфические для ML риски.

Agents70%

Агенты · Генеративный ИИ

LLM, которая планирует, вызывает инструменты и итеративно движется к цели.

Prompting70%

Промптинг · Генеративный ИИ

Управление поведением модели через формулировку запроса, без изменения весов.

Кому эта тема нужна

Профильная компетенция для ролей: ML Engineer, MLOps-инженер, Продуктовый инженер.

Усиливает профиль: Data Engineer, LLM-инженер, CV-инженер, Инженер рекомендаций, Инженер речи.

Спрашивают на собеседовании: Сбер — Промышленный ML и MLOps, Т-Банк — ML-инженерия и продакшен, билайн — Продукты на данных, BI.ZONE — Данные и аналитика угроз, Группа Астра — Платформа и эксплуатация ML, Arenadata — ML на платформе данных, Selectel — Мощности и надёжность, Росатом — Промышленный ИИ.

Добавить в учебную программу
Проверить себя

Тема встречается в тесте по направлениям — ошибки приведут обратно на эту страницу.

Тест: MLOps и инженерия24
Следующий шагПроверить себя: MLOps и инженерияТема встречается в этом тесте 2 раза. Ошибка приведёт обратно на эту страницу — с объяснением, что именно не сошлось.Перейти →
← Model DeploymentDrift Detection →

Глава «MLOps» последний раз правилась . Нашли ошибку — напишите.