Was wir über RL wissen sollten

Kurzfassung

Reinforcement Learning (RL), auf Deutsch oft bestärkendes Lernen, verschiebt moderne KI von plausibler Textproduktion zu zielgerichtetem Verhalten. Der Fortschritt liegt 2026 weniger in einem einzelnen Algorithmus als im gesamten Feedbacksystem: Aufgaben werden als Environments formuliert, Rewards werden verifizierbar, Harnesses machen Tool-Nutzung trainierbar, und verteilte Infrastruktur entscheidet, wie viele Rollouts ein Modell tatsächlich lernt.

Für Fable-5-hafte Reasoning-Modelle, Coding-Agenten und Tool-nutzende Systeme ist RL deshalb die Post-Training-Schicht, die aus einem Sprachmodell eine Policy macht: ein System, das Handlungen wählt, Fehler auswertet, zusätzliche Rechenzeit nutzt und über mehrere Schritte auf ein überprüfbares Ziel hin optimiert.

1. Warum Reinforcement Learning wieder wichtig ist

Viele KI-Systeme der letzten Jahre wurden primär darauf trainiert, Text fortzusetzen. Ein Large Language Model (LLM) lernt beim Pre-Training, aus einem riesigen Korpus den nächsten Token vorherzusagen. Dieses Ziel ist erstaunlich reich. Es zwingt Modelle, Sprache, Fakten, Programmiermuster und viele implizite Strukturen der Welt zu verdichten.

Aber Textfortsetzung ist nicht dasselbe wie zielgerichtetes Handeln.

Ein Modell kann eine plausible Antwort schreiben und trotzdem das Ziel verfehlen. Es kann einen mathematischen Lösungsweg formulieren, der lokal stimmig wirkt, aber global falsch ist. Es kann Code erzeugen, der syntaktisch sauber aussieht, aber die Tests nicht besteht. Es kann eine Websuche starten, aber die falsche Quelle priorisieren. Es kann ein Tool aufrufen, aber keinen belastbaren Abbruchpunkt erkennen.

Genau hier wird Reinforcement Learning (RL) wieder wichtig.

Reinforcement Learning optimiert Verhalten unter Rückmeldung aus einer Aufgabe oder Umgebung — nicht die bloße Plausibilität einer Ausgabe.

Diese Verschiebung ist entscheidend. Bei klassischen Sprachmodellen lautet die Trainingsfrage oft: Welcher Text ist wahrscheinlich? Bei RL lautet sie: Welche Handlung führt zum Ziel?

Das kann ein Roboterarm sein, der ein Objekt greift. Es kann ein Spiele-Agent sein, der eine Partie gewinnt. Es kann aber auch ein LLM sein, das mehrere Lösungspfade erzeugt, Code ausführt, Fehler korrigiert, einen Verifier befragt und erst dann eine Antwort abschließt.

Der aktuelle RL-Boom bei LLMs hat drei strukturelle Ursachen:

1. Reasoning-Aufgaben sind maschinell prüfbar geworden. Bei Mathematik, Code und formalen Aufgaben lässt sich oft automatisch testen, ob ein Ergebnis stimmt.
2. Modelle liefern Suchräume. Große Modelle können viele Lösungspfade erzeugen, vergleichen und verwerfen. RL kann diese Suche auf erfolgreiche Trajectories ausrichten.
3. Systeme werden agentisch. Moderne KI-Systeme schreiben nicht nur Text. Sie rufen Tools auf, durchsuchen Datenbanken, bedienen Browser, testen Code und arbeiten über mehrere Schritte hinweg.

Damit verschiebt sich der operative Fokus von Prompt → Antwort zu Aufgabe → Interaktion → verifiziertes Ergebnis.

2. Die Architektur des Handelns

Entscheidend ist die Kopplung: Ein Agent handelt in einer Umgebung, beobachtet die Folgen und wird anhand eines Feedbacksignals verändert.

flowchart LR
    A[Agent] -- Aktion --> E[Environment / Umgebung]
    E -- neuer Zustand --> A
    E -- Reward / Bewertung --> A

Ein Agent ist das lernende System. Das kann ein Roboter, ein Spieleprogramm, ein Trading-System oder ein LLM-Agent sein. Wichtig ist: Der Agent wählt eine Handlung unter Unsicherheit.

Das Environment ist die Umgebung, in der der Agent handelt. Bei einem Spiel ist es die Spielwelt. Bei Robotik ist es die physische Welt oder ein Simulator. Bei einem Coding-Agenten kann es ein GitHub-Repository mit Tests sein. Bei einem Tool-nutzenden LLM kann es ein Browser, ein Terminal, eine Datenbank oder ein API-System sein. Das Environment definiert, welche Aktionen möglich sind und welche Informationen der Agent zurückbekommt.

Eine Aktion ist das, was der Agent tut. Bei einem Roboter ist das eine Bewegung. Bei einem Spielagenten ist es ein Zug. Bei einem LLM kann eine Aktion ein Text, ein Code-Snippet, ein Tool-Aufruf oder ein nächster Planungsschritt sein. In agentischen Systemen sind Aktionen oft teuer, zustandsverändernd und nur teilweise reversibel.

Ein Reward ist die Rückmeldung. Er bewertet, wie gut ein Zwischenstand oder Endergebnis ausfällt; welche Aktion optimal gewesen wäre, verrät er nicht. Ein Reward kann positiv, negativ, binär, kontinuierlich, automatisch berechnet oder von Menschen beziehungsweise anderen Modellen geschätzt sein.

Eine Policy ist die Strategie des Agenten. Formal ist sie eine Entscheidungsregel: In welchem Zustand wählt der Agent mit welcher Wahrscheinlichkeit welche Aktion? Bei LLMs ist die Policy das Modellverhalten über Tokens, Tool-Aufrufe und Abbruchentscheidungen hinweg.

Eine Trajectory (oder Rollout) ist der erzeugte Interaktionsverlauf: Zustand, Aktion, Beobachtung, nächste Aktion und so weiter — bei LLM-RL also Prompt plus die gesamte Antwort, von einer einzigen Ausgabe bis zu Dutzenden Tool-Schritten. Das Environment weist dem Rollout einen Reward zu, bei verifizierbaren Aufgaben meist erst am Ende. Rollout plus Reward ergeben ein Sample — die Einheit, die der Trainer konsumiert.

RL lernt aus bewerteten Handlungen, nicht aus Musterlösungen.

Das unterscheidet RL von zwei anderen verbreiteten Trainingsarten:

In der Praxis werden diese Kategorien kombiniert. Moderne LLMs durchlaufen meist zwei große Phasen: Pre-Training baut ein Basismodell durch Vorhersage auf großen Datenmengen; Post-Training formt daraus ein nutzbares Verhalten durch Supervised Fine-Tuning (SFT) auf Beispielantworten, Preference Optimization, RLHF, RLVR oder weitere Spezialverfahren. Die Unterscheidung bleibt wichtig, weil RL ein anderes Problem adressiert als Imitation: Imitation lernt, wie eine gute Antwort aussieht; RL lernt, welche Sequenz von Entscheidungen unter einem Feedbacksignal trägt.

3. Der Mechanismus am Beispiel von Coding-Agenten

Ein Coding-Agent erhält beispielsweise die Aufgabe:

„Behebe den Fehler in diesem Repository. Die Tests sollen anschließend bestehen.“

Ein klassisches LLM könnte eine Antwort formulieren: „Ändere Funktion X in Datei Y.“ Ein agentisches System muss mehr leisten. Es inspiziert das Repository, öffnet Dateien, führt Tests aus, liest Fehlermeldungen, ändert Code, testet erneut und erklärt den Patch. Erfolg entsteht aus einer kontrollierten Folge von Beobachtungen und Eingriffen.

Das übersetzt sich in folgende RL-Komponenten:

Das Beispiel zeigt, was RL bei LLMs optimiert: ein interaktives Verhalten. Wie Code aussieht, weiß das Modell aus dem Pre-Training. Lernen muss es, wann Suche besser ist als Änderung, wann ein Testsignal ausreicht, wann ein Fehler wahrscheinlich im Harness liegt und wann ein Patch abgeschlossen werden kann.

Der Reward ist dabei nur auf den ersten Blick eindeutig. „Tests bestanden“ ist ein starkes Signal, aber kein vollständiges Qualitätsmaß. Ein Agent kann fragile Änderungen vornehmen, Tests umgehen, unbeabsichtigte Seiteneffekte erzeugen oder die Aufgabe formal lösen, ohne den zugrunde liegenden Fehler sauber zu beheben. Gutes RL für Coding-Agenten braucht deshalb nicht nur Tests, sondern Sandboxes, Patch-Diffs, Regression Checks, Code-Review-Signale und eine klare Trennung zwischen Trainingsaufgabe und Evaluation. Erste Arbeiten wie SWE-RL trainieren genau auf solchen Daten aus realer Software-Evolution.¹

4. Warum RL schwierig ist

RL klingt linear: Belohnung definieren, Agent handeln lassen, Verhalten verbessern. In der Praxis ist es eine der anspruchsvollsten Formen des maschinellen Lernens, weil das System genau dort optimiert, wo Messung, Handlung und Nebenwirkung zusammenfallen.

4.1 Der Reward ist nie neutral

Der Agent optimiert das, was gemessen wird. Nicht das, was gemeint war.

Wenn ein Coding-Agent nur danach bewertet wird, ob Tests bestehen, kann er Tests aushebeln, statt den Fehler robust zu beheben. Wenn ein Dialogmodell nur auf unmittelbare Nutzerzufriedenheit optimiert, kann es übertrieben zustimmend, manipulativ oder oberflächlich werden. Wenn ein Roboter nur Geschwindigkeit belohnt bekommt, kann er Sicherheit ignorieren.

Dieses Problem heißt Reward Hacking: Der Agent maximiert die formale Bewertungsregel und verfehlt die eigentliche Absicht. Je mächtiger der Agent und je enger die Metrik, desto größer wird diese Lücke.

4.2 Gute Entscheidungen zahlen sich oft erst später aus

Viele Aufgaben haben verzögerte Rückmeldung. Bei einem mathematischen Beweis kann ein früher Zwischenschritt falsch sein, aber der Fehler zeigt sich erst am Ende. Bei einem Software-Agenten kann eine Architekturentscheidung erst nach mehreren Testläufen problematisch werden.

Das nennt man Credit Assignment: Welcher frühere Schritt war für Erfolg oder Misserfolg verantwortlich?

Bei LLM-Agenten wird das besonders schwer, weil eine Trajectory aus vielen Tokens, Tool-Aufrufen, Beobachtungen und Zwischenentscheidungen besteht. Ein positiver Endreward sagt wenig darüber, ob die entscheidende Leistung im ersten Suchschritt, im fünften Testlauf oder in einer späten Korrektur lag.

4.3 Exploration ist teuer

RL braucht Ausprobieren. Aber Ausprobieren kostet.

In einem Computerspiel kann ein Agent Millionen Episoden simulieren. In realer Robotik, Medizin, Finanzsystemen oder produktiven Software-Repositories ist ungezügelte Exploration nicht akzeptabel. Auch LLM-RL ist teuer, weil viele Rollouts erzeugt, bewertet, gefiltert und gespeichert werden müssen. Lange Reasoning-Sequenzen verschärfen das Problem: Ein einzelner Rollout kann tausende Tokens, mehrere Tool-Aufrufe und teure Verifier enthalten.

4.4 Evaluation ist Teil des Systems

Bei klassischem Benchmarking testet man ein Modell auf einem Datensatz. Bei RL ist die Grenze zwischen Training, Evaluation und Environment oft fließend. Die Umgebung definiert, was der Agent ausprobieren kann. Der Harness definiert, wie Aktionen ausgeführt und gemessen werden. Der Reward definiert, was als Erfolg gilt.

Damit wird Evaluation selbst zu einer Angriffsfläche. Wenn Trainingsaufgaben, Verifier und Benchmarks zu ähnlich sind, lernt das Modell nicht zwingend robuste Kompetenz, sondern die Form des Tests. Wenn Logs unvollständig sind, lassen sich Fehlverhalten und Reward Hacking später kaum rekonstruieren.

Deshalb ist RL ein Systemdesignproblem mit Mess-, Sicherheits- und Reproduzierbarkeitsfragen; der Algorithmus ist nur ein Teil davon.

5. Die Systemschichten: Environment, Harness, Benchmark und Trainer

Viele Fehlurteile über LLM-RL entstehen, weil Environment, Harness, Benchmark, Reward Model und Trainer als austauschbare Begriffe verwendet werden. Für moderne Systeme ist die Trennung operativ wichtig: Sie bestimmt, wo Verhalten entsteht, wo es gemessen wird und wo Modellparameter tatsächlich verändert werden.

Ein Harness ist die technische Brücke zwischen Aufgabe, Agent, Ausführung, Bewertung und Datenaufzeichnung — zu unterscheiden vom RL-Algorithmus und vom Benchmark. In einfachen Benchmarks bleibt diese Schicht fast unsichtbar. In agentischem RL entscheidet sie, ob Tool-Aufrufe sicher, reproduzierbar und belohnbar werden.

