Привет! Меня зовут Владимир Суворов, я Senior Data Scientist в Страховом Доме ВСК и core-разработчик нашей библиотеки машинного обучения OutBoxML.

Ссылки на наш проект на GitHub и в Telegram.

Любая модель машинного обучения начинается с данных. Известное выражение «garbage in, garbage out» как нельзя лучше описывает главную уязвимость ML‑систем. В автоматизированном машинном обучении (AutoML) наиболее критичными точками являются процесс сборки данных и проблема мониторинга данных, в т.ч. в онлайне. Если процессы feature engineering и обучения наша библиотека формализует «из коробки» с помощью конфигурационных файлов и единых правил, то ответственность за загрузку и получение данных несет пользователь.

О том, как мы проектируем такие системы, какие инженерные принципы используем и как соединяем физику моделирования с ML-подходом, я регулярно рассказываю в своём Telegram-канале. Там же разбираем технологии, задачи и навыки, необходимые для создания решений, за которые бизнес готов платить. Буду рад видеть вас среди читателей!

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

Поэтому мониторинг как самих моделей, так и данных на всех этапах — одна из самых ответственных задач в промышленном ML.

В моей практике Data Scientist всегда на шаг позади Data Engineer: инженер данных всегда может допустить больше ошибок, чем Data Scientist успевает исправить.

Задачи системы мониторинга данных

Для решения задачи контроля данных мы рассмотрим систему мониторинга на основе нашей библиотеки outboxml. Мониторинг заключается в сравнении контрольного датасета (например, того, на котором обучалась модель) с новым набором данных. Это могут быть логи работы модели или обновленный датасет для обучения.

Основные задачи системы:

1. Мониторинг моделей в онлайн‑режиме: сравнение распределений, средних, мод и других метрик между двумя наборами данных: логов модели и контрольного датасета.

  • Измерение метрик дата‑дрифта: расчет таких величин, как Population Stability Index (PSI) и расхождение Кульбака‑Лейблера (KL‑divergence).

  • Валидация источников данных: проверка, что все внешние источники подтянуты корректно. Бывает, что источник перестает отвечать, и данные по какому‑то полю приходят пустыми. Если это не заметить, мы можем потерять целую фичу.

  • Экстраполяция целевых переменных: расчёт и прогноз финансового эффекта модели.

Архитектура системы мониторинга

Когда у нас есть два набора данных для сравнения, мы используем класс MonitoringManager. В соответствии с нашим подходом к моделированию, описанным в предыдущих статьях, этот класс принимает на вход набор гибких интерфейсов, которые можно использовать как «из коробки», так и кастомизировать под свои нужды.

Процесс мониторинга состоит из нескольких этапов:

Загрузка контрольного набора данных.

Загрузка целевого датасета для контроля (логи модели, новые данные).

Расчет дата‑дрифта. Мы контролируем как обработанные фичи, так и сырые данные. Почему это важно? Рассмотрим пример с мощностью автомобиля.

Проблема: если в новых данных средняя мощность выросла со 140 до 160 л.с., а наша группировка фичей определена как «до 200 л.с.», то для модели дрифт будет равен нулю — оба значения попадают в одну категорию.

Решение: мониторинг сырых данных непосредственно покажет это изменение в распределении.

Расчет экстраполяции таргета или дрифта бизнес‑метрики. Пропуская два разных набора данных через модель, мы получаем два разных прогноза. Например, в страховании ключевой метрикой является убыток. При контроле нового набора данных мы хотим быть уверены, что прогноз модели остался в допустимых пределах.

Рассмотрим пример работы системы мониторинга на задаче о Титанике. Для этого используем версию фреймворка 0.8.1. Запуск мониторинга произведем «из коробки» с помощью класса MonitoringManager.

Что под капотом? Входные данные MonitoringManager

