Context Engineering

Wie Context Engineering funktioniert

Ein Sprachmodell bearbeitet eine Aufgabe nicht mit sämtlichen
Informationen, die irgendwo über das betreffende Thema vorhanden sind.
Seine Ausgabe kann nur auf den im Modell erlernten Zusammenhängen und den Informationen beruhen, die ihm während der Verarbeitung zur Verfügung gestellt werden.

Dieser Kontext kann beispielsweise enthalten:

• Systemanweisungen
• Benutzeranfragen
• bisherige Teile einer Unterhaltung
• Dokumente
• Suchergebnisse
• gespeicherte Zustände
• Ergebnisse von Werkzeugen
• Regeln und Vorgaben
• Beispiele
• Informationen über die aktuelle Aufgabe

Context Engineering beschäftigt sich damit, wie dieser Kontext für eine konkrete Aufgabe zusammengestellt wird.

Kontext ist mehr als ein Prompt

Ein Prompt ist eine Eingabe oder Anweisung an ein Modell.
Der Kontext kann wesentlich mehr enthalten.

Ein System könnte beispielsweise die Benutzeranfrage erhalten:

Aktualisiere die Konfiguration des Mailservers.

Für eine sinnvolle Bearbeitung könnten zusätzlich notwendig sein:

aktuelle Konfiguration
geltende Architekturregeln
Version der verwendeten Software
Dokumentation dieser Version
Informationen über abhängige Dienste
gewünschter Zielzustand

Die Formulierung der Benutzeranfrage allein löst das Informationsproblem nicht.
Das Modell benötigt die für die Aufgabe relevanten Informationen.

Damit verschiebt sich die Fragestellung von:

„Wie formuliere ich den perfekten Prompt?“

zu:

„Welche Informationen benötigt das System jetzt, und wie bekommt es genau diese Informationen?“

Mehr Kontext ist nicht automatisch besser

Eine naheliegende Strategie besteht darin, einem Modell möglichst viele Informationen zu geben.
Das kann funktionieren, besitzt aber Grenzen.

Zusätzliche Informationen können:

• irrelevant für die konkrete Aufgabe sein
• veraltet sein
• anderen Informationen widersprechen
• unterschiedliche Versionen desselben Sachverhalts enthalten
• wichtige Informationen zwischen unwichtigen Informationen verstecken
• das verfügbare Kontextfenster verbrauchen

Ein großes Dokumentenarchiv ist deshalb noch kein guter Kontext.
Entscheidend ist, welche Teile davon für die aktuelle Aufgabe benötigt werden.
Context Engineering ist damit auch ein Auswahlproblem.

Der gültige Kontext

Neben der Relevanz stellt sich die Frage nach der Gültigkeit einer Information.

Ein System kann beispielsweise mehrere Konfigurationsbeispiele enthalten:

config-2024.conf
config-2025.conf
config-current.conf

Alle drei Dateien können technisch korrekt aussehen.
Für die aktuelle Aufgabe ist trotzdem möglicherweise nur eine davon gültig.
Dasselbe Problem entsteht bei Dokumentation, Regeln, Architekturentscheidungen oder früheren Gesprächsinhalten.

Context Engineering muss deshalb nicht nur fragen:

„Ist diese Information thematisch relevant?“

Sondern auch:

„Ist diese Information für den aktuellen Zustand des Systems noch gültig?“

Kontext besitzt Herkunft

Eine Information kann aus unterschiedlichen Quellen stammen.

Sie kann beispielsweise:

• vom Benutzer eingegeben worden sein
• aus einer internen Dokumentation stammen
• aus einer Datenbank geladen worden sein
• durch eine Suche gefunden worden sein
• von einem Werkzeug erzeugt worden sein
• aus einer früheren Interaktion stammen
• von einem anderen KI-System erzeugt worden sein

Diese Herkunft kann für ihre Bewertung wichtig sein.
Eine aktuelle Konfigurationsdatei eines laufenden Systems besitzt für bestimmte Fragen möglicherweise eine andere Aussagekraft als eine mehrere Jahre alte Dokumentation.
Eine vom Sprachmodell zuvor selbst erzeugte Zusammenfassung ist wiederum nicht automatisch eine unabhängige Quelle.
Context Engineering kann deshalb auch Informationen darüber benötigen, woher ein Bestandteil des Kontexts stammt.

Kontext kann schrittweise bereitgestellt werden

Nicht jede möglicherweise relevante Information muss bereits zu Beginn einer Aufgabe vollständig in den Kontext geladen werden.
Ein System kann zunächst einen kleinen Kontext bereitstellen und weitere Informationen verfügbar machen, wenn sie benötigt werden.

