WebArena: Der Benchmark mit 812 Aufgaben, der misst, was Web-Agenten tatsächlich können und was nicht

Der WebArena-Benchmark mit 812 Aufgaben ist der direkte Vorgänger von WorkArena, über das ich gestern berichtet habe. Das Lesen beider Arbeiten hintereinander verdeutlicht eine wichtige Unterscheidung: Während WorkArena die Wissensarbeit in Unternehmen auf einer einzigen Plattform (ServiceNow) misst, legt WebArena die allgemeine Basisfähigkeit für Web-Agenten über realistische Open-Source-Software hinweg fest. Ich möchte diese Basis genau verstehen, bevor ich über Beancount-Agenten nachdenke, die schließlich in Browser-Umgebungen agieren werden.

Das Paper

Zhou et al. (ICLR 2024, arXiv:2307.13854) führen WebArena ein, einen reproduzierbaren Benchmark mit 812 Aufgaben auf vier selbst gehosteten Websites: einem Magento E-Commerce-Shop, einem Postmill-Sozialforum, einer GitLab-Instanz und einem Magento CMS-Admin-Portal, ergänzt durch einen OpenStreetMap-Mirror und eine Offline-Wikipedia-Kopie. Im Gegensatz zu den synthetischen Spielzeugaufgaben von MiniWoB++ läuft auf jeder WebArena-Seite echte Open-Source-Software mit authentischem Umfang: etwa 90.000 Produkte, 95 Subreddits mit über 127.000 Posts und 300 Git-Repositories auf 1.000 Entwicklerkonten. Die Aufgaben umfassen drei Kategorien – Informationsbeschaffung, Seitennavigation sowie Inhalts- und Konfigurationsänderungen – und werden nach funktionaler Korrektheit bewertet: Ob das beabsichtigte Ergebnis in der Datenbank erscheint oder einer exakten bzw. unscharfen Antwort entspricht, und nicht, ob der Agent die erwartete Aktionssequenz befolgt hat.

Kernideen

• GPT-4 erreicht 14,41 %; Menschen erreichen 78,24 %. Die Lücke beträgt 63,8 Prozentpunkte. GPT-3.5 erzielt 8,75 % und die Google Text-Bison-001-Baseline lediglich 5,05 %. Chain-of-Thought-Prompting bringt für GPT-4 etwa 2,3 zusätzliche Punkte – hilfreich, aber nicht bahnbrechend.
• Der häufigste Fehler ist die falsche Unmöglichkeit. GPT-4 stufte etwa 54,9 % der lösbaren Aufgaben (428 von 812) fälschlicherweise als undurchführbar ein und gab [N/A] zurück, anstatt sie zu versuchen. Dies ist der dominierende Fehlermodus, nicht fehlerhafte Aktionssequenzen oder Tool-Fehler.
• Funktionale Korrektheit statt Trajektorien-Wiedergabe. Die Bewertung prüft vier Beweistypen: Exakte Übereinstimmung, Keyword-Prüfungen, LLM-basierter unscharfer Vergleich (Fuzzy Match) und programmatische Validierung über Datenbankabfragen oder JavaScript. Dies macht die Metrik robust gegenüber Paraphrasierungen, bleibt aber anfällig für mehrdeutige Aufgabenspezifikationen.
• Containerisiertes Self-Hosting ermöglicht Reproduzierbarkeit. Alle vier Seiten werden als Docker-Container bereitgestellt, was spätere Benchmarks (WorkArena, OSWorld) übernommen haben. Man kann den Status zurücksetzen und identische Startbedingungen garantieren, was beim Live-Web-Scraping unmöglich ist.
• Aufgabenvorlagen vermeiden blindes Auswendiglernen. 241 Vorlagen ergeben 812 instanziierte Aufgaben (jeweils 3,3 Varianten), was zwar hilft, ein entschlossenes Modell jedoch nicht daran hindert, Vorlagenmuster statt Web-Navigationsprinzipien zu lernen.
• Die reale DOM-Komplexität ist um Größenordnungen höher als bei MiniWoB++. Eine typische WebArena-Seite serialisiert zu Tausenden von Token; verwandte Arbeiten berichten von DOM-Bäumen mit über 100.000 Token für komplexe Portalansichten.

Was Bestand hat – und was nicht

Die Kernmethodik ist solide: Echte Software, ergebnisbasierte Bewertung und reproduzierbare Umgebungen sind genau richtig. Die Zahl von 14,41 % hat sich in unabhängigen Reproduktionen als beständig erwiesen, und die Fehlertaxonomie (falsche Undurchführbarkeit, Schleifenverhalten, zaghafte Verweigerung) wurde durch mehrere Folgearbeiten bestätigt.

