Промпт для улучшения промпта помогает исправить конкретный сбой уже работающего запроса: покажите исходный текст, желаемый ответ и провальный пример. Сохраняйте обе версии и сравнивайте их на одинаковых входных данных; красивый ответ самой модели служит лишь гипотезой.
Точка отсчёта
Рабочая единица проверки — пара версий промпта и один общий набор тестовых входов с ожидаемыми ответами.
Сначала заморозьте текущий промпт как версию А. Скопируйте его целиком в отдельный документ, сохраните системные настройки, формат входа и примеры. Без этой копии правка превращается в спор о памяти: участники команды сравнивают разные исходные условия. В генерации нового промпта модель начинает с задачи. Здесь исходный текст уже есть, и задача состоит в локальном ремонте.
Выберите сбой, который можно увидеть в ответе: потерян артикул, выдумана причина отказа, нарушен формат таблицы. Для каждого входа запишите ожидаемый результат и цену ошибки для процесса. Ошибка в вежливости письма и ошибка в сумме счёта требуют разных критериев приёмки. Полезен небольшой набор обычных, пограничных и заведомо сложных примеров. Примеры возьмите из обезличенной рабочей очереди либо придумайте явно условные.
Для модели можно выбрать GigaChat или YandexGPT, если команда уже работает в соответствующем контуре. При сравнении держите одну и ту же модель и настройки генерации. Смена модели вместе с правкой текста смешает причины улучшения. Для общей структуры запроса пригодится разбор правил промптинга, а здесь важна измеримая разница версий.
Сразу обозначьте, кто признаёт ответ правильным: автор запроса, сотрудник поддержки или владелец процесса. Иначе у редакторов появятся разные критерии для одной ошибки.
Текст мета-запроса
Скопируйте этот запрос в чат вместе с исходным промптом и тестовыми примерами. Разделители между блоками оставляйте явными: модель должна отличать инструкцию от данных. Секреты, клиентские имена и персональные данные замените условными значениями до вставки. В рабочем процессе полезно хранить шаблон в библиотеке команды, чтобы редакторы промптов пользовались одной схемой разбора.
«Ты редактор существующего промпта. Цель: устранить перечисленные сбои при сохранении полезного поведения. Исходный промпт: [текст]. Ожидаемый ответ: [формат и критерии]. Входы и ошибки: [примеры]. Сначала назови вероятную причину каждого сбоя со ссылкой на строку исходной инструкции. Затем предложи минимальную правку: покажи удалённые и добавленные фразы. Отдельно перечисли возможные побочные эффекты. Верни полный промпт версии Б и план проверки на тех же входах. Если данных мало, сформулируй вопросы для редактора».
Просите модель показать именно изменённые строки, а полный текст держите для копирования после ревью. Большой переписанный запрос часто выглядит убедительнее, хотя причина ошибки остаётся. Хорошая правка касается формата, приоритета правил или обработки исключения. Если модель предлагает новые факты о бизнесе, удалите их: промпт задаёт поведение, факты приходят из утверждённого источника.
- Скопируйте исходный запрос без редакторских исправлений и присвойте ему версию А.
- Добавьте желаемый формат, провальный ответ и вход, который вызвал сбой.
- Получите правку строк, полный текст версии Б и перечень возможных побочных эффектов.
Проверка до правки
Прогоните версию А на сохранённом наборе входов. Для каждого ответа фиксируйте результат по короткой шкале: выполнен формат, сохранены факты, корректно обработано исключение. Запишите время ручной доводки либо число исправлений человеком; такой журнал точнее общей оценки «стало лучше». При длинных ответах оцените ещё объём вывода, поскольку многословный промпт может увеличить расход токенов без прироста точности.
Далее запускайте версию Б на тех же входах. Сравнивать два случайных диалога бессмысленно: различие может идти от входного текста, вне связи с вашей правкой. Если интерфейс сохраняет контекст беседы, создайте отдельные чистые сессии. В автоматическом процессе зафиксируйте настройки вызова и повторите проверки при следующем изменении модели или источника данных. Сведения о тарифах смотрите на странице цены выбранного вендора; стоимость работы редактора и разработки обсуждается отдельно.
Перед передачей шаблона коллегам проверьте самый дорогой тип ошибки, даже если общая доля верных ответов выросла. Команде, которая регулярно редактирует такие инструкции, поможет обучение сотрудников работе с ИИ с разбором собственных тестов. Проверка покажет, какие ошибки требуют решения человека.
Покажите команде именно тот сбой, который остался после сравнения версий.
Хотите разобрать повторяющийся сбой вашего промпта?
| Показатель | Версия А | Версия Б |
|---|---|---|
| Формат | Отметьте нарушения | Сравните на тех же входах |
| Факты | Запишите подмены | Проверьте исчезновение ошибок |
| Ручная правка | Считайте исправления | Сравните объём работы |
Локальная правка
Если версия Б улучшила обычные случаи, но испортила крайний, вернитесь к конкретной строке. Например, инструкция «отвечай кратко» может скрыть обязательное объяснение отказа. Добавьте условие для ответа с отказом, сохранив остальное. Этот подход даёт понятную историю изменений и облегчает откат. Правка всего промпта за один заход мешает понять, какое правило сработало.
Оформите протокол для коллег: идентификатор версии, дата, причина, примеры входа, наблюдаемые ошибки и решение ответственного. Если промпт встроен в n8n или другой сценарий, храните версию рядом с настройками сценария. В тестовом запуске передавайте только копии сообщений, без отправки клиентам. Затем проведите ручное ревью спорных ответов и лишь после него меняйте рабочую версию.
Отдельно посмотрите на конфликт инструкций. Системное правило требует краткости, пользовательский текст просит подробный отчёт, а входные данные содержат фразу с командой изменить роль. Для промпта это разные уровни доверия. Укажите, что цитаты и загруженные документы служат материалом для анализа, и лишены силы новых распоряжений. Такой приём особенно нужен в запросах, где модель читает письма клиентов или документы подрядчиков.
Возьмите один известный сбой и внесите одну проверяемую правку. Отдельный журнал покажет, какая формулировка действительно изменила ответ.
Для отката достаточно вернуть сохранённый текст и настройки версии А. Запишите повод возврата в журнал, чтобы та же ошибка снова попала в обязательные тесты.
Критерий выпуска
Публикуйте новую версию только после просмотра всех обязательных тестов человеком, который отвечает за результат процесса. Считайте успехом исчезновение целевого сбоя при сохранении формата и фактов в остальных примерах. Одна удачная демонстрация в чате годится для гипотезы, но для рабочего сценария нужна повторяемая проверка. Отметьте случаи, где модель честно сообщает о нехватке данных: это полезнее уверенной догадки.
Если результаты смешанные, разделите задачу. Один промпт может пытаться одновременно извлечь данные, оценить риск и написать письмо. Для проверки удобнее отдельные этапы с собственными входом и выходом. Анализируйте, на каком этапе появились потери; уже потом меняйте инструкцию этого этапа. В материале о создании промптов показан старт с чистого листа, а такой разбор сохраняет накопленные правила команды.
После выпуска оставьте контрольные примеры в регрессионном наборе. Новые жалобы пользователей сначала классифицируйте: пробел в данных, сбой формата, неверный приоритет инструкции либо чрезмерное обобщение. Так редактор получает конкретный вход для следующей версии. Промпт остаётся рабочим инструментом с историей решений и контрольными примерами.
Полезно назначить владельца регрессионного набора: он добавляет в него новые ошибки после разбора обращений и удаляет устаревшие примеры только с объяснением. Если промпт используют несколько отделов, храните общие правила отдельно от локальных настроек формата. Тогда изменение для одного отдела сохраняет работу другого. По журналу версий можно увидеть, какая правка вызвала отклонение, и быстро вернуть последнюю рабочую формулировку. Качество определяйте по проверенным ответам пользователю; самооценка модели для этого недостаточна.