ТЕХНИЧЕСКОЕ ЗАДАНИЕ: Настроить canary deployment промптов

1. Цель задачи

Научиться безопасно развёртывать новые версии системных промптов в production с минимальным риском для пользователей. Реализовать canary-стратегию, при которой 5% трафика получает новый промпт, а остальные 95% — текущую стабильную версию. Встроить автоматический откат (auto-rollback) при обнаружении деградации ключевых метрик качества ответов.

Ключевой результат Рабочий пайплайн canary-деплоя промптов с автоматическим мониторингом и откатом при ухудшении метрик (например, падение accuracy > 5%).

2. Исходные данные

Перед началом необходимо иметь:

Если нет реального инструмента — симулируем:

1. Развернуть простой веб‑сервер (FastAPI) с mock‑LLM, который возвращает ответ в зависимости от версии промпта (v1 / v2).
2. Написать скрипт эмуляции запросов (Locust или Python с asyncio) для генерации трафика.
3. Реализовать «качество ответа» как синтетическую метрику (например, длина ответа, наличие ключевых слов, или случайный score).
4. Prometheus + Grafana поднять через docker‑compose (готовые образы).
5. Auto‑rollback симулировать путём проверки метрики каждые N запросов и смены версии промпта через переменную окружения.

3. Технологический стек

4. Этапы выполнения

Этап 1: Подготовка окружения и версионирование промптов (1.5–2 часа)

Действия

1. Создать Git-репозиторий и папку prompts/ с двумя версиями: prompt_v1.yaml (текущая стабильная) и prompt_v2.yaml (canary). В каждой — обязательные поля: version, system_prompt, parameters (temperature, max_tokens).

   # prompt_v1.yaml
   version: 1
   system_prompt: "Ты — полезный помощник. Отвечай кратко и по делу."
   parameters:
     temperature: 0.3
     max_tokens: 512
   

2. Развернуть FastAPI приложение, которое загружает выбранную версию промпта и генерирует ответ через mock‑LLM или реальное API.

   • Эндпоинт POST /generate — принимает {"user_query": "..."}, возвращает {"response": "...", "prompt_version": 1|2}.
   • Загрузка промпта при старте из переменной окружения ACTIVE_PROMPT_VERSION или через отдельный REST.

3. Добавить Prometheus метрики через клиент prometheus_client:

   • prompt_version_gauge — метка с номером версии
   • response_latency_seconds — гистограмма
   • response_quality_score — гистограмма или summary
   • forwarded_to_canary — счётчик

4. Написать Dockerfile и docker-compose.yml, включающий сервис приложения, Prometheus, Grafana (с преднастроенным дашбордом).

Ожидаемый результат этапа Приложение стартует, отдаёт ответы в зависимости от ACTIVE_PROMPT_VERSION, метрики видны в Prometheus.

Этап 2: Реализация canary-роутинга (2–3 часа)

Действия

1. Выбрать способ роутинга (рекомендуется программный на Python, чтобы не зависеть от инфраструктуры).
   Добавить middleware в FastAPI:

   import random
   CANARY_PERCENT = 5  # %
   
   @app.middleware("http")
   async def canary_router(request, call_next):
       if random.randint(1, 100) <= CANARY_PERCENT:
           request.state.prompt_version = 2
       else:
           request.state.prompt_version = 1
       response = await call_next(request)
       return response
   

2. Логировать, какой клиент получил какую версию (через заголовок X-Prompt-Version в ответе).

3. Проверить, что с 1000 запросов примерно 50 получают version=2 (можно написать юнит‑тест на симуляции).

4. Добавить управление процентом через эндпоинт POST /admin/canary-percent (защитить API‑ключом).

Ожидаемый результат этапа 5% запросов обрабатываются новым промптом, остальные 95% — старым; процент настраивается динамически.

Этап 3: Интеграция метрик качества и порогов (2–3 часа)

Действия

1. Реализовать функцию оценки качества evaluate_response(user_query, response, version).
   Варианты (выберите один):

   • LLM-as-judge: отправить запрос GPT‑4mini с инструкцией «Оцени ответ от 1 до 5 по шкале полезности» и вернуть score.
   • RAGAS (если есть RAG): метрики faithfulness, answer_relevance.
   • Самописная: длина ответа / наличие ключевых слов / совпадение с эталонным ответом (если есть).

2. Обновить middleware (или отдельный background‑воркер): после каждого ответа асинхронно отправлять запрос на оценку и записывать score в метрику response_quality_score с метками version.

