ТЕХНИЧЕСКОЕ ЗАДАНИЕ: Реализовать автоматический rollback промпта при падении faithfulness

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

Разработать и внедрить механизм автоматического отката версии системного промпта (или конфигурации) при обнаружении статистически значимого падения метрики faithfulness более чем на 5% относительно установленного baseline. Решение должно быть готово к интеграции в существующую RAG-систему и выполняться полностью автономно в пределах 1 минуты с момента детекции деградации.

Ключевой результат Работающий пайплайн мониторинга faithfulness + триггер rollback, который за 1 минуту возвращает стабильную версию промпта по умолчанию.

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

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

1. Разверните минимальную RAG-систему (например, на базе Hugging Face + FAISS) с одним промптом-шаблоном
2. Сделайте две версии промпта: v1 (базовый, faithfulness ~0.85) и v2 (намеренно плохой, faithfulness ~0.70)
3. Напишите скрипт, который постоянно подаёт запросы и считает faithfulness через RAGAS (но можно заменить на быструю proxy-модель, например BERTScore)
4. Сохраняйте метрики в локальную БД SQLite

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

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

Этап 1: Настройка мониторинга faithfulness (2 часа)

Действия

1. Выберите способ вычисления faithfulness в реальном времени

   • Используйте ragas.metrics.faithfulness (требует OpenAI, но можно симулировать локальной LLM)
   • Или напишите простую proxy-метрику: cosine similarity между эмбеддингами ответа и контекста + пороговое правило
   • Если используете RAGAS, запускайте оценку асинхронно (batch по 10 ответов) раз в 30 секунд.

2. Соберите baseline

   • Запустите систему на стабильной версии промпта v1 в течение 30 минут
   • Запишите среднюю faithfulness и стандартное отклонение (std) за этот период
   • Сохраните их в конфигурационном файле:

   {
     "baseline_mean": 0.85,
     "baseline_std": 0.03,
     "window_size": 10,
     "threshold_percent": 5
   }
   

3. Реализуйте скользящее окно метрик

   • Собирайте последние N замеров faithfulness (например, N=10)
   • Каждые 15 секунд пересчитывайте среднее по окну
   • Если среднее упало ниже (baseline_mean * (1 - threshold_percent/100)), считаем это деградацией

Ожидаемый результат этапа
Работающий скрипт monitor.py, который каждые 15 секунд выводит метрику и флаг деградации (True/False).

Этап 2: Разработка логики rollback (1 час)

Действия

1. Определите условия для срабатывания rollback

   • Деградация должна наблюдаться в течение 3 последовательных окон (чтобы отфильтровать шум)
   • Дополнительно: проверьте, что падение не связано с потерей данных (например, если количество ответов в окне < 5)

2. Реализуйте функцию переключения версии промпта

   • Храните версии промптов как JSON-файлы в директории prompts/ (например v1.json, v2.json)
   • Или используйте API LangSmith: langsmith.update_prompt_version(prompt_id, new_version)
   • Напишите rollback_to_stable(), которая:
     • Определяет последнюю стабильную версию (пометьте v1 как stable=true)
     • Меняет симлинк current_prompt.json на эту версию
     • Логирует событие в rollback_events.log (время, версия, метрики до/после)

3. Добавьте защиту от повторных срабатываний

   • После rollback блокируйте новый откат на 5 минут (используйте time.sleep или timestamp)

Ожидаемый результат этапа
Функция rollback_to_stable(), готовая вызываться из мониторинга.

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

Действия

1. Свяжите мониторинг и rollback

   • В скрипте monitor.py при обнаружении деградации в 3 последовательных окнах вызывайте rollback_to_stable()
   • После успешного rollback отправьте уведомление в Telegram/Slack (простой webhook)

2. Интеграция с Git (опционально)

   • Пусть версия промпта – это файл в Git-репозитории.
   • Сделайте GitHub Action, который при мерже hotfix/rollback автоматически меняет current_prompt.txt в ветке main.
   • Либо используйте git revert к последнему коммиту со stable-версией.

