ki-engineeering/24-wartung-model-lifecycle.md

Wartung und Model-Lifecycle

Freitag Nachmittag, Provider-Changelog oder stilles Alias-Update: Montag steigen Repair-Raten, der Ton der Antworten ist „anders“, ein Tool wird seltener gewählt. Niemand hat deployed. Das Golden Set von vor sechs Wochen ist grün auf dem alten Pin — in Prod hing längst etwas anderes. Rollback dauert, weil model in vier Services und einer YAML „latest“ verstreut ist.

Foundation Models sind keine unsichtbare Utility. Sie sind Dependencies mit eigenem Release-Rhythmus — oft außerhalb eures Kalenders (T9).

Kern in einem Satz: Behandelt Model, Prompt, Index und Policy als versionierte Artefakte mit Pin, Change-Checklist, Canary und Rollback — wartbar wie kritische Libraries, nicht wie eine String-Konstante in der Env (T9, T10).

Anschluss: Routing und Pinning → Kapitel 09; Online-Qualität und Shadow/Canary → Kapitel 18; Eval-Gates → Kapitel 17; Serving → Kapitel 21. Checklisten: templates/model-change-checklist.md, templates/adr-model-hosting.md.

---

Bridge: Klassisches SE → AI Engineering

Klassisches SE	Model-Lifecycle …
Library SemVer / Lockfile	Model-ID pin; kein stilles latest in Prod
Dependency update bot + CI	Offline Eval + Safety + Cost-Estimate vor Promote
Canary deploy / feature flag	Canary auf Model/Prompt/Index-Version
Rollback artifact	Pin zurück + Flag; Minuten, nicht Tage
Changelog / release notes	Provider notes plus euer internes Behavior-Delta
Owner eines Services	Owner von Prompt, Eval, Model-Pin, On-Call
Deprecation policy	Dual-Run, Sunset-Datum, Eval auf Nachfolger
SBOM / supply chain	Provider, Region, Subprocessor, Model-Herkunft im ADR

Die Brücke: ihr integriert Fremdsoftware, deren „Patch“ Verhalten und Kosten ändern kann, ohne euren Compile-Schritt zu brechen. Deshalb ersetzen Eval und Canary den Compiler.

---

Was versioniert werden muss

Ein „AI-Release“ ist oft ein Bundle:

Artefakt	Versionieren als	Warum
Model	provider/model_id (+ revision falls verfügbar)	Verhalten, Preis, Limits
Prompt / Template	prompt_id@semver bzw. Content-Hash als prompt_version in Traces	steuert Output stark
Tools / Schemas	Contract-Version	Tool-Wahl und Args
Retrieval Index	index_version / corpus snapshot	Grounding
Policies / Guardrails	policy-pack version	Safety und Refuse-Rate
Orchestrator Caps	config version	Cost/Latency-Hülle
Eval Golden Set	set-version + labels	Gate-Wahrheit driftet auch

Gemeinsam in Traces loggen (Kapitel 22). Ein Prompt-Hotfix ohne ID ist ein unreviewbarer Prod-Patch.

Pinning — konkret

• Prod-Config referenziert explizite IDs.
• latest, stable-Alias ohne eure Kontrolle: nur hinter eigenem Mapping, das ihr moved.
• Staging darf experimentieren; Prod promoted bewusst.
• Self-Host: Image/Weights-Digest pinnen, nicht „was auf dem GPU-Node lag“.

---

Der Change-Prozess (Standardweg)

An model-change-checklist.md und Kapitel 18 anschließen:

1. Anlass & Hypothese (Cost, Quality, Provider-Sunset, Feature)
2. Offline: Golden Set + Safety Suite + Cost/Latency Estimate
3. Shadow (optional, spez- und privacy-ok)
4. Canary mit Stop-Regeln (Quality, Cost, Latency, Safety)
5. Promote + Annotation in Dashboards
6. Watch window 24–72h (feature-abhängig)
7. Changelog intern; Golden Set um neue Fälle erweitern

Decision Frame: Shadow, Canary oder beides?

