Aktie

Submit


Aktie

In diesem Artikel erfahren Sie, was rekursive Sprachmodelle sind, warum sie für die Argumentation mit langen Eingaben wichtig sind und wie sie sich von standardmäßigen Eingabeaufforderungs-, Abfrage- und Agentensystemen für lange Kontexte unterscheiden.

Zu den Themen, die wir behandeln werden, gehören:

• Warum ein langer Kontext allein die Argumentation über sehr große Eingaben nicht löst
• Wie rekursive Sprachmodelle eine externe Laufzeit und rekursive Unteraufrufe verwenden, um Informationen zu verarbeiten
• Die wichtigsten Kompromisse, Einschränkungen und praktischen Anwendungsfälle dieses Ansatzes

Kommen wir gleich zur Sache.

Einführung

Wenn Sie hier sind, haben Sie wahrscheinlich von neueren Arbeiten zu rekursiven Sprachmodellen gehört. Die Idee battle auf LinkedIn und Ich denke, wir sind uns alle einig, dass sich große Sprachmodelle (LLMs) in den letzten Jahren rasant verbessert haben, insbesondere hinsichtlich ihrer Fähigkeit, große Eingaben zu verarbeiten. Dieser Fortschritt hat viele Menschen zu der Annahme veranlasst, dass der lange Kontext ein weitgehend gelöstes Downside sei, aber das ist nicht der Fall. Wenn Sie versucht haben, Modellen sehr lange Eingaben nahe oder gleich ihrem Kontextfenster zu geben, ist Ihnen möglicherweise aufgefallen, dass sie weniger zuverlässig werden. Sie übersehen häufig Particulars in den bereitgestellten Informationen, widersprechen früheren Aussagen oder geben oberflächliche Antworten, anstatt sorgfältig zu argumentieren. Dieses Downside wird oft als bezeichnet „Kontextfäule“was ein recht interessanter Title ist.

Eine Antwort auf dieses Downside sind rekursive Sprachmodelle (RLMs). Anstatt immer mehr Textual content in einen einzigen Vorwärtsdurchlauf eines Sprachmodells zu schieben, ändern RLMs zunächst einmal die Artwork und Weise, wie das Modell mit langen Eingaben interagiert. In diesem Artikel werden wir uns damit befassen, was sie sind, wie sie funktionieren und welche Artwork von Problemen sie lösen sollen.

Warum ein langer Kontext nicht ausreicht

Sie können diesen Abschnitt überspringen, wenn Sie die Motivation aus der Einleitung bereits verstanden haben. Aber wenn Sie neugierig sind oder die Idee beim ersten Mal nicht ganz überzeugen konnte, lassen Sie mich sie weiter aufschlüsseln.

Die Funktionsweise dieser LLMs ist ziemlich einfach. Alles, was das Modell berücksichtigen soll, wird ihm als einzelne Eingabeaufforderung übermittelt, und basierend auf diesen Informationen generiert das Modell die Ausgabe Token für Token. Dies funktioniert intestine, wenn die Eingabeaufforderung kurz ist. Wenn es jedoch sehr lang wird, beginnt die Leistung nachzulassen. Dies ist nicht unbedingt auf Speicherbeschränkungen zurückzuführen. Selbst wenn das Modell die vollständige Eingabeaufforderung sehen kann, kann es diese häufig nicht effektiv nutzen. Hier sind einige Gründe, die zu diesem Verhalten beitragen können:

1. Bei diesen LLMs handelt es sich hauptsächlich um transformatorbasierte Modelle mit einem Aufmerksamkeitsmechanismus. Je länger die Aufforderung wird, desto diffuser wird die Aufmerksamkeit. Dem Modell fällt es schwer, sich klar auf das Wesentliche zu konzentrieren, wenn es Zehntausende oder Hunderttausende von Token verwalten muss.
2. Ein weiterer Grund ist das Vorhandensein heterogener Informationen wie Protokolle, Dokumente, Code, Chat-Verlauf und Zwischenausgaben.
3. Schließlich geht es bei vielen Aufgaben nicht nur darum, einen relevanten Ausschnitt aus einer riesigen Menge an Inhalten abzurufen oder zu finden. Dabei werden häufig Informationen über die gesamte Eingabe hinweg aggregiert.

Aufgrund der oben diskutierten Probleme wurden Ideen wie Zusammenfassung und Abruf vorgeschlagen. Diese Ansätze helfen zwar in manchen Fällen, sind aber keine universellen Lösungen. Zusammenfassungen sind von Natur aus verlustbehaftet und der Abruf geht davon aus, dass die Relevanz zuverlässig identifiziert werden kann, bevor mit der Argumentation begonnen wird. Viele Aufgaben in der realen Welt verstoßen gegen diese Annahmen. Aus diesem Grund schlagen RLMs einen anderen Ansatz vor. Anstatt das Modell zu zwingen, die gesamte Eingabeaufforderung auf einmal zu absorbieren, lassen sie das Modell die Eingabeaufforderung aktiv erkunden und verarbeiten. Nachdem wir nun den grundlegenden Hintergrund kennen, schauen wir uns genauer an, wie das funktioniert.

Wie ein rekursives Sprachmodell in der Praxis funktioniert

In einem RLM-Setup wird die Eingabeaufforderung als Teil der externen Umgebung behandelt. Dies bedeutet, dass das Modell nicht die gesamte Eingabe direkt liest. Stattdessen befindet sich die Eingabe außerhalb des Modells, oft als Variable, und das Modell erhält nur Metadaten über die Eingabeaufforderung sowie Anweisungen zum Zugriff darauf. Wenn das Modell Informationen benötigt, gibt es Befehle aus, um bestimmte Teile der Eingabeaufforderung zu untersuchen. Durch dieses einfache Design bleibt der interne Kontext des Modells klein und fokussiert, selbst wenn die zugrunde liegende Eingabe extrem groß ist. Um RLMs konkreter zu verstehen, gehen wir Schritt für Schritt eine typische Ausführung durch.

Schritt 1: Initialisieren einer persistenten REPL-Umgebung

Zu Beginn eines RLM-Laufs initialisiert das System eine Laufzeitumgebung, typischerweise eine Python REPL. Diese Umgebung enthält:

• Eine Variable, die die vollständige Benutzeraufforderung enthält und beliebig groß sein kann
• Eine Funktion (zum Beispiel llm_query(...) oder sub_RLM(...)), die es dem System ermöglicht, zusätzliche Sprachmodellaufrufe für ausgewählte Textteile aufzurufen

Aus der Sicht des Benutzers bleibt die Schnittstelle einfach, mit einer Texteingabe und einer Ausgabe, aber intern fungiert die REPL als Gerüst, das skalierbares Denken ermöglicht.

Schritt 2: Aufrufen des Root-Modells nur mit Immediate-Metadaten

Anschließend wird das Root-Sprachmodell aufgerufen, es erhält jedoch nicht die vollständige Eingabeaufforderung. Stattdessen heißt es:

• Metadaten mit konstanter Größe über die Eingabeaufforderung, z. B. ihre Länge oder ein kurzes Präfix
• Anweisungen, die die Aufgabe beschreiben
• Greifen Sie über die REPL-Umgebung auf Anweisungen zur Interaktion mit der Eingabeaufforderung zu

Durch das Zurückhalten der vollständigen Eingabeaufforderung zwingt das System das Modell dazu, absichtlich mit der Eingabe zu interagieren, anstatt sie passiv in das Kontextfenster aufzunehmen. Ab diesem Zeitpunkt interagiert das Modell indirekt mit der Eingabeaufforderung.

Schritt 3: Überprüfen und Zerlegen der Eingabeaufforderung durch Codeausführung

Das Modell könnte mit der Überprüfung der Struktur der Eingabe beginnen. Es kann beispielsweise die ersten paar Zeilen drucken, nach Überschriften suchen oder den Textual content anhand von Trennzeichen in Abschnitte aufteilen. Diese Vorgänge werden durch die Generierung von Code ausgeführt, der dann in der Umgebung ausgeführt wird. Die Ausgaben dieser Vorgänge werden gekürzt, bevor sie dem Modell angezeigt werden, um sicherzustellen, dass das Kontextfenster nicht überlastet wird.

Schritt 4: Rekursive Unteraufrufe für ausgewählte Slices ausgeben

Sobald das Modell die Struktur der Eingabeaufforderung versteht, kann es entscheiden, wie es vorgehen soll. Wenn die Aufgabe ein semantisches Verständnis bestimmter Abschnitte erfordert, kann das Modell Unterabfragen ausgeben. Jede Unterabfrage ist ein separater Sprachmodellaufruf für einen kleineren Teil der Eingabeaufforderung. Hier kommt eigentlich der „rekursive“ Teil ins Spiel. Das Modell zerlegt das Downside immer wieder, verarbeitet Teile der Eingabe und speichert Zwischenergebnisse. Diese Ergebnisse leben in der Umgebung, nicht im Kontext des Modells.

Schritt 5: Zusammenstellen und Zurücksenden der endgültigen Antwort

Nachdem genügend Informationen gesammelt und verarbeitet wurden, erstellt das Modell schließlich die endgültige Antwort. Wenn die Ausgabe lang ist:

• Das Modell baut es inkrementell innerhalb einer REPL-Variablen auf, z Ultimate
• Einmal Ultimate gesetzt ist, endet die RLM-Schleife
• Der Wert von Ultimate wird als Antwort zurückgegeben

Dieser Mechanismus ermöglicht es dem RLM, Ausgaben zu erzeugen, die die Token-Grenzwerte eines einzelnen Sprachmodellaufrufs überschreiten. Während dieses Prozesses muss kein einziger Sprachmodellaufruf jemals die vollständige Eingabeaufforderung sehen.

Was unterscheidet RLMs von Agenten und Abrufsystemen?

Wenn Sie Zeit im LLM-Bereich verbringen, verwechseln Sie diesen Ansatz möglicherweise mit Agenten-Frameworks oder Retrieval-Augmented Technology (RAG). Dies sind jedoch unterschiedliche Ideen, auch wenn die Unterschiede subtil erscheinen können.

In vielen Agentensystemen wird der gesamte Gesprächsverlauf oder Arbeitsspeicher wiederholt in den Kontext des Modells eingefügt. Wenn der Kontext zu groß wird, werden ältere Informationen zusammengefasst oder gelöscht. RLMs vermeiden dieses Muster vollständig, indem sie die Eingabeaufforderung von Anfang an extern halten. Im Gegensatz dazu verlassen sich Retrieval-Systeme darauf, eine kleine Menge relevanter Teile zu identifizieren, bevor mit der Argumentation begonnen wird. Dies funktioniert intestine, wenn die Relevanz gering ist. RLMs sind für Umgebungen konzipiert, in denen die Relevanz dicht und verteilt ist und eine Aggregation über viele Teile der Eingabe erforderlich ist. Ein weiterer wichtiger Unterschied ist die Rekursion. In RLMs ist Rekursion nicht metaphorisch. Das Modell ruft buchstäblich Sprachmodelle innerhalb von als Code generierten Schleifen auf, sodass die Arbeit auf kontrollierte Weise mit der Eingabegröße skaliert werden kann.

