Kontext-Reduktion: Token-Kontext verkleinern ohne Qualitätsverlust

von Denis Shokhirev, Enterprise AI Architect aus Erlangen. In meiner Rolle bei DennisCraft AI Studio liefere ich produktive AI-Systeme für DACH-B2B-Kunden in Logistik, FinTech und Industrieautomatisierung – und setze dabei Claude, Supabase, n8n, Doppler sowie selbstgehostetes Postgres ein. In mindestens acht von vierzehn fertigen Projekten war die übermäßige Ausweitung des Kontextfensters der Engpass: Kontexte wachsen in der Praxis schneller als Modellgrenzen, und Standardlösungen aus Demos scheitern oft am regulierten Alltag.

Warum Kontexte im Produktivbetrieb wachsen

Gerade im regulierten Bereich (z.B. DSGVO, BSI Grundschutz, EU AI Act) sind umfangreiche Datenhistorien Pflicht. Selbst Claude 3 Opus unterstützt bis zu 200.000 Tokens (Anthropic-Dokumentation, 2024), doch bereits bei 10.000–20.000 Tokens wird die Verarbeitung langsam, teuer oder instabil. Meine Beobachtungen:

• Logistik: Komplette Sendungshistorien, technische Protokolle, SLA-Checklisten – oft über 15.000 Tokens pro Vorgang.
• FinTech: Transaktionsketten mit mehreren tausend Buchungen pro Nutzer, die in Echtzeit analysiert werden müssen.
• Industrie: Maschinen- und Wartungsprotokolle, Fehlermeldungen – bis zu 10.000 Tokens pro Diagnoselauf.

Kontextüberladung schlägt sich direkt auf Latenz, Kosten und Ergebnisqualität nieder. Modelle werden unpräzise, wenn irrelevante oder veraltete Daten den Prompt verwässern. Token-Overflows führen zu stillen Abschneidungen oder Fehlern.

Fünf praxiserprobte Methoden zur Kontext-Reduktion

Semantisches Chunking und RAG im produktiven Einsatz

Semantisches Chunking

Ich teile Dokumente nie stumpf nach n Tokens auf – das zerstört Zusammenhänge und Kontext. Stattdessen nutze ich semantische Einheiten (Absätze, Kapitel, nummerierte Abschnitte). Für die Praxis kombiniere ich sentence-transformers mit tiktoken:

from sentence_transformers import SentenceTransformer
import tiktoken

model = SentenceTransformer('all-MiniLM-L6-v2')
tokenizer = tiktoken.get_encoding('cl100k_base')

def semantic_chunks(text, max_tokens=1024):
    sentences = text.split('. ')
    current_chunk = []
    current_len = 0
    for sent in sentences:
        token_len = len(tokenizer.encode(sent))
        if current_len + token_len > max_tokens:
            yield ' '.join(current_chunk)
            current_chunk = [sent]
            current_len = token_len
        else:
            current_chunk.append(sent)
            current_len += token_len
    if current_chunk:
        yield ' '.join(current_chunk)

So bleibt der Kontext bei regulatorischen oder technischen Dokumenten erhalten.

RAG mit Supabase und pgvector

Für jede Recherche oder Suche im Langzeitarchiv setze ich Retrieval-Augmented Generation (RAG) ein. Dokumente indexiere ich mit pgvector in Supabase und suche vor dem Prompt nur die relevantesten Textstücke. Typischer n8n-Workflow:

// n8n RAG-Schritt
items = $input.all();
const query = items[0].json.query;
const results = await $supabase
  .from('documents')
  .select('content, embedding')
  .order('embedding', { ascending: false })
  .limit(5);
return results.data;

So schrumpft der Kontext von 20.000+ auf 1–2.000 Tokens – ohne Verlust an Relevanz oder Präzision.

Sliding Window Pruning und laufende Zusammenfassung

Sliding Window Pruning

Dialogagenten verlieren schnell an Nutzwert, wenn der Chatverlauf unkontrolliert wächst. Ich setze immer ein Sliding Window durch: Die letzten 5–7 Nachrichten plus eine laufende Zusammenfassung. Prompt-Größe bleibt so unter 2–3.000 Tokens – für Latenz und Stabilität unerlässlich. Beispiel für das Pruning:

def prune_context(messages, max_tokens=2048):
    pruned = []
    total = 0
    for msg in reversed(messages):
        tokens = len(tokenizer.encode(msg['content']))
        if total + tokens > max_tokens:
            break
        pruned.insert(0, msg)
        total += tokens
    return pruned

Laufende Zusammenfassung (Summarization)

Bei Logs oder Transaktionsketten lasse ich nach jeweils 1.000 Events eine Zusammenfassung durch GPT-4 oder Claude erstellen – so bleiben Ausreißer oder Anomalien sichtbar, ohne den Prompt zu überfrachten. In FinTech-Projekten spart das Zeit und Kosten.

Schema-basierte Filterung: Struktur nutzen

Bei strukturierten Daten (JSON, API-Antworten) filtere ich vor dem Prompting gezielt relevante Felder mit Pydantic oder eigenen Skripten. So bleibt der Kontext schlank und die Verarbeitung stabil:

from pydantic import BaseModel

class Transaction(BaseModel):
    id: str
    amount: float
    date: str
    status: str

def filter_transactions(raw):
    txs = [Transaction(**t) for t in raw if t['status'] == 'active']
    return txs

FAQ

Wie groß ist der tatsächliche Token-Einspareffekt?

In produktiven Systemen erreiche ich mit diesen Methoden meist eine Reduktion um den Faktor 5–10 (z.B. von 20.000 auf 2–4.000 Tokens) ohne Qualitätsverlust. Ich messe mit OpenAI tokenizer und vergleiche Latenz/Kosten.

Kommt Claude mit großem Kontext besser klar als OpenAI?

Ja – Claude 3 Opus erlaubt bis 200.000 Tokens. Dennoch steigen Latenz und Kosten mit wachsendem Kontext nicht-linear. Kontext-Reduktion bleibt Pflicht.

Wann ist RAG besser als Zusammenfassung?

RAG ist bei Dokumentensuche und Wissensdatenbanken überlegen. Bei Eventstreams oder Dialogen funktioniert laufende Zusammenfassung effizienter.

Gibt es Sicherheitsrisiken durch Kontext-Reduktion?

Ja, es droht der Verlust sicherheitsrelevanter Passagen. Ich prüfe mit semgrep, bandit und gitleaks auf sensible Muster – vor und nach der Reduktion.

Muss jeder Reduktionsschritt getestet werden?

Definitiv. Ohne Testabdeckung gehen kritische Inhalte schnell verloren. Ich nutze Unit-Tests (pytest) und Reviews für jede Pipeline.

Wo in Ihrer LLM-Pipeline wächst der Kontext am stärksten – bei Datensammlung, Agentenübergabe oder Logging? Ich freue mich auf Ihren Erfahrungsbericht. Ich biete DACH-Unternehmen einen kostenlosen 30-minütigen Stack-Audit für AI-Lösungen im regulierten Bereich an. Kontaktieren Sie mich auf LinkedIn oder schreiben Sie an @ger_dennis_ai.