Или как избавить DS от рутинных задач по обучению и обновлению моделей и их дальнейшему передеплою в проде?

Всем привет! Я Настя Бондарева, senior Data Scientist в Хабе Юридических Лиц Альфа-Банка, лидирую инициативу ARTEML (AutoReTrainable ML). В статье расскажу, как мы упростили себе работу и часть рутинных задач, число которых росло как снежный ком с ростом количества применяемых моделей.

В чём задача AutoReTrainableML и зачем это нужно?

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

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

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

На примере одной из моделей рассмотрим, как со временем изменяется метрика precision@k. Доля продаж продукта после маркетинговой коммуникации падает на 38% за год. Это происходит из-за того, что со временем модель начинает деградировать и хуже ранжировать клиентов, склонных после маркетинговой коммуникации приобрести этот продукт.

Рассмотренный случай деградации модели не является частным, это закономерность.

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

Тому есть несколько причин.

Features Drift. Чаще всего показатели модели устаревают из-за изменения признаков, на которых обучена модель. Например, изменились данные пользователей или данные по потреблению продукта вследствие разных причин: сезонности или нестабильности экономики, из-за появления новых продуктов и, как следствие, новых интересов на рынке спроса и другое. Модель привыкла «видеть» одну картину, но теперь она изменилась, и точность прогнозов «поплыла». Но помимо устаревания старых закономерностей, также могут появляться новые, и можно за счет этого получить повышение качества модели, если вовремя обновить модель.

Labels Drift. Изменение распределения целевой метки со временем. Наглядный пример — изменение размера среднего чека на клиента вследствие ускорения инфляции, что напрямую влияет на качество предсказания моделью.

Data Quality Issues. Проблемы, связанные с качеством поставляемых данных. Например, отключение или неисправность источника, из-за которого в данных появляется шум/пропуски.

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

• ёмкость маркетингового канала — 10 000 звонков в месяц;

• стоимость 1 звонка — 400 рублей;

• доход от продажи единицы продукта — 800 рублей.

При точности 69% доход от применения модели:

10 000 * 0,69 * 800 — 10 000 * 400 = 1 520 000 рублей

При падении точности до 34% бизнес-процесс становится убыточным для банка:

10 000 * 0,34 * 800 — 10 000 * 400 = - 1 280 000 рублей

В нашем случае граница безубыточности для метрики модели — 50% точности.

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

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

Почему мы решили переобучать модели в автоматическом режиме?

Переобучение или обновление модели вручную — это часто неэффективный и рутинный процесс. 

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

Каждая итерация требует времени на написание кода, а затем на его ревью и корректировку. Чем больше портфель моделей, тем больше ресурса DS необходимо на их обновление. В 2023 году на обновление моделей в Альфа-банке уходило до 10% времени наших DS. С учетом роста количества моделей в 2024 году на это должно было бы уходить от 25 до 35% времени.

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

Но подобный процесс может быть оптимизирован путем шаблонизации. 

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

• Создание такой библиотеки позволит обучать и переобучать модели быстрее и с минимальными затратами ресурсов Data Scientist, тем самым высвободив время.

• Создание такого пайплайна вывода поставит на рельсы текущий процесс обновления моделей.

Эти предпосылки натолкнули нас на мысль о создании AutoReTrainable ML Framework.

AutoReTrainable ML Framework — это система, способная автоматизировать процессы создания (обучения) и обновления (переобучения) моделей для бизнес-задач.

В этой парадигме ML-пайплайн выглядит следующим образом:

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

Как итог при объединении этих двух инструментов, от DS'a при первоначальной разработке требуется:

• обучить и оценить качество и адекватность полученной модели с помощью ARTEML;

• полученную модель выводить через MLOps пайплайн для автопереобучения;

• последующие процедуры по мониторинга и обновления модели уже автоматизированы. 

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

Как устроен фреймворк ARTEML?

Это набор инструментов, предназначенных для упрощения и ускорения работы DS посредством автоматизации множества рутинных этапов обучения, инференса, мониторинга и сравнения моделей, а также описания шагов и параметров модели в виде low-code интерфейса. ARTEML написан на Python и помимо ML-логики, также содержит интерфейсы для работы с банковскими системами и хранилищами данных.

