Kürzere Eingaben, bessere KI-Antworten, weniger Kosten

Für Entscheider: Lohnt sich das in Ihrem Unternehmen?

Dieser Abschnitt beantwortet die beiden Vorfragen, die vor jeder Maßnahme stehen: Zahlen Sie überhaupt pro Token, und reicht Ihr Volumen? Wer hier zu dem Ergebnis kommt, dass nur Stufe 0 infrage kommt, hat eine richtige Entscheidung getroffen und kann sich den technischen Hauptteil sparen. Abbildung 1 zeigt den Weg im Überblick.

Vorfrage 1: Zahlen Sie pro Token?

Die Kostenrechnung dieses Papiers gilt nur für token-abgerechnete Schnittstellen. Das ist keine Nebenbedingung, sondern die Voraussetzung des gesamten Kostenarguments. Prüfen Sie zuerst, welcher Fall bei Ihnen vorliegt:

Der zweite Fall ist im Mittelstand der häufigste. Wichtig ist die saubere Trennung: Hundert Lizenzen können im Jahr deutlich mehr kosten als die Schwelle unten, ohne dass eine einzige Maßnahme aus Woche 1 möglich wäre. Die Schwelle bezieht sich auf den gemessenen Modellverbrauch, nicht auf Ihr KI-Budget insgesamt.

Vorfrage 2: Reicht Ihr Volumen?

Kontextoptimierung ist nicht kostenlos. Telemetrie, Testsatzpflege, Retrieval-Betrieb und Qualitätsgates binden Entwicklungs- und Betriebszeit dauerhaft. Die folgende Aufwandsschätzung ist eine Erfahrungsgröße dieses Whitepapers für ein Unternehmen ohne eigenes Team für maschinelles Lernen. Setzen Sie Ihre eigenen Zahlen ein, die Rechnung bleibt dieselbe.

Daraus folgt die Untergrenze nicht als gesetzte Zahl, sondern als Rechnung:

Ein Beispiel mit offengelegten Annahmen: 900 Euro Mischtagessatz aus interner und externer Leistung, 24 Monate Amortisation, 40 Prozent Kostenreduktion. Für Stufe 1 und 2 zusammen ergeben 3 bis 6 Personentage im Monat rund 2.700 bis 5.400 Euro laufend. Die 40 bis 80 Personentage Einmalaufwand entsprechen 36.000 bis 72.000 Euro, auf 24 Monate verteilt weitere 1.500 bis 3.000 Euro im Monat. Zu decken sind also 4.200 bis 8.400 Euro im Monat. Bei 40 Prozent Kostenreduktion entspricht das einem monatlichen Modellverbrauch von rund 10.500 bis 21.000 Euro. Abbildung 2 stellt Ersparnis und Aufwand gegenüber.

Bevor Sie optimieren: die billigeren Alternativen

Context Engineering ist nicht der einzige Weg zu einer niedrigeren Rechnung und selten der schnellste. Ehrlicherweise gehören diese Optionen zuerst geprüft, weil sie in Tagen statt Monaten wirken:

• Kleineres Modell: Wenn die Qualität für den Prozess reicht, senkt der Modellwechsel den Stückpreis sofort, ohne jede Umbauarbeit.
• Plattformfunktionen statt Eigenbau: Serverseitige Kompaktion, das Entfernen alter Werkzeugresultate und dynamische Werkzeugauswahl liefern einen Teil des Nutzens per Konfiguration (Abschnitte 6.2 und 7.1).
• Vertragliche Hebel: Zugesagte Abnahmemengen, Rahmenverträge und Anbieterwechsel wirken auf den Preis, nicht auf die Menge, aber sie wirken sofort.
• Volumen begrenzen oder Anwendungsfall streichen: Der billigste Token ist der, der nie gesendet wird. Manche Prozesse sind den Modelleinsatz schlicht nicht wert.
• Klassische Software statt Sprachmodell: Filtern, Summieren und Nachschlagen erledigt eine Datenbankabfrage zuverlässiger und praktisch kostenlos.
• Abwarten: Modellpreise fallen. Ein Umbau mit mehrjähriger Amortisation kann von der Preisentwicklung überholt werden.

Context Engineering lohnt sich dort, wo diese Wege ausgeschöpft sind, das Volumen trägt und die Qualität nachweisbar bleiben muss. Genau darum geht es im Rest dieses Papiers.

1. Was „Token sparen“ tatsächlich bedeutet

Ein kürzerer Prompt ist nur ein Teil des Problems. In produktiven Anwendungen entsteht der Verbrauch über eine Kette von Modellaufrufen, Werkzeugantworten, wiederholten Gesprächsverläufen, internem Reasoning und Ausgaben. Wer diese Größen vermischt, optimiert leicht die Rechnung, ohne den Kontext zu verkleinern, oder hält den Hauptagenten schlank, während Subagenten im Hintergrund ein Vielfaches verbrauchen.

Diese Trennung korrigiert einen verbreiteten Denkfehler. Prompt-Caching ist wirtschaftlich wertvoll, aber kein Context Engineering im engeren Sinn. Anthropic beschreibt Kontext treffend als endliche Ressource, die aus Systemregeln, Werkzeugen, Verlauf und externen Daten kuratiert werden muss [15]. Derselbe Anbieter weist ausdrücklich darauf hin, dass gecachte Präfixe weiterhin das Kontextfenster belegen. OpenAI weist Cache-Lese-Token in der Nutzungsstatistik als Eingabetoken aus, Google führt sie als eigene Kategorie neben der Eingabe [17, 26]. In beiden Fällen bleibt der Text im Kontextfenster; nur der Preis unterscheidet sich [27, 28]. Batching kann dieselbe Tokenmenge billiger verarbeiten [30]. Beide Maßnahmen gehören in die Kostenarchitektur, dürfen jedoch nicht als Verbrauchsreduktion berichtet werden.

1.1 Lokaler Kontext und globaler Verbrauch

Bei Agentensystemen müssen zwei Ebenen getrennt werden. Der lokale Kontext ist das Fenster eines einzelnen Agenten. Eine Delegation kann ihn entlasten, weil Rechercheprotokolle und Werkzeugausgaben in einem Subagenten bleiben. Der globale Verbrauch summiert dagegen alle Ein- und Ausgaben aller beteiligten Agenten. Er kann steigen, obwohl der führende Agent übersichtlicher arbeitet. In einem Produktionsbericht von Anthropic benötigten Agentensuchen ungefähr viermal und Multi-Agent-Suchen ungefähr fünfzehnmal so viele Token wie gewöhnliche Chats. Das ist ein Anbieter-Feldbericht, keine allgemeine Naturkonstante, aber eine klare Warnung vor der Gleichung „mehr Agenten = weniger Token“ [24].

2. Was der Forschungsstand bis Juli 2026 trägt

Große Kontextfenster schaffen Kapazität, aber keine Garantie, dass ein Modell diese Kapazität gleichmäßig nutzt. Vier Befundlinien sind für die Praxis besonders relevant: die Position wichtiger Informationen, die effektive statt nominelle Kontextlänge, die semantische Schwierigkeit des Wiederfindens und ein reiner Längeneffekt selbst bei korrektem Retrieval.

Zwei Einordnungen vorweg. Erstens stammen diese Messungen aus den Jahren 2024 und 2025 und damit von älteren Modellgenerationen. Sie belegen Mechanismen, die weiterhin plausibel sind, aber sie sind nicht an den heute verfügbaren Modellen nachgemessen. Bemerkenswert ist immerhin, dass die Anbieter den Effekt inzwischen selbst dokumentieren: Anthropic beschreibt in der eigenen Produktdokumentation, dass Genauigkeit und Trefferquote mit wachsender Tokenzahl nachlassen, und nennt das Phänomen ausdrücklich Context Rot [27]. Zweitens hat sich die Ausgangslage verschoben. Kapazität ist heute selten die bindende Restriktion, seit Modelle mit einem Kontextfenster von einer Million Token zum Standardpreis verfügbar sind [27]. Bindend sind zwei andere Größen: die Qualitätsdegradation bei wachsender Länge und der Preis je Token.

2.1 Relevante Information kann vorhanden und trotzdem schwer nutzbar sein

