Пилот работает у одного, должен работать у всех и без нас

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

Минимальный рабочий набор выглядит так. Реестр моделей с версиями и метриками каждого обучения. Привязка каждой версии модели к версии датасета. Автоматизированный конвейер, который проходит путь от данных до развёртывания без ручных действий. Возможность откатиться на предыдущую версию за минуты. И документация, описывающая, как всё это устроено, чтобы систему мог поддерживать не только её автор.

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

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

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

Практический регламент, который мы настраиваем, состоит из четырёх элементов: ежедневный контроль входных распределений, еженедельный отчёт по доле ручных исправлений, ежемесячный замер метрик на размеченной выборке и порог, при достижении которого запускается переобучение. Без такого регламента мониторинг превращается в набор графиков, на которые никто не смотрит.

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

Управление начинается с измерений. Мы считаем профиль реальных запросов: распределение длины входа и выхода, а не среднее значение. Затем применяем технические меры. Ограничение объёма контекста и отбор только релевантных фрагментов вместо десятка найденных. Кеширование повторяющихся запросов, которых в типовых процессах бывает 15–30%. Разделение задач: для простой классификации используется компактная модель, тяжёлая подключается только там, где она действительно улучшает результат.

Если данные нельзя выносить во внешний сервис, считаем вариант с локальным развёртыванием. Открытые модели на собственных мощностях дают фиксированную стоимость и предсказуемость, а производительный инференс обеспечивается движками вроде vLLM вместе с квантованием. Выбор между внешним API и своим контуром — экономическое решение, и мы считаем его по вашим объёмам, а не по общим соображениям.