Context Engineering

Context Engineering Context Engineering ist die systematische Arbeit an allem, was ein Sprachmodell außer dem eigentlichen Prompt zu sehen bekommt. Dazu zählen Dokumente, der bisherige Gesprächsverlauf, feste Systemregeln und Daten, die erst zur Laufzeit abgerufen werden. Es entscheidet, was in das begrenzte Kontextfenster darf und was draußen bleibt, damit das Modell mit echtem Wissen antwortet statt mit Wahrscheinlichkeiten zu raten. Anders als Prompt Engineering, das die einzelne Anweisung formuliert, baut Context Engineering die Informationsumgebung drumherum, meist über RAG, Vektordatenbanken und System-Prompts.

Was Context Engineering bedeutet

Ein Prompt reicht, solange die Aufgabe klein ist. Sobald ein Sprachmodell echtes Fachwissen braucht, aktuelle Zahlen oder den Verlauf eines längeren Gesprächs, reicht die beste Formulierung allein nicht mehr. Context Engineering ist die systematische Arbeit an dem, was das Large Language Model über den Prompt hinaus zu sehen bekommt: Dokumente, Gesprächsverlauf, abgerufene Daten, Systemregeln. Es geht um das Design der Umgebung, in der die KI arbeitet, nicht um die einzelne Anweisung.

In der Praxis schließt Context Engineering eine Lücke, die jedes Modell mitbringt. Ein Standardmodell weiß nur, was in seinen Trainingsdaten stand, und das ist fast immer veraltet. Über gezieltes In-Context Learning speist man relevantes Wissen direkt in den laufenden Prozess ein, bevor das Modell überhaupt eine Antwort formuliert. Das Modell rät dann seltener, weil es seltener raten muss.

Wer KI im Unternehmen skalieren will, kommt an dieser Verschiebung nicht vorbei: weg von der einzelnen kreativen Eingabe, hin zu einer Daten-Pipeline, die zuverlässig liefert. Auch Anthropic beschreibt in den eigenen Best Practices, wie stark die Qualität eines langen Kontextfensters die Antwort beeinflusst, unabhängig vom Prompt selbst.

Wo die Grenze zu Prompt Engineering verläuft

Die beiden Begriffe werden ständig verwechselt, dabei ist die Trennung simpel. Prompt Engineering fragt: Wie formuliere ich die Anweisung, um das beste Ergebnis zu bekommen? Context Engineering fragt etwas anderes: Was weiß die KI überhaupt, wenn diese Frage bei ihr ankommt?

Eine Küchenanalogie trifft es ziemlich gut. Der Prompt ist das Rezept, das du dem Koch gibst. Context Engineering ist das, was in der Speisekammer steht. Selbst mit dem besten Rezept scheitert der Koch, wenn die Speisekammer leer ist oder die falschen Zutaten enthält.

Wie Context Engineering Halluzinationen reduziert

Isolierte Sprachmodelle neigen zu einem bestimmten Fehler: Wenn sie die Antwort nicht kennen, erfinden sie eine, die plausibel klingt. Context Engineering wirkt hier wie eine Leitplanke.

Reichert man den Kontext mit verifizierten Fakten an, stützt sich das Modell auf diese Fakten statt auf die statistische Wahrscheinlichkeit aus den Trainingsdaten. Man nennt das Grounding. Ein LLM ohne Kontext klingt gut und rät, mit Kontext liefert es eine Analyse, die sich prüfen lässt.

Zwei Faktoren entscheiden, ob das gelingt. Der erste ist Relevanz: Das Kontextfenster ist begrenzt und teuer, also darf nur rein, was wirklich gebraucht wird, denn irrelevante Daten verwirren ein Modell eher, als dass sie ihm helfen. Ein Kontextfenster voller halbrelevanter Textschnipsel verwässert genau die Fakten, auf die es ankommt, auch wenn technisch noch Platz frei wäre. Der zweite Faktor ist Datenqualität, denn Garbage in, Garbage out gilt hier ohne Ausnahme. Sind die Quelldaten unstrukturiert oder fehlerhaft, liefert auch die beste Architektur keine sauberen Ergebnisse.

Ein Grundsatz aus der Praxis lohnt sich aufzuschreiben: Verlass dich nie darauf, dass ein Modell von selbst weiß, was wichtig ist. Leg im System fest, dass Antworten ausschließlich auf dem bereitgestellten Kontext beruhen dürfen. Fehlt die Information im Kontext, soll das Modell "Ich weiß es nicht" antworten, statt zu raten.

RAG und Vektordatenbanken als technische Basis

