Kontextengineering für KI-Agenten: Die Auswahl dessen, was das Modell sieht.
Warum Agenten mit zunehmendem Kontext an Leistung verlieren, wie Kontextengineering sich von Prompt-Formulierungen unterscheidet und ein einfacher Ablauf zur Auswahl dessen, was jede Modellaufruf-Sequenz sieht.
Ein KI-Agent, der in den ersten Schritten gut funktioniert, anschließend Anweisungen ignoriert, Arbeit wiederholt oder veralteten Fakten vertraut, hat in der Regel kein Formulierungsproblem. Es handelt sich um ein Kontextproblem: Das Modell sieht zu viel, die falschen Dinge oder die richtigen Dinge am falschen Ort. Context Engineering ist die Disziplin, genau zu bestimmen, was ein Modell unmittelbar vor dem Denken erhält – also nicht nur die Anfrage, sondern auch den gesamten Satz an Anweisungen, Historie, abgerufenen Daten und Tool-Definitionen. Diese Anleitung erläutert, warum dieser Satz mit zunehmender Komplexität der Agenten wichtiger wird, die vier von Ihnen steuerbaren Komponenten, einen minimalen Zusammenbauprozess sowie die Fehlermuster, auf die man achten muss.
Die Kernidee: ein kleiner, relevanter Ausschnitt
Ziel ist es niemals, dem Modell alles zu geben, was ihm möglicherweise helfen könnte. Es geht darum, ihm nur den eng begrenzten Informationsanteil zu geben, der es tatsächlich in die Lage versetzt, richtig zu antworten, und den Rest wegzulassen.
Eine menschliche Analogie macht diesen Punkt klar. Bitten Sie einen neuen Ingenieur, einen Fehler in einer einmillion Zeilen umfassenden Codebasis zu beheben, indem Sie sagen: „Lesen Sie den Code und finden Sie ihn“, dann wird er überwältigt sein; die relevante Datei geht inmitten von Tausenden verloren. Sagen Sie demselben Ingenieur stattdessen: „Das Problem liegt wahrscheinlich im Zahlungsmodul, diese drei Dateien wurden letzte Woche geändert, und hier ist, was die vorherige Person versucht hat“, dann kann die Behebung bereits in wenigen Minuten erfolgen. Am Ingenieur selbst hat sich nichts geändert – nur die Informationen, mit denen er arbeitete.
Modelle verhalten sich genauso. Context Engineering besteht darin, genau diese drei Dateien statt des gesamten Repositoriums zur Verfügung zu stellen.
Warum allein die Formulierung nicht mehr ausreicht
Frühe Ratschläge zur Arbeit mit Sprachmodellen konzentrierten sich auf die Formulierung: Wie Anweisungen formuliert werden sollten und welche Ausdrucksweisen bessere Antworten liefern. Das ist Prompt Engineering, und auch für eine einzelne Frage spielt das weiterhin eine Rolle.
Ein Agent hingegen beantwortet keine einzelne Frage. Er führt einen Zyklus aus: Er liest etwas, ruft ein Tool auf, erhält ein Ergebnis, wählt die nächste Aktion aus und wiederholt dies manchmal Dutzende Male. Jede Iteration fügt zusätzliches Material zu dem hinzu, was das Modell bereits verarbeitet hat. Schließlich wird der angesammelte Kontext so umfangreich, dass wichtige Details übersehen werden – ähnlich wie jemand, der den ganzen Tag über Meetings besucht hat und sich nicht mehr daran erinnern kann, was in dem ersten Meeting entschieden wurde.
Anthropic betrachtet das Kontextengineering als das Problem, zu jedem einzelnen Zeitpunkt die beste mögliche Informationsmenge für das Modell zu finden, anstatt einmal eine gute Anweisung zu formulieren. Das fasst den Wandel zusammen: Promptengineering bezieht sich auf die Worte; Kontextengineering umfasst alles, was vorhanden ist, wenn das Modell antwortet.
Promptengineering versus Kontextengineering
Beide überlappen sich, unterscheiden sich jedoch in ihrem Umfang, der typischen Anwendung sowie den möglichen Fehlern:
- Umfang. Promptengineering prägt die Formulierung einer einzigen Anweisung. Kontextengineering beeinflusst die gesamte Eingabe: Anweisungen, vorherige Gespräche, abgerufte Fakten und verfügbare Tools.
Eine schnelle Diagnose: Wenn Ihre Lösung darin besteht, Wörter zu ändern, betreiben Sie Prompt-Engineering. Wenn Ihre Lösung die Informationen verändert, die das Modell ursprünglich erhält, betreiben Sie Context-Engineering. Für eine strukturierte Methode, um zu entscheiden, zu welcher Schicht ein Agentenfehler gehört, siehe Debugging von KI-Agenten nach Schichten.
Die vier Komponenten, die Sie verwalten
Der Kontext jedes Agenten wird aus vier Quellen zusammengestellt. Jede hat ihre eigene Art, Fehler zu verursachen.
Anweisungen: die Stellenbeschreibung
Dies ist der System-Prompt, der beschreibt, was der Agent tun soll und wie. Ist er zu starr, kann der Agent nichts außerhalb des Skripts bewältigen. Ist er zu locker, improvisiert der Agent frei. Streben Sie nach Anleitungen, die konkret genug sind, um das Verhalten zu formen, ohne versuchen zu müssen, alle Situationen im Voraus aufzuzählen.
Auswertung: der Forschungsassistent
Durch die Auswertung werden externe Informationen durch das Durchsuchen von Dokumenten, das Abfragen einer Datenbank oder das Lesen von Dateien eingeholt. Eine mangelhafte Auswertung ist die Hauptursache dafür, dass KI-Systeme mit Überzeugung falsche Aussagen treffen. Oft erfindet das Modell nichts Neues; es wurden ihm falsche oder irrelevante Fakten gegeben, auf die es zu Recht vertraut hat. Die Verbesserung dessen, was häufig ausgewertet wird, trägt mehr zur Genauigkeit bei als jede Änderung am Prompt.
Gedächtnis: das Notizbuch
Das Gedächtnis umfasst alles, was der Agent speichert – sowohl innerhalb einer einzigen Konversation als auch über verschiedene Sitzungen hinweg. Ohne einen Mechanismus zur Zusammenfassung und Reduzierung älterer Informationen bleibt das Gedächtnis nicht nützlich. Es wächst stetig an, bis der größte Teil aus Störgeräuschen besteht, die mit den jetzt wichtigen Informationen konkurrieren.
Werkzeuge: der Werkzeugkasten
Tools definieren die Aktionen, die der Agent ausführen kann, wie beispielsweise Web-Suche, Codeausführung oder E-Mail-Versand. Der Name und die Beschreibung jedes Tools tragen ebenfalls zum Kontext bei. Eine Gruppe von zehn überschneidenden, nahezu identischen Tools verwirrt ein Modell genauso wie zehn ununterscheidbare Schraubendreher einen Neuzugang. Weniger Tools mit klar getrennten Aufgaben erleichtern die Auswahl und sind kostengünstiger.
Eine minimale Pipeline zur Erstellung von Kontexten
Der folgende Pseudocode zeigt, wie die vier Komponenten bei einem Modellaufruf zusammenwirken. Die Hilfsfunktionen sind Platzhalter für die Such-, Ranking- und Zusammenfassungsmethoden, die Sie verwenden, doch die Struktur spiegelt wider, wie reale Systeme dieses Problem angehen.
Es arbeitet in vier Schritten. Zunächst erfolgt eine breite Suche, bei der etwas „Rauschen“ in Kauf genommen wird, mit einer großzügigen Obergrenze von 50 Kandidaten. Anschließend werden diese Kandidaten gerankt und nur die fünf besten behalten. Danach wird der Gesprächsverlauf in eine Zusammenfassung mit einer Obergrenze von 500 Einheiten komprimiert, anstatt ihn vollständig abzuspielen. Schließlich werden die Inhalte absichtlich geordnet – zuerst die Anweisungen und zuletzt die aktuelle Frage – wobei das Ergebnis auf den zugewiesenen Token-Budget beschränkt wird.
def get_context_for_the_model(question, past_conversation, budget):
# Step 1: Cast a wide net — search broadly, don't worry about noise yet
possible_facts = search_everywhere(question, limit=50)
# Step 2: Narrow it down - keep only the genuinely relevant ones
best_facts = keep_most_relevant(possible_facts, top=5)
# Step 3: Summarize old conversation instead of keeping all of it
short_memory = summarize(past_conversation, max_length=500)
# Step 4: Put the most important things first and last, not buried in the middle
final_context = [
job_description, # instructions
short_memory, # memory
*best_facts, # retrieval
question, # what's being asked right now, last
]
return trim_to_fit(final_context, budget)
Zwei Gewohnheiten in diesem Ansatz sind es wert, übernommen zu werden.
Suche zunächst weit gefasst und verenge dann stark. Eine breite Suche verringert die Wahrscheinlichkeit, das relevante Dokument zu übersehen; eine strenge Ranking-Methode hält den endgültigen Kontext klein. Wenn nur der erste Schritt durchgeführt wird, wird das Modell überflutet, und wenn nur der zweite Schritt angewandt wird, besteht die Gefahr, nie das richtige Material zu finden.
Stellen Sie das Wichtige an die Ränder. Legen Sie den wichtigsten Inhalt am Anfang oder Ende des Eingabetextes anstatt in die Mitte. Es handelt sich dabei nicht um einen stilistischen Vorzug. Untersuchungen an langen Eingaben haben wiederholt gezeigt, dass Modelle Informationen, die in der Mitte eines langen Kontextes liegen, weniger zuverlässig berücksichtigen – ein Effekt, der oft als „verloren in der Mitte“ bezeichnet wird. Wie stark dieser Effekt ist, variiert je nach Modell; testen Sie daher mit Ihrer eigenen Konfiguration. Dennoch ist eine bestimmte Anordnung auf jeden Fall ein einfacher Ansatz.
Aus derselben Logik ergeben sich einige praktische Verbesserungen. Entscheiden Sie im Voraus, wie das Budget zwischen den Komponenten aufgeteilt wird, damit große Suchergebnisse nicht heimlich die Anweisungen verdrängen können. Beim Kürzen sollten zuerst die am wenigsten relevanten gefundenen Elemente entfernt werden, bevor man sich den Anweisungen oder der aktuellen Frage zuwendet. Protokollieren Sie außerdem den endgültig zusammengestellten Kontext für jeden Aufruf; wenn ein Agent sich falsch verhält, zeigt diese Aufzeichnung in der Regel den Grund dafür.
Was schiefgeht, wenn der Kontext nicht sorgfältig ausgewählt wird
Alles mit aufnehmen, um auf der sicheren Seite zu sein
Das Hinzufügen jedes möglicherweise relevanten Elements erscheint verantwortungsvoll, führt aber oft zu negativen Folgen. Je mehr unverwandtes Material das Modell durchgehen muss, desto schlechter wird es darin, die eine wichtige Information zu finden. Das ist vergleichbar damit, einen hundertseitigen Bericht vor einer Entscheidung, die nur fünf Minuten dauert, zu lesen.
Veraltete Informationen
Falls nichts überprüft, ob der abgerufene Inhalt noch aktuell ist, wird das Modell eine zuverlässige Antwort auf Grundlagen erstellen, die bereits vor Monaten nicht mehr zutrafen. Aktualitätsmetadaten, Ablaufregeln oder erneute Validierung für zeitkritische Quellen helfen dabei.
Verstecken der wichtigsten Fakten
Auch wenn die Suche genau den richtigen Faktor findet, macht seine Platzierung mitten in einem langen Textabschnitt es statistisch wahrscheinlicher, dass er übersehen wird. Der Fakt selbst bleibt unverändert; nur seine Position ändert sich, wodurch das Ergebnis schlechter wird.
Zu viele ähnliche Optionen
Falls jemand in Ihrem Team nicht mit Sicherheit sagen kann, welches Tool oder Dokument in einer bestimmten Situation geeignet ist, wird das Modell keine besseren Ergebnisse liefern. Konsolidieren Sie überschneidende Tools und entfernen Sie nahezu identische Dokumente, bevor sie im Kontext erscheinen.
Häufig gestellte Fragen
Ersetzt Context Engineering Prompt Engineering?
Nicht ganz. Klare Anweisungen sind weiterhin Teil der Aufgabe. Kontextengineering ist die umfassendere Aufgabe, die sie umgibt: Die Entscheidung darüber, was das Modell außerhalb der Anweisung selbst wahrnimmt.
Warum kann mehr Information zu schlechteren Ergebnissen führen?
Aufmerksamkeit ist eine begrenzte Ressource – sowohl für Modelle als auch für Menschen. Je mehr Material das Modell durchgehen muss, desto größer ist die Wahrscheinlichkeit, dass es den entscheidenden Detail übersehen wird, genauso wie eine Person Schwierigkeiten hat, eine wichtige Zeile in einem langen Dokument zu finden.
Löst ein größeres Kontextfenster das Problem?
Es hilft, indem es Platz bietet, beseitigt aber das zugrunde liegende Problem nicht. Informationen in der Mitte langer Eingaben werden weiterhin weniger zuverlässig genutzt, und sowohl die Latenz als auch die Kosten steigen mit der Länge des Eingabes. Die Auswahl dessen, was eingefügt wird, bleibt auch bei sehr großen Fenstern sinnvoll.
Kernpunkte
- Betrachten Sie die Eingabe des Modells als ein speziell für jeden Aufruf erstelltes Werkstück und nicht als einen nur zum Hinzufügen geeigneten Log.
- Verwalten Sie alle vier Komponenten bewusst: Anweisungen, Abrufmechanismen, Speicher und Tools – jede versagt auf ihre eigene Weise.
- Abrufen Sie umfassend, bewerten Sie die Ergebnisse streng, fassen Sie den Verlauf zusammen und platzieren Sie wichtige Inhalte am Anfang oder Ende.
- Wenn ein Agent im Laufe mehrerer Schritte an Leistung verliert, prüfen Sie, was ihm zuvor gegeben wurde, bevor Sie das, was ihm mitgeteilt wurde, neu schreiben.
- Ein größeres Fenster bietet mehr Platz – nicht Immunität; die Disziplin besteht weiterhin darin, genau die drei richtigen Dateien statt des gesamten Codebases zu übergeben.