MLOps vs LLMOps: инфраструктура для foundation models

Viacheslav Dubrov

2025-05-06 · Обновлено 2026-07-15 · 7 мин · ИИ-инфраструктура

Автоматический перевод Эта статья была автоматически переведена с оригинальной английской версии.

Если при релизе foundation model происходит регрессия, файл с весами может оставаться неизменным: измениться могли промпт, retrieval-индекс, разрешения инструментов, маршрут или политика. Поэтому для инженеров ML-, платформенных и AI-приложений, уже эксплуатирующих обычный MLOps, практический артефакт — это манифест релиза, в котором перечислены такие зависимости и указано, какой контроль нужно проверить первым при сбое.

Это редакционная операционная модель, а не утверждение, что каждому приложению нужна одна и та же платформа. Сохраняйте lineage MLOps, поэтапную поставку, мониторинг и откат; расширьте версионируемую единицу, если сгенерированные ответы или действия инструментов начинают зависеть не только от весов.

TL;DR. Сохраняйте lineage MLOps, автоматизацию, поэтапную поставку, мониторинг и откат. Расширьте манифест релиза, включив в него провайдера или веса, промпты, схемы, состояние retrieval, инструменты, роутинг и политику. Пропускайте этот манифест через многоуровневую эвалуацию, а затем используйте трейсы с учётом требований приватности, чтобы превращать продакшен-сбои в новые тесты.

Что MLOps уже решил

MLOps сформировал контроли, которые не устаревают, когда модель начинает генерировать текст:

• lineage от данных, кода, конфигурации и модели до релиза
• воспроизводимые пайплайны обучения или сборки
• офлайн-валидация перед продвижением
• реестры и неизменяемая идентичность артефактов
• поэтапный rollout, SLO, откат и реагирование на инциденты
• телеметрия инфраструктуры и планирование ёмкости
• контроль доступа, политики хранения и аудита данных

Foundation models не устраняют эти потребности. Они лишь делают прежнее выражение «версия модели» слишком узким.

Единицей релиза стал системный манифест

Для системы на базе foundation model я рекомендую манифест, в котором как минимум фиксируются:

application code revision
model provider + model/revision + serving configuration
system and task prompts
response schema + decoding parameters
retrieval corpus snapshot + parser + chunker + embedding model + index
tool definitions + implementation revisions + permission policy
routing, fallback, caching, and budget policy
safety and business-rule revisions
evaluation dataset + scorer revisions

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

Считайте имя модели провайдера изменяемым, если провайдер не документирует неизменяемую ревизию. Хэш чекпоинта помогает идентифицировать self-hosted веса, но я всё равно рекомендую фиксировать рантайм, квантизацию, шаблон и конфигурацию параллелизма.

Пять расширенных поверхностей отказа

Разница между MLOps и LLMOps лучше всего проявляется в анализе отказов, а не в списках инструментов.

1. Модель и сервинг

При планировании разделяйте вопросы hosted-моделей — доступность провайдера, квоты, региональную обработку и стоимость использования — и вопросы self-hosted-моделей — поставку весов, ёмкость GPU, batching, политику кэша, квантизацию и сервинг. Набор релевантных контролей зависит от выбранного варианта деплоя.

В обоих режимах учитывайте при принятии решения о релизе латентность, ошибки, throughput, насыщение ресурсов, стоимость и проверки качества выполнения задач.

2. Промпт, схема и оркестрация

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

Считайте парсящийся JSON проверкой транспорта, а бизнес-инварианты задачи тестируйте отдельно.

3. Retrieval и контекст

Retrieval добавляет независимый датапродукт между источником истины и моделью:

Для retrieval-augmented системы сохраняйте ревизию источника, версии парсера и чанкерa, идентичность эмбеддинга, сборку индекса, метаданные контроля доступа и состояние удаления. В исходной архитектуре RAG retrieval отделён от генерации; используйте это разделение, чтобы независимо тестировать поиск доказательств, фильтрацию по правам доступа и использование доказательств. В статье Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks описана архитектура retrieve-then-generate.

Не используйте векторный индекс вместо feature store или хранилища данных: similarity retrieval, признаки на конкретный момент времени и аналитические факты имеют разные требования к запросам и согласованности.

4. Инструменты и действия

Если модель может вызывать APIs, включите в операционный периметр аутентификацию инструментов, принцип минимальных привилегий, валидацию аргументов, таймауты, идемпотентность, политику подтверждений и проверки постусловий. В Generative AI Profile от NIST указаны риски, связанные с вредоносным контентом, приватностью и безопасностью; перечисленные контроли — это сфокусированная инженерная рекомендация, а не полный каталог контролей.

Трейсьте, какой инструмент был предложен, выбран, вызван, отклонён, повторно вызван и зафиксировал изменения. Грамотный финальный ответ не доказывает, что путь выполнения действия был корректным.

5. Безопасность, защищённость и политика

Фильтры контента — лишь один контроль, а не полноценный слой гардрейлов. К угрозам также относятся промпт-инъекция, retrieval между тенантами, раскрытие секретов, чрезмерная агентность, ненадёжный код модели или узла и небезопасные аргументы инструментов.

