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

Die Einschränkung ist die Aufgabenstellung

Einen Web-Agenten per RL zu trainieren ist teuer: Die Umgebung ist langsam, Episoden sind lang, die Belohnung ist spärlich. Die übliche Antwort lautet Cluster. Die Bedingung dieser Arbeit war die umgekehrte: eine einzelne Consumer-GPU mit 16 GB. Alles Weitere in der Architektur folgt daraus.

Hierarchie: eingefrorener Planer, 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 - einige Millionen Parameter statt acht Milliarden. Planer und Encoder bleiben eingefroren in 4-Bit-Quantisierung. Die Elementauswahl läuft über Pointer-Attention statt Klassifikation, denn die Zahl der Elemente einer Seite ist vorab unbekannt.

Idee 1: Curriculum nach der Value-Varianz

Ein klassisches Curriculum geht in vorab festgelegter Reihenfolge von leicht nach schwer. Das Problem: „schwer" definiert der Autor, nicht der Agent.

Hier bestimmt der Kritiker die Reihenfolge. Für jede Aufgabe wird die Varianz seiner Value-Schätzungen mitgeführt, und Aufgaben werden umso häufiger gezogen, je höher diese Varianz ist. Hohe Varianz heißt: Der Agent weiß nicht, was seine Aktionen in dieser Aufgabe wert sind - genau dort bringt Training am meisten.

Die Spanne zwischen den Aufgaben betrug 2740×: von null bei click-link, längst gelöst, bis 0,00274 bei social-media. Der Mechanismus hat das Trainingsbudget also tatsächlich umverteilt und nicht gleichmäßig gestreut.

Idee 2: Reward Fusion statt binärem Erfolg

Eine binäre Belohnung ist bei langen Episoden fast immer null, dem Gradienten fehlt jeder Halt. Die Belohnung setzt sich 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: Ist das Feld wirklich gefüllt, der Dialog geschlossen, die Checkbox gesetzt;
• R_waypoint - Zwischenmarken innerhalb einer Episode;
• Strafen - für überflüssige Aktionen und unzulässige Übergänge.

Die Laufprotokolle enthalten 100 verschiedene Belohnungswerte zwischen −8,4 und +0,92. Genau das belegt, dass das Schema greift: Die Belohnung ist wirklich abgestuft und kein verkapptes Binärsignal.

Ergebnisse

Metrik	Wert
Mittlere SR (Phase 3)	42 %
Finale SR (letzte 10 Iterationen)	61,7 %
Aufgaben mit SR > 0	20 von 25
Umgebungsschritte	50 000

Beste Aufgaben: click-dialog und focus-text (100 %), click-button (60 %).

Was nicht funktioniert hat

Eine ehrliche Liste zählt mehr als die Tabelle.

• 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 Kennung, das eingebaute fill() greift in der aktuellen Umgebungsversion nicht.
• email-inbox / search-engine: Diese Aufgaben verlangen Schlussfolgern statt Elementauswahl - die Grenze der Pointer-Policy selbst.
• PopArt: Die Statistiken der Value-Normalisierung landen nicht im Checkpoint und werden beim Fortsetzen neu berechnet.

Die ersten beiden Punkte sind Versionsdrift der Umgebung, keine Eigenschaft der Methode. Die letzten beiden sind echte Architekturgrenzen - und sie weisen die Richtung für die nächste Arbeit.