Beispielsweise könnte der erste Kontext enthalten:

Aufgabe
aktueller Systemzustand
geltende Regeln
Übersicht der beteiligten Komponenten

Für einzelne Komponenten stehen zusätzlich detaillierte Dokumente zur Verfügung.
Benötigt das Modell Informationen über eine dieser Komponenten, können die entsprechenden Details nachgeladen werden.

Dadurch entsteht eine mehrstufige Informationsstruktur:

Übersicht
    ↓
relevanter Bereich
    ↓
konkrete Details
    ↓
Originalquelle

Das kann helfen, den unmittelbar bereitgestellten Kontext klein zu halten, ohne den Zugriff auf tiefergehende Informationen grundsätzlich zu verlieren.

Verdichtung verändert Information

Lange Informationen können zusammengefasst oder verdichtet werden, um weniger Kontext zu benötigen.
Dabei entsteht jedoch ein neues Problem.
Eine Zusammenfassung ist nicht identisch mit ihrer Quelle.
Details können verloren gehen.
Ausnahmen können verschwinden.
Die Gewichtung einzelner Aussagen kann sich verändern.
Und eine fehlerhafte Zusammenfassung kann anschließend selbst wieder als Kontext verwendet werden.
Deshalb kann es sinnvoll sein, neben einer verdichteten Darstellung auch die Herkunft oder einen Zugriff auf die zugrunde liegende Quelle zu erhalten.
Verdichtung ist damit keine kostenlose Verkleinerung von Kontext.
Sie ist eine Transformation von Information.

Widersprüchlicher Kontext

Kontext kann widersprüchliche Informationen enthalten.

Beispielsweise könnte eine Dokumentation sagen:

Port 8080 wird verwendet.

Eine aktuelle Konfiguration enthält dagegen:

listen_port=8443

Das Modell muss nun mit zwei unterschiedlichen Aussagen umgehen.
Ohne zusätzliche Informationen ist möglicherweise nicht erkennbar, welche davon gültig ist.

Ein Context-Engineering-System kann deshalb Mechanismen benötigen, um beispielsweise:

• Aktualität zu kennzeichnen
• Quellen zu unterscheiden
• Prioritäten festzulegen
• Gültigkeitsbereiche zu beschreiben
• Widersprüche sichtbar zu machen
• bei Unsicherheit weitere Informationen anzufordern

Das Ziel muss nicht darin bestehen, jeden Widerspruch automatisch aufzulösen.
Es kann ausreichend oder sogar notwendig sein, ihn zunächst sichtbar zu machen.

Kontext und Regeln

Auch Regeln sind Kontext.

Ein System kann beispielsweise festlegen:

Direkte Ausgabe auf stdout ist in diesem Projekt nicht erlaubt.

Damit ein KI-System diese Regel berücksichtigen kann, muss sie bei der relevanten Aufgabe verfügbar sein.

Existieren mehrere hundert Regeln, stellt sich erneut die Context-Engineering-Frage:

Welche davon sind für die gerade bearbeitete Datei oder Komponente relevant?

Eine Möglichkeit besteht darin, Regeln nach Gültigkeitsbereichen zu strukturieren und nur die für den aktuellen Arbeitsbereich relevanten Regeln bereitzustellen.
Die spätere Prüfung, ob die erzeugte Lösung diese Regeln tatsächlich einhält, ist allerdings eine andere Aufgabe.
Kontext kann einem Modell eine Regel mitteilen.
Er garantiert nicht, dass das Modell sie einhält.

Context Engineering und Prüfung

Ein gut zusammengestellter Kontext kann die Voraussetzungen für eine gute Ausgabe verbessern.
Er beweist jedoch nicht deren Korrektheit.

Ein Sprachmodell kann:

• Informationen übersehen
• Regeln falsch anwenden
• Zusammenhänge falsch interpretieren
• aus korrektem Kontext falsche Schlüsse ziehen
• plausible, aber nicht belegte Aussagen ergänzen

Context Engineering und Evaluation erfüllen deshalb unterschiedliche Aufgaben.

Context Engineering fragt:

„Welche Informationen stehen dem System für diese Aufgabe zur Verfügung?“

Evaluation fragt anschließend:

„Wie gut erfüllt das Ergebnis die Anforderungen?“

Beides ergänzt sich, ersetzt sich aber nicht.

Context Engineering ist ein Systemproblem

