OpenAI GPT 2026: Function Calling, Structured Outputs и JSON Schema

Дата сверки — 18 августа 2026. Поля и поведение — по руководству OpenAI Function Calling и руководству Structured Outputs. Здесь нет выдуманных задержек, цен и долей успеха. Где публичная документация ничего не фиксирует, явно написано: «проверить на replay живого трафика».

Если вы переводите OpenAI-совместимый бэкенд на другую модель, структурированный вывод и цикл инструментов нужно принимать отдельно — одной сменой Base URL недостаточно. См. внутренний чек-лист миграции OpenAI API на Kimi K3.

Сначала вывод: меняются три вещи сразу

Многие репозитории всё ещё живут моделью 2024 года: в промпте «верни JSON», потом regex по code fence. В проде 2026 это рвёт парсер через нарушения схемы, отсутствующие поля и галлюцинации enum.

Менять нужно три слоя, а не имя модели побольше:

Контракт поставки

Объект для пользователя или downstream — через Structured Outputs (text.format в Responses, response_format.json_schema в Chat Completions).

Контракт исполнения

Когда модель вызывает ваши инструменты, аргументы должны совпадать с JSON Schema инструмента. Это Function Calling — тот же constrained decoding, что у Structured Outputs.

Контракт совместимости

Старый JSON Mode (json_object) гарантирует только «похоже на JSON», не поля, типы и enum относительно схемы. В доке это предшественник Structured Outputs. Новым проектам не стоит делать его основным путём.

Ещё один продуктовый сдвиг, который легко пропустить: новый код должен идти через Responses API. Chat Completions по-прежнему доступен, но стратегия strict по умолчанию другая — Responses старается нормализовать схему в строгий режим и откатывается только при неудаче; у Chat Completions по умолчанию по-прежнему non-strict / best effort.

Модель и основной API-путь: gpt-5.6 + Responses

Structured Outputs доступны начиная с поколения GPT-4o. Для новых проектов в документации предлагают сразу gpt-5.6. Более старые снимки вроде gpt-4-turbo и раньше по-прежнему отсылают к JSON Mode, а не к полноценному строгому json_schema.

Сначала разделить два входа

На стороне SDK привычка важнее: не писать схему вручную (легко забыть additionalProperties), а генерировать её из типов официальными хелперами. Python: client.responses.parse(..., text_format=YourModel); JavaScript: zodTextFormat. При рукописной схеме и strict: true нарушение ограничений даёт отклонение запроса, а не «модель выдала что попало, вы ретраите».

Сравнивая с линейкой Gemini, «совместимость с OpenAI SDK» не означает то же поведение схемы. Обновления возможностей Google: 10 новых функций Gemini 3.5 Pro. Когда одну и ту же JSON Schema копируют между провайдерами, правило additionalProperties на вложенных object часто взрывается первым.

JSON Mode, Structured Outputs, Function Calling

Самая частая путаница в инцидентах: в логах JSON, значит Structured Outputs уже включены. По официальной семантике:

Когда Function Calling не нужен

Если модель не должна трогать вашу систему (нет склада, тикетов, скриптов), а ответ лишь раскладывается в карточки, шаги или оценки — Structured Outputs. Как только вывод означает «выполни этот побочный эффект», нужны tools: не маскируйте аргументы функции под схему финального ответа.

Отказ — это не «битый JSON»

При safety-отказе модель не запихивают в вашу схему. Responses / Chat Completions отдают отдельное поле refusal. Слой разбора должен считать отказ гражданином первого класса: сначала refusal, потом output_parsed — пустой объект не успех.

Жёсткие правила Strict JSON Schema

После включения strict OpenAI принимает подмножество JSON Schema, а не любой документ Draft 2020-12. Три самых частых отказа на уровне запроса:

1. Каждое поле из properties должно быть в массиве required.
2. Каждый object (включая вложенные) должен иметь additionalProperties: false.
3. Корневой объект не может быть anyOf; опциональность — через «обязательное + разрешён null», например ["string", "null"].

То есть: убрать поле из required и притвориться, что оно опционально — под strict это сразу 400. Правильно: поле остаётся required, тип — nullable union, приложение трактует null как «не задано».

Типичный прод-объект «извлечь тикет» — у вложенного object тоже есть additionalProperties:

from openai import OpenAI
from pydantic import BaseModel

client = OpenAI()

class Ticket(BaseModel):
    title: str
    priority: str
    assignee: str | None
    tags: list[str]