Liu et al. zeigten in Lost in the Middle, dass Modelle relevante Information am Anfang oder Ende langer Eingaben häufig besser verwerten als in deren Mitte [1]. RULER testete 17 Modelle mit nominell mindestens 32.000 Token Kontext. Nur etwa die Hälfte hielt bei 32.000 Token noch eine als zufriedenstellend definierte Leistung. Die Autoren betonen zugleich, dass synthetische Benchmarks die reale Nutzung nicht vollständig abbilden [2]. NoLiMa verschärfte die Aufgabe, indem die Antwort nicht über einfache Wortüberschneidungen auffindbar war. Bei 32.000 Token fielen 11 der 13 getesteten Modelle unter die Hälfte ihrer jeweiligen Kurzkontext-Leistung. Beim damaligen GPT-4o sank der ausgewiesene Wert von 99,3 auf 69,7 Prozent [3]. Beide Zahlen stehen nebeneinander, messen aber Unterschiedliches: RULER prüft gegen eine absolute Leistungsschwelle, NoLiMa gegen die Kurzkontext-Leistung jedes Modells selbst. Eine gemeinsame Skala ergibt sich daraus nicht.

Ein Befund von Du et al. ist für RAG-Systeme besonders unbequem: Längere Eingaben verschlechterten in fünf Modellen und mehreren Aufgaben die Leistung um 13,9 bis 85 Prozent, obwohl das relevante Dokument perfekt abgerufen worden war [4]. Die genaue Höhe ist benchmark- und modellabhängig. Der belastbare Schluss ist enger: „Die richtige Passage ist im Prompt“ reicht als Qualitätskontrolle nicht aus. Auswahl, Länge, Reihenfolge und Darstellung bleiben eigenständige Designvariablen.

2.2 Kürzer ist nicht automatisch besser

Aus den Langkontext-Befunden folgt kein pauschales „immer kürzen“. Eine zu aggressive Verdichtung kann Bedingungen, Zahlen, Ausnahmen oder Quellenbezüge entfernen. LLMLingua berichtete in vier untersuchten Datensätzen bis zu 20-fache Prompt-Kompression bei geringem Leistungsverlust [7]. LongLLMLingua erzielte bei NaturalQuestions mit ungefähr viermal weniger Token sogar einen höheren ausgewiesenen Wert und beschleunigte die Verarbeitung in den getesteten Einstellungen [8]. LLMLingua-2 zeigte zwei- bis fünffache Kompression und kürzere End-to-End-Laufzeiten [9]. RECOMP wiederum lernte extraktive und abstraktive Kompressoren und konnte bei irrelevanter Retrieval-Ausgabe auch leeren Kontext zurückgeben [10].

Die Zahlen sind keine allgemeinen Garantien. Sie stammen aus bestimmten Modellen, Datensätzen und Metriken. BRIEF-Pro berichtete 2026 in vier Multi-Hop-QA-Datensätzen für einen 70B-Reader 32-fache Kompression und im Mittel 4,67 Prozent bessere QA-Leistung als LongLLMLingua bei geringerem Rechenaufwand [11]. Der Vergleichspunkt lag dabei bei 9-facher Kompression, die Kompressionsgrade waren also nicht gleich. Auch dieser Wert beschreibt das untersuchte Setup, nicht jeden Geschäftsprozess. Neuere Arbeiten verschieben den Schwerpunkt deshalb von bloßer Antwortgüte auf Informations- und Nachweiserhalt. Łajewska et al. zeigen, dass verbreitete Kompressionsverfahren wichtige Details unterschiedlich gut bewahren [12]. In einem kontrollierten ASQA-/Self-RAG-Setup sank bei stärkerer LLMLingua-2-Kompression die Antwortkorrektheit nur um zwei bis vier Prozent, während das Grounding, also die Rückführbarkeit der Aussagen auf eine mitgelieferte Belegstelle, um 40 bis 50 Prozent einbrach. Eine hierarchische Priorisierung der Evidenz stellte sie weitgehend wieder her [13]. Die Studie erschien in einem Workshop und ist eng zugeschnitten. Gerade deshalb eignet sie sich als Risikosignal: Eine plausible Antwort kann ihren überprüfbaren Beleg verloren haben.

Eine Lücke bleibt in dieser Literatur bestehen, und sie betrifft ausgerechnet den Maßstab, den dieses Papier an anderer Stelle einfordert. Für Retrieval-Pipelines verlangt Abschnitt 5.1 mit Verweis auf Laitenberger et al. [14] den Vergleich gegen einfache Verfahren bei gleichem Tokenbudget. Für Prompt-Kompression liegt ein entsprechender Vergleich gegen schlichtes, strukturwahrendes Kürzen bei identischem Budget in den hier zitierten Arbeiten nicht vor. Wer Kompression einführt, sollte diesen Vergleich deshalb selbst als Kontrollbedingung mitlaufen lassen.

2.3 RAG, Long Context und Hybridbetrieb

Die RAG-Forschung liefert keine universelle Siegerarchitektur. Eine umfangreiche EMNLP-Studie zu Best Practices zeigt, dass Chunking, Retrieval, Reranking und Generierung als zusammenhängende Pipeline abgestimmt werden müssen [5]. Li et al. fanden, dass Long-Context-Verfahren bei ausreichenden Ressourcen eine höhere Leistung erreichen können, RAG aber häufig kostengünstiger ist. Ihr Self-Route-Ansatz wählte je Anfrage zwischen beiden Pfaden [6]. Neuere Vergleiche mahnen zusätzlich, einfache, strukturwahrende RAG-Baselines unter gleichem Tokenbudget gegen komplexe Pipelines zu testen [14].

Die praktische Folgerung lautet nicht „RAG statt Long Context“, sondern budgetiertes Routing: Kleine, eindeutige Fragen erhalten wenige, hochrangige Belegstellen. Globale Synthesen dürfen einen größeren Kontext oder einen gesonderten Long-Context-Pfad nutzen. Fälle mit geringer Retrieval-Sicherheit werden gekennzeichnet, nicht mit zusätzlichem Material überflutet. Der richtige Pfad wird anhand eines firmeneigenen Testsatzes gewählt.

3. Das Tokenbudget einer Aufgabe sichtbar machen

Eine einzelne Nutzungszahl verschleiert die Ursache. Für steuerbare Anwendungen wird der Verbrauch pro Modellaufruf in Komponenten und anschließend über alle Aufrufe einer Aufgabe summiert.

Das Modell macht einen oft übersehenen Skaleneffekt sichtbar. Wird bei jedem Gesprächsschritt der vollständige bisherige Verlauf erneut gesendet, wächst die Summe der Verlaufstoken ungefähr dreiecksförmig: Bei zehn gleich langen Beiträgen wird der erste Beitrag zehnmal, der zweite neunmal und der letzte einmal übertragen. Lange Werkzeugresultate verschärfen diesen Effekt. Ein Chat mit scheinbar moderaten 3.000 Token im letzten Request hat über zehn Schritte bereits das 5,5-Fache verbraucht, allgemein das (n+1)/2-Fache. Der Effekt gilt für den einfachen Fall, in dem der Verlauf bei jedem Schritt vollständig neu gesendet wird. Serverseitige Zustandsführung und Kompaktion (Abschnitt 6.2) dämpfen ihn, heben ihn aber nicht auf. Abbildung 3 macht den Zusammenhang sichtbar.

3.1 Welche Daten Sie protokollieren sollten

OpenAI bietet ein separates Token-Counting vor der Anfrage. Google weist in der Nutzungsmetrik Eingabe-, Ausgabe-, Gedanken-, Cache- und Werkzeugtoken getrennt aus [16, 17]. Die konkrete API unterscheidet sich je Anbieter. Das herstellerunabhängige Messschema bleibt gleich:

3.2 Ein Budget, das vor dem Modellaufruf greift

Ein Tokenbudget sollte nicht erst auf der Rechnung erscheinen. Es wird vor jedem Request geprüft. Prüfbar ist dabei nur die Eingabe, für die Anbieter ein separates Token-Counting vor der Anfrage bereitstellen [16]. Ausgabelänge und Reasoning entstehen erst während der Antwort: Sie werden über ein Ausgabelimit und über Effort-Stufen begrenzt und erst danach gemessen. Die folgende Aufteilung ist ein Startwert für einen wissensgestützten Assistenten, keine allgemeingültige Norm:

Zwei Hinweise zur Tabelle. Tokenzahlen sind nicht anbieterübergreifend identisch, weil die Zerlegung je Anbieter und Modell abweicht: Messen Sie mit dem Tokenizer des eingesetzten Modells. Und es fehlt bewusst eine Zeile für Reasoning-Token, weil diese sich vorab nicht zählen lassen. Wie der Startwert in Abschnitt 11 und die Schwelle in Abschnitt 13 ist diese Aufteilung eine Empfehlung dieses Whitepapers, kein Forschungswert.

Überschreitet der geplante Input das Budget, gilt eine feste Reihenfolge: alte Rohresultate entfernen, irrelevante Quellen aussortieren, abgeschlossene Verlaufsanteile in Zustand überführen, dann kontrolliert komprimieren. Reicht das nicht, wird die Aufgabe geteilt oder ein genehmigter Long-Context-Pfad gewählt. Stilles Abschneiden ist die schlechteste Option, weil es ausgerechnet Instruktionen oder Belege treffen kann.

