Produktions-Prompt-Labels nicht von Hand verwalten

Prompts sind Teil deiner Anwendung.

Das klingt offensichtlich. Produktionssysteme behandeln sie trotzdem oft anders als Code. Code durchläuft CI/CD, bekommt eine Build-Nummer, wird getestet, deployed und kann zurückgerollt werden. Prompts liegen dagegen manchmal hinter einem Label wie production, das jemand in Langfuse von Hand verschiebt.

Das funktioniert, bis es nicht mehr funktioniert.

Wenn sich Code und Prompt-Version unabhängig voneinander weiterentwickeln, können Kombinationen in Produktion landen, die nie gemeinsam getestet wurden.

Prompts und Code haben einen Vertrag

Ein Prompt steht selten für sich allein.

Die Anwendung bereitet den Input vor, lädt Kontext, ruft den Prompt auf, erwartet eine bestimmte Struktur der Antwort, parst und validiert sie und verarbeitet das Ergebnis anschließend weiter.

Jede dieser Annahmen kann sich ändern. Ein Prompt erwartet plötzlich ein zusätzliches Input-Feld. Die Anwendung benennt eines um. Die Antwort wechselt von Freitext zu strukturiertem JSON. Parsing oder Validierung werden strenger.

Prompt und Anwendung haben einen Vertrag miteinander. Wenn neuer Code einfach auf den Prompt zeigt, der gerade das Label production trägt, ist dieser Vertrag nicht mehr an ein bestimmtes Release gebunden.

Deployments verschärfen das Problem

Produktions-Deployments sind selten sofort abgeschlossen.

Bei einem Rolling- oder Blue-Green-Deployment können zwei Anwendungsversionen gleichzeitig Traffic bedienen. Version 41 wurde mit einem bestimmten Satz von Prompts getestet. Version 42 mit einem anderen.

Wenn beide dasselbe veränderliche production-Label verwenden, auf welche Prompt-Version soll dieses Label während des Rollouts zeigen?

Darauf gibt es keine richtige Antwort. Verschiebst du es zu früh, bekommen alte Instanzen Prompts, für die sie nicht ausgelegt wurden. Verschiebst du es zu spät, bekommen neue Instanzen noch die alten Prompts.

Das Problem ist nicht Langfuse. Das Problem ist, ein veränderliches Label als Deployment-State zu behandeln.

Gib jedem Deployment einen eigenen Prompt-Snapshot

Die Lösung, die ich letztlich verwendet habe, ist einfach: Jedes Application-Deployment bekommt sein eigenes Prompt-Label.

Zum Beispiel:

prod-build-20260907.3

Bevor die Anwendung deployed wird, erstellt CI/CD einen Snapshot der Prompts für dieses Release und weist ihnen das Build-spezifische Label zu. Das Deployment erhält dasselbe Label über eine Umgebungsvariable:

LANGFUSE_PROMPT_LABEL=prod-build-20260907.3

Damit sind Image und Prompts fest miteinander verknüpft. Eine Instanz mit Build 41 lädt weiterhin über das Label von Build 41. Build 42 lädt über das Label von Build 42. Beide können gleichzeitig Traffic bedienen.

Ein Produktions-Label sollte ein Snapshot sein, kein beweglicher Zeiger.

Sobald prod-build-20260907.3 den Prompt-Satz für dieses Deployment repräsentiert, sollte es genau diesen Satz auch weiterhin repräsentieren. Du versionierst die Gesamtheit der Prompts, die die Anwendung verwendet, nicht nur einzelne Prompts. Ein Release ist mit einer bestimmten Kombination davon kompatibel.

Das deployte Artefakt ist:

application release = code + prompt snapshot + configuration

Wenn sich einer dieser Bestandteile unabhängig unter einem laufenden Deployment verändern kann, ist das Release nicht reproduzierbar.

Das gehört in CI/CD

Das von Hand zu machen, skaliert nicht.

