TTRL: Reinforcement Learning auf unbeschrifteten Testdaten

Das Label-Problem, das TTRL adressiert

Klassisches RLVR (Reinforcement Learning with Verifiable Rewards) braucht eine prüfbare Antwort: eine Zahl, einen Beweis, einen Einheitentest. Genau diese Prüfung fehlt, sobald man auf echten Testdaten arbeitet, deren Labels nicht veröffentlicht sind. Die README beschreibt die Kernaufgabe deshalb als Schätzung der Belohnung während der Inferenz, ohne Zugriff auf Ground-Truth-Informationen. TTRL richtet sich an Forschende, die ein bestehendes Reasoning-Modell auf einem solchen unbeschrifteten Satz weiter trainieren wollen, statt nur die Decodierung zu verbessern. Der Einsatzfall ist eng: Es geht um Aufgaben mit eindeutigem Antwortformat, bei denen mehrere Stichproben des Modells überhaupt vergleichbar sind. Freitext-Antworten ohne kanonische Form lassen sich mit dem Mehrheits-Reward nicht sinnvoll bewerten.

Mehrheitsvoting als Reward-Signal

Der Mechanismus ist im Kern eine geänderte Reward-Funktion. Die README verweist auf ein Pseudo-Code-Snippet in figs/ttrl_reward.png: Das Modell erzeugt für dieselbe Frage mehrere Antworten, die häufigste Antwort wird zur Referenz, und alle Antworten, die dieser Mehrheit entsprechen, erhalten Belohnung. Das ist die Praktik des Test-Time Scaling, hier Majority Voting genannt, nur dass sie nicht zur Auswahl einer Antwort dient, sondern als Trainingssignal. Der Datenfluss bleibt der einer gewöhnlichen RL-Pipeline: Prompts kommen aus dem Testdatensatz, Rollouts entstehen im Sampling, der Reward wird aus den Rollouts selbst berechnet, und die Policy wird mit diesem selbst erzeugten Signal aktualisiert. Laut README ist die Umsetzung schnell erreichbar, indem man allein die Reward-Funktion anpasst. Genau darin liegt die Anziehungskraft und das Risiko: Das Modell trainiert gegen seine eigene Mehrheitsmeinung.

Aufsatz auf verl und die Rolle von v0.4.1

TTRL ist keine eigenständige Trainings-Engine. Die News-Sektion vermerkt, dass die Implementierung seit Mai 2025 auf verl basiert, und ab verl v0.4.1 lässt sich TTRL laut Release-Hinweis mit einem einzigen Flag aktivieren: +ttrl.enable=True. Das ist ein wichtiger Hinweis auf die Wartungslage, denn es bedeutet, dass die TTRL-Logik inzwischen im Upstream von verl lebt und das Repository selbst vor allem Skripte, Rezepte und Datenaufbereitung liefert. Wer TTRL produktiv einsetzen will, muss also die Versionskompatibilität mit verl im Auge behalten. Die README verweist für weitere Details ausdrücklich auf die verl-Dokumentation, nicht auf eine eigene API-Referenz. Das ist ein Indiz dafür, dass die Projektdokumentation dünn ist und die eigentliche Referenz woanders liegt.

Installation und erster Lauf

Die README gibt einen konkreten Ablauf vor. Zuerst das Repository klonen, dann in das Unterverzeichnis verl wechseln, eine Conda-Umgebung mit Python 3.10 anlegen, die Abhängigkeiten über bash scripts/install_ttrl_deps.sh installieren und das Paket mit pip install -e . im editierbaren Modus einbinden. Der Reproduktionsbefehl für AIME 2024 lautet bash examples/ttrl/Qwen2.5/aime.sh. Für eigene Daten nennt die README das Skript verl/data/preprocess.py, das JSON in Parquet konvertiert, das Format, das verl für das Training erwartet. Weitere Skripte liegen unter verl/examples/ttrl für verschiedene Modelle und Benchmarks. Alle Experimente wurden laut README auf 8 x NVIDIA A100 80GB ausgeführt. Diese Hardwareangabe ist kein Nebensatz, sondern eine Einstiegshürde: Wer weniger Speicher hat, muss die Batch- und Rollout-Konfiguration selbst anpassen, und dazu schweigt die README.

Wo der Mehrheits-Reward trägt und wo nicht

