Как протестировать точность вызова инструментов в ИИ-агентах

Агент может допустить ошибку в двух местах при использовании инструмента. Он может выбрать не тот инструмент или выбрать правильный, но отправить неверные аргументы.

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

В этом руководстве рассматриваются три способа тестирования поведения при вызове инструментов. Первый — это использование LLM-судьи без эталонных данных. Второй — детерминированные проверки аргументов. Третий — сравнение траекторий. Далее показано, как запускать одни и те же тестовые примеры для нескольких моделей с поддержкой инструментов через OpenRouter.

Кратко

• Тестируйте выбор инструмента и правильность аргументов отдельно. Агент может выбрать неверный инструмент, вызвать его без необходимости или выбрать правильный инструмент и передать неверные аргументы.
• Используйте детерминированные проверки, когда вы знаете ожидаемый инструмент или значение аргумента. Используйте LLM-судью без эталонных данных, когда правильность зависит от контекста или когда допустимыми могут быть несколько вариантов.
• Используйте JSON Schema для выявления некорректных или структурно неверных аргументов, а значения аргументов проверяйте отдельно. Значение, соответствующее схеме, все равно может быть неверным.
• Используйте сравнение траекторий, когда важна последовательность вызовов инструментов. Если к одному и тому же результату можно прийти разными путями, не требуйте строгого соблюдения одной последовательности.
• При сравнении моделей сохраняйте тестовые примеры, правила оценки, настройки моделей и конфигурацию маршрутизации одинаковыми для каждого кандидата.

Два типа ошибок, требующие разных тестов

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

Выбор инструмента

Предположим, внутренний агент поддержки может использовать lookup_order, issue_refund и search_docs.

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

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

Когда ожидается конкретный инструмент, сравните возвращенное имя инструмента с ожидаемым в коде. Если несколько инструментов могут обоснованно решить запрос, точное совпадение может отсеять верный выбор. В этом случае полезнее LLM-судья.

Правильность аргументов

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

Структурная проверка выявляет некорректный JSON, отсутствие обязательных полей, неверные типы, недопустимые значения перечислений (enum) и параметры, которые инструмент не принимает.

Структурно верный вызов все равно может содержать неверное значение.

Если order_id определен как строка, этот полезный груз (payload) соответствует схеме. Но он все равно будет неверным, если пользователь спрашивал об ord_7281.

Существующие фреймворки оценки используют такое же разделение. В DeepEval есть отдельные метрики Tool Correctness и Argument Correctness, а в Phoenix есть отдельный оценщик для выбора инструмента.

Подход 1. LLM-судья без эталонных данных

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

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

Рассмотрим исследовательского агента с инструментами web_search и search_internal_docs. Здесь может не быть одного единственного правильного выбора. Лучший инструмент может зависеть от того, о чем спросил пользователь и какая информация уже доступна в диалоге.

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

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

Если проверка на равенство, валидатор схемы или бизнес-правило могут надежно ответить на тот же вопрос, используйте их.

Подход 2. Детерминированные проверки схемы аргументов

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

Рассмотрим это определение инструмента.

Та же схема, которую вы отправляете модели, может проверять возвращаемые ею аргументы. Она обнаружит отсутствие order_id, строку там, где include_items ожидает логическое значение, или необъявленное поле, например customer_email.

Подход 3. Сравнение траекторий

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

Рабочий процесс возврата средств может требовать трех последовательных вызовов.

Строгое соответствие имеет смысл только тогда, когда порядок обязателен. По этой причине оценщики траекторий в LangSmith поддерживают строгое соответствие, соответствие без учета порядка, а также проверку на подмножество и надмножество. Строгая проверка требует соблюдения одной последовательности. Другие режимы допускают разный порядок или требуют только определенный набор вызовов.

Бенчмарки агентов работают так же. В τ²-bench записанный список действий — это одна эталонная траектория, которая воспроизводится для получения целевого конечного состояния базы данных. Любая последовательность вызовов инструментов, приводящая к эквивалентному конечному состоянию, проходит проверку базы данных.

Если lookup_customer и lookup_subscription могут выполняться в любом порядке, не помечайте последовательность как ошибочную только потому, что в вашем эталоне использовался другой порядок. Оценивайте необходимые вызовы или результирующее состояние.

В одном тестовом примере можно использовать более одной проверки. Например, можно сравнить имя инструмента, проверить его аргументы на соответствие JSON Schema, а затем сравнить известные значения аргументов с ожидаемым полезным грузом.

Запуск одной и той же оценки для разных моделей

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

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