flowchart TD
    P[Aufgabe / Prompt] --> M[Agent oder Modell]
    M --> A[Aktion: Text, Code, Tool Call, Plan]
    A --> H[Harness]
    H --> X[Ausführung: Tests, Tools, Browser, Sandbox]
    X --> R[Reward / Bewertung]
    X --> O[Observation / Logs]
    R --> T[Trainer]
    O --> M
    T --> M2[aktualisierte Policy]

Für LLM-Agenten ist diese Unterscheidung besonders wichtig. Ein Agent-Harness kann:

• Prompts und Aufgaben initialisieren,
• Tools verfügbar machen,
• Code in einer Sandbox ausführen,
• Browser- oder API-Aktionen kontrollieren,
• Zwischenschritte und Logs speichern,
• Rewards berechnen,
• fehlerhafte Rollouts filtern,
• Daten an den Trainer liefern,
• Evaluationen reproduzierbar machen.

Der RL-Algorithmus optimiert Verhalten. Der Harness definiert, welches Verhalten sichtbar, ausführbar, messbar und trainierbar wird.

Harness und Environment hängen eng zusammen, sind aber nicht identisch. Das Environment ist die Aufgabenwelt: Repository, Browser, Simulator, API oder Spiel. Der Harness ist die Implementierungsschicht, die diese Aufgabenwelt für Training oder Evaluation operationalisiert. Er setzt Timeouts, Rechte, Reset-Logik, Logging, Reward-Berechnung und Datenformate.

Bei agentischem RL ist der Harness oft der eigentliche Control Point. Wer den Harness kontrolliert, kontrolliert, welche Fähigkeiten messbar werden und welche Abkürzungen der Agent lernen kann.

6. RL ist mehr als RLHF

RL wurde im LLM-Kontext lange durch Reinforcement Learning from Human Feedback (RLHF) geprägt. RLHF spielte eine zentrale Rolle im Post-Training von Instruktionsmodellen: InstructGPT nutzte Demonstrationen, menschliche Präferenzvergleiche und RLHF, um Sprachmodelle stärker an Nutzerintentionen auszurichten.² Mit RLAIF und Constitutional AI lässt sich ein Teil dieses Feedbacks von Menschen auf andere Modelle verlagern.³

Für 2026 ist diese Gleichsetzung zu eng. RLHF ist ein wichtiger Spezialfall, aber nicht der Kern der aktuellen Dynamik. Reasoning, Code und Tool-Use verschieben den Schwerpunkt zu Feedbacksignalen, die nicht aus menschlicher Präferenz, sondern aus überprüfbaren Ergebnissen kommen.

Wichtig ist: DPO, ORPO und KTO sind keine klassischen Online-RL-Verfahren. Sie sind präferenzbasierte Optimierungsmethoden, die oft als Alternative oder Ergänzung zu RLHF eingesetzt werden. Sie sind stabiler und billiger, weil sie typischerweise auf vorhandenen Präferenzdaten arbeiten und keinen teuren Interaktionsloop benötigen.⁴⁵⁶

Für verifizierbare Reasoning-Aufgaben wurde seit 2024/25 ein anderer Zweig besonders wichtig: RL mit automatisch prüfbaren Rewards.

7. RLVR: Warum überprüfbare Rewards der Durchbruch waren

Reinforcement Learning with Verifiable Rewards (RLVR) bedeutet: Das Modell bekommt seine Belohnung aus einem Ergebnis, das automatisch überprüft werden kann.

Der Unterschied ist klein in der Definition und groß in der Skalierung. Menschliche Präferenzen sind teuer, langsam und verrauscht. Ein Verifier kann Millionen Kandidaten konsistent bewerten, solange die Aufgabe sauber formalisiert ist.

Bei klassischen Dialogantworten ist es schwer zu sagen, ob eine Antwort „wirklich gut“ ist. Man kann Menschen fragen, ein Reward Model trainieren oder ein anderes LLM als Judge einsetzen. Alle drei Optionen sind fehleranfällig. Bei Mathematik und Code ist die Lage besser: Entweder stimmt das Ergebnis oder nicht. Entweder bestehen Tests oder nicht.

DeepSeek-R1-Zero machte diese Idee sichtbar: Das Modell wurde per RL auf Reasoning-Aufgaben trainiert, ohne eine Supervised-Fine-Tuning-Phase als Kaltstart, und zeigte emergente Reasoning-Verhaltensweisen. Der DeepSeek-R1-Bericht beschreibt zugleich die Grenze dieses Ansatzes: R1-Zero entwickelte Reasoning-Fähigkeiten, aber auch schlechte Lesbarkeit und Sprachmischung; R1 ergänzte deshalb Kaltstartdaten und ein mehrstufiges Training.⁷

RLVR hat eine harte Grenze: Es funktioniert dort am besten, wo es einen guten Verifier gibt. Für viele offene, subjektive oder wertgeladene Aufgaben gibt es keinen einfachen automatischen Prüfer. Genau deshalb bleiben Reward Modeling, menschliche Rückmeldung und AI Feedback relevant. RLVR ersetzt RLHF nicht pauschal; es verschiebt die ökonomisch attraktive Zone von RL in Domänen, in denen Korrektheit billig prüfbar ist.

8. Lernt RL neue Fähigkeiten — oder ruft es nur vorhandene besser ab?

Die operative Kernfrage 2026 lautet: Generiert RL neue Fähigkeiten oder macht es latente Fähigkeiten nur verlässlicher abrufbar?

Diese Unterscheidung ist praktisch. Sie bestimmt, ob RL als Fähigkeitsmotor, als Elicitation-Verfahren oder als teure Nachoptimierung verstanden wird.

Die erste Position sagt: Ein starkes Basismodell enthält bereits viele mögliche Lösungsstrategien. RL verschiebt ihre Wahrscheinlichkeiten. Gute Strategien werden häufiger, schlechte seltener. Das Modell wirkt dadurch klüger, aber die Fähigkeit war latent bereits vorhanden.

Die zweite Position sagt: Langes, gut reguliertes RL kann neue Strategien stabilisieren. Das Modell findet Verhaltensmuster, die durch bloßes Sampling zwar theoretisch möglich, aber praktisch extrem unwahrscheinlich waren. Aus einer seltenen Möglichkeit wird ein reproduzierbares Verhalten.

Beide Sichtweisen können gleichzeitig teilweise stimmen:

Der praktische Punkt ist: RL optimiert Verhalten unter einem bestimmten Feedbacksignal; ein automatischer Fähigkeitsgenerator ist es nicht. Ob daraus echte Generalisierung entsteht, hängt von Modell, Daten, Aufgabenvielfalt, Reward-Qualität und Evaluation ab. Für Investoren und Betreiber zählt deshalb eine einzige Frage: Löst das System neue Aufgaben außerhalb des Trainingsharness stabil? Das Etikett „mehr RL“ sagt darüber wenig.

