Kontext-Engineering: Was Prompt-Engineering abgelöst hat
Lange Zeit bedeutete „mit KI arbeiten“ nur eines: einen guten Prompt formulieren. 2025-2026 reicht das nicht mehr. Modelle rufen Tools auf, holen Dokumente über RAG, behalten Sitzungsspeicher und laufen in Agenten-Ketten. Über Qualität entscheidet nicht die Eleganz der Formulierung, sondern Kontext-Engineering - die Disziplin, die plant, genau was das Modell auf jedem Schritt sieht: Anweisungen, Fakten, Historie, Rechte und Grenzen. Unten - wie sie klassisches Prompt-Engineering abgelöst hat und wie man den Ansatz in Produkten und internen Prozessen umsetzt.
- Prompt - Anweisungstext; Kontext - der gesamte Modelleingang pro Schritt
- Shift - von „magische Phrase finden“ zu „richtiges Datenpaket zusammenstellen“
- Schichten - System, Retrieval, Speicher, Tools, Task-State, Policies
- Ziel - Stabilität, weniger Halluzinationen, Token-Kostenkontrolle
- Praxis - enger relevanter Kontext schlägt „alles ins Fenster stopfen“
- Fürs Business - Prozess und Architektur schlagen einen Glücks-Chat in ChatGPT
Was Prompt-Engineering ist - und wo es an Grenzen stieß
Prompt-Engineering ist die Fähigkeit, LLM-Anfragen so zu formulieren, dass Stil, Format und Verhalten stimmen: Rollen („du bist Senior-Analyst“), Few-Shot-Beispiele, Chain-of-Thought, starre Antwortvorlagen.
Es funktioniert gut für:
- einmalige Chat-Aufgaben;
- Entwurfsgenerierung;
- Teams schulen („wie man das Modell fragt“);
- Prototypen ohne Zugriff auf interne Daten.
Die Grenze zeigt sich schnell:
| Situation | Warum ein Prompt allein nicht reicht |
|---|---|
| Aktuelle Preise und Regeln nötig | Das Modell kennt deine Preisliste ohne Retrieval nicht |
| Langer Dialog / Agent mit Tools | Das Fenster füllt sich mit Rauschen; Fokus geht verloren |
| Mehrere Rollen und Systeme | Ein „universeller“ System-Prompt verwässert |
| Risiko- und Compliance-Kontrolle | Policies und PII-Maskierung sind keine „schöne Phrase“ |
| API-Kosten | Extra-Tokens pro Turn = direkter Verlust |
Der Prompt bleibt Teil des Systems. Er ist nicht mehr der Haupt-Hebelschlüssel für Qualität.
Was Kontext-Engineering ist
Kontext-Engineering (context engineering) entwirft das vollständige Eingabepaket für das Modell bei jedem Aufruf: was ins System gehört, was aus der Wissensbasis kommt, was aus dem Speicher, welche Tool-Ergebnisse gezeigt werden, was weggelassen und was verboten wird.
Ist der Prompt „wie man fragt“, ist Kontext „in welcher Informationsumgebung das Modell antwortet“.
Typische Kontextschichten:
- Anweisungen und Rolle - System-Prompt, Antwortpolitik, JSON-/Markdown-Format.
- Nutzeraufgabe - aktuelle Anfrage und minimal nötige Historie.
- Abgerufenes Wissen - Chunks aus Wiki, CRM, Code, FAQ via Suche/RAG.
- State - Funnel-Stufe, Deal-ID, Dokumentversion, Ergebnis des vorherigen Schritts.
- Tool-Observations - API-, SQL-, Browser-, MCP-Ausgaben.
- Grenzen - „kein Rabatt versprechen“, „keine PII zitieren“, „an Menschen eskalieren“.
Ein Kontext-Engineer denkt wie ein Pipeline-Designer, nicht wie ein Texter glücklicher Formulierungen.
Wie Kontext die „Prompt-Magie“ ablöste
| Früher (Prompt im Fokus) | Heute (Kontext im Fokus) |
|---|---|
| Langer Allzweck-System-Prompt | Enger Prompt + dynamische Eingabe-Assemblierung |
| Ganzes PDF in den Chat | Retrieval: nur relevante Chunks |
| „Merke den ganzen Dialog“ | Kompression, Zusammenfassung, selektiver Speicher |
| Ein Modell - ein Chat | Agenten, Orchestrator + Subagenten, getrennte Fenster |
| Qualität = Formulierungs-Kunst | Qualität = Relevanz, Aktualität, Schichtreihenfolge |
| Prompt-Text debuggen | Quelle debuggen: Retrieval-Miss, Tool-Fail, Overflow |
Der Paradigmenwechsel heißt nicht, dass Prompts „gestorben“ sind. Sie wurden eine Schicht neben Retrieval, Memory, Tools und Policies - wie eine SQL-Abfrage neben Schema und Indizes.
Warum der Shift 2025-2026 beschleunigte
Mehrere Faktoren trafen zusammen:
- Agenten und Tools - das Modell handelt, antwortet nicht nur; Kontext muss Tool-Ergebnisse enthalten.
- Lange Fenster - mehr passt hinein, aber mehr ohne Auswahl = Rauschen und höhere Kosten.
- Unternehmensdaten - ohne RAG und Dokumentversionierung sind Antworten fürs Business nutzlos.
- Multi-Agent - jeder Subagent braucht sein eigenes enges Briefing, nicht das volle Log.
- Kosten und Latenz - Kontext-Engineers optimieren das Token-Budget wie Backend-Payloads.
Deshalb verschob sich die Praxis: vom „Prompt Engineer“ hin zu Platform/ML-Eng und Product, die Kontext-Pipelines bauen.
Praxis: Kontext für einen Schritt zusammensetzen
Arbeits-Checkliste vor dem LLM-Aufruf:
- Schrittziel - was am Ende stehen soll (JSON, Entscheidung, Entwurf).
- Minimale Anweisungen - nichts doppeln, was Tools und Daten schon liefern.
- Retrieval - Top-k-Fragmente mit Metadaten (Quelle, Datum, Version).
- Historie - nur relevante Turns oder kurze Summary, nicht der ganze Thread.
- Tool-Ausgaben - roh, aber gekürzt; keine Secrets, keine überflüssigen Felder.
- Token-Budget - hartes Limit; bei Overflow: Anweisung → Aufgabe → Fakten → Historie.
- Policies - was das Modell nicht ohne Mensch behaupten darf.
Support-Beispiel:
[system] Rolle + Verbote + Format
[retrieved] 3 Knowledge-Base-Chunks (mit Datum)
[state] Ticket-ID, Kundentarif, Sprache
[user] aktuelle Frage
Nicht so:
[system] 4 Seiten „sei hilfreich...“
[history] 80 Nachrichten vollständig
[files] der gesamte Notion-Workspace
[user] Frage
Kontext vs Prompt: Was bei schlechter Antwort fixen
| Symptom | Oft per Prompt | Oft per Kontext |
|---|---|---|
| Falscher Ton / Format | Ja: Anweisung schärfen | Selten |
| Erfundene Fakten | „Erfinde nichts“ hilft wenig | Retrieval + ohne Quelle ablehnen |
| Veraltet | Datum in den Prompt | Dokumentversionen + Frischefilter |
| Modell „vergaß“ die Aufgabe | Am Ende wiederholen | Goal/State als eigenen Block halten |
| Teuer und langsam | Höflichkeit kürzen | Historie und Retrieval-Rauschen kürzen |
| Gefährliche Aktion | „Sei vorsichtig“ | Tool entfernen / Human-in-the-Loop |
Debug-Regel: zuerst Daten und Auswahl, dann Formulierungen.
Was das fürs Business bedeutet
Wenn du KI in CRM, Support, interne Suche oder Code-Agenten bringst:
- Budget geht weg von „Prompt-Kursen für Manager“ hin zu Korpus-Qualität, Indexierung, Logging und Zugriffsrichtlinien.
- Qualitäts-KPIs: Retrieval-Hit-Rate, Anteil Antworten „mit Quelle“, Kosten pro Szenario, Eskalationen.
- Prompt-Playbooks helfen weiter für manuelle Chats - Product-Grade-KI baut man als Kontext-Pipeline.
- Lange Kontextfenster vs RAG vs Fine-Tuning ist eine eigene Architekturfrage; siehe die Optionen.
Reife-Test für Inhaber: Kannst du erklären, aus welchen Quellen das Modell die Antwort zum gestrigen Kundencase gebaut hat? Wenn nicht - hast du noch Prompt-Engineering im Chat, nicht Kontext-Engineering im System.
Häufige Fehler
- Dem Modell „alles, was da ist“ füttern, weil das Fenster lang ist.
- Einen riesigen System-Prompt behalten statt dynamischer Assemblierung.
- RAG-Dokumente nicht versionieren - selbstsichere, aber veraltete Antworten.
- Subagenten das volle Orchestrator-Log statt eines kurzen Briefings geben.
- Secrets und PII im Kontext verstecken, „weil es fürs Modell bequemer ist“.
- Bessere Formulierung mit dem Flicken eines Datenlochs verwechseln.
Fazit
Prompt-Engineering hat uns beigebracht, mit Modellen zu sprechen. Kontext-Engineering lehrt Systeme zu bauen, in denen das Modell genau die Information, Tools und Grenzen bekommt, die der Schritt braucht - nicht mehr und nicht weniger. 2026 bestimmt Unternehmens-KI-Qualität keine „Zauberphrase“, sondern eine Pipeline: Faktauswahl, Speicher, Tools, Policies und Token-Budget. Der Prompt bleibt Teil dieser Pipeline - aber nicht mehr der Hauptakteur.
Häufig gestellte Fragen
Worin unterscheidet sich Kontext- von Prompt-Engineering?
Prompt-Engineering fokussiert den Anweisungstext. Kontext-Engineering deckt den ganzen Modelleingang ab: Anweisungen + abgerufene Fakten + Historie + State + Tool-Ergebnisse + Verbote. Der Prompt ist eine Schicht; Kontext ist das System, das diese Schicht und die anderen zusammensetzt.
Braucht man 2026 noch Prompt-Engineering?
Ja, als Skill und als Schicht. Klare Anweisungen, Formate und Few-Shot bleiben wichtig. Für Produkte und Agenten stabilisiert ein „perfekter Prompt“ die Qualität aber nicht ohne Datenauswahl, Speicher und Policies.
Ist das dasselbe wie RAG?
Nein - breiter. RAG ist ein Weg, Kontext mit Korpuswissen zu füllen. Kontext umfasst auch Dialogspeicher, Workflow-State, Tool-Ausgaben, Rollen und Safety-Policies. RAG ist eine typische wichtige Komponente, nicht die ganze Disziplin.
Wo sollte ein Unternehmen starten?
Wähle ein Szenario (Support, Regelwerkssuche, Sales-Assistent). Fixiere Wahrheitsquellen, baue Retrieval mit Datums-/Versionsangaben, komprimiere Historie zu Summary und logge „was in den Kontext ging“. Den Prompt feinjustieren, wenn die Daten aufhören zu lügen.
Woran erkenne ich Kontext- statt Modellproblem?
Wenn ein Modellwechsel (GPT → Claude → Gemini) den Fehler kaum ändert, Dokument- / Top-k- / Historien-Änderung aber schon - liegt es an der Eingabe-Assemblierung. Provider erst wechseln, wenn die Kontext-Pipeline transparent und messbar ist.