Схемы инструментов и функций

Вызов функций позволяет модели запросить выполнение действия вашим кодом. Каждый инструмент объявляется с именем, описанием (когда его использовать) и схемой JSON для его параметров.

Модель никогда не запускает код; она выдаёт структурированный запрос на вызов, который ваша среда выполнения направляет на обработку. Именно схема делает аргументы пригодными для разбора.

Определение инструмента — это объявление возможности, обёрнутое в схему.

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

• Указывайте, когда использовать инструмент, а когда не использовать.
• Отличайте его от родственных инструментов.
• Упоминайте необходимые предварительные условия.

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

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

Современные модели могут запрашивать несколько вызовов инструментов за один ход, если действия независимы. Ваша среда выполнения должна перебрать все tool_calls, выполнить их (по возможности параллельно) и вернуть одно сообщение инструмента для каждого tool_call_id.

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

Управляйте выбором с помощью tool_choice:

• auto — модель решает.
• required — необходимо вызвать какой-либо инструмент.
• {name: ...} — принудительно выбрать конкретный инструмент.
• none — отключить инструменты на этот ход.

Принудительный выбор конкретного инструмента превращает вызов функций в обычное структурированное извлечение.

Даже при строгих схемах рассматривайте аргументы инструмента как ненадёжные входные данные. Повторно проверьте их по схеме и примените бизнес-правила, прежде чем обращаться к реальным системам (базам данных, платежам, удалению файлов).

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

Делайте ошибки понятными для исправления: указывайте причину и, если это безопасно, совет по восстановлению.

Десятки инструментов снижают точность выбора и увеличивают стоимость токенов (каждая схема присутствует в контексте на каждом ходу). Возможные меры:

• Объединяйте связанные действия за одним инструментом с перечислением action.
• Динамически предоставляйте только инструменты, относящиеся к текущему состоянию.
• Используйте пространства имён, чтобы уменьшить путаницу между похожими инструментами.

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

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

Модель выдаёт два независимых вызова инструментов в одном сообщении ассистента. Что должна сделать ваша среда выполнения?

Схемы инструментов и функций на практике:

• Описания определяют выбор, а схемы — аргументы, пригодные для разбора.
• Обрабатывайте все вызовы инструментов в цикле и поддерживайте параллельное выполнение.
• Управляйте поведением с помощью выбора инструмента; принудительно выбирайте инструмент для простого извлечения данных.
• Перепроверяйте аргументы и возвращайте структурированные ошибки.
• Сократите набор доступных инструментов и усильте защиту деструктивных операций.

Далее: циклы исправления и проверки на случай, если результат всё ещё получается неверным.