9. Von PPO zu GRPO, GSPO und CISPO: die Algorithmus-Evolution bei LLM-RL

Die modernen LLM-RL-Verfahren unterscheiden sich weniger in der Grundidee als in ihren Stabilitätsannahmen. Sie beantworten drei praktische Fragen: Braucht man einen Critic? Wird auf Token- oder Sequenzebene korrigiert? Und wie verhindert man, dass ein Update die Policy zu weit von den Daten entfernt, auf denen es beruht?

9.1 PPO: stabiler Klassiker mit Critic

Proximal Policy Optimization (PPO) ist ein Policy-Gradient-Verfahren. Es trainiert eine Policy, begrenzt aber pro Update, wie stark sich die neue Policy von der alten entfernen darf. Diese Begrenzung ist wichtig, weil RL-Updates sonst instabil werden können.⁸

Das praktische Korrektursignal heißt Advantage: Es misst, ob eine Aktion besser oder schlechter war als die erwartete Basislinie. Ein hoher Advantage verstärkt eine Aktion, ein negativer schwächt sie.

In RLHF wurde PPO lange verwendet, weil es relativ robust ist. Der Nachteil: PPO nutzt typischerweise zusätzlich ein Value Model oder einen Critic. Dieser Critic schätzt, wie gut ein Zustand oder eine Antwort voraussichtlich sein wird. Bei LLMs kann der Critic fast so groß und teuer sein wie das eigentliche Modell. Das macht PPO nicht falsch, aber infrastrukturell schwerer: Man trainiert und synchronisiert nicht nur eine Policy, sondern zusätzliche Bewertungsmodelle.

9.2 GRPO: gruppenrelative Bewertung ohne Critic

Group Relative Policy Optimization (GRPO) wurde in DeepSeekMath eingeführt⁹ und durch DeepSeek-R1 besonders bekannt; spätere Arbeiten haben seine Verlustdynamik und Normalisierung genauer analysiert.¹⁰ Die Idee: Für denselben Prompt werden mehrere Antworten erzeugt. Jede Antwort bekommt einen Reward, und ihr Advantage ist der Reward relativ zum Gruppenmittel — wie viel besser oder schlechter sie als eine typische Antwort der Gruppe abschneidet. Antworten über dem Gruppenmittel werden verstärkt, Antworten darunter geschwächt.

Dadurch kann man auf einen separaten Critic verzichten.

Anschaulich:

Prompt: Löse Aufgabe X.

Antwort A: falsch  → Reward 0
Antwort B: richtig → Reward 1
Antwort C: falsch  → Reward 0
Antwort D: richtig → Reward 1

Die guten Antworten bekommen innerhalb der Gruppe positives Signal,
die schlechten negatives oder schwächeres Signal.

GRPO ist attraktiv, weil es einfacher und günstiger als PPO mit großem Critic sein kann. Der Preis ist ein empfindlicheres Gruppensignal. Wenn alle Antworten denselben Reward bekommen — alle falsch oder alle richtig —, ist jeder Advantage exakt null und die Gruppe liefert kein Lernsignal. Das passiert genau bei einer Solve-Rate nahe 0 % (zu schwer) oder nahe 100 % (zu leicht). Wenn Normalisierung oder Längenbehandlung schief laufen, optimiert das Modell Format-Artefakte statt Problemlösung. Typische Risiken sind Längen-Bias, instabile Normalisierung, Entropy Collapse und Schwierigkeiten bei sehr großen Mixture-of-Experts-Modellen (MoE).

Entropy Collapse bedeutet: Die Policy wird zu früh zu sicher. Sie exploriert weniger, erzeugt weniger unterschiedliche Lösungswege und kann in suboptimalem Verhalten feststecken.

9.3 DAPO und Dr. GRPO: Reparaturen an GRPO

Decoupled Clip and Dynamic Sampling Policy Optimization (DAPO) adressiert praktische Schwächen von GRPO. Sein dynamisches Sampling greift genau das Nulladvantage-Problem an: Gruppen, in denen alle Antworten gleich abschneiden, liefern kein Signal und werden verworfen; DAPO sampelt nach, bis genug Gruppen mit nutzbarer Reward-Streuung im Batch sind. Zusammen mit weiteren Anpassungen macht das großskaliges LLM-RL reproduzierbarer und stabiler.¹¹

Dr. GRPO und verwandte Arbeiten versuchen, Normalisierungs- und Längenprobleme von GRPO zu korrigieren. Die Details sind mathematisch, die Grundintuition ist operativ: Wenn das Trainingssignal unbeabsichtigt kürzere, längere oder formal bequemere Antworten bevorzugt, optimiert das Modell nicht mehr sauber die eigentliche Aufgabe.

9.4 GSPO: Sequenz statt Token

Group Sequence Policy Optimization (GSPO) verschiebt einen wichtigen Teil der Optimierung von der Token-Ebene auf die Sequenz-Ebene. Statt jedes Token einer Antwort sehr fein mit einem Importance-Ratio zu korrigieren, betrachtet GSPO die gesamte Antwortsequenz. Die Autoren argumentieren, dass GSPO stabiler und effizienter für LLM-Training ist und insbesondere Mixture-of-Experts-RL stabilisieren kann.¹²

Die Designfrage ist, welche Einheit das Lernsignal tragen soll:

Bei Reasoning-Antworten ist nicht jedes Token isoliert sinnvoll bewertbar. Oft zählt die gesamte Lösung. GSPO macht diese Perspektive algorithmisch expliziter: Die Antwort wird stärker als Trajectory behandelt, nicht nur als Summe lokaler Tokenentscheidungen.

9.5 CISPO: Importance Sampling anders clippen

CISPO (Clipped IS-weight Policy Optimization) wurde im Kontext von MiniMax-M1 vorgestellt. Die Grundidee: Statt Token-Updates komplett zu verwerfen, werden Importance-Sampling-Gewichte begrenzt. Das soll Trainingseffizienz und Stabilität verbessern, insbesondere bei langen Reasoning-Sequenzen.¹³

Importance Sampling nutzt Wahrscheinlichkeitsverhältnisse zwischen alter und neuer Policy. Dadurch lassen sich Rollouts aus einer nicht mehr exakt aktuellen Policy begrenzt weiterverwenden, ohne das Trainingssignal unkontrolliert werden zu lassen.

Die Intuition:

Wenn die neue Policy und die alte Policy zu stark auseinanderlaufen, wird das Trainingssignal riskant. Clipping begrenzt diesen Effekt. Die offene Frage ist, wo man clippt: an Tokens, an Sequenzen oder an Importance-Gewichten.

9.6 Was ist 2026 der „Standard“?

