3,583 papers
arXiv:2510.15955 88 10 окт. 2025 г. FREE

Обработка JSON в LLM: когда код лучше слов

КЛЮЧЕВАЯ СУТЬ
Обнаружено: Даже топовые LLM катастрофически плохи в прямой обработке JSON – GPT-4o достигает максимум 77% точности. Модели теряются в структуре, путают похожие ключи (name, room_name, full_name), сбиваются на вложенности. При росте размера до 80K токенов Mistral-large проседает на 91%. Метод позволяет извлекать данные из сложных JSON-ответов API с точностью до 95% – особенно для фильтрации и агрегации. Фишка: вместо "прочитай JSON и ответ дай" → "напиши Python-функцию, которая распарсит JSON". Код выполняется – результат точный. Добавь схему JSON в промпт – +12% точности. Даже сокращённый пример структуры работает, если полный ответ не влезает в контекст.
Адаптировать под запрос

TL;DR

Как обрабатывать JSON-ответы от API и инструментов — исследование показывает, что LLM лучше справляются, когда генерируют Python-код для парсинга вместо прямого ответа. Особенно для сложных задач: фильтрации и агрегации данных.

Главная находка: Даже топовые модели плохо обрабатывают структурированные данные напрямую. GPT-4o достигает максимум 77% точности. Когда вы просите модель "посмотри в этот JSON и ответь" — она путается в структуре, выбирает не те ключи, теряет данные при вложенности. Точность падает с ростом размера ответа: GPT-4o теряет 7%, Mistral-large — 91% при увеличении с 10K до 80K токенов. Позиция ответа тоже влияет: модели лучше видят последние данные (recency bias).

Суть метода: Вместо "прочитай JSON и ответь" → "напиши Python-функцию, которая распарсит JSON и вернёт ответ". Код выполняется, результат возвращается. Для усиления: добавь схему JSON в промпт (+12% точности) и дай пример структуры даже если полный ответ не влезает в контекст.


🔬

Схема метода

Исследование сравнивало два основных подхода:

ПОДХОД 1: Генерация ответа (answer generation)

Запрос → LLM читает JSON → Выдаёт ответ текстом

ПОДХОД 2: Генерация кода (code generation) ← работает лучше

Запрос → LLM пишет Python-функцию → Код выполняется → Возвращается результат

Варианты улучшения:

  • Добавить схему JSON в промпт
  • Дать сокращённую версию ответа, если полный не влезает
  • Для сложных задач: добавить инструкции по рассуждению (CoT)

Все подходы работают в одном запросе к модели.


🚀

Пример применения

Задача: Вы скачали данные о московских квартирах из API Авито в JSON (50+ объектов, вложенная структура: район → ЖК → квартира → характеристики). Нужно найти все двушки в пределах 15 млн с балконом.

Промпт (базовый подход — работает плохо):

Вот JSON с квартирами. Найди все двушки до 15 млн с балконом, выведи адреса списком.

[JSON]

Промпт (улучшенный — генерация кода):

Вот JSON-ответ от API Авито с квартирами и схема этого JSON.

Напиши Python-функцию, которая:
1. Принимает весь JSON как словарь
2. Фильтрует квартиры: rooms == 2, price <= 15000000, has_balcony == true
3. Возвращает список адресов строкой через запятую

Требования к коду:
- Начинается с "def "
- Проверяет существование ключей перед обращением
- Сравнивает строки в lowercase
- Возвращает только результат (строка), без лишнего текста

Схема JSON:
{
 "apartments": [
 {
 "address": "string",
 "price": "number",
 "rooms": "number",
 "has_balcony": "boolean",
 ...
 }
 ]
}

JSON:
[вставить данные]

Python-функция:

Результат: Модель выдаст Python-код с функцией def filter_apartments(data):, которая корректно обрабатывает вложенность, проверяет условия и возвращает список адресов. Код можно запустить сразу (в локальном Python или через инструмент code execution в чате). Точность выше на 3-50% в зависимости от сложности.


🧠

Почему это работает

