Как проверить, что LLM вызывает инструменты по назначению
Если языковая модель умеет вызывать функции, это ещё не значит, что агент правильно использует инструменты. Он может выбрать не тот инструмент, передать в него неверный аргумент или запустить действие, когда достаточно ответить текстом. Чтобы обнаружить такие ошибки до интеграции с реальными системами, проверяйте вызовы отдельно: на фиксированном наборе сценариев, с известными ожидаемыми действиями и безопасными заглушками вместо рабочих API.
В этом руководстве — узкий тест для цепочки «запрос пользователя → решение модели → вызов инструмента». Он не оценивает качество итогового ответа целиком и не доказывает безопасность агента. Его задача — показать, насколько предсказуемо модель выбирает действие и формирует аргументы в заданных условиях.
Что именно считать правильным вызовом инструмента
Рассматривайте вызов как структурированное решение, а не просто как JSON, прошедший проверку схемы. Для каждого тестового запроса отдельно оцените четыре пункта:
Нужен ли инструмент вообще. На вопрос, ответ на который уже есть в контексте, модель не должна запускать ненужный поиск или изменять данные.
2. Верно ли выбрана функция. Например, для получения сведений о заказе не должна вызываться функция отмены.
3. Правильны ли аргументы. Имена полей, типы и значения должны соответствовать запросу и контракту инструмента.
4. Допустимо ли последующее действие. Если инструмент меняет состояние — отправляет письмо, удаляет файл или оформляет заказ, — вызов должен соответствовать явному намерению пользователя и правилам подтверждения.
Эти пункты нельзя сводить к одному показателю. Корректный JSON может содержать неверный идентификатор, а правильная функция — сработать без необходимого подтверждения. Разделение ошибок помогает понять, что исправлять: описание инструмента, схему, инструкции, маршрутизацию или саму модель.
Как собрать компактный тестовый набор
Начните с 20–50 сценариев, написанных под конкретный контракт инструментов. Такой набор удобен для ручной проверки и повторных запусков, но не гарантирует покрытие всех возможных запросов. Включите не только типичные случаи, но и границы поведения:
- запрос явно требует действия;
- нужная информация уже находится в диалоге;
- пользователь просит то, для чего нет подходящего инструмента;
- не хватает обязательного параметра;
- формулировка допускает два толкования;
- запрос требует изменить данные, но не содержит требуемого подтверждения;
- пользователь просит одно действие, а в контексте упоминается похожее, но другое.
Для каждого случая заранее запишите ожидаемое поведение: конкретный инструмент и аргументы, уточняющий вопрос, текстовый ответ без вызова либо отказ от недоступного действия. Не составляйте эталон после просмотра ответа модели — иначе тест будет подстраиваться под проверяемую систему.
Пример сценария для приложения поддержки:
json
{
«input»: «Покажи статус заказа A-1042»,
«expected»: {
«tool»: «get_order_status»,
«arguments»: {«order_id»: «A-1042»}
}
}
И отрицательный пример:
json
{
«input»: «Какие данные нужны, чтобы узнать статус заказа?»,
«expected»: {
«tool»: null,
«behavior»: «answer_from_context»
}
}
Второй сценарий проверяет не синтаксис, а необходимость действия. Если продукт требует, чтобы статус всегда получался из актуальной системы, задайте ожидаемое поведение иначе — тест должен отражать реальные правила вашего приложения.
Как проверять выбор функции отдельно от аргументов
Первый проход теста должен отвечать на вопрос, выбрала ли модель подходящий инструмент. Сопоставляйте вызванное имя функции с эталоном и считайте результат по сценариям. Для случаев, где вызывать инструмент не нужно, отдельной ошибкой будет любой неожиданный вызов.
Затем проверяйте аргументы. Для структурированных значений применяйте строгую проверку типов и обязательных полей по схеме, а для смысловых значений — отдельные проверки. Например, аргумент `order_id` может быть строкой и пройти JSON Schema, но содержать номер заказа из предыдущего сообщения вместо номера из текущего запроса.
Удобно вести три счётчика:
- точный выбор инструмента — совпало ли имя ожидаемой функции;
- валидность аргументов — прошли ли типы, обязательные поля и ограничения;
- точное соответствие аргументов — совпали ли значения с эталоном или допустимым набором значений.
Не объединяйте точное совпадение и валидность. В некоторых задачах допустимы разные корректные представления аргумента; в других важен конкретный идентификатор. Если сравнение может быть неоднозначным, явно опишите правило нормализации — например, допустимо ли считать `2026-03-01` и `1 марта 2026 года` эквивалентными.
Как сделать тест воспроизводимым
Зафиксируйте конфигурацию, при которой получен результат: версию или идентификатор модели, текст системных инструкций, описания функций, схемы аргументов, настройки генерации и версию тестового набора. В API, где доступен выбор режима или ограничение доступных функций, записывайте и его. Документация OpenAI, Google и Anthropic описывает собственные форматы вызова инструментов; одинаковое по смыслу поведение может быть представлено разными структурами, поэтому сравнивайте нормализованное решение, а не необработанный ответ конкретного API.
Для повторного запуска сохраняйте исходный запрос, ответ модели и разобранный вызов. Если провайдер поддерживает настройку случайности, установите её согласно используемому API, но не считайте это гарантией идентичных результатов: версии моделей и серверная реализация тоже могут влиять на вывод. Запустите каждый сценарий несколько раз и отметьте, где решение меняется.
Простой контур теста выглядит так:
text
для каждого сценария:
отправить запрос и описание инструментов модели
сохранить исходный ответ
извлечь имя инструмента и аргументы
сверить с ожидаемым поведением
выполнить только безопасную локальную проверку
На первом этапе не подключайте тест к платежам, почте или производственным базам. Подмените действия моками: функция возвращает заранее заданный результат, но ничего не меняет во внешней системе.
Как оценить лишние вызовы и пропущенные действия
Одной доли успешных вызовов недостаточно. Для сценариев с ожидаемым действием подсчитайте пропуски — модель не вызвала инструмент или выбрала несовместимую функцию. Для сценариев без действия подсчитайте ложные вызовы. Отдельно фиксируйте неверные аргументы, особенно те, что могут выбрать не тот объект или пользователя.
Минимальный отчёт может содержать число сценариев и количество ошибок каждого типа:
text
Всего сценариев: 30
Неверный инструмент: 3
Невалидные аргументы: 2
Лишний вызов: 1
Пропущенное действие: 2
Неустойчивый результат при повторах: 4
Это пример формата отчёта, а не результат реального бенчмарка. Сравнивая две версии модели или инструкций, прогоняйте их на одном и том же наборе и публикуйте изменения по категориям ошибок. Не делайте вывод об улучшении по одному общему проценту, если, например, ошибок вызова стало меньше, но участились неверные идентификаторы.
Для инструментов с побочными эффектами нужен отдельный критерий: вызов допустим только при выполнении условий вашего продукта. Например, если удаление требует подтверждения, проверьте пары сценариев «удали файл» и «какие файлы можно удалить?». Сам факт, что модель выбрала функцию удаления, не является достаточным основанием запускать её.
Как проверить запросы с нехваткой данных и неоднозначностью
Добавьте случаи, где обязательного параметра нет. Если функция требует `order_id`, а пользователь просит «покажи мой заказ», корректное поведение зависит от доступного контекста и правил приложения. Модель может задать уточняющий вопрос или использовать идентификатор из проверенного контекста, если это разрешено. Тест должен однозначно отражать, какой источник данных допустим.
Также проверьте конфликтующий контекст: пользователь сначала назвал один адрес, затем исправил его; в сообщении цитируется чужой запрос; в истории есть несколько объектов одного типа. Оценивайте не только JSON, но и то, какую информацию модель использовала для его заполнения.
Если модель получает результат инструмента и решает, что делать дальше, это уже тест цепочки, а не только первичного вызова. Набор ToolSandbox от Berkeley NLP полезен как пример исследования взаимодействий с инструментами в многосоставных задачах и состояниях среды. Его результаты нельзя автоматически переносить на ваш продукт: набор, доступные действия и критерии могут отличаться от ваших.
Как встроить проверку в разработку
Храните тестовые сценарии рядом с описаниями инструментов и запускайте их после изменений схем, инструкций, модели или логики маршрутизации. Полезно отмечать, какие случаи проверяют критические действия, чтобы ошибка в таком сценарии не терялась среди малозначимых расхождений.
При изменении модели сначала сравните результаты на прежнем наборе, затем добавьте отдельные регрессионные примеры для обнаруженных ошибок. Не удаляйте неудобный тест только потому, что новая версия на нём проваливается. Если эталон был некорректен, исправьте его с пояснением причины.
Наконец, отделяйте тест вызова от проверки самого инструмента. Модель может правильно сформировать запрос, а API — вернуть неверный или устаревший результат. И наоборот, инструмент может работать надёжно, но агент вызвать его с чужим идентификатором. Логи, тестовые данные и мок-ответы помогают локализовать этап сбоя, но не заменяют проверку прав доступа, валидацию аргументов на сервере и подтверждение опасных действий.
Следующий практический шаг — выбрать один инструмент с заметными последствиями, описать 20–50 сценариев, запустить их несколько раз на моках и сохранить исходные ответы. Перед подключением к рабочей системе проверьте отдельно права, обязательные подтверждения и поведение при ошибках API: тест выбора функции сам по себе этих гарантий не даёт.