Sobald KI-Systeme nicht mehr nur einzelne isolierte Prompts bearbeiten, kann Kontextverwaltung zu einem wichtigen Bestandteil ihres Systementwurfs werden.

Es müssen Entscheidungen getroffen werden über:

• Informationsquellen
• Auswahlverfahren
• Aktualisierung
• Versionierung
• Prioritäten
• Gültigkeit
• Verdichtung
• Speicherung
• Zugriff
• Kontextgrenzen
• Nachladen zusätzlicher Informationen
• Umgang mit widersprüchlichen Informationen

Damit ist Context Engineering nicht nur eine Frage der Formulierung von Text.
Es ist die Gestaltung der Informationsbereitstellung rund um ein KI-Modell und die von ihm bearbeitete Aufgabe.

Warum Context Engineering praktische Auswirkungen hat

• Relevante Informationen werden gezielt bereitgestellt: Das Modell muss nicht sämtliche vorhandenen Daten gleichzeitig verarbeiten.
• Veralteter Kontext kann erkannt werden: Aktualität und Gültigkeit können Bestandteil der Kontextverwaltung sein.
• Kontextfenster werden gezielter genutzt: Unmittelbar benötigte Informationen können gegenüber Hintergrundmaterial priorisiert werden.
• Große Wissensbestände werden nutzbar: Informationen können strukturiert und bei Bedarf nachgeladen werden.
• Widersprüche werden sichtbar: Unterschiedliche Quellen müssen nicht stillschweigend zu einer scheinbar eindeutigen Aussage verschmolzen werden.
• Regeln können aufgabenbezogen bereitgestellt werden: Nicht jede Regel muss bei jeder Aufgabe im Kontext stehen.
• Quellen bleiben nachvollziehbar: Verdichtete Informationen können mit ihren Ursprüngen verbunden bleiben.
• Evaluation kann reproduzierbarer werden: Der verwendete Kontext kann als Teil der Bedingungen einer Prüfung dokumentiert werden.

Typisches Beispiel

Ein Softwareprojekt besitzt mehrere hundert Dokumente.

Darin befinden sich:

• Architekturentscheidungen
• Programmierrichtlinien
• Dokumentation externer Bibliotheken
• alte Entwürfe
• aktuelle Konfigurationen
• Beispiele
• Fehlerberichte
• technische Notizen

Ein KI-System soll eine einzelne Funktion verändern.
Sämtliche Dokumente in den Kontext zu laden wäre weder notwendig noch unbedingt hilfreich.
Stattdessen wird zunächst festgestellt, welche Komponente betroffen ist.
Für diese Komponente werden die aktuell gültigen Architekturregeln, relevanten Programmierrichtlinien, die betroffene Quelldatei und die notwendige technische Dokumentation bereitgestellt.
Während der Bearbeitung stellt sich heraus, dass die Funktion einen externen Dienst verwendet.
Die Dokumentation dieser Schnittstelle wird daraufhin zusätzlich geladen.
Das Modell arbeitet damit nicht mit dem gesamten verfügbaren Wissen, sondern mit einem für die aktuelle Aufgabe zusammengestellten Kontext.
Nach der Änderung wird unabhängig davon geprüft, ob das Ergebnis die geltenden Regeln und funktionalen Anforderungen tatsächlich erfüllt.

Abgrenzung

• Context Engineering beschäftigt sich mit der Auswahl, Strukturierung und Bereitstellung des für eine Aufgabe relevanten Kontexts.
• Prompt Engineering konzentriert sich stärker auf die Gestaltung von Anweisungen und Eingaben für ein Modell. Prompts können Bestandteil des Kontexts sein.
• Retrieval-Augmented Generation (RAG) ist ein mögliches technisches Verfahren, um Informationen zu suchen und für eine Generierung bereitzustellen. RAG kann damit Bestandteil einer Context-Engineering-Lösung sein, ist aber nicht mit Context Engineering gleichzusetzen.
• Das Kontextfenster beschreibt die technisch begrenzte Menge an Kontext, die ein Modell bei einer Verarbeitung berücksichtigen kann.
• KI-Evaluation untersucht die Qualität und Eigenschaften der erzeugten Ergebnisse. Ein geeigneter Kontext kann diese Ergebnisse beeinflussen, ersetzt ihre Prüfung jedoch nicht.

Weiterführend

Verwandte Begriffe

→ Prompt Engineering
→ Prompt
→ System-Prompt
→ Kontextfenster
→ Sprachmodell
→ Token
→ Probabilistisch
→ KI-Evaluation
→ AI Assurance
→ Beobachtbarkeit