Grundlagen: der Prompt als Spezifikation

Der Prompt ist eine Spezifikation, kein Wunsch

Die meisten schlechten Prompts sind nicht falsch formuliert — sie sind unvollständig. Sie beschreiben, was jemand sich wünscht, und lassen offen, woran man erkennen würde, dass der Wunsch erfüllt ist. Ein Modell kann eine Lücke in der Spezifikation nicht als Lücke behandeln; es füllt sie mit dem, was in vergleichbaren Texten am wahrscheinlichsten dastand. Das Ergebnis wirkt wie Unzuverlässigkeit des Modells, ist aber die getreue Ausführung einer unvollständigen Angabe.

Der nützliche Perspektivwechsel: Behandle den Prompt wie eine Schnittstellen-Spezifikation — was hineingeht, was herauskommt, welche Constraints gelten, was in Fällen passiert, die keine Normalfälle sind. Anthropic formuliert dieselbe Haltung als Faustregel: Zeige deinen Prompt einer Kollegin mit minimalem Kontext zur Aufgabe und lass sie ihn ausführen — wenn sie ins Stocken kommt, kommt das Modell es auch.

System-Prompt — Die Instruktions-Ebene, die vor dem Gespräch gesetzt wird und für alle Turns gilt — Rolle, Regeln, Format, Grenzen. Technisch ein eigenes Feld (system) neben der Nachrichtenliste, nicht bloß der erste Satz der Nutzereingabe.

Spezifizität: Constraints statt Adjektive

„Schreibe eine gute Zusammenfassung“ ist keine Anforderung, sondern eine Bewertung. Adjektive wie gut, prägnant, professionell oder ausführlich verschieben die Entscheidung nur ins Modell: Es muss raten, was du unter dem Wort verstehst, und es rät bei jedem Aufruf neu. Genau daraus entsteht die typische Beschwerde „mal zwei Sätze, mal eine halbe Seite“.

Ein Adjektiv wird zur Anforderung, sobald du es durch etwas ersetzt, das jemand nachprüfen kann. Für Textausgaben sind das fast immer die gleichen vier Achsen — und es lohnt, sie stumpf abzuarbeiten, statt auf eine gelungene Formulierung zu hoffen:

Achse

Statt Adjektiv: prüfbare Angabe

Umfang

„3 bis 5 Sätze, höchstens 80 Wörter“ statt „prägnant“

Adressat

„für einen Bereitschaftsdienst, der das Ticket nicht kennt“ statt „verständlich“

Pflichtinhalte

„nennt Auslöser, betroffenen Dienst und aktuellen Stand“ statt „vollständig“

Form

„Fließtext ohne Aufzählung, kein Vorspann“ statt „professionell“

Die Anbieter-Doku ergänzt einen Punkt, der oft übersehen wird: Auch Begründungen wirken. Statt der Regel NEVER use ellipses empfiehlt sie „Deine Antwort wird von einer Sprachausgabe vorgelesen, verwende deshalb keine Auslassungspunkte — die Sprachausgabe kann sie nicht aussprechen.“ Die zweite Fassung ist länger und trotzdem wirksamer, weil das Modell aus dem Grund auf verwandte Fälle verallgemeinern kann. Eine Regel ohne Grund gilt genau für den Fall, den sie nennt.

Struktur: die Grenze zwischen Instruktion und Daten

Ein Prompt in Produktion ist fast immer eine Vorlage: fester Instruktionstext plus zur Laufzeit eingesetzte Daten — ein Dokument, ein Ticketverlauf, eine Nutzereingabe. Klebt man beides zu einem Fließtext zusammen, entsteht ein Text, in dem nichts markiert, welcher Satz Auftrag und welcher Satz Material ist. Das Modell sieht nur eine Zeichenfolge.

Deshalb: jeden Bestandteil in ein eigenes, benanntes Feld. Die Anthropic-Doku empfiehlt dafür XML-Tags — <instructions>, <context>, <input> —, weil sie die Zuordnung eindeutig machen und sich verschachteln lassen (<documents> mit je einem <document index="n">). Wichtig ist nicht das Format; wichtig ist, dass die Grenze existiert und dass die Tag-Namen über deine Prompts hinweg gleich bleiben.