Die Einschränkungen sind jedoch real. Erstens bedeuten 812 Aufgaben aus 241 Vorlagen, dass der Benchmark endlich und systematisch abdeckbar ist; ein Agent, der Vorlagenmuster auswendig lernt, könnte sich überanpassen, ohne zu generalisieren. WebArena Verified (2024–2025) entdeckte und reparierte fehlerhafte Bewertungsprüfungen, was bedeutet, dass ein Teil der ursprünglichen 14,41 % eher auf Bewertungsrauschen als auf reiner Fähigkeit beruhen könnte. Zweitens sind die vier Website-Typen – E-Commerce, Forum, Code-Hosting, CMS – zwar plausibel, aber keine repräsentative Stichprobe des Webs. Es gibt kein Enterprise-SaaS, kein formularlastiges Behördenportal, kein Banking-Interface. Drittens ignoriert der Benchmark Sicherheit und Vertrauenswürdigkeit vollständig: Ein Agent, dem „diesen Post löschen“ gelingt, erhält die gleiche Punktzahl, egal ob er den richtigen Post oder zehn andere löscht. ST-WebAgentBench (2024) wurde speziell entwickelt, um diese Lücke zu schließen.

Der Befund der falschen Undurchführbarkeit ist das interessanteste und am wenigsten beachtete Ergebnis. Er deutet darauf hin, dass LLMs darauf kalibriert sind, Handlungen unter Unsicherheit zu vermeiden – ein vernünftiger Prior für Modelle, die mit menschlichem Feedback trainiert wurden –, dass diese konservative Kalibrierung aber für agentische Aufgaben genau falsch ist, bei denen das Nicht-Handeln selbst ein kostspieliger Fehler ist.

Warum das für Finanz-KI wichtig ist

Die Lücke zwischen 14,41 % und 78,24 % kalibriert direkt, was ein Beancount-Browser-Agent heute ohne spezialisiertes Engineering erreichen kann. Wenn GPT-4 routinemäßige Web-Aufgaben – die Bestellung eines Produkts, das Erstellen eines GitLab-Issues, das Posten in einem Forum – nicht zuverlässig bewältigen kann, kann man ihm sicherlich nicht zutrauen, das Fava-Web-UI ohne Aufsicht zu bedienen. Dies ist kein Plädoyer für Verzweiflung; es motiviert die Art von zweckgebundenen Schnittstellen und strukturierten Aktionsräumen, wie sie der SWE-agent für die Code-Bearbeitung demonstriert hat. Die richtige Lektion ist, dass die reine LLM-Fähigkeit, gemessen an generischen Aufgaben, nicht das ist, was zählt; entscheidend ist, wie sehr die Umgebung darauf ausgelegt ist, den Agenten zu unterstützen.

Das Problem der falschen Undurchführbarkeit hat eine direkte Entsprechung in der Buchhaltung: Ein Agent, der zurückgibt „Ich kann nicht feststellen, ob diese Transaktion ein Duplikat ist“, anstatt dies zu prüfen, scheitert auf genau die gleiche konservative, aber falsche Weise. Write-back-Agenten benötigen einen expliziten Schritt zur Durchführbarkeitsprüfung, der eine Entscheidung erzwingt, anstatt sich zu enthalten, gepaart mit Rollback-Sicherheitsnetzen, damit eine falsche Entscheidung korrigierbar bleibt.

Speziell für Beancount ist der CMS- und Admin-Portal-Teil von WebArena (Magento Admin) das engste strukturelle Analogon zum Fava-Web-UI: ein mehrseitiges Admin-Interface mit komplexen Formularen, verschachtelter Navigation und einem Status, der über Sitzungen hinweg bestehen bleibt. Die Obergrenze von 14,41 % für diese Aufgabenklasse sollte ich als Standardannahme betrachten, bis wir etwas Besseres demonstrieren.

Was man als Nächstes lesen sollte

• VisualWebArena (Koh et al., 2024, arXiv:2401.13649) – erweitert WebArena auf multimodale Agenten unter Verwendung von Screenshots, was für Fava wichtig ist, da sich nicht alle relevanten Zustände im DOM befinden.
• OSWorld (Xie et al., NeurIPS 2024, arXiv:2404.07972) – ein Benchmark für vollständige Desktop-Umgebungen; 12,24 % für das beste multimodale Modell gegenüber 72,36 % für Menschen, was die Fähigkeitslücke auf die GUI-Automatisierung über den Browser hinaus ausdehnt.
• ST-WebAgentBench (arXiv:2410.06703) – befasst sich direkt mit der Sicherheitslücke in WebArena und misst, ob Web-Agenten Richtlinienbeschränkungen einhalten, während sie Aufgaben erledigen.