Recursive Language Models: Wenn das LLM zum Programmierer seines eigenen Gedächtnisses wird

MIT CSAIL hat ein Frame­work entwick­elt, mit dem Stan­dard-LLMs plöt­zlich 10 Mil­lio­nen Tokens ver­ar­beit­en kön­nen – nicht durch größere Kon­textfen­ster, son­dern weil das Mod­ell lernt, seinen eige­nen Infor­ma­tion­szu­griff zu pro­gram­mieren. Während Google und Anthrop­ic im Wet­trüsten um län­gere Con­text Win­dows steck­en, zeigt RLM einen ele­gan­teren Weg: Das Prob­lem liegt nicht in der Hard­ware, son­dern in der Architek­tur. 

Das Kon­textfen­ster-Prob­lem oder: Warum mehr nicht immer bess­er ist

Die Geschichte der Large Lan­guage Mod­els der let­zten zwei Jahre liest sich wie ein Wet­trüsten der Kon­textfen­ster-Größen. GPT‑4 startete mit 8.000 Tokens, dann kamen 32k, Google kündigte eine Mil­lion an, Anthrop­ic kon­terte mit zwei Mil­lio­nen bei Claude. Die implizite Annahme dahin­ter: Wenn wir nur genug Text in das Mod­ell hinein­bekom­men, wer­den die Ergeb­nisse automa­tisch bess­er. Das ist tech­nol­o­gis­ch­er Gigan­tismus – mehr Spe­ich­er, mehr Para­me­ter, mehr Rechen­leis­tung. Es ist die Inge­nieurs-Vari­ante des “wenn der Ham­mer das einzige Werkzeug ist, sieht jedes Prob­lem wie ein Nagel aus.”

Dabei zeigt sich in der Prax­is ein ganz anderes Bild. Claude mit seinen zwei Mil­lio­nen Tokens kann zwar the­o­retisch ein ganzes Buch auf ein­mal ver­ar­beit­en, aber die Qual­ität der Antworten ver­schlechtert sich drama­tisch, je mehr Text tat­säch­lich im Fen­ster liegt. Das Phänomen heißt in der Forschung “Lost in the Mid­dle” oder pro­sais­ch­er “Con­text Rot” – das Mod­ell ver­liert den Überblick, über­sieht rel­e­vante Details in der Mitte des Textes, hal­luziniert Zusam­men­hänge. Der Grund ist fun­da­men­tal: Atten­tion-Mech­a­nis­men skalieren qua­dratisch. Je länger der Kon­text, desto schwäch­er wird die Aufmerk­samkeit für einzelne Tokens.

Das ist nicht nur ein akademis­ches Prob­lem. Für eine deutsche Region­al­bank mit 500.000 Kred­itverträ­gen aus drei Jahrzehn­ten, die her­aus­find­en muss, welche davon prob­lema­tis­che Zin­sklauseln enthal­ten, ist ein Mul­ti-Mil­lio­nen-Token-Fen­ster prak­tisch wert­los. Man kann nicht ein­fach alle Verträge hinein­wer­fen und hof­fen, dass das Mod­ell schon das Richtige find­et. Die Kosten wären astronomisch, die Latenz inakzept­abel, die Fehlerquote hoch. RAG (Retrieval-Aug­ment­ed Gen­er­a­tion) hil­ft teil­weise – man kann vor­ab fil­tern, welche Doku­mente rel­e­vant sein kön­nten – aber auch RAG stößt an Gren­zen, wenn die rel­e­van­ten Infor­ma­tio­nen über Hun­derte von Seit­en verteilt sind und man nicht nur einzelne Fak­ten, son­dern kom­plexe Rea­son­ing-Ket­ten über lange Texte hin­weg braucht.

