Thought Leadership
Wer in den letzten Monaten die KI-Debatte verfolgt hat, ist unweigerlich auf einen Begriff gestoßen, der still und leise die Art verändert, wie wir über den Bau von KI-Systemen nachdenken: Context Engineering.
Inhalt
Geprägt vom bekannten Informatiker Andrej Karpathy und aufgegriffen von Praktikern in der gesamten KI-Branche, beschreibt Context Engineering eine Disziplin, die weit über das bekannte Prompt Engineering hinausgeht und fundamentaler ist, als die meisten ahnen.
Was Prompt Engineering war und wo es endet
Prompt Engineering entstand aus einer simplen Beobachtung: Wie man ein Sprachmodell fragt, beeinflusst massiv, was man zurückbekommt. „Erkläre mir Quantenphysik“ liefert andere Ergebnisse als „Erkläre mir Quantenphysik in einfachen Worten, als würde ich mit einem neugierigen 12-Jährigen sprechen.“
Diese Beobachtung ist korrekt, aber unvollständig. Denn bei einfachen Chatbots und Ein-Schuss-Anfragen ist die Eingabe tatsächlich nur ein Prompt. In modernen KI-Applikationen wie autonomen Agenten, mehrstufigen Workflows, RAG-Systemen, Codegeneratoren oder Kundenservice-Bots ist die Eingabe an das Modell kein einzelner Satz. Sie ist ein hochkomplexes, dynamisch zusammengesetztes Dokument: der Kontext.
Und genau hier beginnt Context Engineering.
Was Context Engineering wirklich bedeutet
Context Engineering bezeichnet die Disziplin, den richtigen Inhalt zur richtigen Zeit in das Kontextfenster eines Sprachmodells zu bringen: in der richtigen Form, der richtigen Reihenfolge und mit dem richtigen Umfang.
Karpathy formulierte es so: Context Engineering sei „die feine Kunst und Wissenschaft, das Kontextfenster mit genau den richtigen Informationen zu füllen.“ Es geht nicht darum, einen guten Satz zu formulieren. Es geht darum, ein System zu bauen, das zur Laufzeit entscheidet, welche Informationen das Modell braucht, woher diese Informationen kommen, in welcher Form sie aufbereitet werden, was weggelassen werden muss und wie alles zusammengefügt wird.
Der Claude-Entwickler Anthropic erklärt es derweil so: „Im Gegensatz zur einmaligen Aufgabe, eine Eingabeformulierung zu verfassen, ist das Context Engineering ein iterativer Prozess, und die Kurationsphase findet jedes Mal statt, wenn wir entscheiden, welche Daten wir an das Modell übergeben.“
Die Bestandteile eines Kontexts
In einer produktiven KI-Anwendung setzt sich das Kontextfenster typischerweise aus mehreren Schichten zusammen.
System Prompt: Die Grundinstruktionen, die das Verhalten des Modells definieren. Rolle, Tonalität, Regeln, Einschränkungen. Der System Prompt ist statisch und verändert sich nicht während einer Session.
Gesprächshistorie: Was bisher gesagt wurde. Bei längeren Konversationen entsteht hier das erste große Problem: Kontextfenster sind endlich. Entscheidungen darüber, welche Teile der Geschichte behalten, komprimiert oder verworfen werden, sind keine trivialen Fragen.
Externes Wissen (RAG): Retrieval-Augmented Generation ermöglicht es, dem Modell zur Laufzeit relevante Dokumente, Datenbankeinträge oder Webinhalte bereitzustellen. Die Kunst liegt darin, genau die richtigen Dokumente abzurufen: nicht zu viele, nicht zu wenige, nicht die falschen.
Tool-Outputs: Wenn ein Agent Werkzeuge aufruft wie eine API, eine Suche oder einen Code-Interpreter, fließen die Ergebnisse in den Kontext zurück. Wie diese Ergebnisse formatiert und eingebettet werden, hat erheblichen Einfluss auf die Qualität der nächsten Modellentscheidung.
Strukturelle Hinweise und Metainformationen: Datum, Nutzeridentität, verfügbare Tools, aktuelle Aufgabe, Zwischenergebnisse: alles, was das Modell braucht, um zu verstehen, in welchem Zustand sich das System befindet.
Warum es eine eigene Disziplin ist
Der entscheidende Unterschied zum klassischen Prompt Engineering liegt in der Systemebene. Context Engineering ist kein Craft, das man am Chat-Interface betreibt. Es ist Software-Engineering.
Context Engineering bedeutet dynamische Komposition: Der Kontext wird nicht statisch geschrieben, sondern zur Laufzeit aus verschiedenen Quellen zusammengebaut. Codelogik entscheidet, was reinkommt. Es bedeutet Speicherverwaltung: Welche Informationen werden langfristig gespeichert? Welche werden komprimiert? Wann wird die Gesprächshistorie verkürzt? Es bedeutet Informationshierarchie: Nicht alle Informationen im Kontext sind gleich wichtig. Und es bedeutet, den Trade-off zwischen Kosten und Qualität aktiv zu steuern, denn mehr Kontext bedeutet bessere Entscheidungen, aber auch höhere Inferenzkosten und längere Latenz.
Das „Lost in the Middle“-Problem
Ein konkretes Beispiel für die Komplexität: Forscher der Stanford University haben gezeigt, dass die Leistung von Sprachmodellen bei Aufgaben, die das Abrufen von Informationen aus langen Kontexten erfordern, drastisch sinkt, wenn die relevante Information in der Mitte des Dokuments liegt, selbst wenn sie sich im Kontextfenster befindet.
Das hat praktische Konsequenzen. Wer kritische Instruktionen oder relevante Fakten in den Kontext lädt, muss sich aktiv überlegen, wo diese Information platziert wird. Context Engineering ist damit auch räumliches Denken über die Struktur von Eingaben.
Context Engineering in der Praxis: Agentic Systems
Die Relevanz des Feldes wird am deutlichsten bei agentischen Systemen, also KI-Anwendungen, in denen das Modell nicht nur antwortet, sondern plant, Werkzeuge aufruft, mehrere Schritte ausführt und dabei den eigenen Zustand verwaltet.
Ein KI-Agent, der eine komplexe Softwareaufgabe lösen soll, muss zu jedem Zeitpunkt entscheiden, was er bereits weiß, welche Informationen noch fehlen, welche vergangenen Schritte für die aktuelle Entscheidung relevant sind und was sicher aus dem Kontext entfernt werden kann, ohne Informationen zu verlieren.
Diese Entscheidungen trifft nicht das Sprachmodell allein. Sie sind ins System eingebaut. Die Architektur, die diesen Informationsfluss steuert, ist Context Engineering.
Vier Kernprinzipien
Aus der Praxis lassen sich vier Leitprinzipien destillieren.
Relevanz vor Vollständigkeit. Ein kürzerer, präziser Kontext schlägt einen langen, vagen Kontext fast immer. Das Modell braucht keine vollständige Dokumentation, sondern genau die Teile, die für die aktuelle Aufgabe relevant sind.
Struktur ist Information. Wie der Kontext formatiert ist, beeinflusst, wie das Modell ihn verarbeitet. Klare Abschnitte, konsistente Formatierung und explizite Labels für verschiedene Informationstypen helfen dem Modell, den Kontext korrekt zu interpretieren.
Zustand explizit machen. Sprachmodelle haben kein inhärentes Gedächtnis zwischen Anfragen. Context Engineering macht den Systemzustand explizit sichtbar: was bisher passiert ist, wo im Prozess man sich befindet, welche Entscheidungen bereits getroffen wurden.
Robustheit vor Optimierung. Ein Kontextsystem, das bei unerwarteten Eingaben, langen Sessions oder fehlenden Daten zusammenbricht, ist wertlos. Robuste Fallbacks, sinnvolle Defaults und graceful Degradation sind ebenso wichtig wie die Optimierung des Happy Path.
Die Abgrenzung zu verwandten Begriffen
Context Engineering vs. Prompt Engineering. Prompt Engineering beschreibt, wie ein einzelner Prompt formuliert wird. Context Engineering beschreibt, wie das gesamte Informationssystem um das Modell herum aufgebaut ist. Ersteres ist Textarbeit, letzteres ist Systemarchitektur.
Context Engineering vs. RAG. Retrieval-Augmented Generation ist eine wichtige Technik innerhalb des Context Engineering, aber nur ein Teil davon. Context Engineering umfasst auch Speicherverwaltung, Tool-Integration, Gesprächshistorie und dynamische Instruktionen.
Context Engineering vs. Fine-Tuning. Fine-Tuning verändert die Gewichte des Modells. Context Engineering verändert die Eingabe. Beide Ansätze sind komplementär, aber Context Engineering ist flexibler, günstiger und in den meisten Anwendungsfällen ausreichend.
Wer Context Engineering beherrscht, hat einen Vorteil
Da die Basismodelle leistungsstärker werden und zunehmend als Commodities behandelt werden, verlagert sich der Wettbewerbsvorteil: weg vom Modell, hin zur Applikationsschicht. Die Fähigkeit, einem Modell genau den richtigen Kontext zur richtigen Zeit bereitzustellen, wird zum entscheidenden Differenzierungsmerkmal.
Das gilt für Startups, die KI-Produkte bauen. Es gilt für Unternehmen, die interne Prozesse automatisieren. Und es gilt für Entwickler, die verstehen wollen, warum ihre KI-Anwendung manchmal brillant und manchmal enttäuschend performt.
Die Antwort liegt fast immer im Kontext.
Fazit
Context Engineering ist kein Buzzword, das in sechs Monaten vergessen sein wird. Es beschreibt eine echte, zunehmend kritische Disziplin im Bau von KI-Systemen, eine, die Software-Engineering, Informationsarchitektur und ein tiefes Verständnis davon kombiniert, wie Sprachmodelle tatsächlich funktionieren.
Prompt Engineering bleibt relevant. Aber wer ernsthaft KI-Applikationen baut, denkt längst in Kontexten.
