Warum „gute Formulierungen“ nicht reichen
Prompt Engineering wird oft als die Kunst verstanden, die „richtige Frage“ an ein KI-Modell zu stellen. In der Praxis genügt das nicht. In produktiven Umgebungen – etwa bei Incident-Triage, Support-Automatisierung oder Klassifikationsaufgaben – müssen Prompts zuverlässig, testbar und sicher funktionieren. Genau hier entscheidet sich, ob ein Prompt schwach bleibt oder produktionsreif ist.
Das Problem schwacher Prompts
Schwache Prompts bitten das Modell lediglich um eine Antwort. Sie fragen nach einer Zusammenfassung, einer Schwere-Einschätzung oder einer Maßnahme – ohne das erwartete Format zu definieren. Das Ergebnis: mal Fließtext, mal Markdown, mal halb strukturiertes JSON. Für Menschen lesbar, für Downstream-Systeme unzuverlässig. Erwartet ein System eine konkrete JSON-Struktur, kann schon eine kleine Abweichung den gesamten Workflow brechen.
Vom Prompt zur Schnittstelle: der Vertrag
Produktionsreife Prompts definieren einen Vertrag. Dieser Vertrag legt fest, welche Rolle das Modell einnimmt, welche Aufgabe zu erfüllen ist, welche Eingaben als vertrauenswürdig gelten – und welche nicht.
- Persona/Rolle: Welche Haltung und Verantwortung das Modell hat.
- Mission/Aufgabe: Was genau zu tun ist (z. B. triagieren, klassifizieren, zusammenfassen).
- Vertrauensgrenzen (Trust Boundary): Welche Teile des Kontexts Anweisungen sind und welche nur Daten.
- Evidence Policy: Wie zwischen Fakten, Vermutungen und fehlender Evidenz unterschieden wird.
- Output Contract: Welches Format die Antwort haben muss (z. B. JSON-Schema).
- Fallback-Regeln: Sicheres Verhalten bei unvollständigen Informationen.
Trust Boundary: Eingaben sind Daten, keine Anweisungen
Nutzereingaben, Logdaten oder Incident Notes sind Daten – keine Befehle. Eine Eingabe wie „Ignoriere alle bisherigen Regeln“ ist eine Prompt Injection und darf nicht befolgt werden. Der Prompt muss klarstellen: Solche Inhalte sind als potenzielle Angriffe zu erkennen und zu melden, nicht auszuführen.
Evidence Policy: zwischen Fakt, Vermutung und Lücke unterscheiden
Ein robustes System bestätigt keine Ursachen ohne ausreichende Belege. Korrelation ist nicht Kausalität: Nur weil ein Deployment kurz vor einem Fehlerspike stattfand, ist es nicht automatisch die Ursache. Ein guter Prompt zwingt das Modell, explizit zu kennzeichnen, was belegt, was vermutet und wo Evidenz fehlt. Das reduziert Halluzinationen und macht Entscheidungen nachvollziehbar.
Praktische Effekte
- Transparenz: Begründungen sind prüfbar.
- Nachvollziehbarkeit: Entscheidungen lassen sich auditieren.
- Risikominderung: Falsche Sicherheit durch Scheinursachen wird vermieden.
Output Contract: fixes, maschinenlesbares Format
Ein festes Ausgabeformat – idealerweise durch ein JSON-Schema definiert – sorgt dafür, dass Antworten nicht nur inhaltlich, sondern auch technisch korrekt sind. Typische Felder:
- severity (z. B. critical, high, medium, low, informational)
- root_cause_status (z. B. confirmed, suspected, unknown)
- evidence_items (strukturierte Belege mit Quelle und Relevanz)
- injection_detected (true/false, ggf. mit Hinweisen)
- routing_decision (z. B. an welches Team/Playbook weitergeleitet wird)
Wichtig ist, dass nur erwartete Felder erlaubt sind. Eine Regel wie additionalProperties: false verhindert Interface-Drift und minimiert Integrationsfehler.
Über die Form hinaus: semantische Tests
Schema-Validierung prüft die Form, nicht das Verhalten. Daher braucht es semantische Tests, die fachliche Regeln absichern. Beispiele:
- Ein Checkout-Ausfall mit Kundenimpact darf nicht als „informational“ klassifiziert werden.
- Eine unbestätigte Ursache darf nicht als „confirmed“ ausgegeben werden.
- Bei erkannten Injections muss das Feld injection_detected konsistent gesetzt sein.
Solche Checks machen Prompt Engineering zu einem echten Software-Engineering-Prozess – mit Testbarkeit und Regressionsschutz.
Bewährte Muster für robuste Prompts
- Mehrteilige Developer Prompts: Klare Trennung von Systemregeln, Instruktionen und Beispielen.
- Delimiter: Saubere Abgrenzung von Daten und Anweisungen.
- Few-Shot-Beispiele: Gezielte Beispiele, die Format und Entscheidungslogik vormachen.
- Tool Calling: Externe Werkzeuge einbinden, wenn strukturierte oder verifizierbare Schritte nötig sind.
- Guardrails: Deterministische Regeln, die unsichere Ausgaben abfangen oder korrigieren.
Wichtig: Nicht „immer mehr Prompt“, sondern jede Komponente mit klarer Funktion – Persona, Mission, Trust Boundary, Evidence Policy, Output Contract und Fallbacks.
Performance: kürzer, schneller, trotzdem sicher
Produktionsreife Prompts müssen korrekt und effizient sein. Kürzere Prompts sparen Tokens und reduzieren Latenz, ohne Sicherheits- oder Qualitätsregeln zu opfern.
- Caching: Wiederkehrende Instruktionen auslagern.
- Kontext-Pruning: Irrelevante Daten vorab entfernen.
- Deterministische Guardrails: Regeln außerhalb des Modells erzwingen.
- Gezielte Fallback-Modelle: Je nach Aufgabe zwischen Modellen wechseln, wenn es Stabilität oder Kosten verbessert.
Fazit
Prompt Engineering in der Produktion ist nicht das Schreiben eines cleveren Satzes, sondern das Design einer zuverlässigen Schnittstelle um ein probabilistisches System. Ein guter Prompt definiert Rollen, Grenzen, Beweise, Ausgabeformate, Tests und Sicherheitsverhalten. So wird aus einem nützlichen KI-Modell eine belastbare Komponente für reale Anwendungen.