3. Настроить Prometheus alerting rule в prometheus.yml:

   groups:
     - name: canary_alerts
       rules:
         - alert: CanaryDegradation
           expr: |
             avg(rate(response_quality_score{version="2"}[5m]))
             <
             0.95 * avg(rate(response_quality_score{version="1"}[5m]))
           for: 2m
           labels:
             severity: critical
           annotations:
             summary: "Canary prompt v2 degraded"
   

4. Проверить срабатывание алерта – симулировать плохой промпт v2, убедиться, что alert переходит в firing.

Ожидаемый результат этапа Алерт в Prometheus срабатывает при деградации качества canary версии на ≥5%.

Этап 4: Автоматический rollback (2–3 часа)

Действия

1. Написать Python‑скрипт auto_rollback.py, который:

   • Подключается к Prometheus API (http://localhost:9090/api/v1/alerts)
   • При появлении алерта CanaryDegradation в статусе firing:
     • Устанавливает переменную окружения ACTIVE_PROMPT_VERSION=1 в контейнере (через Docker API или перезагрузку конфига)
     • Отправляет уведомление в Slack/Telegram
   • Запускается как sidecar-контейнер в docker‑compose.

2. Интегрировать с CI/CD (например, GitHub Actions): при пуше новой версии промпта prompt_v3.yaml в ветку canary:

   • Job deploy-canary обновляет конфиг и рестартует приложение с ACTIVE_PROMPT_VERSION=3.
   • Job monitor-rollback запускает auto_rollback.py (или ожидает алерт в течение 10 минут).
   • В случае rollback – создаётся Issue в GitHub с логами.

3. Протестировать весь сценарий:

   • Задеплоить заведомо плохую версию промпта (например, «Отвечай не по теме»).
   • Убедиться, что через ~3 минуты происходит автоматический откат на стабильную версию.

Ожидаемый результат этапа При деградации canary (score < 95% от baseline) система возвращается к v1, уведомление отправлено.

Этап 5: Написание документации и воспроизводимость (1 час)

Действия

1. Оформить README в репозитории с инструкцией по запуску (docker‑compose up), описанием структуры промптов, настройкой A/B тестирования.
2. Создать дашборд в Grafana (экспортировать JSON): графики latency, quality score по версиям, счётчики canary‑запросов, статус алертов.
3. Написать скрипт simulate_traffic.py с нагрузочным тестом (Locust или простой asyncio), который генерирует 1000 запросов и выводит статистику.

Ожидаемый результат этапа Полный пакет артефактов для воспроизведения canary deployment промптов на любом окружении.

5. Критерии приемки (Definition of Done)

• 5% трафика идёт на новую версию промпта (проверено через лог или дашборд).
• Метрики качества собираются отдельно для каждой версии (Prometheus метрики с лейблом version).
• При деградации метрик качества на >=5% в течение 2 минут срабатывает alert.
• Auto-rollback переключает версию на стабильную без ручного вмешательства.
• После rollback отправляется уведомление (Slack/Telegram/webhook).
• Дашборд в Grafana показывает сравнительные графики по v1 и v2.
• Все компоненты упакованы в Docker и запускаются одной командой docker-compose up.
• Документация (README) содержит инструкцию по добавлению новой версии промпта и настройке процента canary.

6. Ожидаемый результат

• Файл/артефакт Git-репозиторий с кодом приложения, конфигурацией Prometheus/Grafana, скриптами симуляции и auto-rollback.
• Содержание
  • app/ — FastAPI приложение с canary-роутером и метриками.
  • prompts/ — примеры версий промпта v1, v2, v3 (плохой).
  • monitoring/ — prometheus.yml, дашборд Grafana (JSON).
  • scripts/ — auto_rollback.py, simulate_traffic.py.
  • docker-compose.yml — все сервисы.
  • README.md — документация.
• Опционально CI/CD конфигурация (например, .github/workflows/canary-deploy.yml).

7. Возможные сложности и их решение

8. Бюджет времени (оценка)

Примечание: Время может увеличиться на 30‑50% при первом выполнении из-за отладки интеграции Prometheus и Docker.

9. Связанные вопросы из базы знаний

10. Чек-лист самопроверки

• Я настроил canary‑роутер (5% трафика на v2) и проверил через лог количества запросов по версиям.
• Я добавил Prometheus метрики и алерт на деградацию >5%.
• Я запустил simulate_traffic.py с плохим промптом и убедился, что auto‑rollback сработал.
• Я проверил, что после rollback версия в Prometheus метрике prompt_version_gauge вернулась к 1.
• Я задеплоил дашборд в Grafana и вижу обе линии качества (v1 и v2).
• Я написал README с инструкцией для другого разработчика.