В последние годы структурированные выходы ИИ стали почти синонимом «продакшн-готовности». JSON по схеме, строгие типы, никаких сюрпризов — мечта инженера. Но свежий разбор от Boundary ML показывает тревожную вещь: чем жёстче мы загоняем LLM в формат, тем чаще она жертвует качеством ради формы.
Самое опасное здесь — не ошибка как таковая. Самое опасное — иллюзия корректности.
🧠 Что именно ломается при структурированных выходах
На первый взгляд всё выглядит идеально: API гарантирует валидный JSON, схема соблюдена, пайплайн не падает. Но внутри происходит тонкий, почти незаметный перекос.
Модель начинает оптимизироваться не под задачу, а под формат:
- 🧩 подгоняет значения под допустимые типы
- 🧮 округляет там, где не уверена
- 🤐 перестаёт сигнализировать о сомнениях
- 🚫 теряет возможность отказаться от бессмысленного запроса
В примере с чеком GPT-5.2 спокойно «превращает» дробное количество бананов в целое. JSON идеален. Данные — нет.
⚠️ Почему это особенно опасно в продакшене
Ошибки структурированных выходов коварны тем, что они не бросаются в глаза:
- ❌ нет JSON.parse error
- ❌ нет exception
- ❌ нет алерта
Зато есть аккуратный объект, который дальше едет по системе, попадает в аналитику, биллинг или отчёты. Ошибка перестаёт быть технической и становится бизнес-ошибкой.
Это фундаментальное отличие от свободного текста, где модель может:
- ✋ сказать «я не могу выполнить запрос»
- 🤔 явно выразить неопределённость
- 📝 пояснить, что данные противоречивы
🧠 Цепочка рассуждений (Chain-of-thought): интеллект под замком
Один из самых недооценённых эффектов — подавление рассуждений. Цепочка рассуждений работает, когда модель может свободно думать. Но строгий формат заставляет её тратить «интеллектуальный бюджет» на экранирование кавычек, переносы строк и соответствие схеме.
В итоге:
- 🧱 рассуждения ужимаются
- 🧾 логика упрощается
- 📉 точность падает
Это как заставить эксперта решать задачу, одновременно заполняя налоговую декларацию.
⚙️ Техническая причина: декодирование с ограничениями
Корень проблемы — ограниченное декодирование. Когда модель выбирает следующий токен, ей просто запрещают некоторые варианты. Даже если они ближе к истине.
Если схема ждёт int, модель не может выдать 0.46. Не потому что не понимает, а потому что ей нельзя. Она выбирает «допустимое», а не «правильное».
Это важный момент:
ограничения применяются во время генерации, а не после неё.
🧩 Альтернатива: сначала думать, потом парсить
Контринтуитивный, но практичный вывод Boundary ML звучит так:
пусть модель сначала ответит свободно, а структура появится позже.
Да, парсинг сложен.
Да, это требует усилий.
Зато:
- 🧠 сохраняется качество рассуждений
- ⚠️ ошибки остаются видимыми
- 🛡️ появляется дополнительный уровень защиты
- 📉 снижается риск «тихих» ошибок
Формат — это ответственность кода.
Смысл — ответственность модели.
✍️ Личное мнение
Структурированные выходы — это не зло. Это инструмент. Но проблема в том, что мы начали путать валидность формы с истинностью содержания.
Красивый JSON расслабляет. Он создаёт ощущение контроля. Но именно поэтому он опасен: система выглядит стабильной, пока бизнес не начинает задавать неудобные вопросы.
Иногда лучший инженерный выбор — позволить модели сказать:
«Я не уверен» — и уже потом аккуратно разобрать её ответ.
🔗 Источники
- Оригинальная статья Boundary ML:
https://boundaryml.com/blog/structured-outputs-create-false-confidence - Boundary ML (open-source инструменты для AI):
https://boundaryml.com