Prompt Engineering für die Produktion: was funktioniert und was ist Mythos

Als wir zum ersten Mal ein LLM in einer Produktionsumgebung bei einem Fertigungskunden eingesetzt haben, brauchten wir drei Wochen, um zu verstehen, warum das Modell gelegentlich auf Englisch statt auf Deutsch antwortet, warum es die Formatierung ignoriert und warum es in einem von zehn Fällen eine Zahl frei erfindet. Alle drei Probleme hatten dieselbe Lösung: einen systematischen Ansatz für Prompts — nicht Intuition, nicht Trial-and-Error, sondern eine erprobte Struktur.

Prompt Engineering gehört heute zu den meistgenannten, aber auch am wenigsten richtig verstandenen Disziplinen in KI-Projekten. Wenn wir technische Direktoren fragen, was sie davon erwarten, sagen die meisten „bessere Antworten". Das stimmt — aber nur bis zu einem gewissen Grad. Dieser Artikel schlüsselt auf, was Prompt Engineering realistisch leisten kann, wo seine Grenzen liegen und was in ein anderes Werkzeugfeld gehört.

Was Prompt Engineering wirklich ist

Prompt Engineering ist das systematische Entwerfen und Versionieren von Eingaben für ein Sprachmodell mit dem Ziel, konsistente, vorhersagbare und messbare Ausgaben zu erzielen. Das Schlüsselwort ist konsistent — nicht „gelegentlich hervorragend".

In einem Produktionssystem reicht es nicht, dass ein Prompt in 80 % der Fälle funktioniert. Wenn Sie ihn im Kundensupport einsetzen, werden sich Kunden an die 20 % Fehler erinnern. Wenn Sie ihn in der Rechnungsverarbeitung einsetzen, sind 20 % Fehler eine Katastrophe. Prompt Engineering ist daher weniger Kreativarbeit und mehr Ingenieursdisziplin: Dokumentation, Versionierung, Testen, Messen.

Was funktioniert — erprobte Muster

1. Klare Anweisung mit explizitem Ausgabeformat

Den größten Einzeleinfluss auf die Ausgabequalität hat die Präzision, mit der das Modell weiß, was es produzieren soll. Eine vage Anweisung „fasse dieses Dokument zusammen" liefert vage Ergebnisse. Eine spezifische Anweisung funktioniert dramatisch besser:

• Teilen Sie dem Modell mit, wer die Zielgruppe der Ausgabe ist
• Definieren Sie das genaue Format: Anzahl der Aufzählungspunkte, maximale Länge, ob die Ausgabe eine Schlussfolgerung enthalten soll oder nicht
• Verwenden Sie bei strukturierten Daten stets Structured Outputs und JSON-Mode — ein auf ein Schema gebundenes Modell halluziniert deutlich weniger als eines mit freier Textausgabe

Wir haben bei Kunden gesehen, dass allein der Wechsel von „extrahiere Daten aus der Rechnung" zu „gib ein JSON-Objekt mit den Feldern zurück: Lieferant (string), USt-IdNr. (string, 9 Zeichen), Betrag (Zahl), Datum (ISO 8601)" die Fehlerrate der Extraktion um eine Größenordnung von Dutzenden Prozentpunkten gesenkt hat.

2. Few-Shot-Beispiele — wann und wie man sie einsetzt

Few-Shot-Prompting (einige Eingabe-Ausgabe-Beispiele direkt im Prompt) ist eines der zuverlässigsten Werkzeuge — aber nur dann, wenn die Beispiele repräsentativ sind. Die Regeln:

1. 1.Beispiele müssen Edge Cases abdecken, nicht nur den Happy Path
2. 2.Das Format der Beispiele muss konsistent sein — wenn Sie einmal „Eingabe:" und ein anderes Mal „Input:" verwenden, merkt das Modell das
3. 3.Die Anzahl der Beispiele hängt von der Komplexität der Aufgabe ab — für eine einfache Klassifikation reichen 2–3, für mehrstufiges Schlussfolgern 5–7
4. 4.Wählen Sie Beispiele aus realen Daten, nicht aus erfundenen — synthetische Beispiele haben oft andere statistische Eigenschaften als Produktions-Eingaben

Few-Shot ist besonders stark bei der Formatierung und bei Aufgaben mit einer klaren Musterstruktur. Es ist weniger effektiv bei Wissen, bei dem dem Modell der Domänenkontext fehlt — dort ist die Antwort RAG oder Fine-Tuning.

3. Rolle und Persona

Das explizite Zuweisen einer Rolle funktioniert — nicht weil das Modell „glaubt", jemand anderes zu sein, sondern weil die Rolle die Wahrscheinlichkeitsverteilung der Ausgaben hin zu relevanteren Mustern verschiebt. „Sie sind ein Senior-Jurist, spezialisiert auf deutsches Arbeitsrecht" aktiviert andere sprachliche Muster als „Sie sind ein Assistent".

Wichtig: Eine Rolle definiert Ton und Wortschatz, ersetzt aber kein Wissen. Ein Modell mit der Rolle „Experte für ATEX-Richtlinien" kann trotzdem halluzinieren, wenn es über ATEX-Richtlinien keine ausreichenden Trainingsdaten hat. Eine Rolle ist ein sprachlicher Filter, keine Wissensdatenbank.

4. Schrittverkettung (Chain-of-Thought)

Bei komplexen analytischen Aufgaben — Vergleiche, mehrstufige Berechnungen, Entscheidungen nach Bedingungen — verbessert die explizite Anweisung „geh Schritt für Schritt vor" oder die Aufteilung in mehrere Teilprompts die Zuverlässigkeit erheblich. Modelle machen weniger Fehler, wenn sie vor der abschließenden Antwort „laut denken" können.

In der Praxis bedeutet das: Fordern Sie vom Modell keine direkte Schlussfolgerung. Lassen Sie es zunächst das Problem aufschlüsseln, die relevanten Faktoren identifizieren und erst dann eine Schlussfolgerung formulieren. Das Ergebnis ist zuverlässiger und zudem leichter überprüfbar — Sie sehen, wie das Modell zur Schlussfolgerung gelangt ist.

5. Negative Anweisungen — was nicht zu tun ist

Die meisten Prompts sagen dem Modell, was es tun soll. Genauso wichtig ist es zu sagen, was es nicht tun soll. „Beginne eine Antwort niemals mit der Phrase ‚Natürlich!'", „Verwende keine englischen Wörter, wenn ein deutsches Äquivalent existiert", „Wenn du eine Frage aus dem bereitgestellten Kontext nicht beantworten kannst, sage es explizit — reim dir nichts dazu." Negative Anweisungen reduzieren das Auftreten konkreter, wiederkehrender Fehler.

Was nicht funktioniert — Mythen

Mythos 1: „Bitte" und Belohnungen verbessern die Ergebnisse

Kurze Antwort: nein. Aufforderungen wie „für jede richtige Antwort bekommst du 100 Dollar" oder das höfliche „bitte hilf mir mit..." haben keinen messbaren Effekt auf die Qualität der Produktionsausgabe. Das Modell reagiert nicht auf soziale Manipulation oder Emotionen — es reagiert auf statistische Muster in den Trainingsdaten. Zeit, die mit dem „Motivieren" des Modells verbracht wird, ist verlorene Zeit.

Mythos 2: Längerer Prompt = besseres Ergebnis

Länge und Qualität sind zwei verschiedene Dinge. Wir haben System-Prompts mit Tausenden von Tokens gesehen, die schlechter funktioniert haben als fünfzeilige. Das Problem ist, dass Modelle dazu neigen, Anweisungen mitten in einem sehr langen Kontext zu „verlieren" — ein Effekt, der als „lost in the middle" bekannt ist. Struktur und Klarheit sind wichtiger als Volumen. Wenn Ihr Prompt wächst, ist das eher ein Zeichen dafür, dass Sie versuchen, mit dem Prompt ein Problem zu lösen, das ins Systemdesign gehört.

