Context Engineering: Ihr Token-Budget ist Ihre Architektur

Fragt man ein Engineering-Team, warum sein KI-Assistent falsche Antworten gibt, hört man meist eines von zwei Dingen: „Das Modell halluziniert“ oder „Wir brauchen ein besseres Modell“. Nach meiner Erfahrung lautet die ehrliche Antwort fast immer anders: Der Kontext, den wir dem Modell gegeben haben, war falsch, unvollständig oder schlecht angeordnet. Das Modell hat genau das getan, worum es mit dem gebeten wurde, was es bekam.

In diesem Artikel geht es darum, das Kontextfenster als das zu behandeln, was es ist — eine knappe, teure, strukturierte Ressource — und es mit derselben Sorgfalt zu entwerfen wie ein Datenbankschema oder ein Netzwerkprotokoll. Ich nenne das Context Engineering. Es ist der Teil der KI-Systemarbeit, der entscheidet, ob aus einem Piloten ein Produkt wird.

Tokens sind die Einheit von allem

Ein Sprachmodell sieht keine Wörter. Es sieht Tokens: Subwort-Einheiten, die ein Tokenizer erzeugt, typischerweise eine Variante von Byte-Pair-Encoding, trainiert auf einem großen Korpus. Ein häufiges englisches Wort ist oft ein Token; ein seltenes Wort, ein deutsches Kompositum, ein Produktcode oder ein JSON-Schlüssel können mehrere sein. Alles, was im Betrieb zählt, wird in Tokens gemessen:

• Kosten. Anbieter rechnen pro Eingabe- und Ausgabe-Token ab. Selbst gehostete Modelle kosten GPU-Zeit pro Token.
• Latenz. Die Zeit bis zum ersten Token wächst mit der Prompt-Länge; die Gesamtzeit mit der Ausgabelänge.
• Aufmerksamkeit. Die Fähigkeit des Modells, das Gegebene zu nutzen, ist endlich und ungleich über das Fenster verteilt.

Die praktische Konsequenz: Ein Token-Budget ist kein Nice-to-have. Für jeden Anfragetyp Ihres Systems — „Richtlinienfrage beantworten“, „Fallakte zusammenfassen“, „Antwort entwerfen“ — sollten Sie sagen können, wie viele Tokens auf Anweisungen, auf abgerufenes Material, auf Gesprächsverlauf und auf die Antwort entfallen, und warum.

Langer Kontext ersetzt Retrieval nicht

Kontextfenster sind von wenigen tausend auf Hunderttausende Tokens gewachsen, und es ist verlockend zu folgern, Retrieval sei überflüssig: Einfach alles hineinlegen. Drei Dinge sprechen dagegen.

Erstens skalieren Kosten und Latenz mit dem, was Sie hineinlegen — bei jeder einzelnen Anfrage. Ein Fenster, das zu 90 Prozent aus irrelevantem Material besteht, ist eine Rechnung für 90 Prozent Verschwendung.

Zweitens nutzen Modelle lange Kontexte nicht gleichmäßig. Die Arbeit von Liu und Kollegen zeigte, dass die Leistung bei Retrieval-artigen Aufgaben sinkt, wenn die relevante Passage in der Mitte eines langen Prompts steht statt am Anfang oder Ende. Neuere Modelle haben die Lücke verkleinert, aber „irgendwo im Fenster“ ist noch immer nicht dasselbe wie „das Modell wird es nutzen“.

Drittens, und für regulierte Umgebungen am wichtigsten: Was Sie ins Fenster legen, kann das Modell preisgeben, falsch zitieren oder als Handlungsgrundlage nehmen. Einem Assistenten einen ganzen Dokumentenbestand zu füttern, nur weil es geht, ist ein Verstoß gegen Datenminimierung, der nur noch auf seinen Prüfbericht wartet.

Retrieval-Augmented Generation — pro Anfrage eine kleine, relevante Menge von Passagen auszuwählen — bleibt der richtige Standard. Langer Kontext ändert, wie viel Sie sich abzurufen leisten können und wie Sie es anordnen, nicht ob Sie abrufen.

Chunking ist eine Modellierungsentscheidung

Die am meisten unterschätzte Designentscheidung in einem Retrieval-System ist, wie Dokumente in die Einheiten zerlegt werden, die eingebettet und abgerufen werden. Teams übernehmen oft einen Bibliotheksstandard (feste 500-Token-Fenster mit Überlappung) und verbringen dann Monate damit, Embedding-Modelle zu tunen, um das zu kompensieren.

