MLOps-консалтинг: чтобы модель в продакшне была не результатом героизма, а обычным процессом
Помогаем командам, у которых модели уже работают или вот-вот выйдут к пользователям, выстроить процесс: как модель обучается, проверяется, выкладывается, наблюдается и откатывается.
Кратко
Типичная картина: модель обучена в ноутбуке, выложена вручную, а через полгода никто не может сказать, на каких данных она обучена и почему стала хуже. MLOps превращает это в процесс с учётом экспериментов, реестром моделей, автоматической выкладкой и мониторингом. Мы выстраиваем его на инструментах, которые можно развернуть у вас, и передаём команде так, чтобы он работал без нас.
Признаки того, что пора
- Модель в продакшне есть, но повторить её обучение с тем же результатом не получается.
- Выкладка новой версии модели делается вручную одним человеком, и только он знает как.
- О падении качества узнают от пользователей, а не от мониторинга.
- Несколько специалистов по данным работают параллельно, и результаты экспериментов живут в личных папках.
- В систему добавили LLM, и непонятно, как проверять изменение промпта или смену модели.
Что мы выстраиваем
Учёт экспериментов и данных
Каждый эксперимент записывается вместе с параметрами, версией кода и версией данных. Обычно это MLflow для экспериментов и DVC или аналог для версий данных. Цель простая: любую модель можно воспроизвести.
Реестр моделей
Единое место, где видно, какая версия модели в продакшне, какая на проверке, кто и почему её одобрил и на какую версию откатиться.
Автоматическая сборка и выкладка
Обучение, проверка на контрольном наборе и выкладка запускаются конвейером, а не руками. Модель, которая хуже текущей на контрольных данных, не выходит в продакшн автоматически.
Мониторинг
Наблюдаем не только за доступностью сервиса, но и за входными данными и качеством: дрейф данных, распределение предсказаний, отложенные метки, когда они появляются. Для этого подходят открытые инструменты вроде Evidently вместе с Prometheus и Grafana.
Признаки для моделей
Если одни и те же признаки считаются в нескольких местах по-разному, выносим их в общее хранилище признаков (feature store, например Feast). Это нужно не всем: при одной-двух моделях часто достаточно общей библиотеки расчёта.
Инциденты
Порядок действий, когда модель начала ошибаться: кто получает оповещение, как откатиться, как разобрать причину и что изменить, чтобы это не повторилось.
Системы на LLM
Для систем на больших языковых моделях к этому добавляются версии промптов, набор контрольных вопросов для оценки ответов, учёт стоимости и времени ответа по каждому запросу. Подробнее в статье об observability AI-систем.
Как идёт работа
- Обзор текущего процесса. Как модели обучаются, проверяются и попадают в продакшн сейчас, какие инструменты уже есть. Обычно одна-две недели.
- План. Что внедрить в первую очередь, что позже, а что вам не нужно вовсе. Мы не ставим полный набор инструментов там, где хватит двух.
- Внедрение вместе с командой. Настраиваем конвейер на одной реальной модели, а не на демонстрационной, и переводим на него остальные.
- Передача. Документация, разбор с командой, поддержка после запуска по договорённости.
Если вы ещё не дошли до модели в продакшне, начинать с MLOps рано. Тогда полезнее вывод AI-системы в продакшн, где эти практики закладываются с первого дня.
Где мы работаем
Мы работаем с компаниями по всей России удалённо. В таблице отраслевой контекст десяти крупных городов и то, какие модели там обычно приходится сопровождать.
| Город | Отраслевой контекст | Что обычно сопровождают |
|---|
| Москва | Штаб-квартиры большинства крупных банков, телеком-операторов, розничных сетей. | Скоринговые, антифрод- и рекомендательные модели с частым переобучением и требованиями к объяснимости решений. |
| Санкт-Петербург | Сильные технические вузы (ИТМО, СПбГУ, Политехнический университет), много продуктовых команд. | Модели внутри продуктов, где выкладка идёт часто и нужен быстрый откат. |
| Екатеринбург | Металлургия, машиностроение и горнодобывающая промышленность Урала. | Прогноз отказов оборудования и модели технологических процессов, где данные с датчиков меняются вместе с оборудованием. |
| Казань | Нефтехимия республики, IT-город Иннополис рядом с Казанью. | Промышленные модели и языковые модели для русского и татарского, где качество нужно отслеживать по каждому языку отдельно. |
| Новосибирск | Академгородок, институты Сибирского отделения РАН, НГУ, биотехнологии. | Исследовательские модели, которые переходят в прикладные сервисы: здесь главное воспроизводимость и учёт версий данных. |
| Краснодар | Центр одного из главных сельскохозяйственных регионов страны, крупная розница и логистика. | Прогноз спроса и урожайности с сильной сезонностью: мониторинг дрейфа и переобучение по расписанию сезона. |
| Красноярск | Добыча и металлургия края, крупная гидроэнергетика. | Компьютерное зрение на производстве: версии моделей на удалённых площадках и обновление при нестабильной связи. |
| Уфа | Нефтепереработка и нефтехимия Башкортостана. | Модели технологических режимов, где выкладка новой версии требует согласования и понятного отката. |
| Воронеж | Машиностроение, авиастроение, химическая промышленность, сельское хозяйство области. | Модели контроля качества продукции и планирования производства. |
| Сочи | Курорт и гостиничный бизнес. | Прогноз загрузки и динамическое ценообразование, где поведение гостей резко меняется между сезонами. |
Офисов в этих городах у нас нет. Отраслевой контекст описывает типичные задачи региона, а не наши проекты.
Формат работы
- Удалённо. Работаем в вашем репозитории и вашей инфраструктуре через выданный вами доступ, со встречами с командой по договорённому графику.
- Инструменты, которые можно развернуть у вас. Предпочитаем открытые инструменты, которые работают в вашем облаке или на ваших серверах. Часть зарубежных облачных сервисов для ML может быть недоступна из России или означать передачу данных за рубеж, и это учитывается при выборе.
- Данные остаются у вас. Для настройки конвейера обычно достаточно обезличенных или синтетических данных. Если нужны персональные данные, порядок доступа определяют юристы и служба безопасности вашей компании.
- Очные встречи. Возможны по договорённости, если задаче это нужно.
- Часовые пояса. Работаем в часы, удобные для Москвы. С Сибирью общая часть рабочего дня короче, и встречи мы ставим на утро по местному времени.
Почему мы
Мы эксплуатируем программные системы с 2004 года: больше 150 проектов для клиентов в 14 странах. Наша основная система работает в продакшне с 2008 года, обслуживает более 100 000 пользователей с доступностью 99.97%. MLOps для нас продолжение обычной инженерной дисциплины: версии, проверки, мониторинг и откат.
Частые вопросы
Нужен ли нам Kubernetes для MLOps?
Не обязательно. Для нескольких моделей часто достаточно конвейера сборки, реестра моделей и обычных серверов или контейнеров. Kubernetes имеет смысл, когда моделей много или нагрузка сильно меняется.
Какие инструменты вы ставите?
Те, что подходят вашей инфраструктуре и команде. Чаще всего это MLflow, DVC, Evidently, Prometheus и Grafana, а также конвейер в той системе сборки, которой вы уже пользуетесь. Если у вас уже есть рабочие инструменты, мы их не меняем без причины.
Чем MLOps для LLM отличается от обычного?
Модель вы обычно не обучаете, но меняете промпты, корпус документов и саму модель. Поэтому главное здесь набор контрольных вопросов для оценки ответов, версии промптов и наблюдение за стоимостью и временем ответа.
Сколько времени занимает внедрение?
Обзор текущего процесса занимает одну-две недели. Срок внедрения зависит от числа моделей и того, что уже есть, и называется после обзора.
Что останется у нас после завершения работы?
Работающий конвейер в вашей инфраструктуре, документация и команда, которая с ним уже работала. Все учётные записи и ключи оформлены на вас.
SLAtech LTD