3,583 papers
arXiv:2610.12056 89 8 окт. 2026 г. FREE

Reasoning-first: порядок полей в структурированном ответе решает, потеряет ли модель точность

КЛЮЧЕВАЯ СУТЬ
Парадокс: JSON и XML сами по себе точность не роняют. Её роняет порядок двух полей. Схема «дай ответ и обоснование» на арифметике режет точность небольших моделей с ~85% до ~11%. Метод Reasoning-first позволяет получать от модели чёткий JSON или XML для автоматизации и не терять в качестве. Поменяй местами два поля: сначала рассуждение, потом ответ. Модель пишет слева направо и не возвращается назад. Поэтому рассуждение до ответа работает как пошаговые рассуждения (CoT), а точность равна свободному тексту или выше.
Адаптировать под запрос
⚡

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

📋 Дайджест исследования

Ключевая суть

Парадокс: JSON и XML сами по себе точность не роняют. Её роняет порядок двух полей. Схема «дай ответ и обоснование» на арифметике режет точность небольших моделей с ~85% до ~11%. Метод Reasoning-first позволяет получать от модели чёткий JSON или XML для автоматизации и не терять в качестве. Поменяй местами два поля: сначала рассуждение, потом ответ. Модель пишет слева направо и не возвращается назад. Поэтому рассуждение до ответа работает как пошаговые рассуждения (CoT), а точность равна свободному тексту или выше.

Принцип работы

Всё делается в одном промпте. Отдельных запросов не нужно. Процесс такой: поле (модель считает по шагам) → поле (короткий итог). В типичной схеме ответ стоит первым. Это как контрольная, где итог вписывают в клетку до решения. Решение потом просто оправдывает уже написанное. Порядок полей в схеме — это порядок мысли модели. XML-теги в среднем чуть надёжнее JSON-ключей. Они чётче отделяют «думаю» от «отвечаю». Разрыв доходил до 12 пунктов.

Почему работает

Модель опирается только на то, что уже написала. Если первым стоит answer, итог приходится угадывать вслепую. Дальше возможны два сбоя. Первый сбой — подгонка. На тестах с выбором ответа обоснование сжимается до короткой отговорки: 33 слова против 121 при правильном порядке. Второй сбой — ранняя фиксация. На арифметике текста пишется столько же, но число уже стоит, и расчёт его не меняет. Жесть: GPT-4o теряет около 40 пунктов против обычного ответа, хотя знает ровно столько же. Он просто отвечает раньше, чем подумал. У моделей на 4-8 млрд параметров обвал почти полный. Порядок полей — главный рычаг. Меняй его первым, если точность проседает.

Когда применять

Автоматизации и конвейеры, где ответ надо разобрать кодом (n8n, боты, скрипты) → особенно многошаговые расчёты, логические задачи и выбор варианта с обоснованием, когда цифры «плавают». НЕ подходит для генерации SQL: порядок полей там почти не влияет, а XML иногда мешает. Знаний модели метод тоже не добавляет: на вопросах по фактам выигрыш скромнее. Модели с режимом «мышления» в статье не проверяли. Claude Sonnet 4.5 вёл себя странно: на арифметике JSON с ответом первым дал 96%, а XML с тем же порядком — 62%. Проверяй на своей модели.

Мини-рецепт

1. Найди свою схему: где в промпте сейчас стоит поле с ответом? Если первым — вот виновник.
2. Поменяй порядок: сверху, снизу. Лучше теги XML, чем ключи JSON.
3. Скажи, как думать: внутри напиши «считай по шагам» или «проверь каждое условие».
4. Задай форму итога: в одно число, да/нет или метка. Так проще разбирать кодом.
5. Запрети болтовню: добавь «Пиши только после того, как закончил . Ничего вне тегов».
6. Спрячь рассуждение: код парсит только . сохрани для проверки, клиенту не показывай.
7. Не хочешь собирать вручную: вставь шаблон в чат и попроси модель адаптировать его под твою задачу. Порядок тегов она сохранит.

Примеры