3. Разверните демо-приложение

   • Flask-endpoint /trigger_rollback для ручного теста
   • Flask-endpoint /health – показывает текущую версию и метрики

Важно Время от момента фиксации падения до смены версии не должно превышать 60 секунд. Замерьте с помощью time.perf_counter().

Ожидаемый результат этапа
Одно приложение (или набор скриптов), которое в цикле мониторит faithfulness и при обнаружении деградации делает rollback не более чем за 1 минуту.

Этап 4: Тестирование и симуляция падения (1 час)

Действия

1. Создайте тестовый сценарий

   • Запустите систему на v1 (baseline ~0.85)
   • Подождите 3 окна для стабилизации
   • Вручную (или скриптом) переключитесь на v2 (плохой промпт, faithfulness ~0.70)
   • Замерьте, через сколько секунд произошёл rollback обратно на v1

2. Проверьте граничные случаи

   • Падение менее 5% – отката быть не должно
   • Единичный выброс (1 окно плохое, остальные хорошие) – без отката
   • Потеря всех данных (остановка генерации) – не должно ложно сработать

3. Зафиксируйте результаты теста

   # Пример проверки
   assert rollback_triggered == True, "Rollback not triggered for >5% drop"
   assert time_to_rollback < 60, f"Rollback took {time_to_rollback}s"
   

Ожидаемый результат этапа
Лог теста с временами, подтверждающий, что rollback срабатывает корректно в заданных условиях и не срабатывает в шумовых.

Этап 5: Документирование и постмортем (30 минут)

Действия

1. Опишите архитектуру решения (диаграмма последовательности в Mermaid)
2. Напишите README с инструкцией по развёртыванию
3. Создайте типовой постмортем на случай, если rollback не сработал (формат из примера ТЗ)
4. Запушьте весь код в Git с тегом v0.1-rollback

Ожидаемый результат этапа
Репозиторий с кодом, README, логами тестов.

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

• Мониторинг faithfulness вычисляется автоматически с периодом не более 30 секунд
• Порог срабатывания отката – падение >5% от baseline (relative), подтверждённое тремя последовательными окнами
• Время от момента падения до полного переключения на стабильную версию промпта ≤ 60 секунд
• В лог пишутся: время срабатывания, версия до/после, метрики faithfulness до/после
• Откат не срабатывает при единичных выбросах или при падении менее 5%
• После отката система возвращается к работе на стабильной версии без вмешательства оператора
• Предусмотрена защита от повторного циклического отката (блокировка на 5 минут)

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

Основной артефакт
Python-репозиторий с модулями:

• monitor.py – скрипт мониторинга с функциями оценки faithfulness и скользящего окна
• rollback.py – логика отката (выбор стабильной версии, переключение симлинка/API, логирование)
• test_simulation.py – скрипт для симуляции падения faithfulness
• prompts/ – директория с версиями промптов (v1.json, v2.json, ...)
• config.json – параметры (baseline, threshold, window_size)
• README.md – инструкция по запуску

Ожидаемое содержимое config.json

{
  "baseline_mean": 0.85,
  "baseline_std": 0.03,
  "threshold_percent": 5,
  "window_size": 10,
  "min_consecutive_anomalies": 3,
  "rollback_cooldown_seconds": 300,
  "current_version": "v1",
  "stable_version": "v1"
}

Дополнительно (опционально):

• Интеграция с Telegram-ботом для уведомлений
• Grafana dashboard с панелью faithfulness и событиями rollback

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

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

Примечание: Для первого раза может потребоваться +1 час на изучение инструментов (RAGAS, LangSmith).

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

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

• Я реализовал мониторинг faithfulness с периодом ≤ 30 секунд
• В моём скрипте есть проверка трёх последовательных аномалий перед rollback
• Я измерил время rollback и убедился, что оно ≤ 60 с
• Я проверил, что при падении < 5% откат не происходит
• Я написал логирование каждого события rollback с деталями
• Я настроил блокировку повторного отката на 5 минут (cooldown)
• Я добавил в README команду для запуска тестовой симуляции