Release & Rollout

Szenario

Euer Support-Assistent lief seit Monaten stabil. Letzte Woche hat jemand per Hotfix den System-Prompt geschärft — direkt als String-Konstante im Service. Der Modellname steht als Env-Variable im Deployment, temperature und top-k sind Defaults in zwei verschiedenen Modulen. Jetzt sind die Antworten schlechter, und niemand kann sagen, welche Kombination aus Prompt, Modell und Config vorher lief. Ein sauberer Rollback ist nicht möglich.

Anforderungen

• Wie strukturierst du Releases dieses Features künftig?
• Bewerte Ursache, wirksame Grenze und den Preis der tragfähigen Maßnahme getrennt.

Schritte

1. Tragfähiger Ansatz: Prompt-Text, Modell-Pin, Decoding-Parameter und Retrieval-Config als ein versioniertes Artefakt bündeln, das als Einheit deployt und zurückgerollt wird — unabhängig vom Code-Release. Richtig. Die Ausgabe hängt an der Kombination dieser Faktoren. Nur wenn sie gemeinsam eine wiederherstellbare Version haben, ist jede Produktions-Ausgabe reproduzierbar und Rollback = vorherige Artefakt-Version.
2. Plausibler Fehlweg: Den Prompt in eine Registry auslagern und dort versionieren; Modell und Config bleiben Code-Konstanten — danach ohne Kontrollgruppe oder Stop-Gate vollständig auf den Produktionsverkehr ausgerollt. Halbe Reproduzierbarkeit. Ein Modellwechsel oder ein geänderter top-k verschiebt das Verhalten, ohne dass die Prompt-Version sich rührt — die Version beschreibt dann nicht mehr, was tatsächlich lief.
3. Plausibler Fehlweg: Den Prompt in eine Config-DB legen und zur Laufzeit editierbar machen, damit man schnell nachjustieren kann. Editierbar ist nicht versioniert. Ohne festgehaltene, unveränderliche Versionen weißt du hinterher nicht, welche Fassung welche Ausgabe erzeugte — genau das Problem, das euch gerade den Rollback verbaut.
4. Plausibler Fehlweg: Für jede Prompt-Änderung das Service-Image neu bauen und über einen Git-Tag versionieren. Bündelt zwar, koppelt aber jede Inhaltsänderung an den vollen Code-Deploy-Zyklus — langsam für Fixes und schwer für Canary/Rollback. Das Artefakt sollte unabhängig vom Code deploybar sein.

Szenario

Euer Dienst ruft die Modell-API über einen floatenden Alias auf (die „latest“-Variante der Modellfamilie). An einem Morgen brechen plötzlich ~8 % der Antworten das erwartete JSON-Format — ohne dass ihr etwas deployt habt. Ursache: Der Anbieter hat das Modell hinter dem Alias still aktualisiert. Euer Canary- und Rollback-Prozess hat nie gegriffen, weil aus eurer Sicht kein Release stattfand.

Anforderungen

• Wie referenzierst du das Modell in Produktion künftig?
• Bewerte Ursache, wirksame Grenze und den Preis der tragfähigen Maßnahme getrennt.

Schritte

1. Tragfähiger Ansatz: An eine feste, datierte Modellversion/Snapshot pinnen und Upgrades bewusst als Release durch euren Shadow-/Canary-Prozess ziehen. Richtig. Der Pin gibt dir die Kontrolle über den Zeitpunkt der Verhaltensänderung zurück — jeder Wechsel läuft durch euren Rollout und kann gegatet und zurückgerollt werden.
2. Plausibler Fehlweg: Beim floatenden Alias bleiben, um automatisch von Modell-Verbesserungen zu profitieren — danach ohne Kontrollgruppe oder Stop-Gate vollständig auf den Produktionsverkehr ausgerollt. Das delegiert deinen Release-Zeitpunkt an den Anbieter. Stille Änderungen umgehen Canary und Rollback vollständig — genau die Regression, die euch heute Morgen getroffen hat.
3. Plausibler Fehlweg: An eine feste Version pinnen und dort dauerhaft bleiben, um Verhaltensänderungen für immer auszuschließen. Pins werden vom Anbieter irgendwann deprecatet und abgekündigt. Ohne aktiven Nachzieh-Prozess erzwingt das später einen Notfall-Wechsel ohne Testfenster — schlimmer als ein geplantes Upgrade.
4. Plausibler Fehlweg: Beim floatenden Alias bleiben, aber Alerts auf Output-Drift schalten, um Änderungen zu erkennen. Detection ersetzt keine Kontrolle: Der Alert feuert erst, nachdem die Änderung bereits Nutzer getroffen hat. Du willst den Wechsel vorab gaten, nicht ihn im Nachhinein bemerken.

Szenario

Eine neue Prompt- und Retrieval-Konfiguration verbessert das Offline-Eval. In Produktion könnte sie jedoch die Refusal-Rate und Antwortqualität für seltene Anfragen verschlechtern.

Anforderungen

• Ordne den Ablauf vom nachvollziehbaren Release bis zur kontrollierten Ausweitung.
• Bewerte Ursache, wirksame Grenze und den Preis der tragfähigen Maßnahme getrennt.

Schritte