Kosten, Kompromisse und Einschränkungen

Es lohnt sich auch, einige Nachteile dieser Methode hervorzuheben. RLMs eliminieren keine Rechenkosten. Sie verschieben es. Anstatt für einen einzelnen, sehr großen Modellaufruf zu zahlen, zahlen Sie für viele kleinere, zusammen mit dem Mehraufwand für die Codeausführung und Orchestrierung. In vielen Fällen sind die Gesamtkosten vergleichbar mit einem Commonplace-Langkontextanruf, die Abweichung kann jedoch höher sein. Es gibt auch praktische Herausforderungen. Das Modell muss in der Lage sein, zuverlässigen Code zu schreiben. Schlecht eingeschränkte Modelle generieren möglicherweise zu viele Unteraufrufe oder werden nicht sauber beendet. Ausgabeprotokolle müssen sorgfältig entworfen werden, um Zwischenschritte von endgültigen Antworten zu unterscheiden. Dies sind technische Probleme, keine konzeptionellen Mängel, aber sie sind dennoch wichtig.

Fazit und Referenzen

Eine nützliche Faustregel lautet: Wenn Ihre Aufgabe allein deshalb schwieriger wird, weil die Eingabe länger ist, und wenn beim Zusammenfassen oder Abrufen wichtige Informationen verloren gehen, ist ein RLM wahrscheinlich eine Überlegung wert. Wenn die Eingabe kurz und die Aufgabe einfach ist, ist ein Aufruf eines Standardsprachenmodells normalerweise schneller und kostengünstiger. Wenn Sie sich eingehender mit rekursiven Sprachmodellen befassen möchten, sind die folgenden Ressourcen nützliche Ausgangspunkte:

Aktie

Submit


Aktie

der Kontext ist wirklich alles. Die Qualität der Ergebnisse eines LLM hängt eng mit der Qualität und Menge der von Ihnen bereitgestellten Informationen zusammen. In der Praxis sind viele reale Anwendungsfälle mit massiven Kontexten verbunden: Codegenerierung über große Codebasen, Abfragen komplexer Wissenssysteme oder sogar lange, mäandrierende Chats bei der Suche nach dem perfekten Urlaubsziel (das haben wir alle schon erlebt).

Leider können LLMs nur mit einer begrenzten Menge an Kontext effizient arbeiten. Dabei geht es nicht nur um die harten Grenzen des Kontextfensters, insbesondere jetzt, da Grenzmodelle Hunderttausende oder sogar Millionen von Token unterstützen. Und diese Grenzen wachsen immer weiter. Die größere Herausforderung ist ein Phänomen namens Kontextfäulewobei die Modellleistung mit zunehmender Kontextlänge abnimmt.

Dieser Effekt wird in der Arbeit deutlich gezeigt „RULER: Wie groß ist die tatsächliche Kontextgröße Ihrer Langkontext-Sprachmodelle?“ von Hsieh et al. Die Autoren stellen RULER vor, einen neuen Benchmark zur Bewertung der Langkontextleistung, und testen eine Reihe von Modellen. Die Ergebnisse zeigen ein konsistentes Muster: Mit zunehmender Kontextlänge sinkt die Leistung bei allen Modellen erheblich. In vielen Fällen beträgt die effektive Kontextlänge (wobei die Leistung mit Llama 2–7B vergleichbar bleibt) nur etwa 50 % des angekündigten Kontextfensters oder sogar weniger.

In ihrem jüngsten Artikel „Rekursive Sprachmodelle“, Zhang et al. Schlagen Sie einen vielversprechenden Ansatz zur Lösung des Kontextfäuleproblems vor. In diesem Artikel möchte ich mir diese Idee genauer ansehen und untersuchen, wie sie in der Praxis funktioniert, indem ich die kürzlich hinzugefügte Unterstützung von DSPy für diese Inferenzstrategie nutze.

Rekursive Sprachmodelle

Rekursive Sprachmodelle (RLMs) wurden eingeführt, um Leistungseinbußen bei zunehmender Kontextlänge entgegenzuwirken und es LLMs zu ermöglichen, mit sehr großen Kontexten zu arbeiten (bis zu zwei Größenordnungen über das native Kontextfenster des Modells hinaus). Dies wird immer wichtiger, da wir LLMs für Aufgaben einsetzen, bei denen Hunderte Millionen Token verarbeitet werden.

Für die Bewältigung langfristiger Aufgaben gibt es bereits mehrere Ansätze. Das häufigste Downside (etwas, das Ihnen wahrscheinlich bei der Verwendung von Code-Agenten wie Cursor begegnet ist) ist Kontextzusammenfassung. In diesem Setup wird der Gesprächs- oder Arbeitskontext wiederholt zusammengefasst, sobald er sich der Kontextgrenze des Modells nähert. In der Praxis greift dies jedoch oft zu kurz: Wichtige Particulars und subtile Nuancen aus früheren Schritten gehen tendenziell verloren, da das Modell alte Informationen „vergisst“, um Platz für neue Token zu schaffen.

Rekursive Sprachmodelle verfolgen einen anderen und überraschend eleganten Ansatz. Anstatt jedes Mal die gesamte Eingabeaufforderung an das LLM zu übergeben, wird die Eingabeaufforderung als eine Reihe von Variablen behandelt, die in einer Python-REPL-Umgebung (Learn-Eval-Print-Loop) verfügbar sind. Das Modell ist mit Werkzeugen ausgestattet, die es ihm ermöglichen, diese Variablen zu überprüfen oder sich selbst rekursiv auf programmgesteuert ausgewählten Fragmenten aufzurufen.

Mit anderen Worten: RLMs ermutigen das LLM, Code zu schreiben, der seine eigenen Unteraufgaben erstellt, und diese Unteraufgaben dann zu lösen, indem es sich selbst rekursiv aufruft. Dadurch verlagert sich die Final von der Aufgabe, alles in einer einzigen Eingabeaufforderung zusammenzufassen, hin zur Strukturierung des Issues, sodass das Modell zuverlässiger in großen Kontexten navigieren kann.

Die Autoren bewerteten ihren Ansatz anhand mehrerer Langzeitaufgaben, bei denen RLMs sowohl bei GPT-5- als auch bei Qwen-3-Modellen starke Ergebnisse lieferten.

Die Ergebnisse sehen äußerst vielversprechend aus. RLMs (mit oder ohne Unteraufrufe) übertreffen andere Ansätze bei allen Aufgaben durchweg. Mal sehen, wie das in der Praxis funktioniert.

RLM in der Praxis nutzen

Ein häufiges Szenario, in dem ein langer Kontext besonders intestine zur Geltung kommt, ist die Beantwortung von Fragen in einer großen Wissensdatenbank. Genau das werden wir hier versuchen. Ich habe alle Artikel, die ich auf In direction of Knowledge Science veröffentlicht habe, in eine einzige Markdown-Datei geladen. Überraschenderweise summiert sich das auf quick 1,5 MB Textual content. Hoffentlich reicht das für das Modell aus.

Glücklicherweise hat DSPy kürzlich eine Implementierung des Inferenzansatzes rekursiver Sprachmodelle eingeführt. Das bedeutet, dass wir nichts selbst bauen müssen; wir benötigen lediglich DSPy Model 3.1.2 oder neuer.

pip set up dspy --upgrade

Beginnen wir mit dem Laden des Datensatzes.

with open('articles.md', 'r') as f:
    articles = f.learn()

Als nächstes überprüfen wir, wie viele Token darin enthalten sind.

import anthropic

consumer = anthropic.Anthropic(api_key=config('ANTHROPIC_API_KEY'))

# Rely tokens for messages
token_count = consumer.messages.count_tokens(
  mannequin="claude-sonnet-4-5",
  messages=(
    {"position": "person", "content material": articles}
  )
)

print(f"Enter tokens: {token_count.input_tokens}")
# Enter tokens: 386768

In unserem Kontext gibt es quick 400.000 Token. Claude Sonnet 4.5 unterstützt ein 200-KByte-Kontextfenster, sodass die Verarbeitung des gesamten Datensatzes in einer einzigen Eingabeaufforderung nicht möglich ist. Genau hier kommt RLM zum Einsatz.

Um DSPy verwenden zu können, müssen wir zunächst das Sprachmodell konfigurieren. Wie bereits erwähnt, ist RLM für die Interaktion mit der Eingabeaufforderung auf Code angewiesen und funktioniert daher am besten mit Modellen, die über starke Codierungsfunktionen verfügen. Aus diesem Grund verwende ich in diesem Beispiel Claude, da es bekanntermaßen eine gute Leistung bei Code-bezogenen Aufgaben erbringt.

lm = dspy.LM('anthropic/claude-sonnet-4-5', api_key=config('ANTHROPIC_API_KEY'))
dspy.configure(lm=lm)

Als nächstes initialisieren wir das RLM, indem wir seine Signatur angeben. In diesem Anwendungsfall übergebe ich den gesamten Artikelsatz zusammen mit einer Frage und erwarte, dass das Modell wichtige Tendencies extrahiert und sie als Liste von Zeichenfolgen zurückgibt.

rlm = dspy.RLM('articles, query -> tendencies: record(str)')

Hier verwende ich Claude Sonnet 4.5 sowohl für das Hauptmodell als auch für die rekursiven Unteraufrufe. Mit DSPy können Sie auch ein kleineres Modell für Unteranrufe über verwenden sub_lm Parameter, der zur Kostensenkung beitragen kann.

Jetzt können wir das RLM ausführen und darauf zugreifen tendencies Feld in der Ausgabe.

output = rlm(
  articles = articles, 
  query = '''What have been the primary AI tendencies of 2025 primarily based on supplied 
    articles? Take note of the content material not solely the titles.'''
)

print('n'.be part of(output.tendencies))

