Benchmarks Agents

Суть

• LMArena — слепое человеческое предпочтение (Elo); «как ощущается» модель, не задача.
• SWE-bench — 500 реальных GitHub-issue; модель должна выдать patch, проходящий тесты.
• Open LLM Leaderboard — сравнение open-weight (Llama, Qwen, Mistral, DeepSeek).
• AgentBench — 8 интерактивных сред (OS/bash, DB/SQL, knowledge graph, web shopping и др.); меряет long-term reasoning, decision-making, instruction following
• Terminal-Bench — агентные задачи в терминале; в базе появился поздно, а встречается часто, потому что на нём меряют харнессы и обвязку, а не только модель. Версии несопоставимы между собой: V2 и 2.1 — разные наборы, и числа из них рядом не ставятся.
• SWE-Bench Verified — подмножество SWE-bench, вычищенное вручную; именно его обычно имеют в виду, когда называют «SWE-bench» с высоким баллом.
• RoboRewardBench — предпочтения в робототехнических траекториях; интересен тем, что там есть человеческая разметка, с которой сверяют оценщика.
• MedAgentBench — агентные задачи в медицинском контуре..

Зачем это нужно

Это инструмент оценки качества при Model Selection. Главные причины провала агентов видны именно тут: плохие long-term reasoning и decision-making.

Как работает (как читать — 5 правил)

• Не доверяй одному — смотри 3+ бенчмарка под свою задачу.
• Смотри дату: старше 6 мес — устарело.
• Vendor-scores = best-case на их scaffold → умножай на ~0.7.
• Scaffold (Claude Code, Aider, Codex) меняет результат на 10–20%.
• Verified vs Pro: на приватных данных баллы падают в ~3× (GPT-5: 74.9% → 14.9%) — в проде реальность ближе к Pro.
• Финал: свои evals на 50–200 примерах своего домена (на практике — см. Agent Evals).
• В новых материалах для сравнения моделей встречается ARC-AGI Leaderboard (напр., GPT-4.5 / Claude 3.7 / DeepSeek). Отдельное наблюдение: классические бенчмарки на атомарные задачи теряют релевантность для оценки именно «агентности» — модели их уже «решают», а сложность сместилась в многошаговость.
• OSWorld / OSWorld-Verified — бенчмарк для computer-use агентов (Computer Use): задачи управления реальным ПК через GUI. Замер мая 2026: Claude Opus 4.6 — 72.7% (тогда впервые выше human baseline ~72%), UI-TARS-1.5 — 42.5%, OpenAI Operator — 36.4%, Claude 3.7 — 28%. Сверка 2026-08: модели Opus вышли в диапазон низких 80%, то есть за квартал верхняя планка сдвинулась примерно на 8 пунктов — хорошая иллюстрация того, как быстро протухает любая строка этого раздела.
• Не путать с браузерными бенчмарками. WebVoyager и WebArena меряют работу в браузере, а не на десктопе, и числа несопоставимы с OSWorld: на WebVoyager лидируют browser-use (89%) и computer-using agent от OpenAI (87%), у которого на OSWorld при этом около 38%. Сравнивать агентов «по проценту» без указания бенчмарка бессмысленно.

Шестое правило: у прироста есть потолок, и его надо считать

Пять правил выше — про то, как читать чужой балл. Шестое — про то, как читать свой прирост, и оно про величину, которой в заметке не было: оракул.

Pass@1 — доля решённых задач с первой попытки. Pass@k (или oracle) — доля задач, где хотя бы одна из k попыток верна. Разрыв между ними — это весь бюджет, который можно забрать отбором лучшей попытки: ниже Pass@1 не опустишься, выше Pass@k не поднимешься, что ни делай.

Отсюда правило: прирост от отбора измеряется долей закрытого разрыва, а не пунктами. Замер LLM-as-a-Verifier на трёх наборах показывает, насколько это меняет вывод:

