Типы промптов

Промптинг для структурированного вывода: JSON, схемы и ограничения

Как получить надёжный JSON и другой структурированный вывод от LLM. Ограничения вывода, схемы, функции структурированного вывода у провайдеров и проверка.

  • Автор: Vijayraj Palanisamy
  • Обновлено
  • 4 мин чтения

Перевод английского оригинала. Код, промпты и вывод моделей оставлены на английском.

Когда код читает ответ модели, «почти правильная форма» — это ошибка. Промптинг для структурированного вывода — это набор практик, благодаря которым модель каждый раз возвращает данные, которые ваша программа может разобрать: определённый формат, явные ограничения и проверка.

Три уровня надёжности

Уровень Как Гарантия
Только промпт Описать формат в промпте Никакой. Обычно верно, иногда нет
Режим JSON Попросить у API ответ в JSON Корректный JSON, но не ваша схема
Вывод, ограниченный схемой Передать API схему JSON Schema Вывод соответствует схеме

Используйте самый сильный уровень, который предлагает ваш провайдер. OpenAI, Anthropic и Google предоставляют способ ограничить ответ схемой или схемой входных данных инструмента. Промпт важен на любом уровне, потому что схема управляет формой вывода, а промпт — его содержанием.

Как записывать ограничения вывода в промпте

Укажите формат, поля, типы и допустимые значения. Затем скажите, чего быть не должно.

Extract the order details from the email in the tags.

Return a JSON object with exactly these fields:
- "order_id": string, as written in the email
- "items": array of {"name": string, "quantity": integer}
- "total": number, without currency symbol
- "currency": one of "USD", "EUR", "GBP"

If a field is not present in the email, use null.
Return only the JSON object, with no explanation and no code fence.

<email>
{{email}}
</email>

Четыре детали в этом промпте предотвращают большинство сбоев:

  1. «Ровно эти поля» не даёт модели добавлять «полезные» лишние.
  2. Допустимые значения для currency исключают «US dollars» и «$».
  3. Правило для null даёт модели корректный способ сказать «не найдено», чтобы она не выдумывала значение.
  4. «Верни только JSON» убирает фразу-комментарий, ломающую JSON.parse.

Проектируйте схему для модели

Схема — часть промпта. Модель читает имена и описания полей как инструкции.

  • Называйте поля по содержимому. shipping_address лучше, чем addr2.
  • Добавляйте описания к полям, смысл которых неочевиден, включая единицы и формат: «дата ISO 8601, UTC».
  • Используйте перечисления (enum), когда у поля фиксированный набор значений.
  • Держите структуру плоской. Глубокая вложенность увеличивает число ошибок. Очень сложное извлечение разбейте на цепочку промптов.
  • Ставьте рассуждение перед ответом. Если вам нужны и объяснение, и вердикт, расположите поля в порядке "reasoning", затем "verdict". Модель пишет поля по порядку, поэтому рассуждение, написанное первым, может повлиять на вердикт.

Не только JSON

Структурированный вывод — это не только JSON.

  • Markdown с фиксированными заголовками подходит для ответов, которые читают люди: «Используй ровно эти заголовки: Резюме, Риски, Следующие шаги».
  • Теги в стиле XML легко извлекаются регулярным выражением и допускают свободный текст внутри: <answer>…</answer>.
  • Один токен — самый надёжный формат из всех. Для классификации просите только метку.
  • CSV или таблицы подходят для небольших регулярных данных; правила кавычек становятся хрупкими со свободным текстом.

Выбирайте самый простой формат, способный нести информацию.

Ограничения длины и содержания

Ограничения вывода касаются также размера и стиля:

- At most 3 bullet points, each under 20 words.
- Use only facts from the document. If the document does not say, write "not stated".
- Write in the present tense.

Задавайте размеры числами. «Кратко» — не то ограничение, на которое могут опираться парсер или вёрстка.

Всегда проверяйте

Даже при выводе, ограниченном схемой, проверяйте данные перед использованием.

  • Разбирайте и проверяйте по схеме каждый ответ. Ответ может оборваться при достижении лимита выходных токенов, оставив обрезанный JSON.
  • Проверяйте семантику, которую схема выразить не может: итог равен сумме позиций, дата не в будущем.
  • Решите, что делать при сбое. Повторите один раз, включив ошибку проверки в промпт, затем перейдите на запасной вариант или пометьте для проверки человеком.
  • Никогда не выполняйте структурированный вывод вслепую. Поле, которое превращается в SQL-условие, путь к файлу или аргумент оболочки, требует такой же очистки, как и пользовательский ввод. См. безопасность промптов.

Типичные сбои

Сбой Причина Исправление
Текст до или после JSON Нет указания «только» Добавьте его или используйте режим JSON
Завёрнуто в блок кода Привычка модели Напишите «без блока кода» или уберите его в коде
Выдуманные значения Нет правила для недостающих данных Добавьте правило для null или «не указано»
Лишние поля Свободная формулировка Напишите «ровно эти поля»; запретите дополнительные свойства
Обрезанный вывод Достигнут лимит вывода Увеличьте лимит или разбейте задачу
Непоследовательное написание значений enum Значения не перечислены Перечислите допустимые значения

Проверка промпта до запуска

Отсутствие формата вывода — самое частое замечание к промптам, которые питают код. Анализатор промптов PromptFlowEngine сообщает о нём, а также об отсутствии указаний о длине и переменных без разделителей. Шаблон извлечения в JSON — полный пример, проходящий все проверки.

О том, как это вписывается в код приложения, см. промпт-инжиниринг для разработчиков.

Применить на практике

Попробуйте: анализатор промптов

Находит неоднозначности, недостающий контекст, противоречия и лишние токены в любом промпте. Бесплатно, детерминированно и без аккаунта.

Связанные инструменты PromptFlowEngine

Ещё по теме «типы промптов»

Все руководства по промпт-инжинирингу