Prompt Engineering als Systemdisziplin

Ein Prompt definiert Rolle, Aufgabe, Einschränkungen, verfügbare Daten und das erwartete Ausgabeformat des Modells. Er garantiert keine Wahrheit und ersetzt keine Validierung. Zuverlässigkeit entsteht, wenn Anweisungen mit Retrieval, Schemata, Tests und kontrollierten Tools zusammenspielen.

Ein fragiler Prompt versucht, jeden möglichen Fehler mit mehr Text vorwegzunehmen. Ein systematischer Ansatz beseitigt zuerst Mehrdeutigkeiten im Vertrag, trennt Anweisungen von Daten und ergänzt anschließend nur Regeln, die durch Tests begründet sind.

Kritische Regeln sollten kurz, eindeutig und auf der höchsten verfügbaren Anweisungsebene platziert sein. Nutzerdaten, RAG-Dokumente und Tool-Ergebnisse werden als nicht vertrauenswürdige Eingaben behandelt und nicht als Fortsetzung der Systemrichtlinie.

Eine praktische Struktur enthält Ziel, Kontext, Einschränkungen, Ausgabeformat, Erfolgskriterien und Verhalten bei unzureichenden Daten. Jeder Block sollte genau eine Funktion haben; vermischte Anforderungen sind schwerer zu testen und zu versionieren.

• Ziel und Grenzen der Aufgabe;
• verfügbare Fakten und ihre Herkunft;
• verbotene Aktionen;
• Ausgabeformat;
• Kriterien für Ablehnung oder Eskalation.

Few-shot-Beispiele helfen, wenn Format oder Stil nur schwer durch Regeln beschrieben werden können. Beispiele sollten nicht nur den Erfolgsfall abdecken, sondern auch Ablehnung, unbekannte Zustände, Quellenkonflikte und Grenzwerte.

Komplexe Aufgaben sollten in Schritte wie Faktenextraktion, Prüfung, Klassifikation und Antwortbildung zerlegt werden. Dadurch sinkt die Zahl versteckter Entscheidungen in einem einzelnen Aufruf und Fehler lassen sich leichter diagnostizieren.

Ein Prompt sollte auf einem stabilen Evaluation Set mit realen, negativen und adversarial Beispielen getestet werden. Gemessen werden erfüllte Kriterien, Formatfehler, unbelegte Aussagen und Kosten statt des Eindrucks aus wenigen Antworten.

Die Prompt-Version wird zusammen mit Modellversion, Ausgabeschema und Metriken gespeichert. Schon die Änderung eines Satzes kann die gesamte Pipeline beeinflussen; Prompt-Regressions sollten daher wie Code-Regressions behandelt werden.

Fehlen dem Modell notwendige Fakten, muss Retrieval verbessert werden. Bricht das Ergebnis einen Parser, sind Structured Outputs nötig. Führt ein Agent unnötige Aktionen aus, müssen Tools und Policy Layer enger begrenzt werden. Ein weiterer Absatz im System Prompt repariert selten einen Architekturfehler.

Der beste Prompt wird oft kürzer, sobald das System Daten, Anweisungen, Tools und Prüfungen sauber trennt.

Prompt Engineering in Production bedeutet, Anweisungen wie Code zu verwalten. Ein Prompt hat einen Owner, eine Version, ein Testset, ein erwartetes Format und Rollback-Kriterien. Textänderungen ohne Evaluation erzeugen versteckte Regressionen: Eine Verbesserung in einem Szenario kann ein anderes verschlechtern, und ein Modellwechsel kann das Verhalten einer alten Anweisung vollständig verändern.

Ein System Prompt sollte nur stabile Regeln enthalten. Dynamischer Kontext, Nutzerdaten und Retrieval-Ergebnisse werden separat übergeben und als nicht vertrauenswürdig markiert. Bei komplexen Aufgaben ist es robuster, den Workflow in mehrere überprüfbare Schritte zu zerlegen, als Dutzende widersprüchliche Anforderungen in einem Mega-Prompt zu sammeln.

• Prompt Templates in der Versionskontrolle speichern.
• Vor Änderungen an einem Production Prompt Regression Evals ausführen.
• Anweisungen von nicht vertrauenswürdigen Daten trennen.

Ein Production Prompt braucht einen klaren Vertrag: Zweck, erlaubte Eingaben, erwartetes Ausgabeschema, Tool-Fähigkeiten, Sicherheitsgrenzen und Fallback-Verhalten. System Instructions, Task Templates, Beispiele und Retrieved Context sollten getrennt versioniert werden, damit eine Änderung in einer Schicht keine andere verdeckt. Prompts werden deterministisch aus typisierten Variablen aufgebaut; User Input und Retrieved Documents werden als nicht vertrauenswürdige Daten markiert statt ohne Grenzen angehängt. Bei strukturierten Antworten gehören Schema Validation und Retry Strategy ebenso zum Vertrag wie der Anweisungstext.

Jede Änderung sollte Offline Regression, Shadow Evaluation und einen begrenzten Rollout durchlaufen. Ein Diff der Prompt-Datei reicht nicht: Ergebnisse auf einem Kontroll-Dataset, Auswirkungen auf Token Usage und Latency, Refusal Rate sowie Critical Failures müssen erhalten bleiben. Few-shot-Beispiele werden nach Coverage statt nach Eleganz ausgewählt; sie dürfen keine Secrets, personenbezogenen Daten oder versehentlich einen Answer Key enthalten. Prompt Ownership, Review und Deprecation müssen formalisiert sein, sonst driften Dutzende fast identischer Templates schnell zwischen Services auseinander.

• Prompt ID und Version in jedem Trace speichern.
• Runtime-Variablen vor dem Zusammensetzen der Nachrichten validieren.
• Instruction Conflicts und indirekte Prompt Injection testen.
• Einen schnellen Rollback auf eine stabile Version vorsehen.