Hier set­zt das Recur­sive Lan­guage Mod­el Frame­work von MIT CSAIL an. Die Kernidee ist radikal ein­fach und gle­ichzeit­ig konzep­tionell fun­da­men­tal anders als alles, was große Model­lan­bi­eter derzeit ver­fol­gen: Statt den Text in ein immer größeres Kon­textfen­ster zu pressen, wird das Kon­textfen­ster selb­st zum pro­gram­mier­baren Inter­face. Der lange Text liegt nicht im Mod­ell, son­dern als externe Vari­able in ein­er Python-Umge­bung. Das LLM bekommt nur Meta­dat­en – wie groß ist der Text, wie ist er struk­turi­ert – und schreibt dann Code, um gezielt die Teile zu laden, die es ger­ade braucht.

Wie Men­schen mit großen Textmen­gen umge­hen

Die Analo­gie zu men­schlichem Arbeit­en ist offen­sichtlich und instruk­tiv. Nie­mand liest ein Geset­zbuch von vorne bis hin­ten, wenn er eine spez­i­fis­che Rechts­frage klären will. Man schlägt im Inhaltsverze­ich­nis nach, navigiert zum rel­e­van­ten Para­graphen, liest diesen genau, prüft eventuell Querver­weise, und erst wenn das nicht aus­re­icht, erweit­ert man den Suchra­dius. Das ist ein iter­a­tiv­er, strate­gis­ch­er Prozess – kein lin­ear­es Durchkäm­men des gesamten Textes.

Genau das macht RLM. Das Frame­work nutzt typ­is­cher­weise zwei Mod­ell-Instanzen: ein “Root Lan­guage Mod­el” (groß, teuer, strate­gisch) und ein “Recur­sive Lan­guage Mod­el” (klein, gün­stig, oper­a­tiv). Das Root Mod­el bekommt die Auf­gabe und die Struk­tur des Doku­ments. Es entwick­elt eine Such-Strate­gie und schreibt Python-Code, der diese umset­zt. Dieser Code nutzt Funk­tio­nen wie load_section(), um gezielt Textab­schnitte zu laden, search_clause() für Regex-basierte Suchen, oder recursive_analyze(), um das Work­er-Mod­ell auf einen spez­i­fis­chen Abschnitt anzuset­zen.

Das klingt kom­pliziert, ist aber in der Exe­cu­tion bemerkenswert effizient. In den MIT-Bench­marks erre­ichte ein RLM-Set­up basierend auf GPT‑5 bei Eingaben von sechs bis elf Mil­lio­nen Tokens einen Score von 91 Prozent, während Stan­dard­mod­elle kom­plett ver­sagten – null Prozent. Bei infor­ma­tions­dicht­en Auf­gaben, wo selb­st die Posi­tion rel­e­van­ter Infor­ma­tio­nen vari­iert, lag der F1-Score bei 58 Prozent gegenüber nahe null beim Base­line-Mod­ell. Und das bei Kosten, die häu­fig unter denen eines naiv­en Ansatzes lagen, weil eben nicht der gesamte Text durch teure LLM-Calls gejagt wird, son­dern nur die rel­e­van­ten Frag­mente.

Das ist keine inkre­mentelle Verbesserung. Das ist ein Par­a­dig­men­wech­sel – von “werfe alles ins Mod­ell und hoffe auf das Beste” zu “das Mod­ell entschei­det, was es sehen will.”

Die Architek­tur als organ­isatorisches Prinzip

Was RLM tech­nisch umset­zt, entspricht konzep­tionell dem, was Infor­matik­er seit Jahrzehn­ten als “Out-of-Core”-Verarbeitung ken­nen: Der Arbeitsspe­ich­er (hier: Kon­textfen­ster) bleibt klein und schnell, der externe Spe­ich­er (hier: Python-Vari­able mit Voll­text) wird nach Bedarf adressiert. Vir­tu­al Mem­o­ry Man­age­ment für LLMs, wenn man so will. Das ist keine neue Idee, aber die Anwen­dung auf Sprach­mod­elle ist neu – und sie löst ein Prob­lem, das die Indus­trie bis­lang durch Brute Force zu erschla­gen ver­suchte.

