РУКОВОДСТВО · ОБНОВЛЕНО 2026-10-31
Повторяющиеся ключи JSON в ответе LLM: почему схема может не заметить ошибку
Проверка исходного ответа до преобразования в объект языка программирования.
Два одинаковых имени в одном JSON-объекте создают неоднозначность: разные обработчики могут сохранить разные значения или отклонить документ. После обычного разбора одно значение уже может исчезнуть, и проверка схемы его не увидит. Если ваш контракт запрещает повторы, проверяйте их на этапе разбора исходного текста. Не заменяйте такой контроль регулярным выражением по всему ответу: одинаковое имя в разных вложенных объектах допустимо. Сохраняйте безопасный фрагмент исходника и причину отказа для диагностики без утечки содержимого документа.
1. Зафиксируйте контракт результата
Опишите, является ли поле единственным значением или коллекцией. Если модель должна вернуть несколько цен или адресов, используйте массив объектов вместо повторения одного имени. Согласуйте поведение при неоднозначном входе: уточнение, ошибка или явное отсутствие результата. RFC8259 рекомендует уникальные имена членов объекта и описывает различия обработки повторов. Не объявляйте любой принимаемый парсером текст пригодным для записи в рабочую систему без проверки собственного контракта.
2. Проверяйте исходный текст при разборе
Выберите парсер или режим, который сообщает о повторных именах до преобразования в обычный объект. Учитывайте декодированные имена: разные формы записи escape-последовательности могут означать один и тот же ключ. Регулярное выражение не знает границ вложенных объектов и не заменяет разбор синтаксиса. Ограничьте размер и глубину документа. Для конкретного языка проверьте реальное поведение используемой библиотеки, а не переносите правило из другого runtime или старой версии зависимости.
3. Не исправляйте конфликт молча
Если два значения различаются, приложение не должно выбирать более удобное или последнее без заранее определённого правила. Повторный запрос к модели может помочь получить однозначную структуру, но его тоже нужно проверить. Не дописывайте служебные поля строковой конкатенацией к непроверенному JSON. Сначала получите разрешённый объект, затем сформируйте новый документ сериализатором. Содержательная ошибка и техническая недоступность API требуют разных сообщений и разных правил повторной обработки.
4. Проверьте границы и соседние системы
Соберите примеры с повтором на верхнем уровне, внутри объекта и с одинаковым именем в разных элементах массива. Проверьте экранированные ключи и одинаковые значения при повторе. Даже совпадающие значения могут нарушать строгий контракт. Сравните обработку в API-шлюзе, приложении и хранилище: они не должны принимать разные решения о смысле одного документа. Для регрессии сохраняйте минимальные синтетические примеры вместо пользовательских данных и фиксируйте версию парсера в отчёте проверки.
Частые вопросы
Всегда ли JSON-парсер выдаст ошибку при повторе?
Нет. Поведение зависит от реализации. Поэтому запрет повторов нужно проверять явно, не полагаясь только на успешный разбор.
Почему JSON Schema может пропустить повтор?
Валидатор часто получает уже готовый объект, где предыдущая пара потеряна. Проверка исходного текста должна происходить раньше.
Одинаковое имя в двух вложенных объектах — это ошибка?
Нет, если контракт это допускает. Важно различать повтор внутри одного объекта и одинаковые имена в независимых объектах.
Можно ли попросить модель исправить JSON?
Можно, но исправленный ответ снова проходит полный разбор и валидацию. Модель не должна самостоятельно решать конфликт бизнес-значений.