response = client.responses.parse(
    model="gpt-5.6",
    input=[
        {"role": "system", "content": "Извлеки поля тикета из описания пользователя."},
        {"role": "user", "content": "Страница входа 500, назначить Noah, приоритет высокий, теги auth и api."},
    ],
    text_format=Ticket,
)
ticket = response.output_parsed
print(ticket.title, ticket.priority, ticket.assignee)

Если запрос отклонён, сначала смотрите в ошибке, какого ограничения не хватает — не понижайте модель сразу. Схемы из Playground уже со strict; скопировать их в репозиторий обычно быстрее, чем переделывать старые промпты json_object.

Между вендорами проверьте ещё раз: та же схема «у каждого object false» на части совместимых шлюзов или других моделях может дать HTTP 400. Тогда нужна трансформация по провайдеру, а не три бизнес-схемы.

Function Calling 2026: strict, tool_search, custom tools

Function Calling и tool calling в документации — одно и то же: JSON Schema описывает вызываемые функции, исполнитель в приложении делает побочные эффекты. Несколько пунктов, которые в 2026 подчёркивают отдельно, сразу меняют цикл агента.

Значение strict по умолчанию не угадывать

• Рекомендуют всегда явно ставить strict: true.
• Responses: если strict опущен, сервер пытается нормализовать схему; при неудаче откат в non-strict, в ответе у tool будет strict: false.
• Chat Completions: без указания по умолчанию non-strict.
• У дообученных моделей при нескольких вызовах функций за один ход документация допускает отключение strict на этот ход.

Определения инструментов входят в контекст и тарифицируются как input-токены. Слишком длинные description и 40 инструментов сразу бьют и по счёту, и по точности выбора. Если инструментов много — откладывайте редкие через tool_search: только gpt-5.4 и новее. В цикле сначала могут появиться tool_search_call / tool_search_output, и лишь потом настоящий function_call.

Custom tools: не запихивайте DSL в JSON-объект

Function tools подходят для структурированных параметров; custom tools — для свободного текста на входе и выходе, с опциональной контекстно-свободной грамматикой (CFG). Фрагменты SQL, внутренние языки запросов, форматы с взаимоисключающими терминалами: CFG стабильнее, чем «string-поле плюс простыня промпта». Если CFG ругается на unexpected tokens, сначала ищите пересекающиеся терминалы, а не вините модель.

tools = [{
    "type": "function",
    "name": "get_order",
    "description": "Запросить статус заказа по номеру. Вызывать только если пользователь указал конкретный номер заказа.",
    "strict": True,
    "parameters": {
        "type": "object",
        "properties": {
            "order_id": {"type": "string"},
            "locale": {"type": ["string", "null"]},
        },
        "required": ["order_id", "locale"],
        "additionalProperties": False,
    },
}]

Цикл исполнения не изменился: увидели finish_reason / тип item = вызов инструмента → локальная функция → вернуть результат в роли tool → новый запрос. Изменилось другое: аргументы больше не нужно ловить через json.loads наудачу. Полное сообщение assistant (включая tool_calls) всё равно нужно сохранять, иначе на втором ходе пропадут ID вызовов.

Чек-лист миграции старых проектов

Разделите приёмку «оно крутится» и «это можно отдавать». Оставьте переключатель на старый бэкенд и сначала прогоните реальный трафик в изолированной среде.

1. Модель: новая цепочка явно на gpt-5.6 (или эквивалентный уровень, уже открытый на аккаунте); шлюз не должен молча маппить на старый снимок.
2. Вывод: заменить json_object на json_schema + strict: true или на text.format в Responses.
3. Инструменты: у каждой function полный required и вложенный additionalProperties: false; опциональные поля — nullable union.
4. Разбор: подключить parse() и ветку refusal; в стриминге сверить инкрементальный JSON с финальным parsed-объектом.
5. Поверхность инструментов: больше десятка — оценить tool_search; сначала укоротить description, потом отложенную загрузку.
6. Сравнение: один и тот же набор фиксированных задач — ретраи, доля отсутствующих полей, ручная доработка между старым JSON Mode и новым путём схемы.

Критерий прохождения — не HTTP 200, а: парсер без regex-подстраховки, стабильные типы аргументов инструментов, наблюдаемые отказы, уже отработанный переключатель отката. Долгие сессии SDK, скрипты replay и вкладки браузера обрываются, когда ноутбук засыпает — отсюда облачный Mac mini ниже.

FAQ