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 на трёх наборах показывает, насколько это меняет вывод:

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.

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

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

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

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

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

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

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

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

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

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

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

Связано с

• Model Selection — бенчмарки = критерий «качество»
• AI Agent — AgentBench меряет именно «агентность»
• Agent CostControl — онлайн-метрики дополняют офлайн-бенчмарки