Robocikowo>ROBOCIKOWO
Wnioskowanie

RLM

2025BadawczyOpublikowany
Recursive Language Models (RLM) to paradygmat inferencji, w którym LLM root wywołuje sam siebie lub mniejsze modele jako podzapytania w środowisku REPL, traktując długi kontekst jak zmienną w pamięci. Pozwala obsługiwać konteksty o rzędy wielkości większe niż okno modelu i ogranicza zjawisko „context rot”.
Kluczowa innowacja
LLM otrzymuje długi kontekst jako zmienną w środowisku REPL i sam decyduje, jak go partycjonować, przeszukiwać i delegować do rekurencyjnych wywołań mniejszych instancji — zamiast czytać cały kontekst naraz.
Kategoria
Wnioskowanie
Poziom abstrakcji
Paradigm
Poziom operacji
InferencjaSystemOrkiestracjaŚrodowisko agentowe
Zastosowania
Obsługa promptów >10M tokenów bez retrieveraLong-context Q&A (OOLONG, multi-hop nad dziesiątkami tysięcy wpisów)Deep Research nad korpusami ~100k dokumentów (BrowseComp-Plus)Programatyczne przetwarzanie historii (LoCoDiff, git log)Generacja długich wyjść (np. BibTeX z listy 100+ papers)Mitygacja context rot w wielogodzinnych sesjach Claude Code / CursorSkalowanie test-time compute jako alternatywa dla CoT i agentów

Jak działa

Root LM otrzymuje wyłącznie zapytanie q i informację, że kontekst C istnieje jako zmienna w REPL. Środowisko (zwykle Python REPL / Jupyter) pozwala mu wykonywać dowolny kod nad tą zmienną — peek (odczyt pierwszych N znaków), grep (regex), partition + map (chunking + równoległe rekurencyjne wywołania LLM nad fragmentami), summarization (skondensowanie podzbiorów). Każde wywołanie rekurencyjne RLM_M(q̂, Ĉ) tworzy izolowaną instancję sub-RLM z własnym środowiskiem; jej wynik wraca do środowiska wywołującego. W referencyjnej implementacji autorzy ograniczyli głębokość do 1 (root może wołać LLM, ale nie inne RLM). Końcowa odpowiedź zwracana jest tagiem FINAL(...) (bezpośrednio) lub FINAL_VAR(nazwa_zmiennej) (z pamięci REPL).

Rozwiązany problem

Frontier LLM tracą jakość przy długim kontekście (zjawisko „context rot”), a sztywne okno (np. 272k dla GPT-5) blokuje obsługę korpusów rzędu milionów tokenów. Standardowe rozwiązania — RAG, ReAct z retrieverem, agentowe scaffoldy dekompozycji problemu — narzucają z góry strategię, podczas gdy RLM oddaje decyzję o dekompozycji kontekstu samemu modelowi.

Kluczowe mechanizmy

Kontekst C przechowywany jako zmienna w środowisku REPL — model nigdy nie czyta go w całości naraz
Root LM (depth=0) widzi wyłącznie zapytanie q i interaguje z kontekstem przez generowanie kodu Pythona
Peek — odczyt pierwszych N znaków kontekstu w celu rozpoznania jego struktury
Grep / regex — zawężanie przestrzeni wyszukiwania przez wyszukiwanie wzorców w zmiennej kontekstu
Partition + Map — chunking kontekstu i równoległe (lub sekwencyjne) wywołania rekurencyjnych LM nad fragmentami
Summarization — kondensowanie podzbiorów kontekstu przez sub-call przed zwrotem do root LM
Rekurencyjne wywołania LM jako wywołania funkcji w REPL — sub-instance LLM (depth=1) zwraca wynik do środowiska wywołującego
Terminacja przez FINAL(answer) lub FINAL_VAR(var_name) — odpowiedź wprost lub z pamięci REPL
Kompatybilność drop-in — wywołanie RLM jest interfejsowo identyczne z wywołaniem LLM (te same wejście/wyjście)

Mocne strony i ograniczenia

