Когда код читает ответ модели, «почти правильная форма» — это ошибка. Промптинг для структурированного вывода — это набор практик, благодаря которым модель каждый раз возвращает данные, которые ваша программа может разобрать: определённый формат, явные ограничения и проверка.
Три уровня надёжности
| Уровень | Как | Гарантия |
|---|---|---|
| Только промпт | Описать формат в промпте | Никакой. Обычно верно, иногда нет |
| Режим 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>
Четыре детали в этом промпте предотвращают большинство сбоев:
- «Ровно эти поля» не даёт модели добавлять «полезные» лишние.
- Допустимые значения для
currencyисключают «US dollars» и «$». - Правило для null даёт модели корректный способ сказать «не найдено», чтобы она не выдумывала значение.
- «Верни только 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 — полный пример, проходящий все проверки.
О том, как это вписывается в код приложения, см. промпт-инжиниринг для разработчиков.