Вы передаёте сообщение пользователя в GPT API, и вместо ответа на естественном языке модель возвращает структурированный объект JSON, в котором указано, какую функцию вызвать и с какими аргументами. Это и есть «вызов функций» — и он меняет тип приложений, которые можно строить с LLM.
Большинство разработчиков слышат «вызов функций» и предполагают, что модель исполняет код за них. Это не так.
При использовании вызова функций LLM сама не выполняет функцию. Вместо этого она определяет подходящую функцию, собирает все необходимые параметры и предоставляет информацию в структурированном формате JSON.
Ваше приложение по‑прежнему отвечает за запуск фактической логики. Модель лишь указывает, что нужно запустить и с какими входными данными.
Это различие важнее, чем кажется, и влияет на всё — от архитектуры интеграции до подхода к безопасности.
Что такое вызов функций на самом деле — и в чём люди ошибаются
Вызов функций (он же tool calling) предоставляет мощный и гибкий способ для моделей OpenAI взаимодействовать с внешними системами и получать доступ к данным за пределами их обучающего набора.
Название — первый источник путаницы. Люди думают, что модель что‑то исполняет. Нет.
Существует множество названий и объяснений вызова функций, но всё сводится к одному: «вызов функций — это разновидность возможности структурированного вывода у большой языковой модели». LLM сами не вызывают функции; они предлагают, какую функцию вы должны вызвать из набора заранее определённых функций, которые вы предоставляете LLM в подсказке.
Вторая путаница связана со старым API.
Параметры functions и function_call были помечены как устаревшие с выходом версии API 2023-12-01-preview. Замена для functions — параметр tools.
Если вы следуете руководству, использующему старый параметр functions, вы уже работаете с устаревшим синтаксисом. Вместо этого используйте tools и tool_choice.
Функция — это частный случай инструмента, определённого схемой JSON. Определение функции позволяет модели передать данные вашему приложению, где ваш код может получить доступ к данным или выполнить действия, предложенные моделью.
Именно схема даёт вызову функций преимущество по надёжности над простыми подсказками: вы не надеетесь, что модель правильно отформатирует вывод, вы заставляете соблюсти структуру на уровне API.
Как работает вызов функций в OpenAI API — пошагово
Вызов инструментов — это многошаговый диалог между вашим приложением и моделью через OpenAI API. Поток вызова инструментов включает пять шагов: отправить запрос модели с инструментами, которые она может вызвать...
Вот как каждый из этих шагов выглядит на практике.
Шаг 1: Определите схемы своих функций. Вы описываете каждую доступную функцию как объект JSON внутри параметра tools. Схема включает имя функции, описание на естественном языке, которое модель использует, чтобы решить, когда её вызывать, и блок parameters, соответствующий соглашениям JSON Schema.
Чем детальнее ваш description — в терминах ситуаций, когда функцию можно и нужно вызывать, — тем лучше. Обратите внимание, что описания функций являются частью подсказки и также потребляют токены.
Шаг 2: Отправьте запрос. Вы вызываете Chat Completions API с сообщением пользователя и списком tools. Модель видит оба.
Шаг 3: Модель решает, вызывать ли функцию.
Вызов функции — это специальный тип ответа, который вы можете получить от модели, если она, изучив подсказку, определяет, что для выполнения инструкций ей нужно вызвать один из доступных инструментов. Если модель получает подсказку вроде «какая погода в Париже?», она может ответить вызовом инструмента get_weather с аргументом локации «Paris».
Шаг 4: Ваш код выполняет функцию. Вы парсите ответ модели, извлекаете имя функции и аргументы и запускаете фактический код в своём рантайме. API вернул структурированный JSON — вы решаете, что с ним делать.
Шаг 5: Отправьте результат обратно.
Затем вы отправляете модели все определения инструментов, исходную подсказку, вызов инструмента от модели и вывод инструмента, чтобы наконец получить текстовый ответ
— что‑то вроде «Сегодня в Париже 25°C.»
Одна деталь, которую пропускает большинство руководств:
когда вы устанавливаете strict: true в определении функции, Structured Outputs гарантирует, что аргументы, сгенерированные моделью для вызова функции, в точности соответствуют заданной вами JSON Schema.
Установка strict в true гарантирует, что вызовы функций надёжно соответствуют схеме функции, а не будут «по возможности». OpenAI рекомендует всегда включать строгий режим.
Всегда. Нет ни одной веской причины этого не делать.
Есть и параллельные вызовы функций.
В зависимости от запроса пользователя модель будет вызывать функции параллельно, если используются последние модели, выпущенные 6 ноября 2023 года или позже.
Это означает, что один запрос вроде «какая погода в Лондоне и Токио?» может вызвать два одновременных вызова инструментов, а не последовательную цепочку.
Практические сценарии использования вызова функций
Пример с погодой повсюду, потому что он чистый. Реальные промышленные сценарии — более хаотичны и интересны.
Конвейеры поддержки клиентов с актуальными данными
Вызов функций полезен во множестве сценариев — например, для AI‑ассистента, которому нужно получить последние данные о клиенте из внутренней системы, когда пользователь спрашивает «какие у меня недавние заказы?», прежде чем он сможет сгенерировать ответ.
Модель определяет намерение, извлекает ID клиента из контекста и вызывает внутренний API вашей CRM. Никаких хрупких регулярок. Никаких промптов, которые ломаются из‑за отсутствующей запятой.
Извлечение структурированных данных в масштабе
Ещё один сильный вариант — конвейер извлечения данных, который получает сырой текст, преобразует его в структурированные данные и сохраняет в базу. Вы получаете консистентные схемы по тысячам документов без ручной настройки логики парсинга для каждого типа.
Перевод естественного языка в API
Решения на базе LLM для извлечения и тегирования данных, приложения, которые помогают конвертировать естественный язык в вызовы API или валидные запросы к базе, и диалоговые движки поиска знаний, взаимодействующие с базой знаний, — все они выигрывают от гарантии формата вывода при вызове функций. Когда вам нужно, чтобы вывод управлял downstream‑системами, нельзя терпеть вариативность.
Агентные пайплайны с несколькими инструментами
Для разработчиков вызов функций открывает доступ к актуальным данным, чтобы обойти отсечки по обучению, получая в реальном времени котировки, погоду или свежие записи из базы. Он также позволяет выполнять действия — превращая LLM из пассивного наблюдателя в активного участника, который изменяет состояние, например отправляет письма, обновляет CRM или деплоит код.
Ключевое отличие от обычного чат‑бота: модель не просто генерирует текст, она оркестрирует реальные операции в ваших системах.
Лучшие практики вызова функций — в чём разработчики чаще всего ошибаются
Этот раздел чаще всего полностью пропускают, поэтому команды потом отлаживают странные сбои в проде в 2 часа ночи.
Слишком размытые описания. Модель использует описание функции, чтобы решить, когда её вызывать. Если ваше описание общее — вроде «обрабатывает запросы пользователей», — у модели нет надёжного сигнала, когда её триггерить. Будьте конкретны о триггере и ожидаемой форме ввода. Думайте об описании как о контракте, а не ярлыке.
Предоставление слишком большого числа функций одновременно
Описания функций могут занимать значительное количество токенов во входной подсказке.
Загрузка определений 50+ инструментов в системную подсказку создаёт две проблемы: стоимость и задержки, поскольку определения инструментов потребляют входные токены; и деградацию точности, так как при увеличении числа опций инструментов способности модели выбрать правильный снижаются.
Начинайте с минимального набора функций, который действительно нужен вашему кейсу.
Предполагая, что модель не будет галлюцинировать параметры. Будет.
Модель может галлюцинировать параметры
— особенно для опциональных полей, которые не ограничены явным перечислением. Вот почему strict: true так важен: он исключает возможность модели придумывать поля вне вашей схемы.
Не учитывают многошаговый цикл. Разработчики часто строят «счастливый путь» — пользователь спрашивает, модель вызывает функцию, готово.
Модели могут генерировать вызовы функций, не соответствующие вашей схеме, или пытаться вызвать функцию, которую вы не предоставили. Если модель генерирует неожиданные вызовы, попробуйте добавить в системное сообщение фразу «Используй только те функции, которые тебе предоставлены».
Прорабатывайте крайние случаи.
Пропуск шага подтверждения перед операциями записи.
Осознавайте реальное влияние вызовов функций, которые вы собираетесь исполнять, особенно тех, что инициируют действия вроде выполнения кода, обновления баз или отправки уведомлений. Для функций, которые что‑то делают, настоятельно рекомендуется внедрить шаг, где пользователь подтверждает действие перед исполнением.
Если вызов функции может удалить данные, отправить деньги или изменить внешний статус, человек должен сперва это одобрить.
Соображения безопасности и надёжности
Вызов функций расширяет возможности LLM. Он также расширяет то, что злоумышленник может заставить её сделать.
Основная угроза здесь — prompt‑инъекция.
Цели prompt‑инъекций различны, но могут включать эксфильтрацию приватных данных через downstream‑вызовы инструментов, выполнение несогласованных действий или иное непреднамеренное изменение поведения модели.
Когда ваши функции могут отправлять письма, выполнять запросы к базам или триггерить вебхуки, инъекция — это уже не просто чат‑бот, который ушёл «сценарий», это потенциальная утечка.
По мере того как AI‑системы выходят за рамки чата и начинают вызывать инструменты и выполнять действия, prompt‑инъекция становится гораздо более серьёзной проблемой. Злонамеренная инструкция, скрытая на веб‑странице, в документе или внешнем инструменте, может попытаться переопределить системное поведение, раскрыть чувствительные данные или инициировать действия, которых модель никогда не должна предпринимать.
Стратегия снижения риска включает несколько конкретных уровней.
Проектируйте процессы так, чтобы недоверенные данные никогда напрямую не управляли поведением агента. Извлекайте только конкретные структурированные поля — например, enum или валидированный JSON — из внешних входов, чтобы ограничить перенос риска инъекций между узлами.
Сверх того,
всегда проверяйте вызовы функций, сгенерированные моделью. Это включает проверку параметров, вызываемой функции и соответствия вызова задуманному действию.
Неприятная правда:
«Prompt‑инъекции, как и мошенничество и социальная инженерия в сети, вряд ли когда‑нибудь будут полностью “решены”.»
Это оценка самой OpenAI. Практическое следствие: не стоит проектировать агентные системы с вызовом функций, исходя из предположения, что модель всегда будет вести себя как задумано. Глубоко эшелонированная защита — валидация, ограниченные права, человек‑в‑контуре для деструктивных операций — единственно здравый подход.
Вызов функций vs. инжиниринг подсказок — когда что использовать
Этот вопрос возникает постоянно. Короткий ответ: они решают разные задачи, и их смешение приводит к чрезмерно усложнённым промптам там, где хватило бы вызова функций, или хрупким схемам функций там, где более прост был бы хорошо составленный системный промпт.
Инжиниринг подсказок включает создание текстовых входов, которые направляют внутреннее рассуждение LLM — например, просьбы «думать шаг за шагом».
Он влияет на то, как модель рассуждает. Вызов функций, напротив, определяет, что именно модель выдаёт на выход и как это напрямую маршрутизируется в вашу систему.
Вызов инструментов — это возможность, позволяющая LLM взаимодействовать с внешними системами. Вы используете инжиниринг подсказок, чтобы помочь модели решить, какой инструмент использовать, а вызов инструментов — это механизм, который фактически исполняет действие. Скорее всего, вам нужны оба подхода, но они служат разным целям.
Ключевое техническое преимущество вызова функций над структурированным выводом через подсказки:
вызов инструментов встроен в модель. Нет нужды тратить токены и усилия, пытаясь объяснить модели, что она должна вернуть ответ в конкретном формате.
Когда вы формулируете промпт «верни ответ в JSON с полями X, Y и Z», вы тратите токены на инструкции, которым модель может следовать непоследовательно. С вызовом функций принуждение к схеме происходит на уровне API.
API для вызова функций, которые теперь нативно поддерживаются во многих LLM‑платформах, обеспечивают формальный интерфейс, управляемый схемой, позволяющий строгую валидацию данных и интеграцию с программными конвейерами.
Это и есть практическая причина выбирать его вместо инжиниринга подсказок для любых данных, которые должны попадать в downstream‑системы: надёжность не является опциональной в продакшене.
| Измерение | Инжиниринг подсказок | Вызов функций |
|---|---|---|
| Основная цель | Формировать рассуждение и тон модели | Выдавать структурированный вывод для интеграции с системами |
| Формат вывода | Свободный текст (или текстообразный JSON) | Принудительная схема JSON |
| Надёжность схемы | Best‑effort; склонна к дрейфу | Гарантируется при strict: true |
| Стоимость токенов | Ниже для простых выводов | Выше (определения функций добавляют токены) |
| Когда использовать | Задачи рассуждения, генерация текста, стиль | Извлечение структурированных данных, оркестрация API, экшены |
| Экспозиция к инъекциям | Ниже (нет исполнения внешних инструментов) | Выше (вызовы могут триггерить реальные действия) |
Практическая эвристика: если вывод должен управлять downstream‑системой — запись в базу, вызов API, ветвление решений в коде — используйте вызов функций. Если вывод предназначен для чтения человеком, обычно достаточно инжиниринга подсказок и это дешевле.
Основные выводы
| Тема | Что запомнить |
|---|---|
| Что это | Модель выдаёт структурированный JSON с описанием, какую функцию вызывать — она не исполняет функцию |
| Текущая поверхность API | Используйте tools и tool_choice; старые functions и function_call устарели |
| Строгий режим | Всегда ставьте strict: true в определениях функций для соблюдения схемы |
| Параллельные вызовы | Поддерживаются моделями, выпущенными после ноября 2023; один запрос может вызвать несколько инструментов |
| Стоимость токенов | Схемы функций потребляют входные токены; минимизируйте число доступных функций |
| Безопасность | Валидируйте все выходы вызовов функций; не позволяйте недоверенным данным напрямую управлять вызовами инструментов |
| vs. инж. подсказок | Вызов функций обеспечивает структуру на уровне API; инжиниринг подсказок формирует внутреннее рассуждение |
| Подтверждения | Любая функция с реальными побочными эффектами (запись, отправка, удаление) должна требовать подтверждения пользователя |
Если вы хотите поэкспериментировать с вызовом функций в разных моделях — GPT-5.4, claude opus 4.7, gemini 3.1 pro — без необходимости поддерживать отдельные API‑ключи для каждой, CometAPI предоставляет доступ ко всем через единый эндпоинт и ключ, что существенно снижает трение при кросс‑модельном тестировании.
CometAPI снимает инфраструктурные хлопоты:
✅ Унифицированный синтаксис вызова функций для 15+ моделей
✅ Единый API‑ключ — без отдельных аккаунтов для OpenAI/Anthropic/Google
✅ Автоматическая трансляция схем — пишите один раз, тестируйте везде
✅ Встроенный учёт стоимости — сравнивайте использование токенов по моделям в реальном времени
Начните тестирование с бесплатными кредитами → Получить доступ