Система мониторинга ML-моделей: превращаем данные в полезный инструмент

В прошлой статье ^[1] мы разобрали, из каких компонентов собирается система мониторинга, и составили инструкции, чтобы указывать на действительно важные проблемы. Пришло время выстроить их в единую систему. Она должна масштабироваться и давать ясную картину происходящего, чтобы наш мониторинг не был бесполезным потребителем ресурсов.

В этой статье мы сформулируем правила, которые помогут:

• организовать хранение данных для масштабируемости;

• построить понятную визуализацию на дэше;

• настроить осмысленные оповещения;

• написать документацию.

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

Как мы организовали хранилище

Начнём с хранилища. Его нужно организовать так, чтобы данные подтягивались в дашборд автоматически. Для этого структура хранения данных должна отвечать следующим требованиям:

• Подходит для хранения данных мониторинга любых моделей (не зависит от параметров и конфигурации ML‑модели).

• Позволяет построить единый пайплайн сбора данных и расчета проверок (при переходе от одной ML‑модели к другой в SQL‑запросах меняется только id).

Используем стандартные приемы в работе с базой данных:

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

• Название поля сообщает, какие данные в него записаны.

• Поля, содержащие одну и ту же информацию в разных таблицах, называются одинаково.

Опишу основные сущности:

Модель
Основная информация о модели: название, описание, дата создания и тд.

Версия
Информация о конкретной реализации модели и ее описание.

Распределение фичей
Предлагаем агрегированное хранение данных. Для отрисовки графика распределения мы можем использовать все данные, скопировав их внутрь дашборда, но так мы излишне перегрузим его. Лучше загружать готовые агрегаты, которые созданы по единым правилам и показывают статистику по бинам.

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

Тесты на дрифт фичей
Результаты тестов на дрифт данных и дополнительная информация по ним.

Статистики по фичам
Полезная информация о признаках: среднее, 50/95/99 перцентиль и тд.

Сборник ссылок
Список ссылок на ресурсы, которые имеют отношение к модели. Например, документация, мониторинг в grafana, даг в airflow и так далее

Важность тестов
Список тестов, которые мы отмечаем как важные — на них и на порядок их отображения в дэше нам нужно обращать внимание ^[2] в первую очередь.

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

Важность фичей
Список всех фичей с признаками важности для ML‑модели / мониторинга / бизнес‑ценности.

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

Про airflow: частичное решение

Чтобы не выполнять расчет тестов и загрузку результатов в хранилище вручную, нужен инструмент оркестрации. Для нашего пайплайна мониторинга использовали Airflow. Мы упаковали свой Python‑код в даги и быстро настроили запуск по расписанию. Статус выполнения можно отслеживать в интерфейсе или же самостоятельно настроить алёрты, как это работает у нас. Теперь расчёты происходят без нашего участия, а результаты записываются в спроектированное нами хранилище.

Важно убедиться в адекватном потреблении вычислительных ресурсов во время работы дага, иначе процесс будет исполняться непозволительно долго, а в худшем случае будет периодически падать. Мы запускали даг на тестовом слое, а наблюдали за исполнением через grafana.

В результате мы обнаружили проблему потребления памяти ^[3] при создании DataFrame: система выделяла избыточное ОЗУ «на вырост», а после загрузки не всегда возвращала их полностью. Мы решили эту проблему переходом к загрузке батчами. Каждый батч обрабатывается до загрузки следующего, что сокращает общую потребность ^[4] в ресурсах, приводит к более стабильной работе и увеличивает скорость выполнения расчётов.

Кроме того, мы явно задали типы данных при загрузке. Механизм автоматического определения типов в pandas часто перестраховывается, выбирая более ёмкие типы. Ручное указание типов позволило сразу выделить ровно тот объём, который необходим.

Хранилище построили, расчёты автоматизировали — приступаем к визуализации.

Настраиваем визуализацию

Каждой модели нужен мониторинг, каждому мониторингу — визуализация. Если использовать один дашборд для всех моделей, то мы рискуем перегрузить его данными из‑за желания сделать хорошую детализацию, что приведет к долгой отрисовке элементов. Будем придерживаться правила: 1 модель — 1 дашборд. Тогда достаточно один раз спроектировать универсальный шаблон дашборда и использовать (копировать) его каждый раз, когда появляется новая модель.

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

