Когда ИИ-агент уходит в продакшен, главный вопрос уже не в том, звучит ли его ответ убедительно. Ключевой вопрос — способен ли он выполнить цепочку работы из десятков последовательных вызовов инструментов в живой среде и восстановиться, когда какой-то шаг падает. Оценка ИИ-агентов сместилась с подсчёта отдельных вызовов функций на измерение полного выполнения задачи через исполняемые среды, которые отслеживают состояние на протяжении многошагового использования инструментов.
Почему стандартных бенчмарков LLM недостаточно
Первые испытательные стенды создавались для статических задач, а первый открытый стенд, не привязанный к конкретной модели, развёл модель и протокол оценки. Агенты эту предпосылку сломали: работая над многошаговыми задачами, агент вызывает инструменты, обрабатывает ошибки и наблюдает результаты на протяжении многих шагов, поэтому одной выходной строки для оценки уже не хватает.
Для оценки выбора функций и точности аргументов в одно- и многоходовых сценариях появился Berkeley Function-Calling Leaderboard (BFCL). Но BFCL оценивает только отдельные вызовы: корректный вызов issue_refund всё равно провалится, если лежащие под ним проверки или обновления были пропущены. Точность вызовов необходима, но недостаточна.
Два уровня оценки: процесс и результат
Полноценная агентная оценка теперь требует полной среды исполнения: она выполняет каждый вызов инструмента, отслеживает состояние между шагами и читает мир после завершения, чтобы решить, была ли работа сделана. Поверх неё работают два уровня оценки:
- Пошаговый (process scoring) — был ли этот вызов допустимым, релевантным и полезным с учётом состояния на тот момент?
- Сквозной (E2E, outcome scoring) — игнорирует путь и проверяет только финальное состояние: прошёл ли возврат средств, правильно ли маршрутизирован тикет.
Пошаговая оценка показывает, где именно рвётся цепочка, — это то, что нужно при отладке и выборе цели для дообучения. Сквозная оценка схлопывает провал на первом шаге и провал на девятом в одно и то же «задача не выполнена». Именно сквозной результат чувствует пользователь, поэтому большинство продакшен-оценок ставит релиз в зависимость от неё, а пошаговую трассировку держит ниже для отладки.
Обе оценки — два прочтения одного объекта: трассы. Трасса — это упорядоченный журнал одной попытки: сообщение пользователя, каждый шаг и состояние среды в момент остановки. Пошаговая оценка выставляет баллы строкам, сквозная — финальному состоянию.
Что измеряет прогон бенчмарка
Бенчмарк вызова инструментов оценивает три вещи по порядку: решение использовать инструмент, выбор правильного и заполнение его аргументов. Модель, тянущаяся к инструменту там, где хватило бы прямого ответа, провалится так же надёжно, как и та, что пропустила нужный инструмент. Стоимость и задержка лежат сверху и задаются многословностью вызова и временем выполнения.
Каждый прогон сворачивается через фиксированную иерархию: Benchmark → Trial → Task → Turn → Step.
- trial — один независимый проход по всему набору задач при фиксированной конфигурации;
- task — один независимо оцениваемый экземпляр задачи с идентификатором task ID;
- turn — одна граница обмена: сообщение на входе, ответ агента на выходе, всё между ними относится к этому ходу;
- step — одно атомарное действие внутри хода: вызов инструмента или команды либо неинструментальный вывод вроде плана или финального сообщения.
Шаг обычно и есть вызов инструмента, и каждая оценка выше сворачивается из этих шагов. Метрики, за которыми стоит следить, сводятся к трём осям: точность, многословность и стоимость.
| Метрика | Формула | Ось | Зачем нужна |
|---|---|---|---|
| Task success rate | successful_tasks / tasks | Точность | Гейт релиза. Достигла ли среда целевого состояния? |
| Consistency | разброс success rate по 3–5 trials | Точность | Разброс 90% / 74% — это не 84%. Сообщайте 82–88%, а не точечную оценку. |
| Tool-call precision | correct_calls / calls_issued | Точность | Здесь всплывают выдуманные имена и лишние вызовы, а не в success rate. |
| Argument accuracy | correct_args / calls_with_right_tool | Точность | Отделяет «неправильный API» от «правильный API, но заполнен неверно». |
| Steps per success | steps / successful_tasks | Многословность | Как долго идёт траектория, когда задача действительно завершается. |
| Cost per success | spend / successful_tasks | Стоимость | Экономическая единица. Токены и GPU-секунды важны только в расчёте на успешную задачу. |
Важны именно пары: success rate без consistency — точечная оценка на стохастической системе (модель, дающая 90%, а потом 74%, — худшая ставка, чем та, что держит 84%); tool-call precision без argument accuracy скрывает провалы заполнения слотов.
Число шагов часто оказывается осью, которая сильнее всего различается между моделями на одной и той же задаче: четыре шага против пятнадцати. Но в наборах вроде Terminal-Bench 2.0 меняется и число шагов на ход, так что какая ось движется сильнее — зависит от бенчмарка. Параллельный вызов инструментов сокращает число шагов и задержку, но не число вызовов: ход из одного шага, запускающий четыре инструмента, всё равно совершил четыре вызова. Сворачивайте по порядку и не усредняйте шаги, называя это оценкой бенчмарка.
Как читать результаты оценки
Два бенчмарка могут оба заявлять, что проверяют вызов инструментов, и выдавать несопоставимые числа. Большую часть разрыва объясняют три измерения:
- Сложность задачи — один ход с одним инструментом или много ходов с планированием, восстановлением после ошибок и управлением состоянием? Бенчмарк на один вызов не скажет, развалится ли модель на восьмом шаге из пятнадцати.
- Состояние среды — обновляется ли среда при каждом действии? Бенчмарки с состоянием вскрывают дрейф, потерю контекста и повреждённое состояние, которые статические пропускают.
- Методология — исполняемая проверка (обновилась ли БД, прошли ли тесты) считается золотым стандартом. Оценка по эталону требует аннотированного набора ответов, который кто-то должен поддерживать. LLM-as-a-Judge закрывает пробел там, где исполняемой проверки нет, но его оценки считаются предварительными, пока не подтверждены против оценок людей на выборке.
Загрязнение теперь выходит за пределы утечек обучающих данных к живым вариантам: агенты с веб-поиском достают ключи ответов во время оценки, а датасеты на Hugging Face быстро перескабливаются в корпуса предобучения. Приватные доменные оценки решают это тем, что их невозможно соскрести.
Разбор реальной трассы
Публичная трасса из настоящего прогона бенчмарка показывает пошаговую и сквозную оценку, где инструменты, пользователя и критерии завершения даёт сам набор, а не искусственный тикет.
- Набор: SWE-bench Verified (реальные issue из GitHub, проверка исполняемыми тестами)
- Task ID: pytest-dev__pytest-5262 (trial 2, ходы 0–4)
- Вводная от пользователя/симулятора: «Внеси необходимые изменения в репозиторий (
/testbed), чтобы требования из issue были выполнены». Суть issue:_pytest.capture.EncodedFileсообщает режимrb+(бинарный) от своего нижележащего буфера, но егоwrite()принимает толькоstr, поэтому внешний код, проверяющий.mode(например,youtube-dl), падает при записиbytes. - Заметки о стенде: агентный стенд OpenHands; доступные инструменты —
terminal,file_editor,task_tracker,finish; параллельный вызов инструментов выключен (один вызов на ход); состояние репозитория сохраняется между ходами (настоящая файловая система и git, не мок).
| Шаг | Ход | Вызов | Наблюдение среды | Вердикт | Почему |
|---|---|---|---|---|---|
| 1 | 0 | terminal(find /testbed -name "capture.py") | Возвращает /testbed/src/_pytest/capture.py | valid | Находит файл из issue до любых правок |
| 2 | 1 | file_editor(view, capture.py) | Выводит весь файл (400+ строк) | redundant | Файл большой; grep по классу был бы точнее |
| 3 | 2 | terminal(grep -n "EncodedFile" capture.py) | Возвращает 422: return EncodedFile(...) / 425: class EncodedFile(object): | recovered | Исправляет неэффективность шага 2, сужая поиск до нужных строк |
| 4 | 3–4 | file_editor(view, view_range=[420,450]/[450,470]) | Показывает EncodedFile.init / getattr, выявляя делегирование .mode прямо из буфера в бинарном режиме | valid | Указывает точную первопричину — нефильтрованное делегирование в getattr, которое исправляют шаги 5+ |
Итоги: сквозная проверка (состояние БД / тесты / тикет) — PASSED; сквозная оценка (0 или 1) — 1; пошаговая оценка (прошло / шагов) — 3/4; tool-call precision — 3/4; argument accuracy — 4/4.
Разберём последние пять пунктов. Сквозная проверка говорит, что связанные тесты для исправляемого бага прошли, значит сквозная оценка равна 1 (is_resolved: true). Пошаговая оценка показывает, сколько из шагов модели действительно были нужны: 3/4, потому что один шаг — а именно шаг 2 — оказался избыточным. Это напрямую отражается и на tool-call precision, которая тоже получила 3/4 из-за мелкой ошибки. Аргументная точность в этой трассе показала, что все аргументы заполнены правильно, без искажённых аргументов.
Почему бенчмарки сходятся на вызове инструментов
Граница между «вызвать инструмент» и «выполнить задачу» больше не держится: большинство бенчмарков, измеряющих общую способность, теперь измеряют и использование инструментов, потому что без инструментов модели нигде всерьёз не запускают. Бенчмарк, лишающий доступа к инструментам, оценивает способность, которую никто не поставляет.
Не каждый бенчмарк делает этот случай. HumanEval прогоняет сгенерированный Python против юнит-тестов, давая исполняемую проверку, но без вызова инструментов и без среды, на которую можно воздействовать. SWE-bench — место, где сдвиг становится очевиден: решить реальный issue из GitHub значит пройти по кодовой базе, написать патч и пройти набор тестов — чтение файлов, поиск и правки идут последовательностью вызовов. Оценка измеряет результат, но траектория под ней целиком состоит из вызовов инструментов. Так что бенчмарки, которые вы уже прогоняете для общей способности, во многих случаях уже нагружают использование инструментов.
Это переформулирует главный вопрос. Академические бенчмарки измеряют потолок способностей модели в абстракции. Корпоративные бенчмарки отвечают на более узкий и полезный вопрос: может ли она делать мою работу — ваши задачи, против ваших API, по вашим политикам? Чем ближе бенчмарк к продакшену, тем больший вес его оценка должна иметь в решении.
Nemotron 3.5 Lightning через эту призму
Публичный набор NVIDIA Nemotron 3.5 Lightning стоит читать как выполнение задачи и время до готовности, а не как изолированную точность вызовов. Banking оценивает завершение в многоходовом банковском разговоре — та же трасса возврата средств в масштабе, а не один вызов. GDPval-AA v2 оценивает реальную агентную работу по фактическим результатам труда, судимую попарно панелью LLM-судей с Elo, привязанным к базовой линии из 1 000 экспертов-людей, — именно такая человеческая валидация держит оценку судьи заслуживающей доверия. На PinchBench Nemotron 3.5 Lightning достигает 86% точности, завершая 10 000 задач на 30% быстрее, чем Qwen3.6 35B при сопоставимой точности: модель, которая заканчивает эффективно, бьёт ту, что набирает больше на изолированной точности, сжигая больше шагов и токенов.
Публичные оценки — отличный сигнал, но их не стоит считать гейтом релиза. Адаптировать модель к своей задаче и сценариям использования по-прежнему важно.
Как построить оценку под свою нагрузку
Порядок действий из материала такой:
- Задать публичный пол. Прогнать опубликованный агентный набор; записать success rate и его разброс по 3–5 trials.
- Построить доменную оценку из своих реальных тикетов, трасс и API. Гейт ставить на состояние среды — строку в базе, слитый PR, закрытый тикет, — а не на мнение судьи о финальном сообщении.
- Адаптировать модель и стенд к этому распределению.
- Перемерить success rate, consistency, steps per success и cost per success. Пошаговые трассы сохранять для отладки.
Проверяйте последствия в среде, используйте судей для языка, а tool-call precision и argument accuracy — чтобы найти, где рвётся цепочка. Чтобы воспроизвести опубликованные числа, Nemotron поставляет документацию по воспроизводимости с конфигурациями, стоящими за оценками карточки модели.
Вызов инструментов в области бенчмаркинга LLM — фундамент, на котором сегодня держатся оценки. Уметь строить, читать и понимать эти оценки важно для обоснованного решения под свой сценарий. Если вы уже выбираете модель под агентные задачи, полезно сравнить подходы к инференсу — например, замеры задержки для голосовых агентов и локальные модели для агентов на ноутбуке. А перед выпуском агента в продакшен стоит разобрать типовые провалы безопасности ИИ-агентов.
Частые вопросы
Чем оценка агента отличается от обычного бенчмарка LLM?
Обычный бенчмарк оценивает один статический вывод, а агент работает многошагово: вызывает инструменты, обрабатывает ошибки и наблюдает результаты. Поэтому одной выходной строки недостаточно — нужна среда исполнения, которая отслеживает состояние между шагами.
Почему точности вызовов функций недостаточно?
Корректный вызов issue_refund всё равно провалится, если пропущены лежащие под ним проверки или обновления. Точность вызовов необходима, но не достаточна: она не показывает, достигла ли среда целевого состояния.
В чём разница между пошаговой и сквозной оценкой?
Пошаговая проверяет, был ли каждый вызов допустимым, релевантным и полезным при текущем состоянии, и показывает, где рвётся цепочка. Сквозная игнорирует путь и смотрит только на финальное состояние — прошёл ли возврат, закрылся ли тикет.
Зачем сообщать разброс success rate, а не одно число?
Success rate без consistency — точечная оценка на стохастической системе. Модель, дающая 90%, а затем 74%, — худшая ставка, чем та, что стабильно держит 84%, поэтому корректно указывать диапазон по 3–5 trials.
Что такое трасса и что в неё входит?
Трасса — упорядоченный журнал одной попытки: сообщение пользователя, каждый шаг и состояние среды в момент остановки. Пошаговая оценка выставляет баллы строкам трассы, сквозная — финальному состоянию.
Как понять, что два бенчмарка несопоставимы?
Смотрите на три измерения: сложность задачи (один вызов против многоходового планирования), наличие состояния среды и методологию проверки. Различия по ним объясняют большую часть разрыва в числах.
Какая методология проверки считается лучшей?
Исполняемая проверка — обновилась ли база, прошли ли тесты — золотой стандарт. Оценка по эталону требует поддерживаемого набора аннотаций, а LLM-as-a-Judge закрывает пробелы, но его оценки предварительны, пока не подтверждены людьми на выборке.
Что делать, если публичная оценка модели высокая?
Не считать её гейтом релиза. Публичные оценки — хороший сигнал, но модель и стенд нужно адаптировать к своему распределению задач, а затем заново измерить success rate, consistency, steps per success и cost per success.
Какие метрики важнее всего для продакшена?
Task success rate как гейт релиза и его разброс, плюс cost per success как экономическая единица. Токены и GPU-секунды имеют смысл только в расчёте на успешно выполненную задачу.
Что показывает число шагов на успех?
Это ось многословности: как долго идёт траектория, когда задача действительно завершается. Она часто различается сильнее всего между моделями на одной задаче — четыре шага против пятнадцати.
Источник: developer.nvidia.com