Разрыв между валидностью JSON и точностью значений

Самый важный вывод Structured Output Benchmark - разрыв между JSON Pass Rate (ответ является валидным JSON) и Value Accuracy (значения в листовых узлах абсолютно точны). У всех frontier-моделей показатель JSON Pass превышает 95%, тогда как Value Accuracy оказывается на 15-30 процентных пунктов ниже.

Цифры

Модель	JSON Pass	Value Accuracy	Разрыв
GPT-5.4	99.3%	79.8%	19.5 п.п.
Qwen3.5-35B	96.9%	80.1%	16.8 п.п.
GLM-4.7	96.5%	80.4%	16.1 п.п.
Gemini-2.5-Flash	97.2%	79.6%	17.6 п.п.
Claude-Sonnet-4.6	97.9%	77.9%	20.0 п.п.
GPT-5	98.3%	76.9%	21.4 п.п.
Schematron-8B	98.7%	73.1%	25.6 п.п.
Nemotron-3-Nano-30B	98.7%	74.7%	24.0 п.п.
Qwen3-30B	98.3%	75.3%	23.0 п.п.

Даже минимальный разрыв (у Qwen3.5-35B - 16.8 п.п.) означает, что примерно каждое шестое поле содержит ошибку, хотя сам JSON парсится без проблем. Максимальный разрыв у Schematron-8B (25.6 п.п.) означает, что на валидной по схеме структуре ошибочна четверть полей.

Почему JSON Pass перестал быть полезной метрикой

Примерно до 2023 года frontier-модели регулярно спотыкались на парсинге JSON. Инструменты ограниченного декодирования (Outlines, JSON Mode, Structured Outputs) закрыли эту проблему. К 2026 году на уровне парсинга вопрос решён: каждый API предлагает режим "это точно будет валидный JSON", да и сами базовые модели выучили синтаксис схем достаточно хорошо, так что доля успешного парсинга превышает 95% даже без принудительных ограничений. Сторона парсеров за это же время стала строже: jep-540-json-api, инкубируемый стандартный JSON API для Java, намеренно сделан минималистичным и строгим, отвергая ровно тот около-JSON, который нестрогие парсеры раньше пропускали. Так что "распарсилось" теперь повсюду означает одно и то же, но о корректности самих значений по-прежнему ничего не говорит.

Чего ограниченное декодирование исправить не может, так это правильность значений. Валидатор схемы может гарантировать, что в ответе есть поле total: number. Но он не может гарантировать, что total совпадает с тем, что было в исходном документе.

Почему разрыв остаётся незамеченным

Команды в production при оценке качества structured output часто смотрят на три сигнала:

Schema-validation rate - парсится ли JSON и проходит ли валидацию по схеме?
Field-presence rate - на месте ли все обязательные ключи?
Type-correctness - соответствуют ли значения ожидаемым примитивным типам?

Все три показателя могут быть выше 99%, пока точность значений остаётся на уровне 75%. В бенчмарке SOB метрики Type Safety, Path Recall и Structure Coverage вплотную подбираются к максимуму, даже когда 20-30% листовых значений неверны.

Это порождает худший вид ложного сигнала: дашборд сообщает, что со structured output всё отлично, в логах production нет ошибок парсинга, а нижестоящие системы молча принимают галлюцинированные значения, пока кто-нибудь не заметит, что invoice_total отличается на порядок.

Как выглядят "структурированные галлюцинации"

Самый сложный тип сбоя, о котором говорится в отчёте SOB, - это структурированная галлюцинация: корректное по типу, валидное по схеме и правдоподобное значение, которое просто неверно. Пример из SOB: эталонное значение "target_market_age": "15 to 35 years", а модель возвращает "25 to 35". Вывод проходит валидацию схемы, тип правильный, формат правильный. Поймать такую ошибку можно только посимвольным сравнением листового значения с проверенным эталоном.

Структурированные галлюцинации особенно неприятны тем, что привычные guardrail'ы вроде проверки схемы, контроля типов или валидаторов по regex против них бесполезны. Здесь нужна либо построчная ручная проверка, либо ансамблирование с поиском расхождений (ensemble-and-disagree), либо проверка фактической точности (grounding/faithfulness) по исходному контексту.

Практические выводы

Если вы выкатываете structured output от LLM в production и SLA предполагает, что downstream-системы доверяют значениям без ручной проверки:

Не приравнивайте валидацию схемы к качеству. Отслеживайте точность конкретных значений на отложенном эталонном датасете (gold set).
Не переносите результаты текстовых бенчмарков на изображения и аудио. В SOB точность значений на аудио не превышает 23.7% - расшифровка встреч недостижима ни для одной современной модели без принципиально другого пайплайна.
Модель с наивысшим JSON Pass не обязательно лучшая. У Schematron-8B самый высокий Path Recall, но самая низкая Value Accuracy. Выбор по доле успешного парсинга приведёт к худшей модели.
Ограниченное декодирование решает проблему парсинга, а не значений. Это необходимое, но недостаточное условие.

Связанные страницы

structured-output-benchmark - бенчмарк SOB, из которого взят этот вывод
interfaze - сущность Interfaze
average-is-all-you-need - близкий аргумент о том, что LLM поднимают нижнюю планку среднего качества, не меняя верхний предел