Grundlagen

Prompt Engineering

Definition

Prompt Engineering ist die Kunst, Anweisungen an ein Sprachmodell so zu formulieren, dass es zuverlässig das gewünschte Ergebnis liefert - klare Aufgabe, Beispiele, Format und Kontext statt vager Bitte.

Dasselbe Modell liefert je nach Formulierung stark unterschiedliche Ergebnisse. Gutes Prompt Engineering macht die Aufgabe explizit: Es nennt die Rolle, beschreibt Schritt für Schritt, was zu tun ist, gibt Beispiele für gutes Ergebnis und legt das Ausgabeformat fest. Oft ersetzt ein präziser Prompt ein teures Fine-Tuning.

In produktiven Systemen ist Prompt Engineering keine einmalige Textbastelei, sondern ein wiederholbarer, getesteter Prozess: Jede Prompt-Änderung wird gegen einen festen Testsatz geprüft (siehe Evaluation), damit eine Verbesserung an einer Stelle nicht unbemerkt an anderer Stelle schadet. Der Übergang zu Context Engineering ist fließend - dort rückt die Frage in den Mittelpunkt, welche Informationen dem Prompt überhaupt beigelegt werden.

In der Praxis

Ein Maschinenbauer sortiert Reklamationen

Ein Maschinenbauer mit 350 Mitarbeitenden bekommt täglich etwa 30 Reklamationen über verschiedene Kanäle. Sie sollen automatisch einer von sechs Kategorien zugeordnet werden, damit sie beim richtigen Team landen. Die erste Anweisung lautete sinngemäß: „Ordne die folgende Reklamation einer der sechs Kategorien zu.“ Rund zwei Drittel der Zuordnungen waren brauchbar - zu wenig, um die Vorsortierung durch Menschen abzulösen.

Die überarbeitete Fassung änderte vier Dinge: Jede Kategorie bekam eine Definition samt Abgrenzung zur jeweils ähnlichsten; drei Beispiele wurden beigelegt, darunter bewusst ein Grenzfall; das Ausgabeformat wurde festgelegt, inklusive einer kurzen Begründung mit Zitat aus dem Text; und das Modell bekam ausdrücklich die Kategorie „unklar“ erlaubt. Der größte einzelne Gewinn kam von dieser letzten Änderung - vorher musste das Modell raten, jetzt durfte es eskalieren.

Der entscheidende organisatorische Schritt war ein Testsatz: 80 echte Reklamationen, von zwei Mitarbeitenden von Hand zugeordnet, mit dokumentierten Uneinigkeiten. Jede weitere Änderung an der Anweisung läuft seitdem gegen diesen Satz. Genau das trennt Prompt Engineering vom Ausprobieren - ohne Messung merkt niemand, dass eine Verbesserung für Kategorie A die Kategorie C verschlechtert hat.

Abgrenzung

Nicht zu verwechseln mit

Context Engineering
Prompt Engineering formuliert die Anweisung, Context Engineering entscheidet, welche Informationen ihr überhaupt beigelegt werden. Bei Anwendungen mit Zugriff auf eigene Daten verschiebt sich der Hebel früh vom Wortlaut zur Auswahl des Materials.
Fine-Tuning
Ein Prompt wirkt sofort, ist in Minuten geändert und kostet Tokens bei jeder Anfrage. Fine-Tuning verankert Verhalten dauerhaft im Modell, verlangt aber Trainingsdaten und Pflege. Die Reihenfolge lautet fast immer: Prompt ausreizen, messen, erst dann über Training nachdenken.

Fehlerbilder

Worauf es ankommt

  • Beschwörung statt Präzision

    Zusätze wie „arbeite bitte besonders sorgfältig“ oder „das ist sehr wichtig“ verändern das Ergebnis kaum. Wirkung haben konkrete Beispiele, eine klare Definition der Begriffe und ein festgelegtes Ausgabeformat. Wer den Prompt verlängert, ohne ihn genauer zu machen, bezahlt Tokens für nichts.

  • Kein Ausweg für den Zweifelsfall

    Wenn die Anweisung eine Antwort erzwingt, liefert das Modell auch dann eine, wenn die Grundlage fehlt. Eine ausdrücklich erlaubte Antwort wie „unklar“ oder „nicht im Dokument enthalten“ ist oft die wirksamste einzelne Verbesserung - sie verwandelt stille Fehler in sichtbare Rückfragen.

  • Änderungen ohne Regressionstest

    Prompts sind wie Code ohne Typprüfung: Eine Änderung kann an unerwarteter Stelle etwas kaputt machen. Ohne einen festen Satz von Testfällen mit erwartetem Ergebnis bemerkt man Rückschritte erst im Betrieb - und kann dann nicht mehr rekonstruieren, welche Änderung sie verursacht hat.

  • Prompts nur in der Oberfläche pflegen

    Anweisungen, die ausschließlich im Chatfenster eines Anbieters existieren, sind nicht versioniert, nicht reviewbar und beim Personalwechsel verloren. Produktive Prompts gehören in die Versionsverwaltung - mit derselben Sorgfalt wie Quelltext.

Häufige Fragen

Was zu Prompt Engineering oft gefragt wird

Brauchen wir dafür einen eigenen Prompt Engineer?

In aller Regel nicht als eigene Stelle. Die inhaltliche Arbeit leistet, wer die Aufgabe fachlich beherrscht - die Mitarbeiterin, die Reklamationen seit Jahren zuordnet, schreibt die besseren Kategoriedefinitionen als jeder Externe. Was es braucht, ist jemand aus der IT, der Testsatz, Versionierung und Messung aufsetzt, damit aus Formulierungsarbeit ein überprüfbarer Prozess wird.

Wie viele Beispiele gehören in einen Prompt?

Meist genügen drei bis fünf, sofern sie die Bandbreite abdecken und mindestens einen Grenzfall enthalten. Mehr Beispiele kosten bei jeder Anfrage Tokens und bringen ab einem gewissen Punkt kaum noch Genauigkeit. Wenn auch zwanzig Beispiele die Trefferquote nicht ausreichend heben, liegt das Problem meist an unscharf definierten Kategorien, nicht an der Beispielzahl.

Ist Prompt Engineering überflüssig, wenn Modelle besser werden?

Der Aufwand verschiebt sich, er verschwindet nicht. Neuere Modelle verzeihen ungenaue Formulierungen besser, aber sie können immer noch nicht wissen, welche Ihrer sechs Kategorien wie abgegrenzt ist oder wann ein Fall an einen Menschen gehört. Diese Festlegungen sind Fachwissen Ihres Hauses und müssen weiterhin explizit gemacht und getestet werden.

← Alle Begriffe im Glossar

Von der Definition zur Umsetzung?

Lassen Sie uns besprechen, wie sich das konkret in Ihrem Unternehmen anwenden lässt.

Projekt anfragen