Конфиг

DS взаимодействует с фреймворком ARTEML через YAML-конфиг. Пример конфига будет разобран ниже.

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

Соответственно, первый шаг для пользователя — создание такого конфига, отправной точки для выполнения остальных этапов. 

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

Обучение

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

model_name: automl_model
version: 1
model_info: ...
key_metric: roc_auc
log_to_mlflow: true
report_path: report
target: ...
features: ...
preselect_features:
  data:
    dt: ...
    range_dt: true
    sampling_parameters:
      sampling_n_rows: 200000
  feature_selection_params:
    options: 
    - by_nan_rate
    - split
    nan_rate_acceptable: 0.98
    n_top_features:
      split: 200
train:
  data:
    train: ...
    val: ...
  feature_selection_params:
    options: 
    - by_nan_rate
    - by_psi
    - shap
    - permutation
    nan_rate_acceptable: 0.98
    psi_params: ...
    n_top_features: ...
  model_path: model
  model_train_parameters:
    init_params: ...
    fit_params: ...
calibration:
  data: ...
  parameters:
    use_score: score_raw
    method: auto
    num_bins: 10
    split_type: quantile
test:
  data: ...

Мы в команде провели множество экспериментов с разными известными AutoML-библиотеками на разных моделях (ниже представлены полученные метрики на одной из рассмотренных моделей).

По результатам экспериментов и оценке метрик качества, скорости и удобства, в качестве основного ML-ядра обучения в ARTEML мы выбрали решение с открытым исходным кодом от Amazon — AutoGluon. Под капотом он ансамблирует известные типы моделей: CatBoost, LightGBM, XGBoost, Random Forest, Linear Regression и другие. Также можно задать параметры для исключения определенных типов моделей, для ограничения по времени и т.д.

В ARTEML под каждую модель в MLFlow создается эксперимент с названием модели и сама модель также регистрируется в MLFlow Model Registry. Во время обучения мы логируем множество артефактов, по которым можно сделать выводы о самом процессе и полученным результатам. 

Артефактами являются: 

• ссылки на датасеты, сохраненные на Hadoop, чтобы была возможность вытащить их через API MLFlow; 

• параметры финальной модели; 

• метрики, полученные во время обучения; 

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

• полученные логи обучения; 

• информация по отбору признаков; 

• сама модель и лидерборд полученной модели; 

• различные артефакты тестирования качества модели: метрики, посчитанные на полных выборках и в разрезе по датам, графики распределения этих метрик, распределение таргета по модельным персентилям и т.д.; 

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

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

Инференс

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

inference:
  sample_collection_script_path: scripts/sample_collection.py
  sample_function_name: inference_sample
  table: ...
  score_calibration: true

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

Контроллер

Контроллер объединяет в себе шаги мониторинга и сравнения моделей (Quality Gate), поскольку функционал в обоих случаях схож — нужно на выборках контроля считать метрики. Давайте отдельно разберем каждый из шагов.

А. Мониторинг

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

Каждая модель уникальна и требует подсчёта разных метрик с разными параметрами, которые DS может задать через конфиг. Например, основные из них для склонностных моделей: ROC-AUC,  Precision@k, Recall@k, PSI скора (отвечает за стабильность полученных предсказаний). Вот пример конфига, с параметрами, которыми может управлять DS для мониторинга.

monitoring:
  sample_collection_script_path: scripts/sample_collection.py
  sample_function_name: monitoring_sample
  metric_table: ...
  dt: ...
  key_metric: roc_auc
  base_score: 0.85
  epsilon: 0.03
  metrics:
  - roc_auc
  - precision_at_k
  metrics_params:
    precision_at_k:
      k_range:
      - 0.1
      - 0.2
      - 0.3
      mode: share
  additional_info:
    psi_features: 0.1
    psi_score: 0.1
    psi_target: 0.1

Б. Сравнение моделей (Quality Gate)

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

quality_gate:
  sample_collection_script_path: scripts/sample_collection.py
  sample_function_name: quality_gate_sample
  metric_table: ...
  dt: ...
  key_metric: roc_auc
  epsilon: 0.02
  metrics: ...
  metrics_params: ...
  additional_info:
    student_test: true

Как же это всё работает и связано между собой?

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

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