Mythos 3: Ein guter Prompt ersetzt ein Eval

Dies ist wahrscheinlich der gefährlichste Mythos. Ein Prompt ohne Evaluation ist eine Hypothese, keine Lösung. In der Praxis sehen wir Teams, die eine Woche damit verbringen, einen Prompt zu optimieren, ihn in die Produktion bringen und einen Monat später feststellen, dass 15 % der Ausgaben falsch sind — weil sie nie systematisch gemessen haben.

Eval — automatisierte Bewertung der Ausgaben auf einem Test-Set — ist eine Voraussetzung für die Produktionsfreigabe, kein optionales Extra. Mehr dazu, wie man die Qualität einer LLM-Anwendung misst.

Mythos 4: Prompt Engineering ist eine dauerhafte Lösung

Ein Prompt ist ein fragiles Artefakt. Wenn ein Anbieter eine neue Modellversion veröffentlicht, kann sich Ihr Prompt anders verhalten — auch wenn Sie ihn nicht geändert haben. Wir haben Fälle erlebt, in denen ein Modell-Update die allgemeine Qualität verbessert hat, aber spezifische Formatierungsanweisungen kaputt gemacht hat, die auf das Verhalten der älteren Version „aufgesetzt" waren.

Prompt Engineering ist iterative, keine einmalige Arbeit. Wenn Sie sich dessen vor dem Deployment nicht bewusst sind, werden Sie es danach sein.

Mythos 5: Der System-Prompt ist ein sicherer Container für sensible Informationen

Der System-Prompt ist für das Modell eine Anweisung, kein Safe. Prompt Extraction (das Extrahieren des Inhalts eines System-Prompts) ist ein gut dokumentierter Angriff — es gibt Techniken, mit denen ein Angreifer den Inhalt des System-Prompts über eine normale Benutzeroberfläche aus dem Modell herausziehen kann. In den System-Prompt gehören niemals: Passwörter, API-Schlüssel, interne Preislisten, persönliche Mitarbeiterdaten oder irgendwelche Informationen, deren Offenlegung ein Problem wäre. In den System-Prompt gehören Verhaltensanweisungen, keine Geheimnisse.

Prompt als Code — Versionierung und Verwaltung

In Teams, mit denen wir arbeiten, taucht immer wieder dasselbe Problem auf: Der Prompt ist im Code als hartcodierter String gespeichert, niemand weiß, wer ihn zuletzt geändert hat und warum, und wenn etwas schiefläuft, gibt es keine Historie, zu der man zurückkehren könnte.

Ein Prompt ist Code. Es gelten dieselben Prinzipien:

• Versionierung in git — jede Prompt-Änderung ist ein Commit mit einer aussagekräftigen Commit-Message
• Semantic Versioning — Major-Version bei einer Änderung, die das Ausgabeverhalten ändert; Minor bei einer Ergänzung; Patch bei einer Rechtschreibkorrektur
• Test-Set — zu jeder Prompt-Version existiert ein Set von Testfällen mit erwarteten Ausgaben; eine Prompt-Änderung ist bestanden, nur wenn die Tests grün sind
• Prompt-Register — ein zentraler Ort (kann ein einfaches YAML im Repo sein, oder ein Tool wie Langfuse), der zeigt, welcher Prompt wo eingesetzt ist, in welcher Version und wer der Eigentümer ist

Tools wie Promptfoo ermöglichen das automatische Testen von Prompts in einer CI/CD-Pipeline — jeder Pull Request mit einer Prompt-Änderung startet automatisch das Test-Set vor dem Merge. Dies ist eine Praxis, die wir jedem Team empfehlen, das mehr als einen aktiven Prompt in der Produktion hat.

