Was ist Context Engineering? Mehr als Prompt Engineering

Was ist Context Engineering?

Context Engineering ist die Disziplin, alles gezielt auszuwählen und zu ordnen, was ein KI Modell bei jedem Schritt sieht: Anweisungen, Gesprächsverlauf, Tool Ergebnisse, abgerufene Dokumente und Gedächtnis. Das Ziel ist, dem Modell die richtige Information zur richtigen Zeit zu geben, mit möglichst wenig Rauschen.

Was ist Context Engineering also im Alltag? Stellen Sie sich zum Beispiel eine kluge Fachkraft vor, die vor jeder Aufgabe eine frische Mappe bekommt. Also kann sie nur nutzen, was in der Mappe liegt. Fehlt etwas, dann rät sie. Liegt zu viel Ballast darin, dann übersieht sie die eine wichtige Seite.

Deshalb geht der Begriff weit über einen einzelnen gut geschriebenen Prompt hinaus. Er umfasst das gesamte Fenster: Regeln, frühere Nachrichten, Suchergebnisse, Tool Ausgaben und gespeicherte Notizen. Unser Team versteht das daher als Design und Engineering Aufgabe, nicht als Schreibtrick.

Der Begriff wurde populär, als KI Agenten sich verbreiteten. Sobald ein Modell lange Aufgaben in vielen Schritten erledigt, dann verschiebt sich die Arbeit. Sie feilen dann nicht mehr an einem Satz. Stattdessen steuern Sie in jeder Runde, was ins Fenster gelangt.

In diesem Leitfaden erklären wir das Konzept in einfacher Sprache. Zunächst geht es um die Bausteine, danach um die Rolle bei Agenten, am Ende um eine Checkliste für einen Unternehmens Chatbot.

Was ist Context Engineering und wie unterscheidet es sich von Prompt Engineering?

Prompt Engineering konzentriert sich darauf, die Anweisung für das Modell gut zu formulieren. Context Engineering stellt die größere Frage: Welche Zusammenstellung von Informationen führt in diesem Schritt am ehesten zum gewünschten Verhalten? Anthropics Engineering Beitrag zum Kontext von Agenten zieht genau diese Linie.

Kurz gesagt ist Prompt Engineering ein Baustein, Context Engineering dagegen das ganze System. Schreibtechniken finden Sie in unserem Leitfaden zu Prompt Engineering. Deshalb wiederholen wir sie hier nicht.

Die Tabelle macht einen Punkt klar. Eine gut geschriebene Anweisung rettet allerdings keinen schlecht gewählten Kontext. Umgekehrt trägt ein gut geordneter Kontext oft sogar eine durchschnittliche Anweisung.

Anders gesagt lautet die kurze Antwort auf die Frage, was ist Context Engineering: die Gestaltung dessen, was das Modell sieht. Prompt Engineering deckt davon also nur den Schreibteil ab. Datenfluss, Gedächtnis und Werkzeuge brauchen daher eigene Entscheidungen.

Aus welchen Bausteinen besteht Context Engineering?

Die Information im Fenster eines Modells lässt sich in fünf Schichten teilen. Jede Schicht hat eine eigene Lebensdauer, eigene Risiken und eine eigene Pflege. Diese Aufteilung gibt Ihnen somit bei der Fehlersuche eine systematische Landkarte.

• Systemanweisung: Sie legt Rolle, Grenzen und Tonregeln des Modells fest.
• Gesprächsverlauf und Kurzzeitgedächtnis: Sie tragen, was innerhalb der Sitzung gesagt wurde.
• Langzeitgedächtnis: Es speichert Vorlieben oder Notizen über Sitzungen hinweg.
• Abgerufene Dokumente: Das sind Textstücke von außen, zum Beispiel über RAG.
• Tool Ergebnisse und strukturierter Zustand: Eine API Antwort, ein Abfrageergebnis oder der aktuelle Status einer Aufgabe.

Zudem altern die Schichten unterschiedlich schnell. Eine Systemanweisung bleibt womöglich wochenlang gleich, der Gesprächsverlauf wächst dagegen mit jeder Nachricht. Ein Tool Ergebnis zählt für einen Schritt und wird danach zu Ballast. Zum Beispiel belegt die rohe Antwort einer Bestellabfrage nach der Antwort nur noch Platz.