Es gibt keinen universellen Standard. PPO bleibt grundlegend und gut verstanden. GRPO wurde zum wichtigen Open-Source-Referenzpunkt für LLM-RL. DAPO, GSPO, CISPO, REINFORCE++¹⁴ und verwandte Varianten adressieren konkrete Skalierungs- und Stabilitätsprobleme. Welche Methode am besten ist, hängt von Modellarchitektur, Aufgaben, Reward, Systeminfrastruktur und Toleranz gegenüber Off-Policy-Daten ab.

Die präzisere 2026-Zusammenfassung lautet:

Critic-freie oder critic-arme Policy-Gradient-Varianten prägen viele offene LLM-RL-Setups, während die Forschung an stabileren Sequenz- und Importance-Sampling-Varianten arbeitet.

10. Reward-Modeling: Wer oder was gibt die Belohnung?

Der Reward ist das Herzstück von RL. Bei LLMs ist er zugleich die größte Produkt- und Sicherheitsentscheidung: Er legt fest, welches Verhalten verstärkt wird, welche Abkürzungen attraktiv werden und wo menschliche Kontrolle nötig bleibt.

Outcome Reward Models (ORMs) bewerten am Ende: Ist die Antwort richtig? War die Lösung hilfreich? Sie sind effizient, verlieren aber Information über den Weg.

Process Reward Models (PRMs) bewerten den Weg. Das ist bei langen Denkprozessen wichtig. Ein Modell kann am Ende zufällig die richtige Zahl nennen, aber auf dem Weg falsch argumentieren. Prozesssupervision versucht, jeden Schritt zu bewerten. Die Arbeit „Let’s Verify Step by Step“ zeigte, dass Prozesssupervision bei mathematischen Aufgaben Outcome-Supervision übertreffen kann und veröffentlichte PRM800K mit Schrittlabels.¹⁵

Verifier sind oft besser als Reward Models, wenn sie verfügbar sind. Ein Unit-Test ist weniger manipulierbar als ein vager LLM-Judge. Aber Verifier decken nur einen Teil realer Aufgaben ab. Sie prüfen, was formalisiert wurde, nicht zwingend, was Nutzer oder Betreiber wirklich wollen.

LLM-as-Judge ist attraktiv, weil es flexibel und billig skalierbar ist. Aber ein Judge-Modell kann dieselben Schwächen haben wie das zu bewertende Modell: Halluzinationen, Stil-Bias, Überbewertung langer Antworten, Empfindlichkeit gegenüber Prompting. In produktiven Setups braucht ein Judge deshalb Rubrics, Kalibrierung, Stichproben durch Menschen und Guardrails gegen Judge-Gaming.

Je objektiver und automatischer der Reward, desto besser skaliert RL. Je subjektiver die Aufgabe, desto wichtiger werden Rubrics, menschliche Audits und robuste Evaluation.

11. Test-Time Compute: Warum Reasoning-Modelle länger rechnen

Ein klassisches Chatmodell erzeugt oft direkt eine Antwort. Ein Reasoning-Modell nutzt mehr Rechenzeit während der Antwortgenerierung. Diese zusätzliche Rechenzeit nennt man Test-Time Compute oder Inference-Time Compute. Sie ist zusätzliche Suche, Verifikation und Auswahl unter mehreren Kandidaten — keine Denkzeit im menschlichen Sinn.

Das kann mehrere Formen haben:

• mehrere Lösungskandidaten erzeugen,
• längere Zwischenschritte generieren,
• Tools aufrufen,
• Antworten verifizieren,
• schlechte Pfade verwerfen,
• mit einem Judge oder Verifier auswählen,
• parallel mehrere Denkpfade verfolgen.

RL und Test-Time Compute hängen eng zusammen. RL kann ein Modell darauf trainieren, zusätzliche Rechenzeit sinnvoll zu verwenden. Das Modell lernt beides: was es antwortet und wann es länger suchen, prüfen oder ein Tool verwenden sollte.

Das ist ein großer Unterschied:

Mehr Test-Time Compute ist kein Garant für Wahrheit. Ein Modell kann länger argumentieren und trotzdem falsch liegen. Der Gewinn entsteht erst, wenn zusätzliche Rechenzeit mit guten Verifiern, guten Suchstrategien und robustem Training gekoppelt wird. Ohne diese Kopplung skaliert man vor allem Kosten und Selbstbestätigung.

12. Der moderne RL-Systemstack

Viele Erklärungen behandeln RL als Algorithmus. In der Praxis sind moderne LLM-RL-Systeme verteilte Hochdurchsatzsysteme. Der Engpass liegt in der Frage, wie schnell ein System Aufgaben erzeugt, Rollouts ausführt, Rewards berechnet, Daten filtert, Gewichte synchronisiert und Evaluationen reproduziert — seltener im Optimizer selbst.

Ein vereinfachter Stack sieht so aus:

flowchart TD
    D[Aufgaben / Prompts / Environments] --> G[Generator: erzeugt Rollouts]
    G --> S[Sandbox / Tool-Ausführung]
    S --> V[Verifier / Reward Model / Judge]
    V --> B[Rollout Buffer / Datenfilter]
    B --> T[Trainer: Policy Update]
    T --> W[Weight Sync / Broadcast]
    W --> G
    T --> E[Evaluation Harness]

Die wichtigsten Komponenten:

12.1 Generator

Der Generator erzeugt Rollouts. Bei LLMs ist das meist eine Inferenz-Engine wie vLLM oder SGLang. Sie muss viele Antworten parallel erzeugen, lange Sequenzen verwalten und Key-Value-Caches effizient nutzen.

Für RL ist der Generator mehr als ein Serving-System: Er bestimmt, welche Kandidaten überhaupt in den Trainingsdatensatz gelangen. Sampling-Temperatur, maximale Länge, Tool-Call-Protokolle, Parallelisierung und Abbruchregeln formen den Suchraum. Ein schlechter Generator produziert entweder zu wenig Varianz oder zu viel unbrauchbares Rauschen.

12.2 Sandbox oder Environment Runtime

Die Sandbox führt Aktionen aus: Code, Tests, Shell-Kommandos, Browseraktionen, Datenbankabfragen oder APIs. In agentischem RL ist diese Schicht oft der Engpass, weil externe Tools langsam, zustandsbehaftet und fehleranfällig sind.

Technisch reicht die Implementierung von leichtgewichtigen Firecracker-Micro-VMs bis zu vollwertigen QEMU-VMs, je nach Komplexität des Environments. Die Startup-Latenz der Sandbox ist dabei einer der größten Einzelposten der Rollout-Latenz; spezialisierte Anbieter senken sie über content-addressed Caching. Hinzu kommt die Skalierung: Die Zahl lebender Sandboxes schwankt stark mit den nebenläufigen Rollouts, die laufend gestartet, abgebrochen oder abgeschlossen werden.

