Im Jahr 2026 stehen Kontextfenster mit 1 Mio. Tokens zur Verfügung. Gemini, GPT-5 und Claude (mit Extended Thinking) unterstützen sie. Demonstrationen zeigen Modelle, die ganze Bücher in einem Durchgang lesen. Der Traum scheint wahr geworden zu sein: Legen Sie einfach alles in den Kontext und lassen Sie das Modell den Rest erledigen.
Die Realität ist wie immer differenzierter. 1 Mio. Tokens sind eine technische Kapazität, keine Leistungsgarantie. In der Praxis erzielen Modelle mit 5.000–50.000 Tokens Kontext die besten Ergebnisse. Ab 100.000 Tokens treten subtile Qualitätsprobleme auf. Ab 500.000 Tokens werden wichtige Informationen regelmäßig übersehen. Bei 1 Mio. Tokens ist das Modell überfordert.
Dieses Phänomen — Context Rot oder Kontextdegradation — ist real, gut dokumentiert und in Evaluierungen sichtbar. Die Konsequenz: Sie können nicht einfach alles in den Kontext werfen und die Aufgabe als erledigt betrachten. Sie benötigen Context Engineering, also bewusste Entscheidungen darüber, was aufgenommen, zusammengefasst oder dynamisch abgerufen und wie der resultierende Kontext strukturiert wird.
Dieser Artikel behandelt die Muster und die Disziplin wirksamen Context Engineerings für anspruchsvolle Produktivsysteme.
Was Kontextdegradation bedeutet
Kontextdegradation bezeichnet die empirische Beobachtung, dass die Leistung großer Sprachmodelle mit wachsendem Kontext abnimmt — selbst innerhalb des technischen Grenzwerts.
Spezifische Fehlmodi:
Lost in the Middle (Liu et al., 2023). Modelle beachten Inhalte am Anfang und Ende des Kontexts stärker. Informationen in der Mitte werden weniger zuverlässig genutzt. Eine Tatsache an Position 50.000 eines Kontexts mit 100.000 Tokens wird eher übersehen als dieselbe Tatsache an Position 1.000 oder 99.000.
Aktualitätsbias. Modelle gewichten jüngere Inhalte übermäßig stark. Älterer Kontext in einem Gespräch wird dadurch faktisch unsichtbar.
Empfindlichkeit gegenüber Ablenkungen. Irrelevante Inhalte im Kontext verschlechtern die Leistung selbst bei Aufgaben, die diese Inhalte nicht benötigen. Das Modell muss filtern, und ein Teil des Störsignals wirkt dennoch auf die Ausgabe.
Die Qualität von Schlussfolgerungen sinkt. Mehrschrittige Schlussfolgerungen werden mit wachsendem Kontext unzuverlässiger. Das Modell muss mehr Informationen nachverfolgen, wodurch die Qualität leidet.
Kosten und Latenz. Unabhängig von der Qualität sind große Kontexte teuer (Abrechnung pro Token) und langsam (bei vielen Modellen linear zur Tokenzahl).
Das sind keine theoretischen Bedenken. Produktivsysteme mit naiv zusammengestellten großen Kontexten schneiden regelmäßig schlechter ab als Systeme mit kuratiertem Kontext.
Das Prinzip: Weniger ist mehr
Die zentrale Erkenntnis: Kontext ist eine wertvolle Ressource, deren Nutzen mit wachsender Menge abnimmt. Setzen Sie ihn strategisch ein.
Ein Kontext mit 30.000 Tokens und sorgfältig ausgewählten Inhalten übertrifft üblicherweise einen Kontext mit 300.000 Tokens, in den alles hineingeladen wurde. Qualität, Kosten und Latenz sprechen gleichermaßen für den kleineren Kontext.
Damit verschiebt sich die Entwicklungsaufgabe: nicht „Wie passt mehr in den Kontext?“, sondern „Was gehört wirklich hinein und wie wird es sinnvoll platziert?“
Das Kontextbudget
Betrachten Sie Kontext als ein Budget, das Sie gezielt zuweisen.
Eine typische Aufteilung für einen Kundensupport-Agenten:
Total context budget: 30K tokens
- System prompt: 1500 tokens (5%)
- Tool descriptions: 1000 tokens (3%)
- User profile / context: 500 tokens (2%)
- Conversation history summary: 1000 tokens (3%)
- Recent conversation turns (full): 4000 tokens (13%)
- Retrieved relevant knowledge: 12000 tokens (40%)
- User's current message: 500 tokens (2%)
- Output token budget (response): 10K tokens (33%)
Jede Komponente konkurriert um Platz. Mit wachsendem Kontext müssen Sie Kompromisse eingehen.
Die Disziplin besteht darin, die Aufteilung explizit festzulegen und keine Komponente unbegrenzt wachsen zu lassen.
Muster 1: Mehrstufiges Gesprächsgedächtnis
Bei Gesprächen über viele Runden wächst der vollständige Verlauf unbegrenzt. Die meisten Produktivsysteme verwenden deshalb ein mehrstufiges Gedächtnis:
Stufe 1: Jüngste Gesprächsrunden vollständig. Die letzten 5–10 Wortwechsel im Wortlaut.
Stufe 2: Ältere Gesprächsrunden zusammengefasst. Frühere Teile des Gesprächs werden zu einer kurzen Zusammenfassung komprimiert.
Stufe 3: Extrahierte Fakten. Wichtige Informationen aus dem Gespräch — Name, Präferenzen und getroffene Entscheidungen — werden als strukturierte Fakten gespeichert.
Umsetzung:
On each turn:
1. Take the conversation history.
2. The last 10 turns are kept verbatim.
3. Turns 11-30 are summarized into 200 words ("Earlier, the user discussed X and we agreed Y").
4. Turns 31+ are reduced to extracted facts ("User prefers Python. User is on enterprise tier.").
5. Total memory: ~2K tokens regardless of conversation length.
Dieses Muster ist für jedes lang laufende Gespräch grundlegend. Ohne diese Struktur nimmt die Qualität mit zunehmender Länge ab.
Eine wichtige Nuance: Die Zusammenfassung muss Informationen bewahren, die der Agent später benötigt. Wenn der Nutzer beispielsweise in Runde 5 eine Kontonummer nennt und der Agent sie nicht in das Langzeitgedächtnis übernimmt, ist sie bis Runde 50 verloren.
Führen Sie die Zusammenfassung mit expliziten Anweisungen durch, was bewahrt werden soll:
Summarize the conversation so far. Preserve:
- All facts about the user (name, role, preferences, account info).
- All decisions made.
- All open commitments or follow-ups.
- The current goal of the conversation.
Discard:
- Pleasantries.
- Repeated information.
- Detailed reasoning that's been resolved.
Muster 2: Just-in-Time-Retrieval
Laden Sie Kontext nicht vorab, sondern rufen Sie relevante Inhalte genau dann ab, wenn sie benötigt werden.
Ein Gegenmuster besteht darin, alle Dokumente eines Nutzers vorsorglich in den Kontext zu laden. Die meisten Abfragen benötigen nur einen kleinen Ausschnitt. Kontext wird verschwendet und die Leistung leidet.
Besser: Dokumente basierend auf der aktuellen Abfrage abrufen. Unterschiedliche Abfragen erhalten unterschiedliche Dokumente. Der Gesamtkontext pro Aufruf bleibt klein; Relevanz bleibt hoch.
Das ist schlicht diszipliziert angewendetes RAG. Lassen Sie sich nicht dazu verleiten, „einfach alles aufzunehmen, weil es möglich ist“. Selbst erfahrene Teams geraten angesichts großer Kontextfenster in diese Versuchung.
Muster 3: Komprimierte Darstellungen
Für Informationen, die im Kontext bestehen bleiben müssen, verwenden Sie komprimierte Darstellungen.
Ursprünglich (umfangreich):
The user has been working in software engineering for 8 years. They started at a small startup called Acme Corp where they worked on backend systems. After 3 years they moved to a larger company called Beta Inc where they did frontend work. They're currently at Gamma LLC working on machine learning systems.
Komprimiert:
User: SWE, 8 years, currently ML at Gamma LLC. Prior: backend@Acme (3yr), frontend@Beta.
Die komprimierte Version bewahrt die relevanten Fakten mit weniger Tokens. Für die meisten Zwecke kann das Modell beide Darstellungen gleich gut nutzen.
Wenden Sie diese Technik an:
- Nutzerprofile.
- Dokumentzusammenfassungen.
- Frühere Gesprächskontexte.
- Wissensdatenbankeinträge (wenn der vollständige Inhalt nicht benötigt wird).
Der Kompromiss: Komprimierung verliert Nuancen. Verwenden Sie vollständigen Text, wenn Nuancen wichtig sind; komprimiert, wenn nicht.
Muster 4: Hierarchisches Retrieval
Rufen Sie Inhalte aus sehr großen Wissensdatenbanken hierarchisch ab.
Schritt 1: Breite Kategorien oder Dokumentzusammenfassungen basierend auf der Abfrage abrufen.
Schritt 2: Rufen Sie innerhalb der relevantesten Kategorien bestimmte Chunks ab.
Schritt 3: Nehmen Sie nur die in Schritt 2 ausgewählten Chunks in den endgültigen Kontext auf.
Das vermeidet den Ansatz „Ich habe 10.000 Dokumente, also lade ich alle in den Kontext“. Der Trichter hält den Kontext stattdessen kompakt.
Variante: Ein kleiner LLM-Aufruf wählt die relevantesten Chunks aus, bevor sie in den Hauptaufruf gelangen. Das verursacht geringe Zusatzkosten, reduziert aber den Kontextumfang erheblich.
Muster 5: Reflexion über den Kontext
Lassen Sie Agenten bei lang laufenden Aufgaben regelmäßig prüfen, was sich im Kontext befindet und was dort noch benötigt wird.
Every 10 steps, the agent does:
1. Reviews its current context.
2. Identifies what's relevant to ongoing work.
3. Summarizes or drops anything no longer needed.
4. Notes what additional context might help.
5. Replaces the old context with the curated version.
Das ist eine Art Garbage Collection für den Kontext. Ohne sie sammeln Agenten veraltete Informationen an, die neue relevante Inhalte verdrängen.
Die Umsetzung erfordert eigene Orchestrierung — die meisten Frameworks unterstützen sie nicht nativ. Zwischen zwei Schritten durchläuft der Agent eine Phase zur Gedächtniskonsolidierung, die den Kontext neu zusammenstellt.
Muster 6: Dynamische Kontextfenster
Verschiedene Teile eines Agentenlaufs können unterschiedliche optimale Kontextgrößen haben.
- Entscheidungsschritte: Kleiner Kontext, fokussiert auf die unmittelbare Entscheidung.
- Syntheseschritte: Größerer Kontext, einschließlich vieler Quellen.
- Generierungsschritte: Mittlerer Kontextumfang mit Stil- und Formatreferenzen.
Jeder Schritt im Agentenablauf verwendet eine andere Kontextstruktur. Die Orchestrierung steuert, welche Inhalte in welchen Schritt gelangen.
Dafür muss der Agentenablauf in explizite Schritte statt in eine einzige große Schleife zerlegt werden. Die Frameworkwahl ist hier relevant: LangGraph bildet dies natürlich ab, bei einer direkten API ist manuelle Arbeit erforderlich.
Muster 7: Positionsbewusste Platzierung
Da Modelle mehr auf den Anfang und das Ende des Kontexts achten, platzieren Sie wichtigen Inhalt dort.
Weniger wirksam: Eine wichtige Anweisung ist in der Mitte eines langen System-Prompts verborgen.
Effektiver: Wichtige Anweisung am Anfang und erneut am Ende.
Bei RAG mit mehreren abgerufenen Dokumenten steht das relevanteste Dokument am Anfang, das zweitwichtigste am Ende und weniger relevante Dokumente in der Mitte.
Dies ist eine taktische Optimierung, hat aber messbare Auswirkungen auf die Ergebnisse.
Muster 8: Selektive Zusammenfassung
Nicht jede Zusammenfassung ist gleich gut. Richten Sie sie an den Anforderungen der nachgelagerten Aufgabe aus.
Schlecht: Eine generische Zusammenfassung, in der Nutzerpräferenzen verloren gehen.
Besser: Eine Zusammenfassung, die für die nachgelagerte Aufgabe relevante Nutzerpräferenzen ausdrücklich bewahrt.
Summarize this document focusing on:
- Technical decisions made.
- Stakeholders mentioned.
- Open questions or risks.
Drop:
- General context already known to the team.
- Repeated points.
Der Zusammenfassungs-Prompt ist auf die spätere Verwendung zugeschnitten.
Muster 9: Strukturierter Kontext
Fließtext ist eine Möglichkeit. Strukturierter Kontext — JSON, XML oder spezielles Markup — kann deutlich kompakter sein.
Ausführliche Prosa:
The customer's name is John Smith. He's been a customer since March 2023. His current plan is Pro, billed monthly at $29. He has 3 active integrations: Slack, Notion, and Linear. His usage in the last 30 days has been moderate — 1,250 API calls.
Strukturiert:
{
"customer": {
"name": "John Smith",
"since": "2023-03",
"plan": "Pro",
"billing": "monthly $29",
"integrations": ["Slack", "Notion", "Linear"],
"usage_30d": {"api_calls": 1250, "tier": "moderate"}
}
}
Die strukturierte Version ist kürzer und für das Modell häufig leichter nutzbar. Bestimmte Fakten lassen sich schnell finden.
Hinweis: Nicht alle Modelle verarbeiten strukturierte Eingaben gleich gut. Testen Sie beide Formate für Ihren Anwendungsfall.
Muster 10: Kontextschichten
Schichten Sie den Kontext nach Priorität. Hochprioritärer Inhalt ist immer enthalten; mittelprioritärer Inhalt ist enthalten, wenn relevant; niedrigprioritärer Inhalt wird bei Bedarf abgerufen.
Immer:
- System-Prompt (Identität, Verhalten).
- Aktueller Nutzerkontext (wichtige Fakten).
- Jüngste Gesprächsrunden.
Wenn relevant:
- Abgerufene Dokumente, die der Abfrage entsprechen.
- Werkzeugausgaben aus den jüngsten Schritten.
Bei Bedarf:
- Spezifische Daten, die der Agent über Werkzeugaufrufe anfordert.
- Historischer Kontext außerhalb des jüngsten Gesprächsausschnitts.
Das Muster „bei Bedarf“ ist für die Skalierung entscheidend: Der Agent ruft nur dann ab, was er tatsächlich benötigt, statt alles vorab zu laden.
Muster 11: Verdrängungsstrategien
Wenn der Kontext Grenzen erreicht, was wird entfernt?
- Aktualitätsbasiert: Der älteste Inhalt wird zuerst entfernt.
- Relevanzbasiert: Der für die aktuelle Aufgabe am wenigsten relevante Inhalt wird zuerst entfernt.
- Wichtigkeitsbasiert: Als unwichtig markierter Inhalt wird zuerst entfernt.
Ein praktisches Muster: Kennzeichnen Sie Kontextelemente mit Prioritätsstufen. Wenn Inhalte verdrängt werden müssen, entfernen Sie sie in Prioritätsreihenfolge.
context_items = [
{"content": "...", "priority": "critical"}, # Never evict
{"content": "...", "priority": "high"}, # Evict last
{"content": "...", "priority": "medium"}, # Evict if needed
{"content": "...", "priority": "low"}, # Evict first
]
def evict_to_fit(items, budget):
items_by_priority = sorted(items, key=lambda x: priority_value(x.priority))
while total_tokens(items) > budget:
items.remove(items_by_priority.pop(0)) # Remove lowest priority
return items
Muster 12: Caching für wiederholten Kontext
Viele Aufrufe verwenden denselben Kontext — denselben System-Prompt, dieselben Werkzeugbeschreibungen und dasselbe Nutzerprofil.
Die meisten Anbieter unterstützen jetzt Prompt-Caching:
- Anthropic: explizite
cache_control-Marker in Nachrichten. - OpenAI: automatisch bei Anfragen mit übereinstimmendem Präfix.
- Google: explizit zwischengespeicherte Inhalte über die API.
Wenn dasselbe Präfix wiederverwendet wird, ist die zwischengespeicherte Version schneller und günstiger — häufig um 90 %.
Bei Agenten mit vielen Aufrufen pro Sitzung sollten die statischen Teile — System-Prompt, Werkzeuge und Nutzerkontext — cachefähig sein. Platzieren Sie dynamische Inhalte wie den aktuellen Schritt und jüngste Ergebnisse hinter dem cachefähigen Präfix.
Dies ist eine der Optimierungen mit dem höchsten ROI. Bei einem statischen Präfix mit 10.000 Tokens, das in einer Sitzung über 50 Aufrufe hinweg wiederverwendet wird, fallen beim ersten Aufruf die vollen Kosten und bei den folgenden 90 % weniger an. Das ergibt erhebliche Einsparungen.
Muster 13: Kontextbewusste Prompts
Prompts können das Modell ermutigen, den Kontext gut zu nutzen:
Reference the documents below to answer the user's question. Always cite the specific document and quote relevant passages.
If you cannot find the answer in the provided documents, say so explicitly. Do not invent information.
When information from multiple documents is relevant, synthesize them and note any disagreements.
Diese Art des Promptings reduziert Halluzinationen bei kontextgestützten Aufgaben und verbessert die Qualität der Quellenangaben.
Wann Sie längeren Kontext einsetzen sollten
Trotz Kontextdegradation ist längerer Kontext für manche Aufgaben tatsächlich besser:
Analyse eines einzelnen Dokuments. Bei der Aufgabe „Analysieren Sie diesen Vertrag“ ist es oft besser, den gesamten Vertrag in den Kontext aufzunehmen, statt nur abgerufene Chunks zu verwenden.
Vergleich vieler Elemente. Beim direkten Vergleich von zehn Verträgen ist es hilfreich, alle zehn im Kontext zu haben.
Codebearbeitung im Kontext. Eine Funktion in einer Datei mit 5.000 Codezeilen zu ändern ist mit der vollständigen Datei im Kontext einfacher als mit abgerufenen Ausschnitten.
Zusammenfassung eines vollständigen Gesprächs. Eine Zusammenfassung eines langen Gesprächs gelingt mit dem vollständigen Kontext besser — bis zu einem gewissen Punkt.
Das Muster: Wenn die Aufgabe grundsätzlich das Verständnis von Beziehungen über viele Inhalte hinweg verlangt, hilft längerer Kontext. Genügt ein kleiner Ausschnitt, ist ein kleinerer Kontext besser.
Eine praktische Heuristik: Bis zu 50.000 Tokens funktionieren Kontexte in der Regel gut. 50.000–200.000 Tokens sind nutzbar, jedoch mit Qualitätsverlusten. Ab 200.000 Tokens schneiden Modelle häufig schlechter ab als mit kürzeren Kontexten. Testen Sie dies empirisch.
Disziplinierte Evaluierung
Wie erkennen Sie, ob Ihr Context Engineering funktioniert? Durch Evaluierungen.
Konkrete Evaluierungen:
Recall-Tests. Platzieren Sie Schlüsselinformationen an verschiedenen Positionen in langen Kontexten. Prüfen Sie, ob das Modell sie verwendet, und messen Sie den Recall in Abhängigkeit von der Position.
Ablenkungstests. Vergleichen Sie die Leistung bei derselben Abfrage mit und ohne irrelevanten Kontext. Messen Sie den Qualitätsverlust.
Vergleich von Long Context und RAG. Beantworten Sie dieselben Abfragen einmal mit vollständigem Kontext und einmal mit abgerufenen Chunks. Vergleichen Sie die Qualität.
Token-Effizienz. Qualität pro Euro. Mit wachsendem Kontext zahlen Sie mehr — wächst die Qualität entsprechend?
Diese Evaluierungen zeigen, ob Ihre Kontextentscheidungen tatsächlich helfen. Ohne sie raten Sie lediglich.
Ein vollständiges Beispiel: Rechercheassistent
Ein Praxisbeispiel: ein KI-Rechercheassistent für ein kleines Team.
Aufgabe: Fragen zu einem Korpus aus 200 Dokumenten beantworten (Fachartikel, interne Dokumente, Besprechungsnotizen).
Naiver Ansatz: Alle Dokumente in den Kontext aufnehmen (300.000 Tokens). Die Qualität ist akzeptabel, die Kosten sind hoch und die Latenz ist schlecht.
Durchdachter Ansatz:
Context budget: 25K tokens
- System prompt: 1500 tokens (cached)
- Tool descriptions (search, fetch_doc, etc.): 800 tokens (cached)
- Conversation memory: 1500 tokens (last 10 turns)
- Retrieved chunks for current query: 18000 tokens (top 12 chunks via RAG)
- User's current question: 200 tokens
- Output budget: ~3000 tokens
Der Agent ruft abhängig von der Frage dynamisch Chunks ab. Das Gesprächsgedächtnis hält den jüngsten Kontext, statische Elemente werden zwischengespeichert.
Ergebnis:
- Latenz: 2–3 Sekunden (gegenüber 10–15 Sekunden mit 300.000 Tokens Kontext).
- Kosten: ~€0,01/Abfrage (vs. ~€0,10).
- Qualität: besser, gemessen am Evaluierungsdatensatz, weil relevante Inhalte angemessen berücksichtigt werden.
So sieht diszipliniertes Context Engineering aus: keine einmalige Entscheidung, sondern kontinuierliche Optimierung.
Häufige Fehler
Einige Muster:
Fehler 1: „Mehr Kontext = besser.“ Längerer Kontext wird als Lösung für Qualitätsprobleme betrachtet. Häufig ist das Gegenteil der Fall.
Fehler 2: Kein Kontextbudget. Komponenten wachsen unbegrenzt. Der Abschnitt mit dem Nutzerprofil erreicht 5.000 Tokens, der mit abgerufenen Chunks 50.000. Es fehlt an Disziplin.
Fehler 3: Positionen ignorieren. Wichtige Anweisungen werden in der Mitte verborgen, in der Hoffnung, das Modell werde sie finden. Manchmal gelingt das, häufig nicht.
Fehler 4: Ausführliche Prosa für Fakten. Lange Sätze, obwohl strukturierte Daten ausreichen würden. Das verschwendet Tokens.
Fehler 5: Keine Gesprächszusammenfassung. Gespräche wachsen, bis sie Grenzwerte überschreiten. Dann werden ältere Inhalte abgeschnitten oder der Ablauf schlägt fehl.
Fehler 6: Kein Caching. Für wiederholte statische Präfixe fallen bei jedem Aufruf die vollen Kosten an. Leicht erzielbare Einsparungen bleiben ungenutzt.
Fehler 7: Keine Evaluierung der Kontextentscheidungen. Sie vertrauen darauf, dass „besseres Context Engineering“ funktioniert. Manchmal ist das nicht der Fall.
Fehler 8: Generische Zusammenfassung. Inhalte werden zusammengefasst, ohne die Anforderungen nachgelagerter Aufgaben zu berücksichtigen. Dabei gehen wichtige Informationen verloren.
Das Fazit
Lange Kontextfenster sind Realität, aber kein Freifahrtschein, Context Engineering zu ignorieren. Die Qualität sinkt lange vor den technischen Grenzen; Kosten und Latenz bleiben relevant.
Die Disziplin des Kontext-Engineering:
- Behandeln Sie Kontext als Budget.
- Staffeln Sie das Gedächtnis (jüngste Inhalte im Wortlaut, ältere zusammengefasst, älteste als Fakten).
- Rufen Sie Inhalte Just-in-Time statt vorsorglich ab.
- Komprimieren Sie, wo Komprimierung Informationen bewahrt.
- Platzieren Sie kritischen Inhalt an Positionen mit hoher Aufmerksamkeit.
- Schichten Sie Kontext nach Priorität.
- Cachen Sie statische Präfixe.
- Evaluieren Sie kontinuierlich.
Diese Muster erzeugen Systeme, die besser, schneller und günstiger funktionieren als naive „alles in den Kontext werfen“-Ansätze.
Für ausgereifte Produktivsysteme gehört Context Engineering zu den Bereichen mit der größten Hebelwirkung. Die technischen Grundbausteine sind einfach; die konsequente Anwendung trennt „Die Demo funktioniert“ von „Das System ist im Produktivbetrieb zuverlässig“.
Investieren Sie in diese Muster und etablieren Sie die notwendige Disziplin. Das Ergebnis sind KI-Systeme, die bei wachsenden Datenmengen, längeren Gesprächen und höherer Komplexität zuverlässig skalieren.
