ТЕХНИЧЕСКОЕ ЗАДАНИЕ: Реализовать prompt lifecycle

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

Научиться управлять полным жизненным циклом промпта в production-системе: от черновика до вывода из эксплуатации. Создать repeatable pipeline, который обеспечивает контроль версий, ревью, A/B тестирование, канареечный деплой и graceful deprecation каждого промпта.

Ключевой результат Промпт последовательно проходит все стадии (Draft → Review → Staging → Production → Deprecated) с фиксацией каждого шага в истории Git и метриках качества.

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

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

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

1. Создать локальный Git-репозиторий (git init) с ветками main, staging, production.
2. Использовать Actions (бесплатные минуты) для CI/CD; если нет доступа — написать скрипты на Python, эмулирующие шаги.
3. Вместо настоящего LLM API использовать mock-функцию, которая имитирует ответы по шаблону (для проверки пайплайна).
4. A/B тестирование проводить на синтетических данных: сравнивать метрики (например, долю совпадений с эталоном) на тестовом датасете.

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

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

Этап 1: Создание структуры репозитория и первого промпта (Draft) (1 час)

Действия

1. Инициализировать Git-репозиторий с ветками main, staging, production.
2. Создать директорию prompts/ и внутри — поддиректорию для первого промпта, например prompts/qa-assistant/.
3. Внутри создать файлы:
   • template.yaml — сам промпт с переменными;
   • meta.yaml — версия, автор, дата, статус (draft);
   • tests/test_cases.yaml — тестовые примеры (input → expected_output).
4. Написать Python-скрипт validate_prompt.py, который:
   • проверяет обязательные поля в meta.yaml;
   • загружает template и тесты;
   • прогоняет каждый тест через mock LLM и выводит результаты.
5. Закоммитить в ветку feature/qa-draft.

Пример шаблона template.yaml

system_prompt: |
  Ты — квалифицированный ассистент по {domain}. Отвечай кратко и по делу.
  Если не знаешь — скажи «Не знаю». Не выдумывай факты.
user_prompt: |
  Вопрос пользователя: {question}

Пример meta.yaml

version: 0.1.0
author: "Иван Иванов"
status: draft
created: 2025-03-14
description: "Первый черновик Q&A ассистента"

Ожидаемый результат этапа Закоммиченный черновик промпта в отдельной ветке, скрипт валидации проходит.

Этап 2: Review — настройка code review и линтинг (1 час)

Действия

1. Создать Pull Request из feature/qa-draft в staging.
2. Настроить GitHub Actions workflow .github/workflows/review.yml:
   • триггер: pull_request в staging;
   • шаги: checkout → Python setup → запуск validate_prompt.py → проверка статуса;
   • условие: PR не может быть слит, пока workflow не пройдёт.
3. Добавить линтер для YAML (yamllint) — проверка форматирования.
4. Написать тест на то, что промпт не содержит запрещённых слов (например, «всегда», «никогда» без оговорок).
5. Назначить код-ревьюер (в реальной команде) или эмулировать: создать второй аккаунт GitHub и оставить комментарий.

Ожидаемый результат этапа PR прошёл review, изменения слиты в staging.

Этап 3: Staging — деплой на staging и A/B тестирование (2 часа)

Действия

1. Настроить второй workflow staging-deploy.yml:
   • триггер: push в staging;
   • шаги: checkout → копирование промпта в /staging/prompts/ → запуск A/B теста.
2. Написать скрипт ab_test.py, который:
   • берёт текущую production-версию промпта (ветка production) и staging-версию;
   • прогоняет обе на тестовом датасете (из tests/test_cases.yaml);
   • вычисляет метрики (например, точность, ROUGE-1);
   • выводит, какая версия лучше.
3. Добавить порог acceptance: если staging-версия не хуже production на >5% по ключевой метрике — считать успехом.
4. Результаты A/B теста сохранить в prompts/qa-assistant/ab_results.json.
5. Если A/B тест пройден — создать PR из staging в production с приложенными результатами.

Пример ab_test.py

import yaml, json, sys
from mock_llm import mock_response

