Обычный ответ модели — свободный текст. Разбирать его программно тяжело: сегодня модель напишет «Цена: 1200 ₽», завтра — «стоит примерно тысячу двести». Структурированный вывод снимает эту проблему: ответ приходит строго в форме, описанной заранее.
Значение response_format | Что гарантирует |
|---|---|
{"type": "json_object"} | Ответ будет корректным JSON. Какие в нём окажутся поля — на усмотрение модели |
{"type": "json_schema", ...} | Ответ будет соответствовать переданной схеме: те же поля, те же типы |
Первый режим годится, когда форма ответа некритична и достаточно избавиться от лишних слов вокруг. Второй нужен, когда ответ попадает прямо в код или в базу.
Схема описывается в формате JSON Schema. Флаг strict включает строгую проверку — без него схема считается пожеланием, а не требованием.
curl "https://api.proxyapi.ru/v1/chat/completions" \ -H "Content-Type: application/json" \ -H "Authorization: Bearer <КЛЮЧ>" \ -d '{ "model": "openai/gpt-5-mini", "messages": [ {"role": "user", "content": "Ноутбук, 14 дюймов, 89990 рублей, в наличии"} ], "response_format": { "type": "json_schema", "json_schema": { "name": "product", "strict": true, "schema": { "type": "object", "properties": { "title": {"type": "string"}, "price": {"type": "number"}, "in_stock": {"type": "boolean"} }, "required": ["title", "price", "in_stock"], "additionalProperties": false } } } }'
Структура ответа не меняется: JSON приходит строкой в том же поле choices[0].message.content, что и обычный текст. Разница в содержимом — вместо предложения там документ, готовый к разбору.
{"title": "Ноутбук 14 дюймов", "price": 89990, "in_stock": true}
Строгий режим накладывает ограничения, и задаёт их конечный сервис, а не ProxyAPI. Общие для большинства моделей:
- все поля перечислены в
required— необязательных нет; - у каждого объекта проставлено
"additionalProperties": false; - поддерживается не весь JSON Schema: часть ключевых слов, вроде ограничений на длину строки, игнорируется.
Необязательное поле обычно выражают через тип-объединение: ["string", "null"].
Строгий режим доступен не у каждой модели. Если она его не поддерживает, конечный сервис либо ответит ошибкой 400, либо проигнорирует схему и вернёт обычный текст. Поэтому разбор ответа лучше оборачивать в проверку, а не полагаться на формат вслепую.
- Вызов функций — когда от модели нужен не ответ, а обращение к коду.
- Генерация текста — устройство запроса и ответа.
Частые вопросы
Чем json_schema отличается от json_object?
Режим json_object гарантирует только то, что ответ будет корректным JSON — набор полей модель выбирает сама. Режим json_schema закрепляет конкретную структуру: поля, типы и вложенность.
Почему в строгой схеме все поля обязательные?
Такое требование предъявляет конечный сервис. Необязательное поле описывают через объединение типов, разрешая наряду с основным типом значение null, и модель возвращает null, когда значения нет.
Почему ответ приходит строкой, а не объектом?
Структура ответа API не меняется: JSON лежит в поле message.content как текст. Его нужно разобрать самостоятельно — стандартными средствами языка.
Что делать, если модель не поддерживает схему?
Ответом будет либо ошибка 400, либо обычный текст вместо JSON. Варианта два: выбрать модель с поддержкой строгого режима или описать нужный формат в системном сообщении и проверять результат на своей стороне.
Последняя редакция: 2 сентября 2026 г.