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.

Wir interagieren jeden Tag mit LLMs.

Wir schreiben Eingabeaufforderungen, fügen Dokumente ein, führen lange Gespräche fort und erwarten, dass sich das Modell an das erinnert, was wir zuvor gesagt haben. Wenn das der Fall ist, machen wir weiter. Wenn dies nicht der Fall ist, wiederholen wir uns oder gehen davon aus, dass etwas schief gelaufen ist.

Was die meisten Menschen selten bedenken, ist, dass jede Antwort durch etwas eingeschränkt wird, das als Kontextfenster bezeichnet wird. Es entscheidet im Stillen, wie viel von Ihrer Eingabeaufforderung das Modell sehen kann, wie lange ein Gespräch kohärent bleibt und warum ältere Informationen plötzlich wegfallen.

Jedes große Sprachmodell verfügt über ein Kontextfenster, doch die meisten Benutzer erfahren nie, was es ist oder warum es wichtig ist. Dennoch spielt es eine entscheidende Rolle dabei, ob ein Mannequin kurze Chats, lange Dokumente oder komplexe mehrstufige Aufgaben bewältigen kann.

In diesem Artikel werden wir untersuchen, wie das Kontextfenster funktioniert, wie es sich in modernen LLMs unterscheidet und warum das Verständnis davon die Artwork und Weise verändert, wie Sie Sprachmodelle aufrufen, auswählen und verwenden.

Was ist ein Kontextfenster?

Ein Kontextfenster ist die maximale Textmenge, die ein Sprachmodell gleichzeitig lesen und sich merken kann, während es eine Antwort generiert. Es fungiert als Kurzzeitgedächtnis des Modells, einschließlich der Aufforderung und des letzten Gesprächs. Sobald das Restrict überschritten wird, werden ältere Informationen ignoriert oder vergessen.

Warum ist die Größe des Kontextfensters wichtig?

Das Kontextfenster bestimmt, wie viele Informationen ein Sprachmodell gleichzeitig verarbeiten und begründen kann.

Kleinere Kontextfenster erzwingen das Abschneiden von Eingabeaufforderungen oder Dokumenten, wodurch häufig die Kontinuität unterbrochen wird und wichtige Particulars verloren gehen. Größere Kontextfenster ermöglichen es dem Modell, mehr Informationen gleichzeitig zu speichern, was die Argumentation bei langen Gesprächen, Dokumenten oder Codebasen erleichtert.

Stellen Sie sich das Kontextfenster als Arbeitsspeicher des Modells vor. Alles, was außerhalb der aktuellen Eingabeaufforderung liegt, wird praktisch vergessen. Größere Fenster tragen dazu bei, mehrstufige Überlegungen und lange Dialoge beizubehalten, während kleinere Fenster dazu führen, dass frühere Informationen schnell verblassen.

Aufgaben wie das Analysieren langer Berichte oder das Zusammenfassen großer Dokumente in einem Durchgang werden mit größeren Kontextfenstern möglich. Sie bringen jedoch Nachteile mit sich: höhere Rechenkosten, langsamere Antworten und potenzielles Rauschen, wenn irrelevante Informationen einbezogen werden.

Der Schlüssel liegt im Gleichgewicht. Stellen Sie genügend Kontext zur Verfügung, um die Aufgabe zu begründen, aber achten Sie darauf, dass die Eingaben fokussiert und related bleiben.

Lesen Sie auch: Immediate Engineering Information 2026

Kontextfenstergrößen in verschiedenen LLMs

Die Größe der Kontextfenster variiert stark große Sprachmodelle und sind mit neueren Generationen schnell gewachsen. Frühe Modelle waren auf nur wenige tausend Token beschränkt, was sie auf kurze Eingabeaufforderungen und kleine Dokumente beschränkte.

Moderne Modelle unterstützen viel größere Kontextfenster und ermöglichen so ausführliches Denken, Analysen auf Dokumentebene und ausgedehnte Gespräche mit mehreren Runden innerhalb einer einzigen Interaktion. Diese Steigerung hat die Fähigkeit eines Modells, die Kohärenz über komplexe Aufgaben hinweg aufrechtzuerhalten, erheblich verbessert.

Die folgende Tabelle fasst die häufig gemeldeten Kontextfenstergrößen für beliebte Modellfamilien zusammen OpenAIAnthropic, Google und Meta.