In der Praxis läuft Context Engineering fast immer über eine RAG-Architektur, also Retrieval Augmented Generation. Das ist der Industriestandard, um externe Daten mit generativer KI zu verbinden, und wer heute noch statische Prompts ohne RAG für komplexe Aufgaben nutzt, verbrennt Budget.

Dabei übernimmt eine Vektordatenbank die Rolle des externen Langzeitgedächtnisses. Anders als eine klassische Datenbank speichert sie Informationen als mathematische Vektoren, sogenannte Embeddings. Das erlaubt es, nach Bedeutung und Zusammenhang zu suchen, statt nur nach exakten Wortlauten. Wer tiefer in die Funktionsweise von Vektoren einsteigen will, findet bei Pinecone eine gute technische Erklärung.

Der Prozess dahinter läuft in vier Schritten ab:

1. Der Nutzer stellt eine Frage.
2. Das System durchsucht die Vektordatenbank nach den relevantesten Informationsschnipseln.
3. Diese Schnipsel wandern in den Kontext des Prompts.
4. Das Modell generiert die Antwort auf Basis dieses angereicherten Kontexts.

Das Herzstück dieses Prozesses ist die semantische Suche. Sie findet Dokumente, die thematisch passen, auch wenn sie andere Wörter benutzen als die Suchanfrage. Ohne eine funktionierende semantische Suche scheitert Context Engineering meistens genau daran, dass dem Modell die falschen Informationen zugespielt werden, und dann helfen auch die teuersten Vektordatenbanken nichts. Wer die Architektur im Unternehmen aufbauen will, klärt erst die eigene Datenstruktur, bevor er Tools kauft.

Das Kontextfenster: Definition und Grenzen

Context Engineering findet innerhalb des Kontextfensters statt, dem Arbeitsspeicher des Modells, gemessen in Tokens. Jedes Wort, jedes Satzzeichen, jede eingespeiste Information verbraucht davon einen Teil.

Dieses Fenster ist eine harte technische Grenze, auch wenn es mit jeder Modellgeneration wächst. Schlechtes Token-Management führt dazu, dass wichtige Informationen am Anfang oder in der Mitte des Fensters vom Modell übergangen werden. Forscher nennen das Lost-in-the-Middle-Phänomen: Eine Untersuchung dazu zeigt, dass LLMs Informationen am Rand des Kontexts zuverlässiger abrufen als in der Mitte. Effiziente Kontext-Optimierung ist deshalb keine Kür, sondern hält Kosten und Latenz im Griff.

Die Herausforderungen im Umgang mit diesen Grenzen und konkrete Gegenstrategien würden diesen Eintrag sprengen. Dazu gibt es einen eigenen Deep-Dive: Context Engineering: Herausforderungen und Tipps.

Context Engineering für autonome KI-Agenten

Context Engineering wird zur Kernkompetenz, sobald KI-Agenten ins Spiel kommen. Ein Chatbot liefert eine Antwort und ist fertig. Ein autonomer Agent führt dagegen ganze Prozessketten aus, und dafür braucht er ein Gedächtnis.

Ohne sauberes Context Engineering vergisst ein Agent nach dem dritten Schritt, was er im ersten getan hat. Er wiederholt dann eine Anfrage, die längst beantwortet ist, oder startet einen Vorgang neu, den er eigentlich schon abgeschlossen hatte. In einer robusten Architektur sorgt das Context Management dafür, dass der Agent seinen Status, sein Ziel und vergangene Aktionen konsistent abrufen kann. Erst das macht Automatisierung komplexer Workflows zuverlässig, statt einen Agenten zu bauen, der sich im Kreis dreht.

Wohin sich Context Engineering entwickelt

Die Rolle verschiebt sich gerade sichtbar. Aus dem reinen Prompt Engineer wird zunehmend jemand, der Systeme baut, mit System-Prompts als festem Bestandteil: statische Anweisungen, die im Kontext verankert sind und das Verhalten der KI global steuern.

Architektur schlägt am Ende Rhetorik. Wer die Datenflüsse in seinem System beherrscht, beherrscht auch die Qualität der Antworten, die dabei rauskommen. Context Engineering ist deshalb kein Buzzword, sondern die Arbeit, die entscheidet, ob eine KI-Anwendung im Unternehmen verlässlich läuft oder nur in der Demo gut aussieht. Wer KI nicht als Spielzeug, sondern als Werkzeug einsetzen will, kommt an dieser Aufbereitung des Kontexts nicht vorbei.

Mehr Begriffe rund um KI und Automatisierung stehen im Glossar.

Zurück zum AI und Automation Glossar.