MonitoringManager(
    monitoring_config,
    models_config,
    external_config=None,
    logs_extractor: outboxml.extractors.Extractor = None,
    data_extractor: outboxml.extractors.Extractor = None,
    target_extractor: outboxml.extractors.Extractor = None,
    monitoring_report: outboxml.monitoring_manager.MonitoringReport,
    datadrift_interface: outboxml.datadrift.DataDrift = None,
    grafana_connection=None,
    business_metric: outboxml.metrics.base_metrics.BaseMetric = None,
    email: outboxml.core.email.EMailMonitoring = None,
)

Класс MonitoringManager принимает на вх��д:

  • monitoring_config.json: файл с названиями моделей, порогами срабатывания и общими параметрами мониторинга. Заполняется один раз для всей системы.

  • models_config.json: конфиг модели, в соответствии с которым выполняется обработка

  • data_extractor: интерфейс загрузки исходного (контрольного) датасета.

  • logs_extractor: интерфейс загрузки данных для сравнения (логи модели, обновленные данные).

А также набор пользовательских интерфейсов:

  • datadrift_interface: интерфейс расчета дата‑дрифта. «Из коробки» мы считаем дрифт для обработанных фичей. При указании параметра full_calc дополнительно рассчитываются статистики: количество пропусков, среднее, мода и др.

  • monitoring_report: интерфейс для настройки форматов отчетов (например, для отправки по почте или генерации HTML‑отчета).

  • email: интерфейс для отправки писем.

Возьмем исходный датасет и искусственно его «зашумим». Представим, что в логах или в новом датасете по какой-то причине все возраста стали проходить AGE = 100.

import sys
sys.path.append("../../")
sys.path.append("../../outboxml")

import pandas as pd
from outboxml.monitoring_manager import MonitoringManager
from outboxml.extractors import SimpleExtractor

data_old = pd.read_csv('data/titanic.csv')
data_new = data_old.copy()
data_new['AGE'] = 100

Далее инициализируем класс и запустим метод review()

data_extractor = SimpleExtractor(data=data_old)
logs_extractor = SimpleExtractor(data=data_new)

MonitoringManager(monitoring_config='configs/monitoring_test_config.json',
                   models_config='configs/config-example-titanic.json',
                   data_extractor=data_extractor,
                   logs_extractor=logs_extractor,
                   ).review()

Лог выполнения работы:

И отчет по выполнению, где видим, что поле AGE имеет высокий PSI.

Как это работает в реальной жизни?

Система автоматического мониторинга может запускаться по расписанию или по триггеру.

Практические кейсы применения:

  • Контроль переобучения модели:

    Если все проверки пройдены — система инициирует переобучение моделина новых данных.

    Если проверки провалены — переобучение запускается на последних хороших данных, а Data Scientist получает уведомление с указанием проблемных полей или источников.

  • Вывод модели в продакшн с новыми фичами:

    Сценарий: добавили несколько новых фич, одна из которых была запрограммирована некорректно. Модель получает не те данные.

    Реакция системы: мониторинг фиксирует отклонения в PSI и KL‑divergence. В отчете указано, какая фича имеет высокий дрифт, и приведена ее статистика.

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

В рамках статьи будет интересно кратко коснуться кейса Azure Machine Learning model от Microsoft. В Azure Machine Learning вы можете использовать мониторинг моделей для постоянного отслеживания производительности моделей машинного обучения в рабочей среде. Мониторинг моделей предоставляет вам широкий обзор сигналов мониторинга. Он также предупреждает о потенциальных проблемах, отслеживая сигналы и показатели производительности моделей в процессе производства, вы можете критически оценить риски, присущие вашим моделям. В целом, кейс отлично демонстрирует механизм мониторинга (сбор данных, сравнение распределений, триггеры) — понятно и технически полезно для изучения.

Заключение

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

Пишите в комментариях, о каких аспектах автоматизации ML вам хотелось бы узнать подробнее. Удачи в реализации ваших проектов!