Бенчмарки AI-агентов: GAIA, WebArena, OSWorld и SWE-bench

GAIA проверяет ответы на реалистичные вопросы, объединяющие reasoning, multimodality, web browsing и tool use. WebArena проверяет длинные задачи на воспроизводимых функциональных сайтах. OSWorld добавляет desktop-приложения, file I/O и multi-app workflows в реальной компьютерной среде. SWE-bench начинается с GitHub issue и snapshot репозитория и проверяет, решает ли patch проблему software engineering. Это не четыре взаимозаменяемых рейтинга: каждый измеряет свою task distribution, observation/action space и собственное определение успеха.

Сначала сформулируйте production-решение: выбрать scaffold, разрешить browser workflow, сменить coding agent или расширить autonomy tier. Затем сопоставьте реальную работу с benchmark contract. Внешний результат дает prior по capability, но не доказывает качество на ваших данных, правах, locale, UI, репозитории или стоимости ошибки. Для release все равно нужен внутренний eval slice с тем же типом задач и независимым oracle.

GAIA подходит, когда агент собирает факты, работает с файлами и мультимодальными входами, использует web или tools и возвращает проверяемый короткий ответ. Сильная сторона — композиция базовых assistant abilities; ограничение для production — отсутствие состояния ваших приложений и consequential side effects. Добавьте собственные knowledge-work задачи, правила цитирования, freshness cutoff и abstention cases.

WebArena выбирайте для browser agent, который работает с e-commerce, forum, collaborative-development или content-management интерфейсами и должен достигать функционального состояния. OSWorld лучше соответствует computer-use агенту, переключающемуся между browser, office, operating system и file workflows. Для coding agent SWE-bench дает issue-to-patch сигнал на реальных repositories, но внутренний replay должен воспроизводить ваш toolchain, instructions, hidden checks и review policy.

• GAIA → general-assistant вопросы, browsing, tools и multimodal evidence.
• WebArena → функциональные web tasks и execution-based outcome.
• OSWorld → desktop, файлы и workflows между приложениями.
• SWE-bench → repository issue, изменение кода и test-based resolution.

Название модели и один процент не являются воспроизводимым результатом. Зафиксируйте benchmark revision или split, agent scaffold, prompt, tools, observation mode, action adapter, budget, retry policy, sample count, environment image, dependency state и grader version. Для web и desktop дополнительно укажите viewport, locale, account fixtures, reset status и долю infrastructure failures. Для coding eval закрепите base commit, test command, применение patch, network policy и contamination controls.

Сравнивайте только runs с совместимыми правилами. Pass@k с несколькими попытками не равен first-run reliability; успех с browser не равен успеху без web; другой scaffold может объяснить разницу лучше, чем model capability. Не переносите исторические baseline numbers в текущий продукт: они относятся к конкретной версии paper и harness. В decision record храните ссылку на первичный result artifact, а не переписанную leaderboard-цифру без provenance.

Construct validity отвечает на вопрос, измеряют ли task и grader нужную способность. Exact answer полезен для вопроса в стиле GAIA, но ничего не говорит о безопасности trajectory. Прохождение теста в SWE-bench может подтвердить поведение patch, не гарантируя maintainability или соответствие внутренней policy. Web- или desktop-grader может увидеть правильный final state, но пропустить лишнее сообщение, утечку данных или повторный side effect. Добавьте отдельные verdicts для outcome, trajectory, policy и side effects.

Проверьте, могли ли tasks, solutions, screenshots или repositories попасть в training, examples или prompt tuning. Held-out внутренний набор не должен быть виден команде, оптимизирующей агента. Ошибки environment помечайте отдельно: не запустившийся сайт, недоступная dependency или отсутствующий oracle — это не model failure и не success. Регулярно replay-те known-good baseline, чтобы отделить regression агента от drift harness.

Bridge set — небольшой версионированный набор, сохраняющий форму внешнего benchmark, но заменяющий домен на ваш. Для research assistant используйте multi-source вопросы с датой актуальности и citation oracle; для browser agent — resettable копию ключевого workflow; для desktop agent — synthetic files и intercepted outputs; для coding agent — очищенные исторические issues на pinned commits. У каждой задачи должны быть owner, initial state, authority, terminal state, prohibited events и независимый grader.

Запускайте public signal, bridge set и production regression как три отдельных слоя. Первый позволяет сравниваться с исследовательской экосистемой, второй проверяет перенос capability, третий защищает локальные инварианты. Promotion требует приемлемых результатов по risk slices, отсутствия определенных critical failures и проверенного rollback для bundle из model, prompt, tools и policy. Средний score не компенсирует несанкционированный платеж, утечку секрета или destructive patch.

Evidence pack содержит decision question, benchmark-to-workflow mapping, manifest каждого run, raw outcomes, grader evidence, failure taxonomy, сегментированные результаты, reviewer sign-off и known limitations. Отдельно зафиксируйте, что не проверялось: новая locale, более длинная задача, другой permission tier, production latency или внешний side effect. Это не бюрократия, а граница допустимого вывода.

После обновления model, scaffold, environment или dataset предыдущий verdict становится historical evidence. Сначала повторите frozen slice, затем held-out tasks и только после этого узкий canary. Если candidate проигрывает локальному baseline или создает critical failure, rollback возвращает совместимый bundle и останавливает новые runs; незавершенные side effects нужно reconcile отдельно. Публичный leaderboard никогда не отменяет этот release gate.