Слабость LLM: Модели теряются в структуре при прямой обработке JSON. Они путают похожие ключи (name, room_name, name_without_policy), берут значения из не тех объектов, сбиваются на вложенности. При длинных ответах (50K+ символов) точность падает катастрофически. Это как искать нужную строку в таблице Excel на 100 листов на глаз.

Сильная сторона LLM: Модели отлично знают структуру кода и умеют писать точные инструкции. Python для парсинга JSON — это их родная территория. Код однозначен: if item['price'] <= 15000000 не может быть понят двояко. Плюс код компактнее — функция на 20 строк вместо развёрнутого текстового ответа на 200 слов.

Как метод использует это: Вы переводите задачу из пространства "понимания структуры" в пространство "написания кода". Вместо "найди и скажи" → "напиши функцию, которая найдёт". Модель генерирует код, код выполняется — результат точный. Схема JSON работает как карта местности — модель видит типы данных, вложенность, связи. Пример структуры (даже сокращённый) показывает реальные значения — модель понимает формат ("USD 250" vs 250).

Рычаги управления:

  • Длина JSON → если >50K символов, используй сокращённую версию (один пример каждого типа объекта)
  • Тип задачи → для извлечения одного значения ("What is form type?") иногда лучше прямой ответ, для фильтрации/агрегации — всегда код
  • Схема → добавляй всегда, если есть — даёт +12% точности
  • Инструкции CoT → для агрегации (суммы, средние) добавь "Think step-by-step" перед генерацией кода

📋

Шаблон промпта

Вот JSON-ответ от {источник} и его схема.

Напиши Python-функцию, которая:
1. Принимает весь JSON как словарь (параметр data)
2. {описание задачи: фильтрует/извлекает/считает}
3. Возвращает результат строкой

Требования к коду:
- Начинается с "def "
- Проверяет существование ключей и None-значений
- Сравнивает строки в lowercase
- Очищает числовые строки (убирает "$", пробелы) перед конвертацией
- Возвращает только результат, без лишнего текста

Схема JSON:
{схема}

JSON:
{данные}

Python-функция:

Пояснение плейсхолдеров:

  • {источник} — откуда данные (API Авито, экспорт из CRM, etc)
  • {описание задачи} — конкретная операция ("найди все X где Y", "посчитай среднее Z")
  • {схема} — JSON-схема структуры (можно сгенерировать онлайн или попросить модель)
  • {данные} — сам JSON-ответ (полный или сокращённый)

🚀 Быстрый старт — вставь в чат:

Вот шаблон для обработки JSON через код. Адаптируй под мою задачу: [твоя задача]. 
Задавай вопросы, чтобы заполнить поля.

[вставить шаблон выше]

LLM спросит откуда JSON, что нужно извлечь, есть ли схема — потому что эти данные критичны для точного парсинга. Она возьмёт паттерн функции из шаблона и адаптирует под твою структуру данных.


⚠️

Ограничения

⚠️ Тип задачи: Для простого извлечения одного значения ("What is the price?") прямой ответ иногда точнее кода — 10 из 15 моделей показали это. Код оправдан для фильтрации и агрегации.

⚠️ Размер контекста: При JSON >80K токенов точность падает у всех моделей. Даже с кодом. Используй сокращение (один пример каждого типа объекта).

⚠️ Синтаксис кода: ~5-10% ошибок из-за несовместимого синтаксиса (неправильный тип данных, ошибка обхода). Топовые модели (GPT-4o, Claude-4-Sonnet) генерируют исполнимый код в 95%+ случаев.

⚠️ Семантическая двусмысленность: Если в JSON есть похожие ключи (name, room_name, full_name), модель может выбрать не тот. Указывай точный путь в задаче или чисти JSON перед подачей.


🔍

Как исследовали

Команда собрала 1298 реальных вопросов-ответов по API-ответам от RapidAPI (отели, машины, авиарейсы, SEC-документы, товары). JSON были длинными — от 24K до 74K символов. Вопросы разделили на три типа: extractive (найди значение по ключу), filtering (верни все записи по условию), aggregation (посчитай сумму/среднее/минимум).