Mocne strony
✓Obsługuje konteksty >10M tokenów bez dodatkowego treningu modelu bazowego — wystarczy wrapper inferencyjny
✓RLM(GPT-5-mini) przewyższa GPT-5 o ponad 114% na OOLONG (132k tokenów) przy porównywalnym koszcie zapytania
✓Na OOLONG (263k tokenów) RLM(GPT-5-mini) wciąż bije GPT-5 o ~49%
✓Na BrowseComp-Plus (1000 dokumentów) RLM(GPT-5) jako jedyna metoda utrzymuje bliską perfekcji dokładność
✓Generalny paradygmat — środowisko REPL może być zastąpione dowolnym innym środowiskiem (baza wektorowa, system plików)
✓Interpretowalne trajektorie — peek/grep/partition+map czytelne jako logi REPL, bez czarnej skrzynki latentów
✓RLM-Qwen3-8B (post-trening) przewyższa bazowy Qwen3-8B o 28,3% i zbliża się do GPT-5 na 3 zadaniach
✓Udoskonala się automatycznie wraz z modelem bazowym — mocniejszy LLM = mocniejszy RLM bez zmiany frameworka
✓Oficjalny kod open source na GitHub (alexzhang13/rlm, alexzhang13/rlm-minimal), licencja CC BY 4.0 dla papera
Ograniczenia
✗Referencyjna implementacja jest blokująca i bez prefix caching — każde zapytanie trwa od kilku sekund do kilku minut
✗Brak twardego budżetu kosztowego: max_iterations ogranicza kroki, ale outlier-query mogą zużywać znaczne API spend
✗Wykonanie dowolnego kodu Pythona przez REPL nad danymi użytkownika wymaga sandboxingu — ryzyko eksfiltracji lub side effects bez izolacji
✗Głębokość rekursji walidowana do 1; zachowanie przy depth>1 lub przy >4 agentach nie zostało systematycznie zbadane
✗Wydajność na BrowseComp-Plus oparta na 20 losowych zapytaniach — zbyt mała próba na pełne uogólnienie
✗Nie eliminuje context rot w samych sub-callach — rekurencyjne LLM nadal podlegają window limit przy przetwarzaniu chunków
✗Wymaga modelu bazowego zdolnego do generowania poprawnego kodu Pythona — słabsze modele mogą produkować wadliwy REPL kod
✗Strategie dekompozycji (peek, grep, partition+map) są emergentne i mogą być nieoptymalne dla konkretnych zadań

Komponenty

Root LMOrchestrator dekompozycji kontekstu

Główny model językowy (depth=0). Otrzymuje wyłącznie zapytanie q oraz informację o istnieniu kontekstu C w środowisku. Decyduje o strategii dekompozycji i emituje kod do REPL.

Oficjalna

Środowisko REPL (Python)Pamięć i mediator dostępu do kontekstu

Notebook Pythona (Jupyter-like) z kontekstem C załadowanym jako zmienna w pamięci. Pozwala root LM peek'ować, grepować, chunkować i wywoływać rekurencyjne LM jako wywołania funkcji.

Python REPL / JupyterWariant referencyjny z papera RLM.
Inne środowisko wykonawczeAutorzy zaznaczają, że wybór środowiska jest elastyczny — REPL to przykład, nie wymóg.

Oficjalna

Rekurencyjne wywołania LMWykonawcy podzapytań

Sub-instancje LLM (depth=1) wywoływane z REPL nad fragmentami lub przekształconym kontekstem. W referencyjnym setupie GPT-5 lub GPT-5-mini; głębokość ograniczona do 1.

Oficjalna

Tagi FINAL / FINAL_VARProtokół zwrotu odpowiedzi

Mechanizm terminacji: FINAL(answer) zwraca odpowiedź wprost; FINAL_VAR(var_name) zwraca zawartość zmiennej z pamięci REPL.

Implementacja

Implementacje referencyjne
alexzhang13/rlm
Python · Alex Zhang (MIT CSAIL)
Oficjalna
alexzhang13/rlm-minimal
Python · Alex Zhang
Oficjalna
Pułapki implementacyjne
Brak asynchronii w sub-callachWysoka

Referencyjna implementacja wykonuje każde rekurencyjne wywołanie LM blokująco i bez prefix caching, co rozciąga pojedyncze zapytanie z kilku sekund do kilku minut.

Rozwiązanie:Implementować pulę asynchronicznych workerów i prefix caching nad współdzielonymi prefiksami chunków.
Brak twardego budżetu kosztu/czasuŚrednia

Maks. liczba iteracji ogranicza długość, ale nie gwarantuje twardego limitu API spend ani wall-clock — outlier-query mogą być bardzo drogie.

Rozwiązanie:Dodać twarde watchdogi na sumaryczny koszt API i wall-clock per call.
Sandboxing kodu Python z REPLWysoka

REPL wykonuje dowolny kod generowany przez LM nad danymi użytkownika — bez izolacji to ryzyko bezpieczeństwa (eksfiltracja, side effects).

Rozwiązanie:Uruchamiać REPL w sandboxie (kontener, ograniczone uprawnienia sieci/dysku, allowlista bibliotek).

Ewolucja

Oryginalny paper · 2025 · arXiv preprint (MIT CSAIL) · Alex L. Zhang
Recursive Language Models
Alex L. Zhang, Tim Kraska, Omar Khattab
2025
Blog post Recursive Language Models
Punkt przełomowy

Październik 2025 — Alex Zhang publikuje koncept RLM na blogu MIT CSAIL wraz z pierwszymi wynikami na OOLONG i BrowseComp-Plus.

