Ist Prompt Engineering damit tot?

Nein, aber es ist vom Handwerk zur Selbstverständlichkeit geworden: klare Anweisungen, Beispiele, gewünschtes Format – das bleibt. Nur liegt dort nicht mehr der Engpass. Zwischen einem mittelmäßigen und einem exzellenten KI-Ergebnis steht heute fast immer fehlender oder falscher Kontext, nicht die Formulierung der Anfrage.

Was ist der erste konkrete Schritt?

Eine ehrliche Bestandsaufnahme der eigenen Wissensbasis: Wo liegen die Informationen, die ein Modell für eure typischen Aufgaben bräuchte – und in welchem Zustand? Veraltete Wikis und verstreute PDFs sind das häufigste Hindernis. Kuratieren schlägt Anhäufen: eine kleine, gepflegte Wissensbasis liefert bessere Ergebnisse als ein großer, ungepflegter Datensumpf.

Was kostet Context Engineering typischerweise?

Weniger als der Aufbau eines klassischen Software-Projekts, aber mehr als ein guter Prompt. Der größte Kostenblock ist selten die Technik (Retrieval-Systeme sind heute Standardware), sondern die Personenzeit für Datenaufräumen und Testfall-Erstellung. Ein realistischer erster Schritt lässt sich mit überschaubarem Aufwand umsetzen, wenn die Wissensbasis nicht bei null anfängt – wächst der Aufwand aber, je chaotischer die Ausgangsdaten sind.

Ist Context Engineering nur für Unternehmen relevant?

Nein, das Prinzip gilt auch privat: Wer einem KI-Assistenten den eigenen Terminkalender, ein Rezept-Foto oder den Wortlaut eines Vertrags mitgibt, bekommt spürbar bessere Antworten als mit einer abstrakten Frage ohne Material. Der Unterschied ist nur die Systematik – Unternehmen brauchen dafür Prozesse und Pflege, Privatpersonen reicht die Gewohnheit, relevantes Material gleich mitzuliefern.

Wie unterscheidet sich Context Engineering von klassischem Wissensmanagement?

Es baut darauf auf, geht aber einen Schritt weiter: Klassisches Wissensmanagement organisiert Dokumente für Menschen, die selbst suchen und lesen. Context Engineering macht dieselben Quellen zusätzlich maschinenlesbar und zur Laufzeit automatisch abrufbar. Wer bereits ein gepflegtes Wiki oder eine saubere Dokumentenablage hat, hat einen Großteil der Arbeit schon erledigt – der Rest ist vor allem die technische Anbindung.

Technologie · KI im Unternehmen

Context Engineering: Warum Kontext den Prompt schlägt

Context Engineering entscheidet über KI-Qualität – nicht der Prompt. Die drei Ebenen, RAG vs. Fine-Tuning im Vergleich und der Einstieg in sieben Schritten.

Von Boaz Lichtenstein

Beitragsbild: Context Engineering: Warum Kontext den Prompt schlägt

Als ChatGPT neu war, galten Prompts als Geheimwissenschaft: magische Formulierungen, die bessere Antworten hervorzaubern. Diese Phase ist vorbei. Moderne Modelle verstehen normale Sprache – was ihnen fehlt, ist fast nie die richtige Anweisung, sondern der richtige Kontext: die Dokumente, Daten, Regeln und Werkzeuge, die für die Aufgabe relevant sind. Genau darum kümmert sich Context Engineering.

Das Wichtigste in Kürze

Kontext (Wissen, Werkzeuge, Regeln) schlägt Promptformulierung – Modelle verstehen Sprache längst gut genug, ihnen fehlt das Material.
Retrieval (RAG) bindet aktuelle, firmeneigene Informationen zur Laufzeit ein, statt sich auf das eingefrorene Trainingswissen zu verlassen.
Mehr Kontext ist nicht automatisch besser: Relevanz schlägt Menge, veralteter Kontext schadet mehr, als er nützt.
Ohne Testfälle mit erwarteten Antworten bleibt jede „Verbesserung“ reine Gefühlssache.
Der größte Hebel liegt in der Datenpflege, nicht in der Modellwahl.

