CI/CD для LLM-приложений: версионирование, тестирование и деплой агентов

Что версионировать в LLM-приложении

В LLM-приложении версионируются три независимых компонента:

1. Код: логика агента, инструменты, интеграции — стандартный git
2. Промпты: системный промпт, few-shot примеры, prompt templates. Промпты должны быть в git наряду с кодом, а не в базе данных без версионирования. Используйте семантическое версионирование для промптов: major — изменения поведения агента, minor — улучшения качества, patch — исправления ошибок.
3. Модель: версия/snapshot модели провайдера. Используйте зафиксированные версии моделей (claude-3-5-sonnet-20241022 вместо claude-3-5-sonnet-latest) — это предотвращает неожиданные изменения поведения при обновлении модели провайдером.

Связывайте эти три компонента через config file:

# agent_config.yaml
model:
  provider: anthropic
  name: claude-3-5-sonnet-20241022
  temperature: 0
prompt:
  system_prompt_version: "2.4.1"
  few_shot_version: "1.2.0"
tools:

• name: search_kb

    version: "3.1.0"

Тестирование LLM-приложений

Тестирование агентов разбивается на уровни:

Unit тесты (детерминированные):

• Тесты инструментов с моковыми данными
• Тесты парсинга и валидации входных/выходных данных
• Тесты логики оркестрации

Integration тесты (с LLM, но детерминированные при temperature=0):

• Агент правильно вызывает инструменты для стандартных задач
• Агент корректно обрабатывает ошибки инструментов
• Агент завершает задачу за разумное число шагов

Evaluation тесты (с LLM-as-judge):

• Качество финального ответа по критериям: точность, полнота, релевантность
• Соблюдение ограничений (агент не выполняет запрещённые действия)
• Безопасность (resistance к prompt injection)

Golden set regression: набор из 50–200 задач с эталонными ответами. Запускается при каждом изменении промпта или модели, блокирует деплой при деградации > порога.

Структура CI/CD пайплайна

Рекомендуемая структура пайплайна:

Stage 1 — Static analysis (2 мин):

• Линтинг кода (flake8, mypy)
• Валидация синтаксиса промптов
• Проверка конфигурации модели

Stage 2 — Unit & Integration tests (10 мин):

• Инструменты с мокированием внешних сервисов
• Интеграционные тесты с real LLM (кешированные ответы для скорости)
• Security checks (OWASP для API endpoints)

Stage 3 — Evaluation (30–60 мин):

• Golden set regression на staging-окружении
• Сравнение метрик с baseline (task completion rate, steps per task)
• Cost projection: расчёт ожидаемой стоимости токенов в продакшне

Stage 4 — Staged rollout:

• Canary: 5% трафика → мониторинг 1 час
• Progressive: 25% → 50% → 100% при отсутствии деградации
• Автоматический rollback при: error rate > 5% на canary, деградации task completion rate > 10%, cost spike > 3x от baseline.

Управление промпт-инжинирингом как кодом

Промпты в git — необходимость, но недостаточность. Для эффективного управления промптами нужны:

• Prompt registry: централизованное хранилище с версионированием, возможностью A/B-тестирования и rollback. Langfuse, PromptLayer или собственное решение на основе git + database.
• Prompt testing DSL: декларативное описание тестов для промптов:

prompt_tests:

• name: "Агент не галлюцинирует при отсутствии данных"

    input: "Сколько продуктов было продано 31 февраля 2024?"
    expected_behavior: contains_phrase("данные недоступны") OR contains_phrase("такой даты не существует")
    judge_criteria: "Агент не придумал данные и сообщил о невозможности ответить"

• Change diff: при изменении промпта автоматически показывайте diff и запускайте тест на наборе сценариев, специфичных для изменённой части.

Feature flags для агентов

Feature flags позволяют гибко управлять поведением агента без деплоя кода:

• Включение/отключение отдельных инструментов для подмножества пользователей
• A/B-тестирование разных версий промптов на реальном трафике
• Emergency kill switch: мгновенное отключение агента или его компонентов при инциденте
• Graceful degradation: при недоступности внешнего сервиса автоматическое переключение на fallback режим

Инструменты: LaunchDarkly, Unleash (self-hosted), или простой JSON в Redis. Для агентов особенно ценна возможность изменять поведение на уровне конкретной сессии или пользователя.

Заключение

CI/CD для ИИ агентов требует расширения традиционных практик: версионирования промптов и моделей, автоматизированной оценки качества и поэтапного деплоя. Ключевой принцип: любое изменение, влияющее на поведение агента, должно проходить полный цикл тестирования, включая regression на golden set. Инвестиции в CI/CD инфраструктуру окупаются предотвращением деградации качества и ускорением итерационного цикла.