TL;DR
Constraint Tax — это феномен: когда модели дают несколько строгих требований одновременно, она выполняет одно за счёт другого. В агентных системах это работает радикально: если попросить модель и вызвать внешний инструмент, и вернуть ответ в строгом JSON-формате — она тихо перестаёт вызывать инструменты вообще, хотя по-прежнему уверенно возвращает красивый структурированный ответ.
Главная находка: модель не выдаёт ошибку, не предупреждает — она просто молча пропускает действие и генерирует формально правильный, но пустой ответ. В чате это выглядит иначе, но принцип тот же: когда ты одновременно требуешь «глубоко проанализируй» + «строго следуй этому шаблону» + «не выходи за рамки формата» — что-то из этого теряется. Конкурирующие цели → жертва одной из них.
Решение, которое нашли исследователи — разделить шаги: сначала модель выполняет действие (без ограничений на формат), потом форматирует результат (без ограничений на действие). Два прохода вместо одного. Для чата этот принцип работает точно так же: сначала «подумай и собери», потом «оформи».
Схема метода
ПРОХОД 1 — действие: Задай задачу без требований к формату →
модель рассуждает, собирает, анализирует свободно
ПРОХОД 2 — форматирование: Передай результат + требование к формату →
модель оформляет готовый материал в нужную структуру
Оба шага — отдельные запросы в чате. Не смешивай их в один.
Пример применения
Задача: Илья — продакт в стартапе, готовит отчёт для инвесторов. Нужно проанализировать конкурентов (Mindbox, Retail Rocket, Carrot Quest) и оформить в таблицу с колонками: позиционирование, целевой клиент, слабое место.
Промпт — Проход 1 (действие):
Проанализируй трёх конкурентов в нише CDP и маркетинговой автоматизации
для e-commerce в России: Mindbox, Retail Rocket, Carrot Quest.
По каждому разбери:
— В чём их реальное позиционирование (не с сайта, а по сути)
— Кто их типичный клиент
— Что они не умеют или где проседают
Пиши свободно, без формата. Просто разбери по делу.
Промпт — Проход 2 (форматирование):
Вот анализ конкурентов: [вставляешь ответ из Прохода 1]
Оформи это строго в таблицу Markdown с тремя колонками:
"Компания" | "Позиционирование" | "Целевой клиент" | "Слабое место"
Ничего не добавляй от себя — только структурируй готовый материал.
Результат: В первом проходе модель выдаст развёрнутый живой анализ — именно тот, что нужен инвесторам. Во втором — аккуратно упакует его в таблицу, не теряя смысл и не добавляя пустых фраз. Если объединить оба требования в одном запросе — таблица получится, но анализ будет поверхностным: модель будет «думать о формате», пока должна думать о конкурентах.
Почему это работает
Слабость LLM — у модели нет бесконечных «вычислительных мощностей» для одного запроса. Когда ты задаёшь жёсткие требования к формату одновременно с требованием глубоко думать, модель распределяет внимание между двумя целями. Формат обычно «побеждает» — он проще верифицируется прямо в процессе генерации.
Почему формат выигрывает у рассуждений? На уровне токенов (единиц текста, которые генерирует модель) строгий формат буквально ограничивает, какие слова могут идти следующими. Это как писать сонет — пока считаешь слоги, глубину мысли теряешь. В агентных системах это доходит до предела: JSON-схема физически блокирует токены вызова инструментов — они становятся недостижимы.
Как Two-Pass это обходит: в первом проходе модель работает без формальных ограничений — как будто пишет черновик. Рассуждение, сбор аргументов, принятие решений происходят свободно. Во втором проходе задача простая: взять готовый материал и «упаковать». Это несравнимо легче, чем думать и форматировать одновременно. Разделение целей → каждая цель достигается полностью.
Рычаги управления:
- Насколько свободным должен быть Проход 1 — добавь
«не сдерживай рассуждения»,«выписывай всё что приходит в голову»→ больше материала для форматирования - Насколько строгим должен быть Проход 2 — чем точнее опишешь схему (число колонок, названия, порядок), тем чище результат
- Количество проходов — для сложных задач можно добавить Проход 1.5: «проверь свой анализ, чего не хватает?» — перед финальным форматированием
Шаблон промпта
Проход 1 — действие:
{Задача}: {контекст и объект анализа/работы}
Разбери это подробно и свободно. Не думай о формате ответа —
просто выдай всё что знаешь по делу. Пиши как черновик.
Проход 2 — форматирование:
Вот материал: {вставить ответ из Прохода 1}
Оформи строго в формат: {описание формата — таблица / список / JSON /
структура документа / шаблон}
Используй только готовый материал выше. Ничего не выдумывай.
Плейсхолдеры:
- {Задача} — что нужно сделать: «Проанализируй», «Оцени», «Составь план»
- {контекст} — предмет работы: компании, текст, ситуация, данные
- {описание формата} — точная структура вывода: число колонок, названия секций, JSON-поля
🚀 Быстрый старт — вставь в чат:
Вот двухшаговый шаблон Two-Pass для сложных задач.
Адаптируй под мою задачу: {твоя задача}.
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит: что именно анализировать, в какой формат выводить — потому что оба параметра критичны для разделения задач на правильные шаги.
Ограничения
⚠️ Дополнительный шаг: метод требует двух запросов вместо одного. Для простых задач («напиши список из 5 пунктов») — избыточно.
⚠️ Зависит от качества Прохода 1: если первый ответ поверхностный — второй проход его не улучшит, только упакует пустоту. Инвестируй в качество первого запроса.
⚠️ Применимость к ChatGPT/Claude: оригинальное явление (полная блокировка tool calling) воспроизводится на открытых моделях в API-инфраструктуре. В стандартном чате ChatGPT/Claude деградация мягче — но принцип конкуренции целей работает и там.
⚠️ Не лечит слабые модели: Tool Suppression — это не баг слабых моделей, его воспроизвели на нескольких семействах. Но Two-Pass особенно помогает именно там, где модель «средняя» по качеству инструкций.
Как исследовали
Всё началось с реального инцидента в продакшне: агентная система одной компании перестала вызывать внешние инструменты — но только когда был включён JSON Schema. Выключили схему — инструменты заработали. Включили обратно — перестали. Никаких других изменений.
Исследователи воспроизвели это на нескольких семействах открытых моделей (Qwen, Llama и других) через несколько конфигураций развёртывания. Измеряли Tool Invocation Rate (TIR) — долю запросов, где модель реально вызвала инструмент. Без JSON Schema: TIR близок к 100%. С JSON Schema: падает до нуля у ряда моделей.
Самое интересное — они залезли в стек вывода (inference stack) и нашли физическую причину: JSON Schema компилируется в маску токенов. Грамматика схемы буквально запрещает определённые токены на каждом шаге генерации — и теги вызова инструментов (
Это объяснило парадокс: модель понимает задачу, планирует инструменты — но на этапе исполнения тихо их пропускает. Авторы назвали это Constraint Priority Inversion — приоритет схемы инвертирует цепочку исполнения. Решение (Two-Pass) проверили на тех же моделях: TIR восстановился, соответствие схеме сохранилось.
Адаптации и экстраполяции
🔧 Техника: «Промежуточный черновик» для длинных аналитических задач
Добавь явную инструкцию в Проход 1 выдавать сырой поток мысли, а не отшлифованный текст:
«Пиши как будто диктуешь голосом — без редактирования, без структуры. Просто думай вслух по задаче.»
Это максимально освобождает первый проход от любого «форматного давления». Получишь самый богатый черновик для второго шага.
🔧 Техника: «Три-прохода» для комплексных документов
Проход 1 → свободный анализ
Проход 1.5 → «что важного я упустил(а)? добавь»
Проход 2 → финальное форматирование
Полезно для отчётов, питчей, технических документов — где пропущенный аргумент дорого стоит.
🔧 Техника: Применить к рецензии и критике
Constraint Tax работает не только с форматом, но и с ролью. Когда просишь «будь одновременно добрым и критичным» — модель усредняет. Разделяй:
Проход 1: «Критикуй жёстко, без дипломатии»
Проход 2: «Перепиши эту критику в конструктивный тон для клиента»
Ресурсы
Работа: Constraint Tax in Open-Weight LLMs: An Empirical Study of Tool Calling Suppression Under Structured Output Constraints
Авторы: Fangzheng Li, Aimin Zhang, Chen Lv
Организации: Focus AI Center, Focus Technology Co., Ltd.; Nanjing University of Science and Technology
Код и данные: https://github.com/Fzsama/Constrain-Tax-26-06.git
Связанные концепции: Constraint Tax (Ray, оригинальная концепция), Grammar-Constrained Decoding, xgrammar, Outlines, vLLM, SGLang