Was zählt eigentlich zu Kontext? Die drei Ebenen

Kontext für ein KI-System besteht aus drei Bausteinen: dem Wissen, das es nachschlagen kann, den Werkzeugen, die es bedienen darf, und den Regeln, nach denen es antworten soll. Fehlt einer dieser Bausteine, sinkt die Ergebnisqualität – unabhängig davon, wie elegant der Prompt formuliert ist.

Wissen: Was muss das Modell nachlesen können? Produktdaten, interne Richtlinien, Verträge, Historie – typischerweise per Retrieval angebunden (RAG): Die Anfrage zieht sich die relevanten Passagen aus einer Wissensbasis, statt zu hoffen, dass das Modell sie aus dem Training kennt. Das reduziert nebenbei auch das Risiko erfundener Antworten, weil das Modell auf echte Quellen verweisen kann statt zu raten.
Werkzeuge: Was darf das Modell tun? Suchen, rechnen, Systeme abfragen, Dateien schreiben. Ein Modell mit Zugriff auf die echte Datenbank halluziniert keine Zahlen – es fragt sie ab. Genau dieser Baustein macht den Unterschied zwischen einem Chatbot und einem handlungsfähigen Agenten aus.
Regeln und Beispiele: Wie soll das Ergebnis aussehen? Stilvorgaben, Formatvorlagen, zwei, drei Gold-Standard-Beispiele. Das ersetzt seitenlange Beschreibungen fast immer – ein einziges gutes Beispiel transportiert oft mehr als ein Absatz Anweisung.

RAG, Fine-Tuning oder größeres Kontextfenster: Die Optionen im Vergleich

Es gibt drei technische Wege, ein Modell mit Wissen zu versorgen: Retrieval (RAG) holt passende Dokumente zur Laufzeit, Fine-Tuning trainiert das Modell auf eigene Daten um, und ein großes Kontextfenster schiebt relevantes Material direkt in den Prompt. Für die meisten Unternehmensfälle ist RAG der pragmatischste Startpunkt.

Ansatz	Wie aktuell?	Aufwand	Wann sinnvoll
RAG (Retrieval)	Sofort aktuell – Quelle wird bei jeder Anfrage neu gezogen	Mittel (Indexierung, laufende Pflege)	Faktenwissen, sich häufig ändernde Dokumente
Fine-Tuning	Nur so aktuell wie beim letzten Training	Hoch (Trainingsdaten, Rechenzeit, Fachwissen)	Stil, Tonfall, wiederkehrendes Spezialformat
Langes Kontextfenster	Aktuell, aber teurer bei jeder einzelnen Anfrage	Niedrig (kein zusätzliches System)	Kleine, überschaubare Wissensbasis

In der Praxis schließen sich die Ansätze nicht aus: Viele produktive Systeme kombinieren RAG für Faktenwissen mit wenigen Beispielen für den Stil – Fine-Tuning bleibt die Ausnahme für Spezialfälle, weil es am teuersten zu pflegen ist. Ein Faustwert für die Entscheidung: Ändert sich das zugrunde liegende Wissen häufiger als der gewünschte Schreibstil, führt so gut wie kein Weg an Retrieval vorbei – Fine-Tuning friert einen Wissensstand ein, den man kurz darauf schon wieder aktualisieren müsste.

So baust du Context Engineering auf – Schritt für Schritt

Bestandsaufnahme: Wo liegt relevantes Wissen – Wikis, PDFs, Tickets, CRM, E-Mail-Archive?
Aufräumen: Veraltete und doppelte Dokumente aussortieren, bevor überhaupt etwas indexiert wird. Ein gepflegter kleiner Bestand schlägt einen riesigen ungepflegten.
Testfälle sammeln: Zwanzig bis fünfzig reale Aufgaben mit den jeweils erwarteten, richtigen Antworten zusammentragen.
Retrieval aufsetzen: Wissensbasis anbinden (RAG), benötigte Werkzeugzugriffe definieren.
Erste Version gegen die Testfälle prüfen und Lücken konkret benennen, statt pauschal „das passt schon“ zu sagen.
Gezielt nachschärfen: fehlende Dokumente ergänzen, veraltete entfernen – nicht wahllos mehr Material hinzufügen.
Pflege-Verantwortung festlegen: Wer aktualisiert die Wissensbasis laufend, wenn sich Prozesse oder Produkte ändern?

