Prompt-Grundlagen: der Prompt ist eine Spezifikation, keine Beschwörung
Einführung · 8 Abschnitte · ~9 Min Lesezeit · Stand
Das mentale Modell: Prompt als Spezifikation
Ein guter Prompt ist keine magische Zauberformel, die man errät — er ist eine Spezifikation: eine präzise Beschreibung der Aufgabe, der Randbedingungen und des gewünschten Ergebnisses. Genau wie ein Ticket an einen Kollegen. Je vager die Spec, desto mehr muss das Modell raten — und es rät mit seinen eigenen Annahmen.
Spezifizität: Constraints statt Wünsche
„Fasse das zusammen“ ist eine Bitte, keine Spezifikation. Länge, Zielgruppe, Format, was rein- und was rausgehört — jede offene Achse produziert Varianz. Konkrete Constraints machen die Ausgabe wiederholbar.
| Vage | „Schreibe eine Antwort an den Kunden.“ |
|---|---|
| Spezifiziert | „Antwort an den Kunden, max. 4 Sätze, sachlich-freundlich, nenne die Ticket-Nummer, keine Entschuldigungs-Floskeln.“ |
Beispiele schlagen Erklärungen: Few-shot
Manche Anforderungen lassen sich leichter zeigen als beschreiben — ein Ton, ein Ausgabe-Muster, eine Klassen-Abgrenzung. Few-shot: ein paar repräsentative Eingabe→Ausgabe-Beispiele in den Prompt, statt die Regel in Prosa zu erklären.
Entscheidend sind die Grenzfälle: Beispiele, die genau die Unterscheidungen zeigen, an denen Zero-shot scheitert. Drei gute Beispiele mit klaren Rändern schlagen zehn generische.
Struktur: Instruktion und Daten trennen
Sobald du Nutzer- oder Dokument-Text in den Prompt einfügst, verschwimmt für das Modell, was Anweisung und was Daten ist. Ein zusammenhängender Textblock lädt zu Verwechslungen ein.
Abhilfe: den Daten-Teil klar abgrenzen und benennen — z. B. in Markdown-Codezäunen oder mit <daten>…</daten>-Markierungen — und dem Modell sagen, dass der markierte Teil reine Daten sind, keine Befehle.
Ausgabe erzwingen: das Format ist ein Vertrag
Wenn nachgelagerter Code die Ausgabe weiterverarbeitet, ist das Ausgabeformat ein Vertrag — kein Vorschlag. Freitext, der „meistens“ als JSON durchgeht, bricht in Produktion an dem einen Tag, an dem das Modell einen Satz voranstellt.
Spezifiziere ein striktes Schema (benannte Felder), gib ein Format-Beispiel, und validiere die Ausgabe programmatisch, statt auf Wohlverhalten zu hoffen.
Kontext & Rolle: den Rahmen setzen
Die Register- und Tiefen-Wahl des Modells hängt am Kontext, den du gibst: Zielgruppe, Zweck, Vorwissen. „Erkläre für einen erfahrenen DBA“ vs. „für einen Einsteiger“ liefert berechtigt verschiedene Antworten.
Positiv instruieren & Defaults benennen
Eine Liste aus lauter Verboten („mach nicht X, nicht Y“) sagt dem Modell, was es vermeiden soll — aber nicht, was es stattdessen tun soll. Das Ziel bleibt unterspezifiziert. Formuliere das gewünschte Verhalten positiv und explizit, ergänzt um die nötigen Grenzen.
Ebenso wichtig: Edge-Cases benennen. Was, wenn die Information fehlt, mehrdeutig ist oder außerhalb des Auftrags liegt? Wenn du den Fallback nicht spezifizierst, erfindet das Modell einen.
Prompting ist empirisch — gleich im Check
Prompt Engineering ist kein Formulierungs-Talent, sondern ein empirischer Loop: eine kleine Menge repräsentativer Eingabe→Erwartung-Paare bauen und den Prompt daran messen — nicht an einzelnen Anekdoten. Ein Prompt, der bei einer Frage besser klingt, ist keine Verbesserung, solange er nicht über die Menge besser misst (Brücke zum Evaluation-Track).