Beispiele für Kontextfenstergrößen

Modell	Organisation	Kontextfenstergröße	Notizen
GPT-3	OpenAI	~2.048 Token	Frühe Technology; sehr begrenzter Kontext
GPT-3.5	OpenAI	~4.096 Token	Standardmäßiges frühes ChatGPT-Restrict
GPT-4 (Grundlinie)	OpenAI	Bis zu ~32.768 Token	Größerer Kontext als GPT-3.5
GPT-4o	OpenAI	128.000 Token	Weit verbreitetes Lengthy-Context-Modell
GPT-4.1	OpenAI	~1.000.000+ Token	Large Unterstützung für erweiterten Kontext
GPT-5.1	OpenAI	~128.000–196.000 Token	Flaggschiff der nächsten Technology mit verbesserter Argumentation
Claude 3,5 / 3,7 Sonett	Anthropisch	200.000 Token	Starke Stability zwischen Geschwindigkeit und langem Kontext
Claude 4,5 Sonett	Anthropisch	~200.000 Token	Verbesserte Argumentation durch großes Fenster
Claude 4,5 Opus	Anthropisch	~200.000 Token	Hochwertiges Claude-Modell
Gemini 3 / Gemini 3 Professional	Google DeepMind	~1.000.000 Token	Branchenführende Kontextlänge
Kimi K2	Moonshot-KI	~256.000 Token	Großer Kontext, starke, lange Argumentation
LLaMA 3.1	Meta	~128.000 Token	Erweiterter Kontext für Open-Supply-Modelle

Vorteile und Nachteile größerer Kontextfenster

Vorteile

• Unterstützt weitaus längere Eingaben, egal ob vollständige Dokumente, lange Konversationen oder große Codebasen.
• Verbessert die Konnektivität mehrstufiger Argumentation und längerer Gespräche.
• Ermöglicht die gleichzeitige Ausführung komplizierter Aufgaben wie die Analyse langer Berichte oder ganzer Bücher.
• Eliminiert die Notwendigkeit von Chunking-, Zusammenfassungs- oder externen Abrufsystemen.
• Hilft dabei, Antworten auf einen vorgegebenen Referenztext zu stützen, der Halluzinationen verringern kann.

Kompromisse

• Erhöht die Kosten, Latenz und API-Nutzungskosten.
• Es erweist sich als ineffizient, wenn ein breiter Kontext angewendet wird, obwohl er nicht erforderlich ist.
• Der Wert von Angeboten sinkt, wenn das Schüchterne irrelevante oder laute Informationen enthält.
• Kann zu Verwirrung oder Inkonsistenz führen, wenn in langen Eingaben widersprüchliche Particulars enthalten sind.
• Bei sehr langen Aufforderungen kann es zu Aufmerksamkeitsproblemen kommen, z. B. Informationen, die nicht in der Mitte hervorgehoben werden.

In der Praxis sind die größeren Kontextfenster leistungsfähiger und effektiver, wenn sie mit einer konzentrierten, qualitativ hochwertigen Eingabe anstelle der standardmäßigen maximalen Länge kombiniert werden.

Lesen Sie auch: Was ist ein Modellkollaps? Beispiele, Ursachen und Lösungen

Wie wirkt sich das Kontextfenster auf wichtige Anwendungsfälle aus?

Da das Kontextfenster die Menge an Informationen einschränkt, die ein Modell zu einem bestimmten Zeitpunkt anzeigen kann, hat es großen Einfluss darauf, was das Modell ohne zusätzliche Instruments oder Problemumgehungen erreichen kann.

Codierung und Codeanalyse

• Die Kontextfenster sind klein, wodurch das Modell auf eine einzelne Datei oder eine Handvoll Funktionen gleichzeitig beschränkt ist.
• Das Modell ist sich der größeren Codebasis nicht bewusst, es sei denn, sie wird angegeben.
• Große Kontextfenster ermöglichen die Anzeige von zwei oder mehr Dateien oder Repositorys.
• Ermöglicht systemweite Aufgaben wie das Refactoring von Modulen, das Auffinden von dateiübergreifenden Fehlern und das Erstellen von Dokumentation.
• Eliminiert manuelles Chunking oder den wiederholten Austausch von Codefragmenten.
• Bei sehr großen Projekten ist weiterhin eine Selektivität erforderlich, um Lärm und Kontextverschwendung zu vermeiden.

