Промпт в рабочей AI-системе влияет на её поведение не сам по себе, а вместе с остальной конфигурацией. Поэтому после изменения нужно зафиксировать все остальные параметры, запустить baseline (базовую версию) и candidate (изменённую) на одном regression set (регрессионный набор), сравнить переходы в каждом кейсе и применить заранее определённый release gate (критерии готовности). Средний балл помогает оценить результат, но сам по себе не показывает, безопасен ли выпуск.
Команда меняет несколько строк в системной инструкции. На контрольном примере ответ становится точнее, затем правка уходит в production. Потом — бац! И специально обученная AI-функция начинает ошибаться в другом сценарии, который никто не перепроверил. Вот так локальное улучшение оказалось скрытой регрессией. В данном понимании тестирование промптов уже не упирается в поиск удачной формулировки, а даёт квест на проверку изменений и их влияние на поведение системы.
Эта статья не о том, как писать «идеальные промпты» и не приводит пример универсального шаблона для копипасты. Формулировка запроса затрагивает только один слой системы. Необходимые факты приходят из контекста, а качество результата зависит также от модели, инструментов, параметров генерации, выходной схемы и прикладной логики. Отдельно в другом материале блога уже разбирается, как подготовить QA-контекст для AI-ассистента. Здесь вопрос другой: как безопасно изменить инструкцию, по которой AI работает.
Рабочая схема выглядит так:зафиксированная конфигурация → regression set → baseline → candidate → evaluators → попарное сравнение → release gate → выпуск или откат
Почему промпт стал тестируемым артефактом
В прикладной системе промпт управляет не только формулировкой ответа. Он влияет на полноту результата, выбор инструмента, аргументы вызова, формат данных, использование контекста, ограничения безопасности, стоимость и задержку. Небольшой текстовый diff может изменить несколько участков поведения сразу.
Регрессионное тестирование промптов начинается с управляемого изменения. OpenAI рекомендует хранить production-промпты в коде и проводить правки через обычный процесс ревью, тестов и развёртывания.
Но одного файла с инструкцией недостаточно. Фактическое поведение определяет связка:
prompt × model × context × tools × parameters × output schema × application logic
Если вместе с промптом обновились модель и retrieval-конфигурация, разницу нельзя приписать одной текстовой правке. Остальные значимые переменные фиксируют либо учитывают как отдельные изменения.
Что считать регрессией промпта
Регрессия промпта — это ухудшение ранее приемлемого поведения после изменения инструкции или связанной конфигурации. Иная формулировка ответа ещё не означает ошибку. Значимым становится нарушение требования, контракта или установленного ограничения.
| Тип регрессии | Что изменилось к худшему | Пример |
|---|---|---|
| Функциональная | Задача выполняется неправильно или не полностью | AI пропускает обязательный шаг анализа |
| Контрактная | Нарушен машинный интерфейс | Пропало обязательное поле JSON или появился недопустимый enum |
| Семантическая | Ответ допустим по форме, но хуже по смыслу | Классификация не учитывает часть входных данных |
| Инструментальная | Неверно выбран или вызван инструмент | Агент обращается не к тому сервису либо передаёт ошибочные аргументы |
| Безопасностная | Ослабли ограничения | Модель раскрывает сведения, которые должна скрывать |
| Производственная | Выросли стоимость или задержка без выигрыша | Инструкция стала дороже, но не точнее |
| Стабильная | Один сценарий чаще даёт неприемлемый результат | Кейс проходит один раз из трёх |
Регрессия всегда определяется относительно точки отсчёта. Вопрос не в том, «хороша ли модель вообще», а в том, сломало ли конкретное изменение то, что раньше работало.
Что проверять вместо полного совпадения текста
Классическое expected == actual подходит, когда у результата есть единственное допустимое представление: метка класса, числовое значение, имя инструмента или строгая структура. Для свободного текста такой критерий истины быстро становится хрупким. Два корректных ответа могут не совпасть ни одной фразой, а одинаково воспроизводимый ответ может оставаться фактически неверным.
Нулевая температура проблему не устраняет. Microsoft указывает, что seed лишь повышает воспроизводимость, но не гарантирует её. Исследование ICLR 2026 также фиксирует различия при temperature=0. Поэтому проверяют устойчивые свойства результата, а не его буквальную копию.
Удобно разделить проверки на три уровня.
| Уровень | Что проверяется | Подходящий метод |
|---|---|---|
| Машинный контракт | Структура, обязательные поля, допустимые значения, tool calls | Код, JSON Schema, regex, статический анализ |
| Смысл | Полнота, корректность, соответствие рубрике | Экспертная разметка или модельный evaluator |
| Фактический результат | Произошло ли ожидаемое действие в системе | Проверка состояния, записи, статуса или другого outcome |
Для AI-агента последняя строка особенно важна. Сообщение «дефект создан» ничего не доказывает, пока система не подтверждает появление нужной записи.
Из чего собрать regression set
Regression set, или набор регрессионных сценариев, должен отражать реальную область применения функции. Красивые примеры, на которых промпт разрабатывали, почти всегда дают слишком благоприятную картину.
В стартовый набор входят четыре группы:
- типовые успешные сценарии из рабочей среды;
- прошлые сбои и обращения пользователей;
- граничные комбинации данных;
- отрицательные случаи, где действие не должно выполняться.
В руководстве Anthropic по evals для AI-агентов предлагается начинать с 20–50 простых задач из реальных сбоев. Это стартовая рекомендация, а не универсальный норматив: зрелой системе и небольшому ожидаемому эффекту потребуется больше наблюдений.
Набор проверяет оба направления поведения. Рядом со сценарием «должен вызвать поиск» нужен сценарий «должен ответить без поиска». Иначе оптимизация быстро становится односторонней. То же относится к отказам, эскалациям и созданию дефектов.
Каждый кейс должен содержать не только вход, но и критерий успеха: обязательные свойства результата, запрещённое поведение, критичность и подходящий evaluator. Сам dataset тоже версионируется. Иначе исторические прогоны перестают быть сопоставимыми.
| Вопрос | Основной evaluator | Когда применять |
|---|---|---|
| Соблюдён ли формат? | Детерминированная проверка | Схема, поля, типы, диапазоны, регулярные выражения |
| Правильно ли выбран инструмент? | Проверка вызова и аргументов | Tool use, API-команды, разрешённые операции |
| Выполнена ли задача? | Outcome-проверка | Изменение статуса, запись в БД, создание сущности |
| Полон и корректен ли свободный ответ? | Rubric-based evaluator | Несколько допустимых формулировок |
| Допустим ли риск в спорном случае? | Экспертное ревью | Высокая цена ошибки или неоднозначный критерий |
LLM-as-a-judge масштабирует проверку свободных ответов, но не становится источником истины. Его вердикт зависит от рубрики и judge model, а исследования фиксируют влияние порядка ответов и стиля. Поэтому модельного судью калибруют на человеческой разметке и не используют как единственную защиту для безопасности, финансово значимых действий и строгих контрактов.
Приоритет прост: код пишется там, где есть возможность; модель проходится там, где нужна семантика; эксперт уже думает и оценивает только там, где цена ошибки реально высока.
Как сравнить baseline и candidate без самообмана
Baseline — зафиксированная рабочая конфигурация. Candidate — версия с проверяемым изменением. Обе запускают на одном наборе входов при одинаковых остальных условиях.
Общий pass rate нужен, но может скрыть обмен одних ошибок на другие. Например, показатель вырос с 91 до 92%, хотя новая версия исправила двенадцать кейсов и сломала восемь прежних. Два из них могут относиться к критичному сценарию. Среднее стало лучше. Выпуск — нет.
Поэтому основная единица сравнения — отдельный кейс:
| Baseline | Candidate | Интерпретация |
|---|---|---|
| pass | pass | Поведение сохранилось |
| fail | fail | Известная проблема осталась |
| fail | pass | Улучшение |
| pass | fail | Новая регрессия |
Такой анализ похож на сравнение тестовых запусков: сначала выделяется сопоставимое ядро, затем изучаются изменения одних и тех же проверок. Для промптов важны и сами переходы pass → fail, и их срезы по языку, типу запроса, инструменту и риску.
Для бинарных результатов на достаточно большом наборе подходит критерий Мак-Немара: он анализирует несовпавшие пары, где baseline и candidate дали разные вердикты. Подход описан в работе ICLR 2026 и реализован в NVIDIA NeMo Evaluator.
Статистическая значимость не заменяет инженерную оценку. Маленькая, но критическая регрессия может блокировать выпуск. И наоборот, заметное изменение на малом наборе иногда нельзя надёжно отделить от шума. В этом случае корректный вывод — INCONCLUSIVE, а не удобный PASS.
Что версионировать кроме текста промпта
Версия поведения шире Git-коммита с инструкцией. Для каждого прогона сохраняют:
prompt + model snapshot + generation parameters + tool definitions + context/retrieval + output schema + application version + dataset + graders
Так отделяются две ситуации: промпт вызвал регрессию или поведение изменилось при прежнем тексте из-за модели, контекста, инструментов либо постобработки. Git показывает, что поменяли. Конфигурационный снимок — что именно сформировало результат.
Когда изменение промпта можно выпускать
Универсального проходного балла нет. Release gate проверяет несколько независимых условий: критические кейсы не получили новых регрессий, машинные контракты проходят, семантическое качество не вышло за допустимую границу, safety-набор не выявляет ослабления ограничений, а стоимость и latency остаются в бюджете.
Результат получает один из четырёх вердиктов: PASS, WARN, BLOCK или INCONCLUSIVE. Последний означает, что данных недостаточно для решения, а не что регрессии нет.
Порог и критичные срезы определяют до прогона, а не после просмотра результата. Иначе команда подгоняет правило под желаемый выпуск. Для спорного изменения нужен ограниченный rollout, мониторинг и готовый rollback.
Если небольшое улучшение удваивает latency или объём ручного ревью, процесс тоже стал хуже. Расчёт полной стоимости разобран в статье «Как измерить эффективность AI в QA».
Как одна правка кейс исправляет и ломает два других
Рассмотрим учебный практически хрестоматийный сценарий. AI-анализатор получает результат автотеста, stack trace и данные окружения, затем выбирает одну категорию: product defect, test defect, flaky, environment или unknown.
Команда замечает, что несколько инфраструктурных ошибок остаются в unknown. В промпт добавляют требование активнее выбирать конкретную причину. На проблемном примере новая инструкция срабатывает. Затем обе версии запускают на одном regression set из двенадцати кейсов.
| Baseline | Candidate |
|---|---|
| pass → pass | 7 |
| fail → fail | 0 |
| fail → pass | 3 |
| pass → fail | 2 |
Baseline проходил 9 из 12 кейсов, candidate — 10. Средний показатель вырос с 75 до 83%, но две прежние успешные проверки теперь относят инфраструктурный сбой к дефекту продукта. Они создают ложные эскалации, поэтому для критического среза вердикт остаётся BLOCK.
Именно поэтому сравнивают переходы отдельных сценариев, а не только итоговую долю успехов. После исправления оба новых падения остаются в regression set. Как и обычный производственный инцидент, каждый пропущенный сбой должен превращаться в воспроизводимую проверку; этот цикл подробно разобран в материале «Инцидент в проде: как превратить его в регрессионный тест».
Как поддерживать regression set после выпуска
После релиза меняются запросы, интеграции, модель и инфраструктура. Поэтому regression set остаётся живым артефактом.
Рабочий цикл замыкается:production failure → новый eval case → исправление → regression run → release
Вызовы модели и evaluators выполняет eval harness. TMS не заменяет его, но может хранить тест-кейсы, план, запуски, результаты и связи с дефектами. Так сохраняется история решения о выпуске.
Перед изменением достаточно проверить шесть вещей:
- baseline-конфигурация и regression set имеют версии;
- изменяемые переменные перечислены;
- у каждого кейса есть критерий и evaluator;
- baseline и candidate получают одинаковые входы;
- отдельно разобраны pass → fail, критичные срезы, стоимость и latency;
- подготовлены rollout, мониторинг и rollback, а нехватка данных даёт INCONCLUSIVE.
Промпт может поменяться всего одной строкой. Зато потом приходится проверять поведение системы целиком.