TL;DR
Reasoning-first — правило для структурированных ответов (JSON, XML): поле с рассуждением ставь раньше поля с ответом. Модель пишет текст слева направо и не может вернуться назад. Если рассуждение идёт первым, ответ опирается на него. Если первым идёт ответ, рассуждение пишется уже после него.
«Налог на структуру» (падение точности из-за JSON/XML) оказался не свойством структуры, а следствием порядка полей. Типичная схема «оцени и дай обоснование» ставит ответ первым. Модель выдаёт вердикт «с ходу», а потом подгоняет под него объяснение. На многошаговых задачах это ломает результат: на арифметике точность упала с ~85% до ~11% у небольших моделей. У сильных моделей падение мягче, но заметное: GPT-4o потерял около 40 пунктов относительно обычного ответа. Если рассуждение идёт первым, точность равна свободному ответу или выше.
Метод — один шаг в одном промпте: задай схему, где сначала поле , потом . Теги XML в среднем работали лучше, чем JSON-ключи.
Схема метода
ШАГ 1: Поле — модель рассуждает по шагам → текст
ШАГ 2: Поле — модель фиксирует итог → короткий ответ
⚠️ Порядок обязателен: reasoning СТРОГО до answer.
Всё в одном промпте. Отдельных запросов не нужно.
Пример применения
Задача: Владелец магазина на Wildberries собрал автоматизацию в n8n. Модель считает итоговую маржу по товару с учётом комиссии маркетплейса, логистики, скидки по акции и возвратов. Это арифметика в несколько шагов. Раньше промпт просил {"маржа_руб": ..., "пояснение": ...}, то есть ответ шёл первым, и цифры «плавали».
Промпт:
Ты считаешь юнит-экономику товара на Wildberries.
Данные:
- Закупка: 640 ₽
- Цена на витрине до скидки: 1 990 ₽
- Скидка по акции: 25%
- Комиссия WB: 19% от цены после скидки
- Логистика до клиента: 62 ₽
- Выкуп: 85% (на возвраты тратится 50 ₽ за каждый возврат)
Верни ответ строго в XML. Порядок тегов обязателен:
Считай по шагам: цена после скидки, комиссия, логистика,
потери на возвратах, маржа на единицу. Показывай каждое действие.
Маржа на одну проданную единицу в рублях, одно число.
Пиши только после того, как закончил .
Результат: Модель сначала выпишет пошаговый расчёт: цену со скидкой, комиссию, логистику, возвраты. После этого она выдаст в одно число. Это число следует из выкладки выше, а не угадано до неё. Автоматизации достаточно вытащить содержимое тега , а можно сохранить для проверки.
Почему это работает
Слабость. Модель генерирует текст по одному фрагменту и каждый следующий опирает только на уже написанное. Если в схеме первым стоит "answer", она должна назвать итог до всякого рассуждения. Потом поле с обоснованием может только оправдать выбор. Авторы выделили два режима отказа. Первый — рационализация: на тестах с выбором ответа обоснование сжимается до короткой отговорки (33 слова против 121 при правильном порядке). Второй — преждевременная фиксация: на арифметике модель пишет столько же текста, но расчёт уже не может изменить зафиксированный ответ.
Сильная сторона. Модель хорошо рассуждает по шагам, когда ей дают на это место перед ответом. Это старый принцип Chain-of-Thought, но здесь он работает внутри схемы.
Как метод это использует. Порядок полей превращает схему в принудительный Chain-of-Thought. Ответ формируется после рассуждения. Теги XML дополнительно чётко отделяют «думаю» от «отвечаю».
Рычаги управления:
- Порядок полей — главный рычаг. Меняй его первым, если точность проседает.
- XML вместо JSON → в среднем чуть надёжнее. Теги лучше размечают переход от рассуждения к ответу. Разрыв доходил до 12 пунктов.
- Инструкция внутри («считай по шагам», «проверь условия») → управляет глубиной рассуждения.
- Удаление из итога → оставляй поле в ответе модели, но не показывай клиенту. Парсь только .
- Простые структурные задачи (например, SQL) → порядок почти не влияет, можно не усложнять.
Шаблон промпта
{описание_задачи_и_роли}
Данные:
{входные_данные}
Верни ответ строго в XML. Порядок тегов обязателен:
{как_рассуждать: по шагам, какие условия проверить}
{формат_итогового_ответа: одно число / да-нет / метка / короткий вывод}
Пиши только после того, как закончил .
Не пиши ничего вне этих тегов.
Что подставлять:
- {описание_задачи_и_роли} — что модель решает.
- {входные_данные} — исходные цифры, текст, условия.
- {как_рассуждать} — подсказка по шагам. Для арифметики: «выпиши каждое действие».
- {формат_итогового_ответа} — как должен выглядеть итог, чтобы его удобно разбирать.
🚀 Быстрый старт — вставь в чат:
Вот шаблон reasoning-first (рассуждение до ответа). Адаптируй под мою задачу: [твоя задача].
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит, какие входные данные у тебя есть, какого вида должен быть итоговый ответ и какие шаги рассуждения нужны. Это нужно, чтобы правильно заполнить и . Порядок тегов она сохранит из шаблона.
Ограничения
⚠️ Задачи с жёсткой собственной структурой: на генерации SQL порядок полей почти не влияет, а XML-обёртка иногда даже мешает. Там свободный ответ остаётся конкурентным.
⚠️ Не подменяет знания: формат заставляет модель рассуждать по порядку, но не даёт ей недостающих фактов. На вопросах по знаниям (MMLU) выигрыш скромнее, чем на логике.
⚠️ Не универсально у каждой модели: встречались аномалии. Claude Sonnet 4.5 на арифметике справился с JSON при «ответ первым» (96%), хотя в XML с тем же порядком упал до 62%. На логических задачах JSON с правильным порядком у него оказался заметно хуже обычного ответа. Проверяй на своей модели.
⚠️ Маленькие модели хрупче: у моделей на 4–8 млрд параметров обвал при неверном порядке полей почти полный и разброс между запусками выше.
⚠️ Самооценка уверенности слабая: XML в среднем улучшает калибровку (согласованность названной уверенности и реальной точности). Но способность отличить правильный ответ от неправильного по числу «уверенность от 1 до 10» остаётся низкой. Не строй на таком числе жёсткие решения. У малых моделей оно ближе к эвристике, чем к настоящей неуверенности.
⚠️ Не проверены модели с встроенным «мышлением»: тестировали GPT-4o, Gemini Flash 2.0, Claude Sonnet 4.5 (обычный режим) и две малые открытые модели. Как это работает с reasoning-режимами, статья не показывает.
Как исследовали
Команда PayPal задала вопрос: налог на структуру — это приговор любому JSON/XML или следствие ошибки в проектировании схемы? Они взяли пять моделей (GPT-4o, Gemini Flash 2.0, Claude Sonnet 4.5, Llama-3.1-8B, Gemma3-4B) и четыре набора задач. Наборы шли от жёстко структурных (генерация SQL) до слабоструктурных (вопросы на знания, логика), с арифметикой посередине. Каждую модель прогнали в пяти форматах: свободный текст, JSON и XML с ответом первым, JSON и XML с рассуждением первым. Каждый эксперимент повторили по пять раз.
Рассуждение первым выиграло в 13 из 20 пар «модель–задача» и нигде не проваливалось там, где побеждал другой порядок. Самый резкий провал был на арифметике: у двух малых моделей XML с ответом первым дал около 11% против 83–87% при правильном порядке. Чтобы проверить, не артефакт ли это формулировки, авторы меняли текст инструкции, регистр ключей и пробелы: разрыв остался минимум в 37 пунктов во всех 24 комбинациях.
Затем авторы заглянули внутрь двух открытых моделей. Они проверяли, готова ли модель к ответу ещё на этапе рассуждения. При порядке «рассуждение → ответ» ответ распознавался во внутренних слоях модели, при «ответ → рассуждение» — нет. Это объясняет механику: модель называет букву без внутренней подготовки.
Практический инсайт: эффект тем сильнее, чем меньше сама задача диктует структуру. Для арифметики и логики порядок критичен, для SQL почти безразличен.
Оригинал из исследования
Полные шаблоны промптов статья выносит в Приложение A.1, в предоставленном тексте его нет. Из основного текста известна лишь общая схема.
Reasoning-first (R,A): ... затем ...
Answer-first (A,R): "answer": "...", затем "reasoning": "..." (JSON)
... , затем ... (XML)
Контекст: это условия сравнения на рисунке 1: один вопрос по анатомии из MMLU решался в трёх форматах. Свободный текст и reasoning-first XML дали верный ответ D, answer-first JSON — неверный A.
Адаптации и экстраполяции
💡 Адаптация для LLM-судьи и оценщика: привычная формулировка «оцени и обоснуй» ставит вердикт первым. Переверни порядок.
Оцени ответ менеджера поддержки на соответствие регламенту.
Верни XML. Порядок обязателен:
Пройди по каждому пункту регламента, найди нарушения, процитируй фрагменты.
соответствует / не соответствует
🔧 Техника: убрать вердикт из первой строки чата → меньше «подгонки». Даже без XML добавь в промпт: «Сначала разбери задачу по шагам. Итоговый вывод напиши в самом конце, отдельной строкой». Это тот же принцип, перенесённый в обычный диалог. В статье он проверялся именно на структурных схемах.
💡 Адаптация для агентов: в описании инструментов с полем reasoning, plan или thought ставь его перед параметрами действия. Если в твоей схеме вызова инструмента решение идёт раньше пояснения, агент сначала «выбирает», потом оправдывает. Это перенос принципа на агентные схемы, прямо в статье он не проверялся.
Ресурсы
- Работа: Structure Tax: How Structured Output affects LLMs Performance
- Авторы: Vineet Kumar, Kanishka, Bhuvanesh Mandora (PayPal AI, Бангалор, Индия)
- Предшественники: Tam et al., 2024 (исходная гипотеза «налога на структуру»); Long et al., 2025 (пятнадцать форматов); Sclar et al., 2024 и He et al., 2024 (чувствительность к формулировке промпта); Wei et al., 2022 (Chain-of-Thought)
- Наборы задач: GSM8K, MMLU, LogicBench, Spider
