TL;DR
Когда просишь LLM сгенерировать сложный JSON или таблицу, модель почти всегда помнит правильные значения — но раскладывает их не по тем местам. Значение «Москва» она вспомнит верно, но воткнёт в поле «город доставки» вместо «город регистрации». Исследователи назвали это scissors pattern («паттерн ножниц»): чем сложнее структура, тем сильнее расходятся две линии — «значение где-то есть» (остаётся высокой) и «значение на своём месте» (резко падает).
Главная находка: глубина вложенности рушит адресацию быстрее, чем правильность самих значений. На сложных JSON-схемах (4 уровня вложенности) даже топовые модели путают место у 35% правильно вспомненных значений, а слабые модели — у 74%. Причина в том, что модель ориентируется не на реальную позицию в структуре, а на смысл названия поля — если поле «name» встречается в разных разделах (личные данные и рабочая история), модель путает, в какой раздел его класть, потому что цепляется за похожее название, а не за структурную координату.
Авторы предлагают метод диагностики SCD — разбивать проверку вывода на три уровня: формат валиден → все нужные пути на месте → значения на своих местах. Отдельно они дотренировали модель через reinforcement learning (SA-RLVR), чтобы она лучше «привязывала» значения к нужным координатам — но это требует GPU и кода, для чат-пользователя неприменимо.
Схема метода (диагностика SCD)
УРОВЕНЬ 1: Формат валиден? → да/нет (парсится ли JSON/таблица)
УРОВЕНЬ 2: Все нужные пути/поля присутствуют? → % совпадения со схемой
УРОВЕНЬ 3: Значения стоят в правильных местах? → % совпадения "путь = значение"
Диагностика ошибки:
Value Presence (VP) — значение есть где-то в выводе
Value Placement Accuracy (VPA) — значение стоит в правильном месте
Разрыв VP − VPA = сколько значений "потерялись не по смыслу, а по адресу"
Пример применения
Задача: Ты собираешь через ChatGPT структуру для сложной анкеты сотрудника — JSON с разделами «Личные данные», «Образование», «Опыт работы», где в каждом разделе есть повторяющиеся поля: name, phone, дата.
Промпт (двухшаговая генерация, снижает путаницу адресации):
Вот данные для JSON-анкеты сотрудника:
- Личные данные: имя = Иванов И.И., телефон = +7900...
- Образование: имя учебного заведения = МГУ, дата = 2015
- Опыт работы: имя компании = Яндекс, телефон = +7495...
Шаг 1: Сначала выпиши списком, БЕЗ сборки в JSON, соответствие
"путь в структуре → значение" для каждого поля.
Используй полный путь, например: personal.name = Иванов И.И.
Шаг 2: Только после того как список готов и проверен —
собери финальный JSON по этому списку, не меняя значения.
Результат: Модель сначала выдаст явную таблицу «путь → значение» — это заставляет её проверить адресацию отдельно от значений, до сборки итоговой структуры. Затем на основе этого списка соберёт JSON. Такой подход напрямую бьёт по найденной проблеме: модель перестаёт путать похожие поля («name» в разных разделах), потому что адресация зафиксирована текстом заранее, а не решается «на ходу» при генерации вложенной структуры.
Почему это работает
LLM не «видит» структуру как дерево с координатами — она генерирует текст токен за токеном, ориентируясь на смысл названий полей. Когда в разных разделах есть похожие поля (name, phone), модель хватается за смысловую подсказку («это же имя!») вместо того, чтобы отследить, в какой именно узел дерева она сейчас пишет.
Модель хорошо умеет удерживать в памяти сами значения — доказано тем, что VP (значение где-то есть) остаётся высоким даже на сложных схемах. Слабое место — привязка значения к точной координате, особенно когда вложенность глубокая или названия полей повторяются.
Метод из примера использует силу модели (запомнить и разложить по явному списку) для обхода слабости (путаница координат при прямой генерации сложной вложенной структуры). Разделение на «сначала сопоставить путь-значение, потом собрать» — это ровно то, что делает SCD-диагностика вручную, только применённое как приём промптинга, а не как метрика оценки.
Рычаги управления: - Глубина вложенности → если можешь, делай структуру более плоской (меньше уровней = меньше ошибок адресации) - Названия полей → делай их уникальными и описательными внутри всей структуры, не повторяй одинаковые имена в разных разделах - Для критичных данных → проси модель дважды: сначала список «путь→значение», потом сборка; или попроси модель после сборки сверить финальный JSON с исходным списком
Ограничения
⚠️ Глубокая вложенность: начиная с 3-4 уровней вложенности JSON, даже сильные модели массово путают позиции значений — почти каждое третье-четвёртое значение попадает не туда.
⚠️ Повторяющиеся имена полей: если одно и то же название поля встречается в разных разделах структуры (например, «name» в личных данных и в опыте работы), ошибка размещения растёт заметно — модель путает разделы.
⚠️ Метод обучения (SA-RLVR) не для чата: улучшение адресации через RL требует GPU, LoRA-дообучение и код — это не воспроизвести в обычном диалоге с LLM, применим только диагностический принцип и приём "сначала список, потом сборка".
Ресурсы
Zhang Y., Wu C., Wang L., Li J. «Where vs What: Decomposing Structural and Content Failures in LLM-Generated Structured Outputs». Shenzhen University, Shenzhen Institutes of Advanced Technology (Chinese Academy of Sciences).