- Es wurde eine neue Inferenzstrategie RLM (Recursive Language Model) vorgeschlagen, die es Large Language Models (LLMs) ermöglicht, sehr lange Eingabe-Prompts zu verarbeiten
- RLM behandelt lange Prompts als Teil der externen Umgebung und erlaubt dem Modell, sie programmatisch zu durchsuchen, zu zerlegen und rekursiv aufzurufen
- Dieser Ansatz überwindet die Grenzen des bisherigen Kontextfensters, verarbeitet Eingaben im Umfang von bis zu mehreren zehn Millionen Tokens und verbessert die Qualität gegenüber bestehenden LLMs deutlich
- Experimente zeigen, dass RLMs auf Basis von GPT-5 und Qwen3-Coder bei verschiedenen Langtext-Aufgaben Leistungssteigerungen im zweistelligen Prozentbereich erzielen, bei ähnlichen oder niedrigeren Kosten
- Der Ansatz gilt als allgemeine Methode, um die Grenzen der Verarbeitung langer Kontexte zu überwinden und die Inferenzfähigkeit von LLMs stark zu erweitern
Überblick über RLM
- Recursive Language Model (RLM) ist so konzipiert, dass ein LLM lange Eingaben nicht direkt in das neuronale Netz einspeist, sondern sie als Variablen einer externen Umgebung behandelt und mit ihnen interagiert
- Der Eingabe-Prompt P wird als Variable in eine Python-REPL-Umgebung geladen, und das LLM durchsucht, zerlegt und ruft ihn per Code rekursiv auf
- Das LLM erkennt den Zustand der REPL-Umgebung (z. B. die String-Länge), beobachtet die Nebenwirkungen der Codeausführung und löst das Problem schrittweise
- Diese Struktur löst das Problem, dass bestehende Kontextkomprimierungs-(compaction)- oder zusammenfassungsbasierte Ansätze Details verlieren
- RLM wird als allgemeines Inferenzparadigma vorgestellt, das sowohl Eingabe- als auch Ausgabelänge skalieren kann
Grenzen bestehender Ansätze
- Bestehende LLMs zeigen aufgrund der Begrenzung des Kontextfensters bei langen Eingaben das Phänomen des context rot, bei dem die Leistung stark abfällt
- Kontextkomprimierungs-(compaction)-Verfahren wiederholen ab einer bestimmten Länge Zusammenfassungen, sind aber für Aufgaben ungeeignet, die Zugriff auf feine Details erfordern
- RLM kann die Eingabegröße über die Modellgrenzen hinaus erweitern, indem es den Prompt als externes Objekt behandelt
Experimentelles Setup
- Bewertete Modelle: GPT-5 (OpenAI, 2025) und Qwen3-Coder-480B-A35B (Team, 2025)
- Vergleichsverfahren:
- direkter Aufruf des Basis-LLM
- Summary agent
- suchbasierter Agent mit CodeAct + BM25
- RLM (mit REPL-Umgebung) und RLM (REPL, ohne rekursive Aufrufe)
- In den GPT-5-Experimenten wurde GPT-5-mini für rekursive Aufrufe und GPT-5 als Root-Modell verwendet, um ein Gleichgewicht zwischen Leistung und Kosten zu erreichen
Evaluierungsaufgaben
- S-NIAH: einzelnes „needle-in-a-haystack“-Problem mit konstanten Verarbeitungskosten unabhängig von der Eingabelänge
- BrowseComp-Plus: Multi-Hop-Fragebeantwortung über mehrere Dokumente hinweg, wobei die richtige Antwort unter 1000 Dokumenten enthalten ist
- OOLONG: Langtext-Inferenzaufgabe, bei der fast alle Elemente der Eingabe semantisch transformiert und integriert werden müssen; die Verarbeitungskosten steigen linear mit der Eingabelänge
- OOLONG-Pairs: Variante von OOLONG, die die Kombination von Informationen paarweise erfordert; die Verarbeitungskosten steigen quadratisch mit der Eingabelänge
- LongBench-v2 CodeQA: Multiple-Choice-Aufgabe, die das Verständnis eines Code-Repositorys erfordert und selbst für aktuelle Modelle schwierig ist
Zentrale Ergebnisse
- RLM zeigt im Vergleich zu GPT-5 selbst bei langen Kontexten kaum Leistungsabfall
- GPT-5 verliert mit wachsender Eingabelänge und steigender Aufgabenkomplexität schnell an Leistung
- RLM verarbeitet auch Eingaben oberhalb der 272K-Token-Grenze (bis zu 10M+ Tokens) effektiv
- Bei allen Langtext-Aufgaben erzielt RLM gegenüber anderen Methoden Leistungssteigerungen im zweistelligen Bereich
- Auch die Kosteneffizienz bleibt erhalten: Die Kosten pro Anfrage sind ähnlich wie bei bestehenden Ansätzen oder sogar niedriger
Komplexitätsanalyse von Langtext-Aufgaben
- Das effektive Kontextfenster eines LLM kann abhängig von der Aufgabenkomplexität kürzer sein als die physische Grenze
- Ein einfaches NIAH-Problem lässt sich auch bei 1M+ Tokens lösen
- Komplexe Aufgaben vom Typ OOLONG zeigen schon bei deutlich kürzeren Längen Leistungsabfälle
- Daher müssen Informationsdichte der Aufgabe und Eingabelänge in ihrem Zusammenhang gemeinsam betrachtet werden
Fazit
- RLM erweitert die Inferenzfähigkeit von LLMs rekursiv und ermöglicht so die Verarbeitung von extrem langen Eingaben, die bestehende Modelle nicht bewältigen können
- Die Behandlung des Prompts als Umgebungsobjekt ist die zentrale Innovation und löst strukturelle Grenzen der Langtextverarbeitung
- Vorgestellt wird es als allgemeines Inferenz-Framework, das bei verschiedenen Modellen und Aufgaben ein Gleichgewicht zwischen Leistung, Kosten und Skalierbarkeit erreicht
1 Kommentare
Hacker-News-Kommentare
Das wirkt einfach wie das Konzept von Subagents.
Also ein Ansatz, bei dem ein anderes LLM aufgerufen wird, um Dateien zu lesen und die nötigen Informationen zu extrahieren, damit der Hauptkontext nicht unnötig kompliziert wird.
Die Idee ist gut, aber nicht völlig neu.
Im aktuellen Scope-Projekt experimentiere ich damit, beobachtbare Subagents Aufgaben rekursiv zerlegen zu lassen.
Ich weiß allerdings nicht, wie sich diese Bewertung der Planungsphase verbessern ließe.
Ich halte Heuristiken in Markdown-Dateien fest, aber die Struktur ist zu locker, um sie gut messen zu können.
Falls jemand einschlägige Literatur oder Projekte kennt, wäre ich für Hinweise dankbar.
Ein RLM ist weder ein Agent noch eine Zusammenfassung.
Mehrere LM-Aufrufe in einem einzigen System zu verwenden, ist kein neues Konzept; genau das machen die meisten agentic scaffolds.
Als ähnlichstes Beispiel wird der ROMA agent genannt, der Probleme zerlegt und mit mehreren Sub-Agents löst.
Auch Code-Assistenten wie Cursor oder Claude Code fassen zusammen oder schneiden Kontext weg, wenn er zu lang wird.
Solche Ansätze zerlegen normalerweise nach Arbeitseinheiten, während RLM die Zerlegung nach Kontexteinheiten betont und davon ausgeht, dass das LM diese Auswahl selbst treffen sollte.
Die zentrale Einsicht ist, dass man lange Prompts nicht direkt in ein neuronales Netz (Transformer) stecken sollte, sondern sie als Teil einer Umgebung behandeln sollte, mit der ein LLM symbolisch interagieren kann.
Ich frage mich allerdings, worin sich das grundsätzlich von RAG unterscheidet.
Wenn ich Abbildung 4 ansehe, scheint der Unterschied zu sein, dass nicht ein Mensch, sondern das LLM selbst den Retrieval-Mechanismus implementiert.
1️⃣ RAG ist eher ein Workflow, das hier ist stärker agentic.
2️⃣ Es hat eine rekursive Struktur.
In einem Workflow entwirft ein Mensch den Ablauf Schritt für Schritt, bei einem agentischen Ansatz entscheidet der Agent selbst, wonach er sucht, wie oft er etwas aufruft und wann er antwortet.
So durchsuchen etwa Claude Code oder Codex eine Codebasis, lesen Dateien und führen ripgrep aus.
Solche rekursiven Versuche gab es auch früher schon, zum Beispiel babyagi um 2023, aber damals war die Modellleistung zu schwach und es brauchte viel Glue Code.
Inzwischen sind die Modelle stark genug, dass solche Strukturen tatsächlich funktionieren.
Wie der Witz „T̶u̶r̶t̶l̶e̶s̶ LLMs all the way down“ andeutet, geht es um eine Struktur, in der LLMs endlos weitere LLMs aufrufen.
Es gibt eine leichter lesbare Version des Textes: Blogbeitrag von alexzhang13
Was ich mir für 2026 wünsche, ist, dass Anthropic oder OpenAI gegenüber Entwicklern von CLI-Plugins offenlegen, „wie compaction ausgeführt wird“.
Diese Technik könnte möglicherweise Funktionen ersetzen, die derzeit fest in Claude Code eingebaut sind, aber im Moment werden dafür keine passenden Hooks oder Funktionen offengelegt.
Ich habe mir den Code von Gemini angesehen, und dort war es nur eine einfache Prompt-Struktur, die alles zusammenfasst, sobald das Kontextfenster voll ist.
Sieht diesem Paper ähnlich: arXiv:2510.14826