Prompt Engineering & KI-Automatisierung

Ein schlecht konstruierter Prompt liefert unbrauchbare, unstrukturierte Antworten. Ein präzise ausgearbeitetes Prompt-System liefert maschinenlesbare, reproduzierbare Ausgaben, die direkt in automatisierte Workflows eingespeist werden können. Prompt Engineering ist der Schlüssel, der KI-Schnittstellen zur zuverlässigen Arbeitsmaschine macht — und der den Unterschied zwischen „KI ausprobieren" und „KI produktiv nutzen" ausmacht. kommklick bietet diese Kompetenz im Raum Kiel und für Unternehmen in ganz Schleswig-Holstein.

Was Prompt Engineering wirklich ist

Prompt Engineering hat in der Öffentlichkeit ein falsches Image – als gehe es darum, der KI zu "schmeicheln" oder magische Formulierungen zu finden. Das ist falsch. Professionelles Prompt Engineering ist systematisches Software-Engineering für die Schnittstelle zwischen Anforderung und Modell: Anforderungen präzise spezifizieren, Ausgabeformate verbindlich definieren, Randbedingungen und Fehlerbehandlung beschreiben, und das Ganze so testen und iterieren, dass Qualität messbar wird.

Das Ziel: Ein allgemeines Sprachmodell in ein spezialisiertes Werkzeug für eine definierte Aufgabe verwandeln. Eine KI, die "irgendwie" antwortet, ist nur für manuellen Einsatz brauchbar. Eine KI, die in einem definierten Schema antwortet, ist automatisierbar.

Warum der Entwicklungshintergrund entscheidend ist

Prompt Engineering ohne tiefes Systemverständnis produziert fragile Konstrukte. Es braucht Verständnis für das Tokenisierungsverhalten von Modellen, für Kontextfenster-Grenzen, für die Unterschiede zwischen Modellen bei Anweisungsfolge und JSON-Ausgabe, und für das Zusammenspiel von System-Prompt, Few-Shot-Beispielen und Nutzeranfrage. Ich bringe diese Grundlagen aus aktiver Praxis mit – sowohl als Entwickler von KI-Schnittstellen als auch als täglicher Nutzer verschiedener Modelle.

Kernprinzip: Der Unterschied zwischen einem schlechten und einem guten Prompt ist nicht Kreativität, sondern Präzision. "Analysiere diese E-Mail" ist keine Spezifikation. "Extrahiere Kategorie, Dringlichkeit (1–5) und zuständige Abteilung als JSON – gib ausschließlich das JSON zurück, kein erklärender Text" ist eine Spezifikation.

Strukturierte Ausgaben: Der Kern produktiver KI

Strukturierte Ausgaben sind der wichtigste Hebel, um KI automatisierbar zu machen. Wenn das Modell verlässlich valides JSON zurückgibt, kann der Code drumherum simpel sein: parsen, validieren, weiterverarbeiten. Wenn das Modell frei formuliert, braucht es aufwändiges Nachverarbeiten – mit hoher Fehlerrate.

Drei Stufen strukturierter Ausgaben

  • Prompt-basiert: System-Prompt instruiert das Modell, ausschließlich JSON zurückzugeben. Funktioniert zuverlässig bei Modellen ab GPT-4o / Claude 3 Sonnet-Niveau. Einfachste Variante.
  • JSON-Mode (OpenAI): API-Parameter erzwingt auf Engine-Ebene, dass die Ausgabe valides JSON ist. Kein Text außerhalb des JSON möglich. Parse-Fehlerrate: nahe null.
  • Structured Output mit JSON-Schema: Das exakte Schema wird als API-Parameter übergeben. Das Modell kann das Schema nicht verletzen – falsche Feldtypen oder fehlende Pflichtfelder sind ausgeschlossen. Höchste Zuverlässigkeit.
// JSON-Schema für E-Mail-Klassifikation (OpenAI Structured Output) { "type": "object", "properties": { "kategorie": { "type": "string", "enum": ["beschwerde", "anfrage", "bestellung", "sonstiges"] }, "dringlichkeit": { "type": "integer", "minimum": 1, "maximum": 5 }, "produkt": { "type": ["string", "null"] }, "weiterleitung": { "type": "string", "enum": ["vertrieb", "support", "buchhaltung"] } }, "required": ["kategorie", "dringlichkeit", "weiterleitung"], "additionalProperties": false }

Anthropic Tool Use als Alternative

