Function Calling

Function Calling позволяет модели выбрать описанную функцию и вернуть её имя с JSON-аргументами. Функцию выполняет приложение, а не сама LLM. Поэтому схема, права, бизнес-правила и подтверждение опасных действий остаются за обычным кодом.

Коротко

Function calling позволяет модели попросить приложение выполнить конкретную функцию: узнать статус заказа, найти документ или создать черновик письма. Модель выбирает имя функции и её аргументы, а приложение проверяет запрос и решает, выполнять ли его.

Зачем это нужно

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

Примеры:

• get_order_status читает заказ;
• search_documents находит документы;
• calculate_tax выполняет расчёт;
• create_email_draft создаёт черновик;
• schedule_event меняет календарь после подтверждения.

Модель выбирает действие по описанию и контексту, но фактический API-вызов делает приложение.

Схема функции

Описание обычно содержит имя, назначение и JSON Schema аргументов.

{
  "name": "get_weather",
  "description": "Получить прогноз для города и даты",
  "parameters": {
    "type": "object",
    "properties": {
      "city": { "type": "string" },
      "date": { "type": "string", "format": "date" }
    },
    "required": ["city", "date"],
    "additionalProperties": false
  }
}

Это пример описания функции, а не готовый запрос к конкретному API. Модель получает имя, назначение и схему аргументов, по которой приложение сможет проверить ответ.

Поле format: "date" само по себе не гарантирует проверку даты: некоторые валидаторы воспринимают его лишь как подсказку. Проверку формата нужно включить или выполнить отдельно. Допустимость даты — например, принимает ли сервис прогнозов запрос на этот день, — проверяет уже приложение.

Полный цикл

1. Приложение отправляет модели сообщение и список функций.
2. Модель отвечает текстом или предложением вызова.
3. Код разбирает имя и JSON.
4. Валидатор схемы проверяет типы и обязательные поля.
5. Сервер проверяет пользователя, права и бизнес-ограничения.
6. Функция выполняется или отклоняется.
7. Результат возвращается модели как отдельное сообщение.
8. Модель формирует ответ пользователю или предлагает следующий вызов, если данных ещё не хватает.

Каждый шаг должен обрабатывать ошибку: неизвестную функцию, неверный JSON, тайм-аут и повторный вызов.

Схема проверяет форму, а не смысл

Аргумент amount: 100000 может быть корректным числом и недопустимым переводом. Адрес может соответствовать формату email и принадлежать не тому получателю.

После проверки структуры приложение выясняет, кто делает запрос и имеет ли он право на действие. Затем проверяет допустимые значения и текущее состояние объекта. Для изменений важны защита от повторного выполнения и запись результата в журнал. Рискованные действия — например, перевод денег — дополнительно подтверждает человек.

Схема умеет ограничивать диапазоны чисел и списки значений. Но она не узнает сама, хватает ли денег на счёте и разрешён ли перевод именно этому пользователю.

Промпт «не делай опасного» не заменяет эти проверки.

Наглядный пример

Пользователь пишет: «Перенеси встречу с редактором на завтра после обеда».

Помощник сначала вызывает чтение календаря. Если время неоднозначно, задаёт вопрос. Затем предлагает reschedule_event с конкретным ID и временем.

Приложение показывает изменение человеку. Только после подтверждения выполняется запись. Для этого действия приложение создаёт ключ идемпотентности — уникальный идентификатор операции. Если сервер поддерживает такую защиту, повтор сетевого запроса с тем же ключом не создаст новое изменение или повторное уведомление.

Как описывать функции

Хорошее описание отвечает на четыре вопроса:

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

manage_order слишком широко. Лучше разделить чтение и запись: get_order, create_refund_draft, confirm_refund.

Узкие функции проще выбирать, тестировать и ограничивать.

Несколько вызовов

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

Для агентского цикла задаются пределы:

• число шагов;
• время;
• токены и деньги;
• разрешённые домены;
• максимальный объём результата;
• условия остановки.

Function calling и structured output

Оба механизма используют схемы, но решают разные задачи.

• Structured output задаёт форму конечного ответа.
• Function calling описывает промежуточное внешнее действие.

Можно вызвать функцию, затем вернуть пользователю JSON по другой схеме.

Function calling, tool calling и MCP

В некоторых API function calling и tool calling — почти синонимы. Иногда tools — более широкая категория, куда входят поиск, выполнение кода и работа с файлами.

MCP стандартизирует связь между хостом и внешним сервером инструментов. Приложение-хост может получить описание инструмента через MCP, а модели представить его в формате вызова функций, который поддерживает её API.

Безопасность

И аргументы от модели, и результат внешнего инструмента могут содержать ошибочные или вредоносные данные.

• SQL строится параметризованным запросом, а не строкой модели.
• Путь нормализуется и остаётся в разрешённой папке.
• Веб-адрес проверяется по списку разрешённых направлений, включая адрес назначения после перенаправлений. Это помогает избежать SSRF — обращения сервера к закрытым внутренним ресурсам по чужой инструкции.
• Секрет не возвращается модели.
• Вывод веб-страницы не становится инструкцией автоматически.
• Для удаления, отправки и оплаты приложение проверяет, что пользователь разрешил именно это действие с этими данными. Когда такого разрешения нет или риск высок, запрашивает подтверждение.

Логи не должны хранить токены, пароли и лишние персональные данные.

Частые ошибки

• Исполнять JSON сразу. Нужны проверка схемы и прав.
• Давать функции пересекающиеся описания. Модель путает выбор.
• Скрывать побочный эффект. Название должно честно отражать запись или удаление.
• Не обрабатывать повтор. Один запрос способен выполнить действие дважды.
• Передавать слишком много функций. Выбор оценивается на тестах, а каталог можно подгружать по контексту.
• Доверять тексту результата. В нём может быть ошибка API или чужая инструкция, выдающая себя за команду помощнику.

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

Какие модели поддерживают function calling?

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

Можно ли заставить модель выбрать одну функцию?

Многие API имеют режим обязательного или фиксированного выбора. Точный синтаксис относится к платформе, а аргументы всё равно проверяет приложение.

Что вернуть модели после ошибки?

Короткий структурированный результат с типом ошибки и безопасным пояснением. Подробности внутреннего сбоя и секреты остаются в защищённом журнале, а не в сообщении модели.

Нужен ли function calling, если порядок действий уже известен?

Не обязательно. Если порядок заранее известен, прямой код проще и предсказуемее. Модель полезна там, где выбор действия зависит от естественного запроса.

Главное

Function calling превращает намерение модели в проверяемое предложение внешнего действия. Модель выбирает имя и аргументы, а приложение сохраняет контроль: проверяет схему, права, повторы и подтверждение. Без этих проверок даже правильно оформленный вызов может выполнить не то действие.

Источники

• JSON Schema: типы и проверка форматов
• MCP: инструменты и контроль вызовов