TL;DR
Когда LLM заполняет структурированный JSON-ответ (structured output — формат, где модель обязана вернуть данные по строгой схеме полей), у неё появляется два канала инструкций одновременно: обычный текст промпта и текстовые описания внутри самой схемы (например, поле "category" может иметь описание "тип нарушения, если он есть"). Если эти два канала говорят разное — модель не складывает их вместе, а выбирает один источник, и какой именно — зависит от конкретной модели.
Проблема в том, что это выбор невидимый. Разработчик хранит правило классификации в промпте, потом обновляет описание поля в схеме — и точность может рухнуть с 100% до 73% или с 52% до 7%, при этом внешне выглядит так, будто модель просто "тупит" на задаче, хотя на деле она добросовестно выполняет инструкцию — только не ту, что ожидал автор.
Решение из исследования — два простых правила: держать определения правил в одном месте, а не дублировать между промптом и схемой (единый источник правды), и добавить в схему обязательное поле "объясни рассуждение" прямо перед полем с финальным ответом — это подняло точность на 15–24 процентных пункта там, где было куда расти.
Схема метода (два практических вывода)
ДИАГНОСТИКА КОНФЛИКТА:
Дай модели одинаковое правило в двух местах (промпт vs описание поля схемы) →
сделай их слегка противоречащими →
замерь, чья версия победила →
узнаешь, какому каналу эта модель доверяет больше
ИНТЕРВЕНЦИЯ (даёт рост точности):
Добавь в схему поле "reasoning" (рассуждение) ПЕРЕД полем с финальным ответом →
модель обязана сначала написать объяснение →
только потом заполнить итоговое поле-ответ
Оба шага выполняются в одном запросе — это не многошаговый диалог, а структура самого JSON-запроса.
Пример применения
Задача: Вы настроили в Make или Zapier автоматическую классификацию заявок с сайта через OpenAI (Structured Outputs) — бот должен раскладывать входящие обращения на категории: "жалоба", "вопрос по оплате", "заявка на возврат", "прочее". Вы прописали правила категорий и в системном промпте, и (для надёжности) продублировали их в описании поля схемы. В какой-то момент вы обновили формулировку в промпте, но забыли поправить схему — и бот начал массово путать "жалобу" с "вопросом по оплате".
Промпт (система классификации, JSON schema, фрагмент):
Системный промпт:
"Классифицируй обращение клиента по категориям:
- жалоба: клиент недоволен качеством услуги
- вопрос_по_оплате: вопросы о счетах, платежах, тарифах
- возврат: явный запрос вернуть деньги
- прочее: всё остальное"
JSON-схема (передаётся отдельно, через параметр response_format):
{
"reasoning": "Опиши шаг за шагом, к какой категории относится обращение и почему, прежде чем указать финальную категорию",
"category": "одна из: жалоба, вопрос_по_оплате, возврат, прочее"
}
Результат: Если правила в промпте и в описании схемы совпадают — модель классифицирует стабильно. Если они расходятся (например, схема осталась со старой формулировкой) — часть моделей проигнорирует промпт и последует именно тексту в схеме, и точность резко упадёт без видимой причины в логах. Добавление поля "reasoning" перед "category" заставляет модель сначала выписать логику, что заметно поднимает точность именно в схемной части — это и есть рабочий фикс, а не просто отладочная мера.
Почему это работает
LLM не хранит инструкции в единой "памяти важности" — она обрабатывает текст промпта и текст описаний полей схемы как разные потоки входных данных, и то, какой поток "весит больше", — это свойство конкретной модели, не универсальное правило. Одни модели (GPT-4.1, GPT-5.4 без режима рассуждений) больше доверяют системному промпту, другие (Claude Haiku, GPT-5.5) — сильно завязаны на схему и легко теряют точность при конфликте.
Сильная сторона LLM — она хорошо использует любую релевантную инструкцию, если её не размывает конфликтующая информация рядом. Заставить модель сначала написать промежуточное рассуждение — это классический приём "думай вслух", который здесь применён не в тексте промпта, а прямо внутри структуры JSON-ответа: модель не может просто "угадать" метку, ей нужно сначала объяснить логику, и это вынуждает её реально использовать текст описания поля, а не проскочить его.
Рычаги управления: - Дублирование правил в промпте и схеме → убери, оставь один источник правды — иначе рискуешь тихим конфликтом при любом будущем редактировании. - Порядок полей в схеме → поле-рассуждение должно стоять ДО поля-ответа, иначе эффекта не будет (модель уже "закоммитила" ответ). - Проверка на конфликт → быстрый тест (дать заведомо разные версии правила в двух местах и посмотреть, что победит) занимает меньше 100 запросов и сразу показывает, какому каналу доверяет ваша модель.
Шаблон промпта
Для тех, кто настраивает structured output через API, Custom GPT Actions или no-code сервисы (Make, Zapier, n8n) с JSON-схемой:
Системный промпт:
"{правила_и_определения_категорий}
Не дублируй эти правила в других местах — это единственный источник истины."
JSON-схема:
{
"{поле_рассуждения}": "Опиши шаг за шагом свою логику классификации, прежде чем указывать финальный ответ.",
"{поле_ответа}": "{допустимые_значения_категорий}"
}
Подставь: {правила_и_определения_категорий} — точные критерии для каждой категории; {поле_рассуждения} и {поле_ответа} — названия полей в вашей схеме, важно чтобы рассуждение шло раньше ответа; {допустимые_значения_категорий} — список меток.
🚀 Быстрый старт — вставь в чат (если работаешь через API/no-code с structured output):
Вот принцип из исследования про structured output: правила классификации нужно хранить в одном месте (не дублировать между промптом и JSON-схемой), а в схему нужно добавить поле для рассуждения перед полем с финальным ответом.
Помоги мне применить это к моей задаче: {твоя задача}.
Задавай вопросы, чтобы понять мои категории и текущую схему.
LLM спросит, где сейчас хранятся правила категорий и есть ли дублирование — потому что именно рассинхрон между промптом и схемой создаёт риск скрытого конфликта.
Ограничения
⚠️ Только для structured output: метод касается ситуаций, где модель заполняет JSON-схему через API, Custom GPT Actions или no-code интеграции. В обычном чате ChatGPT/Claude без JSON-схемы этот механизм не проявляется буквально — но принцип "не дублируй противоречащие инструкции" переносится и туда.
⚠️ Нет эффекта на потолке: если модель уже даёт 100% точность без интервенции, добавление поля-рассуждения ничего не даст — проверяй, есть ли "запас роста", прежде чем внедрять.
⚠️ Поведение модель-специфично: нельзя один раз выяснить "моя модель доверяет схеме больше промпта" и считать это универсальным правилом навсегда — при обновлении модели поведение может измениться, нужно перепроверять.
Как исследовали
Автор взяла задачу классификации коротких рабочих сообщений на 4 категории и специально дала категориям бессмысленные названия (tomil, varek, selmo, drava) — чтобы модель не могла угадать смысл категории по названию и полагалась только на данные ей определения. Затем один и тот же текст с правилами перемещался между системным промптом, пользовательским промптом и описанием поля схемы — на 10 конфигурациях моделей от OpenAI и Anthropic, каждый тест прогонялся 5 раз для надёжности.
Отдельно проверили конфликт: в промпте — правильные правила, в схеме — специально перепутанные (не случайный мусор, а определения других категорий, чтобы текст выглядел логично, но был неверным). Оказалось, что у Claude Haiku точность упала с 52,5% до 7% — модель почти полностью подчинилась неправильной схеме, игнорируя верный промпт. Это и удивило исследователей больше всего: интуитивно кажется, что системный промпт должен быть "главным", но эмпирически это не так для всех моделей.
Третий эксперимент — добавление обязательного поля "рассуждение" перед полем ответа прямо в схему, без изменения самих правил. Эффект оказался устойчивым и большим (+15–24 п.п.) там, где был запас роста, причём даже у модели с собственным встроенным режимом "размышления" — то есть выигрыш пришёл не просто от лишних вычислений, а от того, как схема организует порядок работы модели.
Ресурсы
Sin-Ying (Alina) Lin, Your Prompt Is Not the Only Prompt: How Much Do LLMs Weight Structured-Output Schema Descriptions? — Independent Researcher, препринт.