Schluss mit Mutmaßen, her mit Messen: Ein systematischer Prompt-Enhancement-Workflow für KI-Systeme in Production

In vielen Fällen entwickeln Teams Prompts auf eine sehr entspannte Art und Weise, ähnlich wie beim Schreiben formloser E-Mails. Das ist ein natürlicher Prozess, bei dem wenig über strukturelle Elemente nachgedacht wird. Dieser unverkrampfte Ansatz ist für die explorative Entwicklung oder auch die schnelle Erstellung eines Prototyps durchaus angemessen.

Sobald man jedoch beginnt, ein Feature, das auf einem Large Language Model basiert, vor echten Nutzern einzusetzen, werden Prompts zu einem kritischen Faktor. Wenn Prompts nicht gut konzipiert sind, kann dies zu Fehlern führen: Die Antworten sind möglicherweise nicht konsistent, wichtige Informationen fehlen oder die Ausgaben sind schlichtweg unzuverlässig.

Darüber hinaus ist das Debugging unerwartet komplex, wenn ein Problem auftritt. Man ist oft gezwungen herauszufinden, ob das Problem mit dem Modell, dem Input oder sogar dem Prompt selbst zusammenhängt.

Dieser Beitrag beschreibt den genauen Prozess, den wir entwickelt haben, um Prompts von „wahrscheinlich gut genug“ zu „definitiv gut genug für Production“ zu bewegen – mit echten Kriterien, echten Evaluations-Datensätzen und echten Benchmarks über mehrere Modelle hinweg. Keine Magie. Nur strukturiertes Engineering, angewendet auf Prompts.

Warum Prompts mehr als nur Anweisungen sind

Wenn die meisten Menschen an einen Prompt denken, stellen sie sich eine einfache Aufforderung vor, wie zum Beispiel: „Fasse dieses Dokument zusammen“ oder „Extrahiere Entitäten aus diesem Text“. Aber in der realen Welt ist ein Prompt so viel mehr als das. Er ist die grundlegende Schnittstelle zwischen Ihrem Programm und dem Verhalten des Modells. Ein guter Prompt erstellt die Persona für das Modell, die Verhaltensregeln, das Ausgabeformat und deckt auch unerwartete Fälle ab.

Das Problem bei Prompts ist, dass sie meist nicht gründlich getestet werden. Sie werden entworfen, implementiert und dann nur flüchtig überprüft, ob sie funktionieren. Man nimmt hier eine Änderung vor und fügt dort eine Regel hinzu. Dann hofft man einfach, dass es gut geht. Manchmal funktioniert es. Meistens nicht. Wenn es fehlschlägt, funktioniert es einfach gar nicht mehr – und möglicherweise bemerken Sie es nicht einmal direkt.

Was macht einen Prompt wirklich „gut“?

Ein guter Prompt ist nicht nur klar formuliert, sondern strukturiert. Stellen Sie ihn sich wie einen API-Vertrag zwischen Ihnen und dem Modell vor. Er sollte Folgendes definieren:

• Eine Rolle oder Persona: Aus welchem Kontext heraus soll das Modell agieren?
• Anweisungen: Was genau soll es tun?
• Einschränkungen (Constraints): Was darf es niemals tun?
• Spezifikation der Ausgabe: Welches Format, welche Struktur und welche Länge werden erwartet?
• Kontextuelle Führung: Welches Hintergrundwissen benötigt das Modell, um ohne Annahmen zu handeln?
• Beispiele: Wie sieht eine gute Ausgabe aus?

Wenn all diese Elemente vorhanden sind, verfügt das Modell über alles, was es braucht, um über verschiedene Inputs und sogar über unterschiedliche Modellversionen hinweg konsistent, zuverlässig und vorhersehbar zu reagieren.

Die echten Kosten schlecht strukturierter Prompts in Production

Folgendes haben wir bei unzureichenden Prompts in realen Deployments beobachtet:

Ausgaben, die richtig aussehen, es aber nicht sind: Das Modell erzeugt eine Antwort, die den Eindruck erweckt, im richtigen Format zu sein, aber subtile Fehler enthält, weil die Spezifikation unklar war.

Modellübergreifende Fehler: Der Prompt funktioniert hervorragend mit GPT-4, liefert jedoch inkonsistente Antworten bei Claude und OSS-Modellen. Niemand hat ihn vor dem Deployment modellübergreifend getestet.

Stille Regressionen: Das Ändern eines einzelnen Wortes zur Behebung eines Problems verursacht drei andere Probleme, die niemand bemerkt, bis sich ein Nutzer beschwert.

Das Problem ist immer dasselbe: Niemand hat den Prompt wie etwas behandelt, das getestet und validiert werden muss. Wir haben diesen Prozess entwickelt, um genau das zu beheben.

