Промпт исправили, старые задачи сломались: набор проверок
Как сравнить версии промпта на фиксированных заданиях: карточка проверки, критические ошибки, таблица регрессий и независимый набор примеров.
Новый промпт лучше сокращает текст, но начал удалять условия акции. На трёх свежих примерах это незаметно: условия были простыми. На старом сложном задании ошибка возвращается. Чтобы заметить такой обмен качества заранее, нужен постоянный набор проверок.
Regression set — это сохранённые входные задания, критерии и результаты, на которых сравнивают версии. Его задача — показать, что улучшилось и что сломалось. Это проверка вывода модели; приёмка изменений AI-лендинга отдельно проверяет поведение сайта.
Соберите задания из разных условий работы
Начните с типов ошибок, которые имеют последствия: выдуманный факт, потерянное ограничение, неправильная категория, неподходящий формат. Для каждого типа сохраните вход и правило оценки. Не ограничивайте набор заданиями, на которых новая версия уже выглядит хорошо.
В руководстве Anthropic Building winning AI with Claude on Vertex AI оценка строится вокруг примеров и критериев успеха. Это поддерживает сам принцип проверяемого набора. Конкретные группы и правила ниже — авторская схема для маркетинговых задач, а не обязательный стандарт Anthropic.
- Обычные задания. Полный бриф, понятный формат, достаточно исходных фактов.
- Сокращение с обязательными ограничениями. Сроки, исключения, условия участия, которые нельзя потерять при сокращении.
- Неполные данные. Отсутствующая цена, источник или характеристика; модель должна отметить пробел, а не заполнить его выдумкой.
- Неудобный вход. Длинный текст, смешанные форматы, противоречащие друг другу версии условий.
В каждой группе нужны разные случаи. Пять почти одинаковых брифов дают меньше полезной проверки, чем пять разных причин ошибки. Число примеров зависит от разнообразия задачи; маленький набор помогает начать, но не доказывает качество на всей будущей работе.
Карточка, которую можно оценить повторно
Сохраните ID задания, версию входа, группу, ожидаемые свойства и критичность ошибок. Для открытого текста эталоном лучше делать проверяемые условия, а не единственный красивый ответ: разные формулировки могут одинаково хорошо решать задачу.
| Поле | Значение |
|---|---|
| ID | offer-missing-price-03 |
| Вход | Написать короткий анонс курса; цена не указана, старт 15 ноября, доступ три месяца |
| Обязательное | Сохранить дату старта и длительность доступа |
| Работа с пробелом | Не придумывать цену; обозначить отсутствие данных или запросить уточнение согласно задаче |
| Критическая ошибка | Добавлена выдуманная цена или изменено условие доступа |
| Вторичный критерий | Краткость и понятность анонса |
Если в одной версии промпта разрешено задавать вопрос, а в другой требуется только готовый текст, сначала согласуйте контракт задачи. Иначе сравниваются разные продукты. Общие элементы постановки описаны в разборе промпт-инжиниринга.
Сравните версии на одинаковом входе
Зафиксируйте модель, доступную версию, системные инструкции, инструменты и параметры генерации. Меняйте один объект сравнения — например, текст промпта. Если одновременно обновились модель и база знаний, результат нельзя уверенно приписать одной правке.
Сохраните полные ответы обеих версий. При вариативной генерации выполните несколько повторов на каждом задании и покажите разброс. Поддержка top-p зависит от модели; наличие параметра не означает полной воспроизводимости. Число повторов выбирайте по стоимости и важности ошибки, а не как универсальную норму.
Для человеческой оценки полезно скрыть название версии и менять порядок ответов. Автоматические проверки применяйте там, где критерий действительно формален: длина, разрешённая категория, наличие обязательного поля. Оценка моделью тоже требует проверки на примерах и не заменяет просмотр критических ошибок.
Почему общего балла недостаточно
Учебный набор содержит двадцать заданий: четыре группы по пять. В таблице показано число заданий, прошедших все критерии группы, при одном сохранённом прогоне. Это условные результаты, не измерение реальной модели.
| Группа | Старая версия | Новая версия | Вывод |
|---|---|---|---|
| Обычные задания | 5 из 5 | 5 из 5 | Без изменения |
| Неполные данные | 5 из 5 | 3 из 5 | Две новые критические ошибки |
| Сокращение с обязательными ограничениями | 2 из 5 | 5 из 5 | Улучшение |
| Неудобный формат | 4 из 5 | 5 из 5 | Улучшение |
| Всего | 16 из 20 | 18 из 20 | 90% не отменяют критическую регрессию |
До прогона можно принять правило: новые критические выдумки блокируют замену, даже если общий результат вырос. Тогда решение следует из последствий ошибки. Если правило появляется только после просмотра удобного результата, сравнение теряет независимость.
Не превращайте проверку в часть промпта
Разделите примеры для разработки и отдельный набор для финальной проверки. В руководстве scikit-learn о типичных ошибках объясняется утечка данных из тестовой части в разработку. Для промптов я применяю тот же принцип: если многократно править инструкцию по одним ответам, это уже набор разработки, а не независимая проверка.
Храните версии набора и причины добавления случаев. После обнаруженной ошибки добавьте её в рабочие проверки, а независимый набор обновляйте отдельно. Финальный отчёт должен показывать новые регрессии, исправленные случаи, непроверенные условия и принятое решение. Начать можно с одной текущей правки и нескольких сохранённых старых заданий, которые она обязана выдержать.