Recursive Language Models (blog) (artykuł)
2025
Preprint arXiv v1

31 grudnia 2025 — pierwsza wersja papera na arXiv (2512.24601).

Recursive Language Models (artykuł)
2026
Preprint arXiv v3 + RLM-Qwen3-8B
Punkt przełomowy

11 maja 2026 — wersja v3 z post-treningiem pierwszego modelu wyspecjalizowanego pod RLM: RLM-Qwen3-8B przewyższa bazowy Qwen3-8B o 28,3% i zbliża się do GPT-5 na trzech zadaniach long-context.

Recursive Language Models (v3) (artykuł)
Szczegóły techniczne

Hiperparametry (konfigurowalne osie)

Maksymalna głębokość rekursjiWysoka

Ile poziomów wywołań RLM jest dozwolonych. Referencyjna implementacja używa depth=1 (root + jeden poziom sub-call). Większa głębokość daje silniejsze systemy, ale zwiększa koszt.

Maks. liczba iteracji root LMWysoka

Limit kroków REPL wykonywanych przez root LM przed wymuszeniem terminacji. Kontroluje koszt i czas, ale nie gwarantuje twardego budżetu API.

Model dla wywołań rekurencyjnychKrytyczna

Który LLM obsługuje sub-calle (np. GPT-5-mini dla taniego dekompozytora pod GPT-5 root). Mocno wpływa na koszt i jakość.

Typ środowiskaWysoka

Co dokładnie jest dostępne dla root LM (REPL, baza wektorowa, system plików). Referencyjnie: Python REPL z kontekstem jako zmienną.

Złożoność obliczeniowa

Charakterystyki obliczeniowe
→Koszt na zapytanie: porównywalny z bezpośrednim wywołaniem GPT-5 (mediana — outlier-query mogą być droższe)
→Latencja: kilka sekund do kilku minut per zapytanie przy referencyjnej blokującej implementacji
→Skalowanie z głębokością: O(d × n) wywołań LLM dla głębokości d i n chunków na poziom — przy depth=1 liniowe w n
→RLM-Qwen3-8B: +28,3% nad bazowym Qwen3-8B na 3 zadaniach long-context (post-trening)
→OOLONG 132k: RLM(GPT-5-mini) +114% nad GPT-5 (raw score ponad dwukrotnie wyższy) przy zbliżonym koszcie
→OOLONG 263k: RLM(GPT-5-mini) +49% nad GPT-5; przy counting problems ujawnia się degradacja quality przy wzroście kontekstu
→BrowseComp-Plus: jedyna metoda utrzymująca bliską 100% dokładność przy 1000 dokumentach (~5k słów/doc, ~5M tokenów)
Uwagi do benchmarku

RLM ewaluowano na czterech zadaniach. (1) OOLONG trec_coarse: zapytania dystrybucyjne nad ~3000–6000 wpisami (konteksty 132k i 263k tokenów). RLM(GPT-5-mini) pobił GPT-5 o ~114% przy 132k i ~49% przy 263k; ablacja bez rekursji (sam REPL bez sub-callów) spada o ~10%. (2) BrowseComp-Plus: 20 losowo wybranych multi-hop zapytań nad korpusem dokumentów (10–1000 dok.). RLM(GPT-5) jedyną metodą utrzymującą bliską perfekcji dokładność przy 1000 dok. (3) Cztery benchmarki long-context (pełna wersja papera v3): mediana +26% vs compaction, +130% vs CodeAct sub-calls, +13% vs Claude Code. (4) RLM-Qwen3-8B (post-training): +28,3% nad bazowym Qwen3-8B, zbliżony do GPT-5 na 3 z 4 zadań. Ważna uwaga: wyniki BrowseComp-Plus opierają się na 20 zapytaniach — autorzy wprost zaznaczają wstępny charakter tych liczb.

Paradygmat wykonania

Tryb główny
conditional

Routing kontekstu jest emergentny — uczy się go z trajektorii lub jest improwizowany przez model w trakcie inferencji.

Wzorzec aktywacji
input_dependent
Mechanizm routingu

Root LM sam decyduje (przez generowanie kodu w REPL), które fragmenty kontekstu analizować i kiedy delegować do rekurencyjnego wywołania.

Równoległość

Poziom równoległości
partially_parallel

Rekurencyjne wywołania nad chunkami można uruchamiać równolegle (np. partition+map), ale referencyjna implementacja autorów jest blokująca (każde sub-call sekwencyjnie). Autorzy wskazują to jako duże low-hanging fruit do optymalizacji systemowej.

Zakres
inferenceacross_devices

Wymagania sprzętowe

Podstawowe

RLM to paradygmat inferencji nad istniejącymi LLM — niezależny od hardware'u modelu bazowego.