Unser Prompt-Enhancement-Workflow: Schritt für Schritt

Der Workflow besteht aus fünf Schritten. Jeder baut auf dem vorherigen auf. Wenn Sie einen überspringen, werden die Ergebnisse schnell unzuverlässig. So funktioniert es End-to-End:

Schritt 1 – Evaluierung des Prompts

Bevor wir Änderungen vornehmen, wollen wir genau wissen, was fehlerhaft ist. Wir verwenden eine strukturierte Evaluation Engine, die für jeden Prompt ausgeführt wird, ihn anhand von fünf verschiedenen Dimensionen bewertet und einen Gesamt-Qualitätsscore von 0 bis 100 liefert.

Wir verwenden keine subjektive Bewertung. Wir haben klare Kriterien für alle Dimensionen und harte Constraints. Wenn beispielsweise keine Ausgabespezifikation im Prompt enthalten ist, gibt es einen Höchstwert für den Score der Ausgabespezifikation. Der Score kann selbst dann begrenzt sein, wenn die Anweisungen im Prompt ansonsten gut formuliert sind. Liegt der Score unter 75, ist der Prompt nicht bereit für Production. Liegt er über 90, ist er in allen Dimensionen solide.

Schritt 2 – Empfehlungen anhand von 5 Kriterien generieren

Dies ist die Diagnose-Engine des Workflows. Jeder Prompt wird anhand von fünf spezifischen Kriterien auf einer Skala von 0–100 bewertet. Der Gesamtscore ist das arithmetische Mittel aller fünf Kriterien. Hier ist, was jedes Kriterium misst und warum es wichtig ist:

1. Klarheit und Spezifität (Clarity and Specificity)

Sind die Anweisungen so klar, dass zwei verschiedene Modelle sie auf genau dieselbe Weise verstehen? Vage Anweisungen verursachen mehr Inkonsistenzen als jeder andere einzelne Faktor. Wenn Sie sich unsicher sind, wie ein Mensch Ihren Prompt interpretieren könnte, sind Sie sich wahrscheinlich auch unsicher, wie ein Modell ihn interpretieren wird. Gibt es mehr als eine Möglichkeit für einen Menschen, ihn zu verstehen, gibt es auch mehr als eine Möglichkeit für ein Modell, ihn richtig oder falsch zu interpretieren.

2. Struktur und Organisation (Structure and Organization)

Fließt der Prompt logisch von Kontext → Anweisungen → Constraints → Ausgabeformat? Ein unstrukturierter Prompt zwingt das Modell dazu, selbst herauszufinden, was wichtig ist und in welcher Reihenfolge. Eine gute Struktur erleichtert dem Modell die Arbeit und macht Ihre Ausgaben zuverlässiger.

3. Ausgabespezifikation (Output Specification)

Sind das erwartete Ausgabeformat, die Struktur und die Länge präzise definiert? Wenn die Ausgabe von einem nachgelagerten Parser verarbeitet werden muss, bestehen dann keinerlei Unklarheiten darüber, wie die Ausgabe aussehen wird? Dies prüft den häufigsten Fehlerfall: Ausgaben, die richtig aussehen, aber nicht geparst werden können.

4. Kontextuelle Führung (Contextual Guidance)

Bietet dieser Prompt dem Modell ausreichend Kontext, um ohne eigene Annahmen zu agieren? Modelle, die Annahmen treffen müssen, werden immer wieder falsche Annahmen treffen. Kontext wie Domänenterminologie, Grenzinformationen und Hintergrundwissen eliminiert diese Art von Fehlern vollständig.

5. Fehlerbehandlung (Error Handling)

Werden Grenzfälle (Edge Cases) abgedeckt? Gibt dieser Prompt an, was zu tun ist, wenn die Eingabe mehrdeutig, unvollständig oder außerhalb des zulässigen Bereichs ist? Dies wird am häufigsten übersehen und verursacht die meisten Probleme in Production. Halluzinationen, unerwartete Eingabeformate, fehlende Informationen – all das muss im Prompt abgedeckt werden.

Bewertungsskala: 90–100 ist bereit für Production. 75–89 weist Lücken auf, ist aber funktional. 50–74 funktioniert, ist aber unzuverlässig. Unter 50 bedeutet erhebliche strukturelle Probleme, die vor dem Deployment behoben werden müssen.

Schritt 3 – Anwenden der Empfehlungen

Wir haben die Scores und Erklärungen für jedes Kriterium vorliegen. Als Nächstes erstellen wir eine konkrete Version des verbesserten Prompts. Die Empfehlungen sind keine abstrakten Ideen; sie entsprechen tatsächlichen Änderungen an der Struktur des Prompts. Zu diesen Änderungen gehören das Hinzufügen fehlender Ausgabespezifikationen, das Präzisieren unklarer Anweisungspunkte, das Trennen von inhaltlichen und formatbezogenen Aspekten sowie das explizite Festlegen von Fallbacks für Grenzfälle.