planned = count(system + tools + state + evidence + user)
if planned > input_budget:
    remove_stale_tool_results()
    evidence = rerank_and_trim(evidence)
    state = compact_verified_state(state)
if count(...) > input_budget:
    route_to_split_task_or_approved_long_context()
log(component_tokens, calls, quality, groundedness)

3.3 Ein minimales Betriebs-Dashboard

Schon ein einfaches Ereignisschema verhindert Blindflug. Jede Aufgabe erhält eine pseudonyme task_id, einen Aufgabentyp, die gewählte Budgetklasse und ein Qualitätslabel. Jeder Modellaufruf erbt diese Kennung. So lassen sich Summen über Agenten und Wiederholungen bilden, ohne Inhalte des Prompts dauerhaft in das Kostenlog zu schreiben.

{
  "task_id": "…", "task_type": "policy_qa", "acceptance_class": "B",
  "variant": "kandidat_b", "agent_id": "planner", "parent_call": null,
  "call_no": 3, "model": "…", "model_version": "…",
  "route": "rag_normal", "ts": "2026-07-27T09:14:22Z",
  "tokens": {
    "system": 540, "tools": 310, "state": 680,
    "evidence": 1420, "user": 96,
    "reasoning": 210, "output": 286
  },
  "cached_read": 420,
  "tools_top": {"richtlinien_suche": 180, "dokument_abruf": 130},
  "retrieval": {"candidates": 30, "selected": 5, "recall": 0.93,
                "missing_required_facts": [], "aux_tokens": 1150},
  "quality": {"success": true, "grounded_claims": 0.96,
              "fact_coverage": 1.0},
  "control": {"retries": 0, "aborted": false, "escalated": false},
  "latency_ms": 2380, "error": null
}

Zwei Konventionen verhindern spätere Auswertungsprobleme. Erstens steht cached_read bewusst außerhalb des tokens-Objekts: Die Zahl ist ein Preisposten, kein Mengenposten, und darf nicht zu den Komponenten addiert werden. Zweitens gilt die Faustregel, dass jede Kennzahl, die später im Dashboard erscheinen soll, ein eigenes Feld im Ereignis braucht. Ohne variant lässt sich das Experiment aus Abschnitt 11 nicht auswerten, ohne agent_id und parent_call nicht über Agenten summieren, und ohne retries und aborted ist die Kennzahl aus Abschnitt 1 nicht bildbar.

Das Dashboard zeigt pro Aufgabentyp Median und p95 der Gesamttoken, Aufrufe, Erfolgsquote und Grounding. Der Wert p95 ist das 95. Perzentil, also der Wert, den nur die teuersten fünf Prozent der Fälle überschreiten. Zusätzlich braucht es eine Pareto-Ansicht: Welche zehn Prozent der Aufgaben verursachen den größten Verbrauch? Häufig lohnt es sich, diese Ausreißer gesondert zu routen, statt das Standardbudget für alle Fälle zu erhöhen. Promptinhalte, personenbezogene Daten und vertrauliche Dokumente gehören nicht automatisch in das Telemetriesystem.

4. Hebel 1: Auftrag, Ausgabe und Reasoning begrenzen

Bei manuellen Chats liegen die schnellsten Einsparungen selten in raffinierten Prompt-Formeln. Entscheidend sind ein klarer Arbeitsauftrag, ein überprüfbares Ziel und ein passendes Ausgabeformat. „Analysiere alles ausführlich“ erzeugt Suchraum und Text. „Entscheide anhand dieser vier Kriterien und nenne nur Abweichungen“ definiert eine endliche Arbeit.

4.1 Nur die Information anfordern, die eine Entscheidung verändert

Analysiere dieses Angebot ausführlich. Berücksichtige alle relevanten Aspekte und gib mir eine detaillierte Einschätzung.

Prüfe das Angebot ausschließlich auf:
1. Preisabweichung > 10 % zur Referenz,
2. fehlende Muss-Leistungen,
3. Laufzeit/Kündigung,
4. Haftungs- oder Datenschutzrisiken.

Ausgabe: Tabelle mit Befund, Belegstelle, Risiko (hoch/mittel/niedrig), nächste Aktion. Maximal 350 Wörter. Wenn kein Befund vorliegt, schreibe „keine Abweichung“. Keine allgemeine Zusammenfassung.

Der zweite Prompt kann etwas länger sein und trotzdem den Gesamtverbrauch senken. Er verhindert irrelevante Analyse, begrenzt die Ausgabe und reduziert Rückfragen. Prompt-Optimierung darf deshalb nicht auf die Länge des Nutzertexts verengt werden. Relevant ist der gesamte Aufgabenpfad.

4.2 Ausgabeformat vor Wortlimit

Ein hartes Ausgabelimit ohne Struktur kann die Antwort mitten im entscheidenden Punkt abschneiden. Besser ist eine abgestufte Regel: zuerst benötigte Felder definieren, dann Detailtiefe und Länge begrenzen. Für wiederkehrende Prozesse sollten die Felder maschinenlesbar sein, etwa entscheidung, belege, risiken, offene_punkte. Folgeinformationen werden nur auf Nachfrage erzeugt.

• Zusammenfassungen: Zielgruppe, Zweck und maximal fünf Kernaussagen festlegen.
• Entscheidungsvorlagen: nur Optionen, Kriterien, Unsicherheiten und Empfehlung ausgeben.
• Datenextraktion: Schema statt erläuternder Prosa verlangen.
• Fehleranalyse: nur wahrscheinlichste Ursache, Evidenz und nächsten Test anfordern.
• Recherche: Belegstellen und offene Evidenzlücken statt langer Nacherzählungen liefern lassen.

4.3 Reasoning und Schleifen kontrollieren

Ein höheres Denk- oder Effort-Budget kann bei schwierigen Aufgaben helfen, ist aber kein sinnvoller Standard für Routinefälle. Anbieter stellen dafür unterschiedliche Steuerungen bereit. Die herstellerunabhängige Regel lautet: Aufgaben zunächst nach Schwierigkeit routen, für Routinefälle ein konservatives Budget wählen und bei klaren Unsicherheits- oder Qualitätsindikatoren eskalieren. Bei Agenten kommen Schritt- und Werkzeugbudgets hinzu.

5. Hebel 2: Evidenz auswählen statt Dokumente anhängen

Für wissensgestützte Anwendungen ist Retrieval einer der größten Input-Hebel. Welcher Posten tatsächlich dominiert, Verlauf, Werkzeugdefinitionen, Evidenz oder Ausgabe, ist eine Messfrage und wird von der Baseline aus Abschnitt 3.3 beantwortet, nicht vorab angenommen. Das Ziel ist nicht, möglichst wenige Chunks zu senden, sondern die kleinste Evidenzmenge, die die Aufgabe vollständig trägt. Ein pauschales „Top 3“ oder „Top 5“ ist keine Best Practice. Die richtige Zahl hängt von Dokumentstruktur, Frageart, Redundanz und Qualitätsziel ab und wird am eigenen Testsatz ermittelt [5, 6, 14].

5.1 Struktur erhalten

Zu kleine Chunks sparen im Prompt, können aber Bedingungen von ihrer Ausnahme, Tabellenwerte von ihren Überschriften oder Schritte von ihrem Zweck trennen. Zu große Chunks erhöhen Ballast. Strukturwahrendes Chunking nutzt Überschriften, Absätze, Tabellen und Dokumenthierarchie. Ein kurzer Elternkontext kann den isolierten Ausschnitt verständlich machen. Laitenberger et al. argumentieren anhand tokenbudgetierter Vergleiche, dass solche einfachen, strukturwahrenden Baselines komplexeren RAG-Systemen ebenbürtig oder überlegen sein können [14].

5.2 Ein tokenbudgetierter Retriever

missing    = required_facts(query)
candidates = retrieve(query, filters, broad_k)
ranked     = rerank(query, deduplicate(candidates))
evidence   = []
for passage in ranked:
    if not missing:
        break
    claim = extract_claim_sentences(passage,
                keep=[heading, source_id, locator])
    facts = covered_facts(claim, missing)
    if facts and tokens(evidence + claim) <= evidence_budget:
        evidence.append(claim)
        missing = missing - facts
return evidence, missing