Außerdem teilen sich alle Schichten dasselbe Fenster. Wer einer Schicht Platz gibt, nimmt ihn einer anderen. Context Engineering heißt also, diesen Tausch bewusst zu steuern.

Welche Rolle spielt die Systemanweisung im Kontext?

Die Systemanweisung ist der stabilste Teil des Kontexts. Sie sagt dem Modell, wer es ist, was es tun und lassen soll und welchen Quellen es vertraut. Weil das Modell sie in jedem Schritt neu liest, muss sie kurz, klar und widerspruchsfrei sein.

Allerdings erzeugt eine sehr lange Anweisung zwei Probleme. Erstens geraten Regeln miteinander in Konflikt. Zweitens verteilt sich die Aufmerksamkeit des Modells auf Nebensachen. Auch Anthropic betont, dass Anweisungen weder übermäßig detailliert und brüchig noch vage sein sollten.

Viele Verbote aneinanderzureihen ist ebenfalls riskant. Denn je länger die Liste, desto schwerer erkennt das Modell, was erlaubt ist. Beschreiben Sie das gewünschte Verhalten stattdessen in positiven Sätzen und halten Sie die Grenzen kurz.

Unser praktischer Rat: Teilen Sie die Anweisung in Abschnitte und geben Sie jedem Abschnitt genau eine Aufgabe. Rolle, Grenzen, Ton und Ausgabeformat bekommen je eine Überschrift. So ändern Sie eine Regel, ohne die anderen zu beschädigen.

Wie funktionieren Kurzzeit und Langzeitgedächtnis im Kontext?

Das Kurzzeitgedächtnis ist der Verlauf des aktuellen Gesprächs. Zunächst: Ein Modell erinnert sich nicht von selbst an frühere Nachrichten. Deshalb sendet Ihre Anwendung den Verlauf mit jeder Anfrage erneut. Die Dokumentation von OpenAI zum Gesprächszustand beschreibt diesen Ansatz und seine Alternativen.

Das Langzeitgedächtnis speichert Informationen über Sitzungen hinweg. Eine bevorzugte Sprache oder eine Notiz zur letzten Bestellung gehört in diese Schicht. Auch die Dokumentation von Googles Agent Development Kit behandelt Zustand, Gedächtnis und Dateiverweise als getrennte Konzepte.

Gedächtniseinträge können außerdem veralten. Ändert ein Kunde seine Adresse und die alte bleibt gespeichert, nutzt das Modell sie mit voller Überzeugung. Daher brauchen Sie Logik zum Aktualisieren und Löschen.

Die zentrale Entscheidung lautet, was Sie ins Gedächtnis schreiben. Speichern Sie alles, dann bläht sich auch das Gedächtnis auf. Sichern Sie deshalb nur, was später wirklich hilft, und zwar nach einer klaren Regel. Bei Notizen mit personenbezogenen Daten planen Sie Aufbewahrungsfrist und Löschweg von Anfang an mit.

Wie gelangen abgerufene Dokumente und Tool Ergebnisse in den Kontext?

Firmendokumente, Produktkataloge oder Hilfeartikel gehören nicht zum Training eines Modells. Deshalb sucht Ihre Anwendung die passenden Stücke heraus und legt sie in den Kontext. Die wichtigste Methode ist RAG (Retrieval Augmented Generation). Wie Sie Dokumente in Stücke teilen, behandelt unser Beitrag zu Chunking.

Ebenso gelangen Tool Ergebnisse auf demselben Weg ins Fenster. Ruft ein Modell ein Werkzeug auf, wird das Ergebnis zur Eingabe des nächsten Schritts. Function Calling erklärt diesen Mechanismus. Ein Werkzeug, das eine lange Tabelle oder rohes JSON liefert, füllt den Kontext daher schnell.

Auch die Zahl der Dokumentstücke ist eine Entscheidung. Viele Stücke pro Frage wirken sicher, bringen allerdings oft Rauschen. Konkret schlagen wenige passende Stücke meist viele halb passende. Die richtige Balance finden Sie, indem Sie mit Ihren eigenen Daten testen.