Die wichtigste Einschränkung, die wir uns auferlegen, ist die Wahrung der Absicht (Intent Preservation). Mit anderen Worten: Wir schreiben den Prompt nicht völlig neu. Stattdessen füllen wir die Lücken, die die Evaluierung aufgezeigt hat, während die ursprüngliche Absicht und die Fachdomäne unverändert bleiben.

Schritt 4 – Testen auf Evaluierungs-Datensätzen

Der optimierte Prompt wird erst dann in der Anwendung ausgeführt, wenn er auf die Probe gestellt wurde. Der Test wird mit einem Benchmark-Datensatz durchgeführt, der alle möglichen Szenarien und Fehlermöglichkeiten in Bezug auf die Anwendung repräsentiert.

Dieser Prozess ist notwendig, da Änderungen an Prompts, die in der Theorie vorteilhaft erscheinen, in der Praxis zu unbeabsichtigten Problemen führen können. Wenn beispielsweise eine Ausgabespezifikation strikter gefasst wird, kann dies in Kombination mit bestimmten Input-Typen zu Fehlern führen, weil dem Modell die nötige Flexibilität in anderen Situationen genommen wird.

Schritt 5 – Leistungsvergleich über Metriken und Modelle hinweg

Der letzte Schritt ist das Benchmarking. Wir vergleichen die ursprünglichen und die verbesserten Prompts in zwei Dimensionen:

• Metriken:

• Allgemeine Qualität: Clarity, Completeness, Accuracy, Conciseness, Professional Tone
• Guardrails / Klassifizierung: Output Format Compliance, Hallucination Avoidance
• Konversationell: Answer Relevance, Prompt Instruction Adherence, Empathy & Tone

Der Gesamtscore ist das arithmetische Mittel der ausgewählten Metriken; Nutzer können relevante Metriken vor der Evaluierung auswählen.

• Modelle: Gemini, GPT-5, Claude und Open-Source-Modelle. Während ein Prompt für ein bestimmtes Modell optimiert ist, kann er bei einem anderen Modell fehlschlagen – nicht weil der Prompt falsch ist, sondern weil sich die Modelle darin unterscheiden, wie gut sie Anweisungen befolgen, wie viel Struktur sie tolerieren und was sie bei unklaren Eingaben annehmen.

Die Vergleichsansicht zeigt, wo die Verbesserung real ist, wo sie modellspezifisch ist und wo weitere Iterationen erforderlich sind, bevor der Prompt als anbieterübergreifend portabel angesehen werden kann.

Schritt 6 – Vorschläge anwenden & verfeinern

Anschließend bewertet der LLM Judge beide Prompts, und es werden Verbesserungsvorschläge in priorisierter Reihenfolge bereitgestellt – kategorisiert als HIGH, MEDIUM und LOW, basierend darauf, wo das Delta des Scores zwischen dem Original und der verbesserten Version am schwächsten war.

Sie wählen aus, welche Vorschläge als Empfehlung angewendet werden sollen, und das System leitet sie erneut durch dieselbe Enhancement-Pipeline, um einen weiter verfeinerten Prompt zu erzeugen. Diese Feedback-Schleife verbessert den Prompt kontinuierlich durch erneutes Evaluieren und Verfeinern.

Dies sind keine allgemeinen Ratschläge, sondern sie beziehen sich spezifisch auf Ihre Testfälle. Der Grund dafür ist, dass das Evaluator-Modell bewertet, wie gut Ihre ursprünglichen und Ihre erweiterten Prompts in Ihren konkreten Testfällen abgeschnitten haben. Die angezeigten Vorschläge stehen in direktem Zusammenhang mit dem, was bei der Evaluierung Ihrer Testfälle gefehlt hat. Wenn Sie dieser Evaluierung weitere Testfälle hinzufügen würden, könnten Sie andere Vorschläge sehen.

Sie können diesen Prozess so oft wie nötig wiederholen. Jeder Zyklus verwendet den zuvor verbesserten Prompt als neue Baseline, sodass sich die Optimierungen aufsummieren. Der finale, verfeinerte Prompt kann direkt aus der Benutzeroberfläche heruntergeladen und über das TrueFoundry Gateway deployed werden.

Warum sich derselbe Prompt bei verschiedenen Modellen unterschiedlich verhält

Wenn wir über Prompt Engineering sprechen, gibt es einen Aspekt, den wir oft nicht bedenken: Modelle wie Gemini, GPT-5, Claude und LLaMA „verstehen“ Dinge nicht auf dieselbe Weise. Das liegt daran, dass sie alle mit unterschiedlichen Methoden und Trainingsdaten trainiert wurden und für leicht abweichende Aufgaben optimiert sind. Wenn wir ihnen dieselbe Frage stellen, geben sie uns daher möglicherweise unterschiedliche Antworten. Das liegt nicht daran, dass die Frage schlecht ist, sondern daran, dass jedes Modell seine eigene Verhaltensweise hat.

