Гайд · TNWS AI

Как настроить Function Calling в OpenAI API: схема, выполнение и второй запрос

OpenAI APIPythonNode.jsChatGPT#OpenAI API #Function Calling #разработка

12 сентября 2026 5 мин—

Как описать функцию для модели, проверить аргументы, выполнить код на сервере и вернуть результат в Responses API.

Что даст этот гайд

Задача — разрешить модели запрашивать строго описанную функцию, не давая ей прямого доступа к базе или внешнему API. Результатом должен стать воспроизводимый рабочий сценарий, который другой человек сможет повторить по тем же входным данным. Перед настройкой запишите критерий успеха: конкретный формат ответа, обязательные поля и ситуацию, в которой процесс обязан остановиться.

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

Что подготовить до начала

Понадобятся серверный обработчик функции, JSON-схему аргументов, тестовый API без необратимых действий и журнал вызовов. Работайте сначала на тестовой копии. Удалите пароли, ключи, персональные данные и закрытые документы, если их обработка не согласована. Секреты храните в переменных окружения или менеджере секретов.

Создайте таблицу контроля: ID теста, вход, ожидаемый результат, фактический результат, источник, статус. Добавьте минимум пять кейсов: обычный, пустой, без нужного факта, с противоречием и с запрещённым действием. Это позволит увидеть регрессию после изменения модели, SDK или инструкции.

Пошаговая настройка

Опишите функцию в массиве tools: задайте уникальное имя, назначение и JSON Schema для аргументов. Укажите обязательные поля и запретите лишние, если это поддерживает выбранная схема. Первый ответ модели может содержать function call — это запрос на действие, а не выполненное действие.

На сервере разберите аргументы, проверьте типы, права пользователя и допустимые значения. Никогда не подставляйте аргументы модели напрямую в SQL или shell. Выполните разрешённую функцию и отправьте результат обратно в контекст как output соответствующего вызова. Затем запросите финальный ответ модели. Для операций удаления, оплаты или отправки добавьте ручное подтверждение независимо от уверенности модели.

После первого успешного ответа сохраните точный запрос, параметры, идентификаторы ресурсов и дату. Не ограничивайтесь скриншотом: текстовый журнал проще сравнивать и повторять. Если действие затрагивает внешнюю систему, добавьте идемпотентный ключ или другой механизм защиты от повторного выполнения.

Готовый промпт

Замените значения в квадратных скобках и сохраните получившуюся версию рядом с тестами:

Используй функцию get_order_status только если во входе есть order_id. Не придумывай идентификатор. Перед вызовом кратко сообщи, какие данные нужны. После результата функции объясни статус без добавления сроков, которых функция не вернула.

Не добавляйте расплывчатые требования вроде «ответь максимально умно». Для фактической задачи важнее перечислить разрешённые источники, формат, правило для отсутствующих данных и критерий остановки. Если результат читает программа, валидируйте JSON до использования полей.

Практический пример

Вход

Пользователь: «Где мой заказ 5842?» Функция принимает order_id строкой и возвращает status=packed, eta=null.

Ожидаемый результат

Модель вызывает функцию с 5842, затем сообщает, что заказ собран. Она не обещает доставку завтра, потому что eta отсутствует.

Повторите пример с одним отсутствующим значением. Корректный процесс должен вернуть null, «нет данных» или понятный статус, предусмотренный вашей схемой. Правдоподобная подстановка опаснее явной ошибки, потому что может незаметно попасть в следующий этап.

Проверка результата в три прохода

Технический проход: запрос завершился, формат читается, идентификаторы не потеряны, секреты не попали в ответ или лог. Смысловой проход: минимум три факта сверены с исходником; отдельно проверены числа, даты и отрицания. Процессный проход: повторный запуск не создаёт дубликат и корректно обрабатывает таймаут или недоступность сервиса.

Меняйте только один параметр за итерацию. Если одновременно заменить модель, промпт и входные данные, причину изменения качества определить невозможно. Сохраняйте старую рабочую версию до завершения проверки.

Чек-лист

задача сформулирована через проверяемый результат;
границы и запрещённые действия указаны явно;
используются тестовые или разрешённые данные;
названия функций сверены с официальным источником;
секреты отсутствуют в коде, тексте запроса и открытом логе;
обычный сценарий проходит от начала до конца;
пустой вход обрабатывается предсказуемо;
отсутствие факта не превращается в догадку;
ключевые числа, даты, имена и URL сверены вручную;
повторный запуск не создаёт необратимый дубль;
сохранены инструкция, параметры и дата проверки.

Как сделать процесс полезнее

Назначьте владельца сценария. Он отвечает не за каждое нажатие, а за актуальность документации, тестов и критериев. В журнале фиксируйте найденный дефект и конкретное исправление: «добавили обязательное поле source», а не «улучшили промпт».

Раз в несколько изменений запускайте старый набор тестов целиком. Новый удачный пример не должен ломать обработку пустых данных или запрещённых действий. Для автоматизированного процесса задайте порог остановки: неверный формат, отсутствующий ID, ошибка авторизации или неподтверждённое критичное поле.

Минимальный журнал качества

Для каждой попытки сохраняйте пять значений: идентификатор входа, версия инструкции, итоговый статус, обнаруженная проблема и решение проверяющего. Полный текст чувствительного запроса в журнале не нужен — используйте обезличенный ID. Раз в неделю или после заметного обновления выберите десять записей разных типов и пересмотрите их вручную. Такой небольшой аудит показывает систематические ошибки: например, модель стабильно теряет единицы измерения или приложение повторно вызывает инструмент после таймаута. Исправляйте сначала процесс и валидацию, а уже затем формулировку промпта.

Ограничения

Function Calling не является песочницей безопасности. Модель предлагает аргументы, а доверенный код обязан проверять авторизацию, диапазоны и последствия. Доступность функций, модели, форматы запросов, тарифы и лимиты могут меняться. Перед внедрением перепроверьте соответствующий раздел официальной документации, а не стороннюю статью или старый пример.

FAQ

Можно ли сразу подключать рабочие данные?

Нет. Сначала прогоните сценарий на обезличенной копии, проверьте ошибки и права. Рабочие данные подключайте только после согласования режима обработки.

Почему недостаточно успешного статуса API?

Он подтверждает обработку запроса, но не истинность вывода. Значимые факты нужно сверять с исходником или результатом доверенной функции.

Что делать, если ответ меняется между запусками?

Зафиксируйте вход и параметры, уменьшите свободу формата, добавьте схему и автоматические проверки. Для творческой задачи вариативность допустима, для извлечения фактов — обычно нет.

Как обновлять такой процесс?

После изменения SDK, модели, схемы или источника повторите весь набор тестов. Сравните результаты построчно и сохраните причину принятого изменения.

Первоисточник и дата проверки

Функции и названия параметров сверены 11 сентября 2026 года: официальное руководство OpenAI по Function Calling. Численные тарифы и лимиты намеренно не приведены: их следует проверять на официальной странице непосредственно перед использованием.

Частые вопросы

Можно ли использовать рабочие данные сразу?

Сначала проверьте сценарий на обезличенной копии и согласуйте обработку данных.

Достаточно ли статуса 200?

Нет. Он подтверждает обработку запроса, но не корректность фактов и действий.

Как тестировать обновления?

Повторяйте одинаковый набор обычных, пустых, противоречивых и запрещённых сценариев.

Где хранить ключ API?

В переменной окружения или менеджере секретов, но не в коде и промпте.