Ein Produktionssystem startet vielleicht mit drei Prompts und wächst auf mehrere Dutzend. Bei jedem Deployment müsste man jeden Prompt finden, die richtige Version auswählen, das Label zuweisen und hoffen, dass nichts übersehen wurde.

Das ist mühsam und gefährlich.

In unserer Deployment-Pipeline lief das Erstellen des Prompt-Snapshots vor dem Application-Deployment. Das Deployment war davon abhängig, dass dieser Schritt erfolgreich war. Der Snapshot-Befehl sammelte alle Prompts hinter einem Source-Label, normalerweise development, und wies ihnen das Deployment-spezifische Produktions-Label zu.

Wenn auch nur ein Prompt nicht übernommen werden konnte, schlug der Befehl fehl. Damit schlug auch das Deployment fehl.

Prompts sollten nicht nach dem Best-Effort-Prinzip promoted werden. Wenn 29 von 30 erfolgreich übernommen werden, hast du kein größtenteils erfolgreiches Release. Du hast ein inkonsistentes Release.

Rollbacks werden langweilig

Der operative Vorteil zeigt sich, wenn etwas schiefläuft.

Build 41 lief mit image:41 und LANGFUSE_PROMPT_LABEL=prod-build-41. Build 42 lief mit image:42 und LANGFUSE_PROMPT_LABEL=prod-build-42.

Wenn Build 42 zurückgerollt werden muss, stellst du Build 41 zusammen mit seinem Prompt-Label wieder her. Du musst Langfuse nicht öffnen und rekonstruieren, welche Versionen von zwanzig Prompts vorher aktiv waren. Es besteht auch kein Risiko, den Code zurückzurollen, während die neueren Prompts weiter in Produktion bleiben.

Code und Prompts bewegen sich als eine Einheit.

Patch-Deployments brauchen dieselbe Eigenschaft

Nicht jedes Deployment sollte automatisch die neuesten Development-Prompts übernehmen.

Manchmal brauchst du nur einen Code-Fix und möchtest die aktuell deployten Produktions-Prompts unverändert lassen. Die Pipeline unterstützte das, indem der Snapshot von einem bestehenden Production-Build-Label statt von development erstellt wurde.

Auch der Patch bekam weiterhin sein eigenes unveränderliches Prompt-Label. Er teilte keinen veränderlichen State mit einem anderen Deployment.

Mach den Snapshot idempotent

CI/CD-Jobs werden erneut ausgeführt.

Ein Prompt-Deployment-Schritt sollte daher gefahrlos mehrmals laufen können. Das Tooling, das wir verwendet haben, verglich zuerst die Target-Labels mit dem Source-Satz. Wenn sie bereits übereinstimmten, wurde der Vorgang erfolgreich beendet, ohne den Zustand erneut zu erzeugen.

Retries bleiben damit sicher. Der Prozess bleibt vorhersehbar. Ein Build-Label ist ein bekannter Snapshot und keine Aktion, die jemand von Hand ausführt.

Prompt-Versionierung ist Application-Versionierung

Prompt-Management beginnt oft als Produkt- oder Experimentier-Thema.

Das ändert sich, sobald Prompts Teil einer Produktionsanwendung sind. Sie sind genauso wie Code Bestandteil von Interfaces, Schemas, Parsing, Validierung und möglichen Fehlerfällen.

Ein veränderliches production-Label verschleiert das. Build-spezifische Labels machen diese Abhängigkeit explizit.

Wenn dein Code an einen bestimmten Build gebunden ist, deine Prompts aber nur an das, was gerade production heißt, hast du nur die Hälfte deiner Anwendung versioniert.

Brauchst du Unterstützung?

Wenn dein Release-Prozess stark manuell und fehleranfällig ist, kann ich helfen. Die übliche Lösung ist kein sorgfältigerer Labeling-Prozess. Es ist ein Snapshot pro Build, damit Code und Prompts gemeinsam deployed werden, parallel existieren und als eine Einheit zurückgerollt werden können.

Hinweis: Dieser Artikel wurde mithilfe von KI aus dem englischen Original ins Deutsche übersetzt.