Kurz gefasst: Context Engineering ist die Praxis, zu entscheiden, was in das Kontextfenster eines Modells gelangt, in welcher Reihenfolge und zu welchen Kosten, statt nur zu entscheiden, wie die Anfrage formuliert wird. Es wurde zur bindenden Fähigkeit, weil sich die Benchmark-Belege entschieden gegen die Annahme gewendet haben, ein großes Kontextfenster sei ein nutzbares Kontextfenster. Der bei der ICML 2025 veröffentlichte NoLiMa-Benchmark testete dreizehn Modelle, die alle mindestens 128.000 Token Unterstützung beanspruchen, und fand, dass elf davon bei nur 32.000 Token unter fünfzig Prozent ihrer eigenen Kurzkontext-Basislinie fielen, wobei GPT-4o von 99,3 Prozent auf 69,7 Prozent absank. Forschende von IBM maßen eine Degradation beim Funktionsaufruf von 7 bis 85 Prozent bei wachsenden Werkzeugkatalogen, 7 bis 91 Prozent bei länger werdenden Werkzeugausgaben und 13 bis 40 Prozent bei länger werdenden Gesprächen. Die grundlegende TACL-Arbeit zu langen Kontexten zeigte, dass Modelle vom Anfang und vom Ende einer Eingabe gut und aus der Mitte schlecht abrufen. Zusammen sagen sie dasselbe: Aufmerksamkeit ist eine knappe Ressource, die man zuteilt, kein kostenloser Behälter, den man füllt. Dieser Leitfaden liefert die Tabelle der gemessenen Degradation, ein abgeleitetes Verhältnis von beworbener Größe zu Degradationspunkt, ein fünfteiliges Kontextbudget und eine praktische Prüfung. Eine CEO teilt knappes Kapital bewusst zu; Studierende messen neu, wenn das nächste Modell erscheint.
Etwa drei Jahre lang war die Geschichte, die wir uns über die Arbeit mit Sprachmodellen erzählten, eine Geschichte über Formulierung. War die Ausgabe schlecht, war der Prompt schlecht. Fügen Sie eine Rolle hinzu. Fügen Sie Beispiele hinzu. Bitten Sie es, Schritt für Schritt zu denken. Sagen Sie: Sie sind Expertin. Ein ganzes Genre von Ratschlägen wuchs um die Idee, dass die Fähigkeit im Modell steckt und der Prompt der Schlüssel ist, der sie freigibt.
Diese Geschichte war nie genau falsch, aber sie ist zu einem kleinen Teil eines viel größeren Problems geworden, und die Verschiebung hat eine konkrete Ursache. Modelle bekamen lange Kontextfenster. Dann füllten die Leute sie. Dann wurden die Ergebnisse auf eine Weise schlechter, die keine Umformulierung beheben konnte, und das Feld musste eine Sprache dafür entwickeln, was tatsächlich vor sich ging.
Diese Sprache ist Context Engineering, und der Grund, warum das zählt, ist nicht, dass es ein modischer Begriff wäre. Es ist, dass der Fehler, den es adressiert, gemessen, veröffentlicht und groß ist.
Die Definition, präzise formuliert
Prompt Engineering fragt: Wie formuliere ich die Anweisung, damit das Modell das Richtige tut?
Context Engineering stellt eine andere und strikt größere Frage: Was ist die kleinste Menge hochwertiger Information, die das Modell in seinem Fenster braucht, um dies gut zu tun, und wie bringe ich genau das hinein und sonst nichts?
Der Unterschied zeigt sich am leichtesten daran, was beide steuern. Prompt Engineering steuert eine Komponente des Fensters, die Anweisung. Context Engineering steuert das gesamte Fenster, das in jedem realen System mindestens fünf konkurrierende Bewohner enthält: die Systemanweisungen, die Werkzeug- und Funktionsdefinitionen, abgerufene Dokumente oder Wissen, den Gesprächsverlauf und die angesammelte Ausgabe früherer Werkzeugaufrufe und Aktionen.
Diese Neurahmung zählt, weil die Anweisung in der Regel die kleinste dieser fünf ist, um eine Größenordnung, und die einzige, die die meisten Menschen je anfassen. Wenn Ihr System versagt und Sie immer noch die Formulierung des Prompts bearbeiten, optimieren Sie einen Rundungsfehler.
Context Engineering ersetzt Prompt Engineering nicht in dem Sinn, dass es dieses überflüssig machte. Es umfasst es. Formulierung ist ein Hebel innerhalb eines größeren Zuteilungsproblems, so wie Preisgestaltung ein Hebel innerhalb der Unternehmensführung ist. Wer sich damit befasst hat, warum Prompt Engineering allein nicht genügt, wird die Form wiedererkennen: Die Fähigkeit, die wie die ganze Arbeit aussah, entpuppt sich als eine Schicht eines Stapels.
Warum das Fenster nicht ist, was auf dem Etikett steht
Hier sind die Belege, die den Wandel erzwangen, und sie lohnen sorgfältige Lektüre, denn die Zahlen sind härter, als die allgemeine Debatte nahelegt.
Das erste Ergebnis ist grundlegend. Die in den Transactions of the Association for Computational Linguistics veröffentlichte Forschung dazu, wie Sprachmodelle lange Kontexte nutzen, fand eine konsistente U-förmige Leistungskurve über Mehrdokumenten-Fragebeantwortung und Schlüssel-Wert-Abruf hinweg. Die Leistung war am höchsten, wenn die relevante Information am Anfang oder am Ende der Eingabe stand, und fiel deutlich, wenn das Modell sie in der Mitte finden musste. Die Position im Fenster ist nicht neutral. Wo Sie etwas hinsetzen, ändert, ob das Modell es nutzen kann.
Das zweite Ergebnis sollte Ihre Standardannahmen ändern. Der NoLiMa-Benchmark, veröffentlicht bei der ICML 2025, wurde entworfen, um eine Lücke im üblichen Nadel-im-Heuhaufen-Test zu schließen. Im klassischen Test teilt die versteckte Tatsache meist offensichtliche Wortwahl mit der Frage, sodass ein Modell durch bloßen wörtlichen Abgleich erfolgreich sein kann, ohne wirklich über den Kontext zu schließen. NoLiMa entfernte diese Krücke, indem Fragen und Zieltatsachen mit minimaler lexikalischer Überschneidung konstruiert wurden, was das Modell zwingt, die Assoziation zu erschließen.
Die Ergebnisse über dreizehn Modelle, die alle mindestens 128.000 Token Unterstützung bewerben: Die Leistung war unter 1.000 Token stark, und elf der dreizehn fielen bei 32.000 Token unter fünfzig Prozent ihrer eigenen Kurzkontext-Basislinie. GPT-4o, eines der stärkeren Modelle, sank von 99,3 Prozent Genauigkeit auf 69,7 Prozent bei ausgedehnter Länge.
Das dritte Ergebnis verlagert dies vom Abruf in die Agenten-Workflows, die den größten Teil heutiger professioneller Nutzung ausmachen. Forschende von IBM führten LongFuncEval ein, um zu messen, wie gut Langkontextmodelle Funktionsaufrufe leisten, wenn der Kontext wächst, und berichteten drei getrennte Degradationskurven: einen Leistungsabfall von 7 bis 85 Prozent bei wachsendem Werkzeugkatalog, 7 bis 91 Prozent Degradation beim Antwortabruf bei länger werdenden Werkzeugantworten und 13 bis 40 Prozent Degradation bei länger werdenden Mehrfachdialogen.
Tabelle 1: Gemessene Degradation bei langem Kontext (verifizierte Quellen)
| Studie | Was gemessen wurde | Gemessene Degradation |
|---|---|---|
| Lost in the Middle, Transactions of the ACL | Position der relevanten Information im Kontext | U-förmige Kurve: am stärksten am Anfang und Ende der Eingabe, in der Mitte deutlich degradiert |
| NoLiMa, ICML 2025 | Assoziativer Abruf ohne lexikalische Überschneidung, 13 Modelle mit Anspruch auf 128K oder mehr | 11 von 13 Modellen unter 50 Prozent ihrer Kurzkontext-Basislinie bei 32.000 Token; GPT-4o von 99,3 auf 69,7 Prozent |
| LongFuncEval, IBM Research | Funktionsaufruf bei wachsendem Kontext | 7 bis 85 Prozent Abfall bei wachsendem Werkzeugkatalog; 7 bis 91 Prozent Abfall beim Antwortabruf bei längeren Werkzeugausgaben; 13 bis 40 Prozent Abfall bei längeren Gesprächen |
Drei unabhängige Forschungsgruppen, drei verschiedene Aufgabenfamilien, eine konsistente Schlussfolgerung. Die Fähigkeit, Token aufzunehmen, und die Fähigkeit, sie zu nutzen, sind getrennte Eigenschaften, und die Lücke dazwischen ist der Ort, an dem die meisten realen Fehler leben.
Was die beworbenen Zahlen tatsächlich wert sind
Die Marketingzahl und die Arbeitszahl sind nicht dasselbe, und es hilft, das Verhältnis explizit zu machen. Die folgende Rechnung ist ein von CEOtudent abgeleitetes Verhältnis, keine Messung: Sie nimmt den einen Punkt, an dem NoLiMa beobachtete, dass die meisten Modelle unter die Hälfte ihrer Basislinie fielen, und drückt ihn als Anteil des jeweils beworbenen Fensters aus.
Tabelle 2: Beworbenes Fenster gegenüber beobachtetem Halbierungspunkt (redaktioneller Rahmen von CEOtudent, abgeleitet aus NoLiMa)
| Beworbenes Kontextfenster | Bei den meisten getesteten Modellen beobachteter NoLiMa-Halbierungspunkt | Verhältnis von Halbierungspunkt zu beworbenem Fenster |
|---|---|---|
| 128.000 Token | 32.000 Token | 25,0 Prozent |
| 200.000 Token | 32.000 Token | 16,0 Prozent |
| 1.000.000 Token | 32.000 Token | 3,2 Prozent |
Lesen Sie die Methode, bevor Sie die Zahlen lesen. Die Zahl von 32.000 Token ist der Punkt, an dem elf der dreizehn NoLiMa-Modelle bei einer bewusst schwierig gestalteten Aufgabe zum assoziativen Abruf unter die Hälfte ihrer eigenen Kurzkontext-Basislinie gefallen waren. Es ist keine universelle Klippe, sie überträgt sich nicht auf jeden Aufgabentyp, und ein Modell, das diesen Test bei 32.000 Token nicht besteht, kann weit darüber hinaus noch nützliche wörtliche Abgleicharbeit leisten. Was das Verhältnis belegt, ist die Richtung und ungefähre Größenordnung des Abschlags, den Sie ansetzen sollten, wenn ein Anbieter eine Fenstergröße nennt. Ein beworbenes Fenster von einer Million Token als eine Million nutzbare Token zu behandeln, ist kein kleiner Fehler, sondern ein Fehler um eine Größenordnung bei der schwierigsten Aufgabenklasse.
Die Verhaltensimplikation ist einfach und leicht kontraintuitiv: Einem strauchelnden System mehr Kontext hinzuzufügen ist meist der falsche Zug. Jenseits einer Schwelle, die weit früher eintritt als das Etikett suggeriert, verdünnen zusätzliche Token, statt zu informieren.
Das fünfteilige Kontextbudget
Wenn Aufmerksamkeit knapp ist, dann gibt alles im Fenster sie aus. Hier ist der Rahmen, mit dem wir diese Ausgaben prüfen. Jede Zeile benennt einen Bewohner des Fensters, den konkreten dokumentierten Fehler, den er antreibt, und den technischen Zug, der ihn adressiert.
Tabelle 3: Das Kontextbudget (redaktioneller Rahmen von CEOtudent)
| Bewohner des Fensters | Typischer Anteil am Problem | Dokumentierter Fehler, den er antreibt | Der Zug |
|---|---|---|---|
| Systemanweisungen | Klein in Token, groß in der Wirkung | Widersprüchliche oder veraltete Regeln, die Ihre Anfrage still überschreiben | Kurz halten, obsolete Regeln entfernen, Vorrang ausdrücklich benennen |
| Werkzeug- und Funktionsdefinitionen | Wächst still mit jeder neuen Fähigkeit | LongFuncEval: 7 bis 85 Prozent Degradation bei wachsendem Katalog | Nur die für diese Aufgabe relevanten Werkzeuge freigeben, nicht den ganzen Katalog |
| Abgerufene Dokumente | Meist der größte Bewohner | Lost in the Middle: mitten im Kontext vergrabenes Material wird schlecht abgerufen | Weniger abrufen, härter ranken, das Entscheidende an den Anfang oder ans Ende setzen |
| Gesprächsverlauf | Wächst monoton, bis Sie eingreifen | LongFuncEval: 13 bis 40 Prozent Degradation bei sich häufenden Runden | Bewusst zusammenfassen und neu starten, statt Fäden endlos laufen zu lassen |
| Angesammelte Werkzeugausgabe | Der unsichtbare Posten; wächst in Agenten-Workflows am schnellsten | LongFuncEval: 7 bis 91 Prozent Degradation bei länger werdenden Werkzeugantworten | Werkzeugrückgaben kürzen und zusammenfassen, bevor sie erneut ins Fenster gelangen |
Die fünfte Zeile ist der Ort, an dem die meisten Menschen verlieren, ohne es zu merken. In einem agentischen Workflow gibt jeder Werkzeugaufruf etwas zurück, und dieses Etwas bleibt für jede folgende Runde im Fenster. Eine Handvoll ausführlicher Antworten kann mehr Budget verbrauchen als die gesamte Aufgabenbeschreibung, und nichts in der Oberfläche sagt Ihnen, dass es passiert ist. Wenn Sie mehrstufige Arbeit an KI-Systeme delegieren, ist das das Wertvollste, was Sie instrumentieren können, und es passt direkt zu den Konzepten in unserem Leitfaden dazu, was man verstehen sollte, bevor man Arbeit an KI-Agenten delegiert.
Eine praktische Prüfung für diese Woche
Sie brauchen keine Infrastruktur, um anzufangen. Sie brauchen die Gewohnheit zu fragen, was im Fenster ist und ob es seinen Platz verdient.
Frage eins: Was ist da eigentlich drin? Die meisten können das für ihre eigenen Workflows nicht beantworten. Listen Sie die fünf Bewohner für eine Aufgabe auf, die Sie regelmäßig ausführen, und schätzen Sie den Anteil jedes einzelnen. Dass die Schätzung grob ist, spielt keine Rolle; die Entdeckung, dass abgerufene Dokumente oder Werkzeugverlauf dominieren, ist meist die ganze Erkenntnis.
Frage zwei: Was würde ich entfernen, wenn das Fenster ein Zehntel so groß wäre? Das ist die erzwingende Funktion. Sie identifiziert zuverlässig das Material, das aus Gewohnheit statt aus Notwendigkeit vorhanden ist. In den meisten laufenden Setups ist ein großer Anteil dessen, was im Fenster steht, dort, weil niemand es entfernt hat, nicht weil jemand entschieden hat, dass es dort sein sollte.
Frage drei: Wo sitzt die entscheidende Information? Angesichts der in der TACL-Arbeit dokumentierten U-förmigen Kurve wird Material, das in der Mitte einer langen Eingabe vergraben ist, am unwahrscheinlichsten genutzt. Verschieben Sie das, wovon die Antwort abhängt, an den Anfang oder ans Ende, und prüfen Sie, ob sich die Ausgabe ändert. Sie tut es häufig, und das ist eine günstige, selbst durchgeführte Replikation eines veröffentlichten Effekts.
Frage vier: Ist dieser Fehler ein Formulierungs- oder ein Kontextproblem? Die Diagnostik ist unkompliziert. Produziert das Modell eine selbstsichere Antwort, die über die von Ihnen gelieferten Fakten falsch ist, ist es ein Kontextproblem: Das Material war vorhanden, wurde aber nicht genutzt, oder fehlte, als Sie annahmen, es sei da. Produziert das Modell die richtigen Fakten in der falschen Form, ist es ein Formulierungsproblem. Beides sieht von außen identisch aus und hat völlig verschiedene Lösungen, und zum Prompt zu greifen, wenn der Fehler im Kontext liegt, ist die häufigste vergeudete Stunde in dieser Arbeit.
Frage fünf: Wann habe ich zuletzt neu gemessen? Jede Zahl in diesem Artikel hängt an einer bestimmten Modellgeneration. Die NoLiMa-Ergebnisse beschreiben die 2025 getesteten Modelle. Die LongFuncEval-Kurven beschreiben die Systeme, die es beim Verfassen der Arbeit gab. Jede neue Generation verschiebt diese Grenzen, im Allgemeinen in die richtige Richtung, und keine hat die Lücke zwischen beworbener und nutzbarer Kapazität bislang geschlossen. Die Gewohnheit des Nachprüfens ist dauerhafter als das Auswendiglernen irgendeiner Schwelle, was genau das Argument ist, das wir zur Fähigkeit, KI-Ausgaben zu beurteilen, machen.
Warum das eine echte Fähigkeit ist und keine Umbenennung
Es gibt einen vernünftigen Einwand: Context Engineering sei Prompt Engineering mit einem beeindruckenderen Namen, erfunden, weil der alte Name unseriös zu klingen begann.
Der Einwand scheitert an einem konkreten Test. Die beiden Disziplinen unterscheiden sich darin, was sie beheben können und was nicht, und die Grenze ist scharf. Keine Umformulierung einer Anweisung repariert eine Tatsache, die abgerufen, aber in die tote Mitte einer Eingabe von 60.000 Token gesetzt wurde. Kein Rollenspiel und kein Schritt-für-Schritt-Rahmen rettet einen Funktionsaufruf, der scheiterte, weil vierzig Werkzeugdefinitionen geladen waren, wo vier relevant gewesen wären. Das sind strukturelle Fehler in der Zusammensetzung des Fensters, und sie sind nur behebbar, indem man diese Zusammensetzung ändert.
Das ist das Kennzeichen einer echten Disziplin statt einer Umbenennung: Sie hat eigene Fehlermodi, eigene Diagnostik und eigene Lösungen, von denen keine aus der Praxis erreichbar ist, aus der sie hervorging.
Die akademische Literatur hat dieselbe Entscheidung bereits getroffen. Eine im Juli 2025 nach systematischer Analyse von mehr als 1.400 Forschungsarbeiten veröffentlichte Übersicht zum Context Engineering für große Sprachmodelle behandelt es ausdrücklich als formale Disziplin, die über Prompt-Design hinausgeht, und zerlegt es in drei grundlegende Komponenten: Kontextabruf und -erzeugung, Kontextverarbeitung und Kontextverwaltung. Diese drei entsprechen fast exakt dem praktischen Budget oben, was ein beruhigendes Zeichen dafür ist, dass der Rahmen etwas Reales beschreibt und nicht etwas für eine Schlagzeile Erfundenes.
Es lohnt auch, ehrlich zu sein, für wen das gilt. Besteht Ihre KI-Nutzung aus einzelnen Gesprächsanfragen, ist die Formulierung tatsächlich der größte Teil Ihres Hebels, und Context Engineering bleibt weitgehend akademisch. In dem Moment, in dem Sie etwas Dauerhaftes bauen, also einen Workflow, der Dokumente abruft, Werkzeuge aufruft oder über viele Runden läuft, kippt die Balance hart, und sie kippt, ohne sich anzukündigen. Zu verstehen, wie Sprachmodelle tatsächlich funktionieren, macht den Grund offensichtlich: Das Fenster ist für die Dauer einer Anfrage die gesamte Welt des Modells, und alles darin konkurriert um dieselbe endliche Aufmerksamkeit.
Die CEO und die Studierende
Der CEO-Rahmen macht das sofort einleuchtend. Kontext ist ein Budget. Es hat eine harte Obergrenze, der Grenznutzen dessen, was Sie hineingeben, fällt viel schneller, als die Obergrenze nahelegt, und alles, was Sie hinzufügen, verdrängt etwas anderes. Niemand würde ein Unternehmen führen, indem er jede verfügbare Kapitaleinheit ausgibt, nur weil sie verfügbar ist. Genau das ist es, was das Füllen eines Kontextfensters bedeutet.
Der studentische Rahmen liefert die Disziplin, die das Budget braucht. Jede hier genannte Schwelle ist eine Momentaufnahme eines beweglichen Systems. Die richtige Reaktion auf eine veröffentlichte Zahl ist nicht, sie auswendig zu lernen, sondern den Test zu lernen, der sie erzeugt hat, damit Sie beim Erscheinen der nächsten Modellgeneration herausfinden können, wo die neue Grenze liegt, statt zu raten. NoLiMa existiert, weil jemand bemerkte, dass der übliche Test eine Lücke hatte, und einen härteren baute. Dieser Instinkt, zu prüfen, ob die Messung tatsächlich misst, was sie behauptet, ist der übertragbare Teil.
Wer in den nächsten Jahren mit diesen Systemen am besten arbeiten wird, sind nicht die Menschen mit den bestformulierten Prompts. Es sind jene, die jederzeit wissen, was im Fenster ist und warum.
Häufig gestellte Fragen
Was ist der Unterschied zwischen Context Engineering und Prompt Engineering in einem Satz?
Prompt Engineering optimiert die Anweisung; Context Engineering optimiert alles im Fenster des Modells, wovon die Anweisung in der Regel der kleinste Teil ist.
Löst ein größeres Kontextfenster das Problem?
Nicht zuverlässig. Der NoLiMa-Benchmark testete dreizehn Modelle, die alle mindestens 128.000 Token beanspruchen, und fand elf davon bei 32.000 Token unter der Hälfte ihrer Kurzkontext-Basislinie. Die Fähigkeit, Token aufzunehmen, ist nicht dieselbe Eigenschaft wie die Fähigkeit, sie zu nutzen.
Ist Prompt Engineering tot?
Nein. Es ist eine Komponente statt der ganzen Disziplin. Formulierung zählt weiterhin bei einzelnen Gesprächsaufgaben und bleibt die richtige erste Diagnose, wenn das Modell korrekte Fakten im falschen Format ausgibt.
Was ist die schnellste Verbesserung, die ich vornehmen kann?
Reduzieren Sie, was im Fenster ist, und verschieben Sie das Entscheidende an den Anfang oder ans Ende. Der in der TACL-Arbeit dokumentierte U-förmige Positionseffekt lässt sich an eigenen Aufgaben in wenigen Minuten replizieren, und das Ergebnis überrascht meist.
Warum degradieren Agenten-Workflows schneller als Chats?
Weil sie zwei Bewohner ansammeln, die ein Chat nicht hat: Werkzeugdefinitionen und Werkzeugausgaben. Die LongFuncEval-Messungen von IBM beziffern die Degradation auf 7 bis 85 Prozent bei wachsendem Werkzeugkatalog und 7 bis 91 Prozent bei länger werdenden Werkzeugantworten, zusätzlich zu den 13 bis 40 Prozent allein durch die Gesprächslänge.
Brauche ich spezielle Werkzeuge, um das zu praktizieren?
Nein. Die fünf Prüffragen in diesem Artikel erfordern nichts außer Aufmerksamkeit dafür, was Sie senden. Werkzeuge helfen im Maßstab, aber der größte einzelne Gewinn, nämlich Material zu entfernen, das aus Gewohnheit statt aus Notwendigkeit im Fenster steht, steht sofort allen offen.
Quellen
- Liu, Lin, Hewitt, Paranjape, Bevilacqua, Petroni und Liang, Lost in the Middle: How Language Models Use Long Contexts, Transactions of the Association for Computational Linguistics
- Modarressi, Deilamsalehy, Dernoncourt, Bui, Rossi, Yoon und Schütze, NoLiMa: Long-Context Evaluation Beyond Literal Matching, International Conference on Machine Learning, 2025
- Kate, Pedapati, Basu, Rizk, Chenthamarakshan, Chaudhury, Agarwal und Abdelaziz, LongFuncEval: Measuring the Effectiveness of Long Context Models for Function Calling, IBM Research, 2025
- Mei, Yao, Ge, Wang, Bi, Cai und Kollegen, A Survey of Context Engineering for Large Language Models, Juli 2025
Dieser Inhalt wurde nach eingehender Recherche mit Unterstützung von KI zusammengestellt und vom CEOtudent-Redaktionsteam geschrieben und für die Veröffentlichung aufbereitet.
This post is also available in:
