MLOps: развёртывание ML-моделей в продакшн, пайплайны и мониторинг

Пакетный запуск по расписанию

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

Сервис с ответом по запросу

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

Что проверяем до выпуска в любом режиме

• Воспроизводимость. На тех же входах в вашей среде получаются те же ответы, что на стенде разработки.
• Одинаковые признаки. Расчёт входных величин написан один раз и применяется и при обучении, и в сервисе, иначе модель в работе видит не то, что видела при обучении.
• Зафиксированное окружение. Образ собирается заново без доступа в интернет.
• Поведение на плохих данных. Пустые поля, неизвестные значения, нули вместо чисел: сервис отвечает ошибкой или запасным результатом, а не случайным числом.
• Скорость на вашем железе. Время ответа измеряется там, где модель будет работать.

Общая схема — в статье «Что такое MLOps простыми словами», разбор дрейфа и отката — в материале «Как следить за моделью в продакшене».

Уровень сервиса

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

Уровень данных

Что приходит на вход: доля пустых полей, диапазоны значений, новые категории, которых не было при обучении, сдвиг распределений относительно обучающего периода. Это видно в день возникновения. Но сдвиг входов — повод посмотреть, а не повод автоматически переобучать: входы могут сдвинуться, а качество остаться прежним.

Уровень качества

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

Кому уходит сигнал

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

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

Если вы развёртываете языковую модель на своём сервере, то основу описывает страница LLM на своём сервере, а скорость и загрузку железа разбирает страница про оптимизацию инференса. MLOps здесь добавляет версии, оценку качества и порядок обновления.

Присмотр после выпуска — сопровождение. Если модель оказалась частью чужой системы, которую сначала надо понять, начинают с аудита кода и архитектуры.