Produktive KI-Releases brauchen mehr als Modellversionierung

Produktive KI-Systeme können ausfallen, obwohl Modell und Anwendungscontainer unverändert bleiben. Liefert eine neue Retrieval-Konfiguration mehr Kontext, kann dies die Generierung verlangsamen, die Inferenzkapazität überlasten und Anfragen in eine Warteschlange zwingen. Ein einfaches Zurücksetzen des Containers behebt das Problem dann nicht.

Den vollständigen Release definieren

Die praktische Einheit einer Bereitstellung ist die getestete Kombination aus Anwendungscode, Modellrevision, Prompts, Retrieval-Indizes und Embeddings, Tool-Verträgen, Serving-Konfiguration und Evaluationsdaten. Ein versioniertes Release-Manifest kann diese Bestandteile verknüpfen und den vorherigen kompatiblen Release ausweisen.

Das Manifest sollte auf aufbewahrte Konfigurationen und Artefakte verweisen. Dazu gehören Ausführungsparameter wie Token-Limits, Batching, Timeouts und Ressourcenzuweisung. Bei kontinuierlich veränderten Daten sollte es den Stand der Datenaufnahme sowie die Indexkonfiguration dokumentieren. Für Geheimnisse werden nur Referenzen gespeichert, niemals die geheimen Werte selbst.

Eine bitgenaue Reproduzierbarkeit garantiert das nicht. Externe Dienste können sich verändern, die Generierung kann nichtdeterministisch bleiben und manche Anbieter stellen keine unveränderlichen Modell-Snapshots bereit. Solche Grenzen müssen dokumentiert werden, statt einen veränderlichen Alias als feste Version auszugeben.

Die Aufgabe der Nutzer testen

Eine HTTP-200-Antwort belegt nicht, dass eine KI-Funktion ihren Zweck erfüllt. Bei einem Dokumentationsassistenten muss eine Evaluationssuite möglicherweise Quellenangaben, die korrekte Produktversion und die Weigerung prüfen, bei fehlenden Belegen Anweisungen zu erfinden.

Die Suite sollte normale Aufgaben, bekannte Fehler, mehrdeutige Anfragen, eine dürftige Beleglage und Versuche zur Überschreitung von Berechtigungsgrenzen abdecken. Ein zurückgehaltener Datensatz reduziert die Überanpassung bei Prompt-Änderungen. Deterministische Prüfungen können Schemas, Tool-Argumente, Quellenkennungen und Berechtigungen validieren. Semantische Bewertungen benötigen dagegen festgelegte Kriterien und menschliche Kontrolle. Ein modellbasierter Bewerter kann die Prüfung priorisieren, gilt aber nicht als verlässliche Wahrheit.

Die Evaluation muss Retrieval, Generierung und Ausgabevalidierung gemeinsam durchlaufen. Abnahmekriterien sollten Qualität, Verstöße gegen Zugriffskontrollen, Latenz und Kosten unter repräsentativer Last berücksichtigen. Scheitert eine Prüfung, müssen Release-IDs, fehlgeschlagene Fälle und Traces zur Fehleranalyse erhalten bleiben.

Das Gesamtsystem messen und zurücksetzen

Lasttests sollten Ein- und Ausgabelängen, Parallelität, Lastspitzen und Cache-Zustände variieren. Zeit bis zum ersten Token, Geschwindigkeit der weiteren Token-Erzeugung, Gesamtdauer und Wartezeit beschreiben unterschiedliche Nutzererfahrungen. End-to-End-Traces helfen dabei, Verzögerungen durch Retrieval, Scheduling, Inferenz oder nachgelagerte Dienste voneinander zu unterscheiden.

Ein Canary-Rollout ermöglicht einen kontrollierten Vergleich, doch kein bestimmter Traffic-Anteil ist allgemein sicher. Teams sollten Verantwortliche, Abbruchbedingungen und Mindestanforderungen an die Beobachtungsdauer vor der Freigabe festlegen. Zusätzlich müssen sie absolute Serviceziele prüfen, weil eine gemeinsam genutzte Abhängigkeit sowohl Kandidat als auch Kontrollversion beeinträchtigen kann.

Ein Rollback muss kompatible Abhängigkeiten einschließlich Retrieval-Indizes und Caches wiederherstellen, nicht nur ältere Modellgewichte. Laufende Generierungen und Nebenwirkungen von Tools benötigen eigene Regeln für kontrolliertes Beenden, Abbruch und Idempotenz. Nach einem Vorfall sollte der Fehler als neuer Evaluationsfall aufgenommen werden, damit Betriebserfahrungen in künftige Releases einfließen.

KI-generierte redaktionelle Illustration; kein Dokumentarfoto.

Quelle: Why model versioning is not enough for production AI