1. SQL‑запросы не должны содержать имена таблиц, которые относятся к конкретной модели. Иначе, для каждой новой модели придется писать свой скрипт, донастраивать визуальные элементы и изменять связи внутри проекта.

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

3. Любые шкалы (их минимум и максимум) задаются правилами, которые самостоятельно адаптируются под параметры модели, чтобы графики были всегда видны целиком, а их масштаб обеспечивал интуитивно верное восприятие ^[5]: то, что выглядит значительным изменением, им и является.

Также договоримся о двух принципах:

1. Цветовой акцент только там, где требуется внимание. Если проблемы подсвечивать красным, успехи зеленым, метрики жёлтым, названия малиновым, надписи розовым (ну, вы поняли), то можно потерять фокус. У вас получится бесполезный дашборд, зато очень красивый.

2. Добавляем скрытое пояснение ко всем элементам дашборда. Это решает сразу несколько проблем:

   1. отсутствие разночтения, все понимают графики и статистики одинаково;

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

Важно, чтобы пояснение было в свернутом элементе, чтобы не перегрузить страницу текстом.

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

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

• График средних для отслеживания смещения центра распределения.

• График распределений для визуальной оценки его формы.

• История результатов тестов для анализа динамики.

Тут главное не потеряться и помнить, что в первую очередь мы смотрим на результат статистического теста, и только потом на графики.

Проектируем дашборд

Можем переходить к проектированию шаблонного решения дашборда:

• Общая информация, она же Стартовая страница. Содержит всю основную информацию про конкретную реализацию модели:

  • версию модели и ссылку на прошлые версии;

  • ссылку на документацию;

  • общую статистику по дрифту внутри блоков;

  • общую статистику по дрифту важных фичей;

  • агрегированные данные о результатах тестов;

  • график с количеством фичей, у которых расхождение по распределению, и суммарной их важностью;

  • график с количеством фичей, у которых расхождение по пропускам, и суммарной их важностью.

• Блоки. Блоком называем группу признаков, объединённых по смыслу Используем их, чтобы иметь возможность обнаружить комплексную проблему, которая может быть общей для нескольких фичей одновременно. Чаще всего, мы формируем блоки по источнику, по которому производили расчёт фичей. Анализ блоков осуществляем следующим путем:

  • Считаем важность блока по сумме важности признаков, входящих в этот блок. Отбираем ТОП-5 самых важных из них.

  • Для каждого блока из ТОП-5 визуализируем расхождения в распределении и пропусках и предоставляем общую сводку по признакам.

  • После топа размещаем информацию по всем прочим блокам и добавляем фильтр отбора блоков, по которому можно увидеть аналогичную визуализацию, как для ТОП-5.

• Фичи детально. Следует уделить особое внимание ТОП-10 самых важных фичей, поскольку в большей степени именно от их значений зависят предсказания ML‑модели. Размещаем их в порядке убывания важности и дополняем визуальными элементами и агрегированными статистиками, которые позволяют быстро сделать выводы. После топа содержится полная таблица со списком всех фичей и их основными статистиками, чтобы отсматривать интересные или подозрительные случаи. Заметив такие, можно перейти к визуальному элементу, выбрать нужную фичу с помощью фильтра и детально рассмотреть всю статистику на графиках.

• Тесты. Общая статистика по всем тестам, которые актуальны на последнюю дату запуска. Собираем в таблицу все тесты и их статистики.

• Качество модели. Предлагаем ограничиться двумя частями. Слева — статистики по ключевым метрикам модели (не более 3-х метрик). Справа — все интересующие метрики и тесты, статистики по которым визуализируются выбором в окне фильтрации. На графиках выделяем цветным столбиком дату, если текущее значение выходит за пределы допустимых диапазонов для него.

Шаблон универсального дашборда готов.

Несмотря на удобство отдельных дашбордов для каждой модели, анализ общей ситуации затруднён: нужно запоминать и открывать множество ссылок. Выходом может стать создание собирательного дашборда, отображающего основную информацию по всем моделям сразу.

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

• все новые дэши складывать в одну папку;

• все наименования писать единообразно.

Внутреннее содержание собирательного дэша:

1. Список заведенных моделей со ссылками на дэш с настроенным мониторингом, документацию и контактом ответственного.

2. Последнее состояние по обработке, с информацией о том, какие проблемы были замечены, согласно компонентам, описанным выше.

Делаем алёрты

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

Мы определили для них следующие параметры:

1. Полезные. Алёрты должны содержать нужную информацию, которая бы отвечала на вопрос: «Модель работает исправно?».

2. Краткие. Содержание включает в себя только ту информацию, по которой можно сделать выводы без подробностей.

3. Своевременные. Алёрты должны отправляться тогда и только тогда, когда это необходимо, чтобы не превратиться в спам‑рассылку.

4. Адресные. Оповещения должны получать только те, кто может и должен на них реагировать ^[6].

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

Теперь точно весь мониторинг построен! Но… как и кто будет его делать, пока сервиса нет? В нашей настроенной системе остается место, где нужно вносить ручные правки и работать с базой данных напрямую. Кроме того, если только один человек знает, как настроить и использовать мониторинг, вся система, без этого человека, превращается в черный ящик.

Мы сделали настройку мониторинга доступной каждому.

Оформили код:

• Весь код сложили в gitlab.

• Написали подробный файл readme, включили в него:

  • вопросы, на которые нужно ответить до создания мониторинга, чтобы определиться с целями, составом тестов и визуальными компонентами;

  • описание всех файлов внутри проекта, а также инструкции с тем, где необходимо подставить свои значения;

  • данные, которые нужно собрать, и названия таблиц, в которые происходит заливка;

  • список дополнительных файлов, которые нужны для настройки, и их описание;

  • пайплайн настройки мониторинга.

• Все логические части кода снабдили комментариями.
  Мы оформили код так, чтобы любой человек смог его понять и отредактировать осмысленно. Для этого добавили описание к каждой функции и каждой логической части, указали места, где необходимы изменения под каждую модель.

Написали документацию:

• Прикрепили все необходимые ссылки для работы: шаблон дашборда, папка с настроенными мониторингами, сводный дашборд со всеми результатами мониторинга.

• Описали структуру хранилища.

• Описали все компоненты решения, их взаимосвязи и как их переиспользовать.

• Написали пошаговую инструкцию по созданию своих дашбордов мониторинга.

• Описали работу с gitlab (даже прописали команды для взаимодействия!) и airflow.

• Дали рекомендации по кастомизации.

• Щедро снабдили гайд иллюстрациями.

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

Как нам помог настроенный мониторинг: кейсы

Напоследок поделимся с вами несколькими кейсами, которые удалось решить, благодаря настроенному мониторингу.

Кейс 1: Скрытая работа над таблицами

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

Кейс 2: Адаптация к изменениям

Наблюдая за результатами мониторинга одной ML‑модели, мы увидели, что данные в одном блоке признаков начали принимать константные значения. Это произошло из‑за прекращения сотрудничества с одним из партнеров. Кроме того, мы заметили дрифт в важных признаках. В итоге на основе анализа мониторинга мы пересобрали признаки, избавились от дрифтующих, заменили константные и обучили новую модель, которая значительно опережала по качеству прошлую версию.

Кейс 3: Спасение перед запуском

Мы обучили модель для рекомендаций определенного продукта клиентам. По результатам АБ‑тестов приняли решение о выкатке в прод, но отложили релиз по просьбе продуктовой команды. Однако, запустили модель в работу в «теневом режиме» и настроили мониторинг. Сразу увидели дрифт данных в нескольких признаках, несмотря на отсутствие предпосылок для этого. Оказалось, что данные одного источника отличаются в тестовом и продовом слоях. В итоге, нам удалось исправить ошибку ^[7] еще до запуска модели в работу.

Бонус

Если мониторинг в вашей команде настраивает не тот человек, который обучал ML‑модель, а, как в нашем случае, опытный аналитик, он выполнит код‑ревью и сможет дать рекомендации по оптимизации запросов (или даже найдет ошибки).

А что дальше?

Мы планируем сделать сервис и добавить бизнес‑составляющую в мониторинг. А еще создать место с описанием ВСЕХ проектов, ML‑моделей и их взаимодействия.

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

Автор: 

Татьяна Бородина, аналитик данных в Точка Банк.