Die prak­tis­che Umset­zung erfordert allerd­ings mehr als nur ein cleveres Prompt­ing-Pat­tern. Man braucht eine Exe­cu­tion-Umge­bung, die den LLM-gener­ierten Code sich­er aus­führen kann. Man braucht Guardrails gegen Kosten­ex­plo­sion, wenn das Mod­ell sich in Schleifen ver­läuft. Man braucht Mon­i­tor­ing, um zu sehen, welche Such-Strate­gien funk­tion­ieren und welche nicht. Und vor allem braucht man struk­turi­erte Dat­en – ein JSON-Baum, der die Doku­menten­struk­tur abbildet, ist unendlich wertvoller als ein Roh­textdump.

Für eine Bank bedeutet das konkret: Bevor man RLM über­haupt ein­set­zen kann, muss ein Pre­pro­cess­ing-Lay­er her, der het­ero­gene Verträge aus FileNet, Share­Point und ges­can­nten PDFs in eine ein­heitliche Struk­tur über­führt. Das ist unglam­ouröse Daten­pipeline-Arbeit – OCR für Alt­doku­mente, LLM-basierte Struk­turex­trak­tion, Meta­dat­en-Anre­icherung. Aber ohne diesen Schritt bleibt RLM the­o­retis­ches Poten­zial.

Die eigentliche Orches­tra­tion fol­gt dann einem klaren Muster: Das Root Mod­el erhält nicht den Voll­text, son­dern nur die Baum­struk­tur der Doku­mente. Es entwick­elt eine Strate­gie – etwa “suche erst nach allen Verträ­gen mit EURI­BOR-Bezug, dann prüfe nur diese auf fehlende Zin­sober­gren­zen” – und gener­iert entsprechen­den Python-Code. Dieser Code wird in ein­er Sand­box aus­ge­führt, wobei jede Funk­tion, die Kosten verur­sacht (etwa recursive_analyze() mit einem LLM-Call), durch Bud­get Man­ag­er und Cir­cuit Break­er überwacht wird.

Das Ergeb­nis ist keine Black Box mehr, son­dern ein nachvol­lziehbar­er Ver­ar­beitungsp­fad. Man kann sehen, welche Doku­mente das Mod­ell angeschaut hat, welche Code-Pfade es gewählt hat, wo es Kosten verur­sacht hat. Für reg­ulierte Indus­trien – Bank­ing, Phar­ma, Ver­sicherung – ist diese Trans­parenz nicht option­al, son­dern Com­pli­ance-Voraus­set­zung.

Quellen:

MIT’s new ‘recur­sive’ frame­work lets LLMs process 10 mil­lion tokens with­out con­text rot.
https://venturebeat.com/orchestration/mits-new-recursive-framework-lets-llms-process-10-million-tokens-without​

YouTube-Video (MIT CSAIL): Scal­ing LLMs to 10M+ Tokens (RLMs).
https://www.youtube.com/watch?v=1knD5bpCm74

​Dera.ai-Zusammenfassung: MIT’s new ‘recur­sive’ frame­work lets LLMs process 10 mil­lion tokens.
https://www.dera.ai/en/news/58c7c134-395b-594d-b4a9-43c9251c2750​

Sekundäre Diskus­sio­nen und Erwäh­nun­gen

Red­dit r/technews: Diskus­sion zum Ven­ture­Beat-Artikel.
https://www.reddit.com/r/technews/comments/1qj3txz/mits_new_recursive_framework_lets_llms_process_10/​

LinkedIn Alok Nayak: Post zum MIT-Frame­work.
https://www.linkedin.com/posts/aloknayak_mits-new-recursive-framework-lets-llms-activity-7419794705728614400–9Nuz

​LinkedIn Antho­ny L.: Weit­ere Erwäh­nung 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 Frame­work.
https://www.linkedin.com/posts/j‑edi-388b2124a_mits-new-recursive-framework-lets-llms-activity-7419548094138134528-M44V​

LinkedIn Chris­tos Makridis: Analyse des Frame­works.
https://www.linkedin.com/posts/christosmakridis_mits-new-recursive-framework-lets-llms-activity-7420525766548918272-Ppv7