Zusammenfassung langer Texte

• Minimale Fenster ermöglichen die Aufteilung und Zusammenfassung von Dokumenten in Fragmenten.
• Kleine Zusammenfassungen neigen dazu, die globale Struktur und wichtige Beziehungen zu verlieren.
• Große Kontextfenster ermöglichen eine Zusammenfassung ganzer Dokumente in einem Durchgang.
• Erzeugt weniger unverständliche und unwahre Zusammenfassungen von Berichten, Büchern oder Transkripten.
• Im Wesentlichen praktisch für juristische, finanzielle, akademische und Besprechungsprotokolle.
• Der Kompromiss besteht darin, mehr zu bezahlen und bei großen Eingaben langsamer zu verarbeiten.

Lange Dokumentenanalyse und Fragen und Antworten

• Kleine Fenster erfordern Abrufsysteme oder eine manuelle Abschnittsauswahl.
• Riesige Fenster bieten die Möglichkeit, komplette Dokumente abzufragen oder mehrere Dokumente zu öffnen.
• Ermöglicht auch Querverweise auf Informationen, die sich an entfernten Standorten befinden.
• Gilt für Verträge, Forschungsarbeiten, Richtlinien und Wissensdatenbanken.
• Vereinfacht Pipelines durch Vermeidung der Verwendung von Such- und Chunking-Logik.
• Auch wenn es unter mehrdeutigen Anleitungen und nicht zusammenhängenden Eingabemöglichkeiten nicht möglich ist, genau zu sein, kann die Genauigkeit dennoch verbessert werden.

Erweiterter Gesprächsspeicher

• Chatbots haben kleine Fenstergrößen, was dazu führt, dass frühere Abschnitte einer langen Konversation vergessen werden.
• Wenn der Kontext verschwindet, muss der Benutzer Informationen wiederholen oder neu formulieren.
• Der Gesprächsverlauf ist länger und dauert in großen Kontextfenstern länger.
• Ermöglicht eine weniger roboterhafte, natürlichere und persönlichere Kommunikation.
• Intestine geeignet für Help-Chats, gemeinsames Schreiben und langwieriges Brainstorming.
• Ein größerer Speicher geht mit einer höheren Nutzung von Token sowie mit Kosten bei der Nutzung langer Chats einher.

Lesen Sie auch: Wie funktioniert das LLM-Gedächtnis?

Abschluss

Das Kontextfenster definiert, wie viele Informationen ein Sprachmodell gleichzeitig verarbeiten kann und fungiert als sein Kurzzeitgedächtnis. Modelle mit größeren Kontextfenstern bewältigen lange Konversationen, große Dokumente und komplexen Code effektiver, während kleinere Fenster Probleme haben, wenn die Eingaben zunehmen.

Allerdings erhöhen größere Kontextfenster auch die Kosten und die Latenz und helfen nicht, wenn die Eingabe unnötige Informationen enthält. Die richtige Kontextgröße hängt von der Aufgabe ab: Kleine Fenster eignen sich intestine für schnelle oder einfache Aufgaben, während größere Fenster besser für tiefgreifende Analysen und ausführliche Überlegungen geeignet sind.

Wenn Sie das nächste Mal eine Eingabeaufforderung schreiben, beziehen Sie nur den Kontext ein, den das Modell tatsächlich benötigt. Mehr Kontext ist wirkungsvoll, aber fokussierter Kontext funktioniert am besten.

Häufig gestellte Fragen

Z.ai hat GLM-4.6 angekündigt, das neueste Modell in seiner GLM-Serie, das ein umfassendes Improve darstellt. Das Modell führt Verbesserungen in Bezug auf Codierung, lang Kontextverarbeitung, Argumentation, Suchfunktionen, Schreibqualität und Agentenanwendungen ein, um die Gesamtleistung zu verbessern.