Anthropic Claude bietet "Tool Use" als Mechanismus für strukturierte Ausgaben: Das Modell wird angewiesen, eine definierte Funktion aufzurufen, statt frei zu antworten. Der Funktionsaufruf ist immer schema-konform. Für Claude-Modelle ist das die zuverlässigste Methode für strukturierte Daten.

Häufiger Fehler: Strukturierte Ausgaben ohne Validierung einsetzen. Auch mit JSON-Mode entstehen gelegentlich Ausgaben, die zwar valides JSON sind, aber inhaltlich falsch (z. B. "dringlichkeit": 7 bei einem Schema mit Maximum 5). Client-seitige Schema-Validierung (Ajv, Zod, Pydantic) ist immer nötig.

Prompt-Architekturen: System-Prompt, Few-Shot, Chain-of-Thought

Professionelle Prompt-Systeme bestehen aus mehreren Schichten. Jede Schicht hat eine klare Aufgabe; zusammen ergeben sie ein robustes System, das auch bei schwierigen oder unerwarteten Inputs stabil bleibt.

System-Prompt: Rolle, Grenzen und Format

Der System-Prompt definiert das grundlegende Verhalten des Modells für alle folgenden Anfragen. Ein guter System-Prompt ist präzise, vollständig, und schließt unerwünschte Verhaltensweisen explizit aus. Drei Pflichtbestandteile:

  • Rolle: Was ist das Modell in diesem Kontext? Nicht "du bist ein Experte", sondern präzise: "Du bist ein Datenextraktions-Assistent. Deine einzige Aufgabe ist die strukturierte Extraktion von Daten aus Kundenmails."
  • Grenzen: Was soll das Modell ausdrücklich nicht tun? "Du bewertest, klassifizierst oder beantwortest keine E-Mails. Du gibst keine Ratschläge."
  • Format-Zwang: "Deine Ausgabe ist ausschließlich valides JSON. Kein einleitender Text, keine Erklärungen, kein Markdown. Nur das JSON-Objekt."

Few-Shot-Prompting: Beispiele statt Beschreibungen

Bei komplexen Klassifikationen ist es effektiver, dem Modell zwei bis fünf konkrete Eingabe-Ausgabe-Beispiele zu geben, als Regeln abstrakt zu beschreiben. Das Modell erkennt das Muster und überträgt es auf neue Fälle zuverlässiger als bei rein textuellen Anweisungen. Entscheidend: Die Beispiele müssen Grenzfälle und typische Fehlerfälle abdecken, nicht nur einfache Standardfälle.

Chain-of-Thought: Komplexe Aufgaben strukturiert lösen

Für mehrstufige Analysen – Risikoeinschätzungen, juristische Bewertungen, Fehlerdiagnosen – wird das Modell explizit angewiesen, Schritt für Schritt zu denken, bevor es eine Antwort gibt. "Denke zuerst durch: (1) Welche Kategorie trifft zu? (2) Welche Signalwörter begründen das? (3) Wie hoch ist die Dringlichkeit aufgrund des Tons?" Diese Strukturierung reduziert Fehler messbar, weil das Modell seinen Denkprozess quasi selbst überprüft.

Praxisfall – E-Mail-Routing: Ein Dienstleister aus Schleswig-Holstein mit 80 Support-E-Mails täglich — manuelle Klassifikation kostete zwei Stunden. Chain-of-Thought-Prompt analysiert zuerst Sentiment, dann Kategorie, dann Dringlichkeit – und gibt erst danach das finale JSON aus. Fehlerrate bei der Routing-Entscheidung: unter 3%. Die API-Anbindung liefert die E-Mails, das Routing-Ergebnis landet direkt im Ticket-System. Kein manueller Eingriff für 97% der Fälle.

Automatisierungs-Pipelines: KI in bestehende Workflows einbetten

Der Wert von Prompt Engineering entfaltet sich erst vollständig, wenn die KI-Ausgaben in einen automatisierten Workflow eingebettet sind. Ein Prompt, der verlässlich strukturierte Daten liefert, kann mit einem Backend-Skript eine vollständige Automatisierungs-Pipeline bilden: Datenquelle → KI-Verarbeitung → Zielsystem. Ohne menschlichen Eingriff.

Mehrstufige Pipelines (LLM-Chains)

