Как оценивать качество tool calling в LLM: метрики, сценарии и CI-проверки
Tool calling (или function calling) — ключевой механизм, позволяющий LLM взаимодействовать с внешними API, базами данных и сервисами. Без него невозможно построить работающего AI-агента. Однако сама по себе способность модели вызывать функции не гарантирует корректной работы в продакшене: модель может выбрать неверный инструмент, передать неправильные параметры или вызвать функцию в неподходящий момент.
Эта статья — не очередной обзор того, как работает tool calling. Это практический гайд по его оценке: какие метрики действительно важны, как собрать тестовый набор сценариев и как встроить проверки в CI/CD, чтобы не выпускать в прод агента, который кладёт базу данных.
Почему стандартных тестов недостаточно
Большинство разработчиков проверяют tool calling «на глаз»: запускают несколько примеров в ноутбуке, смотрят, вызвалась ли функция, и считают задачу решённой. Такой подход не работает по нескольким причинам.
Во-первых, LLM — вероятностные системы. Один удачный прогон не гарантирует, что следующий будет таким же. Исследование Gorilla (Patil et al., 2023) показало, что даже при одинаковых промптах модели могут выдавать разные наборы параметров в до 30% случаев.
Во-вторых, ошибки tool calling часто проявляются только на граничных случаях: когда модель должна не вызывать функцию, когда параметр должен быть null, или когда нужно выбрать между двумя похожими инструментами. Эти сценарии редко попадают в ручное тестирование.
В-третьих, оценка качества tool calling — это не бинарная метрика «вызвал/не вызвал». Важны корректность выбора функции, точность параметров, время ответа и стоимость. Без системного подхода вы рискуете выпустить агента, который будет вызывать платные API с неверными аргументами.
Ключевые метрики для оценки tool calling
Перед тем как писать тесты, нужно определить, что именно вы измеряете. На основе документации OpenAI, Anthropic и исследований в области evaluation, можно выделить четыре группы метрик.
Точность выбора функции (Function Selection Accuracy). Модель должна выбрать правильный инструмент из доступного набора. Это базовая метрика: если модель вызывает не ту функцию, дальнейшие проверки теряют смысл. Измеряется как доля случаев, когда выбранный tool ID совпадает с эталонным.
Корректность параметров (Parameter Correctness). Даже если функция выбрана верно, параметры могут быть неверными. Здесь важно проверять не только типы данных, но и семантику: например, для функции поиска авиабилетов дата должна быть в будущем, а количество пассажиров — положительным числом. Сложность в том, что LLM могут генерировать синтаксически корректный JSON с логически неверными значениями.
Полнота вызова (Call Completeness). Модель может пропустить обязательные параметры или, наоборот, добавить лишние. В документации OpenAI по function calling подчёркивается, что модель иногда «забывает» передать required-поля, особенно если их много. Метрика отслеживает, совпадает ли набор переданных параметров с ожидаемым.
Стабильность при повторных вызовах (Consistency). Сколько раз из десяти модель выдаст одинаковый результат на один и тот же запрос? Низкая стабильность — признак того, что промпт или схема функций настроены неоптимально. В исследовании Berkeley Function Calling Leaderboard (BFCL) этот показатель используется как один из ключевых.
Сбор тестового набора: что должно быть в датасете
Для осмысленной оценки нужен тестовый набор, покрывающий реальные сценарии использования. Недостаточно взять пять примеров из документации — этого хватит только для поверхностной проверки.
В хороший тестовый набор входят:
Позитивные сценарии (happy path). Запросы, где модель должна вызвать конкретную функцию с конкретными параметрами. Например: «Найди билеты из Москвы в Санкт-Петербург на завтра» — ожидаемый вызов search_flights с параметрами origin=«Moscow», destination=«Saint Petersburg», date=«2026-09-08».
Негативные сценарии (edge cases). Ситуации, где модель не должна вызывать функцию. Например: «Привет, как дела?» — никакой вызов не требуется. Или запрос с недостаточной информацией: «Найди билеты» — функция search_flights требует обязательных параметров, модель должна запросить уточнение, а не вызывать функцию с пустыми значениями.
Конфликтующие сценарии (disambiguation). Запросы, которые могут соответствовать нескольким функциям. Например, «Добавь событие в календарь» и «Добавь задачу в список» — модель должна выбрать правильный инструмент на основе контекста диалога.
Сценарии с нестандартными параметрами. Даты в разных форматах, валюты, единицы измерения. Модель должна корректно преобразовывать входные данные в ожидаемый формат параметров.
Интеграция проверок в CI
Ручной прогон тестов при каждом изменении кода или промпта — путь к ошибкам. Tool calling evaluation должна быть частью CI/CD пайплайна.
Запуск тестов при изменении схем функций. Любое добавление, удаление или изменение tool definition должно триггерить полный прогон тестового набора. Это позволяет сразу увидеть, как изменение одной функции повлияло на вызовы других.
Пороговые значения. Определите минимальные acceptable thresholds для каждой метрики. Например: точность выбора функции не ниже 95%, корректность параметров — не ниже 90%. Если прогон показывает значения ниже порога, пайплайн падает, и изменения не мержатся.
Регрессионное тестирование. Сохраняйте результаты предыдущих прогонов. При изменении промпта или модели сравнивайте метрики: если точность упала на 5%, нужно разбираться, что пошло не так.
Интеграция с LLM-as-judge. Для автоматической оценки корректности параметров можно использовать другую LLM (например, GPT-4o или Claude 3.5 Sonnet) в роли judge. Она получает запрос, ожидаемый вызов и фактический вызов, и оценивает, насколько они совпадают. Этот подход описан в ряде работ по LLM evaluation, но требует осторожности: judge-модель тоже может ошибаться.
Практические инструменты и фреймворки
Для организации evaluation не обязательно писать всё с нуля. Существуют готовые инструменты:
Berkeley Function Calling Leaderboard (BFCL). Открытый бенчмарк с набором тестовых сценариев для function calling. Позволяет сравнивать разные модели по единым метрикам. Можно использовать его датасет как основу для своих тестов.
LangSmith / LangFuse. Платформы для observability LLM-приложений, которые поддерживают трекинг tool calls. Позволяют логировать каждый вызов, параметры и результаты, а затем анализировать статистику по метрикам.
Pytest + LLM-клиенты. Простой, но эффективный подход: пишете тесты на pytest, которые отправляют запросы к модели через API (OpenAI, Anthropic) и проверяют ответы. Для автоматической валидации параметров можно использовать Pydantic или JSON Schema.
Пример минимального теста:
python
def test_search_flights_correct_parameters():
messages = [{«role»: «user», «content»: «Найди билеты из Москвы в Питер на завтра»}]
response = client.chat.completions.create(
model=»gpt-4″,
messages=messages,
tools=flight_tools
)
tool_call = response.choices[0].message.tool_calls[0]
assert tool_call.function.name == «search_flights»
params = json.loads(tool_call.function.arguments)
assert params[«origin»] == «Moscow»
assert params[«destination»] == «Saint Petersburg»
assert datetime.fromisoformat(params[«date»]) > datetime.now()
Ограничения и подводные камни
Даже при тщательной настройке evaluation есть несколько моментов, о которых стоит помнить.
Тестовый набор устаревает. Если вы добавили новую функцию, но не обновили тесты, вы не узнаете, как модель ведёт себя с ней. Регулярно пересматривайте и дополняйте датасет.
LLM-as-judge не идеален. Модель-оценщик может иметь собственные bias: например, быть более строгой к одним типам ошибок и снисходительной к другим. Используйте несколько judge-моделей и сравнивайте их результаты.
Метрики не заменяют A/B тестирование. Даже если все метрики в порядке, это не гарантирует, что агент будет хорошо работать с реальными пользователями. Evaluation — это первый фильтр, а не финальный вердикт.
Стоимость прогонов. Полный прогон тестового набора из 100–200 сценариев может стоить несколько долларов при использовании коммерческих моделей. Включайте это в бюджет разработки.
Что делать с результатами
После каждого прогона вы получаете набор метрик. Как на них реагировать?
Если упала точность выбора функции, проверьте, не изменились ли описания (descriptions) в tool definitions. Часто проблема в том, что описания стали менее конкретными или пересекаются между разными функциями.
Если упала корректность параметров, обратите внимание на формат, в котором модель получает данные от пользователя. Возможно, нужно добавить инструкцию по преобразованию форматов в системный промпт.
Если стабильность ниже 80%, попробуйте уменьшить temperature модели или добавить few-shot примеры в промпт.
Если полнота вызова страдает, проверьте, не слишком ли много required-параметров у функций. Разбиение одной сложной функции на несколько более простых часто улучшает этот показатель.
Практическая проверка для вашего агента
Начните с малого: выберите 10–15 ключевых сценариев, которые покрывают основные функции вашего агента. Напишите автоматические тесты на pytest, добавьте их в CI и установите пороговые значения. После каждого изменения промпта или набора инструментов прогоняйте тесты и сравнивайте метрики с предыдущим прогоном.
Это не решит всех проблем, но отсечёт самые очевидные ошибки до того, как они попадут к пользователям. А по мере накопления тестового набора вы сможете точнее понимать, как изменения влияют на поведение модели — и принимать решения на основе данных, а не догадок.
Источники: документация OpenAI по function calling, документация Anthropic по tool use, Berkeley Function Calling Leaderboard, исследование Gorilla (UC Berkeley, 2023), работа «Evaluating LLMs for Tool Use» (arXiv:2405.13011).