Протестировали 15 моделей (от Llama-3.1-8B до GPT-4o) с разными промптами: генерация ответа vs код, с схемой и без, с рассуждениями (CoT) и без. Измеряли точность по трём метрикам: exact match (строгое совпадение), contains (результат содержится в ответе), LLM as a judge (семантическое совпадение).

Результаты удивили: Даже GPT-4o достиг только 77% на лучшем подходе. Код побеждал ответ в 13 из 15 моделей. Схема давала +12% для кода, +7% для прямых ответов. При увеличении JSON с 10K до 80K токенов — точность падала на 7% (GPT-4o) до 91% (Mistral-large). Recency bias (позиция ответа в списке) влиял на 5-75% в зависимости от модели.

Критический инсайт: Когда упростили JSON до минимума (oracle projection — оставили только нужные поля), точность подскочила на 8-38 пунктов. Это значит, шум и сложность структуры — главный враг точности. Модели могут справиться, если дать им чистую, упрощённую версию.


📄

Оригинал из исследования

Контекст: Исследователи использовали этот промпт для генерации кода с полной схемой и ответом.

You will be given a JSON object as data which is a response from a REST API containing information returned from the API call.
You will be given a JSON schema of the response from the REST API returned from the API call.
Your task is to extract and return information from the JSON object which follows the JSON schema and answers the user query: <<task_prefix>>

You need to write a Python function that:
- Starts the function with "def".
- Takes only the entire api response as input and doesn't have any other input.
- Identifies the structure of the input data, ensuring it checks for relevant keys and data types.
- When comparing strings, it should always convert both sides of the comparison to lowercase.
- Processes the provided data.
- Iterates through the data to extract relevant information.
- Cleans numeric strings by removing non-numeric characters before converting them to integers.
- Performs proper checks to ensure a key exists and is not None before querying its value.
- Returns only the requested data as a string and no other extra information or words.
- Do not add any extra keys or terms to the output.

Final Check:
- The function must be formatted in Python markdown for direct execution.
- No explanations, comments, or additional text should be included.
- Do not include any example usage data.

The JSON schema of the object given as data is as follows: <<json_schema>>

data = <<json_obj>>

Python Function:

💡

Адаптации и экстраполяции

💡 Адаптация для таблиц в PDF:

Та же логика работает для извлечения данных из таблиц. Вместо JSON — HTML-таблица или Markdown-таблица из PDF.

Вот таблица из PDF-отчёта в Markdown-формате.

Напиши Python-функцию, которая:
1. Парсит таблицу (можешь использовать pandas)
2. Фильтрует строки где {условие}
3. Возвращает результат списком

Таблица:
{markdown_table}

Python-функция:

💡 Адаптация для вложенных словарей:

Если структура очень сложная (API возвращает 5 уровней вложенности), попроси модель сначала упростить, потом обработать:

Вот сложный JSON с 5 уровнями вложенности.

Шаг 1: Напиши функцию flatten_json(), которая упростит структуру до 2 уровней
Шаг 2: Напиши функцию extract_data(), которая найдёт {что нужно} в упрощённом JSON

JSON:
{данные}

🔧 Техника: Добавь debug-вывод → видишь логику

В шаблоне промпта добавь:

- Добавь print() на каждом шаге обработки для отладки

Получишь код с print(f"Найдено {len(items)} элементов") — видишь как модель рассуждает. Полезно для проверки логики.

🔧 Техника: Замени безликие переменные на говорящие → меньше ошибок

Вместо:

for item in data:
 if item['key'] == value:

Попроси:

- Используй говорящие названия переменных (apartment вместо item, price вместо value)

Модель генерирует более читаемый код, меньше путается.


🔗

Ресурсы

How Good Are LLMs at Processing Tool Outputs? https://github.com/LongFuncEval/toolJSONprocessing

Kiran Kate, Yara Rizk, Poulami Ghosh, Ashu Gulati, Tathagata Chakraborti, Zidane Wright, Mayank Agarwal — IBM Research, USA; Persistent Systems; Grab


📋 Дайджест исследования

Ключевая суть