Situation	Tendenz
Hohes Risiko / starker User-Impact	Shadow → Canary
Kleiner Prompt-Fix, gutes Offline-Gate	Canary reicht oft
Nur Cost-Opt, Quality-parität nötig	Shadow stark nutzen
Tool-Writes im Pfad	Shadow read-only / dry-run
Provider-Notfall-Sunset	beschleunigt, aber nicht ohne Mini-Eval + schneller Rollback

Rollback ist First-Class

Rollback-Ziele:

1. vorheriger model_id
2. vorherige prompt_version
3. vorherige index_version / Flag
4. Feature-Flag off / degrade mode

Wenn Rollback > Zeitbudget eures Incidents braucht, ist das Versions- und Config-Konzept der eigentliche Bug (T9).

---

Provider-Updates und „Breaking ohne Compile Error“

Typische äußere Trigger

Trigger	Risiko
Neues Default-Modell hinter Alias	stilles Behavior-Change
Deprecation / Sunset	erzwungener Wechsel
Preis- oder Limit-Änderung	Envelope bricht
Tool-/Schema-API-Änderung	Integration bricht hart
Safety-Filter strenger/locker	Refuse-Rate und UX
Eigene Self-Host Engine-Upgrade	Performance und Numerics

Interne Haltung

• Abonniert Provider-Status und Changelog; Owner liest sie (T10).
• Periodischer Diff-Lauf: fester Golden-Canary gegen Prod-Pin vs. Kandidat.
• Vertrag/ADR: was passiert bei forced migration? (adr-model-hosting.md)

SemVer-Hoffnung begrenzen: Ein neuer Name „…-mini-2“ kann näher an einem Breaking Change sein als ein Patch eurer Library. Eval ist euer Compiler.

---

Dual-Run, Deprecation, Sunset

Alt (pin A) ──canary──► Neu (pin B)
     \                    /
      \___ dual report ___/
               │
         promote B / rollback A
               │
         sunset A nach Stabilität

Phase	Tun
Announce	intern: Datum, Grund, Risk
Dual	Metriken A vs. B; Eval beide grün
Cutover	Traffic nach Plan; Flag
Sunset	A entfernen, Config aufräumen, Docs

Kein ewiges „wir supporten drei Models“ ohne Owner — das ist Legacy mit Token-Rechnung.

---

Self-Host Lifecycle (kurz)

Zusätzlich zu API-Pins:

Thema	Praxis
Weights/Image	Digest, Registry, reversible Deploy
Serving-Engine	separate Canary (Perf + Quality)
Capacity	vor Traffic-Shift Lasttest
Security patches	Infrastruktur-SLA, nicht „Model-Team irgendwann“
Rollback	vorheriges Replica-Set / Modell-Gewicht

Self-Host verschiebt Kontrolle und Verantwortung. Lifecycle-Disziplin steigt, nicht sinkt (Kapitel 09, 21).

---

Ownership: wer wartet was?

Artefakt	Typischer Owner	Mit
Feature-Spec / Success Metrics	Produkt + Eng	—
Prompt-Version	Capability-Team	Eval-Owner
Model-Pin / Routing	Platform oder Capability (klar wählen)	Security bei Residenz
Golden Set	Eval-Owner	Domain-Reviewer
Index-Pipeline	Data/Search/Capability	Privacy
On-Call Runbook	Team mit Page-Last	Platform

Unklare Ownership ist ein häufiger, typischer Failure Mode, warum latest überlebt und Incidents länger dauern (T10). Team-Tiefe → Kapitel 26.

---

Patterns und Trade-offs

Pattern: Model pin registry

Eine zentrale Config (oder Service): Capability → primary/fallback pins + versions. Alle Services lesen dort.

Trade-off: Platform-Invest; verhindert Pin-Drift über Repos.

Pattern: Compatibility contract tests

Kleine Suite: Schema-Shape, Tool-Call-Form, „verbotene“ Outputs, Latency smoke — neben voller Golden Quality.

Trade-off: mehr Pflege; fängt mechanische Breaks früh.

Pattern: Change calendar

Geplante Model-Reviews (z. B. monatlich) statt nur Notfall-Sunset.

