Что такое «regression testing» для агентов (старый кейс сломался)?

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

Regression testing для AI-агентов — это автоматизированный процесс запуска набора ранее успешно выполнявшихся сценариев (golden set) при каждом изменении кода агента, промптов или конфигурации. Цель — гарантировать, что новое изменение не сломало уже работающее поведение. Такой подход критичен для RAG|agentic RAG систем, где один агент может иметь десятки различных путей выполнения (tool calls, branching, loops), и любое изменение может неожиданно нарушить сценарий, который не проверяется вручную. Реализуется через CI/CD, блокируя мерж при падении любого блокирующего кейса.

1. Термин: Regression testing (регрессионное тестирование) в контексте агентов

Regression testing — это перезапуск всех существующих тестов после каждого изменения, чтобы убедиться, что старые функции продолжают работать. В классическом программировании это стандартная практика, но для AI-агентов есть специфика:

• Агент недетерминирован (LLM может давать разные ответы при одинаковом входе).
• Тесты проверяют не только результат, но и последовательность действий (использованные инструменты, переданные аргументы, соблюдение политик).
• Состояние агента может меняться из-за внешних факторов (например, смена версии LLM, drift|изменение схемы данных).

Regression testing для агентов — это не просто проверка «ответ правильный», а проверка того, что сценарий (workflow) выполнился так же, как в прошлый раз: вызваны те же инструменты, в том же порядке, с корректными параметрами.

2. Зачем нужно regression testing агентам?

Агенты в RAG|agentic RAG часто имеют сложную логику:

• Несколько LLM вызовов (планирование, рефлексия, генерация ответа).
• До 10–20 различных инструментов (поиск в БД, вызов API, выполнение кода).
• Ветвления (если условие A – сделать X, иначе – Y).
• Циклы (повторные попытки, итеративное уточнение).

Любое небольшое изменение (например, изменение промпта, добавление нового инструмента, обновление эмбеддингов) может сломать какой-нибудь редкий, но критичный сценарий, например, «агент, который должен подтвердить бронирование, вместо этого сделал его дважды». Regression testing ловит такие регрессии до выката в production.

3. Golden set (золотой набор)

Golden set — это коллекция проверенных и успешно выполненных сценариев, собранных из production-логов или созданных вручную для типовых случаев.

Требования к golden set:

• 200–500 кейсов: достаточно для покрытия основных путей, но не слишком много для быстрого прогона.
• Разнообразие: простые (один инструмент), сложные (5+ вызовов), граничные (пустой ответ, ошибка инструмента).
• Валидность: каждый кейс в момент добавления выполнялся 100% успешно (прошёл все проверки).
• Аннотация: для каждого кейса записан «правильный» трейс (последовательность вызовов, аргументы, финальный ответ).

Пример структуры кейса (JSON):

{
  "id": "booking_confirm_001",
  "query": "Забронируй столик на сегодня на 19:00 на двоих",
  "expected_trace": [
    {"tool": "check_availability", "args": {"date": "today", "time": "19:00", "people": 2}},
    {"tool": "book_table", "args": {"date": "today", "time": "19:00", "people": 2, "restaurant_id": "123"}},
    {"tool": "confirm", "args": {"booking_id": "expected_id"}}
  ],
  "expected_final_answer": "Столик забронирован, номер брони: ..."
}

4. Automated: CI/CD pipeline

Regression testing должен запускаться автоматически на каждый PR (pull request) перед мержем. Пайплайн в CI/CD (например, GitLab CI, GitHub Actions) включает:

1. Сборка окружения агента (загрузка последней модели, конфигов).
2. Прогон golden set: для каждого кейза запускается агент, записывается реальный трейс.
3. Сравнение с ожидаемым трейсом (с допуском на незначительные отличия).
4. Генерация отчёта: сколько кейсов прошло, сколько упало, детали по упавшим.
5. Решение: если хотя бы один блокирующий кейс упал — мерж блокируется. Некритичные падения могут быть разрешены с комментарием.

