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

В эпоху ChatGPT, LLM и Reinforcement Learning классические методы машинного обучения часто остаются в тени. Однако для большинства бизнес-задач именно они — бустинг и GLM — оказываются наиболее эффективными. Они не только показывают отличные результаты, но и, что критически важно, обеспечивают интерпретируемость, которую часто требуют бизнес-заказчики и регуляторы. Попробуйте объяснить страховому актуарию, как именно нейросеть оценила риск клиента — задача нетривиальная. С GLM-моделями таких проблем не возникает.

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

Зачем нужны Auto ML фреймворки

Мечта любого дата‑сайентиста ­‑ получить готовый ML‑пайплайн «из коробки», где:

• Обучение базовой модели запускается одной командой;

• Производится сравнение с предыдущей версией модели;

• Рассчитывается потенциальный финансовый эффект;

• Принимается решение о деплое модели на основе метрик;

• Результаты экспортируются в MLFlow, Git, дашборды, письма и т. д.

• Вся информация о процессе, параметрах логируется.

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

Что же даёт хороший ML-фреймворк?

• Единый процесс обучения

• Стандартизированные пайплайны для feature engineering.

• Автоматический расчёт метрик (включая бизнес-показатели, например, прогнозируемую прибыль).

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

• Версионирование артефактов и запусков (конфиги, метрики, модели).

• Интеграция с модель-репозиториями (MLflow, Gitlab).

Как итог: быстрый вывод в продакшен.

Рассмотрим технические особенности работы с нашим фрейморком на примере классической задачи о Титанике.

Задача о Титанике

Задача о Титанике является одной из самых известных и часто используемых в обучении машинному обучении. Думаю, что в подробном описании не нуждается. Она основана на исторических данных о пассажирах, которые находились на борту знаменитого лайнера «Титаник», затонувшего 15 апреля 1912 года в северной части Атлантического океана.
Цель модели состоит в том, чтобы предсказать, выживет ли пассажир (т.е. будет ли он спасен или нет) на основе различных признаков, таких как:

• Пол (Sex): Мужчина или женщина — исследования показывают, что женщины и дети спасались чаще.

• Возраст (Age): Молодые дети и пожилые люди имели разные шансы на выживание.

• Класс (Pclass): Социальный статус пассажиров, определяющий уровень комфорта и возможностей в случае эвакуации.

• Число братьев/сестер или супругов на борту (SibSp): Наличие семьи на борту могло повлиять на шансы на выживание.

• Цена билета (Fare): Экономическая способность пассажиров также могла играть определенную роль в их выживании.

• Место отправления (Embarked): Порт, из которого пассажир сел на борт, мог отражать социальные и экономические условия.

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

Знакомство с нашим Auto ML фреймворком

Как организовать непрерывное обновление моделей без простоя сервиса: в современных ML-системах одна из ключевых задач — обеспечить бесперебойную работу инференса, одновременно позволяя моделям постоянно обучаться на новых данных. В этой статье мы разберем архитектуру такого решения на классическом примере набора данных «Титаник», реализованного с помощью FastAPI, фоновых процессов и механизма автоматического обучения и деплоя моделей (AutoML).

Архитектура решения

Запуск библиотеки подробно описан в статье Библиотека OutboxML от Страхового Дома ВСК / Хабр. Для дальнейшей работы выбираем ветку v. 0.8.1

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

• Сервис инференса FastAPI (examples/titanic/run_service.py): принимает прогнозные запросы в реальном времени.

• Фоновый процесс (examples/titanic auto_ml_example.py): периодически проверяет новые данные с заданным интервалом, переобучает модели и обновляет продакшен-сервис. Новая модель, обеспечившая критерий качества по сравнению с предыдущей, автоматически подхватывается сервисом.

Такое разделение гарантирует, что процесс обучения не помешает работе API.

Компонент 1: Сервис инференса на FastAPI

Запуск сервиса является точкой входа для прогнозов. Мы инициализируем приложение и загружаем модель. Параметры host и port передаются для гибкой настройки подключения. Запуск ведется через bash:

python -m service --host 127.0.0.1 --port 8080
                  Код модуля:
from outboxml.service import run_service

def main(host="127.0.0.1",
         port=8080,
         ):
    run_service(
     host=host,
     port=port)

if __name__ == "__main__":
    main()

Компонент 2: Фоновый процесс AutoML

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

Его алгоритм работы:

• Циклический мониторинг данных: Процесс «просыпается» каждые 2 минуты (интервал легко настраивается).

• Мониторинг данных: Он проверяет базу данных (например, PostgreSQL) или файловую систему на наличие новых транзакций (записей о пассажирах).

• Запуск обучения: Если новые данные обнаружены, запускается скрипт обучения. Этот скрипт передается в виде callback, что делает систему гибкой и расширяемой.

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