def load_prompt(branch):
    with open(f'prompts/qa-assistant/template.yaml') as f:
        return yaml.safe_load(f)

def evaluate(prompt_version, tests):
    correct = 0
    for test in tests:
        output = mock_response(prompt_version, test['input'])
        if output.strip() == test['expected'].strip():
            correct += 1
    return correct / len(tests)

# ... (загрузка, сравнение, запись)

Ожидаемый результат этапа Staging-версия протестирована, подготовлен PR в production.

Этап 4: Production — promotion в production с canary (1.5 часа)

Действия

1. Настроить production-deploy.yml:
   • триггер: push в production;
   • можно добавить ручной approval перед деплоем (GitHub Environments / GitLab Approvals).
2. Реализовать canary release:
   • в прод-среде оставить старую версию (0.1.0) для 90% запросов;
   • новую (0.2.0) — для 10%;
   • через 30 минут собрать логи и метрики (можно симулировать генерацией результатов);
   • если метрики не ухудшились — поднять процент до 100%.
3. В meta.yaml обновить статус на production и дату.
4. Зафиксировать версию в production тегом (git tag v0.2.0).

Canary (симуляция):

• Написать скрипт canary_sim.py, который отправляет случайные 10% запросов к новой версии mock LLM, остальные — к старой, и выводит сводку метрик.

Ожидаемый результат этапа Промпт переведён в production, работает с canary, затем full rollout, тег версии создан.

Этап 5: Deprecated — вывод из эксплуатации (0.5 часа)

Действия

1. В meta.yaml изменить статус на deprecated, добавить причину и дату.
2. Создать ветку archive/qa-assistant-v0.1.0, переместить туда файлы.
3. В основной директории (prompts/qa-assistant/) оставить только ссылку на архив в README.md.
4. Обновить CI/CD: отключить триггеры для деприкейтед промптов (добавить условие if: contains(github.event.head_commit.message, 'deprecated') или просто не запускать workflow).
5. Закоммитить и смержить в main.

Ожидаемый результат этапа Старый промпт заархивирован, статус обновлён, production использует новую версию.

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

• Промпт создан через Pull Request в ветку feature/, прошёл code review (минимум 1 approve).
• CI-пайплайн на push в staging выполняет валидацию и A/B тест.
• A/B тест показал, что staging-версия не хуже production по выбранной метрике (допуск ≤5% ухудшения).
• Промпт переведён в production через PR с ручным approval (или автоматически, если настроено).
• Canary release симулирован: не менее 10% трафика на новую версию с положительными метриками.
• В meta.yaml последовательно указаны все статусы: draft, staging, production, deprecated.
• Каждый этап зафиксирован в истории Git: коммиты, теги, слияния веток.
• После deprecation файлы промпта перемещены в archive/ и не влияют на пайплайн.

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

Основной артефакт Git-репозиторий с полной историей жизненного цикла одного промпта.

• Ветки: feature/qa-draft, staging, production, main, archive/qa-assistant-v0.1.0.
• Файлы: все YAML-шаблоны, тесты, скрипты валидации и A/B тестирования.
• Теги: v0.1.0, v0.2.0 (фиксация production-версий).
• CI/CD конфигурация: .github/workflows/*.yml.

Дополнительные результаты

• Результаты A/B теста (ab_results.json).
• Отчёт канареечного деплоя (симуляция canary_sim.log).
• README с описанием lifecycle policy.

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

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

Примечание для первого раза может потребоваться до 10 часов из-за отладки CI/CD и скриптов. Рекомендуется выполнять последовательно, не пропуская этапы.

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

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

• Я создал структуру директорий для промпта и заполнил все обязательные поля в meta.yaml.
• Я запустил скрипт валидации локально и убедился, что он проходит без ошибок.
• Я создал Pull Request в staging, дождался прохождения CI и получил approve.
• Я провёл A/B тест с использованием тестового датасета и записал результаты.
• Я перевёл промпт в production через PR с ручным approval и создал Git-тег.
• Я заархивировал деприкейтированную версию и обновил meta.yaml.
• Я проверил, что в репозитории нет мусорных файлов, а все коммиты имеют осмысленные сообщения.