Vereinfachen Sie deshalb die Ausgabe von Werkzeugen so weit wie möglich. Streichen Sie Felder, die das Modell nicht braucht, und liefern Sie bei langen Listen nur die ersten Treffer oder Zusammenfassungen. Nutzen Sie zusätzlich strukturierte Ausgaben, bleibt die Eingabe jedes Schritts vorhersehbar.

Was ist Context Engineering und warum ist es für Agenten so wichtig?

Bei einer einzelnen Frage mit einer Antwort bleibt der Kontext also klein und leicht zu steuern. Agenten dagegen gehen viele Schritte, um ein Ziel zu erreichen. Konkret rufen sie in jedem Schritt Werkzeuge auf, lesen Ergebnisse und ändern den Plan. Folglich wächst der Kontext in jeder Runde.

Kontrolliert niemand dieses Wachstum, dann passieren drei Dinge. Zunächst belegen alte, nutzlose Ausgaben Platz im Fenster. Dann verbraucht das Modell Aufmerksamkeit für Details ohne Bezug zur neuen Aufgabe. Schließlich steigen Kosten und Wartezeit, weil jede Runde mehr Eingabe verarbeitet.

Auch die Kommunikation zwischen Agenten prägt Kontextentscheidungen. In unserem Beitrag zum A2A Protokoll haben wir den Standard dafür erklärt. Übergibt ein Agent eine Aufgabe an einen anderen, ist die Frage, wie viel Information er mitgibt, ein Thema für Context Engineering.

Die Fehlersuche bei Agenten zeigt oft dasselbe Bild. Die ersten drei Schritte laufen gut, im zehnten vergisst der Agent das Ziel. Meist ist das Modell nicht defekt, denn das Fenster ist voll mit alten Versuchen und unnötiger Ausgabe.

Wenn Sie Agenten bauen, deckt unsere Leistung zur Entwicklung von KI Agenten solche Designentscheidungen ab.

Warum verursachen aufgeblähter Kontext und irrelevante Informationen Probleme?

Kontextaufblähung heißt, dass sich das Fenster mit mehr minderwertiger Information füllt, als die Aufgabe braucht. Anthropic beschreibt dazu einen Effekt: Wächst das Fenster, kann die Fähigkeit des Modells sinken, Information abzurufen. Als Erklärung nennt der Beitrag ein begrenztes Aufmerksamkeitsbudget.

Irrelevante Information kann außerdem in die Irre führen. Fragt ein Kunde zum Beispiel nach dem Versand, während im Fenster eine lange Rückgaberichtlinie liegt, antwortet das Modell womöglich aus dem falschen Dokument. Solche Fehler sehen oft nach Halluzination aus, die Ursache liegt aber im Kontext.

Ablenkende Information muss allerdings nicht falsch sein. Auch korrekte, aber unpassende Information kann das Modell vom Kurs abbringen. Das Problem ist also nicht nur die Qualität des Inhalts, sondern auch, ob er an diese Stelle gehört.

Widersprüchliche Information gehört ebenso zur selben Familie. Liegen eine alte und eine neue Preisliste gemeinsam im Fenster, weiß das Modell nicht, welcher es trauen soll. Die Lösung ist einfach, verlangt aber Disziplin: Entfernen Sie Veraltetes und versehen Sie jedes Dokument mit einem Aktualitätsvermerk.

• Wiederholen Sie dieselbe Information nicht an mehreren Stellen.
• Löschen oder fassen Sie veraltete Tool Ergebnisse in späteren Runden zusammen.
• Legen Sie widersprüchliche Quellen nie gemeinsam ins Fenster.
• Ergänzen Sie jedes Dokumentstück um Quelle und Datum.

Was sagt der Befund Lost in the Middle über Context Engineering?

Die Arbeit Lost in the Middle untersucht, wie Sprachmodelle lange Eingaben nutzen. Laut Zusammenfassung ist die Leistung oft am höchsten, wenn die relevante Information am Anfang oder am Ende der Eingabe steht. Information in der Mitte nutzt das Modell schlechter.