Chunks sollten der Bedeutungsstruktur Ihrer Dokumente folgen. Eine Verordnung zerfällt natürlich in Artikel und Absätze; ein Vertrag in Klauseln; ein Runbook in Prozeduren; ein Support-Ticket in Problem, Kontext und Lösung. An diesen Grenzen zu schneiden erzeugt Chunks, die in sich geschlossen und zitierfähig sind — und das zählt doppelt: einmal für die Retrieval-Qualität, einmal für den Menschen, der die Zitatstelle lesen wird.

Zwei Techniken zahlen sich fast immer aus:

1. Kontextuelle Präfixe. Stellen Sie jedem Chunk vor dem Einbetten eine kurze Beschreibung seiner Herkunft voran — Dokumenttitel, Abschnittspfad, Datum, Verantwortlicher. Ein Chunk, der sagt „Abschnitt 4.2 der Auslagerungsrichtlinie Q3, gültig ab Januar 2026“, wird weit besser gefunden als der nackte Absatz. Anthropic hat eine einfache Version dieser Idee als Contextual Retrieval veröffentlicht; der Effekt ist groß, die Kosten sind ein einmaliger Vorverarbeitungsschritt.
2. Metadaten als Filter erster Klasse. Speichern Sie Rechtsraum, Produkt, Gültigkeitsdaten, Klassifizierung und Sprache neben jedem Chunk, und filtern Sie vor der Ähnlichkeitssuche. Die meisten falschen Antworten, die ich in Unternehmenssystemen untersucht habe, kamen von einem semantisch ähnlichen Chunk, der schlicht aus dem falschen Jahr, der falschen Gesellschaft oder der falschen Sprache stammte.

Reihenfolge und Rahmung im Fenster

Wenn Sie die richtigen Passagen haben, zählt ihre Platzierung. Ein verlässliches Muster:

• Systemanweisungen zuerst, kurz, mit Aufgabe, Rolle, Ausgabeformat und den Regeln für „Ich weiß es nicht“.
• Abgerufene Passagen danach, jede klar abgegrenzt und mit ihrer Quelle beschriftet, die relevantesten zuerst und zuletzt (die Positionen, die Modelle am besten beachten), weniger relevante in der Mitte.
• Gesprächsverlauf danach, gekürzt auf das, was für den aktuellen Schritt nötig ist.
• Die eigentliche Frage des Nutzers zuletzt, bei langen Gesprächen wiederholt.

Grenzen Sie Passagen mit expliziten Markierungen ab und verlangen Sie vom Modell, sie per Label zu zitieren. Zitieren ist keine Dekoration: Es erlaubt Ihnen, automatisch zu prüfen, ob die Antwort im Abgerufenen verankert ist — die Grundlage Ihrer Evaluation.

Messen, sonst raten Sie

Jede Änderung an Chunking, Retrieval, Reihenfolge oder Prompts sollte gegen einen festen Satz von Fragen mit bekannten guten Antworten und bekannten relevanten Quellen evaluiert werden. Verfolgen Sie mindestens:

• Retrieval-Recall bei k — haben es die relevanten Passagen ins Fenster geschafft?
• Antworttreue — wird jede Aussage der Antwort durch eine abgerufene Passage gestützt?
• Antwortkorrektheit — beurteilt gegen Referenzantworten, stichprobenartig durch Menschen und in der Breite durch ein Modell.
• Tokens und Latenz pro Anfrage — damit Qualitätsgewinne mit ihren Kosten sichtbar werden.

Das Evaluationsset sollte mit den Menschen gebaut werden, die das System nutzen werden, in ihrer Sprache, aus Fragen, die sie tatsächlich gestellt haben. Es ist das wertvollste Artefakt des Projekts — und das am häufigsten übersprungene.

Was das für Ihre Architektur bedeutet

Context Engineering verwandelt „Wir nutzen ein LLM“ in ein System mit expliziten Schnittstellen: eine Dokumentenpipeline, die wohlgeformte Chunks mit Metadaten erzeugt, eine Retrieval-Schicht mit Filtern und Re-Ranking, einen Prompt-Assembler mit Budget und eine Evaluationsumgebung, die Änderungen freigibt. Jeder Teil kann verantwortet, getestet und ersetzt werden — auch das Modell.

Es ist zugleich der Teil des Systems, den Ihre Risiko- und Compliance-Funktionen sehen wollen. Ein dokumentiertes Token-Budget, ein Retrieval-Log und eine Treue-Metrik sind genau die Nachweise, die aus „Die KI hat es gesagt“ einen vertretbaren Prozess machen.

Wenn Ihr Pilot mit zehn Dokumenten funktioniert und bei zehntausend zusammenbricht: Hier sollten Sie zuerst suchen.