Die zentrale Einschränkung steckt im Reward selbst. Eine Mehrheit ist nur dann ein nützliches Signal, wenn die Aufgabe überhaupt eine stabile konsensfähige Antwort besitzt und das Modell sie häufig genug erzeugt. Bei Aufgaben mit mehrdeutigen oder offenen Antworten belohnt das Verfahren die häufigste Formulierung, nicht die korrekte Lösung. Die README berichtet, dass TTRL das maj@n-Maß des Ausgangsmodells übersteigt und sich der Leistung von Modellen nähert, die direkt auf Testdaten mit Ground-Truth-Labels trainiert wurden. Das ist eine starke Aussage, aber sie beschreibt genau den Fall, in dem das Signal funktioniert. Für den umgekehrten Fall, in dem die Mehrheit falsch liegt, nennt das Material keine Schutzmaßnahme. Wer TTRL auf ein Modell anwendet, dessen Antworten bereits systematisch danebenliegen, verstärkt diesen Fehler, statt ihn zu korrigieren.

Reproduzierbarkeit und Streuung der Ergebnisse

Die README ist an einer Stelle ungewöhnlich offen: Drei unabhängige Läufe mit der Vorschauversion des Codes werden berichtet, zwei erreichten pass@1 (greedy) von 43,3, einer 46,7. Diese Streuung von über drei Punkten zwischen identisch konfigurierten Läufen ist ein Befund, der bei der Bewertung jedes einzelnen Ergebnisses mitgedacht werden muss. Ein Vergleich zwischen zwei Methoden, die nur einen Lauf pro Konfiguration vorweisen, ist damit kaum belastbar. Die Logs liegen laut README in einem öffentlichen Weights-&-Biases-Workspace, was die Nachprüfung erleichtert. Wer TTRL für eigene Zwecke evaluiert, sollte mehrere Seeds fahren und die Streuung mitberichten, sonst lässt sich ein Effekt nicht von Rauschen trennen. Das Material liefert dafür keine automatische Auswertung.

Alternative: Test-Time Scaling ohne Gewichtsänderung

Die naheliegende Alternative ist, genau dieselbe Mehrheitsentscheidung zu nutzen, ohne das Modell zu trainieren. Man erzeugt n Stichproben pro Frage, stimmt ab und gibt die Mehrheitsantwort zurück. Das ist der klassische Test-Time-Scaling-Ansatz, und die README beschreibt ihn als die Praktik, aus der TTRL seinen Reward bezieht. Der Unterschied liegt im Aufwand und in der Wirkung: Reines Voting kostet nur Inferenz, verändert kein Gewicht und wirkt ausschließlich auf die aktuelle Anfrage. TTRL dagegen schreibt die Mehrheitsmeinung dauerhaft in die Gewichte, was auf neue Aufgaben übertragen kann, aber auch die Fehler der Mehrheit festschreibt. Wer nur eine einzelne Charge von Fragen beantworten will, fährt mit Voting günstiger. TTRL lohnt sich erst, wenn das trainierte Modell danach auf weiteren Aufgaben eingesetzt werden soll.

Lizenz, Wartung und Kosten

TTRL steht unter der MIT-Lizenz, was die Nutzung, Veränderung und Weitergabe mit Namensnennung erlaubt. Da die Trainingslogik inzwischen überwiegend in verl liegt, hängt der Wartungsaufwand an zwei Projekten: dem TTRL-Repository für Skripte und Datenaufbereitung und verl für die eigentliche Engine. Das Flag +ttrl.enable=True ab verl v0.4.1 ist der sauberste Weg, aber es bindet die eigene Pipeline an die verl-Versionslinie. Ein Upgrade von verl kann damit auch das TTRL-Verhalten verändern, ohne dass sich im TTRL-Repository etwas bewegt. Die Lizenzangaben in der README betreffen nur TTRL selbst; für verl und die Modellgewichte sind die jeweiligen Bedingungen separat zu prüfen. Diese Einschätzung ist keine Rechtsberatung.

Redaktionelles Fazit

TTRL ist für Forschungsteams gedacht, die Reasoning-Modelle auf Benchmarks ohne veröffentlichte Labels nachtrainieren wollen und dafür 8 x NVIDIA A100 80GB bereitstellen können. Wer lediglich eine bessere Inferenz-Strategie für ein festes Modell sucht, ist hier falsch: TTRL verändert die Gewichte. Vor dem ersten Lauf sollte man prüfen, ob der Mehrheits-Reward bei der eigenen Aufgabe überhaupt trägt, denn bei Aufgaben ohne verlässliche Konsensbildung kippt das Verfahren in die Selbstbestätigung. Der ehrlichste Test bleibt der Vergleich von maj@n des Basismodells gegen pass@1 nach dem Training auf demselben Datensatz.

Offizielle Quellen

1. License: MIT
2. PRIME-RL/TTRL on GitHub
3. Project website
4. README
5. Releases