Context Corruption: Warum dein KI-Agent vergisst, was du ihm gesagt hast
TL;DR
Context Corruption ist der schleichende Verfall der LLM-Performance mit wachsendem Kontext. Bei 10.000 Tokens trackt das Modell 100 Millionen Token-Beziehungen. Bei 100.000 Tokens sind es 10 Milliarden. Das Ergebnis: Halluzinationen, vergessene Instruktionen und inkonsistentes Verhalten. Die gute Nachricht: Mit Context Engineering lässt sich das Problem managen.
Das Problem: Mehr Kontext, weniger Verstand
Du kennst das Szenario: Eine komplexe Coding-Session mit Claude. Die ersten Stunden laufen perfekt. Dann schleichen sich Fehler ein. Das Modell “vergisst” Architekturentscheidungen. Halluziniert APIs. Kehrt zu Patterns zurück, die du längst korrigiert hast.
Das ist kein Bug. Es ist Context Rot - eine architektonische Realität moderner LLMs.
Die Mathematik dahinter
Transformer-Architekturen erzeugen paarweise Beziehungen zwischen allen Tokens. Die Komplexität wächst quadratisch:
| Tokens | Beziehungen zu tracken |
|---|---|
| 1.000 | 1 Million |
| 10.000 | 100 Millionen |
| 100.000 | 10 Milliarden |
Jede zusätzliche Information konkurriert um dieselbe begrenzte Aufmerksamkeit. Das Modell verliert die Fähigkeit, frühe Instruktionen mit späteren Kontexten zu verbinden.
Die drei Gesichter der Context Corruption
1. Context Rot (Performance-Degradation)
Der häufigste Fall: Schleichende Qualitätsverluste über lange Sessions.
Symptome:
- Vergessene System-Prompts
- Inkonsistente Code-Patterns
- Wiederholung bereits korrigierter Fehler
- Halluzinierte Funktionen und APIs
Eine Studie von Chroma fand, dass selbst triviale Aufgaben wie “Wiederhole diesen String” bei gefüllten Kontextfenstern fehlschlagen.
2. Context Contamination (Unbeabsichtigte Korruption)
Information aus abgeschlossenen Tasks blutet in neue Aufgaben:
Praktisches Beispiel: Ein Entwickler bemerkte, dass Claude nach mehreren Code-Updates mit direktem Deployment begann, jeden Code-Update automatisch mit Deployment zu assoziieren - selbst bei experimentellem, unfertigen Code.
Das Modell lernte eine Assoziation, die nie explizit gelehrt wurde.
3. Context Poisoning (Böswillige Korruption)
Der Sicherheitsaspekt: Eingeschleuste Instruktionen in externem Content.
Angriffsvektoren:
- Versteckter Text in Webseiten (weiße Schrift, Mikro-Fonts)
- Manipulierte MCP-Tool-Descriptions
- Vergiftete RAG-Knowledge-Bases
Real-World Incident: Der Perplexity Comet-Vorfall - Angreifer versteckten unsichtbaren Text in Reddit-Posts, der User-OTPs leakte, sobald die KI den Content zusammenfasste.
Anthropic’s Forschung: 250 Dokumente reichen
Eine beunruhigende Erkenntnis aus Anthropics Zusammenarbeit mit dem UK AI Security Institute:
Nur 250 bösartige Dokumente im Pretraining reichen aus, um Backdoors in LLMs von 600M bis 13B Parametern zu installieren.
Die Annahme, größere Modelle bräuchten proportional mehr vergiftete Daten, ist falsch. Das Sicherheitsperimeter endet nicht beim Modell - es umfasst alles, was in den Kontext fließt.
Mitigation: Context Engineering in der Praxis
1. Context Editing (Anthropics Ansatz)
Automatisches Entfernen veralteter Tool-Calls und Ergebnisse:
// Pseudocode für Context-Pruning
function pruneStaleContext(messages: Message[], tokenLimit: number) {
const staleToolCalls = messages.filter(
m => m.type === 'tool_result' && isStale(m, Date.now())
);
return messages.filter(m => !staleToolCalls.includes(m));
}
Ergebnis: 84% reduzierter Token-Verbrauch in 100-Turn-Evaluationen.
2. External Memory
Wichtige Informationen gehören nicht in den Kontext, sondern in persistente Speicher:
# project-memory.md
## Architektur-Entscheidungen
- Wir nutzen Zod für Schema-Validierung
- API-Responses sind immer camelCase
- Tests: Vitest, nicht Jest
## Aktuelle Bugs
- Auth-Token wird nicht refresht (Issue #42)
Claude kann diese Datei bei Bedarf lesen, statt alles im Kontext zu halten.
3. Just-in-Time Retrieval
Statt alles vorab zu laden: Referenzen halten, bei Bedarf abrufen.
❌ Schlecht:
"Hier ist der komplette Inhalt aller 50 Dateien..."
✅ Gut:
"Die relevanten Dateien sind:
- src/auth/token.ts (Token-Management)
- src/api/client.ts (API-Client)
Lies sie, wenn du sie brauchst."
4. Explizite Session-Resets
Langlaufende Sessions akkumulieren Kontext-Müll. Der /clear Command in Claude Code existiert aus gutem Grund.
Best Practice: Bei Task-Wechseln explizit kommunizieren:
---
NEUER TASK: Feature X
Vorheriger Kontext (Bugfixing) ist nicht mehr relevant.
---
5. Multi-Agent Architektur
Spezialisierte Sub-Agents mit sauberen Kontexten. Nur kondensierte Ergebnisse fließen zurück.
# Lead Agent erhält:
"Sub-Agent (Code-Review) meldet:
- 3 Security-Issues gefunden
- Alle in src/auth/*.ts
- Details in review-report.md"
# Nicht:
[50.000 Tokens Review-Protokoll]
Die Kosten von Context Mismanagement
| Problem | Auswirkung |
|---|---|
| Überfüllter Kontext | Langsamere Responses, höhere API-Kosten |
| Vergessene Instruktionen | Inkonsistenter Output, Nacharbeit |
| Halluzinationen | Bugs in Production, Debugging-Zeit |
| Security-Lücken | Prompt Injection, Daten-Leaks |
OWASP 2025: Prompt Injection ist die #1 Vulnerability in LLM-Applikationen - gefunden in 73% der Produktions-Deployments.
Praktisches Playbook
Vor langen Sessions
- CLAUDE.md anlegen - Stabile Projektinfos außerhalb des Kontexts
- Memory-Dateien definieren - Was muss persistieren?
- Klare Exit-Kriterien - Wann ist ein Task beendet?
Während der Session
- Task-Grenzen markieren - Explizite Übergänge kommunizieren
- Regelmäßig compacten - Alte Tool-Results entfernen
- Assumptions validieren - “Verstehst du noch, dass wir Zod nutzen?”
Bei Problemen
- Session resetten -
/clearund neu starten - State externalisieren - In Dateien dokumentieren
- Debuggen, nicht kämpfen - Neuer Context ist billiger als Frustration
Der Mindset-Shift
Alt: Den Kontext füllen, bis er überläuft. Neu: Kontext als knappe Ressource behandeln.
Jedes unnötige Token degradiert aktiv die Performance. Die Kunst liegt nicht im Hinzufügen, sondern im Weglassen.
Fazit
Context Corruption ist keine Frage des Ob, sondern des Wann. Transformer-Architekturen haben fundamentale Grenzen, und längere Kontextfenster verschieben das Problem nur.
Die Lösung liegt im Context Engineering:
- Externalisiere, was persistieren muss
- Prune, was nicht mehr relevant ist
- Strukturiere, was der Agent braucht
Behandle den Kontext wie RAM - wertvoll, begrenzt und für das Wesentliche reserviert.
Weiterführende Links
