Context Engineering: die Disziplin, die RAG umfasst

Prompt Engineering hat ein Skalierungsproblem

Prompt Engineering setzt voraus, dass die wichtigste Variable das ist, was man in das Textfeld schreibt. Die eigentliche Variable ist größer: alles, was in das Kontextfenster des Modells gelangt (Dokumente, Gedächtnis, Tool-Ausgaben, Gesprächshistorie, System-Anweisungen) und die Entscheidungen darüber, wann welches Element eintrifft. Diese umfassendere Disziplin hat inzwischen einen Namen: Context Engineering.

Was Context Engineering wirklich bedeutet

Ein Sprachmodell ist im Kern eine Funktion seines Kontextfensters. Es kann nichts außerhalb dieses Fensters sehen. Alles, was es zum Zeitpunkt der Inferenz weiß (Fakten, Einschränkungen, Beispiele, abgerufene Inhalte), wurde bewusst oder zufällig dort platziert. Context Engineering ist die bewusste Seite: zu entscheiden, was genau in welcher Reihenfolge und wann eingefügt wird.

Der Begriff entstand in der KI-Community ungefähr 2026, als Teams von Prompt-Templates zu einem systematischen Management der Kontextzusammensetzung übergingen. Andrej Karpathy beschrieb es unter anderem als die Nachfolge-Rahmung des Prompt Engineerings: eine umfassendere Disziplin, die es einschließt, ohne es zu ersetzen. Die Frage lautet nicht mehr "was schreibe ich in den Prompt?", sondern "was soll das Modell wissen, und wann soll es es wissen?"

Prompt Engineering ist ein Hebel innerhalb von Context Engineering. RAG ist ein weiterer. Ebenso dynamisches Tool-Calling, Gedächtnis-Zusammenfassung, Gesprächsbereinigung, System-Prompt-Strukturierung und Retrieval-then-Rerank. Context Engineering ist die Meta-Ebene, die entscheidet, welche Hebel wann betätigt werden.

Warum RAG ein Werkzeug ist, keine Disziplin

RAG (Retrieval-Augmented Generation) löst ein spezifisches Kontextproblem: wie man relevante externe Inhalte in den Prompt einfügt, wenn das Corpus zu groß ist, um es vollständig einzubeziehen. Es ist eine nützliche Technik. Es ist keine vollständige Lösung für Kontextqualität.

Typisch implementiertes RAG trifft trotzdem grobe Entscheidungen. Es ruft eine feste Anzahl von Chunks ab, unabhängig von der Komplexität der Anfrage. Es übergibt diese Chunks in beliebiger Reihenfolge an den Kontext. Es hat keinen eingebauten Mechanismus, um zu erkennen, dass der falsche Chunk abgerufen wurde oder dass die richtige Antwort in einem Abschnitt liegt, den das Embedding-Modell niedrig eingestuft hat.

Eine Context-Engineering-Perspektive macht diese Einschränkungen sichtbar. Die Frage verschiebt sich von "haben wir RAG gemacht?" zu "hat das Modell genau das, was es braucht, und nichts, was es nicht braucht?" Das sind unterschiedliche Fragen mit unterschiedlichen Antworten.

Lange-Kontext-Degradation: warum "alles hineinpacken" scheitert

Längere Kontextfenster sind tatsächlich nützlich. Aber sie machen Kontextqualität nicht irrelevant. Forschung aus verschiedenen Gruppen hat ein konsistentes Muster dokumentiert: Die Modellleistung verschlechtert sich bei Informationen, die in der Mitte sehr langer Kontexte platziert sind. Dieser Effekt wird manchmal als "Lost in the Middle"-Problem bezeichnet. Ein Modell mit einem 128K-Kontextfenster ist nicht gleichmäßig aufmerksam auf alle 128K Token. Material an den Rändern erhält mehr Gewicht als Material, das im Zentrum vergraben ist.

Das bedeutet: Alles in den Kontext zu laden ist keine Strategie. Es ist eine Hoffnung. Wenn ein relevanter Abschnitt inmitten von 100K Token neben Tausenden irrelevanter Token landet, gewichtet das Modell ihn möglicherweise nicht korrekt. Gezieltes Retrieval der wenigen richtigen Dinge übertrifft konsistent einen vollständigen Corpus-Dump, selbst wenn das Corpus technisch ins Kontextfenster passen würde.

Kontextqualität bedeutet nicht nur, was das Modell sehen kann. Es bedeutet, was das Modell tatsächlich nutzen kann.

Warum grep über ein OKF-Bundle gutes Context Engineering ist

Ein OKF-Bundle (strukturierte Markdown-Konzeptdateien, nach Themen organisiert) ist darauf ausgelegt, exaktes, gezieltes Retrieval zu unterstützen. Ein Agent, der ein OKF-Bundle durchsucht, ruft keine Chunks nach Kosinus-Ähnlichkeit ab. Er liest Dateinamen und Überschriften, identifiziert die relevante Konzeptdatei und liest nur diese Datei.

Der Kontext, den das Modell erhält, ist klein und präzise: die wenigen Konzeptdateien, die die Antwort tatsächlich benötigt. Keine probabilistische Auswahl von Textfragmenten, die von einem Embedding-Modell zusammengestellt wurde. Das ist angewandtes Context Engineering: die richtigen Dinge hinein, den Lärm draußen lassen.

Es ist auch deterministisch. Für eine gegebene Anfrage über ein gegebenes Bundle werden dieselben Konzeptdateien abgerufen. Die Antwort ist prüfbar. Man kann inspizieren, was in den Kontext geflossen ist und warum, ein entscheidender Unterschied bei regulierten Anwendungen.

Im Gegensatz dazu: Bei Vektorsuche könnten zwei semantisch ähnliche Anfragen unterschiedliche Chunks abrufen, je nachdem, wie das Embedding-Modell sie verteilt. Bei einem Agenten, der ein OKF-Bundle liest, ist die relevante Konzeptdatei entweder vorhanden oder nicht. Das Reasoning ist transparent.

Was das für die Wissensbasis-Gestaltung bedeutet

Der Wechsel von "RAG machen" zu "Context Engineering betreiben" ist ein Wechsel darin, was man optimiert. Statt Ähnlichkeitsschwellen oder Chunk-Größen zu tunen, fragt man: Ist das Wissen so organisiert, dass eine gezielte Suche genau das findet, was eine vernünftige Frage benötigt?

Für eine begrenzte, strukturierte Wissensbasis (eine Produktspezifikation, ein Richtliniendokument, ein technisches Handbuch, das aus einem PDF konvertiert wurde) ist die Antwort fast immer ja, wenn die Konvertierung gut gemacht ist. Die Strukturierungsarbeit geschieht einmalig, zur Konvertierungszeit, nicht bei jeder Abfrage.

pdf2okf wandelt PDFs in OKF-kompatible Bundles um, die für genau diese Art von Retrieval konzipiert sind. Die Struktur, die bei der Konvertierung entsteht (Konzeptdateien, einheitliche Überschriften, Querverweise), ist die Context-Engineering-Infrastruktur. Ein Agent, der dieses Bundle liest, durchsucht keinen Heuhaufen. Er öffnet den richtigen Abschnitt.