Зачем это нужно
У LLM другой профиль эксплуатации: дорогие GPU, потоковая генерация, недетерминированные ответы и данные, которые могут попасть в prompt. Поэтому LLMOps дополняет привычный MLOps, а не заменяет его.
Основные идеи
Карта LLMOps состоит из четырёх связанных контуров:
| Контур | Вопрос |
|---|---|
| Serving | как дать модели GPU и API? |
| RAG | откуда взять актуальный контекст? |
| Evaluation | полезен ли ответ для задачи? |
| Guardrails | что нельзя принять, раскрыть или сгенерировать? |
Serving. vLLM оптимизирует GPU-инференс и даёт OpenAI-compatible API. Для LLM важны TTFT, tokens/s и лимиты на длину контекста, а не только request latency.
RAG добавляет найденные документы в prompt. Он не «дообучает знания» модели и требует качества как retrieval, так и final answer.
Evaluation. Нужен фиксированный набор задач, ожидаемых свойств и human review для рискованных сценариев. MLflow может логировать GenAI-оценки и traces.
Guardrails включают аутентификацию, rate limiting, фильтрацию входа/выхода, политику PII и ограничение инструментов агента.
Как это выглядит на практике
Сервис помощника оператора: gateway проверяет пользователя → RAG ищет только документы его роли → vLLM генерирует ответ → проверка удаляет запрещённый PII → trace связывает запрос, retrieved chunks, токены и оценку.
Если качество падает, команда сначала смотрит: найден ли правильный документ, вошёл ли он в context window, не изменилась ли модель и не сработал ли guardrail. «LLM галлюцинирует» — не достаточно точный диагноз.
Что сделать после занятия
Нарисуйте карту из serving, RAG, eval и guardrails для одного GenAI-сценария.
Определите один риск для каждого контура.
Выберите один набор вопросов для повторяемой offline-оценки.