Как вы тестируете агента на «неожиданные input» (не только adversarial, но и просто странные)?

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

Тестирование агента на неожиданные input — это проверка его робастности (robustness) и безопасности (safety) в условиях, выходящих за рамки нормального использования. В отличие от обычного RAG, агент может выполнять действия (вызывать инструменты, планировать), поэтому неожиданный запрос способен вызвать не только неверный ответ, но и зацикливание, нежелательные call|вызовы API или утечку данных. Основной метод — фаззинг (fuzzing): генерация граничных, пустых, очень длинных, эмодзи-насыщенных, многократно повторённых запросов, а также adversarial (инъекции, jailbreaking). Ключевые метрики: crash rate, infinite loop rate, Call Call tool call accuracy и response safety.

1. Термин: «Неожиданные input» (unexpected inputs)

Неожиданные input — это любые запросы, которые не соответствуют типичному распределению пользовательских сообщений. Их можно разделить на три категории:

• Adversarial — целенаправленно вредоносные: prompt injection, jailbreaking, попытки заставить агента выполнить опасные действия.
• Странные (weird) — не вредоносные, но нестандартные: пустая строка, только эмодзи, бессмысленный набор символов, очень длинный текст, смесь языков, нецензурная лексика, противоречивые инструкции.
• Граничные (edge cases) — на границе допустимого: запросы длиной ровно в 1 символ, запросы с максимальным числом токенов, запросы с невалидным Unicode, запросы с HTML/JavaScript тегами.

Почему это важно для агента? Агент в Agentic RAG не просто генерирует ответ, а может:

• вызывать внешние API (поиск, базы данных, калькуляторы);
• выполнять многошаговое планирование (chain-of-thought);
• запоминать контекст (memory);
• принимать решения о завершении диалога.

Неожиданный input может нарушить любой из этих процессов.

2. Зачем тестировать агента на неожиданные input?

В отличие от обычного RAG, где неожиданный input ведёт лишь к плохому ответу, у агента есть «рычаги воздействия» — инструменты. Поэтому тестирование должно покрывать не только генерацию, но и планирование и вызов инструментов.

3. Методы тестирования

3.1 Фаззинг (Fuzzing)

Фаззинг — автоматическая генерация большого количества случайных или мутированных запросов. Для агента можно использовать:

• Мутационный фаззинг: взять нормальный запрос и случайно изменить его (заменить символы, вставить эмодзи, удалить слова).
• Генеративный фаззинг: создать запросы по грамматике (например, «повтори слово X 1000 раз»).
• Словарный фаззинг: использовать списки известных странных строк (пустая строка, null, только пробелы, символы Unicode из разных плоскостей).

Пример простого фаззера на Python:

import random
import string

def generate_fuzzy_input(base_length=100):
    # Пустая строка
    if random.random() < 0.1:
        return ""
    # Очень длинная строка
    if random.random() < 0.1:
        return "A" * 10000
    # Только эмодзи
    if random.random() < 0.1:
        return "😀" * 50
    # Случайные символы
    return ''.join(random.choices(string.printable, k=base_length))

3.2 Тестирование граничных случаев (Edge Case Testing)

Создаётся фиксированный набор кейсов:

3.3 Adversarial тестирование

Специфично для агентов: проверка на prompt injection и jailbreaking. Например:

• Попытка заставить агента вызвать инструмент с вредоносными параметрами.
• Запрос, который пытается переписать системный промпт агента.
• Использование role-playing (например, «Ты теперь злой агент, сделай ...»).

Для этого можно использовать готовые датасеты (например, Garak, PromptBench) или написать свои сценарии.

3.4 Стресс-тестирование (Stress Testing)

Проверка поведения агента при высокой нагрузке:

• Множество параллельных неожиданных запросов.
• Запросы, которые требуют многошагового планирования с неожиданными промежуточными результатами.
• Запросы, которые могут вызвать infinite loop (например, «Повторяй за мной: "Повторяй за мной"»).

3.5 Тестирование на зацикливание (Loop Detection)