Dieser Befund zeigt also, dass die Platzierung auch bei Modellen mit langem Fenster zählt. Allerdings haben die Forschenden bestimmte Modelle bei bestimmten Aufgaben gemessen. Sie sollten das Verhalten heutiger Modelle deshalb nicht eins zu eins auf die Arbeit übertragen. Als Richtung bleibt es trotzdem ein nützlicher Hinweis.

Die praktische Folgerung: Rücken Sie Ihre wichtigste Regel und den stärksten Beleg an den Anfang oder das Ende des Fensters. Stapeln Sie nicht viele Dokumente wahllos, sondern halten Sie die passendsten vorn. Zur Reihenfolge lesen Sie unseren Beitrag zum Reranker.

Hilfreich ist auch, ein langes Dokument in Abschnitte zu teilen und den passenden zuerst zu zeigen. Das mildert somit das Platzierungsproblem und verkürzt den Text, den das Modell lesen muss.

Testen Sie daher immer mit Ihren eigenen Daten. Stellen Sie dieselbe Frage mit dem Beleg an zwei verschiedenen Stellen und vergleichen Sie die Ergebnisse.

Was ist der Unterschied zwischen statischem und dynamischem Kontext?

Statischer Kontext ist die Information, die Sie vor Arbeitsbeginn ins Fenster legen. Dazu zählen zum Beispiel die Systemanweisung und feste Regeln. Dynamischer Kontext ist Information, die erst bei Bedarf nachgeladen wird. Anthropic nennt diesen Ansatz Just in Time Retrieval, also bedarfsgerechtes Abrufen.

Die Idee ist einfach: Statt alles vorab zu laden, halten Sie leichte Verweise bereit. Das können zum Beispiel Dateipfade, Links oder gespeicherte Abfragen sein. Dann ruft das Modell die passenden Daten selbst ab, wenn es sie braucht. So trägt das Fenster nur, was der aktuelle Schritt verlangt.

Dieser Ansatz hat allerdings einen Preis. Dynamisches Abrufen kostet zusätzliche Schritte und Zeit. Außerdem muss das Modell das richtige Werkzeug und die richtige Abfrage wählen. Daher kombinieren Teams oft beides: Kritische Regeln bleiben statisch, ausführliche Daten dynamisch.

Über die Wahl entscheiden Datenmenge und gewünschte Antwortzeit. Bei einem kleinen, stabilen Hilfecenter kann statisches Laden genügen. Bei einem großen Katalog, der sich oft ändert, ist dynamisches Abrufen sinnvoller.

Wie sieht Context Engineering in einem Kundenservice Szenario aus?

Der folgende Fall ist ein Beispielszenario und kein echter Kundenfall. Stellen Sie sich einen Onlineshop vor, dessen Chatbot Fragen zu Rückgaben beantwortet. In der ersten Version landen alle Richtlinien, die komplette Bestellhistorie und eine lange Anweisung bei jeder Nachricht im Fenster.

Das Ergebnis ist also vorhersehbar. Antworten werden langsamer, die Kosten steigen, und das Modell nennt manchmal eine alte Rückgaberegel. Das Team sucht den Fehler im Modell, doch das Problem liegt im Aufbau des Fensters.

In der zweiten Version ändert das Team drei Dinge:

1. Es teilt die Anweisung in vier kurze Abschnitte und löscht widersprüchliche Regeln.
2. Es ruft nur die Richtlinienstücke ab, die zur Frage passen.
3. Es beschränkt das Bestellwerkzeug auf Status, Datum und Produktname.

Danach schrumpft das Fenster und die Antworten werden konsistenter. Trotzdem sollten Sie das mit einem festen Testsatz prüfen, statt es anzunehmen. Jedes Unternehmen hat andere Daten, deshalb weichen die Ergebnisse ab.

Wie entlasten Zusammenfassung und Verdichtung den Kontext?

Nähert sich eine lange Aufgabe dem Ende des Fensters, haben Sie zwei Grundoptionen. Sie verwerfen alte Schritte oder Sie fassen sie zusammen. Anthropic nennt diese Idee Compaction, also Verdichtung: Das Gespräch wird zusammengefasst und ein neues Fenster beginnt mit der Zusammenfassung.