Wann ein Prompt nicht ausreicht — und was stattdessen

Prompt Engineering ist ein starkes Werkzeug in einem engen Band von Problemen. Es ist schwach, wenn:

Wissen fehlt — das Modell weiß nicht, was es wissen müsste, weil es nicht in den Trainingsdaten vorhanden ist. Ein Prompt kann kein Wissen hinzufügen. Lösung: RAG (Retrieval-Augmented Generation) für faktische Unterstützung oder Fine-Tuning für eine tiefe Domänenadaptation.

Ein konsistentes Format fehlt — die Ausgabe soll sich stets an ein genaues Schema halten. Ein Prompt kann helfen, aber die zuverlässigere Lösung sind Structured Outputs (JSON-Schema, an das Modell gebunden). Mehr im Artikel über Structured Outputs und JSON-Mode.

Sicherheit fehlt — wenn das System nicht vertrauenswürdige Eingaben verarbeitet (z. B. Kundennachrichten, externe Dokumente), ist Prompt Injection ein reales Risiko. Ein Prompt kann sein eigenes Überschreiben nicht verhindern. Sie brauchen architektonische Guardrails — Eingabevalidierung, Aktion-Allowlists, Sandboxing. Detaillierter im Artikel über Prompt Injection und Jailbreaks.

Messung fehlt — wenn Sie nicht wissen, ob ein Prompt funktioniert, ist Prompt Engineering nur Raten. Ohne Eval sollten Sie auch einem hervorragenden Prompt nicht vertrauen.

Praktische Prompt-Versionierung — wie man anfängt

Für Teams, die noch keine systematische Prompt-Verwaltung haben, empfehlen wir ein einfaches Vorgehen:

1. 1.Erstellen Sie ein Verzeichnis prompts/ im Repository mit einer YAML-Datei pro Prompt
2. 2.Jedes YAML enthält: name, version, description, system_prompt, user_prompt_template, model, temperature, test_cases
3. 3.Änderungen über Pull Requests — Prompt-Review genauso wie Code-Review
4. 4.Vor dem Deployment einer neuen Version: Führen Sie das Test-Set auf der aktuellen und der neuen Version aus, vergleichen Sie die Metriken
5. 5.Nach dem Deployment: Überwachen Sie die Ergebnisse in der Produktion; Anomalien (plötzlicher Anstieg der Fehlerrate, geänderte Ausgabelänge) sind ein Zeichen für eine Regression

Das ist kein Overkill — das ist das Minimum. Teams, die das nicht tun, entdecken Probleme in der Produktion statt im Testing.

Prompt Engineering und Modelle — was sich mit dem Modell ändert

Ein wichtiger Punkt, den wir häufig ignoriert sehen: Verschiedene Modelle reagieren auf denselben Prompt unterschiedlich. Ein für ein Modell optimierter Prompt kann auf einem anderen deutlich schlechter funktionieren. Einige konkrete Muster:

• Instruction Following: Neuere Frontier-Modelle (Claude, GPT-4-Klasse) sind deutlich besser im Einhalten expliziter Anweisungen als ältere oder kleinere Modelle
• Few-Shot-Sensitivität: Manche Modelle reagieren stark auf Few-Shot-Beispiele, andere weniger — das hängt von der Größe und dem Trainingsverfahren ab
• Sprachqualität: Deutsch ist eine gut versorgte Sprache; Frontier-Modelle beherrschen es gut, kleinere Open-Weight-Modelle können degradieren — testen Sie immer in der Zielsprache
• Temperature: Bei deterministischen Aufgaben (Extraktion, Klassifikation) setzen Sie temperature=0 oder sehr niedrig — die Ausgaben werden konsistenter; bei generativen Aufgaben (Schreiben) etwas höher

Wenn Sie das Modell wechseln, führen Sie immer das vorhandene Test-Set aus. Gehen Sie nicht davon aus, dass der Prompt „genauso funktioniert".