• Деплой лучшей модели: Если новая модель оказывается лучше, она помечается в MLflow с определенным тегом, например, Deployment_deсision = True, после чего сразу загружается в сервис FastAPI c помощью MLFlowRelease, заменяя старую модель в памяти.

def main(auto_ml_script: Callable, config: Any, waiting_time: float):
    params = {'script': auto_ml_script, 'config': config, 'waiting_time': waiting_time}

    while True:
        check_postgre_transaction(**params)
        MLFLowRelease(config=config).load_model_to_source_from_mlflow(group_name='example_titanic')
        time.sleep(waiting_time)

if __name__ == "__main__":
    main(auto_ml_script=titanic_example,
         config=config,
         waiting_time=2 * 60,
         )

Как это работает вместе

Запуск:

• В одном терминале: python / –m run_service.py --host 0.0.0.0 --port 8000

• В другом терминале: python / auto_ml_example.py

• Скрипт добавления строки в таблицу add_to_db находится в auto_ml_example.py

Работа в продакшене:

• Пользователи отправляют HTTP-запросы на /predict API-сервиса и мгновенно получают ответы.

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

Обновление:

• Как только появляются новые данные, запускается цикл обучения.

• Обучение и валидация проходят изолированно от работающего API.

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

Ключевая идея — обучение не мешает API. Пользователи всегда получают ответы, а новые модели подгружаются «бесшовно».
Далее разберем процесс AutoML более подробно.

Процесс Auto ML

Как это работает

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

Загрузка и проверка данных. После запуска система:

• Загружает новые данные.

• Проверяет их на наличие новых признаков (features) или новый строк.

• Запускает проверку новых факторов и подбора гиперпараметров моделей.

Обучение и валидация модели. Затем пайплайн:

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

• Сравнивает её качество с предыдущей продакшен-версией по набору метрик.

• Ключевой момент: Решение о деплое принимается автоматически на основе предзаданных условий в конфиге. Эти условия включают как стандартные ML-метрики (например, mae), так и бизнес-метрики, которые может задать пользователь (например, ожидаемый прирост маржи).

Формирование отчетности. По итогам работы система автоматически готовит детальный отчёт в формате HTML или email-письма. В отчёт попадают все ключевые артефакты: графики, метрики, проверенный признаки. Все артефакты (модели, конфигурационные файлы, лог выполнения и т.д.) выгружаются в MLFlow. Метрики выгружаются в Grafana.

Деплой. Если система развёрнута в продакшене и новая модель прошла все проверки, она поступает в предразвёрнутый сервис на основе FastAPI, который предоставляется «из коробки».

Итог: Весь процесс — от появления новых данных до выкладки улучшенной модели в продакшен — полностью автоматизирован. Пользователю достаточно настроить конфигурацию один раз, и система будет работать по принципу set-and-forget, запускаясь по триггеру и самостоятельно принимая решения.

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

• AutoMLManager централизует управление всем пайплайном машинного обучения: от обучения моделей и их сравнения с предыдущими версиями до расчёта метрик качества и финальной выгрузки лучших кандидатов в продакшен.

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

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

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

Модульность и гибкость архитектуры реализуется через систему подключаемых интерфейсов, которые поддерживаются каждым из трёх основных классов. Рассмотрим, как это работает на примере задачи с «Титаником».

Процесс начинается с извлечения данных (Extractor). Запускается экстрактор через метод extract_dataset, и на выходе получается DataFrame для дальнейшей обработки.
Затем в дело вступает предобработка (DataPreprocessor, PrepareDataset). Данные поступают в препроцессор, где подготавливаются согласно правилам, заданным в конфигурации. На этом этапе также можно подключить кастомный интерфейс подготовки PrepareDataset с его абстрактным методом prepare_data, возвращающим объект PrepareDatasetResult.

Следующий этап — обучение моделей (BaseModel). По умолчанию модель выбирается из конфига согласно параметру wrapper, но возможна и передача кастомной модели с обязательными методами fit и predict, поддерживающей классическую архитектуру, например, как у sklearn.BaseEstimator.

После обучения происходит расчёт метрик (BaseMetric). Контейнер с результатами передаётся базовому интерфейсу ModelMetrics, который поддерживает пользовательские метрики, реализованные через класс BaseMetric с абстрактным методом calculate_metrics, что обеспечивает гибкую систему оценки качества.
Далее система проводит A/B тесты (RetroFS) для проверки значимости новых фичей, используя как встроенные, так и кастомные механизмы анализа через интерфейс BaseFS.

Завершающий штрих — формирование отчетов. Фреймворк поддерживает различные форматы, такие как HTML и email, через интерфейсы HTMLReport и Email, позволяя гибко настраивать содержимое итоговых документов.

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

Преимущества архитектуры

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

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

Выводы

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

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

Присоединяйтесь к нашему проекту на  GitHub и в Telegram.

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