Was behält eine gute Zusammenfassung? Getroffene Entscheidungen, offene Probleme und die ausdrücklichen Wünsche der Nutzer. Was lässt sie weg? Wiederholte Tool Ergebnisse und Sackgassen. Ist die Zusammenfassung schlecht, dann verliert das Modell womöglich unbemerkt ein wichtiges Detail.

Zweitens helfen strukturierte Notizen. Der Agent schreibt seinen Fortschritt in einen Notizbereich außerhalb des Fensters und liest ihn bei Bedarf zurück. Die dritte Methode sind Unteragenten: Jeder arbeitet in einem sauberen Fenster und liefert nur ein kurzes Ergebnis.

1. Messen Sie die Auslastung des Fensters und legen Sie eine Schwelle fest.
2. Erstellen Sie bei Überschreitung eine Zusammenfassung und prüfen Sie sie mit eigenen Kontrollfragen.
3. Setzen Sie wichtige Entscheidungen und Nutzerwünsche an den Anfang der Zusammenfassung.
4. Wollen Sie die Rohausgabe nicht verlieren, speichern Sie sie außerhalb und rufen Sie sie bei Bedarf erneut ab.

Wie hängen Context Engineering und Kontextfenster zusammen?

Das Kontextfenster ist die Gesamtmenge an Information, die ein Modell in einer Anfrage verarbeiten kann. Context Engineering entscheidet, was in diese Grenze hineinkommt. Anders gesagt: Das Fenster ist der Behälter, Context Engineering die Auswahl des Inhalts. Zum Begriff selbst lesen Sie unseren Beitrag zum Kontextfenster.

Laut der Anleitung von OpenAI umfasst das Fenster die Summe aus Eingabe, Ausgabe und Reasoning Tokens. Füllen Sie das Fenster also ganz mit Eingabe, bleibt kein Platz für die Antwort. Die Token Rechnung erklären wir im Beitrag zu Tokens.

Ein großes Fenster ist kein Grund, den Kontext zu ignorieren. Es schafft mehr Raum, beseitigt aber weder Ablenkung noch Kostenprobleme. Die aktuelle Fenstergröße prüfen Sie daher in der offiziellen Dokumentation des Anbieters.

Welchen Zusammenhang gibt es zwischen Context Engineering und Prompt Caching?

Prompt Caching verwendet den unveränderten Teil der Eingabe über Anfragen hinweg wieder, statt ihn neu zu verarbeiten. Details finden Sie in unserem Beitrag zu Prompt Caching. Damit ein Cache hilft, muss der Kontext in stabiler Reihenfolge aufgebaut sein.

Deshalb beeinflusst das Kontextdesign direkt die Kosten. Konkret setzen Sie unveränderliche Teile wie die Systemanweisung und feste Referenzen an den Anfang. Häufig wechselnde Teile wie die Nutzernachricht und frische Tool Ergebnisse hängen Sie hinten an. Ändert sich die Reihenfolge ständig, dann nützt der Cache weniger.

Zu den Kosten noch ein Hinweis. Denn je größer die Eingabe, desto teurer wird jede Runde. Ein schlankerer Kontext spart also Zeit und Budget. Qualität und Kosten verbessern sich daher oft in dieselbe Richtung.

Die Einzelheiten hängen vom Anbieter ab. Prüfen Sie in der offiziellen Dokumentation, welche Teile wie lange und unter welchen Bedingungen im Cache bleiben. Zahlen nennen wir hier nicht, denn sie ändern sich mit der Zeit.

Wie verhält sich Context Engineering zu RAG, MCP und Function Calling?

Diese Begriffe werden oft verwechselt, weil alle Information zum Modell bringen. Der Unterschied: Context Engineering ist der Oberbegriff, der sie steuert. Die anderen sind somit Mechanismen darunter.

Zum Verbindungsstandard lesen Sie unseren Beitrag zu MCP, zur Suchschicht den Beitrag zu Embeddings. Hier erwähnen wir sie nur, soweit sie den Kontext betreffen.

Wann brauchen Sie Context Engineering?

Für eine einfache Aufgabe in einem Schritt reicht oft eine sorgfältige Anweisung. Um zum Beispiel einen Text zusammenzufassen oder eine E-Mail umzuschreiben, entwerfen Sie keinen eigenen Kontext. Mit wachsendem System wird der Bedarf allerdings deutlich.

