MIT CSAIL hat ein Framework entwickelt, mit dem Standard-LLMs plötzlich 10 Millionen Tokens verarbeiten können – nicht durch größere Kontextfenster, sondern weil das Modell lernt, seinen eigenen Informationszugriff zu programmieren. Während Google und Anthropic im Wettrüsten um längere Context Windows stecken, zeigt RLM einen eleganteren Weg: Das Problem liegt nicht in der Hardware, sondern in der Architektur.
Das Kontextfenster-Problem oder: Warum mehr nicht immer besser ist
Die Geschichte der Large Language Models der letzten zwei Jahre liest sich wie ein Wettrüsten der Kontextfenster-Größen. GPT‑4 startete mit 8.000 Tokens, dann kamen 32k, Google kündigte eine Million an, Anthropic konterte mit zwei Millionen bei Claude. Die implizite Annahme dahinter: Wenn wir nur genug Text in das Modell hineinbekommen, werden die Ergebnisse automatisch besser. Das ist technologischer Gigantismus – mehr Speicher, mehr Parameter, mehr Rechenleistung. Es ist die Ingenieurs-Variante des “wenn der Hammer das einzige Werkzeug ist, sieht jedes Problem wie ein Nagel aus.”
Dabei zeigt sich in der Praxis ein ganz anderes Bild. Claude mit seinen zwei Millionen Tokens kann zwar theoretisch ein ganzes Buch auf einmal verarbeiten, aber die Qualität der Antworten verschlechtert sich dramatisch, je mehr Text tatsächlich im Fenster liegt. Das Phänomen heißt in der Forschung “Lost in the Middle” oder prosaischer “Context Rot” – das Modell verliert den Überblick, übersieht relevante Details in der Mitte des Textes, halluziniert Zusammenhänge. Der Grund ist fundamental: Attention-Mechanismen skalieren quadratisch. Je länger der Kontext, desto schwächer wird die Aufmerksamkeit für einzelne Tokens.
Das ist nicht nur ein akademisches Problem. Für eine deutsche Regionalbank mit 500.000 Kreditverträgen aus drei Jahrzehnten, die herausfinden muss, welche davon problematische Zinsklauseln enthalten, ist ein Multi-Millionen-Token-Fenster praktisch wertlos. Man kann nicht einfach alle Verträge hineinwerfen und hoffen, dass das Modell schon das Richtige findet. Die Kosten wären astronomisch, die Latenz inakzeptabel, die Fehlerquote hoch. RAG (Retrieval-Augmented Generation) hilft teilweise – man kann vorab filtern, welche Dokumente relevant sein könnten – aber auch RAG stößt an Grenzen, wenn die relevanten Informationen über Hunderte von Seiten verteilt sind und man nicht nur einzelne Fakten, sondern komplexe Reasoning-Ketten über lange Texte hinweg braucht.
Hier setzt das Recursive Language Model Framework von MIT CSAIL an. Die Kernidee ist radikal einfach und gleichzeitig konzeptionell fundamental anders als alles, was große Modellanbieter derzeit verfolgen: Statt den Text in ein immer größeres Kontextfenster zu pressen, wird das Kontextfenster selbst zum programmierbaren Interface. Der lange Text liegt nicht im Modell, sondern als externe Variable in einer Python-Umgebung. Das LLM bekommt nur Metadaten – wie groß ist der Text, wie ist er strukturiert – und schreibt dann Code, um gezielt die Teile zu laden, die es gerade braucht.
Wie Menschen mit großen Textmengen umgehen
Die Analogie zu menschlichem Arbeiten ist offensichtlich und instruktiv. Niemand liest ein Gesetzbuch von vorne bis hinten, wenn er eine spezifische Rechtsfrage klären will. Man schlägt im Inhaltsverzeichnis nach, navigiert zum relevanten Paragraphen, liest diesen genau, prüft eventuell Querverweise, und erst wenn das nicht ausreicht, erweitert man den Suchradius. Das ist ein iterativer, strategischer Prozess – kein lineares Durchkämmen des gesamten Textes.
Genau das macht RLM. Das Framework nutzt typischerweise zwei Modell-Instanzen: ein “Root Language Model” (groß, teuer, strategisch) und ein “Recursive Language Model” (klein, günstig, operativ). Das Root Model bekommt die Aufgabe und die Struktur des Dokuments. Es entwickelt eine Such-Strategie und schreibt Python-Code, der diese umsetzt. Dieser Code nutzt Funktionen wie load_section(), um gezielt Textabschnitte zu laden, search_clause() für Regex-basierte Suchen, oder recursive_analyze(), um das Worker-Modell auf einen spezifischen Abschnitt anzusetzen.
Das klingt kompliziert, ist aber in der Execution bemerkenswert effizient. In den MIT-Benchmarks erreichte ein RLM-Setup basierend auf GPT‑5 bei Eingaben von sechs bis elf Millionen Tokens einen Score von 91 Prozent, während Standardmodelle komplett versagten – null Prozent. Bei informationsdichten Aufgaben, wo selbst die Position relevanter Informationen variiert, lag der F1-Score bei 58 Prozent gegenüber nahe null beim Baseline-Modell. Und das bei Kosten, die häufig unter denen eines naiven Ansatzes lagen, weil eben nicht der gesamte Text durch teure LLM-Calls gejagt wird, sondern nur die relevanten Fragmente.
Das ist keine inkrementelle Verbesserung. Das ist ein Paradigmenwechsel – von “werfe alles ins Modell und hoffe auf das Beste” zu “das Modell entscheidet, was es sehen will.”
Die Architektur als organisatorisches Prinzip
Was RLM technisch umsetzt, entspricht konzeptionell dem, was Informatiker seit Jahrzehnten als “Out-of-Core”-Verarbeitung kennen: Der Arbeitsspeicher (hier: Kontextfenster) bleibt klein und schnell, der externe Speicher (hier: Python-Variable mit Volltext) wird nach Bedarf adressiert. Virtual Memory Management für LLMs, wenn man so will. Das ist keine neue Idee, aber die Anwendung auf Sprachmodelle ist neu – und sie löst ein Problem, das die Industrie bislang durch Brute Force zu erschlagen versuchte.
Die praktische Umsetzung erfordert allerdings mehr als nur ein cleveres Prompting-Pattern. Man braucht eine Execution-Umgebung, die den LLM-generierten Code sicher ausführen kann. Man braucht Guardrails gegen Kostenexplosion, wenn das Modell sich in Schleifen verläuft. Man braucht Monitoring, um zu sehen, welche Such-Strategien funktionieren und welche nicht. Und vor allem braucht man strukturierte Daten – ein JSON-Baum, der die Dokumentenstruktur abbildet, ist unendlich wertvoller als ein Rohtextdump.
Für eine Bank bedeutet das konkret: Bevor man RLM überhaupt einsetzen kann, muss ein Preprocessing-Layer her, der heterogene Verträge aus FileNet, SharePoint und gescannten PDFs in eine einheitliche Struktur überführt. Das ist unglamouröse Datenpipeline-Arbeit – OCR für Altdokumente, LLM-basierte Strukturextraktion, Metadaten-Anreicherung. Aber ohne diesen Schritt bleibt RLM theoretisches Potenzial.
Die eigentliche Orchestration folgt dann einem klaren Muster: Das Root Model erhält nicht den Volltext, sondern nur die Baumstruktur der Dokumente. Es entwickelt eine Strategie – etwa “suche erst nach allen Verträgen mit EURIBOR-Bezug, dann prüfe nur diese auf fehlende Zinsobergrenzen” – und generiert entsprechenden Python-Code. Dieser Code wird in einer Sandbox ausgeführt, wobei jede Funktion, die Kosten verursacht (etwa recursive_analyze() mit einem LLM-Call), durch Budget Manager und Circuit Breaker überwacht wird.
Das Ergebnis ist keine Black Box mehr, sondern ein nachvollziehbarer Verarbeitungspfad. Man kann sehen, welche Dokumente das Modell angeschaut hat, welche Code-Pfade es gewählt hat, wo es Kosten verursacht hat. Für regulierte Industrien – Banking, Pharma, Versicherung – ist diese Transparenz nicht optional, sondern Compliance-Voraussetzung.
Quellen:
MIT’s new ‘recursive’ framework lets LLMs process 10 million tokens without context rot.
https://venturebeat.com/orchestration/mits-new-recursive-framework-lets-llms-process-10-million-tokens-without
YouTube-Video (MIT CSAIL): Scaling LLMs to 10M+ Tokens (RLMs).
https://www.youtube.com/watch?v=1knD5bpCm74
Dera.ai-Zusammenfassung: MIT’s new ‘recursive’ framework lets LLMs process 10 million tokens.
https://www.dera.ai/en/news/58c7c134-395b-594d-b4a9-43c9251c2750
Sekundäre Diskussionen und Erwähnungen
Reddit r/technews: Diskussion zum VentureBeat-Artikel.
https://www.reddit.com/r/technews/comments/1qj3txz/mits_new_recursive_framework_lets_llms_process_10/
LinkedIn Alok Nayak: Post zum MIT-Framework.
https://www.linkedin.com/posts/aloknayak_mits-new-recursive-framework-lets-llms-activity-7419794705728614400–9Nuz
LinkedIn Anthony L.: Weitere Erwähnung des Artikels.
https://www.linkedin.com/posts/anthony-l-22b08151_mits-new-recursive-framework-lets-llms-activity-7419604426845405184-ueYS
LinkedIn J EDI: Kurze Notiz zum Framework.
https://www.linkedin.com/posts/j‑edi-388b2124a_mits-new-recursive-framework-lets-llms-activity-7419548094138134528-M44V
LinkedIn Christos Makridis: Analyse des Frameworks.
https://www.linkedin.com/posts/christosmakridis_mits-new-recursive-framework-lets-llms-activity-7420525766548918272-Ppv7