Пример фрагмента pipeline (YAML):

regression_tests:
  stage: test
  script:
    - python run_agent_tests.py --golden-set golden_set_v2.json --output report.json
  after_script:
    - python check_blockers.py --report report.json
  rules:
    - if: '$CI_PIPELINE_SOURCE == "merge_request_event"'

5. Метрики regression testing

Для количественной оценки качества регрессии используются метрики:

Alert: если pass rate падает ниже порога (например, 95%) или падает любой блокирующий кейс — CI падает, уведомление команде.

6. Автоматизация: инструменты и библиотеки

Для реализации regression testing агентов можно использовать:

• pytest + самописные фикстуры (самый гибкий вариант).
• LangSmith (by LangChain) — встроенная трейсинг и датасеты, можно загрузить golden set и прогонять.
• DeepEval или RAGAS — фреймворки для eval, можно кастомизировать под агентов.
• Custom test runner на базе asyncio (для параллельного прогона).

Пример упрощённого теста на pytest:

@pytest.mark.parametrize("case", load_golden_set())
def test_agent_trace(case, agent_instance):
    result = agent_instance.run(case.query)
    assert result.trace == case.expected_trace, f"Trace mismatch: {result.trace}"
    assert case.expected_answer.lower() in result.answer.lower()

7. Alert и блокировка мержа

Важнейший принцип: нельзя мержить код, сломавший старый сценарий. Правила:

• Блокирующие кейсы (critical) — помечены в golden set флагом blocker: true. Падение хотя бы одного → автоматический reject PR.
• Некритичные кейсы — могут падать, если разработчик явно указал причину (например, обновление промпта изменило формат, и это ожидаемо).
• Метрики-предупреждения (например, time stability) — не блокируют, но ставят warning.

Механизм: после прогона генерируется JSON с статусами, CI читает его и выставляет статус.

8. Поддержание и обновление golden set

Golden set не статичен — его нужно регулярно обновлять:

• Добавление новых кейсов: после фикса инцидента (когда новый баг был пойман) добавляем его кейс в золотой набор.
• Удаление устаревших: если изменилась логика агента (удалён инструмент, изменён API) — соответствующие кейсы удаляются или адаптируются.
• Версионирование: golden_set_v2, v3... чтобы можно было откатить или воспроизвести старый прогон.
• Ребаланс: периодически проверять, что кейсы покрывают все критичные пути.

Частота обновления: раз в 2 недели или после каждого значительного изменения архитектуры агента.

9. Подводные камни и их решение

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

Вопросы из курса, пересекающиеся с regression testing для агентов:

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

Задача

Реализовать систему регрессионного тестирования для простого агента бронирования ресторанов. Агент должен: принять запрос → проверить доступность → если доступно, забронировать → подтвердить.

Инструменты

• Python 3.11+
• LangGraph (или простой класс Agent)
• pytest
• GitHub Actions

Шаги

1. Создать агента с тремя инструментами: check_availability, book_table, confirm. Инструменты реализовать как функции с задержкой.
2. Сформировать golden set из 10 кейсов (разные даты, количество гостей, ошибки). Каждый кейс — JSON с query и expected_trace.
3. Написать pytest-тест, который загружает golden set, запускает агента (с моком LLM, чтобы ответы были детерминированными) и сравнивает трейс.
4. Создать GitHub Actions workflow, который при пуше на любую ветку кроме main запускает тесты. Если любой блокирующий кейс падает — workflow падает.
5. Проверить: изменить промпт агента так, чтобы он начал вызывать confirm до book_table — тест должен упасть.

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

• Рабочий репозиторий с агентов и регрессионными тестами.
• CI падает при нарушении ожидаемого поведения.
• Возможность добавить новый кейс (просто добавить JSON) и он будет проверяться.

Навигация

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