Einige Modelle sind sehr gut darin, Regeln strikt zu befolgen und genau das zu tun, was vorgegeben ist. GPT-4-Modelle neigen beispielsweise dazu, Anweisungen sehr wörtlich zu nehmen. LLaMA-Modelle sind möglicherweise generativer und versuchen, Lücken selbstständig zu füllen. Claude-Modelle glänzen oft bei der Handhabung komplexer, vielschichtiger Fragestellungen, während andere Modelle besser darin sind, einfache Anfragen direkt zu beantworten.

Der einzige Weg herauszufinden, wie sich ein Prompt über verschiedene Modelle hinweg verhält, ist das Testen. Und der einzige Weg, dieses Testen systematisch zu gestalten, besteht in einem Evaluierungs-Workflow wie diesem.

Verwaltung von Prompt-Versionen in Production mit dem TrueFoundry Gateway

Sobald Ihr Prompt evaluiert, verbessert und getestet wurde, benötigen Sie ein System, um ihn im Laufe der Zeit zu verwalten: Versionierung, umgebungsspezifisches Deployment und die Möglichkeit, fehlerhafte Änderungen zurückzusetzen, ohne die gesamte Anwendung neu deployen zu müssen.

Hier kommt das AI Gateway von TrueFoundry ins Spiel. TrueFoundry bietet ein zentrales Prompt-Managementsystem mit integrierter Versionierung: Jede Änderung an einem Prompt wird nachverfolgt, und Sie können sich auf spezifische Versionen über sprechende Aliase wie v1-prod oder v2-staging beziehen. Das Gateway löst die Prompt-Version zur Laufzeit auf, was bedeutet, dass Prompt-Updates keine erneuten Code-Deployments mehr erfordern.

Gewonnene Erkenntnisse und Best Practices

Da der Workflow auf eine Vielzahl von Prompts und Projekten angewendet wurde, haben sich mehrere Kernpunkte herauskristallisiert:

1. Es ist essenziell, stets sicherzustellen, dass Diagnose-Scores vor der Bearbeitung eingeholt werden. Die natürliche Reaktion auf ein Problem besteht darin, sofort Änderungen vorzunehmen, sobald ein Fehler erkannt wird. Dies sollte vermieden werden. Erfassen Sie die Diagnose, bevor Sie Änderungen vornehmen. Das Hauptproblem liegt oft in einem Bereich, der ursprünglich gar nicht im Verdacht stand.
2. Trennen Sie den Ausgabestil vom Inhalt. Die Kombination beider Aspekte erzeugt Unklarheiten, die die Konsistenz subtil untergraben. Dem Modell sollten Inhalt und Ausgabestil separat mitgeteilt werden.
3. Überspringen Sie nicht die Fehlerbehandlung (Error Handling). Der zusätzliche Aufwand macht sich erst bezahlt, wenn unerwartete Eingaben zu unerwünschtem Verhalten führen. Definieren Sie Pfade zur Fehlerbehandlung, um auch Kosteneffizienz zu gewährleisten.
4. Behandeln Sie Prompts wie Code. Implementieren Sie Versionierung und Reviews vor dem Release unter Nutzung des aktuellen Toolsets.
5. Integrieren Sie modellübergreifende Tests frühzeitig. Nach einer Änderung festzustellen, dass ein Prompt zwar für ein Modell, aber nicht für andere funktioniert, ist ungünstig. Machen Sie modellübergreifende Tests zum Standardbestandteil Ihres Workflows.

Wie es weitergeht: Prompt Engineering als System

Das Ziel, auf das wir hinarbeiten, besteht darin, die Prompt-Qualität ebenso messbar und auditierbar zu machen wie jeden anderen Teil Ihres Software-Stacks. Das bedeutet: automatisierte Regressionstests für Prompts, wenn sich die zugrundeliegende Modellversion ändert, eine in Ihre Deployment-Pipeline integrierte Prompt-Versionierung und Evaluierungs-Dashboards, die Einblick in die Prompt-Performance im Laufe der Zeit geben.

Prompt Engineering wird nicht mehr als bloßes Handwerk angesehen, sondern als Disziplin. Organisationen, die es als solche behandeln und einen formalen Prozess für Evaluierung, Iteration und Testen implementieren, werden besser aufgestellt sein, um zuverlässigere KI-Systeme zu bauen als diejenigen, die dies nicht tun. Der in diesem Workflow beschriebene Prozess ist ein Schritt genau in diese Richtung.