Context Engineering ist die Disziplin, die festlegt, welche Informationen einem Sprachmodell übergeben werden, in welcher Form und zu welchem Zeitpunkt. Während sich Prompt Engineering auf die Formulierung einer einzelnen Anweisung konzentriert, steuert Context Engineering das gesamte Informationsumfeld, innerhalb dessen das Modell seine Schlüsse zieht.
Warum die Unterscheidung wichtig ist
Ein Sprachmodell kann keine Informationen abrufen, die ihm nicht mitgegeben wurden. Seine Ausgabe ist durch das begrenzt, was sich zum Zeitpunkt der Inferenz in seinem Kontextfenster befindet. Enthält dieses Fenster falsche Daten, veraltete Daten oder zu viel Rauschen, leidet die Antwort des Modells, unabhängig davon, wie sorgfältig der Prompt formuliert wurde.
Context Engineering behandelt dieses Fenster als verwaltete Ressource. Die Frage lautet nicht nur „Was soll ich fragen?“, sondern „Was soll das Modell wissen, und wie soll dieses Wissen strukturiert sein?“
Was Context Engineering in der Praxis bedeutet
In der Praxis umfasst es mehrere zusammenhängende Entscheidungen:
- Auswahl. Welche Dokumente, Datensätze, Tool-Ausgaben oder Gedächtnisspuren sind für diese Anfrage relevant? Retrieval-Pipelines, einschließlich RAG, sind ein Mechanismus, um diese Frage zur Laufzeit zu beantworten.
- Struktur. In welcher Reihenfolge und in welchem Format sollten Informationen aufbereitet werden? Modelle nehmen Inhalte je nach Position und Darstellung unterschiedlich wahr. Kritische Einschränkungen am Ende eines langen Kontexts zu platzieren, ist eine bekannte Fehlerquelle.
- Komprimierung. Kontextfenster sind begrenzt, und die Inferenzkosten steigen mit der Token-Anzahl. Zusammenfassung, Chunking-Strategie und Filterung beeinflussen, wie viele nützliche Informationen hineinpassen.
- Aktualität. Statischer Kontext veraltet. Systeme, die Live-Daten, Benutzerzustände oder aktuelle Tool-Ergebnisse einbinden, benötigen Logik, um zu steuern, was wann aktualisiert wird.
- Rollentrennung. In Multi-Turn- oder agentischen Systemen ist die Unterscheidung zwischen Systemanweisungen, Benutzereingaben, Tool-Antworten und früheren Modellausgaben entscheidend dafür, wie das Modell die einzelnen Bestandteile interpretiert.
Verhältnis zum Prompt Engineering
Prompt Engineering bleibt relevant: Die Formulierung einer Anweisung beeinflusst nach wie vor, was das Modell mit den empfangenen Informationen macht. Doch Prompt Engineering deckt vielleicht 10 bis 20 Prozent der verfügbaren Stellschrauben ab. Context Engineering adressiert den Rest. Beide stehen nicht im Wettbewerb zueinander; Context Engineering ist der übergeordnete Rahmen, innerhalb dessen Prompt Engineering stattfindet.
Wo es in Produktivsystemen auftritt
Context Engineering-Entscheidungen sind in den meisten nicht-trivialen KI-gestützten Anwendungen eingebettet:
- Ein Coding-Agent, der relevante Dateien, Testergebnisse und Fehlerprotokolle abruft, bevor er ein Modell zur Fehleranalyse auffordert, betreibt Context Engineering.
- Ein kundenorientierter Assistent, der Kontoverlauf und Richtliniendokumente abruft, bevor er eine Antwort generiert, betreibt Context Engineering.
- Eine Dokumentenverarbeitungs-Pipeline, die entscheidet, welche Abschnitte eines Vertrags in welcher Reihenfolge an ein Modell übergeben werden, betreibt Context Engineering.
In agentischen Systemen, bei denen Modelle Abfolgen von Aktionen ausführen und der Kontext mit jedem Schritt wächst, wird das Engineering-Problem komplexer. Entscheidungen darüber, was beibehalten, zusammengefasst oder verworfen wird, wirken sich unmittelbar darauf aus, ob der Agent über eine längere Aufgabe hinweg kohärent bleibt.
Typische Fehlermuster
Schlechtes Context Engineering führt in der Regel zu einem von wenigen erkennbaren Problemen: Das Modell ignoriert eine Einschränkung, weil sie in irrelevantem Material vergraben war; es halluziniert eine Tatsache, die abrufbar gewesen wäre, aber nicht abgerufen wurde; es widerspricht früheren Anweisungen, weil das Kontextfenster über Gesprächsrunden hinweg nicht gepflegt wurde; oder es performt im Test gut und in der Produktion schlecht, weil der Testkontext sauberer war als echte Daten.
Diese Fehler werden häufig dem Modell selbst zugeschrieben. In vielen Fällen verhält sich das Modell jedoch konsistent mit dem, was ihm übergeben wurde.
Was wir prüfen
Das Urteilsvermögen im Bereich Context Engineering wird direkt in unserer technischen Eignungsprüfung bewertet. In der AI-native Session werden Kandidaten nach einem eigenen Kriterium für Prompt- und Context Engineering bewertet: ob sie den Prompt und den Aufgabenkontext so einrichten, dass das Tool in ein bis zwei Durchläufen brauchbare Ergebnisse liefert. Wir achten außerdem auf spezifikationsgetriebene Entwicklung und die Verifikation von KI-Ausgaben – beides setzt dieselbe Grundkompetenz voraus: zu entscheiden, welche Informationen das Modell wann benötigt. Das vollständige Bewertungsschema und der Sitzungsaufbau sind unter „Wie wir prüfen“ beschrieben.
Kurze Antworten
Ist Context Engineering dasselbe wie RAG?
Nein. RAG ist eine Technik, um den Kontext zur Laufzeit durch das Abrufen relevanter Dokumente zu befüllen. Context Engineering ist die übergeordnete Disziplin, die festlegt, was in welcher Form und in welcher Reihenfolge in das Kontextfenster gelangt. RAG ist ein Werkzeug innerhalb dieser Praxis.
Müssen Sie Context Engineering verstehen, um KI-Coding-Tools zu nutzen?
Für den einfachen Einsatz nein. Für Produktivsysteme, bei denen Zuverlässigkeit zählt, ja. Entwickler, die Context Engineering verstehen, treffen bessere Entscheidungen darüber, welche Informationen einem Modell bereitgestellt werden sollen, und warum Ausgaben im Fehlerfall scheitern.
Wie unterscheidet sich Context Engineering von Fine-Tuning?
Fine-Tuning verändert die Gewichte des Modells, um Wissen oder Verhalten einzubetten. Context Engineering stellt Informationen zur Inferenzzeit bereit, ohne das Modell zu verändern. Beide Ansätze ergänzen sich, aber Context Engineering lässt sich günstiger iterieren und erfordert kein erneutes Training.