Wie stark solche Oberflächen-Entscheidungen wirken, ist besser belegt, als es angenehm ist. Sclar und Kollegen haben systematisch bedeutungserhaltende Formatvarianten durchprobiert — andere Trennzeichen, andere Groß-/Kleinschreibung der Feldnamen, andere Reihenfolge — und bei LLaMA-2-13B eine Spanne von bis zu 76 Genauigkeitspunkten zwischen der besten und der schlechtesten Variante gemessen. Die Empfindlichkeit verschwand nicht mit größeren Modellen, mehr Beispielen oder Instruction-Tuning.

Das Ausgabeformat ist ein Vertrag

Sobald Code die Antwort konsumiert, ist das Ausgabeformat keine Stilfrage mehr, sondern eine Schnittstelle. Der typische Produktionsfehler sieht so aus: Der Prompt bittet um JSON, ein Parser liest es, und in 2 von 100 Fällen kommt ein einleitender Satz davor, ein Codeblock-Zaun darum oder ein zusätzliches Feld dazu. Der Parser bricht, und die Fehlerrate wirkt zufällig.

Eine vollständige Format-Spezifikation hat drei Teile, und alle drei fehlen meistens:

• Benannte Felder mit Typ — nicht „gib JSON zurück“, sondern welche Schlüssel mit welchem Wertebereich, und ob weitere Felder erlaubt sind.
• Ein Beispiel der exakten Form — die Doku empfiehlt, Beispiele in <example>-Tags zu setzen, damit sie nicht als Teil der Instruktion gelesen werden.
• Ein Verhalten für „Wert nicht vorhanden“ — sonst ist die einzige Alternative, die das Modell kennt, eine plausibel aussehende Erfindung.

Und danach: validieren. Eine Formatangabe im Prompt ist eine Bitte, keine Durchsetzung — sie senkt die Fehlerrate, sie garantiert nichts. Wie man von der Bitte zum erzwungenen Schema kommt (Schema-Zwang beim Decoding, Validierung, Repair-Budget), ist Thema des Moduls Strukturierte Ausgabe erzwingen. Hier gilt nur der Grundsatz: spezifizieren und prüfen, nie hoffen.

Beispiele: was Few-shot wirklich überträgt

Beispiele sind der zuverlässigste Hebel für Form, Ton und Struktur — insbesondere dort, wo eine Aufgabe an euren Konventionen hängt, die das Modell nicht kennen kann: eure sechs Ticket-Kategorien, eure Grenze zwischen Zugang und Bug, euer Hausformat. Beschreibungen solcher Konventionen werden lang und bleiben mehrdeutig; drei Beispiele erledigen es. Die Anbieter-Doku nennt 3 bis 5 Beispiele als Richtwert und fordert, sie in <example>-Tags zu setzen.

Der interessante Befund betrifft aber, was dabei eigentlich übertragen wird. Min und Kollegen haben in den Demonstrationen die Labels durch zufällige Labels ersetzt — und die Leistung brach über 12 Modelle hinweg kaum ein. Was den Nutzen trägt, waren drei andere Dinge: der Label-Raum (welche Antworten überhaupt in Frage kommen), die Verteilung der Eingaben (wie die Fälle aussehen) und das Format der Sequenz.

Praktisch verschiebt das die Auswahl der Beispiele. Nicht die vier klarsten Fälle nehmen — die kann das Modell ohnehin —, sondern die Ränder, an denen ihr selbst diskutiert habt: den Login-Fehler, der Zugang und nicht Bug ist; die Löschanfrage, die DSGVO und nicht Abrechnung ist. Die Doku sagt dasselbe als Anforderung an Beispiele: relevant, divers (Grenzfälle abdecken), strukturiert.

Die Reihenfolge der Beispiele ist nicht neutral

Ein Detail, das in Reviews fast nie auffällt: Dieselben Beispiele in anderer Reihenfolge ergeben andere Ergebnisse. Zhao und Kollegen haben drei systematische Schieflagen benannt, die genau daraus entstehen — und alle drei sind Eigenschaften deines Beispielblocks, nicht des Modells im Abstrakten.

