Что такое «chaos testing» для агента (внезапно API вернул ошибку)?

Краткий тезис

Chaos testing (тестирование хаосом) — это метод преднамеренного внесения сбоев (ошибок, задержек, отказов) в систему для проверки её устойчивости (resilience). Для AI-агента, который вызывает внешние API и инструменты, chaos testing позволяет выявить слабые места в обработке ошибок, fallback-стратегиях и graceful degradation. Цель — убедиться, что агент продолжает работать (или корректно сообщает о проблеме) даже при нештатных ситуациях, а не выдаёт неверный ответ или падает.

1. Определение chaos testing в контексте AI-агентов

Chaos testing (или Chaos Engineering) — практика, заимствованная из DevOps и SRE. Она предполагает проведение контролируемых экспериментов, в ходе которых в систему намеренно вносятся нарушения. Для AI-агента с RAG и инструментами (API веб-поиска, базы знаний, калькуляторы, переводчики) хаос-тестирование фокусируется на слое коммуникации: вызовы внешних сервисов, задержки сети, поврежденные ответы.

Основные принципы:

• Начинать с гипотезы об устойчивости (например: «агент корректно повторит вызов API после 502 ошибки»).
• Вносить сбои в контролируемой среде (staging/тестовый стенд).
• Измерять влияние (метрики: доля успешных сессий, время ответа, количество повторных попыток).
• Автоматически откатывать изменения системы до введения хаоса, если ущерб превышает порог.

2. Зачем нужно chaos testing для агентов

AI-агенты всё чаще используются в production-сценариях (поддержка клиентов, бронирование, анализ данных). Отказоустойчивость становится критичной:

• Предотвращение «ложных ответов»: если внешний API вернул мусор, а агент просто подставил его в ответ, пользователь введён в заблуждение.
• Graceful degradation: агент должен уметь сообщить «сервис временно недоступен, повторите позже» вместо того, чтобы зависнуть или выдать ошибку.
• Наблюдаемость (observability): хаос-тесты выявляют непокрытые сценарии логирования и метрик.
• Экономия времени разработки: ручное тестирование всех комбинаций ошибок невозможно, автоматизированный хаос покрывает сотни вариантов.

3. Категории вносимых сбоев (Fault injection)

В черновике перечислены основные типы. Расширим их.

4. Роль graceful degradation в хаос-тестах

Graceful degradation — способность системы предоставлять урезанный, но корректный функционал при отказе части компонентов. Для агента это может означать:

• Если search API недоступен → агент использует только внутреннюю базу знаний или просит пользователя уточнить.
• Если LLM endpoint (например, OpenAI) даёт ошибку → агент автоматически переключается на fallback-модель (локальную, меньшего размера).
• Если все внешние вызовы падают → агент выдаёт стандартное сообщение об ошибке и логирует инцидент.

Chaos testing помогает проверить, действительно ли код graceful degradation срабатывает, а не только написан в документации.

5. Методология эксперимента

Типичный хаос-эксперимент для агента состоит из шагов:

1. Определяем «steady state»: нормальное поведение (агент отвечает за < 3 сек, точность > 95%).
2. Выдвигаем гипотезу: «при 5% ошибок 429 агент всё равно завершает диалог с корректным результатом, используя ретраи».
3. Вводим сбой (например, модифицируем прокси-слой, добавляем случайные задержки + 429).
4. Собираем метрики: доля успешных вызовов, среднее время, количество сработавших ретраев, доля ошибок на выходе агента.
5. Сравниваем с steady state.
6. Откатываем сбой (или автоматически, если порог превышен).

Важно проводить эксперименты на отдельном тестовом экземпляре агента, изолированном от реальных пользователей.

6. Инструменты для chaos testing

Чаще всего для агентов используют custom fault injection на этапе разработки, а затем добавляют инфраструктурные сбои на CI/CD.

7. Пример custom fault injection на Python

Допустим, агент использует класс HttpClient для вызова внешней API поиска.

import random
import time
from functools import wraps

def fault_inject(func):
    """Декоратор для имитации сбоев на вызове инструмента."""
    @wraps(func)
    def wrapper(*args, **kwargs):
        # latency
        delay = random.choice([0, 0.5, 5, 30])
        time.sleep(delay)

        # error codes
        if random.random() < 0.1:  # 10% шанс ошибки
            error_code = random.choice([404, 500, 502, 429])
            raise ConnectionError(f"HTTP {error_code}")

        # malformed response
        if random.random() < 0.05:
            return "this is not a valid json"

        return func(*args, **kwargs)
    return wrapper

class SearchTool:
    @fault_inject
    def search(self, query: str) -> dict:
        # normally calls external API
        return {"results": ["doc1", "doc2"]}

# Агент вызывает инструмент с обработкой ошибок
agent = Agent()
try:
    result = agent.ask("Какова столица Франции?")
except Exception as e:
    print(f"Агент упал: {e}")

В реальности fault-injection включается только в тестовом окружении через feature flag.

8. Лучшие практики chaos testing для агентов

• Начинайте с малого: сначала на ошибки одного инструмента, потом комбинируйте.
• Определите blast radius: хаос-эксперименты не должны затрагивать продуктивные данные.
• Автоматизируйте: запускайте набор сценариев в CI, чтобы каждое изменение кода проходило проверку.
• Используйте мониторинг: логирование (структурированные логи), трейсинг (OpenTelemetry), метрики (доля успешных вызовов инструментов).
• Документируйте: каждая проверяемая гипотеза → результат → изменение кода.
• Проверяйте не только ошибки, но и длинные задержки: агент может бесконечно ожидать, расходуя лимит токенов или контекст.

9. Связь с observability

Без наблюдаемости chaos testing бесполезен. Для оценки поведения агента нужно:

• Логировать каждый вызов инструмента (входные параметры, статус, время, ошибку).
• Трейсить полный цикл диалога (trace span на каждый шаг).
• Метрики: количество ретраев, успешность, средняя задержка.

Chaos testing часто выявляет, что какие-то шаги не логируются и не мониторятся — тогда сложно понять, что пошло не так.

Пет-проект для закрепления

Задача: Разработать минимального агента на Python с двумя инструментами (погодное API и поисковик), написать fault-injection middleware и провести хаос-эксперименты.

Инструменты:

• Python, FastAPI (для эмуляции внешних API), httpx (асинхронный клиент).
• asyncio для управления тайм-аутами.
• pytest + декораторы fault injection.

Шаги:

1. Создать «идеальное» окружение: два сервиса (weather, wiki), агент с ретраями (максимум 2).
2. Написать chaos-конфигурацию: 20% задержек > 10 сек, 10% ошибок 500.
3. Запустить серию диалогов (10 запросов) и собрать метрики (успешность, время).
4. Изменить код агента: добавить fallback — если погода падает, брать среднюю температуру из кэша; если поиск падает — выдавать «Временно недоступно».
5. Повторить тесты; убедиться, что метрики улучшились (успешность выросла с 70% до 95%).
6. Добавить логирование и трейсинг (например, через loguru), чтобы видеть каждый шаг.

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

• Простая библиотека (chaos_agent) с конфигурацией fault injection.
• Набор тестов в pytest, доказывающих устойчивость агента.
• Дашборд метрик (в консоли или Grafana) с histogram задержек.
• Отчёт: «До внедрения fallback успешность = X, после = Y».

Связь с другими вопросами

Навигация

• Предыдущий: 795
• Следующий: 797
• Индекс: 00. Индекс разборов