# Agentic AI and Autonomous Techniques: Self-reflection patterns, iterative enchancment via suggestions loops (Self-Refine, Reflexion, CRITIC), and LLMs as reasoning engines that may autonomously plan and execute duties
# Multi-Agent AI Techniques: Evolution from single brokers to collaborative groups of specialised brokers with distinct roles, utilizing frameworks like LangGraph, CrewAI, and AutoGen for orchestration
# Context Engineering and RAG: Shifting past static prompting to dynamic retrieval-augmented era (RAG), adaptive reminiscence programs, and self-improving contexts that study from expertise with out retraining
# Standardization Protocols: Emergence of Mannequin Context Protocol (MCP) for standardizing LLM-tool integrations and Agent Communication Protocol (ACP) for inter-agent communication, lowering integration complexity
# Device-Utilizing LLMs and Operate Calling: LLMs geared up with capability to invoke exterior instruments, execute SQL queries, browse net, and work together with APIs via structured perform calling mechanisms
# Manufacturing-Prepared AI Frameworks: Mature ecosystem together with LangGraph, DSPy, LangChain, NeMo Agent Toolkit, CrewAI, and AutoGen, targeted on shifting from prototype to manufacturing with built-in observability
# LLM Analysis and Observability: LLM-as-judge analysis patterns, complete metrics frameworks (Ragas, DeepEval, Evidently), trajectory analysis, and steady monitoring as important manufacturing infrastructure
# Programming Over Prompting: Shift towards declarative, code-based AI growth with frameworks like DSPy and configuration-driven approaches (YAML-based) changing immediate engineering
# Framework Interoperability: Instruments designed to combine throughout a number of frameworks slightly than create silos, enabling composable AI architectures that leverage greatest options from completely different ecosystems
# Native and Price-Efficient LLM Deployment: Operating smaller environment friendly fashions domestically (Llama, Ollama) to cut back API prices and allow experimentation, with concentrate on cost-quality-latency tradeoffs
# SQL Brokers and Knowledge Evaluation Automation: LLM brokers specialised in information evaluation duties, producing and executing SQL queries, with functions in changing or augmenting conventional information analyst workflows
# Manufacturing High quality and Accuracy Enhancement: Strategies for bettering LLM accuracy together with chain-of-thought reasoning, structured outputs via perform calling, and iterative refinement for business-critical functions

Die Ausführung dauerte etwa drei Minuten und das Ergebnis battle eine überraschend believable Zusammenfassung der Hauptthemen meiner Artikel. Wir sind jedoch nicht hier, um etwas über die Tendencies selbst zu erfahren. Die interessantere Frage ist, wie RLM dies überhaupt geschafft hat. Additionally lasst uns tiefer graben.

RLM unter der Haube

Das Faszinierendste ist natürlich, zu verstehen, was tatsächlich unter der Haube passiert.

RLM-Implementierung

Wie bereits erwähnt, besteht die Schlüsselidee hinter rekursiven Sprachmodellen darin, dass lange Kontexte als Teil einer externen Umgebung behandelt werden und nicht als einzelne Eingabeaufforderung direkt in das Modell eingespeist werden. Stattdessen schreibt das LLM Python-Code, um Unter-LLMs über kleinere Datenausschnitte programmgesteuert zu prüfen, zu zerlegen und rekursiv aufzurufen.

Auf hoher Ebene weist die Implementierung einige Kernmerkmale auf:

• Es verwendet eine Sandbox-Python-REPL (Learn-Eval-Print-Schleife), die es dem LLM ermöglicht, große Kontexte durch Codeausführung zu erkunden.
• Das LLM arbeitet in einer bekannten Agentenschleife: Es schreibt Python-Code, beobachtet die Ausgabe und entscheidet dann, was als nächstes zu tun ist.
• Es kann mit Instruments wie rekursive Unteraufrufe ausführen (additionally sich selbst aufrufen). llm_query() Und llm_query_batched() um kleinere Blöcke semantisch zu analysieren.
• Sobald das Modell mit dem Ergebnis zufrieden ist, schließt es den Prozess durch einen Aufruf ab SUBMIT() mit der Ausgabe.

Aufforderungen

Um wirklich zu verstehen, wie das funktioniert, finde ich es hilfreich, die tatsächlichen Nachrichten zu untersuchen, die an und von der LLM gesendet werden. DSPy macht dies mit dem folgenden Befehl einfach.

# Examine the uncooked LLM calls - reveals the precise prompts despatched to the mannequin
dspy.inspect_history(n=39)

Dies gibt uns einen vollständigen Einblick in das, was bei jedem Schritt mit dem Modell geteilt wurde.

Beginnen wir mit der Systemmeldung. Es definiert die für das Modell verfügbaren Eingabevariablen (wie in der RLM-Signatur angegeben) und listet die Funktionen auf, die das Modell aufrufen kann, z printrekursive LLM-Aufrufe und Standardbibliotheksdienstprogramme.

Insbesondere können Sie mit dem RLM-Modul auch benutzerdefinierte Funktionen für die Python REPL verfügbar machen instruments Parameter bei der Initialisierung des RLM. In diesem Beispiel habe ich mich nur auf die Standardfunktionen verlassen, aber in fortgeschritteneren Setups kann dies ein leistungsstarker Erweiterungspunkt sein.

Your enter fields are:
1. `variables_info` (str): Metadata in regards to the variables out there within the REPL
2. `repl_history` (REPLHistory): Earlier REPL code executions and their outputs
3. `iteration` (str): Present iteration quantity (1-indexed) out of max_iterations
Your output fields are:
1. `reasoning` (str): Assume step-by-step: what have you learnt? What stays? Plan your subsequent motion.
2. `code` (str): Python code to execute.
All interactions might be structured within the following means, with the suitable values crammed in.

