2025-05-06 · Обновлено 2026-07-15

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

MLOps против LLMOps: инфраструктура для систем фундаментальных Модели и LLM моделей

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

Дисциплина MLOps по-прежнему актуальна. Изменилась лишь операционная единица: поведение приложения на основе языка-модель может зависеть от промпты, процесса декодирования, retrieval, спецификаций инструментов, прав доступа, роутинг и правил, а также от веса модели. В этой статье объясняется, что осталось полезным, и какие новые функции добавили системы LLM.

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

Что уже решено с помощью MLOps

MLOps предусматривает устоявшиеся механизмы контроля, которые не устаревают даже при генерации текста с помощью модель:

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

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

Единица релиза преобразовалась в манифест системы

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

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

Конкретный список зависит от системы. Однако неизменным остаётся требование, согласно которому в манифесте должен быть указан каждый компонент, способный к независимым изменениям и влияющий на поведение интерфейса, видимое для пользователя.

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

Расширенный список пяти поверхностей сбоев

Различие между MLOps и LLMOps становится более очевидным при анализе сбоев, чем при перечислении инструментов.

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

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

Оба решения требуют использования латентность (ошибок), throughput (насыщения) и механизмов контроля затрат. При этом ни один из режимов деплой не позволяет отказаться от оценки качества.

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

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

Создайте версии собранного запроса и политики оркестрация. Проверяйте structured outputs с помощью парсеров и бизнес-инвариантов, вместо того чтобы считать задачу выполненной при наличии «допустимого JSON».

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

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

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

Векторный индекс не заменяет хранилище признаков или базу данных. Он предназначен для поиска сходства retrieval; структурированные признаки в конкретные моменты времени и аналитические факты требуют различных уровней согласованности и специфических условий выполнения запросов.

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

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

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

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

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

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

Оценка превращается в брандмауэр выпуска

В режиме свободного формата одного общего показателя точности недостаточно для полной оценки качества. Однако это не означает, что его невозможно измерить.

Создайте стек оценки с несколькими типами доказательств:

1. Детерминистические проверки: корректность схемы, наличие цитат, допустимые инструменты, ограничения аргументов, правила политики, латентность и бюджет.
2. Метрики компонентов: точность воспроизведения retrieval и ранжирования, точность выбора инструмента, корректность аргументов инструмента и выбор маршрута.
3. Задачи «от начала до конца»: репрезентативные входные данные с чёткими критериями успеха и метками сегментов.
4. Оценка на основе Модель: суждения, основанные на рубрике, калиброванные с учётом меток экспертов, с контролем за возникновением смещения джадж.
5. Проверка человеком: неоднозначные, критично важные, новые или выбранные случаи, в которых автоматизация не может служить авторитетным источником.
6. Атакующие тесты: тесты на вставку данных, нарушение границ данных, злоупотребления, отказы в обработке и побочные эффекты, связанные с угрозой модель.

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

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

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

Метрики инфраструктуры могут указывать на медленный вызов модель. Однако они не способны показать, что retrieval вернул недопустимый документ, или что инструмент был вызван с неверным учётным записью.

Зафиксируйте трейс на протяжении всего пути принятия решений:

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

Трейсинг формирует новую среду управления данными. Перед сбором полных промпты или документов необходимо применить методы минимизации объёма данных, удаления конфиденциальной информации, изоляции тенантов, шифрования, выборочной обработки, определения сроков хранения и проверки прав доступа. Генеративные AI конвенции OpenTelemetry могут способствовать взаимодействию различных систем, однако их схемы постоянно развиваются; поэтому рекомендуется фиксировать версии инструментов для мониторинга и сбора данных.

Цикл улучшения выглядит следующим образом:

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

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

Шлюз сервинг представляет собой границу политики

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

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

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

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

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

Выберите меру вмешательства на основе зафиксированной неисправности:

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

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

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

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

Заключение

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

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

Список литературы

• MLflow: оценка работы в продакшене трейсы
• MLflow: LLM и агент трейсинг
• OpenTelemetry генеративный реестр AI семантических конвенций
• NIST AI 600-1: Профиль генеративных AI моделей