TL;DR
Если попросить LLM (или автоматический оптимизатор вроде GEPA, MIPROv2, TextGrad) «улучши мой промпт», точность обычно растёт. При этом промпт часто перестаёт соблюдать формат вывода. В исследовании оптимизированные промпты заставляли модель сначала рассуждать вслух, а потом выдавать JSON. Это шло вразрез с оставшейся в промпте строкой «верни только JSON и ничего больше».
Боль в том, что цифра точности выглядит отлично, а в 14–47% ответов JSON так и не появляется. Рассуждение съедает лимит длины, и ответ обрывается на полуслове. Требования про цитаты, отказ отвечать и длину модель при этом не ломала. Нарушения шли почти целиком из-за одной причины: обрезанный ответ нельзя разобрать. Метрика этого не показывает, потому что считается «мягким» извлечением ответа. Если ответ влез, он засчитан. Если не влез, он потерян.
Вывод для практика: после любой «оптимизации» промпта проверяй не только качество, но и долю ответов, которые не разбираются или обрезаны. Дай модели запас по длине вывода. При лимите 1024 токенов вместо 200 обрывы исчезли полностью, а точность выросла ещё сильнее.
Схема метода
Это не метод, а находка. Из неё следует порядок проверки:
ШАГ 1: Прогнать старый и новый промпт на одних и тех же 30–50 примерах
ШАГ 2: Посчитать долю ответов, которые НЕ разбираются (нет JSON, обрыв) → в обоих вариантах
ШАГ 3: Если у нового промпта доля выше — смотреть, не обрезан ли ответ лимитом длины
ШАГ 4: Только среди разобранных ответов сравнить соблюдение остальных требований
ШАГ 5: Повторить с большим лимитом длины и сравнить
Шаги требуют отдельных прогонов. Это ручная проверка или простая автоматизация.
Пример применения
Задача: Продавец на Ozon автоматизирует карточки товара в n8n. Модель получает описание поставщика и возвращает JSON: {"title": ..., "description": ..., "keywords": [...]}. Дальше JSON уходит в выгрузку без ручной правки. Продавец попросил Claude «улучшить промпт», чтобы тексты были продающими. Новый промпт и правда пишет лучше. Но в n8n всё чаще падает узел разбора JSON.
Промпт (для диагностики, отправляется после получения «улучшенного» промпта):
Ниже два промпта для генерации карточки товара: СТАРЫЙ и НОВЫЙ.
В обоих требуется: «верни один JSON-объект и ничего кроме него, ключи title, description, keywords; title не длиннее 60 символов».
Мой лимит ответа модели: 400 токенов. Ответ идёт в автоматический JSON-парсер.
Задача:
1. Найди в НОВОМ промпте всё, что провоцирует модель писать текст ДО JSON
(например: «сначала проанализируй», «подумай шаг за шагом», «объясни выбор»).
2. Оцени, сколько токенов такое рассуждение займёт при описании товара в 800 знаков.
Влезет ли JSON в мой лимит?
3. Предложи правку НОВОГО промпта, которая сохраняет улучшения в тексте,
но возвращает контракт вывода: только JSON, без пролога.
4. Составь чек-лист из 5 проверок для прогона на 30 карточках:
доля неразобранных ответов, доля обрезанных, соблюдение длины title,
наличие всех ключей, доля ответов с обёрткой ```json.
СТАРЫЙ ПРОМПТ:
{старый_промпт}
НОВЫЙ ПРОМПТ:
{новый_промпт}
Результат: Модель найдёт в новом промпте фразы-провокаторы рассуждения и прикинет, где они съедают лимит. Затем она предложит исправленную версию с жёстким контрактом вывода и выдаст чек-лист для прогона на тестовой выборке. Цифры по вашим данным модель оценит приблизительно. Реальную долю обрывов надо мерить прогоном.
Почему это работает
Слабость. Модель, которой велели «улучшить промпт», оптимизирует то, что ей показали: правильность ответа. Строка про формат остаётся в тексте, но на практике перевешивается. Рассуждение перед ответом повышает точность, особенно в задачах из нескольких шагов. Поэтому оптимизатор находит такие формулировки и закрепляет. Старое требование «только JSON» остаётся в промпте, но модель его не соблюдает.
Сильная сторона. Оптимизированные промпты содержательно не хуже. Цитаты, отказ при нехватке данных и длина ответа не пострадали. Поэтому проблема узкая и локальная. Это формат и бюджет длины, а не «модель стала хуже во всём».
Как использовать. Раздели проверку на две части: «ответ вообще можно разобрать» и «содержание соблюдает требования». Первую считай отдельно. Иначе одна причина (обрыв) размножается на все требования и выглядит как десять разных поломок. Исследование показывает: из 1110 новых нарушений по цитатам 1092 были обрывами.
Рычаги: - Лимит длины вывода. Подними, если в промпте появилось «сначала рассуждай». Так обрывы исчезают. - Строгость разбора. Мягкий разбор (вытащить JSON из текста) скрывает проблему в метрике, но ломает строгий автоматический потребитель. - Размер выборки для проверки. При 30–50 примерах заметна только крупная поломка. Мелкие эффекты на малой выборке не видны.
Шаблон промпта
Улучши мой промпт, но сохрани контракт вывода.
КОНТРАКТ ВЫВОДА (нельзя нарушать):
- Формат: {формат_вывода}
- Обязательные поля: {поля}
- Ограничения: {длина, цитаты, отказ при нехватке данных и т.п.}
- Лимит ответа: {лимит_токенов} токенов
- Потребитель ответа: {парсер / человек / другая автоматизация}
ЗАПРЕЩЕНО в улучшенной версии:
- просить модель рассуждать или объяснять ДО итогового ответа,
если это не предусмотрено форматом;
- убирать или смягчать любое требование из контракта.
Если рассуждение нужно для качества — предложи отдельное поле внутри формата
{поле_для_рассуждения} и пересчитай, влезает ли ответ в лимит.
ИСХОДНЫЙ ПРОМПТ:
{промпт}
Верни: 1) улучшенный промпт; 2) список изменений; 3) какие требования контракта
могут пострадать и как это проверить на {число} примерах.
Подставь формат (JSON, таблица, ровно три пункта), поля, ограничения, лимит токенов из настроек и тип потребителя. От потребителя зависит строгость: парсер в автоматизации не прощает ни пролога, ни обёртки.
Шаблон — практическая адаптация вывода статьи, а не готовый промпт из исследования. Сами авторы промптов для читателя не дают.
Ограничения
⚠️ Одно семейство моделей: все запуски шли на Claude (Haiku 4.5 как исполнитель, Sonnet как автор правок). Склонность писать рассуждение перед структурным ответом на других моделях может быть другой.
⚠️ Основной эффект держится на одной задаче: заметные нарушения были только на HotpotQA (вопросы из нескольких шагов). На SQuAD 2.0 нарушений нет, а IFEval почти не дал прироста.
⚠️ Лимит 200 токенов задан жёстко: результат «ломается» именно при нём. Это не типичный лимит для чата, зато типичный для дешёвых автоматизаций.
⚠️ Объяснение про обрывы — разбор после опыта: разложение на «обрыв» и «содержание» и проверка с лимитом 1024 токена проводились уже после основных запусков, а не планировались заранее. Значимость для них не считали.
⚠️ Малая выборка запусков: по три прогона на оптимизатор, мало исследованных вариантов промпта. Мелкие эффекты (до ~15 пунктов) такая схема не заметила бы.
⚠️ Простые «защитные» фильтры не помогли: проверка кандидатов перед выбором отклонила все варианты на HotpotQA и вернула старый промпт без прироста. Штраф за нарушение внутри оптимизации помогал формату, но снижал точность.
⚠️ Влияние самого рассуждения не изолировали: авторы не проверяли, даёт ли прирост именно рассуждение вслух. Это предположение.
Как исследовали
Команда взяла три популярных автооптимизатора промптов (GEPA, MIPROv2, TextGrad) и три открытых набора задач: вопросы из нескольких шагов (HotpotQA), вопросы по тексту (SQuAD 2.0) и выполнение инструкций (IFEval). В стартовый промпт вложили четыре требования: формат JSON, цитаты, отказ при нехватке данных и длина ответа до 20 слов. Оптимизатору показывали только точность ответа. Остальное проверялось детерминированным кодом, без людей и без LLM-судей.
Всего получилось 54 запуска оптимизации и около 33 тысяч ответов. Для каждого примера сравнивали старый и новый промпт: что стало нарушением, а что починилось. Заранее зафиксированные гипотезы формально подтвердились. На HotpotQA точность выросла на 21–34 пункта, а соблюдение цитат упало на 11–42 пункта.
Удивило объяснение. Почти все «нарушения» оказались обрывами: новые промпты заставляли модель рассуждать вслух, и при лимите 200 токенов JSON просто не появлялся. Каждый из 1629 неразобранных ответов имел длину ровно 200 токенов. Среди разобранных ответов регрессий нет. При лимите 1024 токена обрывы исчезли, точность выросла ещё (лучший вариант: 0,19 → 0,64), а содержательные нарушения остались ниже 1 пункта.
Практический инсайт: «оптимизированный» промпт не ломает смысл, но ломает контракт вывода. Цена этой поломки зависит от параметра, который метрика не видит, то есть от лимита длины.
Адаптации и экстраполяции
🔧 Техника: пустить рассуждение внутрь формата → вернуть контракт без потери качества
Вместо «сначала подумай, потом выдай JSON» добавь в схему поле рассуждения перед ответом:
{"reasoning": "кратко, до 40 слов", "answer": "...", "citations": [...]}и в промпте: «Рассуждение пиши только в поле reasoning. Вне JSON ничего не выводи».
Идея не из статьи, авторы её не проверяли. Она следует из их наблюдения: модели хочется рассуждать до ответа, поэтому ей стоит дать место для рассуждения внутри формата. Проверь на 30 примерах, как ведут себя доля разобранных ответов и точность.
Ресурсы
- Работа: Do Prompt Optimizers Break Requirements They Are Not Scored On? A Preregistered Study — Sangdo Han, Moonsoo Kim (CEO Business School, Корея).
- Оптимизаторы: GEPA (Agrawal и др., ICLR 2026), MIPROv2 (DSPy, Khattab и др.), TextGrad (Yuksekgonul и др.).
- Данные: HotpotQA, SQuAD 2.0, IFEval.
- Близкие работы: PrefPO (Singhal и др., 2026) о «гигиене» и «взломе» оптимизированных промптов; Tam и др. (2024) о падении качества рассуждений при строгом формате; Hochlehnert и др. (2025) о чувствительности точности к лимиту вывода.