Zwei Details entscheiden über die Wirkung. Geprüft wird das Budget gegen den Extrakt, nicht gegen die volle Passage: Andernfalls verwirft der Retriever Passagen, deren Belegsätze bequem gepasst hätten, und füllt sein Budget systematisch nicht aus. Und covered_facts ist der Kern. Sie prüft nicht nur Ähnlichkeit zur Frage, sondern ob die Passage eine noch offene Anforderung belegt. Bei einer Vertragsprüfung können dies Frist, Preis, Haftung und Auftragsverarbeitung sein. Sobald alle Muss-Felder belegt sind, endet das Retrieval. Fehlt ein Feld, wird gezielt nachgesucht. So ersetzt ein fachlicher Vollständigkeitsbegriff die reflexhafte Vergrößerung von top_k.

5.3 Der firmeneigene RAG-Test

Ein kleines, gepflegtes Evaluationsset ist wertvoller als eine allgemeine Benchmark. Beginnen Sie mit 50 bis 100 realen Fragen. Hinterlegen Sie je Frage benötigte Fakten, zulässige Quellen und kritische Ausschlusskriterien. Testen Sie mindestens drei Budgetstufen. Messen Sie Retrieval-Recall, fachliche Richtigkeit, Grounding, Input-Token, Latenz und Kosten. Die kleinste Stufe, die den Qualitätsboden hält, wird zum Standard. Schwierige Fragetypen erhalten einen eigenen Pfad.

Wie dieser Satz zustande kommt, entscheidet über seine Aussagekraft. Ziehen Sie geschichtet nach Aufgabentyp und Verbrauchsdezil und überrepräsentieren Sie die teuersten zehn Prozent bewusst, denn eine reine Zufallsstichprobe unterrepräsentiert genau die Ausreißer, die Sie steuern wollen. Legen Sie namentlich fest, wer die richtige Antwort je Fall festlegt und wie Uneinigkeit aufgelöst wird; mindestens ein Fünftel der Fälle sollte doppelt bewertet werden. Und trennen Sie den Satz in zwei Teile: einen Arbeitsteil für die Auswahl der Budgetstufe und einen eingefrorenen Abnahmeteil, den Sie erst zur Freigabe anfassen. Wer auf demselben Satz optimiert und abnimmt, erhält systematisch zu optimistische Werte.

Der Testsatz ist zugleich ein Datenspeicher. Bei Richtlinienauskunft, Angebots- oder Vertragsprüfung enthält er echte Kunden-, Lieferanten- oder Beschäftigtendaten, die dauerhaft vorgehalten und regelmäßig durch Modelle geschickt werden. Bevorzugen Sie anonymisierte oder synthetische Varianten. Ist das fachlich nicht möglich, gehören Rechtsgrundlage, Zweckbindung, Zugriffskreis und Löschfrist vorab festgelegt, und es ist zu prüfen, ob eine Datenschutz-Folgenabschätzung erforderlich ist (Abschnitt 14).

5.4 Routing nach Frageart

Ein einziges Kontextbudget für alle Fragen ist bequem, aber teuer. Ein leichter Klassifikationsschritt kann die Aufgabe vor dem Retrieval einer Route zuordnen. Die Klassifikation selbst sollte regelbasiert oder mit einem kleinen Modell erfolgen und ihre Unsicherheit ausgeben.

6. Hebel 3: Löschen, verdichten und Zustand führen

Kompression ist erst der dritte Schritt. Was nicht mehr gebraucht wird, sollte gelöscht statt zusammengefasst werden. Was nur für einen Teil der Aufgabe relevant ist, sollte ausgewählt werden. Erst Informationen, die weiterhin notwendig, aber zu umfangreich sind, werden verdichtet. Diese Reihenfolge vermeidet, dass ein Modell viel irrelevantes Material teuer „intelligent“ komprimiert.

6.1 Gespräche als Zustand statt als Transkript

Ein produktiver Assistent braucht selten jede Formulierung des bisherigen Chats. Er braucht den aktuellen Arbeitszustand: Ziel, geltende Randbedingungen, getroffene Entscheidungen, verifizierte Fakten, offene Punkte und nächsten Schritt. Das vollständige Transkript kann revisionssicher außerhalb des Modellkontexts gespeichert bleiben. In den aktiven Kontext gelangt nur der strukturierte Zustand plus die letzten relevanten Beiträge.

ZIEL
- [ein Satz]

GELTENDE ANFORDERUNGEN
- [Muss-Kriterium + Quelle]

ENTSCHEIDUNGEN
- [Entscheidung | Grund | Datum]

VERIFIZIERTE FAKTEN
- [Fakt | Dokument-ID | Seite/Abschnitt]

OFFENE PUNKTE
- [Frage | benötigte Evidenz]

NÄCHSTER SCHRITT
- [genau eine prüfbare Aktion]

NICHT ERNEUT LADEN
- [abgeschlossene oder verworfene Pfade]

Das Schema ist bewusst knapp und quellenbewusst. Freie Zusammenfassungen neigen dazu, Unsicherheit in Tatsachen zu verwandeln. Deshalb tragen Entscheidungen ihren Grund und Fakten ihren Locator. Nach jedem Meilenstein wird ein neuer Zustand erzeugt und gegen die letzte Version geprüft. Änderungen an Zahlen, Namen, Fristen oder Negationen erfordern eine Rückprüfung am Original.

6.2 Kompaktion automatisieren, aber prüfbar halten

Aktuelle Plattformen bieten serverseitige Kompaktion oder das gezielte Entfernen alter Werkzeugresultate. OpenAI beschreibt Kompaktionsobjekte, die wesentliche frühere Zustände in weniger Token weitertragen [18]. Anthropic bietet Context Editing, das ältere Werkzeugresultate nach konfigurierbaren Regeln löscht und die Zahl entfernter Input-Token berichtet [19]. Solche Funktionen reduzieren Implementierungsaufwand. Sie entbinden nicht von fachlichen Tests, weil die intern erhaltene Information anbieter- und konfigurationsabhängig ist. Eine wirtschaftliche Nebenwirkung ist dabei leicht zu übersehen und stellt die Reihenfolge dieses Papiers an einer Stelle auf die Probe: Wer Inhalte aus einem bereits gecachten Präfix entfernt, macht den Cache-Treffer ungültig und bezahlt das Schreiben erneut. Anthropic weist ausdrücklich darauf hin und stellt dafür eine Mindestlöschmenge als Parameter bereit [19]. Praktisch heißt das: Löschen gehört an Meilensteine und an eine Mindestmenge gebunden, nicht in jeden einzelnen Request.

6.3 Qualitätstest für Kompression

Vergleichen Sie Original und komprimierte Fassung nicht nur semantisch. Erzeugen Sie aus dem Original eine Checkliste atomarer Anforderungen und lassen Sie anschließend automatisiert und stichprobenartig prüfen, welche davon in der Verdichtung erhalten sind. Ergänzen Sie Negations- und Zahlentests. Für quellengebundene Aufgaben muss außerdem jede erzeugte Kernaussage auf eine noch vorhandene Belegstelle zurückführbar sein. Ein Verfahren darf bei allgemeiner Antwortgüte gut aussehen und an diesem Grounding-Test scheitern [12, 13]. Damit der Test entscheidbar bleibt, braucht er drei Festlegungen: eine Erhaltungsquote, etwa alle Red-Line-Elemente aus Abschnitt 6.2 vollständig und mindestens 95 Prozent der übrigen Muss-Fakten; ein Kriterium, was „erhalten“ heißt, sinnvollerweise eine inhaltliche Ableitbarkeit statt wörtlicher Übereinstimmung; und einen Stichprobenumfang. Wird die Anforderungsliste selbst von einem Sprachmodell erzeugt, erbt der Test dessen Fehler: Diese Liste gehört mindestens stichprobenweise fachlich geprüft.

7. Hebel 4: Werkzeugdefinitionen und Rohresultate begrenzen

In agentischen Anwendungen entsteht Kontextballast häufig nicht durch Nutzertexte, sondern durch Werkzeuge. Jedes JSON-Schema, jede Parameterbeschreibung und jedes Rohresultat kann in den Modellkontext eingehen. Bei vielen MCP- oder API-Werkzeugen belegt allein der Katalog tausende Token, bevor die Aufgabe begonnen hat. Aktuelle Anbieterempfehlungen kombinieren deshalb dynamische Werkzeugauswahl, Codeausführung außerhalb des Modellverlaufs und das Entfernen alter Ergebnisse [20–23].

7.1 Werkzeuge bei Bedarf laden