Обнаружено: Даже топовые LLM катастрофически плохи в прямой обработке JSON – GPT-4o достигает максимум 77% точности. Модели теряются в структуре, путают похожие ключи (name, room_name, full_name), сбиваются на вложенности. При росте размера до 80K токенов Mistral-large проседает на 91%. Метод позволяет извлекать данные из сложных JSON-ответов API с точностью до 95% – особенно для фильтрации и агрегации. Фишка: вместо "прочитай JSON и ответ дай" → "напиши Python-функцию, которая распарсит JSON". Код выполняется – результат точный. Добавь схему JSON в промпт – +12% точности. Даже сокращённый пример структуры работает, если полный ответ не влезает в контекст.

Принцип работы

Не проси модель читать структуру → попроси написать код который прочитает. Переводишь задачу из пространства "понимания данных" в "написание кода". Вместо "найди все двушки до 15 млн с балконом" (модель лезет в JSON на глаз) → "напиши функцию def filter_apartments(data): которая вернёт отфильтрованный список". Код однозначенif item['price'] <= 15000000 не может быть понят двояко. Python для парсинга JSON – родная территория для LLM.

Почему работает

Модели теряются в структуре при прямом чтении. Берут значения из не тех объектов, путают ключи, на вложенности глубже 3 уровней точность падает в пол. Это как искать строку в Excel-таблице на 100 листов. Но модели отлично знают синтаксис Python для работы с JSON. Код компактнее – функция на 20 строк вместо текстового ответа на 200 слов, плюс исполняется без двусмысленности. Схема JSON работает как карта местности – модель видит типы данных, вложенность, связи. Для сложных задач (фильтрация + агрегация) улучшение достигает 50% по сравнению с прямым ответом.

Когда применять

Работа с API и инструментами → конкретно для фильтрации и агрегации JSON-ответов (отобрать объекты по условиям, посчитать средние, сгруппировать), особенно когда ответ большой (50K+ токенов) или сложная вложенность (3+ уровня). НЕ подходит для извлечения одного простого значения ("What is the price?") – там прямой ответ иногда точнее.

Мини-рецепт

1. Добавь схему JSON в промпт: Покажи структуру с типами данных – {"apartments": [{"price": "number", "rooms": "number"}]}. Это карта для модели.

2. Сформулируй задачу как требования к функции: "Напиши Python-функцию, которая: принимает JSON как словарь, фильтрует по условиям X и Y, возвращает результат строкой".

3. Укажи требования к коду: Начинается с def, проверяет существование ключей перед обращением, сравнивает строки в lowercase, очищает числовые строки (убирает "$", пробелы).

4. Если JSON большой (50K+ токенов): Дай сокращённый пример структуры – один объект каждого типа. Полный JSON не влезает в контекст – пример показывает реальные значения.

5. Выполни сгенерированный код: Запусти функцию в локальном Python или через инструмент code execution в чате.

Примеры

[ПЛОХО] : Вот JSON с квартирами из API Авито. Найди все двушки до 15 млн с балконом, выведи адреса списком. (Модель лезет в JSON на глаз, путает ключи has_balcony и balcony_type, теряет объекты на 3 уровне вложенности)
[ХОРОШО] : Вот JSON-ответ от API Авито с квартирами и схема этого JSON. Напиши Python-функцию, которая: 1) Принимает весь JSON как словарь, 2) Фильтрует квартиры где rooms == 2, price <= 15000000, has_balcony == true, 3) Возвращает список адресов строкой через запятую. Требования к коду: начинается с "def", проверяет существование ключей, сравнивает строки в lowercase. Схема JSON: {"apartments": [{"address": "string", "price": "number", "rooms": "number", "has_balcony": "boolean"}]} (Модель генерирует функцию def filter_apartments(data): с точной логикой – точность 95% vs 60% при прямом чтении)
Источник: How Good Are LLMs at Processing Tool Outputs?
ArXiv ID: 2510.15955 | Сгенерировано: 2026-01-11 23:26

Проблемы LLM

