Проще говоря, regression test отвечает на вопрос: мы улучшили одно место, но не сломали ли другое. В AI-проектах это особенно важно, потому что маленькая правка промпта может улучшить один ответ и ухудшить десятки других. Новая модель может лучше писать текст, но хуже держать JSON-формат. Новый RAG может находить больше документов, но чаще добавлять нерелевантный контекст.
Для обычного сайта регрессионные тесты проверяют кнопки, формы, страницы и API. Для AI-агента они проверяют поведение: правильно ли агент классифицирует запрос, вызывает ли нужный инструмент, не выдает ли запрещенные данные, соблюдает ли формат ответа, умеет ли отказаться, не ломает ли сценарии на русском языке и не ухудшает ли качество на известных кейсах.
Регрессионное тестирование отличается от разовой проверки качества. Evals могут измерять качество новой идеи или сравнивать две модели. Regression suite хранит набор важных кейсов, которые нужно прогонять каждый раз перед релизом. Это как чек-лист безопасности для уже известных рабочих ситуаций.
Хороший набор регрессионных тестов не должен быть огромным в начале. Для MVP достаточно 30-50 реальных запросов: типовые вопросы, сложные случаи, ошибки пользователей, опасные действия, проверки формата, запросы без ответа, кейсы с персональными данными и сценарии, где агент должен передать задачу человеку. Важно, чтобы у каждого теста было ожидаемое поведение.
Результат регрессионного теста должен быть понятным. Не просто "ответ понравился" или "ответ не понравился", а конкретные критерии: содержит ли нужный JSON, вызван ли правильный tool, есть ли ссылка на источник, не раскрыты ли персональные данные, не придумал ли агент факт, соблюден ли tone of voice, нужен ли handoff.
Регрессионные тесты стоит запускать перед production-релизом и после любых изменений, влияющих на поведение агента. В идеале они входят в CI/CD: pull request меняет промпт или код, GitHub Actions запускает набор кейсов, а команда видит, где качество просело.
Главная ошибка - тестировать только счастливые сценарии. Нужны и неприятные случаи: пустой ввод, конфликтные инструкции, prompt injection, плохой документ в RAG, недоступный tool, неоднозначный запрос, пользователь просит запрещенное действие, модель возвращает неправильный формат. Именно такие кейсы чаще всего ломаются после улучшений.
Примеры
- После смены модели агент поддержки снова прогоняется на 50 старых обращениях. Проверяется, что он не стал чаще выдумывать статусы заказов и по-прежнему передает сложные случаи оператору.
- После изменения системного промпта запускают тесты на structured output. Если JSON стал ломаться в трех кейсах из двадцати, релиз останавливают.
- После переиндексации базы знаний RAG проверяют на вопросах без ответа. Агент должен честно сказать, что информации нет, а не искать похожий, но неверный документ.
- После добавления write tool в CRM прогоняют опасные сценарии: неоднозначная команда, чужой клиент, отсутствие approval. Агент не должен менять данные без подтверждения.
Где используется
- проверка AI-агента перед релизом
- контроль качества после смены модели
- проверка промпта после правок
- тестирование RAG и базы знаний
- проверка tool calling и прав доступа
- контроль structured output и JSON-схем
- поиск ухудшений после обновления backend
- security checks и prompt injection тесты
Связанные термины
Частые вопросы
Когда нужно запускать регрессионное тестирование AI-агента?
Запускайте его после изменения модели, системного промпта, RAG-индекса, tools, guardrails, памяти, формата ответа или backend-логики. Если изменение может повлиять на поведение агента, нужен хотя бы короткий regression прогон.
Сколько тестов нужно для первого regression suite?
Для старта хватит 30-50 реальных кейсов. Важнее не количество, а покрытие: типовые запросы, сложные случаи, ошибки, опасные действия, проверки формата и сценарии, где агент должен отказаться или передать задачу человеку.
Чем regression testing отличается от evals?
Evals - более широкое понятие: они могут сравнивать модели, проверять качество идеи или измерять отдельную метрику. Regression testing фокусируется на том, чтобы новая версия не ухудшила уже известные рабочие сценарии.
Можно ли проверять AI-ответы автоматически?
Да, часть проверок автоматизируется: JSON-схема, наличие источника, правильный tool call, запрет на PII, точные expected values. Но сложные ответы полезно периодически проверять человеком, особенно в юридических, финансовых и медицинских сценариях.
Что делать, если regression test упал?
Сначала понять, это реальное ухудшение или устаревший тест. Если поведение стало хуже, релиз лучше остановить: поправить промпт, данные, tool или guardrail, затем снова прогнать набор. Если новое поведение правильное, обновите expected result и зафиксируйте причину.
