Mehr Handwerk als Geheimtrick
Rund um Prompt Engineering kursieren viele „Zauberformeln“. Die meisten bewährten Regeln sind aber unspektakulär und gleichen dem, was ein gutes Briefing für Menschen ausmacht: klar sagen, was gebraucht wird, wofür, in welcher Form – und was nicht passieren darf.
Der Unterschied zum einfachen Prompt liegt in der Systematik. Beim Prompt Engineering wird eine Anweisung nicht einmal geschrieben und benutzt, sondern an vielen echten Eingaben ausprobiert, an den Fehlern verbessert und wieder geprüft. Das lohnt sich vor allem dort, wo derselbe Prompt hundertfach läuft – etwa in einem Tool, das jedes Meeting nach demselben Schema zusammenfasst.
Bewährte Techniken
Diese Techniken tauchen in den Anleitungen der großen Modellanbieter immer wieder auf:
- Klar und direkt sein: Aufgabe, Zielgruppe und Zweck nennen, statt das Modell raten zu lassen
- Beispiele geben: ein oder zwei Muster des gewünschten Ergebnisses zeigen – oft wirksamer als jede Beschreibung
- Material abgrenzen: Anweisungen und eingefügten Text deutlich trennen, etwa mit Überschriften wie „Transkript:“
- Format vorgeben: Gliederung, Länge, Tabelle oder Stichpunkte
- Schritt für Schritt arbeiten lassen: bei kniffligen Aufgaben erst analysieren, dann antworten
- Unsicherheit erlauben: ausdrücklich sagen, dass „steht nicht im Text“ eine gültige Antwort ist
- Aufgaben aufteilen: komplexe Abläufe in mehrere Prompts nacheinander zerlegen (Prompt-Ketten)
Zero-Shot, Few-Shot und Chain of Thought
Drei Fachbegriffe begegnen dir beim Thema immer wieder:
| Begriff | Bedeutung | Wann sinnvoll |
|---|---|---|
| Zero-Shot | nur Anweisung, kein Beispiel | einfache, eindeutige Aufgaben |
| Few-Shot | Anweisung plus einige Beispiele für Eingabe und gewünschte Ausgabe | festes Format, eigener Stil, Klassifizierungen |
| Chain of Thought | das Modell schreibt Zwischenschritte auf, bevor es antwortet | Rechnen, Abwägen, mehrstufige Analysen |
Viele aktuelle Modelle können von sich aus länger „nachdenken“, bevor sie antworten. Die Grundidee bleibt dieselbe: Zwischenschritte machen Fehler seltener und leichter erkennbar.
Testen statt raten
Professionelles Prompt Engineering beginnt mit einer Sammlung echter Testfälle: zehn, zwanzig typische Eingaben, darunter auch schwierige – ein Meeting ohne Entscheidungen, ein Transkript mit viel Durcheinanderreden. Jede neue Prompt-Version läuft gegen alle Fälle, und man vergleicht die Ergebnisse.
Wichtig ist, gezielt auf Fehler zu schauen statt auf den gelungenen Durchschnitt. Ein Prompt, der neunmal gut und einmal mit erfundener Frist antwortet, ist für ein Protokoll nicht gut genug. Und weil sich Modelle mit jedem Update leicht verändern, gehört der Test nach einem Modellwechsel wieder dazu.
Prompt Engineering, Fine-Tuning und RAG
Prompt Engineering ist der günstigste und schnellste Hebel, weil es am Modell nichts ändert. Fine-Tuning trainiert das Modell selbst nach und lohnt sich erst, wenn Prompts an ihre Grenzen stoßen. Retrieval-Augmented Generation löst ein anderes Problem: Es liefert dem Modell Wissen, das es nicht hat. In der Praxis werden die drei oft kombiniert.
Eine einfache Reihenfolge hat sich bewährt: zuerst den Prompt verbessern und testen. Fehlt dem Modell Wissen, eine Quelle per RAG anbinden. Erst wenn beides nicht reicht und dieselbe Aufgabe in großer Menge anfällt, über Fine-Tuning nachdenken.
Version 1: „Fasse das Meeting zusammen und liste die Aufgaben.“ – Ergebnis: ordentlich, aber bei zwei Aufgaben stehen Fristen, die niemand genannt hat.
Version 2: ergänzt um „Nur Informationen aus dem Transkript. Fehlt eine Frist, schreib ‚ohne Frist‘.“ – Die erfundenen Fristen verschwinden, dafür landen Diskussionspunkte als Aufgaben in der Liste.
Version 3: ergänzt um ein kurzes Beispiel, was als Aufgabe zählt und was nicht. Nach dem Test mit fünfzehn echten Transkripten bleibt das Team bei dieser Fassung.
Dieser Eintrag dient der allgemeinen Information und ersetzt keine individuelle Beratung.