Sie ist außerdem die Sicherheitsgrenze. Eine gute Runtime setzt Berechtigungen, isoliert Dateisysteme, begrenzt Netzwerkzugriffe, erzwingt Timeouts und kann Environments deterministisch zurücksetzen. Ohne diese Kontrolle wird RL mit Tools schwer reproduzierbar und operativ riskant. Schließlich muss die Runtime robust gegen Selbst-Erschöpfung sein: Unerwartetes Agentenverhalten — etwa eine Million erzeugter Dateien — kann die zugewiesenen Ressourcen einer Sandbox aufbrauchen, und die Orchestrierung muss solche Ausfälle erkennen und recovern.

12.3 Reward-Schicht

Diese Schicht berechnet Rewards: Unit Tests, Verifier, Reward Models, LLM-Judges oder Rubrics. Sie muss schnell genug sein, um den Generator nicht auszubremsen, und streng genug, um Abkürzungen nicht systematisch zu belohnen.

In großen Setups ist Rewarding oft ein eigenes Pipeline-Problem. Einige Rewards sind billig und deterministisch, andere teuer und probabilistisch. Das System muss beide Arten mischen können, ohne dass langsame Judges den gesamten Trainingsloop blockieren oder verrauschte Rewards die Policy dominieren.

12.4 Rollout Buffer

Der Buffer speichert Trajectories. Er kann Rollouts filtern, gruppieren, priorisieren oder verwerfen. Bei GRPO-artigen Verfahren ist wichtig, wie Gruppen gebildet werden und ob zu leichte oder zu schwere Aufgaben überhaupt ein Lernsignal liefern.

Der Buffer entscheidet damit, welche Erfahrungen Gewicht bekommen. Zu alte Rollouts erhöhen Staleness. Zu aggressive Filterung erzeugt Selection Bias. Zu wenig Aufgabenvielfalt macht das Training benchmark-nah und fragil.

12.5 Trainer

Der Trainer aktualisiert die Modellgewichte. Er verwendet Verfahren wie PPO, GRPO, DAPO, GSPO, CISPO, DPO oder andere Varianten. Seine Aufgabe geht über das Minimieren von Losses hinaus: Er muss ein stabiles Verhältnis zwischen Reward-Signal, KL-Kontrolle, Entropie, Batch-Struktur und Hardwareeffizienz halten.

Bei LLM-RL kann ein technisch sauberer Trainer trotzdem schlechte Policies erzeugen, wenn die Rollouts veraltet, die Rewards verzerrt oder die Evaluationen zu eng sind. Der Trainer ist ein notwendiger, aber nicht hinreichender Teil des Systems.

12.6 Weight Sync

Nach einem Update müssen neue Gewichte zurück zum Generator. Bei großen Modellen und vielen GPUs ist das ein zentraler Systemfaktor.

Weight Sync bestimmt, wie frisch die Daten sind, mit denen weitertrainiert wird. Je langsamer die Synchronisierung, desto größer die Lücke zwischen Policy, die Rollouts erzeugt, und Policy, die optimiert wird. Für on-policy RL gehört diese Lücke zu den mathematischen Annahmen des Verfahrens.

13. Der eigentliche „Gap“: Trainer, Generator und numerischer Mismatch

Der SemiAnalysis-Artikel „RL Systems: Mind the Gap — Matching Trainer and Generator Throughput“¹⁶ rückt einen wichtigen Punkt in den Vordergrund: Die Effizienz moderner RL-Systeme hängt stark davon ab, ob Generator und Trainer im Durchsatz zusammenpassen. Wenn der Generator zu langsam ist, wartet der Trainer. Wenn der Trainer zu langsam ist, stauen sich Rollouts. Das System wird zur Queue.

Diese Perspektive sollte man erweitern. Für LLM-RL zählen mindestens zwei verschiedene Gaps: zeitliche Staleness zwischen Datenerzeugung und Update sowie numerischer Mismatch zwischen Inferenz- und Trainingspfad.

13.1 Gap 1: Policy Staleness

Policy Staleness bedeutet: Rollouts wurden mit einer älteren Version der Policy erzeugt, während der Trainer schon eine neuere Version optimiert.

Das passiert besonders bei asynchronen Systemen. Asynchronität ist attraktiv, weil Generator und Trainer parallel arbeiten können. Aber je länger Rollouts in einer Queue liegen, desto weniger passen sie zur aktuellen Policy.

Bei In-flight-Weight-Updates wird es noch subtiler. Wenn der Trainer die Gewichte des Generators mitten in einer laufenden Generierung aktualisiert, stammt schon ein einzelner Rollout aus mehreren Policy-Versionen: Die frühen Tokens kommen von Policy k, die späten von k+1 oder k+2. Staleness ist dann keine reine Queue-Eigenschaft mehr, sondern steckt innerhalb derselben Antwort.

Das ist problematisch, weil viele Policy-Gradient-Verfahren eigentlich on-policy sind. On-policy bedeutet: Die Daten sollen von der Policy stammen, die gerade optimiert wird.

Wenn Daten zu alt sind, wird aus on-policy faktisch off-policy. Dann braucht man Korrekturen wie Importance Sampling, Staleness-Budgets oder das Verwerfen zu alter Daten. Der Durchsatzgewinn asynchroner Systeme hat also einen Preis: Er muss gegen die Frische des Lernsignals gerechnet werden.

13.2 Gap 2: Training-Inference-Mismatch

Noch subtiler ist der Training-Inference-Mismatch. Selbst wenn Generator und Trainer dieselben Modellgewichte verwenden, können sie wegen unterschiedlicher Engines, Kernel, Präzisionsformate und Batch-Konfigurationen leicht unterschiedliche Wahrscheinlichkeiten berechnen.

Beispiel:

• Der Generator nutzt eine optimierte Inferenz-Engine mit anderen Attention-Kernels.
• Der Trainer nutzt eine Trainings-Engine mit anderen numerischen Pfaden.
• Beide haben dieselben Gewichte, aber berechnen nicht exakt dieselben Log-Wahrscheinlichkeiten.

Für normales Deployment ist eine kleine numerische Abweichung oft egal. Für RL kann sie relevant werden, weil Policy-Gradient-Verfahren empfindlich darauf reagieren, welche Wahrscheinlichkeit eine Aktion unter alter und neuer Policy hatte. Besonders bei langen Sequenzen können kleine Logprob-Abweichungen über viele Tokens kumulieren.

Systemische Lektion: Bei LLM-RL ist „on-policy“ auch eine Systemeigenschaft: Sie hängt davon ab, ob Inferenz- und Trainingssystem numerisch konsistent sind.