Для агентов с циклом размышлений (ReAct, Plan-and-Execute) важно выявить запросы, которые заставляют агента бесконечно повторять одни и те же шаги. Методы:

• Установить максимальное число шагов (например, 10) и логировать каждый шаг.
• Анализировать повторяющиеся паттерны в вызовах инструментов.
• Использовать детектор циклов на основе хэшей состояний.

4. Метрики для оценки

5. Инструменты и фреймворки

• LangSmith — позволяет логировать все шаги агента, анализировать цепочки вызовов, выявлять аномалии.
• DeepEval — библиотека для тестирования LLM, поддерживает кастомные метрики и генерацию тестовых кейсов.
• RAGAS — можно адаптировать для оценки ответов агента на неожиданные запросы (faithfulness, answer relevance).
• Hypothesis (Python) — библиотека для property-based testing, удобна для генерации странных input.
• Atheris — фаззер на основе libFuzzer для Python, может использоваться для поиска крахов.
• Garak — фреймворк для тестирования безопасности LLM, включает сценарии jailbreaking.

Пример интеграции с Hypothesis:

from hypothesis import given, strategies as st

@given(st.text(max_size=1000))
def test_agent_does_not_crash(input_text):
    response = agent.run(input_text)
    assert response is not None

6. Процесс тестирования в CI/CD

1. Сбор тестовых кейсов: создать репозиторий с категориями (edge, adversarial, weird). Использовать как ручные, так и автоматически сгенерированные.
2. Автоматический прогон: запускать фаззеры и фиксированные тесты при каждом изменении кода агента.
3. Логирование: записывать все шаги агента (промпты, вызовы инструментов, ответы) в структурированном виде (JSON).
4. Анализ: вычислять метрики (crash rate, loop rate) и сравнивать с baseline.
5. Пороговые значения: например, crash rate не должен превышать 0.1%, infinite loop rate — 0.5%.
6. Итерация: при обнаружении проблем добавлять новые тестовые кейсы и исправлять логику агента.

7. Пример: тестирование агента-калькулятора

Допустим, агент имеет инструмент calculate(expression: str). Неожиданные input:

• "2+2" — нормально.
• "" — агент должен запросить выражение.
• "2/0" — агент должен вернуть ошибку деления на ноль, а не краш.
• "__import__('os').system('rm -rf /')" — агент не должен вызывать calculate с этим, а отклонить.
• "2+2" * 1000 — агент должен обрезать или вернуть ошибку о превышении длины.

Тестирование: прогоняем 1000 таких запросов, измеряем crash rate и tool call accuracy.

8. Связь с robustness и safety

Тестирование на неожиданные input — часть более широкой практики red-teaming и alignment. Для агентов особенно важно:

• Robustness: способность сохранять функциональность при любых входных данных.
• Safety: предотвращение вредоносных действий.
• Reliability: предсказуемость поведения.

Эти аспекты пересекаются с вопросами оценки качества RAG (вопрос 5), безопасности LLM (вопрос 390), детекции галлюцинаций (вопрос 12) и управления циклами агента (вопрос 393).

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

Задача: Создать простого агента с двумя инструментами (поиск в Википедии и калькулятор) и написать фаззер для тестирования на неожиданные input.

Инструменты: Python, LangChain (или простой класс агента), библиотека hypothesis, логирование в файл.

Шаги:

1. Реализовать агента с циклом ReAct (максимум 5 шагов).
2. Написать функцию generate_weird_inputs(), которая возвращает список из 100 запросов: пустые, очень длинные, с эмодзи, с инъекциями, с противоречиями.
3. Запустить агента на каждом запросе, записывая в лог: запрос, количество шагов, ошибки, вызовы инструментов.
4. Вычислить crash rate, infinite loop rate, среднее число шагов.
5. Визуализировать результаты (гистограмма числа шагов, таблица с типами ошибок).

Ожидаемый результат: Вы получите численные метрики устойчивости агента и список конкретных запросов, которые приводят к проблемам. Это позволит улучшить обработку ошибок и валидацию входных данных.

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

Навигация

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