Skip to content
Innopulse Consulting
AI Engineering

Prompt Engineering für Produkte (nicht für Demos)

Prompts im Produkt sind Code: versioniert, getestet, strukturiert. Wie man Systemprompts aufbaut, Ausgaben erzwingt, Eingaben von Anweisungen trennt und Prompts wartbar hält.

Leutrim Miftaraj
Leutrim Miftaraj
Gründer & CEO
·Aktualisiert ·4 min Lesezeit

In einer Demo genügt ein Prompt, der bei drei ausgewählten Beispielen gut aussieht. In einem Produkt muss er bei tausenden unterschiedlichen Eingaben verlässlich funktionieren, von Menschen gepflegt werden, die ihn nicht geschrieben haben, und Modellwechsel überstehen. Prompt Engineering für Produkte hat deshalb wenig mit cleveren Formulierungen zu tun und viel mit Struktur, Versionierung und Tests.

Prompts sind Code

Ein Prompt im Produkt verdient dieselbe Sorgfalt wie jede andere Programmlogik. Er liegt in der Versionsverwaltung, nicht in einer Datenbankzeile, die jemand im Adminbereich ändern kann. Änderungen laufen über Review und werden gegen einen Bewertungsdatensatz geprüft. Jede Modellanfrage protokolliert, mit welcher Prompt-Version sie gestellt wurde. Nur so lässt sich nachvollziehen, warum sich das Verhalten einer Funktion verändert hat.

Aufbau eines Systemprompts

Bewährt hat sich eine feste Gliederung: zuerst die Rolle und die Aufgabe in wenigen klaren Sätzen, dann der Kontext, den das Modell braucht, dann die Regeln, dann das erwartete Ausgabeformat, zuletzt Beispiele. Regeln sollten positiv formuliert sein — was zu tun ist — und begründet, wo das Verhalten nicht selbsterklärend ist. Lange Listen von Verboten führen eher dazu, dass Modelle unsicher werden und vorsichtig ausweichen.

Stabile Teile gehören an den Anfang, variable an das Ende. Das erleichtert die Pflege und ermöglicht bei vielen Anbietern das Zwischenspeichern des stabilen Teils, was Kosten und Antwortzeit senkt.

Eingaben klar von Anweisungen trennen

Inhalte von Nutzern, aus Dokumenten oder aus E-Mails sollten im Prompt deutlich als Daten markiert sein, etwa durch klar benannte Abschnitte. Das Modell muss wissen, dass Text innerhalb dieses Abschnitts zu bearbeiten ist und keine Anweisungen enthält, denen es folgen soll. Diese Trennung verringert das Risiko von Prompt Injection, ersetzt aber keine strukturellen Schutzmassnahmen: Was ein Modell nicht darf, sollte es technisch nicht können.

Ausgaben erzwingen statt erbitten

Wenn das Ergebnis von Code weiterverarbeitet wird, sollte es strukturiert sein — und zwar nicht nur, weil der Prompt höflich darum bittet. Viele Anbieter unterstützen strukturierte Ausgaben nach einem vorgegebenen Schema oder Werkzeugaufrufe mit definierten Parametern. Zusätzlich prüft der eigene Code jede Ausgabe gegen das Schema und behandelt Abweichungen kontrolliert: erneut anfragen, auf einen einfacheren Weg ausweichen oder einen verständlichen Fehler zeigen.

Beispiele mit Bedacht

Beispiele im Prompt sind wirksam, weil sie Format und Ton zeigen statt beschreiben. Sie haben aber eine Nebenwirkung: Modelle neigen dazu, Inhalte und Formulierungen aus den Beispielen zu übernehmen. Bewährt haben sich wenige, bewusst unterschiedliche Beispiele, die die Bandbreite der erwarteten Fälle abdecken, und Beispiele, deren Inhalt offensichtlich fiktiv ist.

Ein Prompt pro Aufgabe

Ein einziger, immer längerer Prompt, der alle Fälle abdecken soll, wird mit jeder Ergänzung fragiler. Besser sind mehrere spezialisierte Prompts für klar abgegrenzte Aufgaben, verbunden durch Code: ein Schritt klassifiziert die Anfrage, ein zweiter beantwortet sie mit dem passenden Prompt. Das macht jeden einzelnen Teil verständlicher, testbarer und erlaubt, für einfache Teilaufgaben ein kleineres Modell zu wählen.

Modellwechsel überstehen

Prompts, die eng auf die Eigenheiten eines bestimmten Modells abgestimmt sind, funktionieren beim nächsten Modell oft schlechter. Klare, strukturierte Prompts mit expliziten Anforderungen sind robuster als Formulierungen, die sich auf Zufallsbeobachtungen stützen. Vor jedem Wechsel läuft der Bewertungsdatensatz; Anpassungen erfolgen gezielt dort, wo er Schwächen zeigt.

Sprache und Region

Für deutschsprachige Produkte gehört in den Prompt, was Schweizer, deutsche oder österreichische Nutzer erwarten: Schreibweise mit «ss» für die Schweiz, Anrede, Datums- und Zahlenformate, Fachbegriffe. Solche Vorgaben sollten zentral gepflegt und in alle Prompts eingebunden werden, statt in jedem einzeln formuliert zu sein.

Zusammengefasst

  • Prompts versionieren, reviewen und gegen einen Datensatz testen.
  • Feste Gliederung, stabile Teile zuerst, Daten klar markiert.
  • Strukturierte Ausgaben erzwingen und im Code prüfen.
  • Lieber mehrere spezialisierte Prompts als einen allumfassenden.
  • Sprach- und Formatvorgaben zentral pflegen.

Innopulse behandelt Prompts in eigenen Produkten wie Code, und genau so bauen wir sie auch für Kunden.

Über den Autor
Leutrim Miftaraj
Leutrim Miftaraj
Gründer & CEO · Innopulse Consulting

Gründer und leitender Ingenieur von Innopulse Consulting. MSc Innovation Management (FFHS). Autor von „Identity Over Discipline".

Topics
prompt engineering produktsystemprompt aufbaustrukturierte ausgabe llmprompt versionierungprompt injection schutz
Arbeiten Sie an etwas Ähnlichem?

Sprechen wir.

Wenn dieser Artikel ein Problem trifft, an dem Sie gerade arbeiten, schicken Sie uns eine kurze Beschreibung — wir antworten mit einem konkreten nächsten Schritt.