AI-Agent-Benchmarks: GAIA, WebArena, OSWorld und SWE-bench

GAIA prüft Antworten auf realistische Fragen, die Reasoning, Multimodalität, Web-Browsing und Tool-Nutzung kombinieren. WebArena prüft lange Aufgaben in reproduzierbaren funktionalen Websites. OSWorld ergänzt Desktop-Anwendungen, File I/O und Multi-App-Workflows in einer realen Computerumgebung. SWE-bench startet mit einem GitHub-Issue und einem Repository-Snapshot und prüft, ob ein Patch das Software-Engineering-Problem löst. Das sind keine vier austauschbaren Rankings: Jeder Benchmark misst eine andere Task Distribution, einen anderen Observation/Action Space und eine andere Definition von Erfolg.

Benennen Sie zuerst die Production-Entscheidung: einen Scaffold auswählen, einen Browser-Workflow freigeben, einen Coding Agent wechseln oder einen Autonomy Tier erweitern. Ordnen Sie danach die reale Arbeit dem Benchmark Contract zu. Ein externes Ergebnis liefert einen Prior zur Capability, beweist aber keine Qualität auf Ihren Daten, Berechtigungen, Locales, UIs, Repositories oder Fehlerkosten. Für einen Release braucht es weiterhin einen internen Eval Slice mit derselben Aufgabenform und einem unabhängigen Oracle.

GAIA passt, wenn der Agent Fakten sammelt, mit Dateien und multimodalen Inputs arbeitet, Web oder Tools nutzt und eine überprüfbare kurze Antwort liefert. Die Stärke liegt in der Kombination grundlegender Assistant-Fähigkeiten; für Production fehlt jedoch Ihr konkreter Application State mit consequential side effects. Ergänzen Sie eigene Knowledge-Work-Aufgaben, Zitierregeln, Freshness Cutoff und Abstention Cases.

Wählen Sie WebArena für einen Browser Agent, der E-Commerce-, Forum-, Collaborative-Development- oder Content-Management-Interfaces navigiert und einen funktionalen Zielzustand erreichen muss. OSWorld passt besser zu einem Computer-Use-Agenten, der zwischen Browser, Office, Betriebssystem und Datei-Workflows wechselt. Für einen Coding Agent liefert SWE-bench ein Issue-to-Patch-Signal auf realen Repositories; Ihr internes Replay muss jedoch Toolchain, Instructions, Hidden Checks und Review Policy reproduzieren.

• GAIA → General-Assistant-Fragen, Browsing, Tools und multimodale Evidence.
• WebArena → funktionale Web-Tasks und execution-basierte Outcomes.
• OSWorld → Desktop, Dateien und Workflows über mehrere Anwendungen.
• SWE-bench → Repository-Issue, Codeänderung und testbasierte Lösung.

Ein Modellname plus ein Prozentwert ist kein reproduzierbares Ergebnis. Dokumentieren Sie Benchmark-Revision oder Split, Agent Scaffold, Prompt, Tools, Observation Mode, Action Adapter, Budget, Retry Policy, Sample Count, Environment Image, Dependency State und Grader-Version. Für Web- und Desktop-Umgebungen kommen Viewport, Locale, Account Fixtures, Reset Status und der Anteil von Infrastructure Failures hinzu. Bei Coding-Evals pinnen Sie Base Commit, Test Command, Patch Application, Network Policy und Contamination Controls.

Vergleichen Sie nur Runs mit kompatiblen Regeln. Pass@k mit mehreren Versuchen ist nicht First-Run Reliability; Erfolg mit Browser ist nicht Erfolg ohne Web-Zugriff; ein anderer Scaffold kann Unterschiede besser erklären als Model Capability. Übertragen Sie historische Baseline-Zahlen nicht auf das aktuelle Produkt: Sie gehören zu einer bestimmten Paper- und Harness-Version. Speichern Sie im Decision Record den Link zum primären Result Artifact statt eine Leaderboard-Zahl ohne Provenance zu kopieren.

Construct Validity fragt, ob Task und Grader wirklich die benötigte Fähigkeit messen. Exact-Answer-Grading ist für eine GAIA-ähnliche Frage nützlich, sagt aber nichts über die Sicherheit der Trajektorie. Ein bestandener Test in SWE-bench kann das Verhalten eines Patches bestätigen, ohne Maintainability oder interne Policy-Konformität zu beweisen. Ein Web- oder Desktop-Grader kann den richtigen Final State sehen und trotzdem eine unnötige Nachricht, ein Datenleck oder einen wiederholten Side Effect übersehen. Ergänzen Sie getrennte Outcome-, Trajectory-, Policy- und Side-Effect-Verdicts.

Prüfen Sie, ob Tasks, Solutions, Screenshots oder Repositories in Training, Examples oder Prompt Tuning gelangt sein könnten. Ein held-out internes Set darf dem Team, das den Agenten optimiert, nicht sichtbar sein. Kennzeichnen Sie Environment Failures separat: Eine Website, die nicht startet, eine fehlende Dependency oder ein nicht erreichbares Oracle ist weder Model Failure noch Success. Spielen Sie regelmäßig eine known-good Baseline erneut ab, um Agent Regression von Harness Drift zu unterscheiden.

Ein Bridge Set ist ein kleiner versionierter Datensatz, der die Form des externen Benchmarks bewahrt, aber die Domain durch Ihre ersetzt. Für einen Research Assistant nutzen Sie Multi-Source-Fragen mit Aktualitätsdatum und Citation Oracle; für einen Browser Agent eine resettable Kopie eines Kernworkflows; für einen Desktop Agent synthetische Dateien und abgefangene Outputs; für einen Coding Agent bereinigte historische Issues auf pinned Commits. Jeder Task braucht Owner, Initial State, Authority, Terminal State, Prohibited Events und einen unabhängigen Grader.

Führen Sie Public Signal, Bridge Set und Production Regression als drei getrennte Schichten aus. Die erste erleichtert den Vergleich mit dem Research-Ökosystem, die zweite prüft Capability Transfer, die dritte schützt lokale Invarianten. Promotion verlangt akzeptable Ergebnisse in allen Risk Slices, keine definierten Critical Failures und einen getesteten Rollback für Model-, Prompt-, Tool- und Policy-Bundle. Ein Durchschnittsscore kann keine unautorisierte Zahlung, kein Secret Leak und keinen destruktiven Patch kompensieren.

Das Evidence Pack enthält Decision Question, Benchmark-to-Workflow-Mapping, Manifest jedes Runs, Raw Outcomes, Grader Evidence, Failure Taxonomy, segmentierte Ergebnisse, Reviewer Sign-off und Known Limitations. Dokumentieren Sie separat, was nicht getestet wurde: eine neue Locale, eine längere Aufgabe, ein anderer Permission Tier, Production Latency oder ein externer Side Effect. Das ist keine Bürokratie, sondern die Grenze dessen, was die Evidence tatsächlich trägt.

Nach einem Update von Model, Scaffold, Environment oder Dataset wird das vorige Verdict zu Historical Evidence. Wiederholen Sie zuerst den Frozen Slice, dann Held-out Tasks und erst danach einen engen Canary. Wenn der Candidate gegen die lokale Baseline verliert oder einen Critical Failure erzeugt, stellt Rollback ein kompatibles Bundle wieder her und stoppt neue Runs; unvollständige Side Effects müssen separat reconciled werden. Ein öffentliches Leaderboard hebt dieses Release Gate niemals auf.