ТЕХНИЧЕСКОЕ ЗАДАНИЕ: Настроить chaos testing для AI-агента

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

Научиться проектировать и проводить chaos-тесты для LLM-агента, чтобы проверить его способность к graceful degradation при внезапных ошибках API, задержках и отказах. Вы должны внедрить механизмы хаотического воздействия на внешние зависимости агента (LLM API, векторная БД, база знаний), замерить метрики деградации и убедиться, что агент не падает, а корректно обрабатывает ошибки (retry, fallback, логирование).

Ключевой результат Воспроизводимый набор chaos-экспериментов, подтверждающий, что агент сохраняет работоспособность при типовых сбоях.

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

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

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

1. Написать Python‑класс ChaosProxy, который перехватывает HTTP‑вызовы агента и добавляет:
   • случайные задержки (0.5‑3 сек)
   • 5xx ошибки (50% вероятность)
   • таймауты (timeout после 5 сек)
2. Завернуть вызовы LLM и других API через этот прокси (с помощью requests или httpx с middleware)
3. Для каждого теста запускать агента в изолированном процессе с разными параметрами хаоса

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

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

Этап 1: Подготовка тестового агента и сценариев (1–2 часа)

Действия

1. Выберите существующего агента (или соберите простого: принимает вопрос, вызывает LLM, возвращает ответ). Агент должен иметь минимум 2 внешних вызова (LLM + поиск/векторная БД).
2. Подготовьте 10–15 тестовых запросов (нормальных, пограничных). Сохраните в JSON/YAML.
3. Создайте замерочную обёртку: фиксируйте время выполнения, статус ответа (OK/ERROR), количество ретраев.

Ожидаемый результат этапа Рабочий агент + набор тестовых кейсов + измерительная обёртка.

Этап 2: Реализация chaos-прокси (2–3 часа)

Действия

1. Создайте модуль chaos_proxy.py с классом ChaosProxy:

   class ChaosProxy:
       def __init__(self, delay_range=(0.2, 2.0), error_rate=0.3, timeout_prob=0.1):
           self.delay_range = delay_range
           self.error_rate = error_rate
           self.timeout_prob = timeout_prob
   
       async def request(self, method, url, **kwargs):
           # 1. добавить случайную задержку
           # 2. с вероятностью error_rate вернуть HTTPError (5xx)
           # 3. с вероятностью timeout_prob – таймаут (asyncio.TimeoutError)
           # 4. иначе пропустить вызов как есть
   

2. Интегрируйте прокси с агентом: замените прямые вызовы LLM API на proxy.request(...) или используйте перехватчик httpx.AsyncClient с mount на all://.
3. Напишите функцию run_chaos_test(agent, chaos_config), которая запускает агента на всех тестовых запросах и собирает статистику.

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

Этап 3: Проведение chaos-экспериментов (2–3 часа)

Действия

1. Определите базовую линию (baseline) – запуск агента без хаоса. Зафиксируйте success_rate=100%, среднее время ответа.
2. Проведите серию экспериментов с разными уровнями хаоса:
   • Эксперимент A низкий уровень (error_rate=0.1, delay=0.5‑1.5 сек)
   • Эксперимент B средний (error_rate=0.3, delay=1‑3 сек, timeout_prob=0.1)
   • Эксперимент C высокий (error_rate=0.6, delay=3‑6 сек, timeout_prob=0.3)
3. Для каждого эксперимента выполните по 10 прогонов каждого тестового запроса (итого 150–200 запусков). Записывайте:
   • успех/неудача запроса
   • количество ретраев
   • итоговое время ответа
   • факт graceful degradation (агент вернул осмысленный fallback, а не exception)
4. Постройте таблицу результатов:

Ожидаемый результат этапа Заполненная таблица и осознание порогов graceful degradation.

Этап 4: Анализ и улучшение graceful degradation (1–2 часа)

Действия

1. Проанализируйте, при каком уровне хаоса агент перестаёт справляться (success rate < 80% или более 30% fallback).
2. Внедрите улучшения в агента:
   • экспоненциальный backoff при ретраях
   • fallback-ответ (“извините, сервис временно недоступен”)
   • кэширование предыдущих успешных ответов
   • мониторинг health-check перед вызовом
3. Повторите эксперименты B и C с улучшенным агентом. Сравните метрики.

Ожидаемый результат этапа Код улучшенного агента и сравнительная таблица “до/после”.

Этап 5: Оформление отчёта (1 час)

Действия

1. Напишите краткий chaos testing report (в README.md) со структурой:
   • Цель
   • Описание эксперимента
   • Результаты (таблицы, графики)
   • Выводы: при каких условиях агент деградирует приемлемо, а где требуется доработка
   • Рекомендации для production
2. Приложите код прокси, скрипты тестов, лог-файлы.

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

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

• Реализован chaos-прокси, имитирующий задержки, ошибки 5xx и таймауты с настраиваемыми вероятностями.
• Прокси интегрирован с агентом (заменён клиент HTTP).
• Проведён baseline-замер (0% хаос) – success_rate 100%.
• Проведены минимум 3 эксперимента с увеличивающимся уровнем хаоса.
• Для каждого эксперимента собраны метрики: success rate, avg latency, % fallback, max retries.
• Внесены улучшения в агента (retry с backoff, fallback сообщение).
• Сравнение “до/после” показывает прирост success rate минимум на 10 процентных пунктов на высоком уровне хаоса.
• Создан отчёт (README) с описанием эксперимента и таблицами результатов.
• Код прокси и тестов опубликован в Git-репозитории с инструкцией по запуску.
• Все тесты проходят без падений интерпретатора Python (ловятся все исключения).

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

Основной артефакт – репозиторий с:

• chaos_proxy.py – реализация chaos-прокси
• agent.py – код агента (исходный и улучшенный)
• test_chaos.py – pytest-скрипт, запускающий эксперименты
• experiments/results.csv – сырые данные замеров
• chaos_testing_report.md – отчёт с таблицами и выводами

Опциональные результаты:

• Графики (latency distribution, success rate vs chaos level)
• Демонстрация graceful degradation в логах (логи fallback-сообщений)

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

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

Примечание: При первом выполнении рекомендуется заложить до 12 часов, включая изучение документации и отладку.

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

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

• Я понимаю, что такое graceful degradation и как его измерять (success rate, fallback rate).
• Я заменил все внешние вызовы агента на вызовы через chaos-прокси.
• Я зафиксировал baseline без хаоса и убедился, что success_rate = 100%.
• Я провёл минимум три эксперимента с разным уровнем хаоса и записал результаты.
• Я внёс улучшения в агента (backoff, fallback) и повторно протестировал на высоком уровне хаоса.
• Я оформил отчёт с таблицами и выводами, код загружен в Git.