Ein zentrales Merkmal von GLM-4,6 ist die Erweiterung seines Kontextfensters auf 200.000 Token, ein Anstieg gegenüber den 128.000 Token, die in früheren Versionen verfügbar sind. Diese größere Kapazität ermöglicht es dem Modell, komplexere Agentenaufgaben zu erledigen. Die Codierungsleistung des Modells wurde ebenfalls fortgeschritten und erzielte höhere Punktzahlen für Code -Benchmarks. Es zeigt eine bessere reale Leistung in Umgebungen wie Claude Code, Cline, Roo Code und Kilo Code. Das Modell zeichnet sich in bestimmten Funktionen aus, wie beispielsweise die Erzeugung visuell polierter Entrance-Finish-Seiten. Argumentationsfunktionen zeigen klare Verbesserungen, und GLM-4,6 unterstützt die Verwendung von Instruments während der Inferenz, was zu einer stärkeren Gesamtfähigkeit beiträgt.

Das Modell zeigt eine stärkere Leistung bei der Verwendung von Instruments und der Suchbasis in Agenten-Frameworks. In Bezug auf die Textgenerierung wurde seine Schreibqualität verfeinert, um enger mit menschlichen Vorlieben für Stil und Lesbarkeit übereinzustimmen. Es spielt auch natürlicher, wenn es in Rollenspielszenarien verwendet wird. GLM-4.6 ist in Prime-Coding-Instruments erhältlich und eine Komponente des GLM-Codierungsplans. Dieser Abonnementservice mit den Plänen ab 3 USD professional Monat soll die KI-betriebene Codierung in einer Vielzahl von Anwendungen unterstützen.

Technische Spezifikationen bestätigen, dass das Modell Texteingangs- und Ausgangsmodalitäten unterstützt und eine maximale Ausgangs -Token -Grenze von 128.000 enthält. Die GLM-4,6 wurde in acht maßgeblichen Benchmarks bewertet, die mit führenden Modellen wie Claude Sonnet 4 und 4.6 entspricht. In einer wettbewerbsfähigen Bewertung innerhalb der Claude -Code -Umgebung übertraf es andere Modelle in 74 praktischen Codierungsszenarien. Diese Bewertungen zeigten auch, dass GLM-4,6 im Token-Verbrauch um mehr als 30% Effizienz erzielte.

---

Ausgewähltes Bildnachweis

sind jetzt in der Lage, große Eingänge zu bewältigen – ihr Kontextfenster liegt zwischen 200k (Claude) und 2M Token (Gemini 1.5 Professional). Das sind zwischen 280 und 2800 Seiten Textual content! Diese massiven Kontextfenster legen nahe, dass wir uns in den meisten praktischen Szenarien nicht zu viel Sorgen machen müssen, um die LLM -Grenzen hinsichtlich der Eingabe zu erreichen. Unsere neuesten Untersuchungen zeigen jedoch, dass dies nicht der Fall ist. Für viele Probleme mit dem komplexen Kontext ist die LLM wirksam Arbeitsspeicher kann überladen werden mit relativ kleinen Eingängen – weit vorher Wir haben die Kontextfenstergrenzen geschlagen.

Unser Papier führt ein neues theoretisches Berechnungsmodell ein, um zu erklären, warum dies geschieht, und zeigt in Experimenten, dass die Vorhersagen unserer Theorie reale Ergebnisse entsprechen. Unsere Ergebnisse können endlich erklären zuvor gemeldet LLM -Fehlerwie z. B. wie LLMs eine haben Unfähigkeit, Handlungslöcher zu erkennenAnwesend Mühe, lange Geschichten zu verstehenoder Beantworten Sie fälschlicherweise Fragen, wenn Dokumente ähnlich sind.

Im Folgenden stellen wir die Particulars aus, indem wir die folgenden Fragen beantworten:

1. Was passiert, wenn wir das Arbeitsgedächtnis eines LLM überschreiten?
2. Tut Mein Aufgabe benötigen viel Arbeitsgedächtnis?
3. Was kann ich tun, wenn meine Aufgabe viel Arbeitsgedächtnis benötigt?
4. Warum brauchen bestimmte Aufgaben viel Arbeitsgedächtnis?

Was passiert, wenn wir das Arbeitsgedächtnis eines LLM überschreiten?

Intuitiv gesehen erfordern Aufgaben, bei denen viel Kontext korrekt beantwortet werden muss, auch die LLM, um viele Informationen zu verfolgen. Da die Größe dieses „Arbeitssatzes“ zur korrekten Begründung der Antwort musste, wird es wahrscheinlicher, dass das LLM Fehler macht, da sie nicht in der Lage ist, die relevanten Informationen in seinem begrenzten Arbeitsspeicher zu behalten.