Про совпадение чисел, которое выглядит опечаткой. Строка V2 (86.5% при оракуле 92.1%) совпадает по обоим числам с результатом Best-of-3 самопроверки на 2.1, приведённым в Generator Evaluator (79.4% → 86.5% ± 1.1% при оракуле 92.1%). Оракул — свойство пары «генератор + набор», поэтому два разных генератора на разных версиях набора один оракул иметь не должны. Сверено по первоисточнику 2026-09-12: обе строки верны, это совпадение в данных, а не ошибка копирования. Оставлено как есть с этой пометкой, чтобы следующий читатель не тратил время на ту же проверку.

MedAgentBench тут поучительнее всех. Прирост 3.1 пункта — самый скромный в таблице, но разрыв там всего 4.8 пункта, и отбор выбирает две трети доступного. Читать этот результат как «отбор почти не помог» — ошибка; правильный вывод другой: на этом наборе Best-of-N уже почти исчерпан, и вкладываться надо в генератор, а не в верификатор.

Практическое следствие: оракул считается до того, как строить отбор. Прогоняешь k попыток, смотришь, сколько задач решается хотя бы одной. Разрыв узкий — Best-of-N не окупится независимо от качества судьи (Generator Evaluator, LLM as Judge).

Сравнение обвязок: балл без стоимости — половина результата

Отдельный класс замеров — когда сравнивают не модели, а обвязки поверх сопоставимых моделей. Пример на MLE-bench (75 задач машинного обучения): специализированная исследовательская система против универсального кодового агента как базовой линии — 60 медалей против 55, из них 49 золотых против 34, при стоимости прогона 3 054 доллара против 38 370.

Читать это как «одна система лучше другой на пять медалей» — потерять большую часть измеренного. Чтение двумерное: разрыв по качеству узкий, разрыв по стоимости двенадцатикратный, и здесь основной результат именно второй. Балл, поданный без стоимости прогона, скрывает ту ось, по которой разница на порядок.

Оговорка обязательна: замер авторский и независимо не воспроизводился, а базовой линией взят универсальный агент на задаче, под которую соперник построен специально. Такое сравнение честно показывает цену универсальности, но ранжированием систем не является.

Минимальный harness как экспериментальный контроль

Для сравнения моделей полезен второй тип базовой линии: не слабый конкурент, а намеренно малый и прозрачный harness, одинаковый для всех кандидатов. mini-SWE-agent реализует именно такую постановку: короткий координатор вызывает модель, исполняет действие в заменяемой среде и возвращает наблюдение; траектория хранит те сообщения, которые действительно ушли провайдеру. На официальном SWE-bench один и тот же mini-SWE-agent используется для строк разных моделей в категории Bash Only. Это уменьшает число скрытых переменных и делает различия легче разбирать.

Но «минимальный» не означает нейтральный. Системный prompt, единственный bash-инструмент, права среды, parser/tool-calling adapter, лимиты, retry и completion gate всё ещё формируют результат. Поэтому такой прогон отвечает на вопрос «какая модель лучше в этом фиксированном малом harness», а не «какая модель лучше вообще». Версия harness и полный config остаются частью идентичности точки — ровно как у более сложной обвязки.

Code review: относительный выигрыш не отменяет абсолютный recall

AACR-Bench собирает 200 реальных PR из 50 репозиториев на десяти языках и 1 505 подтверждённых замечаний. В авторском сравнении OpenCodeReview на Claude 4.6 Opus получил semantic F1 25,10%, precision 33,90%, recall 20,00% и около 385K токенов; Claude Code на том же backend — 11,57%, 7,23%, 28,90% и 5 664K токенов. Детерминированная обвязка заметно улучшила стоимость и precision, но четыре из пяти эталонных дефектов всё равно пропущены, а две трети выданных комментариев не совпали с ground truth. Это pre-reviewer с выбранным precision/recall trade-off, а не доказанная замена человеку.

