Curriculum nach Kritiker-Unsicherheit: einen Web-Agenten auf einer GPU trainieren

Eine Einschränkung als Aufgabenstellung

Einen Web-Agenten mit RL zu trainieren ist teuer, weil die Umgebung langsam ist, Episoden lang sind und die Belohnung spärlich ausfällt. Die übliche Antwort ist ein Cluster. In dieser Arbeit galt die umgekehrte Bedingung: eine einzige Consumer-GPU mit 16 GB. Der Rest der Architektur ergibt sich aus dieser Einschränkung.

Hierarchie: eingefrorener Planer und trainierbarer Executor

Qwen3-8B (frozen, 4-Bit NF4)         ← Planer, setzt ein Teilziel
        ↓ Teilziel (JSON)
DeBERTa-v3-small (frozen)
        → Transformer (2 Schichten, 4 Köpfe) → GRU(256)
        → Aktionstyp + Pointer-Attention (welches Seitenelement)
        ↓ CLICK / TYPE / SCROLL / SELECT
BrowserGym / MiniWoB++

Trainiert wird nur der Executor mit einigen Millionen Parametern, der Planer hat acht Milliarden. Planer und Encoder sind eingefroren und laufen in 4-Bit-Quantisierung. Das Seitenelement wird über Pointer Attention ausgewählt, weil die Anzahl der Elemente auf einer Seite vorher unbekannt ist und eine gewöhnliche Klassifikation nicht passt.

Idee 1: ein Curriculum nach der Varianz der Value-Funktion

Ein klassisches Curriculum führt den Agenten in fester Reihenfolge von leichten zu schweren Aufgaben. Was als schwer gilt, legt dabei der Autor fest, und das muss nicht mit dem übereinstimmen, was für den Agenten tatsächlich schwierig ist.

Hier bestimmt der Kritiker die Reihenfolge. Für jede Aufgabe wird die Varianz seiner Schätzungen gespeichert, und je höher sie ist, desto häufiger wird die Aufgabe ausgewählt. Eine hohe Varianz bedeutet, dass der Agent den Wert seiner Aktionen in dieser Aufgabe noch nicht versteht, daher bringt das Training dort am meisten.

Die Varianz unterschied sich zwischen den Aufgaben um den Faktor 2740, von null bei click-link, das der Agent bereits beherrschte, bis 0,00274 bei social-media. Das zeigt, dass der Mechanismus das Trainingsbudget tatsächlich zwischen den Aufgaben umverteilt hat.

Idee 2: Reward Fusion statt binärem Erfolg

Bei langen Episoden ist eine binäre Belohnung fast immer null, und der Gradient hat keinen Ansatzpunkt. Die Belohnung setzt sich deshalb aus vier Termen zusammen:

R = 0,5·ORM + 0,3·R_DOM + 0,2·R_waypoint − Strafen

• ORM: Bewertung des Endzustands durch ein Judge-Modell;
• R_DOM: programmatische DOM-Prüfung, etwa ob ein Feld ausgefüllt, ein Dialog geschlossen oder eine Checkbox markiert ist;
• R_waypoint: Zwischenziele innerhalb einer Episode;
• Strafen: für überflüssige Aktionen und unzulässige Übergänge.

Die Logs des Laufs enthalten 100 verschiedene Belohnungswerte zwischen −8,4 und +0,92. Das bestätigt, dass die Belohnung tatsächlich abgestuft ist und wie vorgesehen funktioniert.

Ergebnisse

Metrik	Wert
Mittlere SR (Phase 3)	42 %
Finale SR (letzte 10 Iterationen)	61,7 %
Aufgaben mit SR größer null	20 von 25
Umgebungsschritte	50 000

Die besten Ergebnisse erzielten click-dialog und focus-text (100 %) sowie click-button (60 %).

Was nicht funktioniert hat

Die Misserfolge dieser Arbeit verdienen ebenso viel Aufmerksamkeit wie die Ergebnisse.

• choose-date / book-flight: Der jQuery-Datepicker sammelt beim Neuzeichnen des DOM Element-IDs an, wodurch lange Navigation unzuverlässig wird.
• enter-date / enter-time: Drei Eingabefelder teilen sich eine ID, und das standardmäßige fill() funktioniert in der aktuellen Version der Umgebung nicht.
• email-inbox / search-engine: Diese Aufgaben erfordern Schlussfolgern, die Auswahl eines Elements reicht nicht aus, und die Pointer-Policy stößt hier an ihre Grenze.
• PopArt: Die Normalisierungsstatistiken der Value-Funktion werden nicht im Checkpoint gespeichert und beim Fortsetzen des Trainings neu berechnet.

Die ersten beiden Probleme gehen auf Versionsdrift der Umgebung zurück und haben mit der Methode selbst nichts zu tun. Die letzten beiden spiegeln echte Grenzen der Architektur wider und bestimmen die Richtung der nächsten Arbeit.