Привет! Меня зовут Владимир Суворов, я Senior Data Scientist в Страховом Доме ВСК и core-разработчик нашей библиотеки машинного обучения OutBoxML.
Ссылки на проект на GitHub и в Telegram. О том, как мы проектируем такие системы, какие инженерные принципы используем и как соединяем физику моделирования с ML-подходом, я регулярно рассказываю в своём Telegram-канале.
В предыдущих статьях мы разобрали AutoML на задаче о Титанике и показали систему мониторинга моделей. Это были туториалы по компонентам OutBoxML. Сегодня я хочу подняться на уровень выше и поговорить о принципах, на которых эти компоненты и вся система держатся.
Откуда я смотрю на MLOps
До осени 2022 года я работал инженером-расчётчиком в судостроении. Конструктор приносил 3D-модель судового крана, я прикладывал нагрузки, моделировал качку, искал слабые места и автоматизировал расчёты. Моя кандидатская — про оптимальное проектирование крана из карбона.
В 2022-м, когда производители ПО и ключевые эксперты ушли из России, я сел оценивать свои компетенции. И обнаружил, что то, чем я занимался, называется Data-Driven Modeling and Simulations. По сути — тот же Data Science, только в технике. Не хватало только Python и навыков визуализации данных. Я ими занялся и переехал в страхование.
С тех пор я программирую на Python уже дольше, чем считал прочность в ANSYS. Но один важный навык я принёс с собой и до сих пор считаю его главным: умение представлять любой процесс как систему уравнений, вводить допущения для декомпозиции задачи и находить основные слагаемые, приводящие к результату.
Покажу на одном примере, почему это работает.
Кран против Каско
Берём расчёт прочности судового крана и модель цены страховки Каско.
Этап | Кран | Каско |
|---|---|---|
Что считаем | Точку максимального напряжения. Если выше предела прочности — беда | Потенциальный убыток. Если матожидание выше цены полиса — беда |
Входные данные | 3D-модель: массив точек (x, y, z) со свойствами материала и связями | Таблица: возраст, стаж, мощность, регион — те же признаки в многомерном пространстве |
Подготовка | Чистим геометрию: убираем болты, фланцы, упрощаем формы | Чистим данные: пропуски, выбросы, объединяем «Toyota» и «Тойота» |
Модель | y = K · x, где K — матрица жёсткости | y = K · x, где K — коэффициенты GLM |
Оценка | Коэффициент запаса: 240 МПа при пределе прочности 242 МПа — формально цел, но рискованно | Loss Ratio: прогноз равен цене — формально работает, актуарий поднимет тариф |
Для математики нет разницы, что является координатой — положение узла металлоконструкции в пространстве или возраст водителя в пространстве признаков. Различаются инструменты, но не подходы.
И это касается не только моделей, но и систем, в которых эти модели живут. Дальше — про четыре принципа, которые я перенёс из расчётной инженерии в архитектуру 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. Слабая связность позволяет менять источник данных, не меняя итоговую цель.
Но здесь возникает парадокс гибкости. Если мы становимся слишком гибкими, мы теряем суть. Это как при строительстве дома акцентироваться только на кирпичах и технологиях их укладки — велик риск вместо уютного жилья построить бездушную промышленную фабрику.
Гибкость должна служить целям системы, а не наоборот. Первый вопрос при проектировании — «Что мы хотим получить?», а не «Как?».
Конкретный пример: мы построили AutoML для быстрого вывода классических моделей в продакшен — GLM, Catboost, Catboost over GLM. Попытки запихнуть туда тяжёлые нейронки сейчас просто размоют фокус и убьют эффективность. Мы не тратим время на инструменты, которые не соответствуют цели. Когда нам по-настоящему понадобятся нейронки — мы построим под них отдельную систему.
Куда правильнее строить специализированные системы под конкретные задачи и не бояться начинать с чистого листа.
Принцип 4. Система, прощающая ошибки
В ANSYS ты можешь задать сетку с пересечениями, неверные нагрузки или забыть про граничное условие. Программа не упадёт. Она пересчитает что сможет, выдаст предупреждение и оставит лог. Ответственность за адекватность результата — на расчётчике, но факт получения результата программа гарантирует.
Это четвёртый принцип, который я перенёс в OutBoxML. Мы заранее ждём и принимаем право пользователя на ошибку.
Мы знаем, где ввод данных и настроек может пойти не так.
Знаем, где обычная невнимательность способна обрушить процесс обучения на десятом часу работы.
Мы не ругаем пользователя, а исправляем за него ошибку с явным сообщением: «Здесь ты ошибся, мы подправили. Когда будешь смотреть результаты — учти, что параметр X переставлен на значение Y».
Пользователь всегда должен получить результат. Именно факт успешного запуска — главная задача. Чтобы пользователь думал о результате, а не боролся с интерфейсом и настройками.
Конечно, библиотека не несёт ответственности за адекватность модели Каско — так же как ANSYS не гарантирует прочность крана, если расчётчик задал неверные нагрузки. Но полный и прозрачный лог каждой операции снимает все вопросы к «чёрному ящику». Ты всегда видишь путь, по которому прошла система, и можешь повторить его.
Заключение
Хорошая ML-система — это инженерная система. Она проектируется по тем же правилам, что любая другая надёжная конструкция: с расчётом на отказы, с заменяемыми элементами, с мониторингом на входе и выходе, с гибкостью под изменения и с уважением к ошибкам пользователя.
Когда ты принимаешь, что любая система рано или поздно будет заменена новой, становится гораздо легче относиться и к архитектурным ошибкам, и к изменениям в мире.
Меняются домены — от прочности конструкций до автоматического страхования и голосовых ассистентов. Меняются инструменты — от ANSYS до Python с FastAPI и Whisper. Подходы остаются прежними.
Присоединяйтесь к нашему проекту на GitHub и в Telegram. А о принципах проектирования и инженерном взгляде на ML — в моём личном канале.
Пишите в комментариях, какие принципы из вашей предыдущей профессии вы перенесли в ML и какие из них работают лучше всего. Удачи в реализации ваших проектов!