VAKRA проверяет, насколько уверенно AI-агенты справляются с многошаговыми сценариями, где нужно рассуждать, выбирать инструменты и работать с API и документами в условиях, близких к корпоративным
В этом материале разобраны устройство бенчмарка, типы задач, система оценки и характерные режимы отказов, которые проявляются у агентных систем на практике
В отличие от тестов на изолированные навыки, VAKRA измеряет полную траекторию работы агента: от выбора инструмента и промежуточных шагов до финального ответа и соблюдения ограничений
VAKRA предоставляет исполняемую среду, в которой агенты взаимодействуют с более чем 8 000 локально размещённых API, подкреплённых реальными базами данных, охватывающими 62 домена, а также с коллекциями документов, выровненными по доменам. Задачи могут требовать цепочек рассуждений из 3–7 шагов, сочетающих структурированное взаимодействие с API и неструктурированный поиск в условиях ограничений на использование инструментов, заданных на естественном языке
Отдельно полезно сопоставить этот разбор с темой прозрачности поведения агентов: Прозрачность агентного ИИ: как найти моменты раскрытия
Для сравнения режимов отказов и внешней диагностики можно посмотреть связанный материал: UC Berkeley и IBM: диагностика сбоев корпоративных агентов с IT-Bench и MAST
Описание задач
Бенчмарк VAKRA включает четыре задачи, каждая из которых проверяет отдельный набор способностей
Способность 1: цепочки API с использованием BI API
Эта система охватывает 2 077 тестовых экземпляров в 54 разных областях и требует использования инструментов из коллекций SLOT-BIRD и SEL-BIRD (Elder et al., 2026). В отличие от примера в Elder et al., инструментальная вселенная в SLOT-BIRD и SEL-BIRD была расширена за счет большего числа областей. Каждый домен связан с одной коллекцией инструментов, а задачи подразумевают 1–12 вызовов инструментов для получения финального ответа
{ "query": "Which football team has a build-up play speed of 31, build-up plan dribbling of 53, and build-up play passing of 32?", "tool_calls":[ { "name": "get_data", "arguments":{"tool_universe_id="486ea46224d1-aeb8037c5e78"}, "label": "retrieved_data_1" }, { "name": "select_data_equal_to", "arguments":{"data_label":"retrieved_data_1","key_name":"play_speed","value":31}, "label": "FILTERED_DF_0" }, { "name": "select_data_equal_to", "arguments":{"data_label":"FILTERED_DF_0","key_name":"play_dribble","value":53}, "label": "FILTERED_DF_1" }, { "name": "select_data_equal_to", "arguments":{"data_label":"FILTERED_DF_1","key_name":"play_passing","value":32}, "label": "FILTERED_DF_2" }, {"name":{get_team_name},"arguments":{"data_label":"FILTERED_DF_2","n":1}}}], "answer": "FC Barcelona" }Каждый экземпляр включает связанный источник данных в формате JSON, используемый для получения ответа. MCP-серверы, поддерживающие эту задачу, включают специальный инструмент — get_data(tool_universe_id=id), который необходимо вызвать в начале каждого экземпляра
Этот инструмент инициирует источник данных, возвращает облегчённый предварительный просмотр и сохраняет полный набор данных на стороне сервера, что позволяет избежать передачи больших объемов данных по протоколу MCP
Коллекция SLOT-BIRD предоставляет глобальный набор из 7 инструментов для универсальных операций с данными — например, фильтрация и сортировка, — вдохновлённых такими системами, как Tableau и Google Analytics
Коллекция SEL-BIRD расширяет это, вводя более специализированные инструменты: часть из них общая с SLOT-BIRD, тогда как другие получены путём разворачивания категориальных аргументов в отдельные функции (например, sort_data с аргументом ascending: bool = False превращается в sort_data_ascending и sort_data_descending)
Кроме того, универсальная функция (retrieve_data) из SLOT-BIRD заменяется запросо-специфическими геттерами (getter). Каждый ключ в данных для данного экземпляра имеет связанную функцию get (get_KEY_NAME) — в среднем 4 get-функции на экземпляр
{ "handle": "retrieved_data_1", "num_records": 2, "key_details": [ {"name": "team_name", "dtype": "str", "first_3_values": ["FC Barcelona", "Manchester City"]}, {"name": "play_speed", "dtype": "int32", "first_3_values": [31, 40]}, {"name": "play_dribble", "dtype": "int32", "first_3_values": [53, 30]}, {"name": "play_passing", "dtype": "int32", "first_3_values": [32, 16]} ]}Способность 2: выбор инструментов с использованием Dashboard API
Эта способность включает 1 597 экземпляров в 17 доменах и требует инструментов из расширенной коллекции REST-BIRD (Elder et al.). Они используют интерфейсы в стиле конечных точек (endpoint), предоставляющие высокоспецифичные, выровненные по запросу эндпоинты, инкапсулирующие большую часть вычислений. Они обслуживаются как REST API, работающие на сервере FastAPI, который обёрнут MCP-сервером
Эта задача требует выбора правильных API из доменно-специфического набора инструментов (как показано в примере на рисунке 1). Каждый домен содержит минимум 6 и максимум 328 инструментов (в среднем 116 инструментов). Аналогично предыдущей задаче, инструмент get_data настраивает MCP-сервер на предоставление только релевантных доменно-специфических API
Спецификация OpenAI API ограничивает входной список инструментов максимальной длиной в 128 инструментов. Это ограничение требует от разработчика агента непосредственного управления длиной списка инструментов через механизм предварительного отбора. В базовых агентах в нашем репозитории с этой задачей справляется простая возможность предварительного отбора
Способность 3: многошаговое рассуждение с использованием Dashboard API
Сегмент Способности 3 содержит 869 тестовых экземпляров из 38 предметных доменов. Эти экземпляры снова опираются на коллекцию REST-BIRD API, но добавляют к задаче многошаговое рассуждение (см. пример на рисунке 1). Многошаговые вопросы требуют извлечения и объединения нескольких фрагментов подтверждающих свидетельств для получения ответа
Экземпляры в этом разделе требуют от одного до пяти логических переходов для ответа на запрос. Распределение типов вопросов для запросов в тестовом наборе данных показано ниже на рисунке 4
Способность 4: многошаговое многоисточниковое рассуждение и соблюдение политик
Способность 4 включает 644 экземпляра в 41 домене и также построена на коллекции REST-BIRD API. Рисунок 4 выше показывает распределение гибридных переходов для тестовых запросов без политик. Он содержит наиболее сложные запросы со следующими характеристиками:
Multi-Source (многоисточниковость). Этот сегмент добавляет индексы документов для каждого домена. Запросы в этой способности могут требовать информации как из этих индексов документов, так и из вызовов API. Аналогично Способности 3, эта задача также содержит многошаговые запросы
Требуемый источник информации применяется на уровне отдельного перехода, так что, например, вопрос может предполагать три логических перехода с источниками: API — RAG (поиск по документам) — API. Для обеспечения корректного рассуждения источники деконтаминируются в процессе генерации данных, то есть информация, необходимая для данного перехода, доступна только в одном источнике
Например, если переход должен быть отвечен с использованием API, индекс документов строится путём удаления документов, которые, вероятно, содержат информацию, необходимую для ответа на вопрос
Multi-Turn (многоходовость). Этот сегмент набора данных добавляет многоходовые диалоги в постановку задачи. Каждый экземпляр представляет собой диалог с несколькими ходами. Данные публикуются в виде пар контекст–ответ, где контекст кодирует текущую историю диалога, а агент отвечает только за ответ на текущий ход
Политики использования инструментов (Tool-usage Policies). Подмножество этих экземпляров включает политики использования инструментов, которым агент обязан следовать. Эти политики представлены в виде инструкций на естественном языке об источниках знаний, к которым агент имеет право обращаться и при каких обстоятельствах. Например:
Если запрос пользователя относится к Technology & Software, то есть к темам про кодовые базы, программные платформы, приложения и пользовательские взаимодействия в технологической среде, отвечать нужно только с помощью поиска по документам. Другие типы инструментов использовать не следует
Базовый агент в репозитории проекта обеспечивает соблюдение этих политик через простое добавление в промпт (prompt): "You are a helpful assistant with access to tools.\n Tool Usage Constraint: {additional_instructions}.". Разработчики агентов вольны выбирать любой механизм принуждения к соблюдению ограничений
Система оценки
VAKRA оценивает агентов в инструментальных средах, где успех зависит как от способности выполнять связные многошаговые рабочие процессы, так и от правильности ответов. Мы представляем ориентированную на выполнение систему оценки, которая анализирует не только конечные результаты, но и полную траекторию выполнения инструментов, включая вызовы инструментов, входные данные и промежуточные результаты
Метрика оценки. Оценщик VAKRA работает с двумя ключевыми входными данными для каждого образца: предсказанным финальным ответом и соответствующей траекторией вызовов инструментов. Вызовы инструментов из предсказанной траектории выполняются в той же среде, что и эталонные, для проверки промежуточных выходных данных инструментов
Оценка следует конвейеру каскадного типа (рисунок 6), где последующие этапы обусловлены успехом предыдущих:
- Для задач Способности 4 сначала программно проверяется соблюдение политик (этот шаг не применяется к другим способностям).
- Затем предсказанная последовательность вызовов инструментов сравнивается с эталонной последовательностью.
- Только образцы с корректными траекториями переходят к оценке финального ответа.
Сравнение последовательностей инструментов. В связи с наличием исполняемой среды агенты могут исследовать среду и иногда возвращать ответ, вызывая набор API, отличный от того, который был определён нами. Для поддержки альтернативных, но корректных вызовов инструментов и путей рассуждения правильность оценивается путём выполнения каждого предсказанного инструмента и сравнения набора ответов инструментов с ответами из эталонного набора — вместо применения строгого пошагового сопоставления
В частности, мы сначала выполняем программную проверку, верифицируя, восстанавливается ли вся информация, присутствующая в эталонных ответах инструментов, предсказанными ответами инструментов. Эта проверка может быть неокончательной в случаях частичных совпадений, семантической эквивалентности или различий в представлении — например, порядке, агрегации или форматировании
В таких случаях мы применяем вторичную оценку на основе LLM, адаптированную из фреймворка CRAG (Yang et al., 2024), чтобы определить, извлекает ли предсказанная траектория всю необходимую информацию, несмотря на структурные различия
На этом шаге используется адаптированный промпт для определения того, захватывает ли предсказанная траектория всю необходимую информацию, даже если она получена через другую последовательность вызовов инструментов
Оценка финального ответа. Для траекторий, прошедших предыдущую проверку, финальный ответ оценивается с помощью судьи на основе LLM. Этот шаг гарантирует, что ответ (i) основан на предсказанных выходных данных инструментов и (ii) фактически согласован с эталонным ответом с учётом возможных вариаций в формулировке или структуре
Такой дизайн гарантирует, что агенты получают вознаграждение не только за производство правильных ответов, но и за их получение через корректные и полные процессы рассуждения
Подсчёт баллов. Каждая способность имеет одинаковый вес для получения итогового балла в таблице лидеров. Для получения балла за способность каждый образец внутри способности имеет одинаковый вес для способностей с 1 по 3. Для Способности 4 присваивается более высокий вес неоднородным запросам
Анализ ошибок
Теперь я хочу подробно разобрать режимы отказов по четырём способностям VAKRA. Для облегчения анализа мы применяем пошаговую категоризацию ошибок, чтобы отнести каждый сбой к первой точке отказа
В частности, мы последовательно оцениваем: (i) были ли выбраны правильные инструменты, (ii) были ли предоставлены необходимые аргументы без пропусков или галлюцинаций, (iii) были ли значения аргументов корректными, и (iv) является ли финальный ответ одновременно точным и основанным на выходных данных инструментов
Изоляция этапа сбоя. Поскольку один образец может демонстрировать несколько ошибок на разных шагах, мы последовательно классифицируем каждый экземпляр по наиболее раннему этапу сбоя — например, ошибки выбора инструмента имеют приоритет над ошибками аргументов. Это позволяет избежать двойного подсчёта и позволяет интерпретировать категории ошибок как непересекающиеся доли набора данных
Хотя более детальные метрики (например, точность/полнота по использованию инструментов) возможны (Elder et al., 2026), данная формулировка обеспечивает простую и интерпретируемую разбивку сбоев агентов
Способность 1: цепочки BI API. Экземпляры в этой части бенчмарка требовали выбора и последовательного применения нескольких инструментов для решения одной задачи. В этой способности у нас 2 077 образцов. Это было сложно для всех моделей, однако GPT-OSS-120B показал наилучшие результаты в этом сегменте бенчмарка
GPT-OSS-120B превзошёл другие модели с большим отрывом, главным образом благодаря лучшему пониманию схем инструментов. Инструменты в этой части бенчмарка включают большое количество параметров, многие из которых являются необязательными, и GPT-OSS-120B был особенно устойчив по сравнению с другими в выборе правильных параметров для заполнения
В целом, синтез правильного ответа после корректного выполнения всех вызовов инструментов был менее сложным в этом разделе бенчмарка — скорее всего потому, что последовательность вызовов инструментов делала задачу выбора инструмента менее поддающейся угадыванию по сравнению со способностью Dashboard API
Способность BI API содержит два набора API из коллекций инструментов SLOT-BIRD и SEL-BIRD. Часть SEL этого бенчмарка содержала 600 образцов, а часть SLOT — 1 477 образцов. Эти две коллекции сгруппированы в рамках способности BI API, но имеют несколько различные характеристики
Коллекция SLOT-BIRD содержит меньшее количество универсальных инструментов с большим числом значений параметров для заполнения, тогда как коллекция SEL-BIRD содержит более широкий набор инструментов с меньшим количеством параметров на инструмент. Этот акцент отражается в относительных ошибках, допускаемых моделями при использовании этих двух коллекций инструментов
При использовании SLOT-BIRD все модели, кроме GPT-OSS-120b, допускали значительное количество ошибок при формировании правильных имён аргументов инструментов. Это в значительной мере объясняет столь высокую общую производительность GPT-OSS-120b в этом сегменте бенчмарка
При меньшем количестве параметров для заполнения те же модели допускали очень мало подобных ошибок при использовании коллекции инструментов SEL-BIRD, однако они допускали значительно больше ошибок при выборе правильных инструментов — что отражает возросшую сложность выбора из более широкого и динамического набора инструментов
Способность 2: выбор инструментов через Dashboard API. Как показано выше, для 1 597 образцов в способности выбора инструментов Gemini-3-flash-preview превосходит другие протестированные модели по всем категориям ошибок
Как и ожидалось, поскольку экземпляры Dashboard API требуют от моделей выбора из большого числа вариантов инструментов, но каждый инструмент требует лишь небольшого количества параметров, наблюдается большое количество ошибок при выборе инструментов и выборе значений параметров
По всей видимости, проблем с галлюцинированием или пропуском обязательных параметров практически нет. Однако даже когда все вызовы инструментов выполнены корректно, модели — особенно Gemini-3-flash-preview и Claude-Sonnet-4-5 — всё равно испытывают трудности с синтезом правильного ответа из ответов инструментов, о чём свидетельствуют значительные падения в крайней правой части графика
Многошаговое рассуждение: влияние глубины переходов на производительность модели.
Многошаговое рассуждение увеличивает сложность исходной задачи, требуя от моделей успешного ответа на несколько неявно связанных вопросов, каждый из которых требует выбора и вызова правильного API. Как и ожидалось, все модели показали наилучшие результаты на вопросах с единственным логическим переходом и демонстрировали снижение производительности на вопросах с 2 переходами и снова на вопросах с 3 и более переходами
Многошаговое многоисточниковое рассуждение: влияние гибридных переходов на производительность модели.
Финальный сегмент набора данных включает документальные источники в дополнение к источникам инструментов и API в других сегментах. Это приводит к экземплярам, требующим одного или нескольких вызовов API, одного или нескольких поисков по документам, или некоторой комбинации вызовов API и поисков по документам
Как и прежде, наблюдается заметная разница в производительности на экземплярах, требующих одного вызова API (1-hop API), по сравнению с теми, которые требуют нескольких вызовов API (2-hop API), а включение поиска по документам делает задачу более сложной (RAG Hops и Hybrid)
Интересно, что на вопросах, требующих одного вызова поиска по документам (1-hop RAG), GPT-OSS-120B пытается напрямую вернуть ответ из параметрических знаний, хотя когда вопрос, по всей видимости, требует нескольких переходов, он отвечает на вопрос. Мы выдвигаем гипотезу, что поскольку вопросы для 1-hop RAG очень сфокусированы на сущностях Википедии, модель пропускает вызов инструмента — мы не наблюдаем этой проблемы на 1-hop API, где специфичные для внутренних баз данных сущности и факты могут присутствовать в вопросе чаще
Также интересно, что производительность Gemini-3-flash-preview резко возрастает на 2-hop API-RAG по сравнению с другими гибридными паттернами переходов. Это, вероятно, объясняется относительно высокой производительностью Gemini-3-flash-preview на Dashboard API (Способность выбора инструментов), и, таким образом, как только правильный промежуточный ответ определён с помощью вызова инструмента, поисковый запрос, скорее всего, оказывается более успешным
Влияние политик на производительность модели.
Политики вводят дополнительный уровень сложности поверх многошагового многоисточникового рассуждения. Когда политики согласуются с необходимым источником для ответа — то есть не влияют на список инструментов, необходимых моделям для ответа на вопрос, — мы называем это «Без обновлений ответа»
Как показано на рисунке 10, все модели, кроме Granite-4.0-h-Small-32B, демонстрируют явное снижение производительности при ограничениях политики, ограничивающих доступ к наиболее релевантному источнику информации — то есть «Политика обновляет ответ»
В целом мы обнаруживаем, что модели либо нарушают ограничения, либо не могут извлечь достаточно информации: иногда они понимали политику, но не могли правильно ответить на вопрос, либо демонстрировали один из ранее проанализированных режимов сбоя
Настройки с ограничениями политики использования инструментов показывают, что хотя модели могут рассуждать об инструментах и источниках, им трудно включать внешние ограничения в это рассуждение — что зачастую является ключевым требованием для надёжного развёртывания в реальных условиях
Типичные ошибки при работе с VAKRA
Изучив результаты, я выделил несколько устойчивых паттернов сбоев, которые воспроизводятся у большинства моделей независимо от их общего уровня
Ошибки именования аргументов особенно характерны для коллекции SLOT-BIRD, где инструменты содержат большое число параметров. Модели путают имена аргументов или передают значения в неверные поля — и это единственная категория ошибок, где GPT-OSS-120B стабильно выигрывает у конкурентов
Ошибки выбора инструмента доминируют в коллекции SEL-BIRD и в задачах Dashboard API, где набор инструментов шире, но каждый инструмент требует меньше параметров. Модели выбирают похожий, но не тот инструмент — и вся цепочка рассуждений рушится на первом шаге
Ошибки синтеза ответа возникают даже тогда, когда все вызовы инструментов выполнены корректно. Gemini-3-flash-preview и Claude-Sonnet-4-5 особенно часто не могут собрать финальный ответ из правильно полученных промежуточных данных
Пропуск вызова инструмента наблюдается у GPT-OSS-120B на задачах 1-hop RAG: модель возвращает ответ из параметрических знаний, минуя поиск по документам. Гипотеза — вопросы слишком похожи на стандартные факты из Википедии, и модель не видит необходимости обращаться к инструменту
Нарушение политик — наиболее сложный режим отказа. Модели либо игнорируют ограничение, либо понимают его, но не могут ответить на вопрос в рамках разрешённых источников
VAKRA обнажает критический разрыв между поверхностной компетентностью в работе с инструментами и надёжной, сквозной устойчивостью агентов. Несмотря на то что современные модели всё лучше справляются с выбором API и выполнением изолированных вызовов инструментов, VAKRA показывает: одних этих способностей недостаточно для реального развёртывания. На практике модели нередко дают сбой, когда от них требуется выполнять композиционное рассуждение в условиях ограничений выполнения — охватывающих API, документы, контекст диалога и требования политик
Ответы на эти вопросы могут быть для вас полезными
Чем VAKRA отличается от других бенчмарков для ИИ-агентов? VAKRA использует исполняемую среду с более чем 8 000 реальных API и проверяет не только финальный ответ, но и полную траекторию вызовов инструментов. Большинство других бенчмарков оценивают изолированные навыки без проверки промежуточных шагов рассуждения
Какая модель показала лучшие результаты на VAKRA и почему? GPT-OSS-120B лидирует в задачах цепочек BI API — прежде всего благодаря устойчивости к ошибкам именования аргументов в инструментах с большим числом параметров. Gemini-3-flash-preview лучше справляется с задачами выбора инструментов из Dashboard API
Что такое политики использования инструментов в VAKRA и зачем они нужны? Политики — это инструкции на естественном языке, ограничивающие, какие источники знаний агент может использовать при ответе. Они моделируют реальные корпоративные ограничения: например, запрет обращаться к API при вопросах из определённой категории. Большинство моделей либо нарушают эти ограничения, либо не могут ответить в их рамках
Как устроена система оценки VAKRA? Оценка работает по каскадному принципу: сначала проверяется соблюдение политик (для Способности 4), затем корректность траектории вызовов инструментов, и только потом — правильность финального ответа. Образец засчитывается только при прохождении всех этапов
Можно ли протестировать своего агента на VAKRA? Да. Датасет доступен на Hugging Face по адресу ibm-research/VAKRA, код — на GitHub в репозитории IBM/vakra. Там же описан процесс отправки результатов в таблицу лидеров