Trade-off: Prozesslast; weniger Überraschung und technische Schuld am Pin.

Pattern: Prompt und Model koppeln releasen

Wenn ein Prompt nur mit Modell B funktioniert: ein Release-Bundle, nicht zwei unabhängige Deploys.

Trade-off: weniger Flexibilität; weniger halb-kompatible Zustände.

Decision Frame: Fix-Forward oder Rollback?

Signal	Tendenz
Safety / schwerer Quality-Drop nach Change	Rollback zuerst
Kleiner Format-Bug, Offline grün reproduzierbar	Fix-Forward mit Mini-Canary
Provider total out	Fallback-Pin, nicht Prompt-Hotfix-Chaos
Unklare Ursache	Traffic runter + Evidence; nicht drei Änderungen gleichzeitig

Trade-off: häufig small updates vs. seltene big bangs

Häufig klein	Selten groß
Übung im Prozess	rostiger Muskel
mehr Canary-Overhead	höheres Delta-Risiko
schneller lernen	„alles auf einmal“-Schmerz

Mit automatisierten Gates und Canary sind kleine, häufige Wechsel meist gesünder — analog zu gutem SE-Release-Wesen.

---

Anti-Patterns

Anti-Pattern	Symptom	Besser
latest in prod	unerklärliche Deltas	pin + registry
Hotfix prompt unversioned	kein Diff, kein Rollback	prompt_id + Gate
Big-bang swap Friday 17:00	Wochenend-Incident	Canary + Watch window
Eval once, never again	Golden Set veraltet	periodisch + aus Prod lernen
No rollback path	„muss fixen“ unter Druck	Pin zurück in Minuten
Every team own model string	Drift, Rechnung unklar	zentrale Pins
Ignore provider changelog	Sunset-Panik	Owner + Kalender
Canary only on 5xx	Silent Degradation	Quality/Cost stops
Self-host without upgrade owner	veraltete Engine	named infra owner
Change three things at once	keine Kausalität	eine Variable pro Canary

---

Production Notes

Cost. Jeder Kandidat-Lauf (Shadow, parallele Eval) kostet. Einplanen. Model-Wechsel kann €/Task halbieren oder verdoppeln — Estimate ist Gate, nicht Nachtrag (T7, Kapitel 23).

Latency. Neue Modelle/Engines verschieben TTFT und Total. Canary-Stop-Regeln inkl. Latency-Envelope.

Observability. Annotations bei Promote; vor/nach Vergleichbarkeit. Pflicht: versions on every trace (Kapitel 22).

Security / Privacy. Neues Modell/neuer Provider = erneute Residenz- und DPA-Annahme (Kapitel 20). Safety-Suite vor Promote (Kapitel 19).

Lifecycle. Dieses Kapitel ist die Lifecycle-Note: Pin, Checklist, Canary, Rollback, Owner. Production-Ready verlangt den Prozess eingebaut (production-ready-checklist.md). Wenn es trotzdem brennt → Kapitel 25.

---

Key Takeaways

• Model, Prompt, Index, Policy sind versionierte Dependencies — Pin statt latest (T9).
• Standardweg: Offline-Gates → Shadow/Canary → Promote → Watch → Changelog.
• Rollback in Minuten ist Teil des Designs, nicht Hoffnung.
• Provider-Updates brechen ohne Compiler-Fehler — Eval und Canaries sind euer Schutz.
• Zentrale Pins und klare Ownership verhindern Drift und verlängerte Incidents (T10).
• Checklist leben: model-change-checklist.md.

Praktische nächste Schritte

1. Sucht alle Prod-model-Zuweisungen; ersetzt latest/Alias durch Pins und dokumentiert sie.
2. Führt prompt_version (oder Hash) ein und loggt sie in Traces.
3. Verankert model-change-checklist.md im Release-Prozess der Top-Capability.
4. Definiert Rollback-Run (wer, welches Flag/Config) und übt ihn einmal.
5. Benennt Owner für Provider-Changelog und monatlichen Pin-Review.
6. Wenn es schiefgeht trotz Prozess: Incident Response.