Инженерный подход к MLOps: как принципы расчётной механики ложатся в архитектуру AutoML

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

В предыдущих статьях мы разобрали AutoML на задаче о Титанике ^[2] и показали систему мониторинга моделей ^[3]. Это были туториалы по компонентам OutBoxML. Сегодня я хочу подняться на уровень выше и поговорить о принципах, на которых эти компоненты и вся система держатся.

Откуда я смотрю на MLOps

В 2022-м, когда производители ПО и ключевые эксперты ушли из России, я сел оценивать свои компетенции. И обнаружил, что то, чем я занимался, называется Data-Driven Modeling and Simulations. По сути — тот же Data Science, только в технике. Не хватало только Python и навыков визуализации данных. Я ими занялся и переехал в страхование.

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

Покажу на одном примере, почему это работает.

Кран против Каско

Берём расчёт прочности судового крана и модель цены страховки Каско.

Для математики ^[4] нет разницы, что является координатой — положение узла металлоконструкции в пространстве или возраст водителя в пространстве признаков. Различаются инструменты, но не подходы.

И это касается не только моделей, но и систем, в которых эти модели живут. Дальше — про четыре принципа, которые я перенёс из расчётной инженерии в архитектуру OutBoxML и AI-ассистентов, который мы сейчас разрабатываем.

Принцип 1. Самый слабый элемент

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

В ML то же самое. Примеры неисправностей:

• Сменился формат данных — модель получает мусор на вход.

• «Отвалился» внешний источник — вместо фичи приходит NULL.

• Ушёл ключевой инженер из команды (bus factor).

• В новых данных все возраста стали AGE = 100.

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

При проектировании мы закладываем четыре свойства:

• Изоляция. Отказ одного элемента не вызывает отказ системы. Часть функционала отключается, остальные подсистемы работают.

• Заменяемость. Любой элемент можно заменить быстро и без переписывания соседей.

• Резервирование. Автоматическое переключение на дублирующую подсистему.

• Валидация на входе. Автоматические проверки данных. Не пускаем мусор в систему.

В OutBoxML это реализовано через разделение ответственности на классы внутри оркестраторов — AutoMLManager, DataSetsManager, MonitoringManager. В голосовом ассистенте — через разделение на STT-движок (Whisper), LLM-движок (Gemini) и PromptEngine с PostProcessor. Любой компонент меняется без переписывания соседних.

Простым языком: если мы всегда ждём плохого, мы к этому готовы. И когда оно случается — всё уже не так плохо.

Принцип 2. Реализм против перфекционизма

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

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

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

Я за второй вариант. Он же — стандарт инженерных расчётов: мы не доказываем, что конструкция не сломается никогда; мы считаем коэффициент запаса и закладываем мониторинг износа.

Система мониторинга — это отдельный класс-контроллер. Он не лезет внутрь процесса AutoML и модели. Он следит за «входом» и «выходом» системы. В моей практике DS всегда на шаг позади Data Engineer: инженер успевает наделать больше ошибок, чем DS успевает их исправить. Поэтому мониторинг данных — критическая часть инфраструктуры, а не «фича».

Основа мониторинга данных в OutBoxML:

• Контроль дата-дрифта. PSI и KL-divergence между текущим потоком и эталоном.

• Валидация источников. Не «отвалился» ли внешний сервис, не приходят ли NULL вместо важной фичи.

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

Задача мониторинга — не «показать график», а сформировать сигнал о проблеме и оценить последствия. Сигнал передаётся по цепочке, и система может изолировать отказ, переключиться на резервную подсистему или применить временную обработку. Мониторинг превращает героическое тушение пожаров в плановое обслуживание.

В голосовом ассистенте та же идея реализуется на уровне инфраструктуры: warm-up Whisper в RAM при старте через Lifespan, атомарные транзакции обновления статуса в БД, постпроцессинг ответов LLM регулярными выражениями. Это всё — превентивные проверки на «входе» и «выходе» каждого узла. Мы не верим, что Gemini вернёт чистый текст без артефактов. Мы заранее ставим PostProcessor.

Принцип 3. Гибкость без потери фокуса

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

Три практических правила:

• Принцип подстановки Лисков (LSP). Не латаем старые элементы. Создаём новые и переподключаем. Разбираться в «древнем» коде — сомнительное приключение, проще заменить деталь целиком.

• Слабая связность. Модули знают друг о друге как можно меньше. Если я меняю Whisper на другой STT-движок, блок генерации текста (Gemini) вообще не должен об этом «знать». Они общаются через абстрактную прослойку.

• Интерфейсы — наше всё. Система состоит из «чёрных ящиков» с чёткими входами и выходами. Пока интерфейс соблюдён, начинка может быть любой.

В OutBoxML эта философия пронизывает всю архитектуру. У вас есть набор интерфейсов: Extractor, PrepareDataset, BaseModel, BaseMetric, BaseFS, MonitoringReport. Каждый можно использовать «из коробки» или подменить кастомной реализацией. На выходе всегда модель:

AutoMLManager(...).update_models() -> Model

В голосовом ассистенте — тот же контракт, только результат другой:

AIAssistantService(...).result() -> Text

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

Но здесь возникает парадокс ^[5] гибкости. Если мы становимся слишком гибкими, мы теряем суть. Это как при строительстве дома акцентироваться только на кирпичах и технологиях их укладки — велик риск вместо уютного жилья построить бездушную промышленную фабрику.

Гибкость должна служить целям системы, а не наоборот. Первый вопрос при проектировании — «Что мы хотим получить?», а не «Как?».

Конкретный пример: мы построили AutoML для быстрого вывода классических моделей в продакшен — GLM, Catboost, Catboost over GLM. Попытки запихнуть туда тяжёлые нейронки сейчас просто размоют фокус и убьют эффективность. Мы не тратим время на инструменты, которые не соответствуют цели. Когда нам по-настоящему понадобятся нейронки — мы построим под них отдельную систему.

Куда правильнее строить специализированные системы под конкретные задачи и не бояться начинать с чистого листа.

Принцип 4. Система, прощающая ошибки

В ANSYS ты можешь задать сетку с пересечениями, неверные нагрузки или забыть про граничное условие. Программа не упадёт. Она пересчитает что сможет, выдаст предупреждение и оставит лог. Ответственность за адекватность результата — на расчётчике, но факт получения результата программа гарантирует.

Это четвёртый принцип, который я перенёс в OutBoxML. Мы заранее ждём и принимаем право пользователя на ошибку ^[6].

• Мы знаем, где ввод данных и настроек может пойти не так.

• Знаем, где обычная невнимательность способна обрушить процесс обучения на десятом часу работы.

• Мы не ругаем пользователя, а исправляем за него ошибку с явным сообщением: «Здесь ты ошибся, мы подправили. Когда будешь смотреть результаты — учти, что параметр X переставлен на значение Y».

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

Конечно, библиотека не несёт ответственности за адекватность модели Каско — так же как ANSYS не гарантирует прочность крана, если расчётчик задал неверные нагрузки. Но полный и прозрачный лог каждой операции снимает все вопросы к «чёрному ящику». Ты всегда видишь путь, по которому прошла система, и можешь повторить его.

Заключение

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

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

Меняются домены — от прочности конструкций до автоматического страхования и голосовых ассистентов. Меняются инструменты — от ANSYS до Python с FastAPI и Whisper. Подходы остаются прежними.

Присоединяйтесь к нашему проекту на GitHub ^[7] и в Telegram ^[8]. А о принципах проектирования и инженерном взгляде на ML — в моём личном канале ^[9].

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