Statt hundert vollständige Schemas in jeden Request zu legen, erhält das Modell zunächst Namen, Kurzbeschreibung oder eine Suchfunktion. Nur die für den aktuellen Schritt benötigten Werkzeuge werden vollständig geladen. Beide großen Anbieter dokumentieren dafür denselben Grundmechanismus unter dem Namen Tool Search: Werkzeuge werden erst bei Bedarf nachgeladen [20, 21]. Die Größenordnung zeigt ein Anbieterbeispiel: Ein Aufbau mit über 50 Werkzeugen aus MCP-Servern belegte rund 72.000 Token allein an Definitionen und rund 77.000 Token Gesamtkontext, bevor die eigentliche Arbeit begann; mit bedarfsgesteuertem Laden sank dieser Wert auf ungefähr 8.700 Token, vom Anbieter als 85 Prozent Reduktion berichtet. In der eigenen Umgebung desselben Anbieters wurden vor der Umstellung sogar 134.000 Token allein für Werkzeugdefinitionen gemessen. Beides sind Vendor-Benchmarks und ohne eigenen Test nicht übertragbar [22].

7.2 Rohdaten außerhalb des Verlaufs verarbeiten

Ein Tabellenexport mit 20.000 Zeilen sollte nicht an das Modell zurückgegeben werden, wenn der nächste Schritt nur fünf Summen braucht. Filterung, Aggregation, Sortierung und Joins gehören in deterministischen Code. Das Modell erhält Ergebnis, angewandte Filter, Zeilenzahl und einen Verweis auf das gespeicherte Artefakt. Anthropic beschreibt dieses Muster für programmatische Tool-Aufrufe und MCP-Codeausführung: Zwischenergebnisse bleiben in der Ausführungsumgebung, statt den Gesprächsverlauf aufzublähen [21, 23].

Gib nicht die Rohzeilen zurück. Liefere:
- Ergebnis: höchstens 20 Datensätze oder aggregierte Kennzahlen
- angewandte Filter und Zeitraum
- Anzahl gelesener und ausgeschlossener Zeilen
- Warnungen zu fehlenden/inkonsistenten Daten
- artifact_id für die vollständige Datei
- next_cursor nur, wenn weitere Daten wirklich benötigt werden

7.3 Lebensdauer von Werkzeugresultaten festlegen

Jedes Werkzeug braucht eine Kontext-Lebensdauer. Dauerhafte Fakten wandern mit Quelle in den strukturierten Zustand. Große Rohresultate werden nach Extraktion entfernt. Fehlerprotokolle bleiben nur bis zur Behebung aktiv. Veraltete Versionen werden ersetzt statt angehängt. Diese einfache Governance verhindert, dass ein Agent dieselben Daten in jedem Folgeschritt erneut bezahlt.

8. Hebel 5: Agenten nur dort einsetzen, wo Parallelität bezahlt

Ein Subagent kann Kontext isolieren, ist aber keine Kompressionsfunktion. Er erhält einen eigenen Systemprompt, Werkzeugdefinitionen und Arbeitsverlauf und erzeugt eine Rückgabe, die der führende Agent erneut lesen muss. Agenten lohnen sich, wenn unabhängige Teilaufgaben parallel bearbeitet werden können, der Informationswert hoch ist und der Rückgabevertrag streng bleibt. Für sequenzielle Aufgaben mit vielen gemeinsamen Abhängigkeiten ist ein einzelner Agent häufig sparsamer und konsistenter [24].

8.1 Entscheidungstest vor jeder Delegation

• Unabhängigkeit: Kann die Teilaufgabe ohne den vollständigen Hauptverlauf gelöst werden?
• Parallelitätswert: Spart parallele Bearbeitung relevante Zeit oder erweitert sie die Evidenzabdeckung?
• Informationswert: Ist das erwartete Ergebnis wichtig genug für einen zusätzlichen Modelllauf?
• Rückgabevertrag: Lässt sich das Ergebnis in wenigen strukturierten Feldern übergeben?
• Budgetierbarkeit: Sind maximale Schritte, Aufrufe, Token und Abbruchbedingungen festgelegt?

Eine Recherche nach zehn unabhängigen Wettbewerbern kann parallelisiert werden. Das fortlaufende Schreiben desselben Angebots durch mehrere Agenten erzeugt dagegen Übergaben, Wiederholungen und Konflikte. Anthropic beschreibt für langlaufende Agenten einen weiteren sinnvollen Mechanismus: frische Kontextfenster kombiniert mit strukturierten Fortschrittsartefakten und klaren Handoffs [25]. Das hält einzelne Sitzungen klein, verursacht aber Orchestrierungsaufwand. Auch hier muss die Summe über alle Sitzungen gemessen werden.

Aufgabe: Prüfe ausschließlich [Teilfrage].
Budget: max. 4 Modellaufrufe, 6 Quellen, 6.000 Gesamttoken.
Stop: sobald zwei unabhängige Primärquellen die Antwort tragen.
Rückgabe:
1. Ergebnis in max. 120 Wörtern,
2. bis zu 5 atomare Befunde,
3. Quelle + genauer Locator je Befund,
4. Widersprüche/Unsicherheit,
5. keine Suchchronik, keine Rohseiten.

Das Tokenbudget bezieht sich auf den Kontext des Subagenten, nicht auf die Rohdaten: Sechs abgerufene Webseiten überschreiten 6.000 Token bereits im Rohtext. Der Vertrag funktioniert deshalb nur zusammen mit der Verarbeitung außerhalb des Verlaufs aus Abschnitt 7.2.

8.2 Typische Agentenfehler und ihre Begrenzung

9. Hebel 6: Caching und Batch korrekt einordnen

Nachdem der Kontext fachlich reduziert ist, kann die verbleibende Verarbeitung wirtschaftlich optimiert werden. Prompt-Caching belohnt identische Präfixe. Statische Systemregeln, Beispiele und Werkzeugdefinitionen stehen deshalb am Anfang, dynamische Nutzer- und Retrieval-Daten am Ende. Selbst kleine Änderungen im Präfix können einen Cache-Treffer verhindern. Die genauen Schwellen, Haltezeiten und Preise sind anbieter- und modellabhängig und ändern sich. Maßgeblich ist die jeweils aktuelle Dokumentation [26–28].

Ein Punkt fehlt in den meisten Darstellungen und kehrt die Rechnung im ungünstigen Fall um. Das Schreiben in den Cache kostet einen Aufschlag auf den normalen Eingabepreis, je nach Haltezeit von einem Viertel bis zu einer Verdopplung; ein Treffer kostet dagegen nur einen Bruchteil, in der Größenordnung eines Zehntels [26, 27]. Wer Caches ausdrücklich anlegt statt sie automatisch entstehen zu lassen, zahlt bei manchen Anbietern zusätzlich eine Speichergebühr je Token und Stunde [28]. Daraus folgt eine Untergrenze: Ein Präfix, das innerhalb seiner Haltezeit nur ein einziges Mal wiederverwendet wird, ist mit Caching teurer als ohne. Erst ab dem zweiten bis dritten Treffer trägt sich die Maßnahme. Caching ist deshalb keine Einstellung, die man vorsorglich aktiviert, sondern eine Entscheidung je Präfix und Aufrufmuster. Abbildung 4 zeigt, ab welchem Treffer sie sich trägt.

Eine zweite Preisgröße wird häufig übersehen. Manche Anbieter berechnen oberhalb einer Kontextschwelle einen höheren Stückpreis für Ein- und Ausgabe, andere haben diesen Aufschlag abgeschafft und rechnen auch sehr große Fenster zum Standardpreis ab [27, 28]. Der genehmigte Long-Context-Pfad aus den Abschnitten 5.3 und 12 kann also je nach Anbieter nicht nur mehr Token bedeuten, sondern zusätzlich einen anderen Preis je Token. Prüfen Sie das, bevor Sie den Pfad freigeben.

Das Designziel lautet nicht „möglichst viel cachen“. Ein überlanger, fachlich unnötiger Präfix bleibt überlang und belegt Kontext. Zuerst wird gekürzt, danach stabilisiert und gecacht. Batch-Verarbeitung eignet sich für zeitunkritische Massenläufe wie nächtliche Klassifikation, Extraktion oder Evaluation. OpenAI dokumentiert für seine Batch API einen Preisnachlass gegenüber synchronen Aufrufen, aber die Tokenmenge der Aufgabe bleibt gleich [30].

Von allen Caching-Varianten spart genau eine tatsächlich Token: das Zwischenspeichern fertiger Antworten auf wiederkehrende Fragen, oft semantisches Caching genannt. Wird eine Frage erkannt, die inhaltlich bereits beantwortet wurde, entfällt der Modellaufruf vollständig. Für einen Wissens-Chat mit einem langen Ausläufer nahezu gleicher Fragen (Abschnitt 10.1) ist das häufig der größte Einzelhebel überhaupt, und er wirkt sofort auf Menge und Preis. Der Preis dafür ist Governance: Es braucht eine Ähnlichkeitsschwelle, eine Gültigkeitsdauer und eine Invalidierung, sobald sich die zugrunde liegende Richtlinie ändert. Eine veraltete Antwort aus dem Cache kostet mehr, als jeder gesparte Token einbringt.

