Reef Infras OpenClaw-RL verwandelt Nutzerkorrekturen in Trainingsdaten – Session-Matching ist der Haken

Reef Infras OpenClaw-RL-Rezept behandelt die nächste Nutzernachricht als Trainingssignal – aber erst, nachdem der schwierige Teil gelöst ist: herauszufinden, auf welchen früheren Turn sich die Korrektur tatsächlich bezieht. Eine Nachricht wie „Nein, behalte die Schritte, hör nur auf, alles in Aufzählungspunkte zu packen“ enthält echtes Feedback, lässt das System aber ableiten, was abgelehnt wurde, was bleiben soll und welche Antwort korrigiert wird.

So funktioniert die Pipeline

• Rekonstruiert Konversationen aus aufgezeichnetem Inferenz-Traffic.
• Schickt einen abgeschlossenen Turn plus seinen Folgezustand an einen separaten PRM-Judge.
• Bündelt die bewerteten Turns für das Training.

Das Training verwendet zwei Terme. Akzeptanz kann einen Hindsight-Hinweis erzeugen, der vom On-Policy-Distillation-Term konsumiert wird; der andere Term ist ein PPO-artiges Update auf den gesampelten Tokens. Beides sind Parameter-Updates an einer trainierbaren Policy – das ist kein Memory-Write, sondern eine Gewichtsänderung.

Die Session-Korrelation ist das Deployment-Detail, das zubeißt

Das Harness sollte einen stabilen x-reef-tag-session-Wert an Aufrufe in derselben Konversation hängen. Ohne ihn fällt Reef Infra auf den Abgleich der Transkripte zurück, die Clients erneut senden – und Kompaktierung oder ein gleitendes Fenster können diesen Abgleich zunichtemachen. Ein nicht zugeordneter Turn erreicht nie den Judge und wird nie zu Trainingsdaten, sodass Traffic, der auf deinen Dashboards gesund aussieht, null Lernsignal erzeugen kann.

Das enthaltene Experiment und was es nicht beweist

Das Repo liefert einen kleinen Anpassungstest mit: Ein simulierter Student lehnt Hausaufgabenantworten ab, die Fettdruck oder Listen enthalten. Im aufgezeichneten Lauf erreicht der Agent in Session 14 drei aufeinanderfolgende bestandene Erstantworten. Das ist ein Lauf über die ersten 36 Sessions – kein Beweis dafür, dass beliebige Nutzerpräferenzen mit dieser Rate konvergieren.

Was du zum Ausführen brauchst

• Ein trainierbares Modell
• Einen GPU-Stack
• Den PRM-Judge

Das Interessante ist, dass Feedback-Inferenz, Session-Matching und das eigentliche Gewichts-Update trennbare Komponenten sind, die du unabhängig untersuchen kannst. Erwähnenswert für den Vergleich: dieselbe Beschwerde in einer Markdown-Memory-Datei zu speichern, nutzt einen völlig anderen Mechanismus – keinen Judge, kein Policy-Update.