AI agent benchmarks: GAIA, WebArena, OSWorld і SWE-bench

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

Спочатку назвіть production-рішення: вибрати scaffold, дозволити browser workflow, змінити coding agent або розширити autonomy tier. Потім зіставте реальну роботу з benchmark contract. Зовнішній результат дає prior про capability, але не доводить якість на ваших даних, правах, локалі, 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 interfaces і має досягти функціонального стану. 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 questions, browsing, tools і multimodal evidence.
• WebArena → функціональні web tasks та execution-based outcome.
• OSWorld → desktop, files і workflows між застосунками.
• SWE-bench → repository issue, code change і 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 application, 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-подібного питання, але не покаже безпечність траєкторії. Test pass у SWE-bench може підтвердити поведінку patch, але не гарантує maintainability або відповідність внутрішній policy. Web і desktop grader може побачити правильний final state, не помітивши зайвого повідомлення, витоку даних або повторного side effect. Тому додавайте окремі outcome, trajectory, policy і side-effect verdicts.

Перевірте, чи tasks, solutions, screenshots або repositories могли потрапити в training, examples чи prompt tuning. Held-out внутрішній набір не повинен бути видимим команді, що оптимізує agent. Environment failure позначайте окремо: сайт не піднявся, 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. Кожен task має owner, initial state, authority, terminal state, prohibited events і незалежний grader.

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

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

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