DevOps, MLOps и LLMOps: как генеративный ИИ вышел в продакшен

На привычной схеме три конвейера выглядят как сменяющие друг друга поколения. Для первого знакомства это удобно, но теряется главное: DevOps, MLOps и LLMOps — не конкурирующие продукты и не замены друг другу. Это способы эксплуатации артефактов, которые всё сложнее определить и проверить. В программной инженерии появилась автоматизация доставки; машинное обучение добавило данные и статистическое поведение; фундаментальные модели — контекст на естественном языке, внешних поставщиков, инструменты и семантический риск.

Ниже — документированная история этого перехода и, прежде всего, разбор того, что на самом деле эксплуатирует команда LLMOps. У MLOps и LLMOps нет общепризнанной даты рождения, поэтому хронология опирается на проверяемые вехи, а не назначает единственного «изобретателя».

Три названия — три артефакта

Это не жёсткие границы команд. LLM-продукту по-прежнему нужны CI/CD, секреты, сети, откаты и SLO. Если организация владеет весами, нужны также происхождение данных и реестр моделей. LLMOps расширяет DevOps и MLOps, а не отменяет их.

2009: DevOps и проблема передачи через стену

На Velocity 2009 Джон Оллспоу и Пол Хэммонд представили доклад 10+ Deploys per Day: Dev and Ops Cooperation at Flickr.^[flickr] Тезис был прямо в названии: частые релизы рождаются не из героической передачи пакета через организационную стену, а из сотрудничества и автоматизации. В том же году в Генте прошёл первый DevOpsDays.^[devopsdays]

Документированная история: десять деплоев в день звучали вызывающе, когда многие выпускали релизы раз в квартал. Урок не в числе десять. Малые изменения сокращали обратную связь и делали разработку и эксплуатацию совместной ответственностью. Позднее DORA формализовала метрики доставки и показала, что скорость и стабильность не обязательно противоречат друг другу.^[dora]

2015–2017: когда артефакт начал учиться

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

Отсюда потребность, которую сегодня называют MLOps: воспроизводить датасеты и признаки, проверять схемы, регистрировать эксперименты и модели, предотвращать расхождение обучения и serving, отслеживать drift и решать, когда переобучать. ML Test Score 2017 года предложил 28 тестов и требований к мониторингу готовности к продакшену.^[mltest]

История с измеримым результатом: статья о TFX описывает, как Google заменил хрупкие glue-скрипты стандартными компонентами. В одном развёртывании для Google Play модели обновлялись по мере поступления данных; авторы сообщили о более быстрых экспериментах, сокращении выхода в продакшен с месяцев до недель и росте установок на 2 %, связанном с улучшенным анализом данных и моделей.^[tfx] Это результат конкретного кейса, не универсальное обещание.

MLOps добавил к CI/CD непрерывную доставку ML-конвейера и непрерывное обучение. Руководство Google Cloud различает ручной процесс, автоматизированный ML-конвейер и полную автоматизацию CI/CD.^[mlops]

2020–2022: от отдельной модели к фундаментальной системе

Три изменения подготовили LLMOps. RAG в 2020 году объединил параметрическую память с внешним индексом, дав обновляемые знания и происхождение ответа.^[rag] Отчёт Stanford 2021 года закрепил понятие foundation model: широко обученная основа для многих задач даёт рычаг, но заставляет множество продуктов наследовать общие дефекты.^[foundation]

В 2022 году InstructGPT показал, что обучение по человеческой обратной связи заметно меняет полезность: на распределении промптов авторов люди предпочли модель 1,3 млрд параметров GPT‑3 на 175 млрд, хотя меньшая модель всё ещё допускала простые ошибки.^[instruct] HELM в том же году предложил прозрачную многомерную оценку вместо одной цифры бенчмарка.^[helm]

В этой среде распространился термин LLMOps. Это не «MLOps плюс промпт» и не обязательное обучение фундаментальной модели. Многие приложения не обучают веса вообще: они эксплуатируют API, промпты, поиск, инструменты и правила. Единица изменения — составная LLM-система.

Что LLMOps эксплуатирует на самом деле

1. Версионируемый комплект, а не отдельный промпт

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

Продвигается неизменяемый комплект: app@sha + prompt@sha + index@snapshot + eval@version + policy@version + model@id. Если комбинацию нельзя восстановить, нельзя объяснить инцидент или надёжно откатиться.

2. Сначала оценка, потом оптимизация

В обычном тесте есть ожидаемый результат. У языка несколько корректных форм — и красноречивые ложные ответы. Поэтому LLMOps начинается с eval-датасета из реальных задач, краевых случаев и предсказуемых атак. Каждому примеру нужна рубрика, а не только «золотая» строка.

• Качество задачи: точность, полнота, формат и следование инструкции.
• RAG: recall поиска, релевантность контекста, верность ответа источнику и качество цитат; поиск и генерацию следует оценивать отдельно.
• Безопасность: прямая и косвенная инъекция, утечка данных, злоупотребление инструментами и запрещённый контент.
• Эксплуатация: end-to-end задержка, токены, стоимость, повторы, ошибки и квоты.

LLM-судьи масштабируют проверку, но сами являются моделями: их калибруют по человеческим оценкам, версионируют и сохраняют расхождения. Надёжный release gate сочетает детерминированные проверки, судей, adversarial-тесты и человеческую выборку.

3. RAG как онлайн-конвейер данных

RAG — не «подключить векторную базу». Это цепочка: авторизация документов → извлечение → очистка → chunking → embeddings → индексация → поиск → reranking → сборка контекста → генерация → ссылки. Деградировать может каждое звено.