Betrachten Sie das folgende Beispiel. Sagen Sie, wir möchten einen bestimmten Teil des Code eines Menschen debuggen und herausfinden, ob der endgültige Wert der Variablen x7 ist „A“ oder „B“:

x6 = "a"
x4 = "b"
x0 = x6
x2 = x4
x3 = x0
x8 = x2
x9 = x3
x7 = x3

Diese variable Monitoring -Aufgabe erfordert viel Kontext, um eine Antwort zu berechnen, da es nicht zu einer falschen Antwort führen kann. Durch das Ausführen von Experimenten mit einer Reihe von Frontier -Modellen in dieser Aufgabe zeigt sich, dass sie alle auf zufällige Vermutungen zwischen den beiden Antworten zurückzuführen sind, wenn die Anzahl der Variablen wächst:

Dieses Experiment zeigt an, dass diese LLMs höchstens n = 5 bis 10 Variablen verfolgen können, bevor sie ihre Arbeitsspeicherkapazität überschreiten. Danach verschlechtert sich die Leistung schnell auf 50–50 zufällige Vermutungen.

Tut Mein Aufgabe benötigen viel Arbeitsgedächtnis?

Jetzt sind Sie wahrscheinlich neugierig, ob Arbeitsgedächtnisgrenzen ein Downside für die Aufgabe sein könnten, die Sie zu lösen versuchen. Das erste, was wir empfehlen, ist zu überprüfen, ob die anstehende Aufgabe den Aufgaben ähnlich ist, die wir theoretisch in unserem Artikel analysieren. Wir rufen Aufgaben an Bapo-hard Wenn sie unter unserem BAPO -Modell viel Arbeitsgedächtnis benötigen (weiter unten mehr). Wir wissen, dass die Aufgaben theoretisch schwer sind:

• Erreichbarkeit der Grafik: Kann in komplexer Zusammenfassung, Entitätsverfolgung, variabler Verfolgung oder logischem Abzug auftreten
• Mehrheit: Kann in der Überprüfung der Klassifizierung auftreten, eine Konsensmeinung finden usw.
• Argumentation über Dreifach

Ebenso können Sie sehen, ob Ihre Aufgabe bapo-einfach ist:

• Minimal/Most: Geben Sie beispielsweise die negativste oder positivste Überprüfung in einer Liste zurück
• Index oder Nadel-in-a-haystack: zB, finden Sie heraus, ob ein Thema diskutiert wird

Intuitiv müssen Probleme, bei denen nur kleine Informationen verfolgt werden müssen, um die Frage zu beantworten, niedrige Arbeitsspeicheranforderungen (z. B. Nadel-in-a-Haystack). Wenn die Antwort quick alle Eingangs -Token erfordert und keine kurze Zusammenfassung vorliegt, sind die Anforderungen an das Arbeitsgedächtnis hoch.

Wenn Ihre Aufgabe nicht in der obigen Liste steht, können Sie Ihr Urteilsvermögen verwenden, um festzustellen, ob es eine einfache Lösung gibt, die nicht viel Speicher benötigt, z. B. eine einfache aufmerksamkeitsbasierte Suche, die die LLM ausführen kann, um die Frage zu beantworten, oder eine Möglichkeit, den Kontext zusammenzufassen (ohne die Frage a priori zu wissen), damit Ihre Frage aus der Zusammenfassung beantwortet werden kann. Wenn nicht, erfordert Ihr Downside möglicherweise ein erhebliches Arbeitsgedächtnis. In diesem Fall ist LLMs gefährdet, bei Ihrer Aufgabe zu fehlschlagen, insbesondere wenn die Größe der Aufgabe zunimmt (z. B. Anzahl der Variablen, relevante Informationen). Gehen Sie nicht davon aus, dass ein LLM sie berechnen kann, da die Antwort aus dem Kontext berechnet werden kann.

Was kann ich tun, wenn meine Aufgabe viel Arbeitsgedächtnis benötigt?

Wenn Sie erkennen, dass Ihre anstehende Aufgabe viel Arbeitsgedächtnis erfordert und häufig fehlschlägt, finden Sie hier eine Vielzahl von Korrekturen, die theoretisch motiviert sind, Ihre Chancen auf gute Leistung zu erhöhen:

• Verwenden Sie ein argumentierendes Modell (und hoffen Sie, dass es nicht aus Token ausgeht). Wir zeigen, dass theoretisch Arguming-Token LLMs ermöglichen, eine Bapo-harte Aufgabe zu lösen. Die Anzahl der Argumentationstoken, die zur Überwindung der Arbeitsgedächtnisgrenzen erforderlich sind, kann jedoch extrem groß sein (wie die Experimente in unserer Arbeit zeigen). Und in der Praxis sogar die besten Argumentationsmodelle Machen Sie immer noch Fehler.
• Basierend auf unseren theoretischen Ergebnissen könnten Sie Ihr Downside in einen, der mehr hat kompakt Zwischenausdauer, die weniger wahrscheinlich überschreitet, die Arbeitsgedächtnisgrenzen überschreiten. Anstatt die LLM zu bitten, über die vollständige HTML einer Webseite zu begründen, geben Sie eine vereinfachte Syntax wie nur den gerenderten Textual content an. In ähnlicher Weise könnte es für Lumpenszenarien nützlich sein, um nützlich zu sein Vorannotieren oder Vorkombination der Daten Auf eine Weise, die die endgültige Antwort aus den kleineren Zusammenfassungen leicht zu erhalten hat.
• Schließlich können Sie die Arbeitsmomit-mory-starken Stücke an einen externen Löser oder Software auslagern, z. B. anstatt direkt nach der Mehrheitsmeinung zu fragen, jede Meinung separat zu klassifizieren (bapo-einfach) und dann die Ergebnisse in Python zu aggregieren, anstatt die LLM zu fragen.

Denken Sie daran, dass diese Korrekturen möglicherweise nicht für alle Aufgaben funktionieren, insbesondere wenn nicht klar ist, wie die Aufgaben in weniger Arbeitsgedächtnis -intensive Unteraufgaben zerlegt werden können. Hier kann zukünftige Forschungen hoffentlich die Lücke füllen.

Warum brauchen bestimmte Aufgaben viel Arbeitsgedächtnis?

Für Interessenten befasst sich dieser Abschnitt etwas tiefer in die Theorie aus unserer Arbeit. Um zu analysieren, welche Aufgaben viel Arbeitsgedächtnis benötigen, haben wir zunächst ein abstraktes Modell entwickelt, wie Transformatoren Lösungen berechnen. Wir haben dann das Modell verwendet, um zu beweisen, dass eine Aufgabe schwierig oder einfach ist.

Betrachten Sie als Illustration die Aufgabe, ein neu veröffentlichtes langes Buch zu lesen und dann eine Frage dazu zu beantworten. Es gibt ungefähr zwei Strategien, die Menschen nach dem Lesen anwenden können. Wenn man einen großen Arbeitsgedächtnis hat und alle wichtigen Informationen des Buches erinnern kann, kann man die Frage direkt vom Kopf beantworten. Wenn man dies nicht tut und sich nur an die Huge -Image -Ideen erinnern kann, kann man diesen verwenden, um den groben Ort der relevanten Informationen im Buch zu finden und auf die Seite zurückzukehren, um die Antwort zu finden.

Überlegen Sie nun, wie ein transformatorbasiertes LLM dieselbe Aufgabe verarbeitet. Es wird über den Inhalt des Buches gelesen und dann eine Antwort an der letzten Place berechnet, nachdem es die Frage gelesen hat. Während der Verarbeitung des Inhalts des Buches kann sich die LLM um einige relevante Orte kümmern, um die Antwort zu berechnen (das Äquivalent des Durchblätterns durch Seiten). Oder es kann kontextbezogene Einbettungen des Buches verwenden, um wichtige Fakten zu speichern und die Frage direkt von ihnen zu beantworten (das Äquivalent des Rückrufs). Was es nicht tun kann, ist zurück zu gehen und das Buch in seiner Gesamtheit erneut mit der Frage zu lesen, da die kausale Aufmerksamkeit dazu führt nach vorne Durch das Kontextfenster.

