Model Monitoring

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

Что отслеживать#

Мониторинг в производственной среде обычно охватывает четыре уровня:

• Задержка инференса и работоспособность сервиса: Частота запросов, частота ошибок, задержка p95 и p99, объём и утилизация памяти GPU; показатели часто собираются с помощью Prometheus и отображаются в Grafana.
• Входные данные: Нарушения схемы, пропущенные значения и сдвиги статистик признаков или изображений, например яркости, разрешения или размера объектов.
• Уверенность предсказаний и распределение выходных данных: Распределение классов, число обнаружений на изображение и оценки уверенности. Сдвиг этих показателей, называемый дрейфом предсказаний, служит ранним предупреждением ещё до появления меток.
• Производительность модели: Точность, precision, recall или mAP, вычисляемые после получения эталонной разметки. Метки мошенничества могут поступить спустя несколько недель в виде чарджбэков, а команды компьютерного зрения вручную размечают выборку производственных изображений.

Ultralytics Platform встраивает слой предсказаний в свои выделенные конечные точки: на вкладке Monitoring отображаются распределение уверенности развёрнутой модели YOLO, средняя уверенность с течением времени, наиболее частые классы и число предсказаний на изображение. Недавние изображения вместе с предсказаниями можно сохранить в набор данных для проверки и повторного обучения. Руководство по мониторингу и обслуживанию моделей и урок Ultralytics Academy «Наблюдаемость и дрейф» подробно описывают проверки дрейфа для развёртываний YOLO.

Большинство случаев снижения качества вызвано двумя видами изменений. Дрейф данных, также называемый сдвигом ковариат, меняет входные данные — например, перемещается камера контроля на линии производства или меняется освещение. Концептуальный дрейф меняет связь между входными данными и правильными ответами: например, мошенники меняют тактику, и обычные раньше транзакции становятся мошенническими. Статистики входных данных непосредственно показывают дрейф данных, а концептуальный дрейф проявляется только в показателях производительности после появления меток. Оба фактора относятся к наиболее распространённым причинам сбоев моделей компьютерного зрения в производственной среде.

Обнаружение дрейфа#

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

import numpy as np
from scipy.stats import ks_2samp

rng = np.random.default_rng(0)

# Detection confidences logged at validation time form the reference distribution
reference = rng.beta(8, 2, size=2000)

# Two simulated production windows: one like the reference, one shifted lower
windows = {"week 1": rng.beta(8, 2, size=500), "week 2": rng.beta(5, 3, size=500)}

for name, live in windows.items():
    # Two-sample Kolmogorov-Smirnov test: do both samples come from one distribution?
    result = ks_2samp(reference, live)
    drift = result.pvalue < 0.01
    print(f"{name}: mean {live.mean():.2f}, KS {result.statistic:.3f}, p {result.pvalue:.1e}, drift {drift}")

Первая неделя проходит проверку: статистика KS равна 0,037, p = 0,64. На второй неделе средняя уверенность снижается до 0,63 против 0,80 на первой неделе, а статистика KS, равная 0,456 при p = 1,2e-75, сигнализирует о дрейфе. При нескольких тысячах образцов статистически значимыми становятся даже безвредные сдвиги, поэтому производственные проверки обычно отправляют уведомление, когда статистика KS или индекс стабильности популяции (PSI) превышает установленный порог. Библиотеки с открытым исходным кодом, такие как Evidently и NannyML, объединяют эти тесты в отчёты о дрейфе; NannyML также оценивает точность классификатора без меток по откалиброванным оценкам уверенности. Аналогичные проверки в виде управляемых сервисов предлагают Amazon SageMaker Model Monitor и Vertex AI Model Monitoring. Затем уведомление запускает расследование:

Мониторинг, наблюдаемость и оценка#

• Наблюдаемость: Логи, трассировки и сохранённые входные данные, объясняющие причину срабатывания уведомления. Мониторинг выполняет заранее заданные проверки; многие поставщики объединяют обе возможности под названием наблюдаемости ML.
• Оценка модели: Оценивает модель на отложенной тестовой выборке перед выпуском. Мониторинг повторяет это измерение на реальном потоке запросов всё время, пока модель обслуживает запросы.
• Отслеживание экспериментов: Записывает запуски обучения во время разработки, до появления производственных данных.