Function calling: как связать нейросеть с вашими сервисами

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

Как это работает

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

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

Ключевой момент, который часто понимают неверно: модель никогда ничего не выполняет сама. Она только предлагает вызов. Исполняет всегда ваш код, и права проверяете тоже вы.

Как описывать инструменты

**Понятное имя и назначение.** Модель выбирает функцию по описанию, поэтому «получить остаток товара по артикулу» работает лучше, чем «метод №3».

**Минимум параметров.** Чем больше аргументов, тем чаще модель ошибается в их заполнении.

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

**Немного инструментов.** Пять-семь штук модель различает уверенно, тридцать — начинает путать.

Что остаётся на вашей стороне

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

Валидация аргументов тоже ваша. Артикул, пришедший от модели, может не существовать, дата — оказаться в прошлом. Проверяйте так же строго, как данные из внешней формы.

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

Типичные сценарии

• Ответ о статусе заказа с обращением к вашей базе.
• Подбор товара по параметрам из каталога.
• Проверка свободных слотов и запись на приём.
• Создание заявки в вашей системе с готовым описанием.
• Поиск клиента и подтягивание истории обращений.

Где ломается

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

Второе место — молчаливые ошибки. Функция вернула пустой результат, модель истолковала это как «ничего нет» и уверенно сообщила об этом пользователю. Возвращайте различимые ответы: пусто, не найдено и ошибка выполнения — три разных случая.

Как это отлаживать

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

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

Типичные поломки и что с ними делать:

• **Вызывается не та функция.** Уточните описания: чаще всего два инструмента описаны похожими словами.
• **Аргументы заполнены неверно.** Сократите число параметров и замените свободные строки перечислениями.
• **Функция вызывается по кругу.** Ограничьте число шагов в одном обмене, иначе модель может уйти в цикл и потратить бюджет.
• **Вызова нет там, где он нужен.** Обычно помогает прямое указание в системной инструкции: при вопросах о статусе заказа всегда обращаться к соответствующему инструменту.

Отлаживайте по одному инструменту за раз. Когда их сразу пять, причину поведения не найти.

С чего начать

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

Если результат устраивает, добавляйте второй инструмент. Наращивать по одному надёжнее, чем описать сразу двадцать и разбираться, почему модель выбирает не то.