Нужно версионировать корпус и индекс, измерять свежесть, соблюдать ACL, хранить chunk ID в трассах и тестировать вопросами с известным источником. Поиск улучшает привязку к фактам, но не делает вывод истинным автоматически и не устраняет prompt injection; OWASP прямо предупреждает об этом.^[owasp]

4. Семантическая наблюдаемость и FinOps

HTTP 200 не означает полезный ответ. Трасса должна связывать ввод, политику, retrieval, reranking, вызовы модели, инструменты, повторы и финальный результат. OpenTelemetry уже определяет соглашения для модели, токенов, сообщений и tool calls; запись содержимого должна быть опциональной из-за чувствительных данных.^[otel]

Полезные панели объединяют качество и эксплуатацию: успех задачи и groundedness по версиям, p50/p95/p99 задержки, входные/выходные токены, стоимость завершённой задачи, cache hit rate, глубину агента, сбои инструментов и передачу человеку. Дешёвый токен становится дорогим, если агент зацикливается.

SLO формулируют от пользовательского опыта — доступность, задержка и корректность.^[sre] Например: «95 % авторизованных вопросов о политике получают ответ менее чем за шесть секунд, с действительной ссылкой и без межтенантной утечки».

5. Безопасность, управление и пределы автономности

Модель получает данные и инструкции по одному каналу. Эта неоднозначность превращает prompt injection в архитектурную проблему, а не в финальный фильтр. OWASP ведёт каталог рисков LLM; профиль NIST структурирует управление, измерение и снижение рисков генеративного ИИ.^{[nist][owasp]}

• Считать найденный текст, веб-страницы и результаты инструментов недоверенным вводом.
• Применять минимальные права для каждого инструмента; разделять чтение, предложение и выполнение.
• Проверять вывод перед SQL, shell, почтой, платежами или изменением инфраструктуры.
• Требовать одобрения человека для необратимых и значимых действий.
• Определить хранение, маскирование PII, резидентность и доступ к промптам и трассам.
• Иметь kill switch, лимиты шагов и бюджета, таймауты и откат.

Производственный LLMOps-конвейер

1. Определить задачу и риск: решение, полномочия, ответственность и недопустимые исходы.
2. Создать eval-набор: обычные и краевые случаи, языки, релевантные группы и атаки.
3. Выбирать по ограничениям: качество задачи, задержка, приватность, регион, контекст, инструменты и цена.
4. Построить контекст: RAG только для знаний или проверяемости; сохранять ACL, происхождение и свежесть.
5. Инструментировать до запуска: версии, correlation ID, spans, токены, стоимость и результаты оценок.
6. Прогнать offline gates: регрессии, безопасность, нагрузка и бюджет.
7. Развернуть shadow или canary: сравнить реальный трафик без полной автономности кандидата.
8. Сэмплировать продакшен: автоматические сигналы, контекстная обратная связь и приватный human review.
9. Продвигать или откатывать комплект целиком: модель, промпт, индекс, инструменты и политики вместе.

Три истории, ставшие эксплуатационными правилами

Flickr, 2009: запомнились «десять деплоев в день», но долговечной половиной заголовка было сотрудничество Dev и Ops. Частота была видимым результатом короткой обратной связи и общей ответственности.^[flickr]

TFX, 2017: проблему продакшена решили не лучшим алгоритмом, а заменой ad-hoc glue на повторяемую платформу. Это переход от «у нас есть модель» к «мы умеем эксплуатировать модели».^[tfx]

Tay, 2016: Tay появился до современных LLM, поэтому это не инцидент LLM. Но это важное эксплуатационное предупреждение. Microsoft сообщила, что в первые 24 часа скоординированная атака использовала непредвиденную уязвимость, после чего бот был отключён.^[tay] Лабораторные тесты, red teaming, живое наблюдение и путь отключения — части продукта.

Частые ошибки LLMOps

• Называть каталог промптов платформой: без оценки, lineage, прав, трасс и отката это просто хранилище.
• Измерять лишь галлюцинации: полезность, отказ, формат, безопасность, задержка и цена не менее важны.
• Логировать все промпты без политики: observability может стать теневой копией чувствительных данных.
• Менять модель прямо в продакшене: даже «лучшая» меняет стиль, tool calling, длину и цену.
• Выдавать инструментам права сервисного аккаунта: агенту нужен scope пользователя или минимальной функции.

Настоящая эволюция — расширение ответственности

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

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

Источники и дополнительное чтение

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

1. John Allspaw & Paul Hammond — 10+ Deploys per Day: Dev and Ops Cooperation at Flickr
2. DevOpsDays — Ghent 2009, official event archive
3. DORA / Google Cloud — 2019 Accelerate State of DevOps Report
4. Sculley et al. — Hidden Technical Debt in Machine Learning Systems
5. Breck et al. — The ML Test Score
6. Baylor et al. — TFX: A TensorFlow-Based Production-Scale ML Platform
7. Google Cloud Architecture Center — MLOps: Continuous delivery and automation pipelines
8. Lewis et al. — Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks
9. Bommasani et al. — On the Opportunities and Risks of Foundation Models
10. Ouyang et al. — Training language models to follow instructions with human feedback
11. Liang et al. — Holistic Evaluation of Language Models (HELM)
12. Microsoft — Learning from Tay’s introduction
13. NIST AI 600-1 — Generative AI Profile
14. OWASP GenAI Security Project — Top 10 for LLM Applications
15. OpenTelemetry — Inside the LLM Call: GenAI Observability
16. Google SRE Book — Service Level Objectives