10. Drei konkrete Anwendungsmuster

10.1 Wissens-Chat für interne Richtlinien

Ausgangsproblem: Der Assistent erhält bei jeder Frage mehrere vollständige Handbücher sowie den gesamten Chatverlauf. Antworten werden langsam, widersprüchliche Versionen landen gemeinsam im Prompt und jede Folgefrage sendet alles erneut.

Erfolgsmessung: Gesamttoken je erfolgreich beantworteter Frage nach der Definition aus Abschnitt 1, also einschließlich Rückfragen und Fehlläufen, dazu Anteil korrekter Richtlinienversionen, Faktenabdeckung, Grounding und Anteil nötiger Rückfragen. Ein bloßer Kostenrückgang ohne erhaltenes Grounding ist kein Erfolg. Weil sich in diesem Muster viele Fragen inhaltlich wiederholen, gehört das Antwort-Caching aus Abschnitt 9 hier zu den ersten Hebeln.

10.2 Dokumentenprüfung, etwa Verträge oder Angebote

Ausgangsproblem: Ein 80-seitiges Dokument wird vollständig mit einer offenen Aufforderung analysiert. Das Modell produziert eine lange Zusammenfassung, aber keine zuverlässige Abdeckung der Prüfkriterien.

Zielarchitektur: Zuerst werden Dokumentstruktur und relevante Abschnitte lokal ermittelt. Dann arbeitet die Prüfung kriteriumsweise: Für jedes Muss-Kriterium werden passende Klauseln extrahiert, Seitenbezüge erhalten und nur diese Belege an das Modell gesendet. Globale Abhängigkeiten, etwa Definitionen oder Anlagenverweise, werden gezielt nachgeladen. Das Ergebnis ist eine Matrix aus Kriterium, Befund, Beleg, Risiko und offenem Punkt.

Erfolgsmessung: gefundene kritische Klauseln, Fehlalarme, Abdeckung der Prüfliste, belegte Aussagen sowie Gesamttoken und Bearbeitungszeit je vollständig geprüftem Dokument, Wiederholungen eingerechnet. Rechtliche Bewertungen bleiben qualifizierter Fachprüfung vorbehalten.

10.3 Recherche- und Analyseagent

Ausgangsproblem: Ein Agent sucht iterativ, hängt jede Webseite und jedes Tool-Ergebnis an den Verlauf und startet Subagenten ohne Grenze. Der führende Agent sieht am Ende eine große Suchchronik statt einer Evidenzbasis.

Zielarchitektur: Der Planer zerlegt die Frage in höchstens fünf unabhängige Evidenzlücken. Jede Teilaufgabe erhält Such-, Aufruf- und Tokenbudget sowie einen strengen Rückgabevertrag. Rohseiten und Duplikate bleiben außerhalb des Hauptkontexts. Der Syntheseagent erhält nur atomare Befunde, Locator, Widersprüche und verbleibende Lücken. Eine zweite Suchrunde startet ausschließlich für klar benannte Lücken.

Erfolgsmessung: Gesamttoken aller Agenten je belastbar beantworteter Frage, Quellenqualität, Grounding, doppelte Quellen, Suchrunden und Zeit bis zur belastbaren Antwort. Eine schlanke Abschlussantwort darf nicht über einen explodierenden Hintergrundverbrauch hinwegtäuschen.

11. Einsparungen mit einem Qualitätsgate absichern

Tokenoptimierung ist ein kontrolliertes Experiment. Die bisherige Konfiguration bleibt Kontrollgruppe, die schlankere Variante ist der Kandidat. Beide laufen auf denselben repräsentativen Aufgaben. Fachliche Prüfer oder belastbare automatische Kriterien bewerten die Ergebnisse blind gegenüber der Variante. Nur dann lässt sich vermeiden, dass eine erwartete Kostenersparnis die Qualitätsbewertung unbewusst beeinflusst.

Als interner Startpunkt kann ein Unternehmen beispielsweise mindestens 20 Prozent weniger Token bei nachweislich gehaltener Qualität verlangen. Damit bleibt der Anspruch des Titels intakt: Ziel ist nicht, Qualität gegen Token zu tauschen, sondern denselben Qualitätsboden mit weniger Token zu halten. Wo ein Tausch nötig wäre, ist die Optimierung an ihrer Grenze angelangt.

Für die Qualitätsseite entscheidet allerdings das Prüfverfahren, nicht die Zielzahl. Ein Testsatz aus 50 bis 100 Fällen kann kleine Unterschiede gar nicht auflösen: Bei hundert Fällen und einer Erfolgsquote um 90 Prozent liegt allein die Unsicherheit einer einzelnen Messung bei etwa sechs Prozentpunkten, bei fünfzig Fällen bei rund acht. Eine Toleranzgrenze von zwei Prozentpunkten wäre dort keine Aussage, sondern Rauschen. Sie zuverlässig zu messen verlangt vierstellige Fallzahlen.

Praktikabel ist deshalb ein anderes Kriterium. Bewerten Sie Kontrolle und Kandidat auf denselben Fällen, betrachten Sie die Differenz je Fall und verlangen Sie, dass die untere Grenze ihres Vertrauensbereichs eine vorher festgelegte Schranke nicht unterschreitet. Weil Modellausgaben nicht deterministisch sind, gehören mindestens drei Wiederholungen je Fall und Variante dazu, berichtet als Median mit Streuung. Legen Sie außerdem vorab eine Hauptkennzahl fest: Wer fünf Gates gleichzeitig scharf schaltet, lehnt einen guten Kandidaten allein durch Zufall in rund vier von zehn Fällen ab.

Ein Wort zu automatischen Bewertern. Sie bevorzugen messbar längere Antworten, und die schlanke Variante fällt systematisch kürzer aus. Der Effekt wirkt also gegen den Kandidaten. Randomisieren Sie die Reihenfolge und prüfen Sie den automatischen Bewerter auf einer Teilstichprobe gegen fachliches Urteil, bevor Sie ihm eine Freigabeentscheidung überlassen.

Diese Werte sind Governance-Empfehlungen dieses Whitepapers, keine universellen Forschungsgrenzwerte. Für Recht, Sicherheit, Medizin, Finanzen oder verbindliche Kundenkommunikation sollte der Qualitätsboden strenger sein und eine menschliche Freigabe einschließen. Eine Grenze der Methode bleibt ohnehin: Wer in hundert Fällen keinen Fehler findet, hat damit eine wahre Fehlerrate von bis zu drei Prozent nicht ausgeschlossen. Für Prozesse mit hoher Wirkung ist das zu grob. Dort ersetzt kein Testsatz die fachliche Freigabe.

11.1 Abnahmeklassen für die interne Freigabe

Die folgenden Klassen steuern die interne Qualitätsfreigabe. Sie sind bewusst nicht die Risikokategorien des europäischen KI-Rechts und ersetzen die dortige Einstufung nicht. Ein Prozess kann hier in der mittleren Klasse liegen und nach Anhang III der KI-Verordnung dennoch ein Hochrisiko-System sein, etwa bei der Vorauswahl von Bewerbern. Nehmen Sie die rechtliche Einstufung getrennt vor (Abschnitt 14).

• Klasse A, geringe Wirkung: Stil, interne Ideensammlung, unverbindliche Zusammenfassung. Moderate automatische Qualitätsprüfung kann genügen.
• Klasse B, mittlere Wirkung: interne Entscheidungen, Angebote, Richtlinienauskunft. Testset, Quellenprüfung und Stichproben durch Fachverantwortliche.
• Klasse C, hohe Wirkung: rechtliche, sicherheitskritische, medizinische oder finanzielle Folgen. Kein Rollout allein aufgrund von Tokenmetriken. Qualifizierte menschliche Prüfung bleibt Pflicht.

12. Der 30-Tage-Plan für den Mittelstand

Der Plan setzt die beiden Vorentscheidungen aus dem Entscheidungsteil am Anfang dieses Papiers voraus: ob Sie überhaupt pro Token abgerechnet werden und ob Ihr Volumen den Aufwand trägt. Danach richtet sich, wie weit Sie gehen.

