Локальный редактор промптов: как тестировать версии

Промпт в рабочем процессе ведёт себя скорее как конфигурация программы, чем как обычная заметка. Одно добавленное предложение может убрать выдуманные факты, но сломать формат письма или увеличить ответ вдвое. Поэтому локальный редактор промптов полезен не ради красивого окна, а ради дисциплины: каждая версия хранится отдельно, запускается на одинаковых примерах и имеет понятную причину выпуска.

Опишите задачу до текста инструкции

Начните с карточки процесса. Запишите, кто даёт вход, что должна вернуть модель, какие поля обязательны и где решение принимает человек. Для письма клиенту это может быть тема, короткий ответ и следующий шаг; для классификатора — метка, уверенность и объяснение. Отдельно перечислите запреты: нельзя обещать срок без подтверждения, раскрывать персональные данные или менять числа.

Такая карточка не даёт редактору превратить промпт в бесконечный список пожеланий. Если новое правило не связано с измеримым результатом, его лучше вынести в инструкцию оператору или в проверку после ответа.

Формат записи версии

Храните промпт и его окружение в одной записи. В ней нужны название задачи, текст системной инструкции, список переменных, модель, параметры запуска, автор и дата. Эталонный ответ держите отдельным файлом, чтобы его нельзя было незаметно переписать вместе с промптом.

task: письмо после обращения в поддержку
prompt_version: 0.7
model: версия из рабочего контура
temperature: 0.2
fixture_set: fixtures/support-v3.json
required: тема, ответ, следующий шаг
changed_by: редактор
changed_at: 2026-09-04

В репозитории редактора не должно быть реальных имён, телефонов, переписок и ключей API. Используйте вымышленные значения с той же длиной и структурой, что и в рабочем входе. Секреты передавайте через переменные окружения, а в журнале отмечайте только название переменной.

Соберите разнообразный тестовый набор

Один удачный пример ничего не доказывает. Включите короткий и длинный запрос, пропущенное поле, конфликтующие требования, опечатки, неуместный тон и случай, когда правильного ответа нет. Для каждого примера зафиксируйте обязательные элементы и недопустимые действия. В письме без указанной скидки модель не должна придумывать размер скидки; в сводке без даты — не должна выдавать её как факт.

Разделите набор на рабочую и контрольную части. Рабочая используется во время редактирования, контрольная открывается только после выбора кандидата. Иначе легко подогнать правило под знакомые фразы и принять случайное улучшение за устойчивый результат. Набор обновляйте новыми ошибками, но не удаляйте старые: они показывают, какую проблему вы уже научились ловить.

Меняйте одну вещь за раз

В описании коммита или версии напишите одно изменение и ожидаемый эффект: «запретить неподтверждённые сроки» или «разрешить таблицу из трёх колонок». Не переписывайте одновременно тон, формат и правила фактов. Иначе при ухудшении вы не поймёте, какая правка его вызвала.

Сравнивайте не длину промпта, а поведение. Для каждой версии отметьте фактическую точность, полноту, формат, тон, соблюдение ограничений и количество ручных исправлений. Ответ сохраняйте до редакторской правки; иначе вы будете сравнивать работу модели с работу человека.

Запускайте две стадии сравнения

Сначала прогоните обе версии на рабочем наборе. Зафиксируйте время, стоимость вызова и все существенные расхождения. Затем повторите запуск на контрольных примерах. Кандидат принимается только если он не ухудшает контрольные случаи; преимущество на пяти знакомых запросах недостаточно.

Если модель отвечает непредсказуемо, проведите несколько прогонов с одинаковыми параметрами и запишите разброс. Через сутки повторите короткий тест: обновление модели или изменение контекста иногда меняет результат без изменения текста промпта. Результаты удобно хранить в таблице с колонками «версия», «пример», «оценка», «ошибка», «решение».

Откат должен занимать минуту

Активную версию храните отдельным идентификатором, а черновик — рядом. Публикация меняет только этот идентификатор; не копируйте длинную инструкцию вручную в несколько сервисов. В журнале запускайте запись номера версии, модели и набора примеров. Если после выпуска выросло число исправлений, появились запрещённые формулировки или нарушился формат, переключитесь на предыдущий идентификатор и запишите причину.

Не удаляйте неудачные версии. Они объясняют, какое правило вызвало регрессию, и экономят время при следующем эксперименте. Для крупных изменений добавьте срок пересмотра и владельца, чтобы устаревшая инструкция не продолжала работать годами.

Пример изменения с проверкой границ

Допустим, модель иногда вставляет в письмо неподтверждённую скидку. Добавьте одно правило: «Называй скидку только при наличии поля discount в JSON; если поля нет, сообщи, что скидка не определена». Проверьте четыре случая: поле содержит число, равно нулю, отсутствует или содержит текст. Отдельно убедитесь, что тон и структура письма не изменились. Если одно из условий не выдержано, версия возвращается в черновик.

Приватность и обслуживание

Локальное хранение уменьшает количество передач, но не отменяет права доступа и резервные копии. Ограничьте каталог редактора, исключите его из публичной синхронизации и удаляйте старые тестовые входы по регламенту. После изменения модели, системных ограничений или тарифа прогоняйте набор заново. Выборочно проверяйте реальные ответы после выпуска: тестовые фикстуры не отражают всех странных формулировок пользователей.

Чек-лист публикации

1. Цель версии сформулирована одной фразой.
2. Рабочие и контрольные примеры разделены.
3. Сохранён необработанный ответ и параметры запуска.
4. Проверены факты, формат, тон, границы и стоимость.
5. Кандидат прошёл повторный прогон на контрольной выборке.
6. Предыдущая версия доступна одним переключением.
7. В журнале есть автор, дата, модель и причина решения.

Ежедневная проверка после выпуска

После публикации версии выберите два новых обезличенных входа и один старый контрольный пример. Сравните необработанный ответ с эталоном, отметьте лишние утверждения и проверьте, что активный идентификатор версии совпадает в журнале и интерфейсе. Если появилась ошибка, сначала зафиксируйте вход и откатите версию, а не переписывайте промпт прямо в рабочем поле.

Такой короткий прогон занимает минуты, но показывает регрессию раньше большого отчёта. Раз в неделю просматривайте причины ручных исправлений и превращайте повторяющиеся случаи в новые контрольные фикстуры. Это поддерживает редактор в рабочем состоянии и не даёт тестовому набору застыть.

Локальный редактор превращает спор «кажется, стало лучше» в проверяемый эксперимент. Он не обещает идеальных ответов, зато показывает, какая инструкция работала, на каких данных и почему её можно принять или отклонить.