Если финальное качество устраивает DS и бизнес-подразделение, то уже можно приступить к деплою модели в систему исполнения с помощью MLOps пайплайна автопереобучения. Подробнее почитать как устроено решение инфраструктурно можно в статье Автопереобучение моделей в Production. Здесь разберем коротко основную концепцию работы и какие усилия для вывода требуются от DS.

Хочу отметить, что команде MLOps для создания пайплайна пришлось сильно постараться, чтобы поменять IT-регламент в банке и убедить всех в необходимости такой системы. 

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

На изображении ниже указано из каких основных компонент состоит пайплайн MLOps, и как эти компоненты между собой взаимодействуют.

В пайплайне присутствуют компоненты обучения, инференса, мониторинга и сравнения моделей. В репо деплоя все эти модули закрываются библиотекой ARTEML и кладутся в качестве исходного шаблона (при необходимости возможность кастома кода всегда остается у DS). 

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

• Обучить модель на ретро датах.

• После пометить полученную модель как продовую.

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

• После DS может запустить инференс и посмотреть полученные скоры модели

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

Также при каждом непрохождении и прохождении мониторинга или quality gate DS получает уведомления на почту и может изучить полученные логи и результаты (посмотреть таблицы метрик, полученные артефакты в MLFlow по новому обучению). 

Деплой новой версии модели без изменения программного кода происходит без процедур ревью и ФТ по быстрому (автоматическому) процессу. При обнаружении ошибок в автоматически обновленной модели проработана возможность быстрого отката к предыдущей версии.

Необходимые пререквизиты

Автоматизация ML-процессов, создание системы автопереобучения требует определённой технологической зрелости. В течение 2022-2023 годов у нас появилась указанная новая инфраструктура для машинного обучения, но не стоит сразу же выстраивать процесс автопереобучения, если нет этих инструментов по автоматизации.

• Feature Store. Здесь все поступающие данные автоматически обрабатываются etl-процессами и из них выделяется список фичей. Всего их сейчас около 25 000. Фичи организованы в лонг-листы по группам клиентов (например, лонг-лист для юридических лиц содержит свыше 3000 фичей). И любая модель может «заглянуть» в соответствующий список при необходимости переобучения.

• Target Store. В нём поставлены на регулярный расчет все необходимые целевые события, относящиеся к определенным моделям.

• Платформа для разработки моделей — сервис для DS (Jupyter notebook, MLFlow, Bitbucket, Airflow и другие)

• Единая Система Исполнения Моделей — СИМ, облегчающая внедрение моделей и предоставляющая возможность тестового развертывания модели.

Что получили

В итоге у нас есть AutoReTrainable ML Framework — первая в банковской сфере в России полностью автоматическая система переобучения внедрённых в эксплуатацию моделей.

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

AutoReTrainable ML Framework имеет три уникальных характеристики, которых нет среди других решений по автоматизации машинного обучения в банках в России. 

• Это система постоянного мониторинга моделей, работающих в промышленных системах и обратной связи. 

• Сквозной процесс автоматизации — от выделения фичей до бесшовной замены старой модели на новую в работающей бизнес-системе. Плюс минимальное участие человека в принятии решений. 

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

Внедрение повысило среднегодовое качество моделей на 5-7%. Без использования переобучения точность прогнозов моделей начинает падать через полгода использования. Регулярный мониторинг и своевременное переобучение возвращает метрики на исходный уровень. Обычно требуются одна-две таких процедуры в год. 

Прогнозируемый финансовый эффект на 2024 год — экономия 200 млн рублей. 

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

Как работа изменилась для DS: сравнительная таблица.

Другими словами для DS изменился путь разработки и выкатки модели. Она стал проще. И быстрее.

Благодарности

Выражаем благодарность всем причастным к созданию AutoReTrainable ML Framework.

• Команда Департамента Продвинутой Аналитики: Константин Четин, Максим Тюриков, Андрей Мирошниченко, Кирилл Анпилов, Дмитрий Тырин, Тимофей Лисоченко.

• Коллеги MLOps: Екатерина Лазаричева, Марк Кузнецов, Максим Синюгин, Дмитрий Гончаров, Илья Мясников, Александр Егоров, Артем Соловьев.