У результата четыре оговорки. Benchmark и система созданы одной организацией с пересекающимися авторами, поэтому проверка не независима. Совпадение оценивает LLM-судья после проверки пути, стороны и строки; полезное замечание вне неполного ground truth может стать false positive. В статье нет полноценной component ablation, отделяющей вклад rule dispatch, ограниченных инструментов и reflection. Наконец, evaluation harness исключает отсутствующие result files из знаменателей: missing_instances показывается отдельно, но итоговая метрика способна выглядеть лучше, если частота пропусков у систем различается.

Отсюда правило чтения code-review benchmark: рядом с precision/recall/F1 показывать coverage запуска — сколько выбранных PR и файлов реально получили терминальный результат, сколько упало или отсутствовало — и отдельно измерять human acceptance полезных unmatched comments. Без этих двух величин низкий шум можно получить не только точностью, но и молчанием.

Long-horizon: фиксированный расход и практическое плато

Для длинной работы финальный балл без оси расхода ещё слабее. Harness может держать агента в цикле дольше конкурента, породить сотни субагентов или преждевременно завершить задачу; сравнение только конечных ответов смешает способность модели, политику остановки и величину test-time compute.

Две формы измерения отвечают на разные вопросы:

• score at fixed expenditure — какой проверенный результат получен при одинаковом лимите времени, output tokens или денег;
• score at practical plateau — как выглядит кривая прогресса и после какого расхода дополнительные вычисления дают лишь малый прирост.

Расход агрегируется по всему дереву исполнения: model calls, инструменты, повторы и дочерние сессии. Делегирование, не попавшее в счётчик корня, делает параллельный harness искусственно дешёвым. Рядом фиксируются версия модели, harness revision, prompt, права среды, compaction/refinement policy, completion gate и retry policy — иначе сравниваются разные системы под одним именем.

Заголовочный результат Prime Agent 30% → 95,5% на ARC-AGI-3 нельзя читать как чистый causal lift обвязки. Авторы сообщили, что их собственные повторы native harness дали результат ниже опубликованного поставщиками, поэтому для ориентира использовали внешние точки; сами они прямо пишут, что такое сопоставление не изолирует причинный эффект harness. Полезны кривые «результат против токенов/стоимости» и семантика учёта, а не лозунг из двух процентов.

MAST: почему падают мультиагентные системы

Бенчмарк, измеряющий не качество ответов, а причины отказов мультиагентных систем. На семи state-of-the-art open-source фреймворках доля неуспешных прогонов составила от 41% до 86,7% — то есть падение здесь норма, а не исключение.

Распределение причин:

Практический вывод из бенчмарка: явная верификация цели и протоколов даёт +15,6% к успеху — наибольший ROI среди всех мер по надёжности.

Читать это стоит вместе с общим правилом чтения бенчмарков: цифры получены на конкретных фреймворках и задачах, но структура причин полезна сама по себе. Она говорит, что почти 80% отказов — это ошибки проектирования и договорённостей между агентами, а не «модель плохо ответила» (см. Multi Agent Systems, Agent Failure Modes).

Как получить поправку на свой харнесс

Универсального коэффициента нет — множитель, упомянутый выше, снимает вендорский оптимизм, но не описывает вашу обвязку. Поправка меряется, и дёшево: взять подмножество публичного бенчмарка (несколько десятков задач достаточно), прогнать его через свой харнесс и сравнить долю решённых с опубликованной для той же модели.

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

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

Связано с

• Model Selection — бенчмарки = критерий «качество»
• Generated Test Quality — бенчмарк итеративной деградации и почему приёмка по контрольным точкам совместима с падающим качеством
• AI Agent — AgentBench меряет именно «агентность»
• Agent CostControl — онлайн-метрики дополняют офлайн-бенчмарки
• Agent Code Review — архитектура ревьюера и sealed manifest для denominator