Когда в компании появляется первая ML‑модель, кажется, что самое сложное выбрать алгоритм и добиться хороших метрик. Но настоящий вызов начинается позже: когда моделей становится десятки, затем сотни, а скорость бизнеса начинает требовать обновлений не раз в год, а раз в недели.
В Страховом Доме ВСК мы довольно быстро поняли: без стандартизации и автоматизации машинного обучения масштабирование превращается в хаос. Так у нас появился собственный AutoML‑фреймворк как ответ на реальные боли промышленного ML.
Когда ML перестает быть «экспериментом»
В страховании по‑прежнему доминируют классические ML‑модели: табличные данные, логистическая регрессия, GLM, градиентный бустинг. Именно они дают предсказуемый и измеримый бизнес‑эффект — от скоринга до антифрода.
Типичный старт выглядит знакомо:
исследование данных → фичи → подбор алгоритмов → первые метрики.
На этом этапе редко кто думает о будущем жизненном цикле модели. Но довольно быстро появляются:
model_1, model_2_upd, model_final_v3;
разные версии датасетов и фичей;
метрики, посчитанные «как получилось»;
сервисы с похожей логикой, но разной реализацией.
И если в начале это кажется управляемым, то при росте числа моделей ситуация резко меняется. Поддерживать всё это становится всё сложнее. Любая общая доработка — например, оптимизация расчета или исправление системной ошибки — требует изменений в каждом сервисе по отдельности. Масштабирование команды и скорости разработки при этом практически невозможно.
В какой‑то момент появляется естественная мысль: а не объединить ли всё это в единый продукт? Чтобы можно было переиспользовать готовые решения, вносить правки в одном месте, автоматически считать метрики, сравнивать версии, строить графики и рассылать отчеты.
Когда количество п��реходит в системную проблему
В компании переломный момент наступил, когда:
число моделей приблизилось к сотне;
вариантов пайплайнов обучения и внедрения стало больше десятка;
одна и та же логика начала дублироваться в разных сервисах.
Мы столкнулись со следующими системными проблемами:
Из‑за большого объема уникального кода для каждой модели стало практически невозможно проводить полноценные код‑ревью и выстраивать быстрый и надежный процесс валидации качества.
Не было единого подхода к расчету метрик — ни технических, ни бизнесовых. Каждый раз появлялись новые, плохо интерпретируемые для бизнеса числа и графики, что сильно замедляло принятие решений.
Процесс внедрения каждой модели был почти уникальным. Сервисы отличались и на уровне кода, и на уровне архитектуры, и по бизнес‑логике. Поддержка такого зоопарка стала чрезмерно дорогой.
Регулярно возникали ошибки при внедрении: неописанное дефолтное поведение, новые категории, отсутствующие в обучающей выборке, заведомо некорректные числовые значения (например, возраст 2025 лет), рассинхрон в преобразованиях фичей между обучением и инференсом.
Большое количество уникальных сервисов не позволяло качественно покрыть их мониторингами: сдвиги данных, рост доли пропусков, появление новых категорий и так далее.
В результате новая версия модели могла разрабатываться до полугода, а запуск новой до года. Для рынка, где цена ошибки и простоя высока (как в ИТ‑системах, так и в страховых продуктах компании), это неприемлемо.
Зачем нам понадобился собственный AutoML-фреймворк
В какой‑то момент стало очевидно: проблема не в конкретных моделях, а в отсутствии единого продукта вокруг ML.
Мы хотели:
переиспользовать архитектурные решения;
вносить типовые изменения в одном месте;
автоматически считать метрики и сравнивать версии;
ускорить путь от идеи до прода с месяцев до дней, а иногда часов.
Так родилась идея собственного AutoML-фреймворка, заточенного под наши реальные сценарии и инфраструктуру.
Принципы, на которых мы его строили
Мы не стремились сделать «универсальный AutoML для всего». Вместо этого сформулировали набор практичных требований:
Компонентная архитектура: простые независимые блоки со стабильными интерфейсами.
Единое описание модели: все — от фичей до метрик — в одном месте, а не разбросано по коду.
Конфигурационный подход: типовые изменения без переписывания логики.
Встроенные проверки корректности (дефолты, типы, обязательные поля).
Автоматический расчет и сравнение метрик, включая бизнес-показатели.
Полное логирование и версионирование экспериментов.
Автодеплой при успешном прохождении проверок.
Идентичная логика фичей для обучения и инференса.
Последний пункт оказался одним из самых сложных: батч‑обработка и онлайн‑инференс требуют разной оптимизации. Мы решили это через общий пайплайн с разными обработчиками и обязательными тестами на консистентность.
Когда AutoML действительно оправдан
Наш опыт показывает: AutoML‑фреймворк дает максимальный эффект, если:
увас много однотипных моделей;
модели регулярно обновляются;
фичи эволюционируют быстрее, чем архитектура.
И наоборот, он будет избыточен для:
R&D и MVP-проектов;
задач с принципиально разной природой (CV, NLP, сложные таймсерии);
случаев, когда в проде живут одна-две модели.
Итог
AutoML — это не про «заменить дата‑сайентистов кнопкой». Это про инженерную дисциплину, скорость и управляемость ML в проде. Для нас собственный фреймворк стал способом снизить операционные риски, ускорить развитие моделей и говорить с бизнесом на одном языке метрик и эффектов.
В следующей статье разберем архитектуру нашего решения и покажем, как оно выглядит «под капотом».
А с какими проблемами масштабирования ML сталкивались вы? Делитесь опытом в комментариях.