1. Tragfähiger Ansatz: 1. Prompt, Modell-Pin, Decoding- und Retrieval-Konfiguration als gemeinsames, versioniertes Release-Artefakt festlegen.. Dieser Schritt besitzt eine fachliche Vorbedingung und einen überprüfbaren Abschluss.
2. Tragfähiger Ansatz: 2. Qualitätssignale, Vergleichsbasis, Zeitfenster, Rollback-Trigger und sicheren Fallback vor der Exposition festlegen.. Dieser Schritt besitzt eine fachliche Vorbedingung und einen überprüfbaren Abschluss.
3. Tragfähiger Ansatz: 3. Wenn Nutzerkontakt zunächst unvertretbar ist: Requests gespiegelt vergleichen und Seiteneffekte isolieren.. Dieser Schritt besitzt eine fachliche Vorbedingung und einen überprüfbaren Abschluss.
4. Tragfähiger Ansatz: 4. Kleinen echten Traffic-Anteil exponieren und nur bei erfüllten Qualitäts- und Betriebs-Gates ausweiten.. Dieser Schritt besitzt eine fachliche Vorbedingung und einen überprüfbaren Abschluss.
5. Tragfähiger Ansatz: 5. Bei Trigger auf das bekannte Artefakt oder den getesteten Fallback zurückführen.. Dieser Schritt besitzt eine fachliche Vorbedingung und einen überprüfbaren Abschluss.

Szenario

Ihr wollt für einen risikoreichen Anwendungsfall das Modell wechseln: eine LLM-Komponente, die eingehende Support-Tickets nur liest und zusammenfasst — keine Tool-Calls, keine Writes. Das Feature ist stark reguliert; schon eine kleine Rate falscher Zusammenfassungen bei echten Nutzern wäre inakzeptabel. Du willst die neue Variante an der realen Ticket-Verteilung prüfen, bevor irgendein Nutzer ihre Ausgabe sieht.

Anforderungen

• Wie validierst du die neue Variante vor dem ersten Nutzerkontakt?
• Bewerte Ursache, wirksame Grenze und den Preis der tragfähigen Maßnahme getrennt.

Schritte

1. Tragfähiger Ansatz: Shadow-Deploy: Produktions-Requests parallel an die neue Variante spiegeln, ihre Ausgabe verwerfen und offline gegen die alte vergleichen — kein Nutzer sieht die neue Ausgabe. Richtig — bei diesem nebenwirkungsfreien Read-only-Feature ist Shadow sauber: du prüfst an der realen Verteilung bei null Nutzerkontakt. (Bei Tool-Calls/Writes müsstest du diese im Schatten stubben, sonst doppelte Effekte.)
2. Plausibler Fehlweg: Direkt ein 1 %-Canary fahren und die Live-Qualitätsmetriken beobachten — danach ohne Kontrollgruppe oder Stop-Gate vollständig auf den Produktionsverkehr ausgerollt und nur anhand globaler Fehler- und Latenzwerte als erfolgreich markiert. Ein Canary exponiert echte Nutzer — auch 1 % sehen die eventuell schlechtere Zusammenfassung. Die Anforderung lautet „null Nutzerkontakt vor der Validierung“, und die verletzt der Canary.
3. Plausibler Fehlweg: Ein größeres, breiteres Offline-Eval-Set bauen und die Variante dagegen abnehmen. Das ist Offline-Methodik und ein anderer Hebel: es testet nicht die reale Produktions-Verteilung mit ihren Edge-Cases. Die Frage ist Runtime-Validierung an echtem Traffic, nicht Testset-Design.
4. Plausibler Fehlweg: Blue-Green: die neue Variante voll bereitstellen und per Umschalter live nehmen, mit sofortigem Rollback bei Problemen. Beim Umschalten sehen 100 % der Nutzer sofort die neue Ausgabe. Der schnelle Rollback macht bereits ausgelieferte schlechte Zusammenfassungen nicht ungeschehen und liefert keinen Vergleich vor der Exposition.

Szenario

Um 2 Uhr nachts fängt euer LLM-Feature — automatisch generierte Antwortvorschläge für Support-Agents — an, teils toxische und faktisch falsche Vorschläge zu liefern. Ein Rollback über eure CI/Deploy-Pipeline dauert etwa 20 Minuten. Ihr habt bereits einen einfachen, regelbasierten Nicht-LLM-Pfad, der brauchbare Standard-Antworten liefert.

Anforderungen

• Was brauchst du, um das entgleiste Feature sofort zu entschärfen?
• Bewerte Ursache, wirksame Grenze und den Preis der tragfähigen Maßnahme getrennt.

Schritte

1. Tragfähiger Ansatz: Einen Kill-Switch (Feature-Flag), der das Feature zur Laufzeit sofort auf den sicheren Fallback — den regelbasierten Nicht-LLM-Pfad — umlegt, ohne Deploy. Richtig. Der Schalter greift in Sekunden statt Deploy-Minuten und leitet auf einen funktionierenden, degradierten Pfad um — unabhängig davon, ob die Ursache im letzten Deploy, im Modell oder beim Anbieter liegt.
2. Plausibler Fehlweg: Über die CI/Deploy-Pipeline auf die letzte Version zurückrollen. Im akuten Incident zu langsam (hier 20 Minuten), in denen die schlechten Vorschläge weiterlaufen. Und wenn die Ursache am Modell/Anbieter liegt, rollt der Rollback auf dasselbe Problem zurück.
3. Plausibler Fehlweg: Das Provider-Rate-Limit stark drosseln oder den API-Key rotieren, um das Feature auszuhungern. Das bricht das Feature hart (Fehler statt Fallback), trifft womöglich andere Features am selben Key und liefert keinen sicheren Ersatzpfad — Agents stehen ohne Vorschläge da.
4. Plausibler Fehlweg: Einen Kill-Switch, der als Compile-Time-Konstante gesetzt und beim nächsten Deploy scharf geschaltet wird. Dann ist es kein Laufzeit-Schalter, sondern genauso langsam wie ein Rollback. Ein Kill-Switch muss ohne Deploy greifen, um schneller als der Deploy-Zyklus zu sein.