Der Plan gliedert sich in drei Stufen. Stufe 0 umfasst präzisen Arbeitsauftrag, festes Ausgabeformat, Abbruchbedingungen, keine Volldokumente im Prompt und die Zustandsvorlage aus Abschnitt 6.1. Sie kostet ein bis zwei Personentage, braucht keine Telemetrie und lohnt sich in jedem Fall. Stufe 1 ist Woche 1 samt dem Messanteil von Woche 2: Telemetrie, Testsatz und Qualitätsgate. Sie ist ausdrücklich nicht kostenfrei, sondern der aufwendigste Einzelposten des Programms, und sie lohnt ab etwa 2.000 bis 3.000 Euro Modellverbrauch im Monat. Stufe 2 sind die Wochen 3 und 4. Die Wochenbezeichnungen beschreiben die Reihenfolge, nicht die Dauer: Woche 3 liefert einen Piloten, der vollständige Umbau ist ein eigenes Projekt.

Ein Schritt gehört an den Anfang und nicht ans Ende. Ein System, das je Aufgabe Erfolg, Fehler und Bearbeitungszeit erfasst und sich einzelnen Nutzern zuordnen lässt, ist im Regelfall mitbestimmungspflichtig und datenschutzrechtlich zu würdigen. Binden Sie Datenschutzbeauftragten und Betriebsrat ein, bevor die erste Zeile Telemetrie produktiv läuft. In der Praxis ist das der längste Posten im Terminplan, nicht die Entwicklung.

Woche 1: Baseline und Kostentreiber

Wählen Sie einen klar abgegrenzten Anwendungsfall mit ausreichendem Volumen. Definieren Sie die erledigte Aufgabe und sammeln Sie 50 bis 100 Fälle, geschichtet nach Aufgabentyp und Verbrauch wie in Abschnitt 5.3 beschrieben. Protokollieren Sie Tokenkomponenten, Modellaufrufe, Latenz, Cache-Anteil, Ergebnisqualität und Fehler. Zerlegen Sie die teuersten zehn Prozent der Aufgaben. Häufig werden lange Historien, Werkzeugdefinitionen, Rohresultate oder ausufernde Ausgaben als Haupttreiber sichtbar. Rechnen Sie für diesen Schritt mit zehn bis zwanzig Personentagen und damit eher mit zwei Kalenderwochen. Ohne eigene Schnittstelle oder ein zentrales Gateway ist er nicht durchführbar; in diesem Fall ersetzt der Anbieterfragebogen aus Abschnitt 12.1 die eigene Messung.

Woche 2: Schnelle, risikoarme Kürzungen

Begrenzen Sie Ausgabeformat und Detailtiefe, entfernen Sie doppelte Systemregeln und unnötige Beispiele, verschieben Sie Rohdateien aus dem Prompt und setzen Sie harte Schrittbudgets. Stabilisieren Sie wiederkehrende Präfixe für spätere Cache-Treffer, berichten Sie die Wirkung jedoch getrennt. Führen Sie nach jeder Änderung das Qualitätsgate aus. Planen Sie die dafür nötige Zeit im Fachbereich ein: Jeder Durchlauf bindet die Personen, die die Ergebnisse bewerten, und das ist in der Praxis der Engpass, nicht die Entwicklung.

Woche 3: Retrieval und Zustand

Pilotieren Sie auf dem gewählten Prozess Metadatenfilter, Reranking, Deduplizierung und ein Evidenzbudget. Ersetzen Sie vollständige Gesprächsverläufe durch einen strukturierten Zustand und die letzten relevanten Beiträge. Definieren Sie Red-Line-Informationen, die nicht frei komprimiert werden. Testen Sie mindestens drei Kontextbudgets auf demselben Evaluationsset. Planen Sie dabei realistisch: Diese Woche liefert einen Piloten und eine Entscheidungsgrundlage. Ein vollständiger Retrieval-Umbau über alle Wissensquellen ist ein Entwicklungsprojekt von typischerweise drei bis sechs Monaten, kein Vier-Wochen-Sprint.

Woche 4: Werkzeuge, Agenten und Rollout

Laden Sie Werkzeuge dynamisch, aggregieren Sie große Ergebnisse außerhalb des Modellverlaufs und definieren Sie deren Lebensdauer. Prüfen Sie jede Agentendelegation mit dem Fünf-Punkte-Test aus Abschnitt 8. Aktivieren Sie Caching und Batch für die verbleibende stabile Last. Dokumentieren Sie Standardbudget, Eskalationspfad, Qualitätsboden, Verantwortliche und Rückfalloption. Legen Sie dabei namentlich fest, wer Budgets, Qualitätsgates und Dashboard nach dem Rollout dauerhaft betreibt. Kontextoptimierung ist Betrieb, nicht Projekt.

12.1 Schnellcheck vor dem Produktivgang

Die folgende Liste kann als Abnahmekarte für einen einzelnen Prozess verwendet werden. Jede mit „nein“ beantwortete Frage verweist auf einen konkreten nächsten Test. Wer die Lösung eingekauft statt selbst gebaut hat, nutzt dieselbe Liste als Fragebogen an den Anbieter. Schon die Frage, ob Token über alle Agentenaufrufe summiert werden, beantworten die wenigsten Anbieter belastbar. Eine ausweichende Antwort ist selbst ein Befund. Zur Auswertung: Die vier mit K. o. markierten Fragen sind Ausschlusskriterien, ein Nein blockiert den Produktivgang. Bei den übrigen gilt als Faustregel, dass bis zu zwei Nein vertretbar sind, sofern für jedes ein terminierter nächster Schritt festgehalten ist; ab drei Nein fehlt die Steuerungsfähigkeit.

12.2 Was das Unternehmen selbst leisten muss

Werkzeuge, Plattformfunktionen und externe Unterstützung ersetzen fünf Eigenleistungen nicht. Sie verlangen Wissen über die eigenen Prozesse und bleiben deshalb im Unternehmen:

Vier der fünf Punkte liegen im Fachbereich, nicht in der IT. Ohne benannte Rolle, zugestandenes Zeitbudget und Rückendeckung der Führung verfällt der Testsatz binnen eines Quartals, und das Qualitätsgate wird zur Fassade.

13. Wirtschaftlichkeit ohne Scheinmultiplikation

Eine belastbare Kalkulation trennt Mengen- von Preiseffekten. Angenommen, eine Aufgabe benötigt heute 8.000 Input- und 1.000 Output-Token. Retrieval, Zustandsführung und kürzere Werkzeugresultate senken den Input in einem validierten Test auf 3.200 Token, der Output bleibt bei 1.000. Die echte Verbrauchsreduktion beträgt dann 4.800 von 9.000 Gesamttoken, also 53,3 Prozent. Erst auf diesen verkleinerten Prompt werden Cache-Rabatt, Modellpreis oder Batch-Tarif angewandt.

Diese 53,3 Prozent sind eine Mengenangabe, keine Kostenangabe, und ausgerechnet in diesem Abschnitt wäre die Verwechslung unangenehm. Ausgabe-Token werden bei allen großen Anbietern deutlich teurer abgerechnet als Eingabe-Token, üblich ist das Drei- bis Fünffache, und Reasoning-Token zählen zum Ausgabepreis. Rechnet man dasselbe Beispiel bei vierfachem Ausgabepreis durch, sinken die Kosten je Aufgabe um rund 40 Prozent statt um 53. Bei einem Verhältnis von eins zu acht bleiben etwa 30 Prozent. Berichten Sie deshalb immer beide Zahlen getrennt: Tokenreduktion und Kostenreduktion. Abbildung 5 zeigt den Abstand zwischen beiden.

Die Monatswirkung berechnet sich aus Aufgabenvolumen, Erfolgsquote und Wiederholungen. Eine billige Antwort, die wegen eines Fehlers erneut erzeugt oder manuell korrigiert werden muss, kann pro erfolgreicher Aufgabe teurer sein. Deshalb gehören Nacharbeit, Eskalation und Abbruchquote in den Business Case. Aktuelle Anbieterpreise sollten nicht dauerhaft in das Whitepaper eingebaut werden, weil sie sich ändern. Die aktuelle Cost-Optimization-Dokumentation nennt weniger Requests, weniger Input, kürzere Outputs und ein geeignetes kleineres Modell als getrennte Hebel [29].

Zur Kalkulation gehört eine Untergrenze, und sie ist nicht für alle Maßnahmen dieselbe. Kontextoptimierung verursacht eigene Kosten: Telemetrie, Testsatzpflege, Retrieval-Betrieb und Qualitätsgates binden Entwicklungs- und Betriebszeit dauerhaft. Der Entscheidungsteil am Anfang dieses Papiers rechnet das mit offengelegten Annahmen durch. Das Ergebnis in Kürze: Stufe 0 lohnt sich immer, auch ohne jede Messung. Stufe 1 mit Telemetrie und Testsatz lohnt ab etwa 2.000 bis 3.000 Euro Modellverbrauch im Monat. Der vollständige Umbau der Stufe 2 trägt sich grob erst ab 10.000 bis 20.000 Euro im Monat, weil ihm 40 bis 80 Personentage Einmalaufwand und drei bis sechs Personentage im Monat an laufendem Betrieb gegenüberstehen.

