# Grundlagen: der Prompt als Spezifikation > Die Kern-Hebel eines zuverlässigen Prompts — Spezifizität, Beispiele, Ausgabeformat, Struktur und das empirische Vorgehen dahinter. Track: [Prompt Engineering](https://physar.tech/learn/prompt-engineering) Kanonische Fassung: https://physar.tech/learn/prompt-engineering/prompt-foundations Stand: 2026-07-22 Interaktiver Teil: 8 Checks (nur im Browser) ## Prompt-Grundlagen: der Prompt ist eine Spezifikation, keine Beschwörung ### 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. _[Abbildung: Ein Prompt strukturiert Aufgabe, Kontext und erwartete Ausgabe; Validierung und Berechtigung bleiben jedoch Aufgaben des Systems.]_ > **Grundregel:** Alles, was du nicht spezifizierst, füllt das Modell selbst — nach seinem statistischen Default, nicht nach deinem Bedarf. Unterspezifikation ist die häufigste Ursache für „das Modell macht nicht, was ich will“. ### 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.“ | > **Merksatz:** Jede nicht genannte Anforderung ist eine Wette darauf, dass das Modell deinen Geschmack trifft. Spezifizieren heißt, diese Wetten zu eliminieren. ### 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. > **Wann Few-shot:** Wenn du eine Regel dreimal umformulierst und das Modell sie trotzdem missversteht, hör auf zu erklären — **zeig** ein Beispiel. ### 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 `…`-Markierungen — und dem Modell sagen, dass der markierte Teil reine Daten sind, keine Befehle. > **Mehr als Kosmetik:** Dieselbe Trennung ist die erste Verteidigungslinie gegen Prompt Injection (Details im Security-Track). Hier zählt zunächst: klare Struktur = zuverlässigeres Befolgen. ### 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. > **Vertrauen, aber prüfen:** Ein Format vorzugeben senkt die Fehlerquote; es garantiert sie nicht. Die Validierung nachgelagert bleibt Pflicht — das Modell ist kein deterministischer Parser. ### 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. > **Kontext, nicht Kostüm:** Wirksam ist der **aufgabenrelevante Kontext** (Zielgruppe, Zweck, Constraints) — nicht die Behauptung „du bist ein Weltklasse-Experte“. Gib dem Modell Information, keine Verkleidung. ### 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. > **Merksatz:** Sag, was zu tun ist — nicht nur, was zu lassen ist. Und definiere den Normalfall **und** den Ausnahmefall, sonst tut es das Modell für dich. ### 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). > **Gleich im Check:** Du entscheidest jetzt selbst: welcher Hebel bei welchem Symptom — Spezifizität, Beispiele, Format, Struktur, Kontext, positive Instruktion — und wann das Problem gar nicht am Prompt liegt. ## Quellen - Language Models are Few-Shot Learners — Brown et al., 2020 - Training language models to follow instructions with human feedback (InstructGPT) — Ouyang et al., 2022 - A Systematic Survey of Prompt Engineering in Large Language Models — Sahoo et al., 2024 - Training language models to follow instructions with human feedback — Ouyang et al., 2022 - OWASP Top 10 for LLM Applications — LLM01: Prompt Injection - Survey of Hallucination in Natural Language Generation — Ji et al., 2023 - RAGAS: Automated Evaluation of Retrieval Augmented Generation — Es et al., 2023