Diese Anzeichen zeigen, dass es Zeit ist:

• Ihr Chatbot vergisst in langen Gesprächen frühe Aussagen oder verwechselt sie.
• Sie erhalten an verschiedenen Tagen unterschiedlich gute Antworten auf dieselbe Frage.
• Ihr Agent weicht nach wenigen Schritten vom Ziel ab.
• Ihre API Kosten wachsen schneller als die Nutzung.
• Bei Antworten aus Firmendokumenten nennt er das falsche Dokument.

Außerdem steigt der Bedarf schnell, sobald Sie mehrere Werkzeuge und Datenquellen anbinden. Ein Assistent, der Kalender, Lagerbestand und Dokumente liest, muss zum Beispiel die Ausgabe jeder Quelle steuern.

Erkennen Sie zwei oder mehr dieser Anzeichen, prüfen Sie zuerst den Kontext und erst dann das Modell. Oft liegt das Problem also nicht im Modell, sondern in der Information, die Sie ihm geben.

Wie sieht eine Checkliste für Context Engineering bei einem Unternehmens Chatbot aus?

Bauen Sie einen Kundenservice Chatbot oder einen internen Wissensassistenten, können Sie die folgende Liste als Ausgangspunkt nutzen. Sie ist allerdings nur ein Beispielrahmen. Passen Sie ihn daher an Branche und Datenstruktur an.

1. Teilen Sie die Systemanweisung in Abschnitte und entfernen Sie widersprüchliche Regeln.
2. Schreiben Sie auf, zu welchen Themen der Chatbot nicht antwortet und wann er übergibt.
3. Entscheiden Sie, welche Information im Sitzungsgedächtnis und welche im dauerhaften Gedächtnis liegt.
4. Legen Sie für Notizen mit personenbezogenen Daten Aufbewahrungsfrist und Löschweg fest.
5. Kennzeichnen Sie Dokumentquellen mit einem Aktualitätsvermerk und entfernen Sie veraltete.
6. Fügen Sie jeder Antwort das Quelldokument bei, damit Prüfungen leichter fallen.
7. Vereinfachen Sie Tool Ergebnisse und liefern Sie nur nötige Felder.
8. Definieren Sie für lange Gespräche eine Zusammenfassungsschwelle und einen Test für die Zusammenfassung.
9. Protokollieren Sie Eingabegröße und Kosten jedes Schritts.
10. Testen Sie regelmäßig mit echten Beispielfragen und vergleichen Sie die Ergebnisse.

Planen Sie ein Chatbot Projekt, deckt unsere Leistung zur Chatbot Entwicklung eine solche Umsetzung ab.

Welche Fehler passieren bei Context Engineering am häufigsten?

Der häufigste Fehler in Teams ist die Annahme, mehr Information bedeute eine bessere Antwort. Tatsächlich lenkt zusätzliche Information das Modell ab und erhöht die Kosten. Ziel ist deshalb nicht, das Fenster zu füllen, sondern die kleinste Informationsmenge zu finden, die den Bedarf deckt.

Der zweite Fehler ist, den Kontext einmal zu bauen und dann zu vergessen. Denn Produktkataloge, Richtlinien und Preise ändern sich. Bleiben die Kontextquellen unverändert, dann antwortet das Modell weiter mit alten Informationen.

• Die Anweisung endlos erweitern und Regeln vermischen.
• Rohe Tool Ausgaben unverändert ins Fenster kippen.
• Den Gesprächsverlauf verlängern, ohne je zusammenzufassen.
• Nicht festhalten, aus welcher Schicht eine Information stammt.
• Eine neue Dokumentquelle ohne Test hinzufügen.

Ein weiterer Fehler ist, Daten verschiedener Nutzer im selben Kontext zu mischen. Ziehen Sie Sitzungsgrenzen nicht klar, dann kann die Information eines Kunden in der Antwort eines anderen auftauchen. Das ist ein Qualitäts und ein Datenschutzproblem.

Schließlich genügt es bei der Fehlersuche nicht, nur die Ausgabe anzusehen. Sie müssen festhalten, was das Modell in diesem Schritt genau gesehen hat. Ohne die Eingabe ist die Ursache somit kaum zu finden.