В примере для tool_choice установлено значение "auto". Это значение по умолчанию при предоставлении инструментов, а явное его указание упрощает отслеживание теста без использования инструментов.

В этом примере используется Python SDK от OpenAI с нашей конечной точкой, совместимой с OpenAI. Сначала установите зависимости.

Установите OPENROUTER_API_KEY в своем окружении, а затем запустите одни и те же тестовые примеры для каждой модели-кандидата.

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

Тестовая среда устанавливает для reasoning.effort значение low для каждого кандидата, чтобы разница в стандартном уровне рассуждений не проявлялась как разница в точности вызова инструментов. Каждая из трех моделей выше указывает low в массиве supported_efforts своего объекта reasoning в конечной точке models. Она также устанавливает provider.require_parameters в значение true. Список supported_parameters модели может включать параметр, который принимают только некоторые конечные точки провайдера этой модели, и при стандартной маршрутизации провайдер, не поддерживающий параметр, все равно получает запрос и игнорирует его. При установленном require_parameters мы направляем запрос только тем провайдерам, которые поддерживают каждый параметр в нем, поэтому каждый оцененный ответ выполнялся с тем уровнем усилий, который запрашивала тестовая среда. См. маршрутизацию провайдеров для этого поля. Тестовая среда не устанавливает temperature, поскольку openai/gpt-5.6-sol не указывает temperature в supported_parameters. Если каждый кандидат в вашем списке принимает temperature, установите его явно.

Идентификаторы моделей выше являются примерами. Каждая запись в конечной точке models имеет массив supported_parameters. Модель поддерживает эту тестовую среду, когда этот массив включает tools и tool_choice. Проверяйте текущую коллекцию моделей с поддержкой вызова инструментов, прежде чем фиксировать список кандидатов в долгосрочном наборе тестов.

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

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

Маршрутизация провайдеров также влияет на то, что измеряет ваше сравнение. Auto Exacto по умолчанию запускается для каждого запроса, который включает инструменты, и переупорядочивает провайдеров для выбранной вами модели, поэтому он может изменить конечную точку провайдера, которая обслуживает запрос на вызов инструмента. Одним из его входных данных является частота ошибок вызова инструментов (Tool Call Error Rate). Для каждого запроса, который включает инструменты, мы проверяем каждый вызов инструмента, возвращенный моделью, и классифицируем структурные сбои как InvalidJson, UnknownName или SchemaMismatch, проверяя аргументы на соответствие схеме параметров, которую вы предоставили в соответствии с JSON Schema Draft 7. Эта метрика измеряет поведение провайдера. Она не заменяет локальную проверку схемы в вашей собственной тестовой среде, поэтому в примере выше аргументы проверяются самостоятельно.

Если вы хотите протестировать настройку маршрутизации, которую ваше приложение будет использовать в рабочей среде, оставьте Auto Exacto включенным для каждого кандидата. Если вам нужно сравнение на уровне конечных точек, используйте наши элементы управления маршрутизацией провайдеров, чтобы закрепить провайдера. Установите поле order в объекте provider на slug этого провайдера и установите allow_fallbacks в значение false, чтобы каждый запрос направлялся на одну конечную точку.

Сохраняйте промпты, инструменты, тестовые примеры, модель-судью и критерии оценки неизменными между запусками. Устанавливайте параметры выборки и рассуждения, такие как temperature и reasoning, явно, а не полагаясь на значения по умолчанию, и проверяйте, что каждый кандидат поддерживает установленные вами параметры. Не устанавливайте max_tokens в тестовой среде. Усеченный ответ может обрезать JSON вызова инструмента и проявиться как сбой InvalidJson, который не имеет ничего общего с выбором инструмента моделью.

Если вы не хотите самостоятельно поддерживать кросс-модельный исполнитель, Ori Eval запускает вашего агента против моделей-кандидатов, выполняет проверки инструментов, которые он вызвал, и инструментов, которых он избежал, а также оценивает ответы в свободной форме с помощью LLM-судьи.

Распространенные ошибки

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

• Тестирование только корректных запросов. Включайте отсутствующую информацию, похожие инструменты, случаи, когда не следует вызывать ни один инструмент, и промпты, где модель должна запросить значение, вместо того чтобы выдумывать его.
• Проверка только tool_calls[0]. Ответ может содержать несколько вызовов, поэтому оценивайте весь массив.
• Отношение к валидной полезной нагрузке как к правильной. Проверка схемы не может сказать вам, является ли валидное значение правильным клиентом, заказом, датой или суммой.
• Изменение оценки между моделями. Если инструменты, промпты, судья, настройки модели или политика маршрутизации меняются между запусками, вы больше не проводите то же самое сравнение.