13.3 Warum das systemisch zählt

Der Fortschritt hängt neben besseren Loss-Funktionen an:

• Inferenzdurchsatz,
• Weight-Broadcast-Latenz,
• GPU-Auslastung,
• Sandbox-Latenz,
• Queue-Design,
• Präzisionsformaten wie BF16, FP16 oder FP8,
• konsistenter Logprob-Berechnung,
• Rollout-Filterung,
• Reproduzierbarkeit von Evaluationen.

Das ist der Moment, an dem RL von „Machine-Learning-Algorithmus“ zu „verteiltem Produktionssystem“ wird. Wer nur den Algorithmus betrachtet, unterschätzt Kosten, Reproduzierbarkeit und Skalierungsrisiko.

14. Synchron, asynchron und PipelineRL

Ein synchrones RL-System hält die Phasen sauber getrennt:

Rollouts erzeugen → Rewards berechnen → Training → neue Gewichte → nächste Rollouts

Das ist konzeptionell sauber und leichter zu analysieren, aber teuer. Viele Ressourcen warten aufeinander.

Ein asynchrones System überlappt die Phasen:

Während der Trainer trainiert, erzeugt der Generator schon neue Rollouts.
Während Rollouts bewertet werden, bereitet der Trainer das nächste Update vor.

Das erhöht den Durchsatz, erzeugt aber Staleness. Der Trainingsloop wird schneller, aber die Daten passen potenziell schlechter zur aktuellen Policy.

PipelineRL ist ein Beispiel für die Richtung moderner Systeme: Es erzeugt Daten und trainiert nebenläufig und aktualisiert die Gewichte während laufender Generierung, damit sich Generation und Training stärker überlappen. Die Autoren berichten auf Long-Sequence-Reasoning-Aufgaben mit 128 H100 GPUs ungefähr zweifach schnelleres Lernen gegenüber konventionellen Baselines bei weiterhin sehr frischen Trainingsdaten.¹⁷

Die eigentliche Designfrage hinter „synchron oder asynchron“ lautet:

Wie viel Staleness akzeptieren wir, um wie viel Hardwareauslastung zu gewinnen?

Diese Frage ist bei LLM-RL zentral, weil Rollouts teuer sind. Viele moderne Systeme sind generation-bound: Die Erzeugung und Ausführung von Rollouts dominiert die Wall-Clock-Zeit. Pipeline-Design ist deshalb Teil der Lernmethode.

15. Agentisches RL: wenn die Umgebung selbst komplex wird

Bei klassischen RL-Benchmarks ist die Umgebung oft klar definiert. Bei LLM-Agenten ist sie heterogen:

• ein Terminal,
• ein Browser,
• ein Git-Repository,
• eine SQL-Datenbank,
• ein Dokumentenspeicher,
• APIs,
• Suchmaschinen,
• Bild- oder Video-Tools,
• mehrere andere Agenten.

Das nennt man häufig agentisches RL oder Agentic Reinforcement Learning. Der Agent handelt über viele Schritte hinweg. Er muss beobachten, planen, Tools wählen, Fehler korrigieren und entscheiden, wann die Aufgabe abgeschlossen ist.

Der Unterschied zu klassischem LLM-Training ist fundamental. Das Modell optimiert eine Interaktionspolitik mit externem Zustand. Jede Tool-Aktion kann neue Informationen schaffen, Kosten verursachen oder das Environment verändern. Dadurch wird die Grenze zwischen Modellfähigkeit und Systemdesign unscharf.

Daraus entstehen neue Probleme:

15.1 Multi-Turn Credit Assignment

Wenn ein Agent nach 40 Tool-Aufrufen scheitert, welcher Schritt war schuld? Die erste falsche Suchanfrage? Eine übersehene Fehlermeldung? Ein falscher Patch? Ein zu früher Abschluss?

Multi-Turn Credit Assignment ist härter als Rewarding einer einzelnen Antwort, weil der Fehler oft nicht im letzten Schritt entsteht. Gute Systeme brauchen deshalb Zwischenbeobachtungen, strukturierte Logs und manchmal Prozesssignale, die nicht nur den Endzustand bewerten.

15.2 Sparse Rewards

Viele agentische Aufgaben haben erst am Ende einen Reward. Entweder die Aufgabe ist gelöst oder nicht. Das macht Training schwer.

Sparse Rewards können zu hohem Datenverbrauch führen, weil die meisten Rollouts kein verwertbares Signal liefern. Curricula, Teilziele, heuristische Zwischenrewards und bessere Initialisierung helfen, erzeugen aber neue Risiken: Der Agent kann lernen, Teilziele zu optimieren, die nicht mehr sauber mit dem eigentlichen Erfolg korrespondieren.

15.3 Stateful Environments

Ein Repository, Browser oder Terminal hat Zustand. Wenn ein Rollout unterbrochen und später fortgesetzt wird, kann die Umgebung in einem Zwischenzustand sein. Partial Rollouts können dadurch Environment-State-Staleness erzeugen.

Statefulness macht Reset-Logik und Reproduzierbarkeit zentral. Ein Agent, der in einem halb veränderten Repository trainiert, sieht eine andere Aufgabe als der nächste Agent. Ohne saubere Snapshots, deterministische Seeds und isolierte Sandboxes vermischen sich Lernsignal und Environment-Artefakt.

15.4 Sicherheitsgrenzen

Agenten mit Tools können reale Seiteneffekte haben. Deshalb brauchen sie Sandboxes, Berechtigungsmodelle, Audit-Logs und klare Grenzen.

Die Sicherheitsfrage reicht über „gefährliche“ Aktionen des Agenten hinaus. Sie umfasst auch, ob das Trainingssystem gefährliche Strategien belohnt: Daten exfiltrieren, Tests manipulieren, Rate Limits umgehen, externe Dienste überlasten oder menschliche Freigaben simulieren. Agentisches RL braucht deshalb technische Grenzen und Reward-Grenzen.

Hier wird der Harness wieder zentral: Für agentisches RL ist er die Schicht, die Agenten überhaupt trainierbar macht.

16. RL-Infrastruktur und Frameworks

Die Wahl des RL-Frameworks entscheidet sich an der Systemanforderung: Geht es um Prototyping oder produktionsnahe Skalierung im Cluster?

OpenRLHF beschreibt sich als skalierbares, nutzerfreundliches RLHF-Framework mit Unterstützung für RLHF, DPO, Rejection Sampling und andere Alignment-Techniken und nutzt unter anderem Ray, vLLM und DeepSpeed.¹⁸ Im verl-Umfeld zielt VerlTool darauf, agentisches RL mit Tool-Use ganzheitlich abzudecken.¹⁹ RLlib ist eher eine allgemeine verteilte RL-Bibliothek, deren Entwicklung RL als Dataflow-Problem interpretiert.²⁰