По возможности выносите детерминированные бизнес-правила за пределы модели. Определяйте остаточные риски, тестируйте adversarial-сценарии и назначайте владельца изменений политики. Generative AI Profile от NIST — полезный перечень рисков, но не готовый acceptance-тест.

Эвалуация становится гейтом релиза

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

Соберите стек эвалуации из нескольких типов свидетельств:

1. Детерминированные проверки: валидность схемы, наличие цитат, разрешённые инструменты, ограничения аргументов, правила политики, латентность и бюджет.
2. Метрики компонентов: recall retrieval и качество ранжирования, точность выбора инструмента, корректность аргументов инструмента и выбор маршрута.
3. End-to-end задачи: репрезентативные входы с явными критериями успеха и метками срезов.
4. Оценка на основе модели: суждения по рубрике, откалиброванные относительно экспертных меток и отслеживаемые на предмет дрейфа джаджа.
5. Проверка людьми: неоднозначные, значимые, новые или отобранные случаи, где автоматизация не является авторитетным источником.
6. Adversarial-тесты: инъекции, нарушения границ данных, злоупотребления, отказы и сценарии с побочными эффектами, связанные с моделью угроз.

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

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

Трейсы связывают продакшен с эвалуацией

Метрики инфраструктуры могут показать медленный вызов модели. Но они не покажут, что retrieval вернул документ, к которому не было доступа, или что инструмент был вызван с неправильным аккаунтом. В документации MLflow’s tracing documentation описаны трейсы, которые фиксируют промежуточные шаги и метаданные, необходимые для анализа этого пути.

Фиксируйте трейс по всему пути принятия решения:

• идентичность манифеста релиза и корреляция запроса
• вызовы модели и провайдера, латентность, использование ресурсов и состояние завершения
• retrieval-запрос, идентификаторы документов, оценки и решения о фильтрации
• ревизию промпта/шаблона без бездумного сохранения чувствительного содержимого
• предложения инструментов, аргументы, подтверждения, результаты и идентификаторы побочных эффектов
• решения политики, ретраи, fallback-сценарии и финальный результат

Трейсинг создаёт новую поверхность для управления данными. Прежде чем собирать полные промпты или документы, примените минимизацию, редактирование, изоляцию тенантов, шифрование, сэмплирование, политики хранения и ревью доступа. OpenTelemetry’s GenAI semantic conventions могут помочь с интероперабельностью, но пока находятся в разработке. Фиксируйте версии соглашений или схем, инструментирования и коллектора.

Цикл улучшения выглядит так:

production trace → triaged failure → labeled regression case
                 → candidate change → offline comparison
                 → staged release → monitored outcome

Обратная связь пользователей может помочь расставить приоритеты для расследования, но лайк не является ground truth. Сохраняйте окружающий трейс и получайте экспертные метки для значимых случаев.

Шлюз сервинга — граница политики

Шлюз может отделить клиентов приложения от провайдеров или self-hosted-движков. В него стоит вынести следующие обязанности:

• аутентификацию, бюджеты тенантов, квоты и rate limits
• стабильные контракты запросов и ответов
• выбор маршрута по возможностям, региону, латентности или измеренному качеству
• ограниченные ретраи, circuit breaker и явно определённую семантику fallback
• разделение кэша и политику работы с чувствительными данными
• атрибуцию использования и передачу идентичности манифеста релиза

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

Не помещайте все решения по оркестрации в шлюз. Держите доменные правила рядом с приложением и делайте зоны ответственности видимыми.

Файн-тюнинг — лишь один из вариантов вмешательства, а не ступень зрелости

Выбирайте вмешательство на основе наблюдаемого отказа:

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

Практическая последовательность внедрения

1. Определите пользовательскую задачу, границы потенциального вреда, сервисные цели и допустимый бюджет.
2. Создайте манифест релиза до внедрения registry промптов, векторной базы данных или продукта-шлюза.
3. Соберите небольшой набор для эвалуации с разбивкой на срезы и детерминированные тесты компонентов.
4. Инструментируйте один end-to-end трейс с контролями приватности и стабильными идентификаторами релизов.
5. Продвигайте релиз через shadow, canary или ограниченный трафик с явно определённым триггером отката.
6. Превращайте проверенные продакшен-сбои в регрессионные кейсы и повторяйте цикл.

Добавляйте инфраструктуру только тогда, когда она отвечает за конкретный именованный контроль или устраняет измеренный боттлнек. «Платформа LLMOps» не является архитектурным требованием.

Заключение

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

Версионируйте всю эту единицу, оценивайте её до релиза, трейсите с границами приватности и откатывайте как единую систему.

Ссылки

• MLflow: evaluating production traces — использование продакшен-трейсов для эвалуации и оценка промежуточной информации трейса.
• MLflow: LLM and agent tracing — фиксация промежуточных шагов и метаданных трейса для расследований.
• OpenTelemetry GenAI semantic conventions — соглашения в текущем статусе разработки для GenAI-спанов, метрик, событий и данных, специфичных для провайдера.
• NIST AI 600-1: Generative AI Profile — категории рисков, связанных с промпт-инъекциями, приватностью, безопасностью и другими аспектами генеративного AI.
• Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks — исходная архитектура retrieve-then-generate.
• LoRA: Low-Rank Adaptation of Large Language Models — замороженные претрейнинговые веса и обучаемые низкоранговые матрицы для downstream-адаптации.