(( ## variables_info ## ))
{variables_info}

(( ## repl_history ## ))
{repl_history}

(( ## iteration ## ))
{iteration}

(( ## reasoning ## ))
{reasoning}

(( ## code ## ))
{code}

(( ## accomplished ## ))
In adhering to this construction, your goal is: 
Given the fields `articles`, `query`, produce the fields `tendencies`.
        
You might be tasked with producing the next outputs given the inputs `articles`, `query`:
- {tendencies}        # observe: the worth you produce should adhere to the JSON schema: {"kind": "array", "objects": {"kind": "string"}}
        
You've gotten entry to a Python REPL setting. Write Python code and it will likely be executed. You will notice the output, then write extra code primarily based on what you discovered. That is an iterative course of.

Out there:
- Variables: `articles`, `query` (your enter information)
- `llm_query(immediate)` - question a sub-LLM (~500K char capability) for semantic evaluation
- `llm_query_batched(prompts)` - question a number of prompts concurrently (a lot quicker for a number of queries)
- `print()` - ALWAYS print to see outcomes
- `SUBMIT(tendencies)` - submit remaining output when achieved
- Customary libraries: re, json, collections, math, and many others.
        
IMPORTANT: That is ITERATIVE. Every code block you write will execute, you may see the output, then you definitely determine what to do subsequent. Do NOT attempt to clear up every thing in a single step.
        
1. EXPLORE FIRST - Take a look at your information earlier than processing it. Print samples, test varieties/lengths, perceive the construction.
2. ITERATE - Write small code snippets, observe outputs, then determine subsequent steps. State persists between iterations.
3. VERIFY BEFORE SUBMITTING - If outcomes appear fallacious (zeros, empty, sudden), rethink your method.
4. USE llm_query FOR SEMANTICS - String matching finds WHERE issues are; llm_query understands WHAT issues imply.
5. MINIMIZE RETYPING (INPUTS & OUTPUTS) - When values are lengthy, exact, or error-prone (IDs, numbers, code, quotes), re-access them through variables and parse/compute in code as an alternative of retyping. Use small, focused prints to sanity-check, however keep away from guide copying when variables can carry the precise worth.
6. SUBMIT ONLY AFTER SEEING OUTPUTS - SUBMIT ends the present run instantly. If you must examine printed output, run it in a single step, evaluate the end result, then name SUBMIT in a later step.
        
You've gotten max 50 sub-LLM calls. When achieved, name SUBMIT() together with your output.

Schauen wir uns auch die erste Benutzernachricht an, die an das LLM gesendet wurde. Dadurch erhält das Modell einen Überblick über die Eingabevariablen: deren Typen, Längen (damit das Modell weiß, wie viel es auf einmal lesen kann) und eine Vorschau des Inhalts, um die Struktur zu verstehen.

(( ## variables_info ## ))
(1) «««
    Variable: `articles` (entry it in your code)
    Sort: str
    Whole size: 1,392,921 characters
    Preview:
    ```
    ---
    title: "Agentic AI from First Rules: Reflection"
    date: "2025-10-24T12:00:00-05:00"
    class: "Agentic AI"
    read_time: "21 min learn"
    url: "https://towardsdatascience.com/agentic-ai-from-first-principles-reflection/"
    ---
    
    Arthur C. Clarke's Third Regulation says that "*any sufficiently superior know-how is indistinguishable from magic*". That is precisely how lots of immediately's AI frameworks really feel. Instruments like GitHub Copilot, Claude Desktop, OpenAI Operator, and Perplexity Comet are automating everyda...
    ```
»»»
(2) «««
    Variable: `query` (entry it in your code)
    Sort: str
    Whole size: 114 characters
    Preview:
    ```
    What have been the primary AI tendencies of 2025 primarily based on supplied articles? Take note of the content material not solely the titles.
    ```
»»»
(3) «««
    Variable: `verbose` (entry it in your code)
    Sort: bool
    Whole size: 4 characters
    Preview:
    ```
    True
    ```
»»»

(( ## repl_history ## ))
You haven't interacted with the REPL setting but.

(( ## iteration ## ))
1/20

Reply with the corresponding output fields, beginning with the sphere `(( ## reasoning ## ))`, then `(( ## code ## ))`, after which ending with the marker for `(( ## accomplished ## ))`.

Hier ist die erste Antwort des Modells entsprechend dem in der Benutzernachricht angegebenen Format.

(( ## reasoning ## ))
I want to research articles to determine important AI tendencies of 2025. Let me begin by exploring the information:

1. First, I am going to study the construction and content material of the `articles` variable to grasp what I am working with
2. I am going to want to take a look at a number of articles, not simply titles, to grasp the precise content material
3. Then I am going to use semantic evaluation (llm_query) to extract and determine tendencies
4. Lastly, I am going to compile the tendencies into a listing

Let me begin by exploring the articles information to see its construction and get a way of what is out there.

(( ## code ## ))
# First, let's perceive the construction of the articles
print("Sort of articles:", kind(articles))
print("nLength of articles:", len(articles))
print("n" + "="*80)
print("First 2000 characters:")
print(articles(:2000))
print("n" + "="*80)

# Let's examine if we will determine the construction - seems like articles are separated
# Let's attempt to break up and depend them
article_separator = "---ntitle:"
article_parts = articles.break up(article_separator)
print(f"nNumber of article elements discovered: {len(article_parts)}")
print(f"First half size: {len(article_parts(0))} (probably empty or header)")
print(f"Second half size: {len(article_parts(1)) if len(article_parts) > 1 else 0}")

(( ## accomplished ## ))

Die Rohprotokolle gaben uns ein solides Verständnis dafür, wie das LLM mit der Umgebung unter der Haube interagiert. Als nächstes untersuchen wir die Flugbahn, die das LLM verfolgte, um seine endgültige Ausgabe zu erreichen.

Flugbahn

Für eine strukturierte Sicht auf die Flugbahn können wir inspizieren output.trajectory. Dies ermöglicht den Zugriff auf jeden Schritt der Modellbegründung, den von ihm generierten Code und die resultierenden Ausgaben. Im Wesentlichen bietet es einen umfassenden Überblick über alle REPL-Interaktionen.

# Look at the total trajectory - this reveals all REPL interactions
for i, step in enumerate(output.trajectory):
  print(f"n{'='*60}")
  print(f"STEP {i+1}")
  print(f"{'='*60}")
  print(f"n REASONING:n{step('reasoning')}")
  print(f"n CODE:n{step('code')}")
  print(f"n OUTPUT:n{step('output')(:1000)}{'...' if len(step('output')) > 1000 else ''}")

Dort finden Sie auch die vollständige Anmeldung GitHub.

Die Überprüfung der Flugbahn hilft uns, die Hauptmuster zu verstehen, die das LLM zur Lösung des Issues verwendet. In diesem Fall waren 13 Schritte erforderlich, um zur endgültigen Antwort zu gelangen.

Der erste Schritt bestand erwartungsgemäß darin, das zu erkunden articles Variable: Untersuchung ihrer Struktur und Gewinnung eines Gefühls für die verfügbaren Daten. Diese erste Erkundung bildet die Grundlage für alle nachfolgenden Überlegungen und Unteraufrufe.

# First, let's perceive the construction of the articles
print("Sort of articles:", kind(articles))
print("nLength of articles:", len(articles))
print("n" + "="*80)
print("First 2000 characters:")
print(articles(:2000))
print("n" + "="*80)

# Let's examine if we will determine the construction - seems like articles are separated
# Let's attempt to break up and depend them
article_separator = "---ntitle:"
article_parts = articles.break up(article_separator)
print(f"nNumber of article elements discovered: {len(article_parts)}")
print(f"First half size: {len(article_parts(0))} (probably empty or header)")
print(f"Second half size: {len(article_parts(1)) if len(article_parts) > 1 else 0}")

Als nächstes stellte das LLM fest, dass es insgesamt 40 Artikel gab, die jeweils durch getrennt waren ---ntitle:und dass jeder Artikel Metadatenfelder wie enthielt title, date, class, read_timeUnd urlgefolgt vom Hauptinhalt. Allein die Identifizierung dieser Struktur anhand einer 1,5 MB großen Textdatei ist bereits eine bedeutende Leistung.

Aufbauend auf diesem Verständnis analysierte das LLM dann die Artikel und erstellte eine Zusammenfassung der Artikeltitel und Hauptthemen.

# Parse articles into structured format
import re

# Cut up by the article separator
raw_articles = articles.break up("---ntitle:")

# Course of every article (skip the primary empty aspect)
parsed_articles = ()
for i, raw_article in enumerate(raw_articles(1:), 1):  # Skip first empty aspect
  # Add again the "title:" that was eliminated by break up
  raw_article = "title:" + raw_article
  
  # Extract metadata utilizing regex
  title_match = re.search(r'title:s*"((^")*)"', raw_article)
  date_match = re.search(r'date:s*"((^")*)"', raw_article)
  category_match = re.search(r'class:s*"((^")*)"', raw_article)
  
  # Discover the place content material begins (after the second "---")
  content_start = raw_article.discover("---", 10)  # Skip the primary half
  content material = raw_article(content_start+3:).strip() if content_start != -1 else ""
  
  parsed_articles.append({
    'index': i,
    'title': title_match.group(1) if title_match else "Unknown",
    'date': date_match.group(1) if date_match else "Unknown",
    'class': category_match.group(1) if category_match else "Unknown",
    'content material': content material,
    'content_length': len(content material)
  })

print(f"Efficiently parsed {len(parsed_articles)} articlesn")
print("="*80)
print("Pattern of articles (titles and classes):")
print("="*80)
for i, article in enumerate(parsed_articles(:10), 1):
  print(f"{i}. ({article('class')}) {article('title')}")
  print(f"   Content material size: {article('content_length')} chars")
  print()

Nach der Analyse der Artikel entschied sich das LLM, sich ausschließlich auf KI-bezogene Inhalte zu konzentrieren, da es sich bei der Frage speziell um KI-Tendencies handelte.

# Let's concentrate on AI-related articles (AI, Agentic AI, LLM Purposes, ChatGPT classes)
# and pattern strategically to grasp content-based tendencies

ai_related = (a for a in parsed_articles if a('class') in (
  'Synthetic Intelligence', 'Agentic AI', 'LLM Purposes', 'ChatGPT', 'Deep Studying'
))

Als nächstes identifizierte das LLM die Schlüsselartikel, auf die es sich konzentrieren wollte. Es handelte sich um eine subjektive Auswahl nach Relevanz und Inhalt. Um diese im Element zu analysieren, wurden rekursive Unteraufrufe verwendet, wobei jeder Artikel programmgesteuert verarbeitet wurde.

Um die Arbeitsbelastung effizient zu bewältigen, teilte das LLM die Artikel in zwei Chargen auf und verarbeitete sie nacheinander. Für jeden Artikel wurde außerdem der Inhalt auf die ersten 15.000 Zeichen gekürzt. Diese Strategie ermöglichte es dem Modell, eine große Textmenge zu verarbeiten, ohne sein Kontextfenster zu überschreiten, und gleichzeitig die wichtigsten Erkenntnisse aus jedem Artikel zu erfassen.

# Create prompts to extract AI tendencies from article content material
# I am going to embody a considerable portion of every article's content material for evaluation

prompts_batch1 = ()

for i, article in enumerate(selected_for_analysis(:8)):  # First batch of 8
  # Take first ~15K chars of content material to remain inside LLM limits whereas getting substance
  content_sample = article('content material')(:15000)
  
  immediate = f"""Analyze this text about AI from 2025 and determine the primary AI tendencies, applied sciences, methodologies, or ideas it discusses.

Article Title: {article('title')}

Article Content material (excerpt):
{content_sample}

Primarily based on the content material above, record the important thing AI tendencies, applied sciences, or ideas mentioned on this article. Concentrate on:
- New frameworks, instruments, or methodologies talked about
- Rising patterns in AI growth (e.g., agentic AI, multi-agent programs)
- Vital methods or approaches
- Manufacturing/deployment issues

Present a concise record of 3-5 important tendencies/ideas from this text."""

  prompts_batch1.append(immediate)

print(f"Created {len(prompts_batch1)} prompts for first batch")
print("nProcessing first batch of articles...")

# Question the primary batch
results_batch1 = llm_query_batched(prompts_batch1)

print(f"nReceived {len(results_batch1)} outcomes")
print("nResults from first batch:")
print("="*80)

for i, (article, end result) in enumerate(zip(selected_for_analysis(:8), results_batch1), 1):
  print(f"n{i}. {article('title')}")
  print("-"*80)
  print(end result)
  print()

Abschließend überprüfte das LLM noch einmal die vollständige Liste der Artikel, identifizierte weitere relevante Themen und verarbeitete diese mithilfe rekursiver Unteraufrufe auf die gleiche Weise. Nachdem alle Informationen abgerufen worden waren, wurden die Ergebnisse zusammengefasst trends_2025 Variable (eine Liste von Zeichenfolgen, die die wichtigsten KI-Tendencies darstellen) und übermittelte sie als endgültige Antwort.

##### STEP 12 #####

# Now let me synthesize all findings into complete AI tendencies
# I am going to evaluate all the outcomes and create a structured abstract

print("SYNTHESIZING ALL FINDINGS FROM 20 ANALYZED ARTICLES")
print("="*80)
print("nBased on deep content material evaluation of 20 AI-focused articles from 2025,")
print("listed here are the primary AI tendencies recognized:n")

# Compile the excellent record of tendencies
trends_2025 = (
  "Agentic AI and Autonomous Techniques: Self-reflection patterns, iterative enchancment via suggestions loops (Self-Refine, Reflexion, CRITIC), and LLMs as reasoning engines that may autonomously plan and execute duties",
  "Multi-Agent AI Techniques: Evolution from single brokers to collaborative groups of specialised brokers with distinct roles, utilizing frameworks like LangGraph, CrewAI, and AutoGen for orchestration",
  "Context Engineering and RAG: Shifting past static prompting to dynamic retrieval-augmented era (RAG), adaptive reminiscence programs, and self-improving contexts that study from expertise with out retraining",
  "Standardization Protocols: Emergence of Mannequin Context Protocol (MCP) for standardizing LLM-tool integrations and Agent Communication Protocol (ACP) for inter-agent communication, lowering integration complexity",
  "Device-Utilizing LLMs and Operate Calling: LLMs geared up with capability to invoke exterior instruments, execute SQL queries, browse net, and work together with APIs via structured perform calling mechanisms",
  "Manufacturing-Prepared AI Frameworks: Mature ecosystem together with LangGraph, DSPy, LangChain, NeMo Agent Toolkit, CrewAI, and AutoGen, targeted on shifting from prototype to manufacturing with built-in observability",
  "LLM Analysis and Observability: LLM-as-judge analysis patterns, complete metrics frameworks (Ragas, DeepEval, Evidently), trajectory analysis, and steady monitoring as important manufacturing infrastructure",
  "Programming Over Prompting: Shift towards declarative, code-based AI growth with frameworks like DSPy and configuration-driven approaches (YAML-based) changing immediate engineering",
  "Framework Interoperability: Instruments designed to combine throughout a number of frameworks slightly than create silos, enabling composable AI architectures that leverage greatest options from completely different ecosystems",
  "Native and Price-Efficient LLM Deployment: Operating smaller environment friendly fashions domestically (Llama, Ollama) to cut back API prices and allow experimentation, with concentrate on cost-quality-latency tradeoffs",
  "SQL Brokers and Knowledge Evaluation Automation: LLM brokers specialised in information evaluation duties, producing and executing SQL queries, with functions in changing or augmenting conventional information analyst workflows",
  "Manufacturing High quality and Accuracy Enhancement: Strategies for bettering LLM accuracy together with chain-of-thought reasoning, structured outputs via perform calling, and iterative refinement for business-critical functions"
)

print("MAIN AI TRENDS OF 2025:")
print("="*80)
for i, pattern in enumerate(trends_2025, 1):
  print(f"n{i}. {pattern}")

print("n" + "="*80)
print(f"nTotal tendencies recognized: {len(trends_2025)}")
print("nThese tendencies are primarily based on content material evaluation of articles masking:")
print("- Agentic AI programs and design patterns")
print("- Multi-agent architectures and frameworks")
print("- Manufacturing deployment and analysis")
print("- Rising protocols and standardization")
print("- Device use and exterior system integration")
print("- Price-effective and correct LLM functions")

##### STEP 13 #####

# Submit the ultimate record of AI tendencies from 2025
SUBMIT(trends_2025)

Wir können sehen, dass das Modell ziemlich kreativ battle: Es verstand die Struktur unseres Inhalts, analysierte die Artikel und verwendete rekursive Aufrufe, um jeden einzelnen Artikel einzeln zu verarbeiten. Allerdings gab es in dieser Analyse eine wesentliche Lücke. Die Filterung nach Jahr wurde völlig übersehen, obwohl die Metadaten für jeden Artikel eindeutig das Veröffentlichungsdatum enthielten.

Um dieses Downside anzugehen, wiederholte ich die Anfrage und betonte diesmal die Wichtigkeit der Filterung für 2025, um sicherzustellen, dass sich das Modell nur auf Artikel aus diesem Jahr konzentriert.

output2 = rlm(
  articles = articles, 
  query = '''What have been the primary AI tendencies of 2025 primarily based on supplied 
    articles? Take note of the content material not solely the titles. 
    Remember to filter by yr, this data is current in 
    metadata for every article.'''
)

Dieses Mal berücksichtigte das Modell das Jahr und führte eine anspruchsvollere Analyse durch, indem es reguläre Ausdrücke verwendete, um das Veröffentlichungsdatum für jeden Artikel zu extrahieren.

import re
from datetime import datetime

# Cut up articles by the separator "---" firstly of metadata blocks
# The sample is: --- adopted by metadata, adopted by --- adopted by content material
article_blocks = re.break up(r'n---n', articles)

print(f"Whole article blocks discovered: {len(article_blocks)}")
print("n" + "="*80)

# Let's study the construction - articles appear to begin with "---ntitle:"
# Let me strive a distinct method - discover all articles by their metadata sample
article_pattern = r'---ntitle: "(.*?)"ndate: "(.*?)"ncategory: "(.*?)"nread_time: "(.*?)"nurl: "(.*?)"n---n(.*?)(?=n---ntitle:|$)'

matches = re.findall(article_pattern, articles, re.DOTALL)
print(f"Articles discovered with regex: {len(matches)}")

if len(matches) > 0:
  print("nFirst article metadata:")
  print(f"  Title: {matches(0)(0)}")
  print(f"  Date: {matches(0)(1)}")
  print(f"  Class: {matches(0)(2)}")
  print(f"  Content material preview (first 200 chars): {matches(0)(5)(:200)}")

Anschließend wurden die Artikel nach Jahr gefiltert und 13 Artikel aus dem Jahr 2025 identifiziert.

# Parse articles and filter for 2025
articles_2025 = ()

for match in matches:
  title, date_str, class, read_time, url, content material = match
  # Extract yr from date string (format: "2025-10-24T12:00:00-05:00")
  yr = date_str.break up('-')(0)
  
  if yr == "2025":
    articles_2025.append({
      'title': title,
      'date': date_str,
      'class': class,
      'content material': content material.strip()
    })

print(f"Whole articles: {len(matches)}")
print(f"Articles from 2025: {len(articles_2025)}")
print("n" + "="*80)
print("2025 Articles:")
print("="*80)

for i, article in enumerate(articles_2025, 1):
  print(f"n{i}. {article('title')}")
  print(f"   Date: {article('date')}")
  print(f"   Class: {article('class')}")
  print(f"   Content material size: {len(article('content material'))} chars")

Anschließend wurden diese 13 Artikel mithilfe rekursiver Unteraufrufe analysiert und eine aktualisierte Liste von Tendencies erstellt. Diesmal wurde die Aufgabe korrekt erledigt. Wie bei vielen anderen Beispielen wird auch hier hervorgehoben, wie wichtig es ist, klare, explizite Fragen zu stellen und die Kriterien und Aktionen anzugeben, denen das Modell folgen soll.

Agentic AI and Multi-Agent Techniques: Constructing autonomous AI brokers able to multi-step reasoning, software use, planning, and reflection, usually with a number of specialised brokers collaborating on complicated duties
Code Brokers: AI brokers that execute software calls utilizing precise code (Python) as an alternative of JSON-based software calling, enabling dynamic perform creation and reaching greater success charges with fewer steps
Mannequin Context Protocol (MCP): Anthropic's standardization protocol for connecting AI functions to exterior instruments and information sources, lowering integration complexity from M*N to M+N and enabling reusable, framework-agnostic parts
Agent Communication Protocol (ACP): Rising open protocol below the Linux Basis for standardizing communication between AI brokers through RESTful APIs, enabling interoperability throughout completely different frameworks
Reflection and Self-Refinement Patterns: LLMs reviewing and bettering their very own outputs via iterative suggestions loops, together with self-feedback, verbal reinforcement studying, and tool-interactive critiquing, reaching 10-30% accuracy enhancements
Framework Ecosystem Proliferation: A number of competing frameworks together with LangGraph, smolagents, CrewAI, DSPy, and NeMo Agent Toolkit, with rising emphasis on interoperability and declarative configuration approaches
Manufacturing-Prepared LLM Infrastructure: Shifting past prototypes to handle 'day 2' issues like API publicity, observability, monitoring, analysis frameworks, and deployment at scale
Parameter-Environment friendly Effective-Tuning (PEFT) and LoRA: Strategies for customizing LLMs by updating solely small subsets of parameters, enabling task-specific optimization whereas lowering computational prices and enabling on-premises deployment
Superior Effective-Tuning with Reminiscence Consultants: Lamini's Combination of Reminiscence Consultants (MoME) utilizing ~1 million LoRA adapters for near-perfect factual accuracy (95%) with zero loss on particular data
Shift from Prompting to Programming Paradigm: Frameworks like DSPy treating LLM duties as modular programming slightly than guide immediate crafting, with structured signatures and reusable parts
LLM Analysis and High quality Assurance: Complete analysis frameworks (Evidently, DeepEval, MLFlow, LangSmith) for testing, monitoring, and guaranteeing reliability in manufacturing, particularly for regulated industries
RAG (Retrieval-Augmented Era): Offering related context and data bases to boost LLM precision and allow specialised capabilities in brokers
Device Use and Orchestration: AI programs dynamically choosing and executing instruments from a number of sources, with standardized software definitions and security controls
YAML-Primarily based Declarative Configuration: Defining LLM workflows, fashions, and agent habits via configuration recordsdata slightly than purely code-based implementations
Interpretable AI and Rule-Primarily based Techniques: Utilizing choice timber, extracted guidelines, and clear fashions as alternate options to black-box approaches for compliance, explainability, and speedy deployment in regulated industries

Zusammenfassung

Es ist Zeit, die Dinge zusammenzufassen und über das Gelernte nachzudenken. In diesem Artikel haben wir RLM (Recursive Language Fashions) untersucht – eine neue Inferenzstrategie, die es LLMs ermöglicht, Kontexte zu verarbeiten, die bis zu zwei Größenordnungen größer als ihr Standardkontextfenster sind, und gleichzeitig das Downside der Kontextverrottung zu mildern.

Ich bin wirklich fasziniert von diesem Ansatz. Der Artikel schlägt eine einfache, aber elegante Methode zur Behandlung von Eingabeaufforderungen als Variablen in einer Python-Umgebung vor, die mich an mein bevorzugtes Agenten-Framework erinnert: Smolagenzien von HuggingFace. Ich glaube, dass diese Methode besonders effizient ist, weil LLMs auf so viel Code trainiert wurden, dass sich das Programmieren für sie wie eine Muttersprache anfühlt. Die Verwendung von Code als Schnittstelle für Argumentation und Rekursion ist sowohl praktisch als auch leistungsstark.

Insgesamt bieten rekursive Sprachmodelle eine praktische und elegante Möglichkeit, die Grenzen der Kontextlänge zu überschreiten und LLMs in der Lage zu machen, komplexe, umfangreiche Aufgaben zu bewältigen. Klare Anweisungen und eine durchdachte Anleitung sind jedoch nach wie vor der Schlüssel zum Erzielen der besten Ergebnisse.

Vielen Dank fürs Lesen. Ich hoffe, dieser Artikel battle aufschlussreich. Erinnern Sie sich an Einsteins Rat: „Wichtig ist, nicht mit dem Hinterfragen aufzuhören. Neugier hat ihre eigene Daseinsberechtigung.“ Möge Ihre Neugier Sie zu Ihrer nächsten großen Erkenntnis führen.

Referenz

Dieser Artikel basiert auf dem Artikel von Zhang et al., „Rekursive Sprachmodelle“veröffentlicht am 31. Dezember 2025.

Große Sprachmodelle sind großartig. Dem können wir alle zustimmen. Sie sind ein Eckpfeiler der modernen Industrie und wirken sich zunehmend auf immer mehr Bereiche aus.

Angesichts der ständigen Aktualisierungen und Verbesserungen der Architektur und Fähigkeiten von Sprachmodellen könnte man denken: „Das ist es!“ Leider … Eine aktuelle Entwicklung unter dem Namen RLM oder rekursive Sprachmodelle steht jetzt im Mittelpunkt.

Was ist das? Wie hängt es mit LLMs zusammen? Und wie verschiebt es die Grenzen der KI? Wir werden es in diesem Artikel herausfinden, der diese neueste Technologie auf verständliche Weise analysiert. Beginnen wir damit, die Probleme durchzugehen, die aktuelle LLMs plagen.

Ein grundsätzliches Downside

LLMs haben eine architektonische Grenze. Es heißt Token-Fenster. Dies ist die maximale Anzahl an Token, die das Modell in einem Vorwärtsdurchlauf physisch lesen kann, bestimmt durch die Positionseinbettungen + den Speicher des Transformators. Wenn die Eingabe länger als diese Grenze ist, kann das Modell sie nicht verarbeiten. Es ist, als würde man versuchen, eine 5-GB-Datei in ein 500-MB-RAM-Programm zu laden. Es führt zu einem Überlauf! Hier sind die Token-Fenster einiger beliebter Modelle:

Normalerweise gilt: Je größer die Zahl, desto besser das Modell … Oder doch?

Kontextfäule: Der versteckte Fehler vor dem Restrict

Hier ist der Haken. Selbst wenn eine Eingabeaufforderung in das Token-Fenster passt, nimmt die Modellqualität mit zunehmender Länge der Eingabe stillschweigend ab. Die Aufmerksamkeit wird diffus, frühere Informationen verlieren an Einfluss und das Modell beginnt, Verbindungen über entfernte Textteile hinweg zu übersehen. Dieses Phänomen ist bekannt als Kontextfäule.

Obwohl ein Modell technisch gesehen 1 Million Token akzeptieren kann, ist dies oft nicht möglich Grund zuverlässig in allen Bereichen. In der Praxis bricht die Leistung lange vor Erreichen des Token-Fensters ein.

Kontextfenster

Kontextfenster ist wie viele Informationen das Modell tatsächlich nutzen kann, lange bevor die Leistung einbricht. Diese Zahl ändert sich je nach Komplexität der Eingabeaufforderung und der Artwork der verarbeiteten Daten. Der wirksam Das Kontextfenster eines LLM ist viel kleiner als das Tokenfenster. Und im Gegensatz zum Token-Fenster, das mehr oder weniger eindeutig ist, ändert sich das Kontextfenster mit der Komplexität der Eingabeaufforderung. Dies zeigt sich an der schlechten Leistung von LLMs mit großen Tokenfenstern bei Argumentationsaufgaben, da quick alle gleichzeitig zugeführten Informationen beibehalten werden müssen.

Das ist ein Downside. Lange Kontextfenster und folglich Token-Fenster sind wünschenswert, aber ein Kontextverlust (aufgrund ihrer Länge) ist unvermeidbar … oder zumindest so Conflict.

Rekursive Sprachmodelle: Zur Rettung

Trotz des Namens handelt es sich bei RLMs nicht um eine neue Modellklasse wie LLM. VLMSLM usw. Stattdessen ist es ein Inferenzstrategie. Eine Lösung für das Downside der Kontextfäule in langen Eingabeaufforderungen. RLMs behandeln lange Eingabeaufforderungen als Teil einer externen Umgebung und ermöglichen dies LLM um sich über Ausschnitte der Eingabeaufforderung programmgesteuert zu untersuchen, zu zerlegen und rekursiv aufzurufen.

Dadurch wird das Kontextfenster effektiv um ein Vielfaches größer als üblich. Dies geschieht auf ähnliche Weise:

Konzeptionell bietet RLM einen externen LLM-Speicher und eine Möglichkeit, damit zu arbeiten. So funktioniert es:

1. Die Eingabeaufforderung wird in eine Variable geladen.
2. Diese Variable wird abhängig vom Speicher oder einer fest codierten Zahl gespleißt.
3. Diese Daten werden an das LLM gesendet und ihre Ausgabe wird als Referenz gespeichert.
4. Ebenso werden alle Teile der Eingabeaufforderung einzeln verarbeitet und ihre Ausgaben aufgezeichnet.
5. Diese Liste von Ausgaben wird verwendet, um die endgültige Antwort des Modells zu erzeugen.

Ein Untermodell wie o3-mini oder ein anderes praktisches Modell könnte verwendet werden, um das Modell bei der Zusammenfassung oder Begründung lokal in einer Untereingabeaufforderung zu unterstützen.

Ist das nicht… Chunking?

Auf den ersten Blick magazine das wie verherrlichtes Chunking aussehen. Aber es ist grundlegend anders. Beim herkömmlichen Chunking wird das Modell dazu gezwungen, frühere Teile zu vergessen, während es sich vorwärts bewegt. RLM hält alles außerhalb des Modells am Leben und ermöglicht es dem LLM, jedes Teil bei Bedarf selektiv erneut aufzurufen. Es geht nicht darum, die Erinnerung zusammenzufassen, sondern darin zu navigieren.

Welche Probleme RLM endlich löst

RLM macht Dinge frei, an denen normale LLMs regelmäßig scheitern:

• Argumentation zu massiven Daten: Anstatt frühere Teile zu vergessen, kann das Modell jeden Abschnitt großer Eingaben erneut aufrufen.
• Synthese mehrerer Dokumente: Es zieht Beweise aus verstreuten Quellen, ohne an Kontextgrenzen zu stoßen.
• Informationsreiche Aufgaben: Funktioniert auch dann, wenn die Antworten von quick jeder Zeile der Eingabe abhängen.
• Lange strukturierte Ausgaben: Erstellt Ergebnisse außerhalb des Token-Fensters und fügt sie sauber zusammen.

Kurz gesagt: Mit RLM können LLMs Skalierung, Dichte und Struktur verwalten, die herkömmliche Eingabeaufforderungen übertreffen.

Die Kompromisse

Bei allem, was RLM löst, gibt es auch ein paar Nachteile:

Kurz gesagt: RLM tauscht pure Geschwindigkeit und Stabilität gegen Skalierbarkeit und Tiefe.

Abschluss

Skalierende LLMs bedeuteten früher mehr Parameter und größere Token-Fenster. RLM führt eine dritte Achse ein: die Inferenzstruktur. Anstatt größere Gehirne aufzubauen, bringen wir Modellen bei, wie sie das Gedächtnis außerhalb ihres Gehirns nutzen können – genau wie Menschen.

Es ist eine ganzheitliche Sichtweise. Es ist nicht mehr das, was vorher battle, wie üblich. Eher eine Neuinterpretation der herkömmlichen Ansätze des Modellbetriebs.

Häufig gestellte Fragen

Rekursive Sprachmodelle Ziel ist es, den üblichen Kompromiss zwischen Kontextlänge, Genauigkeit und Kosten in großen Sprachmodellen zu durchbrechen. Anstatt ein Modell zu zwingen, eine riesige Eingabeaufforderung in einem Durchgang zu lesen, behandeln RLMs die Eingabeaufforderung als externe Umgebung und lassen das Modell entscheiden, wie es sie mit Code überprüft, und rufen sich dann rekursiv für kleinere Teile auf.

Die Grundlagen

Die vollständige Eingabe wird als einzelne String-Variable in eine Python-REPL geladen. Das Root-Modell, zum Beispiel GPT-5, sieht diese Zeichenfolge nie direkt in ihrem Kontext. Stattdessen erhält es eine Systemaufforderung, die erklärt, wie Slices der Variablen gelesen, Hilfsfunktionen geschrieben, Sub-LLM-Aufrufe erzeugt und Ergebnisse kombiniert werden. Das Modell gibt eine abschließende Textantwort zurück, sodass die externe Schnittstelle mit einem Customary-Chat-Abschlussendpunkt identisch bleibt.

Das RLM-Design verwendet die REPL als Steuerebene für langen Kontext. Die normalerweise in Python geschriebene Umgebung stellt Instruments wie String-Slicing, Regex-Suche und Hilfsfunktionen wie bereit llm_query die eine kleinere Modellinstanz aufrufen, zum Beispiel GPT-5-mini. Das Root-Modell schreibt Code, der diese Helfer aufruft, um die externe Kontextvariable zu scannen, zu partitionieren und zusammenzufassen. Der Code kann Zwischenergebnisse in Variablen speichern und die endgültige Antwort Schritt für Schritt aufbauen. Diese Struktur macht die Eingabeaufforderungsgröße unabhängig vom Modellkontextfenster und macht die Handhabung langer Kontexte zu einem Downside bei der Programmsynthese.

Wo steht es in der Bewertung?

Der Forschungsarbeit bewertet diese Idee anhand von vier langen Kontext-Benchmarks mit unterschiedlicher Rechenstruktur. S-NIAH ist eine Nadel im Heuhaufen mit konstanter Komplexität. BrowseComp-Plus ist ein Multi-Hop-Benchmark für Fragen und Antworten im Internet-Stil für bis zu 1.000 Dokumente. OOLONG ist eine lineare Komplexitätsaufgabe mit langem Kontextschluss, bei der das Modell viele Einträge transformieren und dann aggregieren muss. OOLONG-Paare erhöhen die Schwierigkeit durch quadratische paarweise Aggregation über die Eingabe weiter. Bei diesen Aufgaben wird sowohl die Kontextlänge als auch die Argumentationstiefe betont, nicht nur das Abrufen.

Bei diesen Benchmarks bieten RLMs große Genauigkeitsgewinne gegenüber direkten LLM-Aufrufen und herkömmlichen Agenten mit langem Kontext. Für GPT-5 auf CodeQA, einem Setup für die Beantwortung langer Dokumentfragen, erreicht das Basismodell eine Genauigkeit von 24,00, ein Zusammenfassungsagent erreicht 41,33, während RLM 62,00 und das RLM ohne Rekursion 66,00 erreicht. Für Qwen3-Coder-480B-A35B erreicht das Basismodell 20,00, ein CodeAct-Retrieval-Agent 52,00 und das RLM 56,00 mit einer reinen REPL-Variante bei 44,66.

Die Gewinne sind bei der härtesten Einstellung, den OOLONG-Paaren, am größten. Für GPT-5 ist das direkte Modell mit F1 von 0,04 nahezu unbrauchbar. Zusammenfassungs- und CodeAct-Agenten liegen in der Nähe von 0,01 und 24,67. Der volle RLM erreicht 58,00 F1 und die nicht rekursive REPL-Variante erreicht immer noch 43,93. Für Qwen3-Coder bleibt das Basismodell unter 0,10 F1, während das vollständige RLM 23,11 und die REPL nur Model 17,34 erreicht. Diese Zahlen zeigen, dass sowohl REPL als auch rekursive Unteraufrufe bei dichten quadratischen Aufgaben von entscheidender Bedeutung sind.

BrowseComp-Plus hebt die effektive Kontexterweiterung hervor. Der Korpus umfasst etwa 6 bis 11 Millionen Token, was zwei Größenordnungen über dem 272.000 Token-Kontextfenster von GPT-5 liegt. RLM mit GPT 5 behält eine starke Leistung bei, selbst wenn 1.000 Dokumente in der Umgebungsvariablen angegeben werden, während die Customary-GPT-5-Baselines mit zunehmender Dokumentanzahl abnehmen. Bei diesem Benchmark erreicht RLM GPT 5 eine Genauigkeit von etwa 91,33 bei durchschnittlichen Kosten von 0,99 USD professional Abfrage, während ein hypothetisches Modell, das den vollständigen Kontext direkt liest, zum aktuellen Preis zwischen 1,50 und 2,75 USD kosten würde.

Der Forschungsarbeit analysiert auch die Trajektorien von RLM-Läufen. Es entstehen mehrere Verhaltensmuster. Das Modell beginnt oft mit einem Peek-Schritt, bei dem es die ersten paar tausend Zeichen des Kontexts untersucht. Anschließend wird eine Filterung im Grep-Stil mit Regex oder einer Stichwortsuche verwendet, um relevante Zeilen einzugrenzen. Bei komplexeren Abfragen wird der Kontext in Blöcke unterteilt und für jeden Block rekursive LMs aufgerufen, um eine Kennzeichnung oder Extraktion durchzuführen, gefolgt von einer programmgesteuerten Aggregation. Bei langen Ausgabeaufgaben speichert das RLM Teilausgaben in Variablen und fügt sie zusammen, wodurch die Ausgabelängenbeschränkungen des Basismodells umgangen werden.

Die neue Model von Prime Mind

Prime Mind-Crew hat dieses Konzept in eine konkrete Umgebung, RLMEnv, umgesetzt, die in ihren Verifizierer-Stack und Environments Hub integriert ist. In ihrem Design verfügt das Haupt-RLM nur über eine Python-REPL, während Unter-LLMs die umfangreichen Instruments wie Websuche oder Dateizugriff erhalten. Die REPL macht eine verfügbar llm_batch Funktion, damit das Root-Modell viele Unterabfragen parallel auffächern kann, und eine reply Variable, in die die endgültige Lösung geschrieben und als fertig gekennzeichnet werden muss. Dadurch werden Token-lastige Werkzeugausgaben vom Hauptkontext isoliert und das RLM kann teure Vorgänge an Untermodelle delegieren.

Höchster Intellekt bewertet diese Implementierung in vier Umgebungen. DeepDive testet die Webrecherche mit Such- und Öffnungstools und sehr ausführlichen Seiten. Math Python stellt eine Python-REPL für schwierige mathematische Probleme im Wettbewerbsstil bereit. Oolong verwendet den Lengthy-Context-Benchmark in RLMEnv wieder. Der Schwerpunkt der wörtlichen Kopie liegt auf der exakten Reproduktion komplexer Zeichenfolgen über Inhaltstypen wie JSON, CSV und gemischte Codes hinweg. In diesen Umgebungen profitieren sowohl GPT-5-mini als auch das INTELLECT-3-MoE-Modell vom RLM-Gerüst hinsichtlich der Erfolgsrate und der Robustheit gegenüber sehr langen Kontexten, insbesondere wenn die Werkzeugausgabe andernfalls den Modellkontext überfordern würde

Sowohl das Autorenteam des Forschungspapiers als auch das Prime Mind-Crew betonen, dass die aktuellen Implementierungen nicht vollständig optimiert sind. RLM-Aufrufe sind synchron, die Rekursionstiefe ist begrenzt und Kostenverteilungen weisen aufgrund sehr langer Trajektorien starke Ausläufer auf. Die eigentliche Likelihood besteht darin, RLM-Gerüst mit dediziertem Verstärkungslernen zu kombinieren, damit Modelle im Laufe der Zeit bessere Chunking-, Rekursions- und Werkzeugnutzungsrichtlinien erlernen. In diesem Fall bieten RLMs einen Rahmen, in dem Verbesserungen in Basismodellen und im Systemdesign direkt in leistungsfähigere Agenten mit langem Horizont umgesetzt werden, die Umgebungen mit mehr als 10 Millionen Token ohne Kontextverlust nutzen können.

Wichtige Erkenntnisse

Hier sind 5 prägnante, technische Erkenntnisse, die Sie unter den Artikel einfügen können.

• RLMs formatieren den langen Kontext als Umgebungsvariable um: Rekursive Sprachmodelle behandeln die gesamte Eingabeaufforderung als externe Zeichenfolge in einer REPL im Python-Stil, die vom LLM überprüft und durch Code transformiert wird, anstatt alle Token direkt in den Transformer-Kontext aufzunehmen.
• Die Inferenzzeitrekursion erweitert den Kontext auf mehr als 10 Millionen Token: RLMs ermöglichen es einem Root-Modell, rekursiv Sub-LLMs für ausgewählte Ausschnitte des Kontexts aufzurufen, was eine effektive Verarbeitung von Eingabeaufforderungen ermöglicht, die bis zu etwa zwei Größenordnungen länger als das Basiskontextfenster sind und bei Workloads im BrowseComp-Plus-Stil mehr als 10 Millionen Token erreichen.
• RLMs übertreffen herkömmliche Gerüste mit langem Kontext bei harten Benchmarks: Über S-NIAH-, BrowseComp-Plus-, OOLONG- und OOLONG-Paare hinweg verbessern RLM-Varianten von GPT-5 und Qwen3-Coder die Genauigkeit und F1 gegenüber direkten Modellaufrufen, Abrufagenten wie CodeAct und Zusammenfassungsagenten, während die Kosten professional Abfrage vergleichbar oder niedriger bleiben.
• Nur REPL-Varianten helfen bereits, Rekursion ist für quadratische Aufgaben von entscheidender Bedeutung: Eine Ablation, die nur die REPL ohne rekursive Unteraufrufe verfügbar macht, steigert immer noch die Leistung bei einigen Aufgaben, was den Wert der Auslagerung des Kontexts in die Umgebung zeigt, aber vollständige RLMs sind erforderlich, um große Gewinne bei informationsdichten Einstellungen wie OOLONG-Paaren zu erzielen.
• Prime Mind operationalisiert RLMs durch RLMEnv und INTELLECT 3: Das Crew von Prime Mind implementiert das RLM-Paradigma als RLMEnv, wobei der Root-LM eine Sandbox-Python-REPL steuert, Instruments über Sub-LMs aufruft und das Endergebnis in eine schreibt reply Variable und meldet konsistente Gewinne in DeepDive-, Math Python-, Oolong- und Verbatim-Copy-Umgebungen mit Modellen wie INTELLECT-3.

---

Schauen Sie sich das an Papier Und Technische Particulars. Sie können uns auch gerne weiter folgen Twitter und vergessen Sie nicht, bei uns mitzumachen 100.000+ ML SubReddit und Abonnieren Unser Publication. Warten! Bist du im Telegram? Jetzt können Sie uns auch per Telegram kontaktieren.

Glaubst du, das ist klein? neuronales Netzwerk (wie TRM) bei Argumentationsaufgaben um ein Vielfaches größere Modelle übertreffen kann? Wie ist es möglich, dass Milliarden von LLM-Parametern eine so kleine Anzahl bescheidener Millionen-Parameter-Iterationen haben, die Rätsel lösen?

„Derzeit leben wir in einer skalierungsbesessenen Welt: Mehr Daten. Mehr GPUs bedeuten größere und bessere Modelle. Dieses Mantra hat bisher den Fortschritt in der KI vorangetrieben.“

Aber manchmal ist weniger wirklich mehr, und die Ting Recursive Fashions (TRMs) sind markante Beispiele für dieses Phänomen. Die Ergebnisse, wie darin bewiesen diesen Berichtsind leistungsstark: TRMs erreichen eine Genauigkeit von 87,4 % bei Sudoku-Excessive und 45 % bei ARC-AGI-1 und übertreffen gleichzeitig die Leistung größerer hierarchischer Modelle, während einige hochmoderne Modelle wie DeepSeek R1, Claude und o3-mini bei Sudoku 0 % erzielten. Und DeepSeek R1 erreichte 15,8 % auf ARC-1 und nur 1,3 % auf ARC-2, während ein TRM 7M-Modell eine Genauigkeit von 44,6 % erreicht. In diesem Weblog diskutieren wir, wie TRMs durch minimale Architektur maximale Argumentation erreichen.

Die Suche nach intelligenteren, nicht größeren Modellen

Künstliche Intelligenz ist in eine Part übergegangen, die von gigantischen Modellen dominiert wird. Die Bewegung conflict unkompliziert: Skalieren Sie einfach alles, dh Daten, Parameter, Berechnungen und Intelligenz werden entstehen.

Doch während Forscher und Praktiker beharrlich daran arbeiten, diese Grenzen zu erweitern, setzt sich eine Erkenntnis durch: Größer ist nicht immer gleich besser. Wenn es um strukturiertes Denken, Genauigkeit und schrittweise Logik geht, versagen größere Sprachmodelle oft. Die Zukunft der KI liegt möglicherweise nicht darin, wie groß wir bauen können, sondern eher darin, wie clever wir denken können. Daher stößt es auf zwei Hauptprobleme:

Das Downside bei der Skalierung großer Sprachmodelle

Große Sprachmodelle haben das Verständnis, die Zusammenfassung und die kreative Texterstellung natürlicher Sprache verändert. Sie können scheinbar Muster im Textual content erkennen und eine menschenähnliche Sprachverständlichkeit erzeugen.

Dennoch, wenn sie aufgefordert werden, sich darauf einzulassen logisches Denken Um Sudoku-Rätsel zu lösen oder Labyrinthe zu planen, lässt die Genialität dieser Modelle nach. LLMs können das nächste Wort vorhersagen, aber das bedeutet nicht, dass sie den nächsten logischen Schritt durchdenken können. Bei Rätseln wie Sudoku macht eine einzige falsch platzierte Ziffer das gesamte Raster ungültig.

Wenn Komplexität zur Barriere wird

Dieser Ineffizienz liegt die einseitige, additionally ähnliche Architektur von LLMs zugrunde; Sobald ein Token generiert wurde, ist es behoben, da keine Möglichkeit besteht, einen Fehltritt zu beheben. Ein einfacher logischer Fehler zu Beginn kann die ganze Technology verderben, genauso wie eine falsche Sudoku-Zelle das Rätsel ruiniert. Daher gewährleistet eine Vergrößerung weder Stabilität noch bessere Argumentation.

Der enorme Rechen- und Datenbedarf macht es für die meisten Forscher nahezu unmöglich, auf diese Modelle zuzugreifen. Darin liegt additionally ein Paradox, dass einige der leistungsstärksten KI-Systeme Aufsätze schreiben und Bilder malen können, aber nicht in der Lage sind, Aufgaben zu erfüllen, die selbst ein rudimentäres rekursives Modell leicht lösen kann.

Dabei geht es nicht um Daten oder Umfang; Vielmehr geht es um Ineffizienz in der Architektur und darum, dass rekursiver Intellektualismus sinnvoller sein könnte als expansiver Intellekt.

Hierarchische Argumentationsmodelle (HRM): Ein Schritt in Richtung simuliertem Denken

Der Hierarchisches Argumentationsmodell (HRM) ist eine aktuelle Weiterentwicklung, die gezeigt hat, wie kleine Netzwerke komplexe Probleme durch rekursive Verarbeitung lösen können. HRM verfügt über zwei Transformatorimplementierungen, ein Low-Degree-Netz (f_L) und ein Excessive-Degree-Netz (f_H). Jeder Durchgang läuft wie folgt ab: f_L übernimmt die Eingabefrage und die aktuelle Antwort sowie den latenten Zustand, während f_H die Antwort basierend auf dem latenten Zustand aktualisiert. Dies ist eine Artwork Hierarchie aus schnellem „Denken“ (f_L) und langsameren „konzeptionellen“ Veränderungen (f_H). Sowohl f_L als auch f_H sind vierschichtige Transformatoren mit insgesamt ~27 Millionen Parametern.

Die HRM-Architektur trainiert unter umfassender Aufsicht: Während des Trainings führt HRM bis zu 16 aufeinanderfolgende Generations-„Verbesserungsschritte“ durch, berechnet jedes Mal einen Verlust für die Antwort und vergleicht die Steigungen aller vorherigen Schritte. Dies imitiert im Wesentlichen ein sehr tiefes Netzwerk, eliminiert jedoch die vollständige Backpropagation.

Das Modell verfügt über ein adaptives Stoppsignal (Q-Studying), das entscheidet, wann das Modell das nächste Mal trainiert und wann die Aktualisierung bei jeder Frage beendet wird. Mit dieser komplizierten Methodik schnitt HRM sehr intestine ab: Es übertraf große LLMs bei Sudoku-, Labyrinth- und ARC-AGI-Rätseln mit nur einer kleinen Stichprobe mit überwachtem Lernen.

Mit anderen Worten: HRM hat gezeigt, dass kleine Modelle mit Rekursion eine vergleichbare oder bessere Leistung erbringen können als viel größere Modelle. Der HRM-Rahmen basiert jedoch auf mehreren starken Annahmen. Seine Vorteile ergeben sich in erster Linie aus der hohen Überwachung und nicht aus dem rekursiven dualen Netzwerk.

In der Realität gibt es keine Sicherheit, dass f_L und f_H in wenigen Schritten ein Gleichgewicht erreichen. HRM verwendet außerdem eine Zwei-Netzwerk-Architektur, die auf biologischen Metaphern basiert, wodurch die Architektur schwer zu verstehen und abzustimmen ist. Schließlich erhöht das adaptive Anhalten von HRM die Trainingsgeschwindigkeit, verdoppelt jedoch die Berechnung.

Winzige rekursive Modelle (TRM): Einfachheit im Denken neu definieren

Tiny Recursive Fashions (TRMs) rationalisieren den rekursiven Prozess von HRMs und ersetzen die Hierarchie zweier Netzwerke durch ein einziges winziges Netzwerk. Bei einem vollständigen Rekursionsprozess führt ein TRM diesen Prozess iterativ durch und durchläuft die gesamte endgültige Rekursion rückwärts, ohne dass die Festkommaannahme auferlegt werden muss. Das TRM behält explizit eine vorgeschlagene Lösung 𝑦 und einen latenten Argumentationszustand 𝑧 bei und iteriert über die bloße Aktualisierung 𝑦 und des 𝑧 Argumentationszustands.

Im Gegensatz zur sequentiellen HRM-Instanz ist die vollständig kompakte Schleife in der Lage, von massiven Gewinnen bei der Generalisierung zu profitieren und gleichzeitig die Modellparameter in der TRM-Architektur zu reduzieren. Die TRM-Architektur beseitigt im Wesentlichen die Abhängigkeit von einem Fixpunkt und IFT (Implicit Mounted-Level Coaching) vollständig, da PPC (Parallel Predictive Coding) für den vollständigen Rekursionsprozess verwendet wird, genau wie HRM-Modelle. Ein einzelnes winziges Netzwerk ersetzt die beiden Netzwerke im HRM, was die Anzahl der Parameter verringert und das Risiko einer Überanpassung minimiert.

Wie TRM größere Modelle übertrifft

TRM behält zwei unterschiedliche Variablenzustände bei, die Lösungshypothese 𝑦 und die latente Gedankenkettenvariable 𝑧. Durch die Trennung von 𝑦 muss der latente Zustand 𝑧 nicht sowohl die Argumentation als auch die explizite Lösung beibehalten. Der Hauptvorteil davon besteht darin, dass die dualen Variablenzustände bedeuten, dass ein einzelnes Netzwerk beide Funktionen ausführen kann, indem es auf 𝑧 iteriert und 𝑧 in 𝑦 umwandelt, wenn sich die Eingaben nur durch die Anwesenheit oder Abwesenheit von 𝑥 unterscheiden.

Durch das Entfernen eines Netzwerks werden die Parameter im HRM halbiert Modellgenauigkeit bei Schlüsselaufgaben nimmt zu. Durch die Änderung der Architektur kann das Modell sein Lernen auf die effektive Iteration konzentrieren und die Modellkapazität reduzieren, wo Osmose überangepasst hätte. Die empirischen Ergebnisse zeigen, dass das TRM die Generalisierung mit weniger Parametern verbessert. Daher stellte das TRM fest, dass weniger Schichten eine bessere Verallgemeinerung ermöglichten als mehr Schichten. Die Reduzierung der Anzahl der Ebenen auf zwei, wobei die Rekursionsschritte proportional zur Tiefe waren, lieferte bessere Ergebnisse.

Das Modell wird umfassend überwacht, um $y$ zum Zeitpunkt des Trainings und bei jedem Schritt der Wahrheit anzupassen. Es ist so konzipiert, dass bereits ein paar Durchläufe ohne Gradienten $(y,z)$ einer Lösung näher bringen – das Erlernen der Verbesserung der Antwort erfordert additionally nur einen vollständigen Durchlauf mit Gradienten.

Vorteile von TRM

Dieses Design ist schlank und bietet viele Vorteile:

• Keine Festkomma-Annahmen: TRM eliminiert Festkommaabhängigkeiten und führt bei jeder Rekursion eine Backpropagation durch. Ausführen einer Reihe von Rekursionen ohne Gradienten.
• Einfachere latente Interpretation: TRM definiert zwei Zustandsvariablen: y (die Lösung) und z (das Gedächtnis des Denkens). Es wechselt zwischen der Verfeinerung beider, wodurch der Gedanke für einen Zweck und die Ausgabe für einen anderen Zweck erfasst wird. Die Verwendung genau dieser beiden, weder mehr noch weniger als zwei, conflict zweifellos optimum, um die Klarheit der Logik aufrechtzuerhalten und gleichzeitig die Leistung des Denkens zu steigern.
• Einzelnes Netzwerk, weniger Schichten (weniger ist mehr): Anstatt zwei Netzwerke zu verwenden, wie es das HRM-Modell mit f_L und f_H tut, komprimiert TRM alles in einem einzigen 2-Schichten-Modell. Dadurch wird die Anzahl der Parameter auf etwa 7 Millionen reduziert, eine Überanpassung vermieden und die Gesamtgenauigkeit für Sudoku von 79,5 % auf 87,4 % erhöht.
• Aufgabenspezifische Architekturen: TRM ist darauf ausgelegt, die Architektur an jede Fallaufgabe anzupassen. Anstatt zwei Netzwerke zu verwenden, wie es das HRM-Modell mit f_L und f_H tut, komprimiert TRM alles in einem einzigen 2-Schichten-Modell. Dadurch wird die Anzahl der Parameter auf etwa 7 Millionen reduziert, eine Überanpassung vermieden und die Gesamtgenauigkeit für Sudoku von 79,5 % auf 87,4 % erhöht.
• Optimierte Rekursionstiefe: TRM verwendet außerdem einen exponentiellen gleitenden Durchschnitt (EMA) für die Gewichte, um das Netzwerk zu stabilisieren. Durch die Glättung von Gewichtungen wird die Überanpassung bei kleinen Datenmengen reduziert und die Stabilität mit EMA erhöht.

Experimentelle Ergebnisse: Kleines Modell, große Wirkung

Winzige rekursive Modelle zeigen, dass kleine Modelle eine bessere Leistung erbringen können große LLMs zu einigen Denkaufgaben. Bei mehreren Aufgaben übertraf die Genauigkeit von TRM die von HRM und großen vorab trainierten Modellen:

• Sudoku-Extrem: Das sind sehr schwere Sudokus. HRM (27 Millionen Parameter) ist 55,0 % genau. TRM (nur 5–7 Mio. Parameter) springt auf 87,4 (mit MLP) oder 74,7 (mit Aufmerksamkeit). Kein LLM ist überhaupt in der Nähe. Die hochmodernen Chain-of-Thought-LLMs (Deepseek R1, Claude, o3-mini) erzielten bei diesem Datensatz 0 %.
• Labyrinth-schwer: Bei Wegfindungslabyrinthen mit einer Lösungslänge > 110 ist TRM mit Aufmerksamkeit zu 85,3 % genau, während HRM zu 74,5 % genau ist. Die MLP-Model erreichte hier 0 %, was darauf hindeutet, dass Selbstaufmerksamkeit erforderlich ist. Auch hier erzielten geschulte LLMs in diesem Small-Information-Regime ~0 % auf Maze-Laborious.
• ARC-AGI-1 und ARC-AGI-2: Auf ARC-AGI-1 erreichte TRM (7M) eine Genauigkeit von 44,6 % gegenüber HRM von 40,3 %. Bei ARC-AGI-2 erzielte TRM eine Genauigkeit von 7,8 % gegenüber 5,0 % bei HRM. Beide Modelle schneiden intestine im Vergleich zu einem direkten Vorhersagemodell ab, bei dem es sich um ein 27M-Modell handelt (21,0 % auf ARC-1 und eine neue LLM-Gedankenkette, Deepseek R1 erreichte 15,8 % auf ARC-1 und 1,3 % auf ARC-2). Selbst bei intensiver Testzeitberechnung erreichte der High-LLM Gemini 2.5 Professional auf ARC-2 nur 4,9 %, während der TRM das Doppelte erreichte (praktisch keine Feinabstimmungsdaten).

Abschluss

Winzige rekursive Modelle veranschaulichen, wie Sie mit kleinen, rekursiven Architekturen erhebliche Denkfähigkeiten erreichen können. Die Komplexität wird beseitigt (dh es gibt keinen Festkomma-Trick/keine Verwendung dualer Netzwerke, keine dichten Schichten). TRM liefert genauere Ergebnisse und verwendet weniger Parameter. Es nutzt die Hälfte der Schichten und verdichtet zwei Netzwerke und verfügt nur über einige einfache Mechanismen (EMA und einen effizienteren Stoppmechanismus).

Im Wesentlichen ist TRM einfacher als HRM, lässt sich jedoch viel besser verallgemeinern. Dieses Papier zeigt das intestine gestaltete kleine Netzwerke Mit rekursivem, tiefem und überwachtem Lernen können schwierige Probleme erfolgreich gelöst werden, ohne dass eine große Größe erforderlich ist.

Dennoch stellen die Autoren einige offene Fragen zur Überlegung, zum Beispiel: Warum genau hilft Rekursion so viel mehr? Warum nicht einfach zum Beispiel ein größeres Feedforward-Netz aufbauen?

Derzeit ist TRM ein aussagekräftiges Beispiel für effiziente KI-Architekturen, da kleine Netzwerke LLMs bei Logikrätseln übertrafen und zeigt, dass beim Deep Studying manchmal weniger mehr ist.