TL;DR
Когда вы отдаёте LLM структурированные данные — таблицу, JSON, список — способ их форматирования меняет точность ответа сильнее, чем кажется. Исследование проверило четыре формата подачи одних и тех же медицинских данных: сырой JSON, таблицу Markdown, нарративный текст и хронологическую ленту. Для небольших моделей (~7–8B параметров) нарратив с явными заголовками разделов оказался лучше сырого JSON на 19 процентных пунктов точности. Для больших моделей (~70B) картина перевернулась — сырой JSON дал лучший результат.
Главная находка касается не формата, а типа ошибок: LLM пропускает элементы значительно чаще, чем выдумывает несуществующие. Во всех 20 комбинациях моделей и форматов точность (precision) превышала полноту (recall). Это значит: когда вы просите LLM извлечь список чего-либо, она вернёт вам часть правильных элементов, а не смесь правильных и ложных. Проблема — в пропусках, не в галлюцинациях.
Дополнительный потолок — длина списка. Маленькие модели перестают работать надёжно при попытке перечислить больше 7–10 элементов одновременно. Причём дело не в длине входного текста — длинные истории с малым числом активных пунктов модели обрабатывали хорошо. Проблема именно в размере выходного списка.
Схема метода
Это не один промпт-метод, а три извлекаемых принципа из исследования:
ПРИНЦИП 1: Формат данных
→ Для больших моделей (Claude, GPT-4o): сырой JSON и таблицы — ОК
→ Для меньших моделей: нарратив с явными заголовками > структура
ПРИНЦИП 2: Тип ошибок
→ LLM пропускает элементы, не выдумывает
→ Проверяй на полноту, не только на правдивость
ПРИНЦИП 3: Ёмкость списков
→ Просишь перечислить > 10 элементов → жди пропусков
→ Дроби на части: «первые 5», потом «следующие 5»
Пример применения
Задача: Ты ведёшь небольшой онлайн-магазин на Wildberries. Тебе нужно разобрать выгрузку из личного кабинета — 23 SKU с продажами, возвратами и остатками — и найти позиции, требующие пополнения склада.
Вместо того чтобы вставить сырую таблицу Excel и спросить «что нужно пополнить?», применяем принцип нарративного формата:
**Промпт:**
Я веду магазин на Wildberries. Ниже — данные по остаткам товаров за
последние 30 дней. Найди все позиции, которым грозит out-of-stock
в ближайшие 14 дней при текущем темпе продаж.
Критерий: остаток < скорость продаж × 14 дней.
ТОВАРЫ НА СКЛАДЕ (требуют мониторинга):
- Кроссовки белые р.38: остаток 12 шт., продаётся 2 шт./день
- Сумка кожаная чёрная: остаток 3 шт., продаётся 1 шт./день
- Толстовка серая XL: остаток 45 шт., продаётся 1 шт./день
[...остальные позиции...]
ТОВАРЫ ВНЕ МОНИТОРИНГА (уже в пополнении или сняты с продажи):
- Куртка синяя р.46: снята с продажи 10.05
- Ремень коричневый: уже заказан у поставщика
Верни список только тех позиций, которым грозит out-of-stock.
Без объяснений — только список названий.
Результат: Модель вернёт список позиций, которым грозит обнуление склада. Важно: если позиций больше 10–12, проверь ответ — часть может быть пропущена. Лучше разбить на две части: «проверь первые 10 позиций», потом «проверь следующие 10».
Почему это работает
Проблема с форматом. Когда вы даёте LLM сырую таблицу или JSON, модель должна одновременно разобрать структуру и решить задачу. Это два шага сразу, и на первом часть внимания уходит на то, чтобы понять «где тут нужные поля». Нарративный формат с явными заголовками снимает первую задачу — модель сразу видит, что важно.
Почему большие модели обходятся без этого. Claude и GPT-4o — это модели уровня 70B+ и выше. Для них разбор структуры не стоит усилий — они обрабатывают JSON не хуже нарратива. Поэтому на больших моделях можно смело кидать таблицы и JSON без ручного переформатирования.
Почему модели пропускают, а не выдумывают. LLM генерирует ответ последовательно, слово за словом. Остановиться раньше — легко. Добавить лишнее к уже сказанному — сложнее (особенно при температуре 0 и чёткой инструкции). Поэтому при любом формате ошибка «не упомянул» встречается чаще, чем «придумал несуществующее». Это меняет логику проверки: не «правда ли это?», а «всё ли это?».
Рычаги управления: - Явное разделение «активное / историческое» в заголовках раздела → модель не тратит логику на классификацию, сразу работает с нужными данными - Число элементов в запросе → если больше 10, дроби на части или проси «перечисли порциями по 5» - Фраза «верни только список, без объяснений» → снижает «мусор» в ответе и уменьшает число пропусков у маленьких моделей (меньше токенов тратится на рассуждения)
Шаблон промпта
Принцип 1 — нарративный формат с явными заголовками:
Ниже — данные по {тема}. Найди все {что искать}.
{НАЗВАНИЕ РАЗДЕЛА 1 — то, что нужно проверять}:
- {элемент 1}: {параметр А}, {параметр Б}
- {элемент 2}: {параметр А}, {параметр Б}
{НАЗВАНИЕ РАЗДЕЛА 2 — то, что не нужно трогать}:
- {элемент}: {причина исключения}
Верни только список {что искать}. Без объяснений.
Принцип 2 — дробление длинных списков:
Это первая из {N} частей данных по {тема}.
{данные — не более 8-10 элементов}
Найди {что искать} в этой части.
Сохрани результат — в следующем сообщении будет вторая часть.
Принцип 3 — проверка на полноту:
Я дам тебе {список/данные}. Твоя задача — убедиться, что ничего не пропущено.
{данные}
Сначала перечисли все элементы, которые видишь в данных — даже те, что
не подходят под критерий. Потом из этого полного списка выдели {что искать}.
Плейсхолдеры:
- {тема} — что анализируем: товары, задачи, транзакции, позиции в смете
- {что искать} — критерий отбора: «с риском просрочки», «без исполнителя», «требующие доплаты»
- {НАЗВАНИЕ РАЗДЕЛА} — явный заголовок типа «АКТИВНЫЕ ЗАДАЧИ», «УЖЕ ЗАКРЫТО», «ВНЕ РАМОК ПРОЕКТА»
- {N} — число частей при дроблении
🚀 Быстрый старт — вставь в чат:
Вот шаблон для подачи структурированных данных в LLM.
Адаптируй под мою задачу: [опиши задачу].
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит про тему анализа, что именно искать и как разделить данные на разделы — потому что для нарративного формата важно правильно назвать группы, чтобы модель сразу поняла, что приоритетно.
Ограничения
⚠️ Для крупных моделей (Claude, GPT-4o): Нарративный формат не даёт преимущества перед сырым JSON — большие модели справляются одинаково хорошо в обоих форматах. Переформатировать данные вручную ради красоты не стоит.
⚠️ Потолок длинных списков: Даже у крупных моделей точность падает при попытке вытащить 10+ элементов одним запросом. Нарративный формат смягчает, но не снимает эту проблему.
⚠️ Точного совпадения строк: В исследовании считали только дословные совпадения. В реальности у LLM точность выше — «аспирин 100мг» и «Aspirin 100 MG Oral Tablet» это одно. Реальные пропуски меньше, чем в цифрах исследования.
⚠️ Хронологический формат — ловушка: Подача данных строго по времени без разделения «актуальное/историческое» оказалась худшим вариантом даже для самой крупной модели. Если у тебя в данных есть «живые» и «архивные» записи — разделяй их явно, а не по дате.
⚠️ Медицинский домен ≠ гарантия: Модель, обученная на медицинских текстах (BioMistral), но без instruction tuning, вернула ноль полезного вывода. Доменные знания без умения следовать инструкциям — бесполезны.
Как исследовали
Исследователи взяли 200 синтетических пациентов с генерированными медицинскими историями и спросили пять разных LLM — от маленькой 3.8B до большой 70B — один и тот же вопрос: «какие лекарства сейчас активны у этого пациента?». Но каждую из четырёх версий формата подачи данных (сырой JSON, таблица, нарратив, хронология) тестировали отдельно. Итого 4000 запросов.
Интересное решение дизайна: для сырого JSON пришлось вводить обрезку — полные истории некоторых пациентов не помещались в контекст маленьких моделей (один пациент = 800 000 строк JSON). Это само по себе аргумент против сырого JSON в production-системах с небольшими моделями.
Удивительная находка: история записей не влияла на точность. Модели одинаково хорошо обрабатывали пациентов с 10-летней и 25-летней историей болезни. Ломались они только когда нужно было перечислить много активных позиций одновременно — не читать длинный текст, а написать длинный список. Узкое место — в генерации ответа, не в чтении данных.
Ещё один неожиданный результат: BioMistral — модель специально дообученная на медицинских текстах — вернула мусор на всех 200 пациентах и всех четырёх форматах. Ноль полезного вывода. Это разрушает интуитивное «возьми специализированную модель для специализированной задачи» — если у модели нет instruction tuning, она не умеет следовать инструкциям независимо от своего «экспертного» обучения.
Ресурсы
Название: Serialisation Strategy Matters: How FHIR Data Format Affects LLM Medication Reconciliation
Авторы: Sanjoy Pator (Independent Researcher)
Связанные работы: LLMonFHIR (Schmiedmayer et al., 2025, Stanford), FHIR-GPT (Li et al., 2024), Asgari et al. 2025 (оценка галлюцинаций в клинических текстах)
Инструменты из исследования: Synthea (генератор синтетических пациентов), Ollama (локальный запуск моделей)