Wie der Startwert in Abschnitt 11 sind diese Schwellen Empfehlungen dieses Whitepapers auf Basis offengelegter Annahmen, keine Forschungsgrenzwerte. Setzen Sie Ihre eigenen Tagessätze und Ihre eigene Amortisationszeit ein, die Struktur der Rechnung bleibt dieselbe. Und bevor Sie überhaupt in diese Rechnung einsteigen, prüfen Sie die billigeren Alternativen aus dem Entscheidungsteil: ein kleineres Modell, vorhandene Plattformfunktionen, vertragliche Hebel oder der begründete Verzicht auf einen Anwendungsfall wirken in Tagen statt in Monaten.

14. Datensparsamkeit, Grenzen und Methodik

Ein kleinerer Kontext kann zugleich die Menge vertraulicher oder personenbezogener Daten reduzieren, die an einen Modellanbieter übertragen wird. Das unterstützt den Grundsatz der Datenminimierung aus Art. 5 DSGVO [31]. Es ersetzt weder Rechtsgrundlage, Auftragsverarbeitungsvertrag, Löschkonzept, Zugriffskontrolle noch eine Prüfung internationaler Übermittlungen. Besonders bei Retrieval und Logging muss geklärt sein, welche Daten dauerhaft gespeichert und wer sie einsehen darf. Konkret heißt das: festlegen, welche Felder des Telemetrie-Ereignisses aus Abschnitt 3.3 dauerhaft im Log landen und welche nicht, wer diese Logs einsehen darf, wie lange sie aufbewahrt und wie sie gelöscht werden. Verarbeitet ein externer Anbieter die Daten, gehören Auftragsverarbeitungsvertrag und Löschkonzept dazu, bevor die erste Telemetrie produktiv läuft. Der Testsatz aus Abschnitt 5.3 ist dabei ausdrücklich mitgemeint: Er enthält häufig echte Kunden- oder Beschäftigtendaten und ist ein dauerhafter Datenspeicher, kein Testartefakt.

Neben dem Datenschutz steht das europäische KI-Recht, und der Zeitpunkt ist unmittelbar. Die Pflicht zur KI-Kompetenz der eigenen Leute nach Art. 4 der KI-Verordnung gilt bereits seit dem 2. Februar 2025. Zum 2. August 2026 wird der überwiegende Teil der Verordnung anwendbar, darunter die Transparenzpflichten nach Art. 50 und die Pflichten für Hochrisiko-Systeme nach Anhang III; die Einstufung über Art. 6 Abs. 1 folgt ein Jahr später [32]. Zwei Punkte sind hier praktisch relevant. Erstens sind die Abnahmeklassen aus Abschnitt 11.1 interne Qualitätsstufen und keine Rechtskategorien: Die Vorauswahl von Bewerbern etwa kann intern in der mittleren Klasse liegen und nach Anhang III trotzdem ein Hochrisiko-System sein, mit Dokumentations-, Protokollierungs- und Aufsichtspflichten. Zweitens arbeitet die Telemetrie aus Abschnitt 3.3 der Protokollierungspflicht solcher Systeme zu. Wer sie ohnehin einführt, sollte sie gleich so schneiden, dass sie beides bedient. Das ist eine Einordnung und keine Rechtsberatung; die Einstufung im Einzelfall gehört fachlich geprüft.

Innerbetrieblich kommt die Mitbestimmung hinzu. Ein System, das je Aufgabe Erfolg, Fehler und Bearbeitungszeit erfasst und sich einzelnen Beschäftigten zuordnen lässt, ist eine technische Einrichtung, die zur Verhaltens- und Leistungsüberwachung geeignet ist. Nach § 87 Abs. 1 Nr. 6 BetrVG löst bereits diese Eignung die Mitbestimmung aus, unabhängig von der Absicht [33]. Pseudonymisierung mildert das, hebt es aber nicht auf. Hinzu kommen die Unterrichtungspflicht beim Einsatz Künstlicher Intelligenz und das Recht des Betriebsrats, Sachverstand hinzuzuziehen. Die Feldliste aus Abschnitt 3.3 eignet sich unmittelbar als Anlage einer Betriebsvereinbarung. Planen Sie diesen Schritt als Ersten ein, nicht als Letzten.

Dieses Whitepaper ist eine fokussierte Literatur- und Praxisübersicht mit Stichtag 27. Juli 2026. Berücksichtigt wurden peer-reviewte Arbeiten zu Langkontext, RAG und Prompt-Kompression sowie aktuelle Primärdokumentation der Plattformanbieter. Anbieterberichte wurden nur als Implementierungs- oder Felderfahrung verwendet und entsprechend gekennzeichnet. Benchmarkwerte sind nicht direkt zwischen Modellen, Datensätzen und Messverfahren vergleichbar. Sie belegen Mechanismen und Risiken, nicht die Einsparung eines konkreten Unternehmens. Die Langkontext-Befunde stammen aus den Jahren 2024 und 2025 und sind an heutigen Modellgenerationen nicht nachgemessen. Alle Budget-, Schwellen- und Aufwandswerte sind als solche gekennzeichnete Empfehlungen dieses Whitepapers, keine Forschungswerte.

Vier Grenzen bleiben. Erstens verändern Modelle und APIs ihr Verhalten schnell. Zweitens können Aufgaben mit globalen Dokumentabhängigkeiten von großem Kontext profitieren [6]. Drittens erzeugt Kontextoptimierung eigene Komplexität: Retrieval, Kompression und Agentenrouting müssen betrieben und überwacht werden. Diese Zusatzkomplexität braucht einen dauerhaften Eigentümer. Vor dem Ausbau steht deshalb eine Make-or-buy-Entscheidung: selbst bauen und betreiben, einkaufen und den Anbieter mit dem Schnellcheck aus Abschnitt 12.1 prüfen, oder bewusst beim einfachen Pfad bleiben. Ein Interessenkonflikt gehört dabei offen benannt: Wer die Integration gebaut hat und nach Aufwand oder mit einem Aufschlag auf den Verbrauch abrechnet, soll nun den Verbrauch halbieren. Regeln Sie das vertraglich, mit Optimierung zum Festpreis oder gegen Beteiligung an der Ersparnis, mit Tokenreporting nach den Feldern aus Abschnitt 3.3 als Bringschuld, mit dem Eigentum an Testsatz und Telemetriedaten beim Auftraggeber und mit einer Ausstiegsklausel. Der Schnellcheck gehört in die Ausschreibung, nicht erst in die Abnahme. Viertens schließlich gilt der Kostenteil dieses Papiers nur für token-abgerechnete Schnittstellen; wer Künstliche Intelligenz ausschließlich als Lizenz pro Nutzer bezieht, findet hier das Qualitäts-, aber nicht das Kostenargument. Der belastbare Weg ist deshalb nicht maximale Kürzung, sondern die kleinste getestete Evidenzmenge, die den fachlichen Qualitätsboden hält.

Kurzglossar

• Token: die Abrechnungseinheit von Sprachmodellen, grob ein Wortteil. Ein deutscher Fließtext hat ungefähr anderthalb Token je Wort.
• Kontextfenster: die Menge an Text, die ein Modell bei einer Anfrage gleichzeitig berücksichtigen kann, einschließlich seiner eigenen Antwort.
• Grounding, auch Quellenverankerung: der Anteil wichtiger Aussagen, der sich auf eine tatsächlich mitgelieferte Belegstelle zurückführen lässt. Dieses Papier verwendet durchgängig den Begriff Grounding.
• Retrieval, auch RAG: das gezielte Heraussuchen passender Textstellen aus eigenen Dokumenten, statt ganze Dokumente in den Prompt zu laden.
• Reranking: ein zweiter Sortierschritt, der die gefundenen Textstellen nach Aufgabenrelevanz ordnet.
• Chunk: ein Textabschnitt, in den ein Dokument für die Suche zerlegt wird.
• Reasoning-Token, auch Denk-Token: interne Zwischenschritte des Modells vor der Antwort. Sie werden zum Ausgabepreis abgerechnet.
• Prompt-Caching: das Wiederverwenden eines identischen Textanfangs zu einem niedrigeren Preis. Es verkleinert das Kontextfenster nicht.
• MCP (Model Context Protocol): ein verbreiteter Standard, über den Sprachmodelle externe Werkzeuge und Datenquellen ansprechen.
• p95: das 95. Perzentil, also der Wert, den nur die teuersten oder langsamsten fünf Prozent der Fälle überschreiten.
• PT: Personentag, ein Arbeitstag einer Person.

Quellen