Schieflage

Was sie in deinem Prompt anrichtet

Majority-Label-Bias

Kommt ein Label in den Beispielen häufiger vor, wird es häufiger vorhergesagt — deine Beispielverteilung wird zur Vorannahme.

Recency-Bias

Labels am Ende des Beispielblocks werden bevorzugt — die letzten zwei Beispiele wirken stärker als die ersten zwei.

Common-Token-Bias

Antworten, die im Vortraining häufig waren, werden bevorzugt — ein seltener Kategoriename ist strukturell benachteiligt.

Daraus folgen zwei stumpfe, wirksame Regeln. Erstens: die Label-Verteilung im Beispielblock ausbalancieren, statt sie zufällig entstehen zu lassen — sonst baust du eine Vorannahme ein, die du nicht dokumentiert hast. Zweitens: nicht alle Beispiele einer Kategorie ans Ende stellen; die Reihenfolge ist Teil des Prompts und gehört fixiert, nicht dem Zufall der Datei überlassen.

Kontext und Rolle: Register statt Beschwörung

„Du bist ein Weltklasse-Experte für …“ ist der beliebteste Prompt-Baustein ohne benennbare Wirkung. Er enthält keine Information, die das Modell nicht schon hat: Es weiß, wie Fachtexte klingen. Was es nicht wissen kann, ist die Situation — wer liest, mit welchem Vorwissen, zu welchem Zweck, unter welcher Einschränkung.

Ein Doku-Assistent, der erfahrenen Engineers Grundlagen erklärt und Neueinsteigern Kürzel hinwirft, hat kein Wissensproblem, sondern ein Register-Problem: Im Prompt steht nicht, wer fragt. Die Anbieter-Doku empfiehlt entsprechend, Kontext und Motivation der Anweisung mitzugeben.

Trägt nichts

Trägt etwas

„Du bist ein erfahrener SRE.“

„Der Leser hat Bereitschaft, kennt das System, aber nicht diesen Vorfall.“

„Antworte professionell.“

„Die Antwort geht als Kommentar in ein Kundenticket.“

„Sei gründlich.“

„Unklarheiten benennen, statt sie zu überbrücken — es wird danach gehandelt.“

Positiv instruieren: den Zielzustand benennen

System-Prompts wachsen in eine erkennbare Form: eine Liste von Verboten, die nach jedem Vorfall um eins länger wird. „Nicht ausschweifen“, „keine internen Codenamen“, „nicht spekulieren“ — fünfzehn Regeln später ist der Prompt lang, teuer und beschreibt trotzdem nirgends, wie eine gute Antwort aussieht.

Zwei Gründe, warum Verbotslisten schwächer sind, als sie sich anfühlen. Der erste ist sprachlich: Negation ist für Sprachmodelle nachweislich schwierig. Truong und Kollegen fanden über eine Reihe von Negations-Benchmarks eine Unempfindlichkeit gegenüber der Anwesenheit einer Negation und ein Versagen beim Schließen unter Negation. Der zweite ist logischer Natur: Ein Verbot schließt einen Teil des Fehlerraums aus und lässt den Rest offen — es gibt beliebig viele Arten, „nicht ausschweifend“ zu sein, und nur wenige davon willst du.

Die Anbieter-Doku macht daraus eine explizite Regel: Sage dem Modell, was es tun soll, statt was es nicht tun soll. Ihr eigenes Beispiel: statt Do not use markdown in your response besser „Deine Antwort besteht aus flüssig geschriebenen Absätzen.“ Die zweite Fassung ist kein höflicheres Verbot, sondern eine andere Art von Angabe — sie beschreibt einen Zielzustand, den man erkennen kann.

Grenzfälle sind Teil der Spezifikation

Die teuersten Prompt-Lücken sind die, die im Normalfall nicht auffallen. Ein Extraktions-Prompt zieht Vertragsende aus Dokumenten. Bei befristeten Verträgen funktioniert er. Bei unbefristeten steht kein Datum im Dokument — und im Feld erscheint trotzdem eines, plausibel, erfunden, syntaktisch korrekt. Nichts protokolliert einen Fehler, weil kein Fehler auftrat: Das Feld war als „Datum“ spezifiziert, und ein Datum kam.