Die wichtigste praktische Frage lautet:

Will man RL verstehen, prototypisieren oder produktionsnah skalieren?

Für Lernen und Experimente sind TRL und CleanRL attraktiv. Für LLM-RL im Cluster braucht man Frameworks, die Rollouts, Inferenz, Rewarding, Weight Sync und Training orchestrieren können. Für allgemeine RL-Systeme außerhalb von LLMs bleibt RLlib relevant.

Der Auswahlfehler liegt oft darin, ein Trainingsframework mit einer vollständigen RL-Plattform zu verwechseln. Wer agentisches LLM-RL betreibt, braucht zusätzlich Sandboxes, Datenversionierung, Eval-Harnesses, Security Controls und Observability. Das Framework löst den Optimizer-Teil, nicht automatisch den Systemteil.

17. State of the Art 2026 als Landkarte

Der State of the Art in RL ist kein einzelner Algorithmus. Er ist eine Landkarte aus Anwendungsfeldern, Datenregimen, Reward-Typen und Systemarchitekturen. Wer nur nach dem „besten RL-Verfahren“ fragt, übersieht die entscheidende zweite Hälfte: Welche Umgebung, welcher Reward und welcher Systemloop machen das Verfahren überhaupt wirksam?

Für LLMs ist 2026 besonders wichtig: Der Fortschritt liegt im Loop, nicht nur im Modell.

bessere Aufgaben → bessere Rollouts → bessere Rewards → stabileres Training → bessere Policy → bessere Rollouts

Dieser Kreislauf kann Fähigkeiten verstärken. Er kann aber auch Artefakte verstärken. Deshalb ist robuste Evaluation so wichtig: Sie entscheidet, ob der Loop Kompetenz skaliert oder nur seine eigenen Messfehler.

18. Wie man erkennt, ob RL sinnvoll ist

RL ist teuer, empfindlich und mächtig. Es lohnt sich, wenn die Aufgabe tatsächlich sequenzielles Verhalten unter Feedback verlangt. Für reine Zuordnungs-, Format- oder Stilprobleme ist RL oft unnötige Komplexität.

RL ist besonders sinnvoll, wenn:

• es eine klare Zielmetrik gibt,
• Handlungen sequenziell sind,
• Feedback aus Interaktion kommt,
• mehrere Lösungswege möglich sind,
• der Reward automatisch oder zuverlässig berechnet werden kann,
• Exploration sicher oder simulierbar ist,
• Supervised Learning allein nicht ausreicht.

RL ist oft überdimensioniert, wenn:

• es gute gelabelte Beispiele gibt,
• die Aufgabe nur eine einfache Zuordnung ist,
• keine echte Interaktion nötig ist,
• Rewards unklar oder manipulierbar sind,
• Exploration gefährlich oder teuer ist,
• Evaluation nicht robust ist.

19. Strategische Einordnung

1. RL optimiert Verhalten, nicht bloß Text. Die relevante Einheit ist die Handlung im Environment. „Lernen durch Belohnung“ ist als Erklärung zu dünn: Optimiert wird eine Policy für sequenzielles Verhalten unter einem Feedbacksignal aus einer Umgebung.
2. Der Reward ist die Spezifikation. Schlechte Rewards erzeugen nicht zufällig schlechte Ergebnisse; sie erzeugen genau die falsche Optimierung. Mehr Optimierung verstärkt immer auch Messfehler.
3. RLHF ist nur ein Ausschnitt. RLVR, Preference Optimization, agentisches RL, Robotik, Offline- und Multi-Agent-RL gehören zur gleichen Landkarte, lösen aber verschiedene Aufgaben. Und DPO ist kein klassischer RL-Algorithmus: Es stammt aus der RLHF-Theorie, ersetzt den RL-Loop aber durch direkte Offline-Präferenzoptimierung.⁴
4. Verifier sind der wichtigste Skalierungshebel. Code, Mathematik und formale Aufgaben profitieren, weil Korrektheit billig und konsistent prüfbar wird. Verifizierbare Rewards lösen Reward Hacking aber nicht vollständig: Tests können unvollständig sein, Endantworten zufällig richtig, der Evaluationsharness ausnutzbar.
5. Harnesses sind Control Points. Sie definieren, welche Aktionen möglich sind, welche Daten entstehen und welche Abkürzungen der Agent lernen kann. Benchmark, Umgebung und Harness bleiben dabei drei verschiedene Dinge: eine Aufgabensammlung mit Metriken, die interaktive Welt und die technische Schicht, die beides operationalisiert.
6. LLM-RL ist Infrastrukturarbeit. Rollout-Durchsatz, Sandboxes, Weight Sync, Logprobs und numerische Konsistenz entscheiden mit über Qualität und Kosten.
7. GRPO ist Referenzpunkt, nicht Endzustand. DAPO, GSPO, CISPO und verwandte Varianten zeigen, dass die relevante Forschung an Stabilität, Sequenzebene und Off-Policy-Korrektur arbeitet.
8. Mehr Compute — und mehr RL — brauchen Struktur. Test-Time Compute, Rollout-Sampling und RL-Skalierung helfen nur, wenn Suchstrategien, Verifier und Evaluation robust sind. Sonst macht RL Modelle auch überangepasst, manipulierbar oder scheinbar kompetent.
9. Elicitation bleibt die offene Frage. RL kann latente Fähigkeiten besser abrufen und unter bestimmten Bedingungen neue Strategien stabilisieren; beides muss außerhalb des Trainingsharness geprüft werden.
10. Evaluation ist Teil des Designs. Bei RL entscheidet die Evaluation nicht nachträglich über Qualität, sondern während des Trainings über das Verhalten, das entsteht.

RL 2026 lässt sich am Ende in einem Satz verdichten:

Reinforcement Learning ist die Kunst und Technik, ein System durch bewertete Interaktion so zu optimieren, dass es in einer Umgebung zielgerichtet handelt; bei modernen KI-Agenten entscheidet die Qualität von Environment, Harness, Reward und Systeminfrastruktur mindestens so stark über den Erfolg wie der Optimierungsalgorithmus.

Oder noch kürzer:

RL ist ein Feedbacksystem.

Quellen und weiterführende Literatur

Die folgende Liste ist bewusst gemischt: Grundlagen, LLM-Alignment, RLVR, moderne LLM-RL-Algorithmen und Systeminfrastruktur. Einige sehr aktuelle 2025/26-Arbeiten sind Preprints; ihre Ergebnisse sollten für produktive Entscheidungen gegen Primärquellen und Replikationen geprüft werden.