Die häufigsten Fehler

Zu viel Kontext: Wer dem Modell wahllos hundert Dokumente in den Prompt kippt, verdünnt die relevanten Informationen – Qualität sinkt, Kosten steigen. Relevanz schlägt Menge. Veralteter Kontext: Ein RAG-System über einem ungepflegten Wiki liefert selbstbewusst falsche Antworten – die Pflege der Quelle ist Teil des Systems, nicht optional. Fehlende Evaluation: Ohne Testfälle mit erwarteten Ergebnissen bleibt jede Verbesserung Gefühlssache. Ein Satz von fünfzig realen Aufgaben mit Soll-Antworten ist das wertvollste Artefakt eines KI-Projekts. Fehlende Zugriffssteuerung: Kontext, der jedem Nutzer alles zeigt – unabhängig von Berechtigung –, ist kein technisches Detail, sondern ein Sicherheitsrisiko, besonders sobald Agenten mit Werkzeugzugriff im Spiel sind (mehr dazu in unserem Artikel zu Prompt Injection und Agenten-Sicherheit).

Aus der Praxis: Wann lohnt sich der Aufwand

Nicht jede Aufgabe braucht ein aufwendiges Retrieval-System. Ein einfacher Prompt mit ein, zwei eingefügten Dokumenten reicht für Einzelaufgaben völlig aus. Systematisches Context Engineering lohnt sich, sobald eine Aufgabe wiederkehrt, mehrere Personen sie nutzen oder Fehler teuer werden – etwa bei Kundenanfragen, internem Support oder KI-Agenten, die eigenständig Aufgaben erledigen. Für Einzelfälle gilt: erst ausprobieren, ob ein gut formulierter Prompt mit Kopier-Kontext reicht, bevor ein System gebaut wird, das anschließend niemand pflegt. Ein Nebeneffekt sauberen Kontexts, der in der Praxis unterschätzt wird: gut kuratierte Quellen senken auch das Risiko, dass das Modell überzeugend klingende, aber falsche Antworten produziert – Details dazu in unserem Artikel zu KI-Halluzinationen.

Ein Beispiel macht den Unterschied greifbar: Ein Support-Team beantwortet monatlich mehrere Hundert Rückfragen zu Rücksendungen. Ohne Kontext liefert ein Chatbot generische Antworten, die Mitarbeitende in vielen Fällen von Hand nachbessern müssen. Bindet man dieselbe KI stattdessen an die aktuelle Rückgabe-Richtlinie und die Historie ähnlicher Tickets an, sinkt der Nachbesserungsaufwand spürbar – nicht, weil das Modell besser geworden ist, sondern weil es plötzlich weiß, welche Regeln für diesen einen Fall tatsächlich gelten.

Unterm Strich

Context Engineering ist unglamourös – Datenpflege, Schnittstellen, Testfälle. Aber es ist der Unterschied zwischen einer KI, die beeindruckende Demos liefert, und einer, die verlässlich arbeitet. Modelle werden austauschbarer; der kuratierte Kontext eines Unternehmens ist es nicht. Wer klein anfängt – eine Aufgabe, eine gepflegte Wissensbasis, ein Satz Testfälle – merkt den Unterschied schneller, als ein komplettes System aufzubauen dauern würde. Der langfristige Wert liegt dabei nicht im einzelnen Projekt, sondern in der Gewohnheit: Ein Team, das Kontext systematisch pflegt, wird mit jedem neuen Modell automatisch besser – ohne Kontext bleibt jedes neue Modell nur ein neues Versprechen.