In diesem Szenario bedeutet größerer Arbeitsgedächtnis sowohl für Menschen als auch für KI, dass es eine bessere Likelihood gibt, Informationen zu speichern, die die richtige Antwort ermöglichen, insbesondere wenn die Dinge kompliziert werden. Okay, aber wie definieren wir formeller, welcher Arbeitsgedächtnis für LLM -Aufgaben benötigt wird? In unserer Zeitung machen wir das durch die Aufmerksamkeitspräfix Oracle (BAPO) Modell.

Das BAPO -Modell bietet eine vereinfachte rechnerische Charakterisierung, die wir theoretisch analysieren können, um zu beweisen, welche Probleme mehr oder weniger Bandbreite (dh Arbeitsgedächtnis) für ein LLM erfordern. Um eine Antwort zu berechnen, verwendet das BAPO -Modell (so etwas wie) die beiden Strategien von oben:

• Das BAPO -Modell kann ein Präfix -Orakel verwenden F zu senden A Informationsbits weiterleiten Informationen zum Lesen merken
• Das BAPO -Modell kann auch ein Aufmerksamkeits -Orakel verwenden G zu tun B Token aus früheren Token kehren auf die Seiten zurück

Wir definieren dann die Arbeitsgedächtnis Anforderungen an eine Aufgabe als Kombination aus zwei Bapo-Bandbreitenparametern (a, b)-die erste bezieht sich darauf, wie viele Informationen vorbereitet und weitergegeben werden (Bandbreite a) und der zweite bezieht sich darauf, wie viel nach der Tatsache (Bandbreite B) nachgeschaut werden kann. Warum ist das Arbeitsgedächtnis die Kombination von zwei Parameter? Es liegt daran, dass es einen Kompromiss gibt: Je mehr Informationen man auswendig gelernt hat, desto weniger Informationen können man nachschlagen.

Wenn eine Aufgabe konstante Bandbreitenanforderungen (dh a, b in o (1)) enthält, wird die Aufgabe die LLM -Arbeitsspeichergröße wahrscheinlich nicht überschreiten. Wenn jedoch eine Aufgabe Bandbreitenanforderungen hat, die von der Größe des Eingangs abhängen (z. B. Sequenz oder Alphabetlänge), überschreiten sie schließlich die Arbeitsspeichergrenzen und führt zum Versagen.

Schlussfolgerungen

Arbeitsgedächtnis ist ein Wichtiger Engpass In transformatorbasierten LLMs. Lange bevor die Informationen die Kontextfenstergröße überschreiten, wird die Fähigkeit des Transformators, diese Informationen im Fenster effektiv darzustellen und zu kommunizieren, überschritten. Aktuelle lange Kontext -Benchmarks Verlassen Sie sich stark auf Nadel-in-a-Haystack-Problemewas wir gezeigt haben, sind bapo-einfach. Dies bedeutet, dass die aktuelle Benchmark-Leistung die Leistung über den gesamten Bereich der Langzeitaufgaben mit langer Kontext nicht genau erfasst wird.

Aufgaben wie komplexe Zusammenfassung, Codeverfolgung oder Inkonsistenzerkennung sind für LLMs gemäß unserem theoretischen Modell schwierig. Sie können enthalten Bapo-harte Unteraufgaben was zu hohen Arbeitsspeicheranforderungen führt, die wiederum Fehler verursachen in der Praxis. Während die jüngsten Fortschritte in der Kontextfensterlänge die Anwendbarkeit von LLMs erweitert haben, erhöht die Verwendung längerer Kontexte auch die Komplexität der damit verbundenen Aufgaben. Dies wird wahrscheinlich die Häufigkeit von Bapo-hartigen Aufgaben erhöhen und zu mehr LLM-Fehlern führen.

Wir haben eine Reihe von Strategien dargelegt, um die Anforderungen des Arbeitsgedächtnisses von Aufgaben zu senkenArgumentationstoken. Sie haben jedoch ihre eigenen Einschränkungen, z. B. einige Aufgaben möglicherweise eine Vielzahl von Argumentationstoken, um die Bandbreitenbeschränkungen in der Praxis zu überwinden. Wir hoffen, dass zukünftige Forschung allgemeinere Lösungen und möglicherweise sogar neue Architekturen über Transformatoren liefern kann.

Referenzen

Fußnoten

ª Sie fragen sich vielleicht, ob die Frage zuerst die Arbeitsspeicheranforderungen ändert. Nein – Weitere Informationen finden Sie in Papier.