Häufige Fragen

Lohnt es sich, Zeit in Prompt Engineering zu investieren, oder ist es besser, direkt zu fine-tunen?

Prompt Engineering ist der erste Schritt, Fine-Tuning der nächste — keine Alternative. Wenn Sie einen gut gestalteten Prompt haben und trotz Few-Shot-Beispielen und Struktur mit den Ergebnissen noch nicht zufrieden sind, untersuchen Sie, ob das Problem nicht an fehlendem Domänenwissen liegt (Lösung: RAG) oder an der Konsistenz des Ausgabestils (Lösung: Fine-Tuning). Fine-Tuning ohne einen gut gestalteten Prompt und ohne Eval ist verschwendete Zeit und verschwendetes Geld.

Kann ich Prompt Engineering nutzen, um sicherzustellen, dass das Modell niemals auf bestimmte Themen antwortet?

Nicht zuverlässig. Prompt-Only-Abwehrmechanismen (Anweisung „antworte niemals auf X") sind überwindbar — das ist die Haupterkenntnis der Forschung zu Prompt Injection und Jailbreaking. Für Produktionssysteme sind architektonische Maßnahmen unerlässlich: Filterung der Eingaben vor der Übergabe an das Modell, Validierung der Ausgaben vor der Anzeige, Monitoring. Eine Anweisung im Prompt ist die erste Schicht, nicht die einzige.

Woran erkenne ich, dass mein Prompt gut ist?

Nur durch Messung. Definieren Sie ein Test-Set von Fällen (mindestens 20–50 für eine einfache Aufgabe, mehr für komplexe) mit erwarteten Ausgaben oder Bewertungskriterien. Führen Sie den Prompt auf dem Test-Set aus und messen Sie die relevante Metrik (Genauigkeit, Formatierung, sprachliche Korrektheit, Faktentreue). Ohne Zahl ist ein „guter Prompt" nur ein Gefühl.

Wie viele Tokens sollte ein System-Prompt haben?

Es gibt keine universelle Antwort, aber in der Praxis sehen wir, dass effektive System-Prompts typischerweise im Bereich von 200–800 Tokens liegen. Kürzere sind zu wenig spezifisch, längere beginnen unter dem „lost in the middle"-Effekt zu leiden — das Modell verliert den Überblick über Anweisungen, die in der Mitte gespeichert sind. Wenn Ihr Prompt tausend Tokens überschreitet, ohne klaren Grund, ist es Zeit, ihn zu refaktorieren oder darüber nachzudenken, ob einige Informationen nicht in den RAG-Kontext statt in den System-Prompt gehören.

Gilt dasselbe für lokal eingesetzte Open-Weight-Modelle?

Die meisten Prinzipien gelten, aber mit einem wichtigen Vorbehalt: Kleinere Open-Weight-Modelle (7B–13B Parameter) sind weniger robust beim Einhalten von Anweisungen als Frontier-Modelle. Few-Shot-Beispiele sind wichtiger, die Prompt-Formatierung muss präziser sein und das Test-Set muss auf die spezifische Modellfamilie zugeschnitten sein. Ein für Frontier-Modelle entworfener Prompt muss auf Mistral 7B oder ähnlich großen Open-Weight-Modellen nicht genauso funktionieren — und das auch nicht nach sorgfältiger Optimierung. Deutsch stellt für kleinere Modelle im Vergleich zu Englisch zudem eine zusätzliche Herausforderung dar — testen Sie immer in der Produktionssprache.

*Prompt Engineering ist ein Handwerk, keine Magie — und wie jedes Handwerk lässt es sich erlernen, systematisieren und messen. Wenn Sie mit dem Einsatz eines LLM in der Produktion befasst sind und nicht sicher sind, wo Sie anfangen sollen, beurteilen wir gerne Ihren konkreten Fall und helfen Ihnen dabei, die Grundlagen zu schaffen, auf denen sich aufbauen lässt.*