Как проверить, не ломает ли изменение промпта ответы LLM
Новая формулировка системной инструкции может исправить один заметный сбой и незаметно ухудшить десятки других ответов. Чтобы проверить изменение промпта LLM до выкладки, сравните старую и новую версии на одном фиксированном наборе примеров: с одинаковыми входными данными, критериями оценки и, насколько возможно, параметрами модели.
Такой тест не доказывает, что промпт будет работать на всех будущих запросах. Он помогает обнаружить регрессии на известных сценариях и сделать решение о замене версии проверяемым. Подход подходит для классификаторов, извлечения полей, поддержки клиентов и других задач, где можно описать ожидаемое поведение.
Сначала определите, что именно должно улучшиться
Не начинайте с метрики вроде «ответ стал лучше». Запишите конкретную проблему и желаемое изменение поведения. Например: «модель должна спрашивать уточнение, если в заявке нет даты», а не «модель должна быть аккуратнее».
Затем разделите критерии на две группы:
- обязательные условия — например, ответ соответствует JSON-схеме, не содержит выдуманного идентификатора и не раскрывает данные, которых нет во входе;
- качество ответа — полнота, полезность, тон, точность формулировки.
Обязательные условия удобно проверять автоматическими тестами, если они формализуемы. Качество ответа иногда требует оценки человеком или отдельным оценщиком. В документации OpenAI evals и graders описаны как способы задать критерии и систематически оценивать ответы; Anthropic также рекомендует заранее определять признаки успешного результата для конкретной задачи.
Критерии нужно зафиксировать до просмотра результатов новой версии. Иначе легко невольно подобрать оценку под ожидаемый эффект.
Соберите тестовые случаи из реальных запросов и ошибок
Набор должен отражать не только типичный запрос, но и ситуации, в которых промпт чаще всего ошибается. Для помощника по заявкам это могут быть:
полный запрос со всеми нужными полями;
отсутствующая дата или другая обязательная информация;
3. противоречивые сведения;
4. лишний текст рядом с нужными данными;
5. опечатки, нестандартный порядок полей или короткие ответы;
6. запрос вне области задачи;
7. попытка заставить модель нарушить заданный формат.
Для каждого случая сохраните вход и критерии результата. Если нужен конкретный ответ, добавьте эталон. Если допустимы разные формулировки, оценивайте свойства: например, «задаёт вопрос о дате» или «не заполняет отсутствующее поле догадкой».
Начните с небольшого набора, который команда может вручную проверить, а затем расширяйте его по мере появления новых ошибок. Размер сам по себе не гарантирует качества: тысяча почти одинаковых примеров может хуже выявлять проблемы, чем несколько десятков разнообразных и тщательно отобранных случаев.
Зафиксируйте условия честного сравнения
Прогоните обе версии на одинаковых входах и сохраните результаты. Помимо текста промпта, запишите модель и её версию, системные параметры, инструменты и формат вывода. Если изменились одновременно промпт, модель и параметры генерации, нельзя уверенно приписать результат одной только правке инструкции.
Для модели с вероятностной генерацией полезно зафиксировать доступные параметры, например температуру, и повторять отдельные тесты несколько раз, если ответы заметно варьируются. Повторные прогоны помогают увидеть нестабильность, но не превращают небольшой тестовый набор в гарантию качества.
Практический формат данных может выглядеть так:
json
{
«id»: «missing-date»,
«input»: «Создайте заявку на замену пропуска для сотрудника Анны.»,
«checks»: {
«asks_for_date»: true,
«does_not_invent_date»: true
}
}
В таблице или тестовом файле храните идентификатор случая, вход, ожидаемые свойства, ответ старой версии, ответ новой версии и результат каждой проверки. Не включайте в тестовые данные секреты и персональную информацию, если они не нужны для задачи.
Проверяйте формат отдельно от смысла
Если модель должна возвращать JSON, сначала проверьте, что ответ разбирается и соответствует схеме. Затем проверьте содержимое: обязательные поля заполнены корректно, пустые значения обработаны по правилам, а данные не придуманы.
Эти проверки отвечают на разные вопросы. Валидный JSON может содержать неверный ответ; полезный текст может нарушать контракт интеграции. Поэтому не объединяйте их в одну оценку «прошёл/не прошёл».
Утилиты для тестирования промптов, например Promptfoo, позволяют описывать входные тесты и проверки ожидаемых результатов. Можно начать и без отдельного фреймворка: небольшой скрипт, который запускает обе версии, проверяет схему и сохраняет ответы, уже обеспечивает воспроизводимый базовый регрессионный тест. Важнее хранить версии тестовых данных и критериев вместе с изменениями промпта.
Сравнивайте ответы по критериям, а не по впечатлению
Для каждого случая посчитайте, прошли ли обязательные проверки. Полезно отдельно свести:
- долю ответов, прошедших форматные и логические проверки;
- ошибки по каждому критерию;
- новые ошибки, которых не было у прежнего промпта;
- случаи, где новая версия улучшила результат;
- случаи, где ответы меняются между повторными запусками.
Пример: старая версия правильно обрабатывает 18 из 20 случаев, новая — 19 из 20. Это ещё не обязательно означает улучшение: нужно посмотреть, какой именно случай исправлен и не стала ли новая версия нарушать критичное правило в оставшемся примере.
Для субъективных критериев сравнивайте ответы вслепую: оценщик видит вход и два ответа, но не знает, какой из них создан новой версией. Используйте короткую шкалу с описанными границами, например 0 — критерий не выполнен, 1 — выполнен частично, 2 — выполнен. Для спорных случаев сохраняйте обоснование и периодически проверяйте автоматические оценки человеком.
Оценщик на основе LLM тоже может ошибаться или предпочитать более длинный и уверенный текст. Не используйте его единственным судьёй для высокорисковых решений; сверяйте результаты с ручной оценкой и явными проверками там, где они возможны.
Установите порог, который блокирует регрессию
До запуска теста решите, какое ухудшение недопустимо. Например, можно запретить выпуск, если новая версия нарушает хотя бы одно обязательное условие безопасности или теряет корректность в ключевом сценарии. Для менее критичных критериев допустим порог по доле ошибок — но его нужно выбирать исходя из последствий ошибки, а не подгонять под удачный результат.
Не сводите всё к среднему баллу. Если промпт отвечает за извлечение суммы или маршрутизацию обращения, единичный сбой в конкретном важном сценарии может быть существеннее небольшого прироста средней оценки.
При небольшом наборе результаты следует трактовать как сигнал, а не точную оценку будущего качества. Разделите примеры по типам случаев и смотрите, где именно меняется поведение. Если новые данные похожи на те, что использовались при правке промпта, добавьте отдельные проверочные примеры, которые не участвовали в настройке.
Разберите каждый изменившийся ответ
После автоматической сводки вручную изучите все новые ошибки и несколько случаев, где результат изменился, но формально прошёл проверки. Уточните, чем вызвано изменение: новой инструкцией, нестабильностью генерации, несовпадением теста с реальным запросом или слишком расплывчатым критерием.
Если тест обнаружил ошибку, добавьте её как отдельный регрессионный случай. Не удаляйте неудобный пример только потому, что после очередной правки он мешает пройти тест. Если критерий оказался неправильным, обновите его с пояснением и повторно оцените обе версии.
Так тестовый набор становится историей известных отказов, а не коллекцией примеров, выбранных для демонстрации успеха.
Что сохранить перед заменой промпта
Для воспроизводимой проверки достаточно хранить версии промпта, модели и параметров запуска; входы и ожидаемые свойства; ответы; результаты проверок; дату прогона и причину изменения. Если провайдер меняет модель под тем же именем, повторный запуск прежнего набора поможет обнаружить изменение поведения, но не всегда позволит определить его причину без дополнительных данных о версии модели.
Перед выкладкой проверьте, что тесты покрывают главную причину изменения, обязательные ограничения не ухудшились, а новые ошибки просмотрены человеком. После выкладки следите за реальными сбоями и добавляйте характерные случаи в набор. Это не заменяет мониторинг: тесты проверяют известные сценарии, а эксплуатация приносит новые.