Das ist der Kern: Ein Modell hat für den unspezifizierten Fall keinen Ausgang. Es kann null nicht wählen, wenn null nicht existiert. Also braucht jede Ausgabe-Spezifikation einen benannten Weg für die Fälle, die keine Normalfälle sind:

• Wert nicht im Dokument — was steht dann im Feld? (null, leerer String, ein Marker — aber benannt.)
• Mehrere Kandidaten — welcher gewinnt, oder ist Mehrdeutigkeit selbst das Ergebnis?
• Widerspruch in der Eingabe — melden oder auflösen, und wenn auflösen: nach welcher Regel?
• Eingabe passt gar nicht zur Aufgabe — eigener Rückgabewert statt bester Versuch.

Beachte, was hier nicht hilft: temperature auf 0 senken. Das macht die Erfindung reproduzierbar, nicht wahr. Nachgelagerte Validierung fängt zwar ein ungültiges Datum, aber ein plausibles erfundenes Datum ist gültig — die Prüfung hat keinen Angriffspunkt. Die Lücke ist in der Spezifikation, und nur dort kann man sie schließen.

Prompting ist empirisch

Alle Hebel dieses Moduls sind Hypothesen. „Beispiele an die Ränder legen“ ist plausibel und meistens richtig; ob es bei euren Daten und eurer Taxonomie hilft, entscheidet die Messung. Zwei Engineers, die je eine Handvoll Chatverläufe als Belege vorlegen, können diesen Streit nicht entscheiden — beide haben aus fünf Fällen die ausgewählt, die ihre Position stützen.

Die Mindestausrüstung ist kleiner, als man denkt: eine feste Menge von Eingabe-Erwartung-Paaren, an derselben Menge gemessen, mit dem Ergebnis notiert. Zwanzig gut gewählte Fälle schlagen zweihundert zufällige. Wichtig ist nur, dass die Menge fix ist — wer sie mit dem Prompt zusammen anpasst, misst nichts mehr.

Auch die Anbieter-Doku setzt das voraus, bevor sie überhaupt Technik nennt: Kriterien für Erfolg und ein Weg, empirisch dagegen zu testen, kommen vor dem Prompt-Tuning. Wie so eine Menge zusammengestellt wird, welche Assertions tragen, wie man Rauschen von Signal trennt und was ein Gate taugt, ist Thema des Moduls Eval-Sets und Regressionstests.

Was diese Grundlagen nicht lösen

Die Hebel dieses Moduls machen einen Prompt spezifisch, strukturiert und prüfbar. Drei Dinge leisten sie ausdrücklich nicht — besser hier als im Betrieb gelernt.

Erwartung

Tatsächliche Grenze

Delimiter schützen vor Prompt Injection

Sie markieren die Grenze, sie erzwingen sie nicht. Ein Modell kann eine Anweisung aus dem Datenblock befolgen. Abwehr ist Systemdesign, nicht Formulierung — Modul Injection-Abwehr.

Eine Formatangabe garantiert das Format

Sie verschiebt Wahrscheinlichkeit. Garantien kommen aus Schema-Zwang und Validierung — Modul Strukturierte Ausgabe.

Mehr Kontext ist mehr Verständnis

Kontext ist knappe, ungleich wirksame Fläche mit Positionseffekten — Modul Kontext als Budget.

Zusammenfassung — gleich im Check

Du kennst jetzt die acht Achsen eines belastbaren Prompts: Spezifizität statt Adjektive, Struktur mit markierter Grenze zwischen Instruktion und Daten, das Ausgabeformat als Vertrag, Beispiele an den Rändern statt in der Mitte, die nicht neutrale Reihenfolge dieser Beispiele, Kontext statt Rollen-Beschwörung, positive Instruktion statt wachsender Verbotsliste und einen benannten Ausgang für jeden Grenzfall — geprüft an einer fixen Fallmenge.