Wie testen und messen Sie die Qualität des Kontexts?

Bewerten Sie Änderungen am Kontext mit einem festen Testsatz und nicht nach Bauchgefühl. Stellen Sie eine kurze Liste echter Kundenfragen zusammen und notieren Sie die Merkmale der erwarteten Antwort. Führen Sie nach jeder Änderung dieselbe Liste aus.

Zu Bewertungsmethoden lesen Sie unseren Beitrag zu LLM Evals. Dort erklären wir zudem die Grenzen automatischer und modellgestützter Bewertung.

Außerdem empfehlen wir, drei Kennzahlen zu verfolgen. Erstens zählt Genauigkeit, also ob die Antwort zur Quelle passt. Zweitens zählt Konsistenz, also ob ähnliche Fragen ähnliche Antworten bekommen. Drittens zählt Effizienz, also Eingabegröße und Wartezeit je Antwort.

Nehmen Sie auch schwierige Beispiele in den Testsatz auf. Unklare Fragen, widersprüchliche Dokumente und Anfragen außerhalb des Themas decken Kontextfehler am schnellsten auf. Ein Test nur mit leichten Fragen führt Sie also in die Irre.

So erkennen Sie, ob eine Verbesserung wirklich eine ist. Sinkt zum Beispiel beim Verkleinern des Kontexts der Preis, aber auch die Genauigkeit, hat das gestrichene Stück Nützliches geleistet.

Welche Risiken und Grenzen hat Context Engineering?

Das erste Risiko ist die Sicherheit. Ein von außen geholtes Dokument oder eine Webseite kann Text enthalten, der für das Modell wie eine Anweisung aussieht. Dieses Problem behandelt unser Beitrag zu Prompt Injection. Behandeln Sie externe Inhalte im Kontext daher stets als nicht vertrauenswürdige Daten.

Das zweite Risiko ist der Datenschutz. Fließen Kundendaten durch Gedächtnis und Kontext, müssen Sie festlegen, wer sie sehen darf und wie lange sie bleiben. Dieser Beitrag ist allerdings keine Rechtsberatung zu personenbezogenen Daten oder Urheberrecht. Fragen Sie für Ihren Fall eine qualifizierte Fachperson.

Die dritte Grenze: Context Engineering ist keine Zauberei. Ein gut geordneter Kontext senkt Fehler, beseitigt sie aber nicht. Das Modell kann sich trotzdem weiter irren. Bei kritischen Entscheidungen brauchen Sie deshalb menschliche Freigabe und Guardrails.

Wo fängt Ihr Team mit Context Engineering an?

Fangen Sie klein an. Wählen Sie einen einzigen Anwendungsfall, etwa einen Kundenservice Chatbot. Halten Sie fest, was das Modell heute in jedem Schritt sieht. Die meisten Teams staunen beim ersten Mal, weil sie weit mehr unnötige Information im Fenster finden als erwartet.

Klären Sie zuerst das Ziel. Welche Fragen soll der Chatbot beantworten, welche an einen Menschen übergeben? Ohne diese Grenze können Sie also nicht entscheiden, was ins Fenster gehört. Die Grenze schriftlich festzuhalten ist somit der erste Schritt des Kontextdesigns.

Ordnen Sie danach die Probleme. Vereinfachen Sie zum Beispiel zuerst aufgeblähte Tool Ergebnisse, beheben Sie dann die Aktualität der Dokumente und ergänzen Sie zuletzt die Zusammenfassung. Führen Sie bei jedem Schritt denselben Testsatz aus.

Bestimmen Sie schließlich Verantwortliche. Wem gehören die Kontextquellen, wer aktualisiert die Dokumente, wer liest die Testergebnisse? Kontext ohne Besitzer verfällt also mit der Zeit.

Möchten Sie das im Unternehmensmaßstab angehen, unterstützen Talha Aslan und Team bei KI Beratung und Integration. Details finden Sie auf unserer Seite zur KI Beratung. Prüfen Sie aktuelle Modell, Fenster und Preisangaben immer in der offiziellen Dokumentation des Anbieters, denn dieser Leitfaden erklärt das Konzept und nennt keine versionsabhängigen Zahlen.