Строгий JSON и табличный вывод

Чтобы подключить LLM к коду, ответ должен быть данными, а не прозой — учимся получать предсказуемый JSON.

Структурированный вывод — ответ модели в машиночитаемом формате (JSON, таблица) по заранее заданной схеме, который можно распарсить программой.

Опишите схему и дайте пример

Не просто «верни JSON» — покажите точную структуру с типами и пример заполнения. Это резко повышает валидность.

Извлеки данные о товаре. Верни ТОЛЬКО JSON по схеме,
без пояснений и текста вокруг:

{
  "name": строка,
  "price": число,
  "in_stock": булево,
  "tags": массив строк
}

Если поле неизвестно: строку — "", число — 0,
булево — false, массив — [].

Описание: "Кружка керамическая, 590 руб, есть в наличии,
теги: посуда, подарок."

Ожидаемый ответ — чистый JSON, который без проблем парсится.

{
  "name": "Кружка керамическая",
  "price": 590,
  "in_stock": true,
  "tags": ["посуда", "подарок"]
}

Три правила надёжного JSON

  • «Только JSON». Явно запретите вступления вроде «Конечно, вот данные:» — иначе парсер споткнётся.
  • Правила для пустых полей. Опишите, что класть, если данных нет, иначе модель то пропустит ключ, то напишет null, то «неизвестно».
  • Фиксированные ключи. Перечислите ровно те ключи, что нужны; иначе модель добавит «полезных» лишних.

Таблицы

Для отчётов удобнее таблица. Задайте колонки и разделитель.

Сравни 3 тарифа в виде таблицы Markdown с колонками:
Тариф | Цена | Лимит | Поддержка
Только таблица, без текста до и после.

Поддержка на стороне API

Многие провайдеры умеют гарантировать формат на уровне API: режим «JSON mode» или передача JSON-схемы (structured output / tool use), когда модель физически не может вернуть невалидный JSON. Если такой режим доступен — используйте его вместе с понятным промптом: это надёжнее, чем уговоры в тексте. Но даже там понятная схема в промпте улучшает содержание.

Защита парсера

В продакшне всё равно оборачивайте разбор в try/except и при сбое делайте повторный запрос с уточнением «верни строго валидный JSON». Модель — не гарантированный сериализатор, и код должен это учитывать.

Итог

  • Описывайте точную схему с типами и давайте пример заполнения.
  • Требуйте «только JSON», задавайте правила для пустых полей и фиксируйте ключи.
  • Используйте JSON-mode / structured output на уровне API, если он есть.
  • Всё равно защищайте парсинг в коде и предусматривайте повтор.
Проверьте себя
1. Что сильнее всего повышает валидность JSON-ответа от модели?
AПросто написать «верни JSON»
BОписать точную схему с типами, дать пример и правила для пустых полей
CПовысить температуру
DПопросить добавить пояснения вокруг JSON
2. Зачем требовать «только JSON, без текста вокруг»?
AДля красоты
BЧтобы вступительные фразы не ломали парсер на стороне кода
CЧтобы снизить стоимость вдвое
DЭто требование модели
3. Что разумно сделать в продакшн-коде помимо хорошего промпта?
AДоверять, что JSON всегда валиден
BОбернуть парсинг в обработку ошибок и при сбое повторить запрос с уточнением
CОтключить проверки ради скорости
DНикогда не использовать JSON
Поддержать проект