Grundlagen

Context Engineering

Definition

Context Engineering ist die gezielte Auswahl und Aufbereitung der Informationen, die einem Modell zur Laufzeit beigelegt werden - die richtigen Fakten im richtigen Umfang, statt möglichst viel Text.

Der nächste Reifeschritt nach dem Prompt Engineering: Nicht nur wie man fragt zählt, sondern womit man das Modell versorgt. Denn ein Modell ist nur so gut wie sein Kontext. Zu wenig Kontext, und es rät; zu viel oder irrelevanter Kontext, und es verliert das Wesentliche zwischen Ballast.

Gutes Context Engineering entscheidet, welche Dokumentauszüge, Nutzerdaten und Zwischenergebnisse in das Kontextfenster gelangen - und in welcher Reihenfolge und Verdichtung. In RAG-Systemen und bei Agenten ist das die zentrale Qualitätsstellschraube: Sie bestimmt Trefferquote, Kosten und Verlässlichkeit oft stärker als die Wahl des Modells selbst.

In der Praxis

Ein Facility-Dienstleister räumt das Kontextfenster auf

Ein Facility-Management-Dienstleister betreut 600 Objekte und stellt seinen Objektleitern einen Assistenten für Fragen zu Verträgen, Wartungsplänen und Zuständigkeiten zur Verfügung. Die erste Fassung legte bei jeder Frage alles bei, was greifbar war: den vollständigen Objektvertrag, die letzten 20 Störmeldungen, das Nutzerprofil und den bisherigen Gesprächsverlauf - zusammen rund 30.000 Tokens pro Anfrage.

Das Ergebnis war ein Assistent, der langsam antwortete und auffällig allgemein blieb. Der Umbau betraf vier Punkte: Ein Suchschritt liefert nur noch vier Vertragsabschnitte statt des ganzen Vertrags; der Gesprächsverlauf wird nach jedem Austausch auf drei Sätze verdichtet; Objektstammdaten kommen als kompakte Tabelle statt als Fließtext; und die Reihenfolge wurde umgestellt - zuerst die Aufgabe, dann die Belege, zuletzt die Frage. Der beigelegte Umfang sank auf einen Bruchteil, die Antworten wurden konkreter.

Betrieblich ist Context Engineering damit keine einmalige Einstellung, sondern eine Pflegeaufgabe. Als das Unternehmen seine Wartungsdokumentation auf ein neues System umstellte, veränderten sich Struktur und Länge der Abschnitte - und die Trefferqualität sank schleichend, ohne dass eine Fehlermeldung auftrat. Bemerkt wurde es, weil protokolliert wird, welche Auszüge jede Antwort tatsächlich gestützt haben.

Abgrenzung

Nicht zu verwechseln mit

Prompt Engineering: Prompt Engineering formuliert die Anweisung, Context Engineering wählt das Material aus. Sobald eine Anwendung auf eigene Daten zugreift, entscheidet die Auswahl des Materials die Qualität meist stärker als der Wortlaut der Anweisung.
RAG: RAG ist ein Werkzeug des Context Engineering, nicht dasselbe. Über die Suche hinaus entscheidet Context Engineering auch über Gesprächsverlauf, Werkzeugausgaben, Stammdaten, Reihenfolge und Verdichtung - also über alles, was im Fenster landet.
Kontextfenster: Das Kontextfenster ist der verfügbare Platz, Context Engineering die Entscheidung darüber, wie er belegt wird. Ein größeres Fenster ersetzt diese Entscheidung nicht - es verschiebt nur den Punkt, an dem ihr Fehlen auffällt.

Fehlerbilder

Worauf es ankommt

Beilegen, was verfügbar ist
Weil das technisch leicht ist, wandert oft der gesamte erreichbare Datenbestand in jede Anfrage. Das kostet bei jedem Aufruf Geld, verlängert die Antwortzeit und lässt das Wesentliche zwischen Nebensächlichem untergehen. Jeder Baustein im Fenster sollte begründbar sein - sonst gehört er nicht hinein.
Werkzeugausgaben ungefiltert übernehmen
Antworten von Schnittstellen enthalten typischerweise Metadaten, technische Kennungen und Wiederholungen, die niemand braucht. Ungefiltert weitergereicht füllen sie das Fenster und lenken das Modell ab. Reduzieren Sie jede Werkzeugausgabe auf die Felder, die für die Antwort tatsächlich gebraucht werden.
Nicht protokollieren, was im Fenster stand
Wenn eine Antwort falsch war, ist die erste Frage: Lag der richtige Beleg überhaupt vor? Ohne Protokoll der tatsächlich beigelegten Auszüge ist die Fehlersuche Raten - und man repariert den Prompt, obwohl der Suchschritt das Problem war.
Den Gesprächsverlauf ungeprüft mitschleppen
Frühere Annahmen, korrigierte Zahlen und verworfene Zwischenstände wirken weiter, solange sie im Fenster stehen. Ein Assistent, der sich an eine widerrufene Auskunft hartnäckig erinnert, hat selten ein Modellproblem, sondern ein Kontextproblem - Verlauf verdichten, Widerrufenes entfernen.

Häufige Fragen

Was zu Context Engineering oft gefragt wird

Wie unterscheidet sich Context Engineering von Prompt Engineering?

Prompt Engineering betrifft die Anweisung: Aufgabe, Rolle, Format, Beispiele. Context Engineering betrifft das Material, das mit dieser Anweisung geliefert wird: welche Dokumentauszüge, welche Stammdaten, wie viel Gesprächsverlauf, in welcher Reihenfolge und Verdichtung. In einfachen Anwendungen genügt das Erste; sobald eigene Daten im Spiel sind, liegt der größere Hebel beim Zweiten.

Wie viel Kontext ist zu viel?

Ein praktischer Test: Streichen Sie einen Baustein und prüfen Sie an zwanzig echten Fällen, ob die Antwortqualität sinkt. Bleibt sie gleich, war der Baustein Ballast. Als Anhaltspunkt gilt, dass ein gut gebauter Assistent mit gezielten Auszügen meist einen kleinen Bruchteil selbst mittelgroßer Kontextfenster belegt - Anwendungen, die routinemäßig das Fenster ausreizen, haben fast immer ein Auswahlproblem.

Wer sollte im Unternehmen für den Kontext zuständig sein?

Die Auswahl ist eine fachliche Frage - welche Quelle gilt, welcher Stand ist maßgeblich, was ist bei Widerspruch führend - und gehört daher in den Fachbereich. Die IT baut die Auswahl, das Protokoll und die Messung. Ohne benannte fachliche Verantwortung veraltet der Kontext still, weil sich Quellen ändern, ohne dass jemand die Wirkung prüft.

Verwandte Begriffe