Komplexe Aufgaben lassen sich selten mit einem Prompt lösen. Mehrere Modell-Aufrufe werden hintereinander geschaltet, jeder Schritt verfeinert das Ergebnis des vorherigen:

  • Schritt 1 – Segmentierung: Vertragstext in Klauseln aufteilen. Ausgabe: strukturierte Liste.
  • Schritt 2 – Klassifikation: Jede Klausel kategorisieren (Haftung, Laufzeit, Kündigung, Zahlungsbedingung).
  • Schritt 3 – Risikobewertung: Kritische Klauseln auf Risiken prüfen (neutral / problematisch / inakzeptabel) mit Begründung.
  • Schritt 4 – Summary: Executive Summary der kritischen Punkte mit Handlungsempfehlung.

Jeder Schritt ist eigenständig testbar und austauschbar. In Kombination mit Browser-Automatisierung können die zu verarbeitenden Dokumente automatisch aus Webportalen extrahiert und die Ergebnisse direkt zurückgeschrieben werden.

Kosten-Optimierung in Pipelines

  • Modellauswahl nach Schritt: Einfache Klassifikation → günstiges Modell; komplexe Risikobewertung → leistungsstarkes Modell
  • Prompt-Kompression: Kürzere Prompts kosten weniger. Präzision statt Länge.
  • Ergebnis-Caching: Identische Inputs werden gecacht – kein Modell-Aufruf, keine Kosten
  • Batch-Verarbeitung: Mehrere Inputs in einem Aufruf – 40–60% Kosteneinsparung gegenüber Einzelanfragen

Qualitätssicherung und Prompt-Testing

Prompts sind Software. Wie Software brauchen sie Tests, Versionierung und Qualitätssicherung. Modell-Updates können das Verhalten verändern, ohne Ankündigung. Was gestern funktionierte, kann morgen anders antworten.

Evaluierungs-Framework

  • Goldstandard-Datensatz: 50–200 reale Inputs mit manuell erstellten Soll-Ausgaben. Jede Prompt-Änderung wird dagegen getestet – Regressionen sofort sichtbar.
  • Strukturelle Validierung: JSON-Schema-Validierung aller Ausgaben. Parse-Fehlerrate muss unter 0,5% liegen.
  • Semantische Metriken: Für Klassifikationsaufgaben: Precision, Recall, F1-Score pro Klasse.
  • Konsistenz-Test: Dieselbe Anfrage fünffach senden (Temperatur > 0). Varianz muss innerhalb akzeptabler Grenzen bleiben.
  • Adversarial Testing: Absichtlich schwierige, mehrdeutige oder manipulative Inputs testen – stellt sicher, dass der System-Prompt bei Grenzfällen stabil bleibt.

Prompt-Versionierung

Prompts werden versioniert wie Code: in Git, mit Changelogs, mit Test-Ergebnissen pro Version. Ein Rollback auf eine ältere Prompt-Version muss jederzeit möglich sein. Ich lege für jedes Projekt eine Prompt-Bibliothek an, die unabhängig von der Anwendungslogik gepflegt wird.

Monitoring nicht vergessen: Prompt-Qualität muss auch im laufenden Betrieb überwacht werden. Ich baue Monitoring-Systeme, die Ausgaben kontinuierlich auf Qualitätsmetriken prüfen und alarmieren, wenn die Fehlerrate einen Schwellenwert überschreitet oder Ausgabe-Strukturen vom Schema abweichen.

Wo Prompt Engineering an Grenzen stößt

Nicht jede Aufgabe ist durch bessere Prompts lösbar. Wenn ein Modell systematisch bei bestimmten Eingabe-Typen versagt, kann Fine-Tuning auf einem eigenen Datensatz die bessere Lösung sein. Wenn Latenz und Kosten kritisch sind und die Aufgabe präzise definiert ist, kann ein klassisches ML-Klassifikationsmodell schneller und günstiger sein als ein Sprachmodell. Ich empfehle den richtigen Ansatz für die konkrete Aufgabe – nicht den, der am modernsten klingt.

Praxisfall – Finanzkennzahlen-Extraktion: Kennzahlen aus Jahresberichten (EBITDA, Umsatz, Eigenkapitalquote) automatisch extrahieren. Pipeline: PDF-Parsing → Keyword-Filterung relevanter Seiten → strukturierter Extraktions-Prompt mit JSON-Schema und expliziter Quellenangabepflicht ("Jede Zahl muss mit Seitenangabe belegt sein – wenn nicht belegbar, null setzen"). Halluzinationsrate auf numerische Felder: unter 1%. Verarbeitungskosten: Bruchteil manueller Arbeit. Weitere technische Details zur API-Anbindung: KI-Schnittstellen.