ПроблемаСутьКак обойти
Модель теряется в структуре JSONДаёшь модели JSON от API. Просишь найти нужные данные. Модель путает похожие ключи (name, room_name, full_name). Берёт значения из не тех объектов. Сбивается на вложенности (массив внутри объекта внутри массива). Чем больше JSON — тем хуже: при 50K+ символов точность падает в разы. Проблема для любых задач где нужно обработать ответ API или инструментаНе проси модель читать JSON напрямую. Вместо "прочитай и ответь" проси "напиши Python-функцию которая распарсит и вернёт ответ". Добавь схему JSON в промпт — модель увидит структуру как карту. Для больших ответов (50K+) дай сокращённую версию: один пример каждого типа объекта

Методы

МетодСуть
Генерация кода для парсинга вместо прямого ответаВместо "вот JSON, найди X" "вот JSON и схема, напиши Python-функцию которая найдёт X". Модель пишет код типа def parse(data): return [item for item in data if item['price'] < 15000]. Код выполняется — получаешь результат. Почему работает: Код однозначен. if price <= 15000 не может быть понят двояко. Функция на 20 строк компактнее текстового ответа на 200 слов. Python для парсинга JSON — родная территория модели. Усиление: добавь схему JSON (+12% точности), дай пример структуры даже если полный ответ не влезает. Когда применять: фильтрация данных, агрегация (суммы, средние), множественные условия. Когда не работает: простое извлечение одного значения ("What is the price?") — там иногда прямой ответ точнее
📖 Простыми словами

Обработка JSON в LLM: когда код лучше слов

arXiv: 2510.15955

Суть в том, что современные нейронки, несмотря на всю свою крутость, по-прежнему пасуют перед обычными таблицами и JSON-файлами. Когда ты скармливаешь модели огромный массив данных из API, она не «видит» структуру целиком, а читает её последовательно, как текст. В итоге, если данных много, у модели начинается когнитивная перегрузка: она путает вложенные поля, теряет ключи и начинает банально галлюцинировать, выцепляя цифры из соседних объектов. Прямая обработка данных для LLM — это билет в один конец до ошибки, особенно если нужно что-то посчитать или отфильтровать.

Это как если бы ты попросил гуманитария найти одну конкретную опечатку в бухгалтерском отчёте на тысячу страниц, просто листая его перед глазами. Формально он читает, но на сотой странице мозг превращается в кашу, и он начинает путать дебет с кредитом. Вместо того чтобы заставлять человека мучиться, проще дать ему калькулятор и научить писать простенькие формулы. В мире AI этот «калькулятор» — генерация Python-кода, который делает всю грязную работу за модель.

Исследование четко разделяет два подхода: прямой ответ и программная обработка. Выяснилось, что когда модель сначала пишет скрипт на Python для парсинга JSON, а потом просто запускает его, точность взлетает до небес. Вместо того чтобы гадать, в каком поле лежит цена квартиры, модель создает четкий алгоритм фильтрации. Это работает безотказно: Python-код не ошибается в индексах, в отличие от нейронки, которая может «забыть» закрывающую скобку или перепутать похожие названия ключей вроде room_id и room_name.

Тестировали это на сложных задачах вроде поиска квартир по куче параметров, но принцип универсален. Это касается любого взаимодействия с внешними инструментами и API. Если твоя задача сложнее, чем «перескажи этот абзац», заставлять модель анализировать сырые данные напрямую — полный провал. Будь то финансовые отчеты, логи серверов или база клиентов, схема одна: модель должна выступать в роли архитектора, который пишет код, а не чернорабочего, который перебирает строки вручную.

Короче: забудь про попытки скормить нейронке «простыню» JSON и надеяться на адекватный результат. Если хочешь, чтобы AI реально помогал в аналитике, используй метод Code-as-Intermediary. Пусть модель пишет код для обработки данных, а не пытается быть этим кодом сама. Точность выше, галлюцинаций меньше, а ты не тратишь время на проверку каждой цифры за «умным» ассистентом, который опять всё перепутал.

Работа с исследованием

Адаптируйте исследование под ваши задачи или создайте готовый промпт на основе техник из исследования.

0 / 2000
~0.5-2 N-токенов ~10-30с
~0.3-1 N-токенов ~5-15с