[ПЛОХО] : Посчитай маржу товара на Wildberries. Верни JSON: {"маржа_руб": ..., "пояснение": ...}
[ХОРОШО] : Ты считаешь юнит-экономику товара. Закупка 640 ₽, цена 1 990 ₽, скидка 25%, комиссия 19% от цены после скидки, логистика 62 ₽, выкуп 85%, возврат стоит 50 ₽. Верни строго XML. Порядок тегов обязателен: считай по шагам: цена после скидки, комиссия, логистика, потери на возвратах, маржа. Показывай каждое действие маржа на одну проданную единицу в рублях, одно число. Пиши только после того, как закончил . В плохом варианте модель сначала выдаёт число, потом сочиняет пояснение. В хорошем число следует из выкладки выше. Автоматизация забирает только содержимое .
Источник: Structure Tax: How Structured Output affects LLMs Performance
ArXiv ID: 2610.12056 | Сгенерировано: 2026-10-09 06:20

Проблемы LLM

ПроблемаСутьКак обойти
Ответ в структурированном формате (JSON, XML) хуже, чем в свободном тексте, если поле с ответом стоит раньше поля с рассуждениемПросишь типичную схему: {"ответ": ..., "пояснение": ...}. Модель пишет текст слева направо и назад не возвращается. Ответ она должна назвать первым, ещё не рассуждая. Потом пояснение лишь подгоняется под него. На задачах в несколько шагов (расчёты, логика) точность падает в разы. У небольших моделей падение почти полное. У сильных моделей оно мягче, но заметное. Кажется, что виноват сам формат. На деле виноват порядок полейПоменяй порядок полей. Рассуждение первым, ответ вторым. Например: ……. Остальную схему не трогай. Тогда точность сравнима со свободным ответом или выше

Методы

МетодСуть
Рассуждение перед ответом в схеме — цепочка рассуждений внутри форматаОпиши в схеме два поля в строгом порядке. Сначала с шагами. Потом с коротким итогом. Добавь в запрос: «Пиши только после того, как закончил » и «Ничего вне тегов не пиши». Внутри задай способ рассуждать: «считай по шагам», «проверь каждое условие», «выпиши каждое действие». Почему работает: ответ строится по уже написанному тексту. Схема принуждает модель сначала думать, потом отвечать. Всё делается одним запросом, отдельные шаги не нужны. Для программы: разбирай только . Рассуждение сохрани для проверки, клиенту не показывай. Когда применять: расчёты, логика, многошаговые решения, классификация с обоснованием. Когда не нужно: простые задачи с жёсткой своей структурой, например генерация SQL. Там порядок почти не влияет, а обёртка иногда мешает. Оговорка: у разных моделей бывают аномалии. XML в среднем чуть надёжнее JSON, но не всегда. Проверяй на своей модели
📖 Простыми словами

Structure Tax: How Structured Output affectsLLMsPerformance

arXiv: 2610.12056

Любая нейросеть генерирует текст строго слева направо и не умеет возвращаться назад, чтобы стереть написанное. Когда ты заставляешь модель отвечать через JSON и первым ключом требуешь итоговый вердикт, ты просишь назвать победителя до свистка арбитра. Знаменитый налог на структуру — это не врождённый дефект JSON, а тупейшая ошибка в порядке ключей. Модель тычет пальцем в небо, выдаёт число наугад, а потом судорожно пытается его оправдать.

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

Лекарство здесь ровно одно — железобетонный паттерн Reasoning-first. Ты обязан сначала запросить поле reasoning, и только потом — answer. Цифры в исследовании просто дикие: на многошаговой арифметике неверный порядок полей роняет точность с 85% до позорных 11%, а хвалёная GPT-4o теряет около 40 пунктов. Стоит поменять поля местами — и точность восстанавливается до уровня свободного ответа.

Тестировали на задачках, но грабли одни и те же везде. Считаешь маржу на Wildberries в n8n, настраиваешь AI-агента для скоринга лидов или автоматизируешь разбор тикетов в поддержке — не смей требовать статус раньше анализа ситуации. Любая автоматизация в проде будет безбожно врать, если ты лишаешь модель возможности подумать на черновике.

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

Работа с исследованием

Адаптируйте исследование под ваши задачи или создайте готовый промпт на основе техник из исследования.

0 / 2000
~0.5-2 N-токенов ~10-30с
~0.3-1 N-токенов ~5-15с